最近在几个 AI 社区群里看到不少人在讨论同一个架构思路：把多个 Agent 分别命名成「产品经理」「架构师」「测试工程师」，让它们像公司部门一样传文档、协作完成任务。
图画得特别漂亮，逻辑听起来也顺。但如果你正打算用这套思路搭系统，我劝你先别急。
这套被社区戏称为「三省六部」式的多 Agent 架构，在工程实践里其实有根本性的问题——而且 Anthropic、OpenAI、Google 三家厂商在做自己的生产级 Agent 系统时，没一家用这个模式。
这不是巧合。
「三省六部」这套思路到底是什么
这个比喻指的是一类在社区里流行很久的多 Agent 设计——在不同框架里有不同名字：role-based agents、virtual team、CrewAI 那一套、MetaGPT 的组织模式……为了方便讨论，下面统称「三省六部」。
核心玩法就是把复杂任务按职能拆：
- PM Agent 负责收集需求
- Tech Lead Agent 负责架构设计
- Dev Agent 负责写代码
- QA Agent 负责测试验收
任务在 Agent 之间流转，像一条流水线。
这玩意儿为什么这么流行？因为它好解释、好展示。画成流程图有部门、有箭头、有交接，领导一眼就懂。你跟非技术的人聊「AI 团队自己开发产品」，这个模式是最容易让人「哦懂了」的。
但好解释好展示，跟工程上能不能跑起来，是两码事。
核心矛盾：它在解决人类的瓶颈，不是 AI 的瓶颈
想想为啥人类需要分工：
- 单个人注意力有限，没法同时处理所有信息
- 人有专业壁垒，跨领域学习成本高
- 人与人之间需要接口协调
但 LLM 的特性刚好相反：
| 人类 | LLM |
|---|---|
| 单人能力边界清晰 | 同一个模型能写 PRD 也能写代码 |
| 瓶颈是注意力广度 | 瓶颈是推理深度和上下文完整度 |
| 靠默契和文化补信息差 | 之间没有任何默契可言 |
把「人要分工」这个前提直接搬到 Agent 上，是个典型的错误类比。
坑一：角色标签其实是在制造假边界
给 Agent 贴「产品经理」的 system prompt，不会让它更专业，但会让它拒绝越界。
我之前就见过一个案例：一个被限定在「测试工程师」角色里的 Agent，review 代码时看到了一个架构层的明显问题，直接跳过不报，理由是「不在我的职责范围」。
这就很离谱了。
最有价值的推理，往往发生在边界上。 三省六部模式在系统层面上就把跨边界的思考给封死了，等于主动放弃了 LLM 最有价值的能力。
坑二：信息在流转中会「死亡」
三省六部模式下，Agent A 写完文档传给 Agent B，这个过程传递的是结论，不是推理过程。
B 拿到文档，重新理解、重新建立上下文。原始意图在衰减，隐含假设在丢失，每次传递都在累积误差。
工作流越长，最终输出越「局部正确但整体漂移」——每个节点单看都合理，但整体已经偏离最初的目标了。
人类组织靠什么补这个差？会议、文化、饭局上的闲聊。Agent 之间一样都没有。
有人会问：大厂的 progress.txt、spec 文件不也是「传文件」吗？
这是个好问题，但两者本质完全不同：
三省六部模式：A 写完交给 B，B 不再回头，A 也不知道 B 咋用的。写的人和读的人是不同角色，信息被压成结论，推理过程丢失。
外部状态文件模式：同一任务的增量日志，执行主体在每个 checkpoint 往同一份记录里追加。写的人和读的人是同一角色，只是不同时间。信息不是被「压缩传递」的，是被「连续积累」的。
一个是接棒，一个是接续。这一字之差，决定了推理链能不能跨 session 保持连续。
三家大厂实际是怎么做的
这块儿有意思。翻一翻 Anthropic、OpenAI、Google 的工程博客，几乎找不到「角色扮演」或「部门分工」的字眼。
Anthropic：Context Engineering + 显式状态文件
Anthropic 内部把「Prompt Engineering」升级成了「Context Engineering」——问题不是「怎么写好一个 prompt」，而是「什么样的 token 配置最能产生想要的行为」。
他们构建 Claude Code 时的核心挑战是：Agent 必须在离散的 session 里工作，每个新 session 对之前发生的事情没有任何记忆。
他们用的比喻特别贴切：「轮班工程师」——每个新班次的工程师到岗时，对上一班的工作一无所知。
解法不是给 Agent 分角色，而是：
claude-progress.txt：跨 session 的工作日志，每个 session 结束时更新，下一个 session 开始时读取- Git history：作为状态锚点，记录每一个增量变化
- Initializer Agent：只在第一个 session 跑，负责建环境、展 feature list、写 runbook，供后续所有 session 共用
核心洞察就一句话：推理链的连续性不靠模型「记住」，靠显式的外部状态来锚定。
他们还发现一个有意思的事：Sonnet 4.5 有「context anxiety」，快到 context 上限时会提前收尾。于是 harness 里加了 context reset。但到了 Opus 4.5，这个行为消失了，reset 直接变成死重量。
这说明 harness 得跟着模型迭代不断演化，「永久解法」只是当前阶段的工程妥协。
在多 Agent 的 Research 系统里，Anthropic 用的是 orchestrator-worker 架构：一个 lead agent 分解任务，subagent 并行探索不同方向，结果回流给 lead agent 综合。
他们实测下来发现，token 消耗量本身就解释了 80% 的性能差异。多 Agent 的价值不在「分工」，而在用更多 token 覆盖更大的搜索空间。
容易混淆的点：Anthropic 的 subagent 看起来也像「分工」，但本质不一样——
- 三省六部：职能性分工，A 做完传给 B，接力赛
- Anthropic 的 subagent：功能性并行，多个同质 Agent 同时搜索不同方向，同时撒网捞鱼
OpenAI：Spec + Skills + Compaction
OpenAI 的长任务原则更直接：在任务开始时就为 continuity 做规划。
他们 Codex 的实验里，工程师给 Agent 一个 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：大窗口 + Context-Driven Development
Google 这边走的是硬扩窗口路线：Gemini 的 1M token context 是明确的差异化策略。
逻辑很直白：之前被迫用的 RAG 切片、丢旧消息等等，在足够大的窗口下都可以被「直接放进去」替代。
但 Google 自己也承认这不够。他们在 Gemini CLI 推出了 Conductor 扩展，哲学跟 Anthropic 如出一辙：
「不依赖不稳定的聊天记录，依赖正式的 spec 和 plan 文件。」
Gemini 3 还引入了 Thought Signatures 机制：在长 session 里保存推理链的关键节点，防止「reasoning drift」——长 context 里逻辑前后不一致的问题。
从三家实践里能提炼出的几条硬原则
1. 推理链不能断，只能分叉再合并
多 Agent 的正确用法不是流水线，而是一个主 Agent 持有完整意图，子调用是为了深挖某个子问题，结果回流给主 Agent。
千万不要让 A 传给 B、B 传给 C 再传给 D。
2. 显式外部状态，不靠模型记住
progress.txt、git history、spec 文件、数据库——形式不重要，原则是：推理链的关键节点必须外化到持久存储里，而不是依赖模型在 context window 里「记住」。
3. 多 Agent 的价值是并行覆盖，不是分工
Anthropic 的结论已经很清楚：性能提升主要来自「花了更多 token」，而不是「分工更合理」。
多 Agent 适合 breadth-first 类任务——需要同时探索多个独立方向。不适合需要连续推理、深度依赖上下文的场景。
4. 验证 Agent 应该是否定者，不是接棒者
如果要用多 Agent 做质量控制，正确做法是让一个 Agent 专门找另一个 Agent 的问题，对抗性检验，不是「传递工作成果」。
5. 工具是工具，不是角色
给 Agent 配什么工具（bash、文件读写、搜索、代码执行）远比给它贴什么标签重要。
工具决定了 Agent 能做什么；角色标签只是约束它愿意做什么——后者是纯粹的负面作用。
为什么这么坑的模式反而这么流行？
三省六部能火起来，底层原因很简单：它好解释。
「这个 Agent 是 PM，那个是 QA」——任何人一句话能听懂。它同时满足了两种需求：
- 技术人对「AI 系统可解释性」的渴望
- 管理层对「AI 像团队一样工作」的想象
再加上流程图画出来特别直观，天然适合做 PPT 给领导汇报。
但更深层的原因是：大多数采用这个模式的团队，根本没真正面对过「上下文在多 Agent 间传递时的损耗」这个问题。
他们的任务还不够复杂，或者问题被其他因素掩盖了。等到任务复杂度上来，系统开始出现诡异的「局部正确、整体错误」时，问题才会暴露。
等发现的时候，流水线已经很长了，拆都拆不动。
我的实践建议
最好的多 Agent 系统，不像公司。
它更像一个思考者的多次草稿——同一个大脑，在不同维度上展开推理，最终合并成一个连贯的结论。
具体怎么落地？
别问「我需要几个 Agent」，要先问「这个任务的信息依赖结构是什么」。
- 如果任务需要连续推理、上下文高度依赖（比如写一个复杂功能的设计文档）：单 Agent + 好的 context engineering 通常优于多 Agent
- 如果任务需要同时探索多个独立方向（比如同时研究 10 个竞品的不同模块）：多 Agent 并行是合理的
- 如果任务跨多个 session：外部状态文件是必须的
一份有效的状态文件应该包含四类信息：
| 类型 | 操作 | 作用 |
|---|---|---|
| 任务目标 | 不变，session 开始读取 | 防止漂移 |
| 已完成步骤 | 追加，不覆盖 | 保留完整历史 |
| 当前状态 | 覆盖 | 反映最新进展 |
| 已知的坑 | 追加 | 避免下一个 session 重复踩 |
这四类信息分开维护，合起来就是「下一个自己」需要的完整上下文。
最后一句
模型能力还在快速提升，今天 harness 里需要的 workaround，半年后可能就变成死重量。
Anthropic 已经验证过了——为 Sonnet 4.5 的 context anxiety 设计的 context reset，到了 Opus 4.5 直接就没用了。
保持架构的可演化性，比选一个「完美架构」更重要。
三省六部听起来很合理，画图很好看，但它的真正代价不是直接失败，而是让你的系统在复杂度上升时，以一种难以诊断的方式退化——每个节点都「看起来在工作」，但整体已经在漂移。
等你发现的时候，想回头已经没机会了。
你们项目里有用这种分工式多 Agent 架构的吗？踩过哪些坑，欢迎聊聊。