【转载】三省六部幻觉：为什么“虚拟公司”式多 Agent 架构在工程上不成立
【转载】三省六部幻觉：为什么“虚拟公司”式多 Agent 架构在工程上不成立
说明：这篇文章整理自一篇我认为很有价值的外部帖子。因为不少读者访问不了 X，我把它转成了适合博客阅读的版本，方便存档和传播。文中观点保留原意，表达和排版做了适度整理。
一个在 AI 社区广泛流传的架构思路，正在让大量团队走弯路。
先说结论
如果你正在考虑把多个 AI Agent 分别命名为“产品经理”“架构师”“测试工程师”，让它们像公司部门一样传递文档、协作完成任务——请先停一下。
这个模式看起来很直觉，逻辑上似乎也很合理，但它在工程上存在根本性的缺陷。更重要的是，Anthropic、OpenAI、Google 在构建自己的 Agent 系统时，没有一家真正采用这种模式。
这不是巧合。
什么是“三省六部”式架构
这里的“三省六部”，指的是一类在社区里很流行的多 Agent 设计方式。它在不同框架和文章里有不同名字，比如：
- role-based agents
- virtual team
- CrewAI 式分工
- MetaGPT 式组织
本文把这类方案统称为“三省六部”。
它的核心模式是：把一个复杂任务拆解成若干职能，让每个 Agent 扮演一个角色：
- PM 负责需求
- Tech Lead 负责架构
- Dev 负责实现
- QA 负责测试
任务在这些 Agent 之间流转，像一条流水线。
这个模式在图示上非常好看。它满足了人类对“分工协作”的直觉，也让“AI 团队”这个概念显得很具象、很容易解释。很多人第一次接触多 Agent 时，几乎都会自然想到这一套。
但问题在于：它解决的是人类的瓶颈，不是 AI 的瓶颈。
为什么这个类比从根本上是错的
人类需要分工，通常是因为：
- 单个人的注意力有限，无法同时处理所有信息；
- 人有专业壁垒，学习和切换成本高；
- 人与人之间需要接口和组织结构来协调。
但 LLM 的特性并不是这样。
同一个模型，既能写 PRD，也能写代码，没有天然的“职业边界”。模型的瓶颈也不是“注意力广度”，而更像是推理深度、上下文质量，以及信息是否完整。更关键的是，不同 Agent 之间也没有人类团队那种“文化”“默契”或者长期协作关系，可以用来补偿信息传递中的损耗。
所以，当你给 Agent 贴上“产品经理”“测试工程师”之类的标签时，并不会真的让它更专业，反而很可能把它限制住。
比如，一个被框死在“测试工程师”角色里的 Agent，看到架构层的问题，可能会直接跳过，因为“这不在我的职责范围内”。但现实里，最有价值的推理往往恰恰发生在边界上。很多关键问题，本来就不是某一个单独角色能完全看清的。
也就是说，角色扮演制造了假边界。
这是第一个问题。
第二个问题：信息在流转中死亡
在“三省六部”模式里，典型过程是：
- Agent A 产出一个文档；
- 把文档传给 Agent B；
- B 基于这份文档继续往下做。
但这个过程传递的，通常只是结论，不是完整的推理过程。
B 拿到文档后，需要重新理解、重新建立上下文。原始意图在衰减，隐含假设在丢失，每一次传递都在累积误差。工作流越长，最后的输出就越容易变成一种“局部正确但整体漂移”的状态：
- 每个节点看起来都合理；
- 但整个结果已经偏离了最初目标。
人类组织之所以还能勉强运转，是因为有很多补偿机制：会议、文化、口头同步、非正式沟通、跨团队经验等等。Agent 之间没有这些东西。
一个常见反驳：那 progress.txt、spec 文件不也是“传文件”吗？
表面上看，三家厂商常用的 progress.txt、spec、runbook 也在“写文件”和“读文件”，好像没什么本质区别。
但真正关键的差别在于：谁在写、写给谁、怎么更新。
“三省六部”的信息流转，本质上是角色之间的单向交接：
- A 写完交给 B；
- B 往往不再回头；
- A 也不知道 B 怎么使用这份文档。
信息被压缩成结论，交接就是断点。
而外部状态文件的逻辑是：同一个任务执行主体，在不同 checkpoint 上持续往同一份记录里追加。
也就是说：
- 下一个 session 读取的是任务的完整历史；
- 不是某个“同事”交来的输出结论；
- 写状态的人和读状态的人，本质上是同一个角色，只是处在不同时间点。
信息不是被“压缩传递”的，而是被“连续积累”的。
这个区别，决定了推理链能不能跨 session 保持连续。
在“三省六部”模式下，大量 token 被浪费在 Agent 之间的“交接文件”上，而不是用于真正的推理。你最终得到的是一个模拟公司行为的系统，而不是一个真正解决问题的系统。
三家厂商实际是怎么做的
真正值得注意的是：当 Anthropic、OpenAI、Google 构建自己的生产级 Agent 系统时，它们的工程文档里几乎看不到“角色扮演”或“部门分工”这种思路。
Anthropic：Context Engineering + 显式状态文件
Anthropic 在内部把“Prompt Engineering”升级成了“Context Engineering”。重点不再是“怎么写一个漂亮 prompt”，而是：应该如何配置 token、状态和上下文，才能最稳定地产生想要的行为。
在构建 Claude Code 和 Research 系统时，他们面对的核心挑战是：Agent 必须在离散的 session 中工作，而每个新 session 对之前发生的事没有天然记忆。
他们用了一个很形象的比喻：这就像“轮班工程师”。每个新班次的工程师到岗时，对上一班做了什么一无所知。
Anthropic 的解法不是让 Agent 扮演不同角色，而是引入显式的外部状态：
claude-progress.txt：作为跨 session 的工作日志；- Git history：作为状态锚点，记录每一个增量变化；
- Initializer Agent：只在第一个 session 运行，用于建立环境、展开 feature list、写好 runbook，供后续所有 session 使用。
它的关键洞察是：推理链的连续性，不靠模型“记住”，而靠显式外部状态来锚定。
他们还发现，把“模型能力假设”硬编码进 harness 其实是很危险的。
例如，Sonnet 4.5 一度表现出所谓的 “context anxiety”：当接近 context limit 时，会倾向于提前收尾。于是工程层加了 context reset。但到了 Opus 4.5，这种行为又消失了，于是之前的 reset 机制反而成了累赘。
这说明一件事：harness 必须随着模型演化而演化。 所谓“永久正确的工程套路”，很多时候只是某个阶段的临时妥协。
在多 Agent 的 Research 系统里，Anthropic 实际采用的是 orchestrator-worker 架构：
- 一个 lead agent 负责分解任务和协调；
- 多个 subagent 并行探索不同方向；
- 结果再统一回流给 lead agent 综合判断。
他们后来发现，token 消耗量本身就能解释 80% 的性能差异。换句话说，多 Agent 的价值并不来自“角色分工”，而是来自：你用更多 token 覆盖了更大的搜索空间。
这里很容易和“三省六部”混淆，因为看起来也像“有不同 Agent 在协作”。但两者本质完全不同。
“三省六部”是职能性分工：
- PM 做完传给 Dev；
- Dev 做完传给 QA；
- 每个角色只处理流水线的一段。
Anthropic 的 subagent 则是功能性并行：
- 多个 agent 同时搜索不同方向；
- 没有“下一棒”；
- 所有结果都回到同一个 orchestrator 汇总。
前者像接力赛，后者更像同时撒网捞鱼。
OpenAI：Compaction + Skills + 结构化 Spec 文件
OpenAI 对长任务的原则更直接：在任务开始时就要为 continuity 做规划。
在 Codex 的实验里，工程师会先给 agent 一个 spec 文件，用来冻结目标，防止 agent“做出了很 impressive 的东西，但方向完全错了”。然后再让它生成基于里程碑的 plan，并用 runbook 指定实际操作方式。
这个 runbook 同时承担两个角色：
- 共享记忆；
- 审计日志。
结果是，GPT-5.3-Codex 可以连续运行约 25 小时，完成一个完整设计工具的实现，并保持全程连贯。
OpenAI 还把 server-side compaction 当作默认 primitive，而不是紧急 fallback。在多步骤任务里，通过 previous_response_id，模型可以在同一个 thread 里持续工作，而不是每次都从头重建上下文。
另一个值得注意的点是 Skills。
OpenAI 的 Skills 指的是：
- 可复用的、版本化的指令集；
- 可以挂载到 container；
- 让 agent 执行某类任务时有稳定的操作规范。
这不是“角色”。
它更像工具、操作规程和流程沉淀，而不是“你现在扮演测试工程师”。这是非常本质的差别。
Google：1M 上下文 + Context-driven Development
Google 的方向很明确：先硬扩 context window。
Gemini 的 1M token context，本身就是一种非常明确的差异化策略。它的逻辑是：很多过去不得不用的技术，比如 RAG 切片、丢弃旧消息、不断压缩对话，在足够大的窗口下，可以被“直接全放进去”替代。
但 Google 自己也承认，这仍然不够。
于是他们在 Gemini CLI 上推出了 Conductor 扩展，核心思路和 Anthropic 非常接近：把项目意图从聊天窗口里移出来，放到代码库中的持久化 Markdown 文件里。
它背后的哲学是：
不依赖不稳定的聊天记录，而依赖正式的 spec 和 plan 文件。
Gemini 3 还引入了 Thought Signatures，用来保存长 session 中推理链的关键节点，尽量减少 long context 下的 reasoning drift——也就是逻辑前后不一致、逐步跑偏的问题。
真正的架构原则是什么
如果把三家的工程实践放在一起看，可以提炼出几个非常一致的原则。
1. 推理链不能断，只能分叉再合并
多 Agent 的正确用法，不是把任务做成流水线，而是：
- 主 Agent 始终持有完整意图；
- 子调用只负责深挖某个子问题；
- 结果必须回流给主 Agent；
- 而不是再传给“下一个部门”。
也就是说，允许分叉，但最终必须合并。
2. 显式外部状态，不靠模型“记住”
progress.txt、Git history、spec 文件、数据库……形式并不重要。
真正重要的原则是：推理链的关键节点必须外化到持久存储里，而不能指望模型在 context window 里一直“记得”。
3. 多 Agent 的价值是并行覆盖，不是分工
Anthropic Research 系统给出的结论已经很清楚：性能提升主要来自“花了更多 token”，而不是“角色分工更合理”。
所以，多 Agent 更适合 breadth-first 型任务，也就是：
- 需要同时探索多个独立方向；
- 需要扩大搜索空间；
- 需要并行试错。
它并不适合那些需要连续推理、深度依赖上下文、且必须长时间保持意图一致的场景。
4. 验证 Agent 应该是否定者，而不是接棒者
如果你想用多 Agent 做质量控制，更合理的方式是：
- 让一个 Agent 专门去找另一个 Agent 的问题；
- 做对抗性检验；
- 做交叉审查。
而不是让它们按部门顺序传递工作成果。
也就是说，验证型 Agent 的价值在于挑错，而不是接棒。
5. 工具是工具，不是角色
给 Agent 配什么工具——比如 bash、文件读写、搜索、代码执行——远比给它贴什么标签重要。工具决定了 Agent 能做什么；角色标签更多只是在限制它“愿意做什么”。
“技能包”“操作规范”“工作流模板”“结构化 spec”这些东西，都是工具层能力。
它们的作用是：
- 提高执行稳定性；
- 让任务可以复用；
- 让模型在关键步骤上不跑偏。
这和“你现在是一个 QA，请只做 QA 的工作”完全不是一回事。
把工具误当成角色，把流程误当成组织，本质上是在用人类公司的外观，掩盖系统设计中的真正问题。
那“三省六部”为什么会流行？
一个重要原因是：它太好解释了。
“这个 Agent 是 PM，那个是 QA。”——这句话几乎任何人都能理解。它满足了人类对 AI 系统可解释性的渴望，也满足了管理层对“AI 像团队一样工作”的想象。
它也很好展示。流程图一画：
- 有部门；
- 有箭头；
- 有交接；
- 看起来非常直观。
但“好解释”和“好展示”，跟工程上是否成立，是两回事。
更深一层的原因是：很多采用这个模式的团队，其实还没有真正撞上“上下文在多 Agent 之间传递时的损耗”这个墙。可能是任务还不够复杂，可能是问题暂时被其他因素掩盖了。
但一旦任务复杂度上来，系统开始出现那种很诡异的状态——局部都对，整体却错——这个问题就会非常明显地暴露出来。
实践建议
最好的多 Agent 系统，并不像一家公司。它更像一个思考者的多次草稿：同一个大脑，在不同维度上展开推理，最后再合并成一个连贯的结论。
从这个原则出发，我觉得至少有几条建议值得记住。
1. 不要先问“我需要几个 Agent”
更应该先问的是：这个任务的信息依赖结构是什么？
如果任务本身需要连续推理、上下文高度依赖，比如写一个复杂功能的设计文档、做一轮完整的架构权衡，那么通常：
- 单 Agent
- 配合好的 context engineering
会优于多 Agent 流水线。
2. 并行探索适合独立问题，不适合强依赖问题
如果任务需要同时探索多个相对独立的方向，比如：
- 同时研究 10 个竞品的不同模块；
- 同时比较多个技术方案；
- 同时做多路资料检索；
那么多 Agent 并行是合理的。
因为此时各个 subagent 之间任务相对独立，信息损耗代价最小。
这也是为什么在 Anthropic Research 系统里，token 量能解释 80% 性能差异：不是“分工”让系统更强，而是“更大的搜索覆盖”让系统更强。
3. 跨 session 任务必须有外部状态文件
如果任务天然跨越多个 session，那么外部状态文件基本是必需品。
一份有效的状态文件，至少应该包含四类信息：
任务目标
相对不变，session 开始时优先读取，用来防止漂移。已完成的步骤
采用追加方式，不覆盖，保留完整历史。当前状态
允许覆盖，反映最新进展。已知的坑
采用追加方式，避免下一个 session 重复踩坑。
这四类信息分开维护，合在一起，才构成“下一个自己”真正需要的完整上下文。
4. 如果加验证环节，就让验证 Agent 专门挑错
如果你要引入额外 Agent 做质量控制，那么更合理的设计不是让它“接着做下去”，而是让它的唯一任务就是：找问题。
也就是说：
- 做对抗性检验；
- 做交叉审查；
- 做否定性检查。
而不是把它放进流水线里接下一棒。
5. 保持架构可演化，比追求“完美架构”更重要
模型能力还在快速变化。今天 harness 里必不可少的 workaround，六个月后很可能就成了死重量。
Anthropic 已经验证了这一点：Sonnet 4.5 的 context anxiety 在 Opus 4.5 里消失后，原本为它设计的 context reset 很快就从“必要机制”变成了“无用代码”。
所以真正重要的，不是拍脑袋选一个“听起来最完整”的架构，而是让系统能随着模型能力迭代而持续调整。
总结
“三省六部”式多 Agent 架构之所以迷人，是因为它太符合人类对组织协作的直觉了。画出来像公司，讲起来像团队，听上去仿佛很专业。
但工程上真正重要的问题不是“像不像公司”，而是：
- 推理链有没有连续；
- 上下文有没有丢失；
- 状态有没有外化；
- 搜索空间有没有被有效扩展；
- 最终意图有没有被主导者持续掌握。
从 Anthropic、OpenAI、Google 的实践来看，真正有效的多 Agent 系统，核心并不是“让 AI 扮演不同岗位”，而是：
- 用主从结构保持意图统一；
- 用外部状态保持连续性；
- 用并行探索提升覆盖率；
- 用验证机制做对抗性纠错。
换句话说，多 Agent 不是在模拟一家虚拟公司，而是在构建一个能持续推理、持续校准、持续积累状态的系统。
这两者，差得非常远。
更麻烦的是，“三省六部”的真正成本并不总是直接失败，而是让系统在复杂度上升时，以一种很难诊断的方式退化：
- 每个节点都“看起来在工作”；
- 但整体却在持续漂移。
等你真正发现问题的时候，流水线往往已经很长了。
参考来源
- Anthropic Engineering Blog：Building Effective Agents、Effective Context Engineering、Multi-Agent Research System、Effective Harnesses for Long-Running Agents、Managed Agents
- OpenAI Developers Blog：Run Long Horizon Tasks with Codex、Shell + Skills + Compaction
- Google Developers Blog：Architecting Efficient Context-Aware Multi-Agent Framework、Conductor: Context-Driven Development for Gemini CLI
