三省六部幻觉：为什么"虚拟公司"式多 Agent 架构在工程上不成立

一个在 AI 社区广泛流传的架构思路，正在让大量团队走弯路。

先说结论

如果你正在考虑把多个 AI Agent 分别命名为"产品经理"、"架构师"、"测试工程师"，让它们像公司部门一样传递文档、协作完成任务——请停下来。

这个模式看起来很直觉，逻辑上似乎很合理，但它在工程上有根本性的缺陷。更重要的是，Anthropic、OpenAI、Google 三家厂商在构建自己的 Agent 系统时，没有一家采用这个模式。

这不是巧合。

什么是"三省六部"式架构

这个比喻指的是一类在社区里广泛流行的多 Agent 设计思路，在不同框架和文章里有不同名字：role-based agents、virtual team、CrewAI 式分工、MetaGPT 式组织——本文统称"三省六部"。

核心模式是：把一个复杂任务拆解成若干职能，每个 Agent 扮演一个角色——PM 负责需求、Tech Lead 负责架构、Dev 负责实现、QA 负责测试。任务在 Agent 之间流转，像一条流水线。

这个模式在图示上非常好看。它满足了人类对"分工协作"的直觉，也让"AI 团队"这个概念变得具象可解释。CrewAI 等框架正是因此积累了大量用户。

问题在于，它解决的是人类的瓶颈，不是 AI 的瓶颈。

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

人类需要分工，是因为：

• 单个人的注意力有限，无法同时处理所有信息
• 人有专业壁垒，学习切换成本高
• 人与人之间需要接口来协调

但 LLM 的特性完全不同：

• 同一个模型既能写 PRD 又能写代码，没有"职业边界"
• 模型的瓶颈不是注意力广度，而是推理深度和信息完整性
• 模型之间没有"文化"和"默契"来补偿信息损耗

给 Agent 贴上"产品经理"的标签，不会让它更专业——但会让它拒绝越界。一个被框死在"测试工程师"角色里的 Agent，看到架构层的问题可能直接跳过，因为"不在我职责范围内"。最有价值的推理往往发生在边界上，而三省六部模式在系统层面封死了这个可能性。

角色扮演制造了假边界。这是第一个问题。

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

三省六部模式里，Agent A 产出一个文档，传给 Agent B。

这个过程传递的是结论，不是推理过程。

B 拿到文档，重新理解，重新建立上下文。原始意图在衰减，隐含假设在丢失，每次传递都在累积误差。工作流越长，最终输出越"局部正确但整体漂移"——每个节点看起来合理，但整体已经偏离了最初的目标。

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

这里有一个常见的反驳：三家厂商的解法（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 对之前发生的事情没有任何记忆。他们的比喻是"轮班工程师"——每个新班次的工程师到岗时对上一班的工作一无所知。

解法不是让 Agent 扮演不同角色，而是：

• claude-progress.txt：一个跨 session 的工作日志，Agent 在每个 session 结束时更新，下一个 session 开始时读取
• Git history：作为状态锚点，记录每一个增量变化
• Initializer Agent：只在第一个 session 运行，建立环境、展开 feature list、写好 runbook，供后续所有 session 使用

关键洞察：推理链的连续性不靠模型"记住"，靠显式的外部状态来锚定。

他们同时发现，把"model 能力假设"硬编码进 harness 是危险的。Sonnet 4.5 有"context anxiety"——快到 context limit 时会提前收尾，于是 harness 里加了 context reset。但 Opus 4.5 这个行为消失了，reset 变成了死重量。这说明：harness 需要随模型迭代而演化，任何"永久解法"都只是当前阶段的工程妥协。

在多 Agent 的 Research 系统里，Anthropic 的架构是 orchestrator-worker：一个 lead agent 分解任务、协调 subagent，subagent 并行探索不同方向，结果回流给 lead agent 综合。他们发现 token 消耗量本身就解释了 80% 的性能差异——多 Agent 的价值不是"分工"，而是用更多 token 覆盖更大的搜索空间。

这里有一个容易混淆的地方：Anthropic 的 subagent 看起来也像"分工"，但本质完全不同。三省六部是职能性分工——不同角色承担不同工种，PM 做完传给 Dev，Dev 做完传给 QA，每个角色只处理流水线的一段。Anthropic 的 subagent 是功能性并行——多个相同性质的 agent 同时搜索不同方向，没有"下一棒"，结果全部汇聚回同一个 orchestrator 综合。前者是接力赛，后者是同时撒网捞鱼。

OpenAI：Compaction + Skills + 结构化 Spec 文件

OpenAI 给出的长任务原则更直接：在任务开始时就为 continuity 做规划。

他们的 Codex 实验里，工程师给 agent 一个 spec 文件（冻结目标，防止 agent"做出了很 impressive 但方向错误的东西"），让它生成 milestone-based plan，然后用一个 runbook 文件告诉 agent 如何操作。这个 runbook 同时也是共享记忆和审计日志。

结果：GPT-5.3-Codex 跑了约 25 小时不间断，完成了一个完整的设计工具，保持了全程的连贯性。

