来源： Twitter/X 长文
作者： SagaSu (@sujingshen)
发布时间： 2026-04-14
数据： 302,577 阅读 | 317 转发 | 1,494 点赞 | 78 引用
核心观点
如果你正在考虑把多个AI Agent分别命名为"产品经理"、"架构师"、"测试工程师"，让它们像公司部门一样传递文档、协作完成任务——请停下来。
这个模式看起来很直觉，逻辑上似乎很合理，但它在工程上有根本性的缺陷。更重要的是，Anthropic、OpenAI、Google三家厂商在构建自己的Agent系统时，没有一家采用这个模式。 这不是巧合。
什么是"三省六部"式架构
这个比喻指的是一类在社区里广泛流行的多Agent设计思路：
- role-based agents — 基于角色的Agent
- virtual team — 虚拟团队
- CrewAI式分工 — CrewAI框架的分工模式
- MetaGPT式组织 — MetaGPT的组织方式
核心模式：
PM（产品经理）→ Tech Lead（架构师）→ Dev（开发者）→ QA（测试）
需求 架构设计 实现 测试
↓ ↓ ↓ ↓
文档 文档 文档 文档
这个模式在图示上非常好看，满足了人类对"分工协作"的直觉，也让"AI团队"这个概念变得具象可解释。
问题在于：它解决的是人类的瓶颈，不是AI的瓶颈。
问题一：角色扮演制造假边界
人类需要分工的原因：
- 单个人的注意力有限，无法同时处理所有信息
- 人有专业壁垒，学习切换成本高
- 人与人之间需要接口来协调
LLM的特性完全不同：
- 同一个模型既能写PRD又能写代码，没有"职业边界"
- 模型的瓶颈不是注意力广度，而是推理深度和信息完整性
- 模型之间没有"文化"和"默契"来补偿信息损耗
给Agent贴上"产品经理"的标签，不会让它更专业——但会让它拒绝越界。
一个被框死在"测试工程师"角色里的Agent，看到架构层的问题可能直接跳过，因为"不在我职责范围内"。最有价值的推理往往发生在边界上，而三省六部模式在系统层面封死了这个可能性。
问题二：信息在流转中死亡
三省六部模式的问题：
Agent A 产出一个文档 → 传给 Agent B
这个过程传递的是结论，不是推理过程。
B拿到文档后： 重新理解，重新建立上下文。原始意图在衰减，隐含假设在丢失，每次传递都在累积误差。工作流越长，最终输出越"局部正确但整体漂移"——每个节点看起来合理，但整体已经偏离了最初的目标。
人类组织靠什么补偿？ 会议、文化、非正式沟通。Agent之间没有这些机制。
关键区别：谁在写、写给谁、怎么更新
| 三省六部模式 | 外部状态文件 |
|---|---|
| 角色间的单向交接 | 同一任务的增量日志 |
| A写完交给B，B不再回头 | 执行主体在每个checkpoint往同一份记录里追加 |
| 信息被压缩成结论 | 信息是连续积累的 |
| 写的人和读的人不是同一个角色 | 写的人和读的人是同一个角色，只是时间不同 |
大量token被浪费在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使用
关键洞察：推理链的连续性不靠模型"记住"，靠显式的外部状态来锚定。
在多Agent的Research系统里，Anthropic的架构是orchestrator-worker：
- 一个lead agent分解任务、协调subagent
- subagent并行探索不同方向
- 结果回流给lead agent综合
他们发现token消耗量本身就解释了80%的性能差异——多Agent的价值不是"分工"，而是用更多token覆盖更大的搜索空间。
Anthropic的subagent和三省六部的本质区别：
| 三省六部 | Anthropic subagent |
|---|---|
| 职能性分工（PM→Dev→QA） | 功能性并行（同时搜索不同方向） |
| 不同角色处理流水线的一段 | 没有"下一棒"，结果汇聚回同一个orchestrator |
| 接力赛 | 同时撒网捞鱼 |
OpenAI：Compaction + Skills + 结构化Spec文件
OpenAI给出的长任务原则更直接：在任务开始时就为continuity做规划。
Codex实验的核心设计：
- spec文件 — 冻结目标，防止agent"做出了很impressive但方向错误的东西"
- milestone-based plan — 分阶段计划
- runbook文件 — 告诉agent如何操作，同时也是共享记忆和审计日志
结果： GPT-5.3-Codex跑了约25小时不间断，完成了一个完整的设计工具，保持了全程的连贯性。
Server-side compaction作为默认primitive，不是紧急fallback。 多步骤任务里，previous_response_id让model能在同一个thread里继续工作。
他们还引入了Skills概念——可复用的、版本化的指令集，挂载进container。 这不是"角色"，是工具和操作规程。
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任务相互独立，信息损耗最小 |
如果任务跨越多个session
外部状态文件是必须的。一份有效的状态文件应该包含四类信息：
- 任务目标（不变，session开始时读取，防止漂移）
- 已完成的步骤（追加，不覆盖，保留完整历史）
- 当前状态（覆盖，反映最新进展）
- 已知的坑（追加，避免下一个session重复踩）
如果要加验证环节
让验证Agent的唯一任务是找问题，不是"接棒继续做"。
对抗性检验，不是流水线传递。
保持架构的可演化性
模型能力在快速提升，今天harness里需要的workaround，六个月后可能变成死重量。
Anthropic已经验证了这一点——Sonnet 4.5的context anxiety在Opus 4.5里消失了，为它设计的context reset随即变成了无用代码。
结论
三省六部是一个让人感觉良好但工程上代价高昂的错觉。
它的真正成本不是直接的失败，而是让你的系统在复杂度上升时，以一种难以诊断的方式退化——每个节点都"看起来在工作"，但整体在漂移。
等你发现问题的时候，流水线已经很长了。
