pi-mono 的极简 与李小龙的哲学 引言
“拥抱 AI”的分水岭，往往不在模型本身，而在你能不能把它放进一套长期可控的工作方式里：能做事、能纠偏、能复盘、能持续迭代。 这也是为什么讨论 Agent 时，单纯比较“功能多不多”常常会跑偏。复杂并不必然更强，它可能带来更细的控制，也可能带来更多摩擦：责任被切得更碎、错误传播链更长、纠偏成本更高。 pi-mono 有意思的地方在于它选了另一条路径：不急着堆控制器，而是把框架收敛成少数原语与可靠主循环，把“判断”交给 LLM，把“边界与记录”留在工程结构里。 它的工程价值也被行业项目认可：OpenClaw 的作者 Peter Steinberger（X/Twitter: @steipete）将 Pi 作为核心 runtime 之一接入，并在 README 里公开致谢：“Special thanks to Mario Zechner for his support and for pi-mono.” 这篇文章不求讲全 pi-mono，而是只抓它最有辨识度、也最可迁移的几块： 极简原语（read / edit / write / bash） 主循环（生成 → 执行工具 → 回填 → 再生成） steering（用户可插话、可打断、可改线） compaction（Goal-first 摘要，让长任务不丢方向） 树与分叉（把试错变成可回滚、可复盘的结构） 哲学参照来自李小龙（Bruce Lee）：截拳道不是“少练”，而是把基础动作提炼成原语，让少数原语组合出无限打法。 如果你还在因为AI的快速进展而焦虑，一定读完这篇文章，我相信会让你有所收获。 致谢：Mario Zechner（pi-mono 主要作者，GitHub: badlogic，X/Twitter: @badlogicgames ）， Bruce Lee。 GitHub：badlogic/pi-mono
正文
第一原则：分工——pi-mono框架当手脚，LLM 当大脑 如果把一个 Agent 看成“会干活的队伍”，最常见的失败方式不是模型不够聪明，而是分工错了：框架越想替模型思考，越容易把自己写成一套僵硬的套路；模型越被框架牵着走，越难在关键时刻纠偏。 pi-mono 的第一刀下得很狠：框架不当教练，只当手脚；模型不当打字机，而当大脑。 框架做的事几乎只有三件：
接住模型输出（解析工具调用）
执行工具（read / edit / write / bash）
把结果回喂（toolResult 进对话） 其余所有“聪明”的选择——先读哪份文件、先跑哪条命令、要不要回滚、要不要换路——都交给 LLM。 这不是偷懒，而是一种截拳道式的纪律：把“套路”从框架里拿掉，把“判断”还给大脑。 你可以把它理解成两种完全不同的系统气质： 传统“重框架”像门派套路：招式写得很全，但一旦现场变了，改一处就牵一身。 pi-mono 像截拳道原语：动作少，但每个动作都通用；现场一变，立刻换组合。 于是它敢把系统简化到近乎残酷的程度：框架不做路径规划、不做任务分解、不写状态机。它只负责让“想法”能落地，让“事实”能回到模型脑子里。
主循环是心脏：出招机制（packages/agent/src/agent-loop.ts） 分工决定上限，但让系统“活起来”的，是它的心跳。 pi-mono 的心跳不在某个高明的规划器里，而在一个近乎原始的循环：想一下 → 动一下 → 看结果 → 再想一下。这听起来朴素，却是很多复杂 Agent 做不到的事——它们往往“想太久”，或者“动太多”，却没把反馈当成下一步决策的第一输入。 从代码视角看，这个 loop 有两层节奏： 外层循环（出招）：调用模型生成 assistant 回复；把回复写入会话；如果没有工具调用，就收手。 内层循环（连击）：如果回复里带 toolCalls，就按顺序逐个执行；每执行完一个工具，就把 toolResult 写回会话；再决定要不要执行下一个。 这套循环的关键不是“会执行工具”，而是它的实战气质：允许被打断，允许改线。 当用户在工具链执行过程中发来新消息，pi-mono 会把它当成“局势变化”，而不是“等我打完这一套再说”。具体表现就是： 只要检测到 queued user message，就中断剩余未执行的 toolCalls； 并在记录里留下明确痕迹：“Skipped due to queued user message.” 这一步很像截拳道的“截”：不是把动作做完，而是在正确时机把错误动作链截断。 还有一个更工程但更关键的点：pi-mono 内部始终维持统一的 AgentMessage[] 结构（便于记录、压缩、回放），只在“模型调用边界”才转换成 provider 需要的 Message[]。 这意味着：插话、压缩、回放这些会让系统变复杂的事情，面对的都是稳定的数据结构。手脚不乱，心跳才稳。
对比：“Pi” vs “重框架 Agent”——“截拳道原语”与“门派套路” 如果你只看功能清单，“Pi”和“重框架 Agent”很难分出高下：都能读文件、跑命令、改代码，也都能做“计划”“反思”“验证”。真正的差别不在功能，而在气质——它们把“确定性”放在了不同的位置。 “重框架 Agent”更像门派套路：它相信只要把流程写得足够完整，就能把不确定的世界压进一套可控的招式里。于是你会看到：任务分解树、状态机、评分器、重试器、反思器、验证器……每一层都有自己的逻辑，也都有自己的盲区。 这套方法的优点很实际：在边界清晰、任务结构稳定、失败模式可枚举的场景里，它能跑得很顺。它的问题也同样实际：一旦进入真实世界的混沌区——需求会变、证据会补、用户会插话、工具输出会反复打脸——流程就开始积累惯性。 惯性来自哪里？往往来自一种不自觉的前提：把变化当例外，把流程当常态。 下一步被写进流程图时，现场的变化就被当成“之后再处理”； 纠偏被包进某个模块时，纠偏就被安排在“系统允许它发生”的时点； 控制被切成很多小责任时，“对齐目标”反而很难落在某一个清晰的主体上。 很多 Agent 失控不是因为它们不会做事，而是因为它们太像一套已经写好的“连招”：连招可以很漂亮，但连招对“突然变化”天生迟钝。 “Pi”的选择更像截拳道：不是用更多套路对抗不确定，而是用更少的原语承载不确定。 原语少：read / edit / write / bash 足够朴素，朴素到几乎不带立场。 循环短：每一次“想”都紧贴一次“动”，每一次“动”都紧贴一次“看结果”。 可被打断：steering 把“用户新意图”当成随时可能发生的现实，而不是异常。 方向可保留：compaction 用 Goal-first 把“要做什么”做成硬路标，让长任务不靠记忆，而靠结构。 所以它的控制方式不是“提前规划得更细”，而是“把反馈回路做得更短”。短回路并不会让系统更聪明，但往往让系统更不容易跑偏。 这也解释了一个常见误会：
极简是不是意味着能力弱？ 未必。极简只是把能力从“框架里写死”换成“由模型在现场组合”。框架做的少，不代表系统做的少；它只是把“做什么”留给大脑，把“怎么做得可靠”交给手脚。 如果要把这段对比翻成李小龙语言，大概是： 门派套路追求“招式覆盖率”，但覆盖率越高，越容易被自己的招式拖慢。 截拳道追求“反应带宽”，把动作种类压到少数原语，把带宽留给时机、距离和判断。 写到这里，“Pi”的极简就不太像一种审美，更像一种节制：它不试图提前赢下所有局面，只是把系统做成一件更接近现实的东西——能停一下，看一眼，再改线。
缓存友好设计：把“重复话”变成“可复用前缀” 很多人第一次听到“System/Tools 分层”，会下意识反问：那不是更长了吗？怎么还省 token？ 省不省，看的不是“理念里有几层”，而是每次调用你喂给模型多少重复内容。 对长对话来说，最昂贵的往往不是新信息，而是你一轮又一轮地把同一套背景、规则、工具说明重新讲一遍——模型也要一遍又一遍地重新理解。 pi-mono 的做法很朴素：把长期不变的东西挪到稳定层，把每一轮真正变化的东西留在消息层。 System：行为原则与写作/工作方式（像“拳的性格”） Tools：能力边界与使用说明（像“规则 + 兵器说明书”） Messages：现场证据与最新意图（像“当下对手与地形”） 这套分层本身就会逼着你把“长期不变”写得更短、更规整，避免散落在聊天里反复重述。平台若支持 prompt caching，这种稳定前缀的意义会更大：同一段前缀在多次调用里保持一致，就更有机会被复用处理结果，减少反复“读懂背景”的成本。 30 轮对话的直觉账本（粗估） 把 System+Tools 当作“稳定前缀”，Messages 当作“新增信息”。对话越长、轮次越多，稳定前缀越能复用，重复理解的成本就越低。 以 30 轮为例：在“重 coding + 已触发 compaction”的场景下，稳定前缀带来的重复负担通常能被压到原来的约 1/5–1/10（即减少约 80%–90%）。 这不是精确计费表，但足够传达一个实践经验：长会话里，真正昂贵的往往是“反复讲同一套背景”；而稳定前缀做得越干净，这部分就越少。
少而精：read / edit / write / bash——把动作“原语化”，才能组合出无限打法 李小龙反复强调：真正可依赖的不是“招式库有多大”，而是你手里那几样基本动作是否足够通用、足够快、足够熟练。 pi-mono 把工具收敛到四个最硬的原语： read：获取事实 edit：局部修改（低噪音、可控） write：写入新文件或大段内容 bash：把系统能力当作“外骨骼”调用 表面看像“工具少”，实质是把动作压成最小可组合单元（primitive）：少数原语 → 无限组合。 5.1 对比视角：Claude Code 的“十几种原语” 为了让差异更清晰，可以对照一个典型的“工具更丰富”的体系：Claude Code。 Claude Code 除了 Bash 之外，还提供了多种专用工具来分别承担“找、读、改、写、记、查”的不同职责，例如： LS（列目录） Glob（按通配符找文件） Grep（在文件中搜索） Read（读文件） Edit / MultiEdit（局部替换 / 多点替换） Write（写文件） NotebookRead / NotebookEdit（读写 Jupyter） WebFetch / WebSearch（抓网页 / 搜网页） TodoRead / TodoWrite（会话任务清单） Task/Agent（起一个子 agent 去搜索/探索） exit_plan_mode（从“计划模式”切回执行） 这套“十几种原语”的好处很直观：每个动作更专门、更明确，能把常见操作拆得更细，工具边界也更清晰。 5.2 pi-mono 为什么仍坚持“四招” pi-mono 的选择很像截拳道：不追求“招式越多越好”，而追求“原语越少越通用”。它的逻辑大致是：
工具越多，越像门派套路：动作变细固然方便，但也更容易把“如何做”写死在工具结构里。
原语越少，组合空间越大：read/edit/write/bash 四个动作足够覆盖“查证—改动—验证—回滚”的全链路，其余差异交给 LLM 在现场组合。
把“聪明”留在大脑里：pi-mono 不想在框架层做太多“预判”，更愿意让 LLM 根据证据临场决定下一步是 read 还是 bash，先改哪一段、要不要回滚。 这不是说“工具越多越差”。更准确的说法是： Claude Code 更像一套装备齐全的训练馆：器械多、分工细、流程更容易标准化。 pi-mono 更像截拳道的街头实战：动作少，但每个动作都足够通用，能在混乱环境里快速组合出路。 真正关键不在于“工具数量”，而在于你想把复杂性放在哪里： 放在工具层：用更多专用工具把世界切得更细； 放在大脑层：用更少原语把世界留给临场判断。 这也解释了为什么 pi-mono 的四招能撑起长任务：它训练的是“组合能力”，而不是“背诵套路”。
截击与改线：Steering 让“现实变化”优先于计划 截拳道里最核心的一个字是“截”。它不是“快”，而是“对”：在对方招式还没走完时，就抓住关键时机截断、转向。 pi-mono 的 steering 不是一句口号，而是一套非常具体的工程机制：在执行工具调用链（toolCalls）时，允许用户新消息插队；一旦插队发生，立即中断剩余工具调用，把控制权还给用户。 下面把它拆成三层讲清楚：消息队列、执行循环、以及“被跳过”如何落在记录里。 6.1 问题是什么：工具调用链很容易“跑过头” LLM 经常会一次性生成一串工具调用，比如：
read 配置文件
bash 跑测试
edit 改代码
bash 再跑测试 如果系统傻傻地把这串全部执行完，风险很大： 用户在第 2 步看见测试输出，想补充信息/改目标，但系统仍会继续执行第 3、4 步。 这会造成“错方向的改动”被写入文件，甚至引入更多噪音。 所以 steering 要解决的是一个很朴素的实战问题：用户的最新意图必须能打断旧的动作链。 6.2 机制一：用户消息进入队列（Queued user message） pi-mono 并不是“等工具都跑完再看用户说什么”。它在 agent loop 里会维护一个“用户消息队列”： 当用户在执行过程中发来新消息，这条消息会被排队（queued）。 loop 在合适的检查点会看队列：只要队列不空，就把它视为“新的局势已出现”。 这里的关键思想很像武术：新情报优先级高于旧计划。 6.3 机制二：执行循环分两层，steering 发生在内层 可以把 pi-mono 的 loop 想成两层： 外层循环：调 LLM 生成 assistant 回复（可能包含 toolCalls） 把回复写入会话记录
内层循环（工具执行链）：逐个执行 toolCalls 把每个 toolResult 写回会话 每执行完一个工具，就检查一次“用户队列是否有新消息”
steering 的“截击”就发生在内层： 如果队列里出现用户新消息：立即停止执行剩余 toolCalls 把还没执行的工具调用标记为跳过 直接回到外层，让 LLM 在“新消息 + 已发生的工具结果”基础上重新生成下一步
这就是“可被打断、可转向”的技术含义。 6.4 机制三：跳过不是黑箱——会在记录里留下痕迹 一个很容易被忽略的细节：pi-mono 不会把未执行的 toolCalls 悄悄丢掉。 它会在会话里留下明确标记，类似： Skipped due to queued user message. 意义是两点： 1) 对用户诚实：你知道哪些动作被取消了。 2) 对系统可追溯：后续如果要复盘“为什么没执行那一步”，日志里有证据。 这和截拳道的训练记录很像：不是“我当时感觉不对就没做”，而是把“停止与改线”本身也当成一种可记录的动作。 6.5 还有一个更工程的点：内部结构稳定，边界处才转换 pi-mono 在内部会尽量保持自己的 AgentMessage 结构（便于记录、压缩、回放），只在“调用模型”这个边界，才把内部消息转换成 provider 需要的 Message[] 格式。 这看似是实现细节，但和 steering 的关系很大： 内部结构稳定 ⇒ 更容易在任意时刻插入用户消息（队列/插话） 边界转换集中 ⇒ 更容易保证“哪些信息被喂给模型”是可控的 6.6 把技术翻回李小龙：steering 就是“前手优先级” 在哲学上，steering 对应的不是“聪明”，而是“纪律”： 现实变化优先 最新意图优先 停止与改线是默认能力，而不是失败 这就是“截”：不是把动作链做完，而是在正确的时机把它截断。 6.7 怎么操作：Enter vs Alt+Enter（两种插话方式） pi-mono 把“插话”分成两种，分别对应两种心理预期： Enter：Steering（立刻改方向）用在：你要马上纠正目标、补充关键信息、或止损，别让后续工具继续跑偏。 行为：消息会在当前工具执行完后立刻送达；系统会跳过剩余未执行的工具调用，回到外层重新生成下一步。
Alt+Enter：Follow-up（先排队，不打断）用在：你只是想先把补充想法记上，但不介意它把当前这一串工具执行完。 行为：消息会进入 follow-up 队列，等 agent 完成这一轮所有工作后再送达，不会中断工具链。
如果需要紧急止损（例如 bash 跑错了、正在改错文件），除了发消息之外，也可以使用界面的“停止/中止”操作把当前执行停下来，再发送新的 steering。
目标不走丢：Goal-first compaction 的“强记忆”机制 “不分解任务”最容易被质疑的一点就是：长对话会不会把初始目标忘掉？ pi-mono 的回答很直接：不靠任务树防迷路，而靠 compaction（压缩）把“路标”做得足够硬。它不是随便总结两句，而是把“目标、约束、进度、下一步”固定成结构，让目标在每次压缩后都重新出现在视野最前面。 下面把它按工程机制拆开：什么时候触发、怎么写摘要、怎么更新摘要、摘要如何回注入对话，以及它如何降低“漏信息”的风险。 7.1 什么时候触发 compaction：不是每轮都压，而是逼近窗口才压 对话会不断增长，增长的不是“轮数”，而是 tokens。pi-mono 会在上下文接近窗口上限时触发压缩： 保留最近一段原文不动（避免“刚刚说过的细节被压缩掉”） 更早的历史改为摘要（用一条结构化 summary 取代大量旧消息） 直觉上可以理解为： 最近发生的事 = 现场 更早发生的事 = 路标 7.2 摘要为什么 Goal 放第一行：这不是文风，是强制记忆的结构 compaction 的核心不是“写得像不像”，而是“结构”。pi-mono 用的总结模板把 Goal 放在第一块： 先写 Goal（用户到底要完成什么） 再写 Constraints（有哪些硬要求/偏好） 再写 Progress（Done / In Progress / Blocked） 再写 Key Decisions（哪些决定不能丢） 再写 Next Steps（下一步按顺序列出来） 最后写 Critical Context（关键数据/例子/引用） 这相当于把摘要变成一张检查清单：每一项都在强迫模型回想“这一类信息有没有漏”。 7.3 多次压缩怎么办：不是重写，而是“在旧摘要上更新” 长会话可能被压缩很多次。pi-mono 第二次以后不会让模型从零再写一份新摘要，而是把旧摘要完整交给模型，让它按规则做“合并更新”。 更新规则的关键点是两句： 保留既有信息（PRESERVE） 保留既有目标（PRESERVE existing goals），必要时只新增 这就是“强记忆”的实质：目标不是每次靠模型重新回忆出来，而是被要求在每次更新时显式保留。 7.4 摘要怎么回到对话里：作为一条特殊消息注入上下文 压缩后，旧历史不会消失成黑箱，而是被替换成一条“对话已被压缩”的消息，消息正文包含那份结构化 summary。随后用户的新消息继续追加。 效果是：模型下一次看到上下文时，最早那段冗长历史被一份短摘要替代，但摘要的第一件事就是 Goal。 从模型视角看，它每次“重新进入任务”时，看到的开头永远像这样： 你要做什么（Goal） 你不能做什么/偏好什么（Constraints） 你做到哪了（Progress） 你下一步要做什么（Next Steps） 这就像截拳道的前手：每次重新开打前，先把距离、方向、节奏摆正。 7.5 为什么它能降低遗忘：把“目标记忆”从自由发挥变成硬约束 如果没有这种结构，模型在长对话里最容易犯的错是： 记住了最近细节，却忘了最初目标 记住了局部争论，却丢了全局约束 下一步越走越像“把工具跑完”，而不是“把目标做完” Goal-first 模板把这三类风险都压住了： 目标被强制写在第一块 约束被强制单列 进度/下一步被强制维护 所以 pi-mono 不靠任务树“规划路线”，而靠摘要“保持方向”。 7.6 诚实的边界：它不验证摘要质量，但用工程手段降低漏项风险 需要坦诚：pi-mono 不做摘要质量验证（没有第二模型对照、没有自动 completeness check）。这意味着漏信息的可能性在理论上存在。 它的实用主义选择是： 用更高推理强度 + 更严格结构降低风险 用“更新旧摘要而非重写”降低漂移 用“保留最近原文”保护临场细节 必要时让用户通过 read/再读文件把关键事实重新拉回上下文 技术上，这是把“不可完全消灭的风险”转成“可控且可补救的风险”。
摘要质量：承认边界，但用“基本功”把风险压到可接受 讲到这里，一个尖锐问题就出现了：
compaction 摘要要是漏了关键信息怎么办？ 如果用“门派套路”的思路，这个问题会诱发无穷无尽的补丁：再加一层验证、再加一个审稿模型、再加一个对照器、再加一套回退策略……最后系统确实更“完备”，但也更重、更慢、更难维护。 “Pi”的回答更接近李小龙的实战观：承认不确定，承认风险存在，然后把风险压到一个可接受的范围。 它并没有做“摘要质量验证”，也没有让第二个模型逐条对照历史，更没有要求用户逐次确认。它选择的不是“绝对正确”，而是“足够可靠 + 足够便宜 + 足够持续”。 8.1 “Pi”做了什么：不是老师批改，而是把题目变得不容易答错
高推理强度 摘要不是随便写的，它会让模型“认真想”再写，尽可能降低漏项概率。
结构化模板 = 检查清单 Goal / Constraints / Progress / Key Decisions / Next Steps / Critical Context 这套顺序，本质上是在逼模型逐项检查： 目标是什么？ 有什么约束？ 做到哪了？ 哪些决定不能忘？ 下一步是什么？ 哪些关键材料必须带着走？ 这很像训练时的“基本功口令”：不是让你自由发挥，而是让你按固定节拍把关键点都过一遍。
迭代式保留：更新而不是重写 多次压缩时，它不是“从零再写一份摘要”，而是在旧摘要上做合并更新：保留既有目标、更新进度，把 in progress 移到 done。 这对应训练日志的逻辑：你不是每天重写一遍过去，而是在同一本记录上追加今天。
保留最近原文：让“临场细节”不受伤 压缩不是把所有历史都变成摘要；它会保留最近一段原始对话不动。很多时候，真正危险的是“刚刚说过的细节被压缩掉”，而“Pi”把这部分风险直接切掉。 8.2 “Pi”没做什么：它明确选择了不走“门派套路化”的方向
没有摘要验证 摘要生成后直接进入会话，没有二次模型对照，也没有格式完整性检查。
没有质量回退 如果摘要写得不好，但 API 调用没有报错，它不会自动回退到压缩前的历史。
没有人工确认 压缩过程通常是静默发生的，用户不会被迫“审稿”。 这三条看似“缺点”，其实是一个非常明确的价值取向： 系统宁可把复杂性留给人（必要时你自己回读文件/重新 read）， 也不把复杂性堆进框架（把每次压缩都变成昂贵的审计流程）。 8.3 用一个比喻把取舍讲透：开卷考试，但没有老师逐题批改 “Pi”的摘要质量保障更像一场开卷考试： 给你固定答题模板（结构化 prompt） 给你足够思考时间（高推理） 给你上一版答案做参考（旧摘要） 还会保留最近几题的原卷（保留最近原文） 但它没有做三件事： 没有老师逐题批改（不验证） 答错了不补考（不回退） 成绩不强制公示（不让用户每次确认） 这听起来“放任”，但实战里它反而很诚实：它把系统能保证的部分做到工程化，把系统难以保证的部分交还给人。 李小龙的哲学同样如此：他反对“万能套路”，因为那是一种把不确定性假装消灭的傲慢。真正的强，是把基本功练到足够可靠，然后在不确定性面前保持清醒。
对话版 Git：/tree /fork /status /commit /merge——把试错变成“可回滚的记录” 真正让人疲惫的不是试错，而是试错之后什么也没留下：你只记得自己“走过很多路”，却说不清哪一步带来了结果、哪一步只是噪音。 pi-mono 用一套很像 Git 的会话操作，把“探索”变成可管理的结构：对话是树，分叉是实验，提交是记忆，合并是筛选。 9.1 /tree：先知道自己在哪 长对话最常见的失控不是跑偏，而是“定位感消失”。/tree 把会话结构摊开：主干在哪里，分叉在哪里，你现在站在哪个节点。 9.2 /fork：把试验从主线里挪开 当你想做一个可能会失败的尝试（换方案、改 prompt、重写逻辑），最好的保护不是更谨慎，而是更结构化：/fork 让你在当前节点分出支路，失败就留在支路里，主线不受污染。 9.3 /status：让变化可见 试错之后最怕“凭感觉”。/status 把你到底改了什么、差异在哪里，变成可检查的事实。 9.4 /commit：把一次有效改动封口 没有 commit 的探索很难复用。/commit 让你把一次改动写成一条清晰记录：目的、改动点、结果。它更像训练日志：不是记情绪，而是记动作。 9.5 /merge：只把可靠的带回主线 /merge 做的不是“把一切都带回去”，而是把验证过的成果回灌主干，把失败的探索留在支路里当经验。 9.6 一个极短的例子（小白也能跟着走） 你想把输出格式从“自由叙述”改成“固定模板”，又怕改坏：
/tree 确认当前节点
/fork 分支试改模板
让 agent 跑一轮输出
/status 看差异是否符合预期
/commit 记下“模板化输出”这一刀
/merge 把有效版本回到主线 这套流程背后只有一句很随笔、但很实用的经验： 树负责定位，分叉负责试错，提交负责记忆，合并负责把可靠的东西带回主线。
把系统变成水：分流、蓄势、持续流动 回到李小龙那句被引用到发烂的 “Be water”，它真正的含义不是“随便”，而是：不执着形态，但永远遵守现实；不迷信套路，但永远保留改线能力。 把这句话放回 pi-mono，会发现“水性”并不只存在于 bash。它贯穿了整个系统的骨架。 10.1 Loop：持续流动（反馈驱动，而不是计划驱动） 水不会提前写一份路线图，它靠地形和阻力不断修正轨迹。pi-mono 的 agent loop 也是如此：每一轮都是“出手—反馈—再出手”。 工具结果是地形 用户插话是突发阻力 下一步动作由当下证据决定 这就是“流动”：不是一次性计划，而是连续校正。 10.2 Bash：触地形（把推理交给现实验证） 水之所以聪明，是因为它真实地接触地形。bash 的意义也在这里：把“脑内推演”换成“现实验证”。 命令能不能跑？跑出来是什么？ 测试过不过？日志怎么说？ 当系统愿意去触碰现实，很多不确定性就不必被“流程穷尽”，而是被事实裁决。 10.3 Tree：分流与回流（允许走错，关键是能回到分叉处） 线性对话像一条河道：越往下游走，越难回头。会话树更像水系：遇到障碍就分流；发现支流不对，就回到上游分叉点改道。 树的价值不在“有很多路径”，而在： 错了可以回流 改线不会污染主干 每一次探索都能成为可复用的支流 10.4 Compaction：浓缩与蓄势（体积可变，但方向不丢） 水蒸发成云，看似消失，实际上变成更轻的形态继续移动。compaction 也类似：它不是“遗忘”，更像“浓缩”。 细节会被压掉（代价真实存在） 但方向与势能被保留下来（Goal-first、Progress、Next Steps） 这里最关键的是 Goal-first：目标被放在摘要的第一块，像水永远遵循重力一样，保证“流动”不会变成“乱跑”。 你可以把它理解成一种水的纪律： 水可以随容器变形，但它不会违背重力 pi-mono 可以随局势改线，但它不会丢掉 Goal 摘要把庞杂历史变成路标，让系统在长任务里不被历史重量拖死。 10.5 一句话收束：树负责分流，摘要负责蓄势 树解决“路线的不确定性”，摘要解决“规模的不可承受性”。 树让你敢于探索：错了能回到分叉处 摘要让你能走很远：历史不会无限膨胀 两者一起，再加上 loop 的持续校正、bash 的现实验证，pi-mono 才真正具备了“水”的特性：能走远、能改线、能绕路、也能在关键时刻冲过去。 真正的强，不是把世界写成一套流程，而是在不确定的世界里保留流动、分流、蓄势的能力。