「三省六部」式架构正在让大量团队走弯路。

什么是「三省六部」

在 AI 社区广泛流传的一种多 Agent 设计思路：把 Agent 分别命名为「产品经理」「架构师」「测试工程师」，任务像流水线一样在 Agent 之间传递文档、协作完成。CrewAI、MetaGPT 都采用这个模式，图示上非常好看。

但问题是：它解决的是人类的瓶颈，不是 AI 的瓶颈。

为什么这个类比根本上是错的

第一个问题：角色标签制造假边界

人类需要分工，是因为单个人注意力有限、有专业壁垒。但 LLM 完全不同：

  • 同一模型既能写 PRD 又能写代码，没有「职业边界」
  • 瓶颈不是注意力广度，而是推理深度和信息完整性
  • 给 Agent 贴上「测试工程师」标签，不会让它更专业——只会让它拒绝越界

最有价值的推理往往发生在边界上。三省六部模式在系统层面封死了这个可能性。

第二个问题：信息在流转中死亡

Agent A 产出文档传给 Agent B，传递的是结论，不是推理过程。B 重新理解，重新建立上下文。原始意图衰减，隐含假设丢失，每次传递累积误差。

人类组织靠会议、文化、非正式沟通来补偿这个损耗。Agent 之间没有这些机制。

关键区别：三省六部的交接是「角色间单向」——A 写完交给 B，B 不再回头。外部状态文件是「同一任务增量」——执行主体在每个 checkpoint 往同一份记录里追加，下一个 session 读取的是完整历史。

三家厂商实际怎么做的

Anthropic：Context Engineering + 显式状态文件

核心隐喻：「轮班工程师」——每个新 session 对之前一无所知。

解法不是角色分工，而是：

  • claude-progress.txt：跨 session 工作日志
  • Git history 作为状态锚点
  • Initializer Agent：只在第一个 session 运行，建立环境和 runbook

关键洞察：Anthropic 的 subagent 是「功能性并行」，不是「职能性分工」。前者是同时撒网捞鱼，后者是接力赛。

Token 消耗量解释了 80% 的性能差异——多 Agent 的价值在于用更多 token 覆盖更大的搜索空间，不是分工更合理。

OpenAI：Compaction + Skills + Spec 文件

任务开始时规划 continuity，给 Agent spec 文件冻结目标，milestone-based plan 加 runbook 文件作为共享记忆。

Server-side compaction 是默认 primitive，不是紧急 fallback。Skills 是可复用的、版本化的指令集——是工具和操作规程，不是角色。

Google：1M 上下文 + Conductor 扩展

硬扩窗口，但自己也知道不够用。Conductor 扩展把项目意图从聊天窗口移到持久化 Markdown 文件。Thought Signatures 机制在长 session 里保存推理链关键节点。

真正的架构原则

推理链不能断，只能分叉再合并。 正确用法：主 agent 持有完整意图，子调用是为了深挖某个子问题，结果回流给主 agent，不是传给下一个 agent。

显式外部状态，不靠模型记住。 状态文件应该包含四类信息：任务目标（不变）、已完成步骤（追加）、当前状态（覆盖）、已知坑（追加）。

多 Agent 的价值是并行覆盖，不是分工。 适合 breadth-first 场景（同时探索多个独立方向）。不适合需要连续推理的场景。

验证 Agent 是对抗者，不是接棒者。 正确设计是让 Agent 专门找另一个 Agent 的问题，对抗性检验，不是流水线传递。

工具是工具，不是角色。 工具决定了 Agent 能做什么；角色标签只是约束它愿意做什么。

为什么三省六部还是流行的

因为它好解释、好展示。「这个 Agent 是 PM，那个是 QA」——任何人都能理解。

但好解释和工程上成立是两件事。大多数采用这个模式的团队，任务复杂度还没高到暴露这个问题。等到流水线足够长，系统开始「局部正确但整体漂移」时，诊断会非常困难。

实践建议：不要问「我需要几个 Agent」，要问「这个任务的信息依赖结构是什么」。