Server-side compaction 作为默认 primitive，不是紧急 fallback。多步骤任务里，previous_response_id 让 model 能在同一个 thread 里继续工作，而不是每次重建上下文。

他们还引入了 Skills 概念——可复用的、版本化的指令集，挂载进 container，让 agent 执行特定任务时有稳定的操作规范。这不是"角色"，是工具和操作规程，是本质上不同的东西。

Google：1M 上下文 + Context-driven Development

Google 的方向是硬扩窗口：Gemini 的 1M token context 是明确的差异化策略。他们的逻辑是：之前被迫使用的 RAG 切片、丢弃旧消息等技术，在足够大的窗口下可以被"直接放进去"所取代。

但他们自己也承认这不够用。Google 在 Gemini CLI 推出了 Conductor 扩展，核心思路和 Anthropic 如出一辙：把项目意图从聊天窗口里移出来，放进代码库里的持久化 Markdown 文件。哲学是："不依赖不稳定的聊天记录，依赖正式的 spec 和 plan 文件。"

Gemini 3 还引入了 Thought Signatures 机制：在长 session 里保存推理链的关键节点，防止"reasoning drift"——长 context 里逻辑前后不一致的问题。

真正的架构原则是什么

从三家的工程实践中，可以提炼出几个共同的原则：

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

显式外部状态，不靠模型记住。 progress.txt、git history、spec 文件、数据库——形式不重要，原则是：推理链的关键节点必须外化到持久存储里，而不依赖模型在 context window 里"记住"。

多 Agent 的价值是并行覆盖，不是分工。 Anthropic Research 系统的结论很清楚：性能提升主要来自于"花了更多 token"，而不是来自"分工更合理"。多 Agent 适合 breadth-first 类任务——需要同时探索多个独立方向的场景。不适合需要连续推理、深度依赖上下文的场景。

验证 Agent 是否定者，不是接棒者。 如果要用多 Agent 做质量控制，正确的设计是让一个 Agent 专门找另一个 Agent 的问题，而不是"传递工作成果"。对抗性检验，不是流水线传递。

工具是工具，不是角色。 给 Agent 配什么工具（bash、文件读写、搜索、代码执行）远比给它贴什么标签重要。工具决定了 Agent 能做什么；角色标签只是约束它愿意做什么。

那三省六部为什么会流行？

因为它好解释。

"这个 Agent 是 PM，那个是 QA"——这句话任何人都能理解。它满足了人类对 AI 系统可解释性的渴望，也满足了管理层对"AI 像团队一样工作"的想象。

它还好展示。用流程图画出来，有部门、有箭头、有交接，非常直观。

但好解释和好展示，和工程上是否成立是两件事。

更深层的原因是：大多数采用这个模式的团队，并没有真正面对过"上下文在多 Agent 间传递时的损耗"这个问题。他们的任务可能不够复杂，或者问题被其他因素掩盖了。等到任务复杂度上来，系统开始出现诡异的"局部正确整体错误"时，问题才会暴露。

实践建议

最好的多 Agent 系统，不像公司。它更像一个思考者的多次草稿——同一个大脑，在不同维度上展开推理，最终合并成一个连贯的结论。

从这个原则出发：

不要问"我需要几个 Agent"，要问"这个任务的信息依赖结构是什么"。

如果任务需要连续推理、上下文高度依赖（比如写一个复杂功能的设计文档），单 Agent + 好的 context engineering 通常优于多 Agent。

如果任务需要同时探索多个独立方向（比如同时研究 10 个竞品的不同模块），多 Agent 并行是合理的——每个 subagent 的任务相互独立，信息损耗代价最小。这正是 Anthropic Research 系统 token 量解释 80% 性能差异背后的原因：不是分工让它更好，是更大的搜索覆盖让它更好。

如果任务跨越多个 session，外部状态文件是必须的。一份有效的状态文件应该包含四类信息：

• 任务目标（不变，session 开始时读取，防止漂移）
• 已完成的步骤（追加，不覆盖，保留完整历史）
• 当前状态（覆盖，反映最新进展）
• 已知的坑（追加，避免下一个 session 重复踩）

这四类信息分开维护，合在一起就是"下一个自己"需要的完整上下文。

如果要加验证环节，让验证 Agent 的唯一任务是找问题，不是"接棒继续做"。对抗性检验，不是流水线传递。

最后：模型能力在快速提升，今天 harness 里需要的 workaround，六个月后可能变成死重量。Anthropic 已经验证了这一点——Sonnet 4.5 的 context anxiety 在 Opus 4.5 里消失了，为它设计的 context reset 随即变成了无用代码。保持架构的可演化性，比选一个"完美架构"更重要。

三省六部是一个让人感觉良好但工程上代价高昂的错觉。它的真正成本不是直接的失败，而是让你的系统在复杂度上升时，以一种难以诊断的方式退化——每个节点都"看起来在工作"，但整体在漂移。

等你发现问题的时候，流水线已经很长了。

文章来自于"Tech Information快递猿"，作者 "Tech Information快递猿"。