第 10 章三层模型的反思

第 9 章讲完了五要素怎么实现，这一章我们退后一步，回头看这套架构——它改变了什么，代价是什么，什么时候不该用。

最大的变化：人的角色变了

第 9 章那张三层架构图里，最容易引起误解的是"人"这一层。

很多人看到三层模型，第一反应是"哦，就是加了个 Agent 层帮我干活"。没错，但更重要的是——人的角色变了。

在传统的 Agent 使用方式里，人是指挥官。你给 Agent 下指令，Agent 执行，你检查结果，再下下一条指令。每一轮交互都是人发起的。你是发动机，Agent 是轮子。

引入双 Agent 协作之后，人不再是发动机了。PM Agent 承担了大部分指挥工作，人退到了两个非常具体的场景里：

第一个场景：审批越界操作。 开发 Agent 想执行工作区之外的文件操作，或者想跑 Bash 命令，这个请求会推送到群聊。人看一眼，点"允许"或"拒绝"。几秒钟的事。

第二个场景：重试失败后兜底。 开发 Agent 做的东西连续两次没过验证，说明这不是偶发失误而是系统性问题。这时候人需要判断——是任务描述不清楚？是开发 Agent 能力不够？还是需求本身有问题？

就这两个场景。其他时候，人不需要在场。

这个变化听起来很舒服——"我不用管了，Agent 自己干"。但它有一个容易忽略的含义：人从"执行者"变成了"守门员"。 守门员大部分时间是闲着的，但他在场上的价值不是"频繁动作"，而是"关键时刻的判断"。你判断得好不好，直接决定了系统安全不安全。

PM Agent：项目经理，不是传话筒

PM Agent 在三层模型里是最忙的。如果理解成"把用户的话转达给开发 Agent"，那就大错特错了。

PM Agent 干的事远比传话复杂：

理解需求。 用户在群里说的话是零散的、口语化的、不完整的。"帮我做个周末出游的网页"——做什么样的？给谁看？包含哪些信息？PM Agent 要从群聊上下文里提取这些信息，补全不完整的部分，组织成结构化需求。

拆任务。 需求理解清楚后，它要判断：信息够不够做？不够的话先追问用户还是先整理已有信息？什么时候该调开发 Agent？

验收产出。 第 9 章的双层验证，验证的执行是引擎干的，但"根据验证结果做决策"是 PM Agent 的职责。通过就通知用户，没过就触发重试，重试用完就判断要不要求助人。

维护上下文。 这是最容易被忽略但最重要的。开发 Agent 每次被调时是"失忆"的，靠 plan.md 恢复。PM Agent 才是那个"记得来龙去脉"的角色——它维护着项目的完整状态。

贯穿这些职责的有一条原则：PM Agent 有能力边界意识。 它知道什么自己做、什么交给开发 Agent、什么求助人。这种"知道自己不知道什么"的意识，是它能当好"经理"的前提。

开发 Agent：三条规矩

开发 Agent 的定位最简单，但有三条规矩必须守住：

第一，不参与对话。 用户不知道它的存在。用户只跟 PM Agent 交互。用户说"做个网页"，是 PM Agent 收到的；PM Agent 在背后调开发 Agent，用户看到的只是"我去处理了"和"做好了"。

第二，不理解全局。 它收到的只有一个文件路径和一句任务描述。它去读文件、干活、交文件。它不需要知道"用户为什么要这个""上次哪里没做好"——这些是 PM Agent 管的。

第三，产出不直接给用户。 它的产出要过 PM Agent 的验证关，验证通过了才通知用户。用户永远不直接面对开发 Agent 的原始产出。

这三条确保了一件事：开发 Agent 的任何失误，都不会直接传导给用户。 失误会被验证层拦住，或被人的审批拦住。

这套架构的代价

讲了这么多"怎么协作"，必须诚实地说代价。三层模型不是免费的午餐。

延迟。 双 Agent 协作天然比单 Agent 慢。PM Agent 理解需求 + 写 plan + 启动开发 Agent + 执行 + 验证 + 回调通知——整条链路下来，一个任务要两三分钟。如果用户期望"秒回"，这套架构就不合适。

复杂度。 五要素的每一个都是工程量。异步回调、文件交接、双层验证、自动重试、权限控制——开发完不算结束，维护它们才是成本。验证逻辑要不要调？重试策略要不要改？权限边界要不要收紧？这些都是持续要做的决策。

不可靠性叠加。 PM Agent 是概率性的，开发 Agent 是概率性的，LLM 裁判也是概率性的。三个概率性系统串联，整体可靠性是乘法关系——假设每个 90%，三个串联就是 73%。大约每四次协作就有一次出问题，需要人介入。

所以三层模型不是"更高级的架构"，而是"特定场景下的妥协"。 只有当任务确实需要两种能力、单 Agent 做不了、且延迟和复杂度可以接受时，才值得用。如果你的场景不满足这些条件，单 Agent 加好工具永远更简单、更可靠、更快。

还没做完的事

最后诚实交代一下，这套架构在我手里也不是完整的。有几个地方我知道有问题但还没解决：

plan.md 的恢复机制没有完全闭环。 合成触发里告诉 Agent "请读取 plan.md 恢复上下文"，但这是约定不是强制。偶尔会出现 Agent 的回复"看似还要继续做什么"，但系统其实已经不会有后续动作了——上下文断了，Agent 自己不知道。我后来在对话日志里抱怨过这件事，说"很割裂"。这个问题还在。

brief 没有 Schema 契约。 plan.md 现在是自由格式的 Markdown，没有做结构化的 Schema 校验。理论上 Agent 和 CC 之间应该用 Schema 约束交接格式，防止漂移。但实际操作中，自由 Markdown 的灵活性反而更好——这个改进的优先级一直排不上。

容器沙箱还没做。 现在的权限控制是"工作区内自由 + 越界审批"，但工作区本身不是隔离的容器。更彻底的方案是给每个项目一个独立容器，CC 只能在容器里操作。这个我知道该做，但工程量大，还没排上。

写这些不是为了找借口，而是想说明——"双 Agent 协作"不是一锤子买卖。 搭好五要素只是开始，持续维护、发现问题、迭代改进，才是真正的工程。

这一章的工具：三层协作自查

🔧 三层协作自查清单

如果你在构建人-Agent-Agent 的三层协作，检查以下几点：

人的角色

[ ] 人需要介入的节点定义清楚了吗？（审批什么？兜底什么？）
[ ] 人的介入频率合理吗？（太高说明自动化不够，太低说明可能漏掉关键风险）
[ ] 人不在的时候，系统能安全运行吗？（还是每一步都需要人盯着？）

PM Agent

[ ] PM Agent 有"能力边界意识"吗？（知道什么自己做、什么交给开发 Agent、什么求助人）
[ ] PM Agent 维护着项目的完整状态吗？（还是上下文经常丢失？）
[ ] PM Agent 的产出验证是否可靠？（还是烂产出会直接到用户手里？）

开发 Agent

[ ] 开发 Agent 是否对用户透明？（用户不应该直接面对它的原始产出）
[ ] 开发 Agent 的上下文是否解耦？（靠文件交接，不靠共享上下文）
[ ] 开发 Agent 的权限是否受控？（边界内自由，越界审批）

整体

[ ] 你评估过延迟吗？（协作链路的时间成本可以接受吗？）
[ ] 你算过可靠性吗？（多个概率性系统串联，整体可靠性够吗？）
[ ] 你有退出策略吗？（如果三层协作太重，能不能退回单 Agent？）

小结

三层模型的核心变化是：人从指挥官变成了守门员，PM Agent 成了项目经理，开发 Agent 是被管理的高级工具。

但这个变化是有代价的——延迟、复杂度、不可靠性叠加。三层模型是特定场景下的工程妥协，不是"更高级"的架构。而且就算搭好了，它也需要持续维护——我自己的实现里还有几个没解决的问题。

到这一章为止，第四部分"怎么让多个 Agent 协作"就讲完了。第 8 章判断要不要拆，第 9 章给全景图再逐个展开五要素，第 10 章退后一步反思角色和代价。

下一部分，也是这份手记的最后一部分，我们回到更基础的工程问题——怎么把 Agent 做稳，怎么让它达到企业级的质量标准。

第 11 章 · 被忽略的鲁棒性 —— 做功能的时候，别忘了超时、重试、熔断这些基本卫生。