第七章：用“三省六部制”来组织Agent

独奏和交响乐的差别

前四章，我们一直在讲单个Agent。怎么让它理解你、怎么给它工具、怎么让它稳定、怎么评价它。

现在单个Agent已经靠谱了。下一个问题：一个Agent不够怎么办？

你有一个“信息搜集Agent”，能从网上搜资料。你有一个“数据分析Agent”，能从表格里找规律。你有一个“报告撰写Agent”，能写结构清晰的文稿。

它们单独工作都没问题。但如果你想让它们协作：搜来的信息喂给分析，分析的结果喂给撰写，那事情就不一样了。

搜来的信息里有一个错误数据。分析Agent基于这个错误数据得出一个偏差结论。撰写Agent把这个偏差结论写成了一段完美的文字：语气自信，逻辑完整，数据引用清晰。你收到报告，看不出任何问题。

这就是单Agent和多Agent（Multi-Agent，多智能体）的质变：单Agent的错误是“局部错误”。多Agent的错误是“全局偏差”，上游的微小误差，在下游的忠实传递中被层层放大，最终被包装成一个“看起来完全正确”的错误结论。这一章要解决的问题，就是怎么组织多个Agent，让它们的协作不是“放大错误”，而是“互相纠错”。

这个答案，出乎意料地，藏在一套一千三百年前的制度里。

三省六部：一套天生适合Agent的组织逻辑

公元六世纪，隋唐确立了三省六部制。它的核心设计思想很简单：

决策、审议、执行：三权分开，各司其职。

中书省负责起草政令。它不能直接执行，必须交给——

门下省负责审议复核。如果门下省觉得有问题，可以打回去——

尚书省只有在政令经过审议后，才能执行。

而尚书省下面有六部：吏、户、礼、兵、刑、工。每部管一个领域，互不越界。

第七章：用“三省六部制”来组织Agent-BtoAI 图1：“三省六部制”与Agent的映射关系

这套系统的精妙之处在于：

没有人能单独完成全部流程：中书写不了尚书执行的活儿
每个环节都有“校验”：门下是天然的质量闸门
出错时能溯源：是政令写错了，还是审议没发现，还是执行走样了
分工明确但不割裂：六部各自独立，但通过尚书的统一调度协同

这恰恰是Agent编排需要的全部原则。

“三省”——三种编排模式

把三省翻译成Agent编排语言，你会得到三种经典模式：

模式一：串行流水线

规划Agent → 校验Agent → 执行Agent
  (中书)      (门下)     (尚书)

这是最基础的模式。每一步的输出成为下一步的输入，每步有明确的职责边界。

什么时候用： 任务可以被清晰分解为“规划→检查→执行”三个阶段。比如：生成一份市场分析报告，规划Agent确定分析框架和需要的数据维度，校验Agent检查框架是否完整、数据来源是否可靠，执行Agent逐段撰写并标注引用。

核心原则： 每步只做自己职责范围内的事。规划的不执行，执行的不校验。职责越清晰，出错时越容易定位。

风险： 如果校验Agent漏了一个错误，执行Agent会在错误的基础上产出。这和三省制度里“门下省失职则政令有误”是一模一样的逻辑。所以校验Agent不能“走过场”，它需要有明确的校验清单。

模式二：并行分工（六部各司其职）

    调度Agent
   /    |    \
Agent1 Agent2 Agent3
(吏部)  (户部)  (礼部)

不同Agent同时处理同一个任务的不同方面，最后汇总。

什么时候用： 任务有多个互不依赖的子任务。比如：做一个新产品的市场研究，一个Agent分析竞品，一个Agent分析用户评价，一个Agent分析行业趋势。三者并行工作，最后汇总成一份综合报告。

核心原则： 子任务之间没有顺序依赖。如果有依赖（比如“分析竞品”的结果会影响“分析用户评价”的角度），那就不适合并行，应该用串行流水线。

风险： 并行Agent产出的内容可能互相矛盾。竞品Agent说“市场饱和”，趋势Agent说“增长空间大”，那么汇总时需要有一个裁判（或规则）来判断和调和。

模式三：监督者仲裁

    监督Agent
   /    |    \
执行A  执行B  执行C
   \    |    /
    汇总Agent

不是一个“规划者指挥执行者”，而是一个“监督者看执行者的输出，判断对不对，不对就让重做”。

什么时候用： 任务有明确的质量标准，但执行路径不确定，需要试错。比如：生成一份文案，多个Agent各自生成一版，监督Agent按预设标准打分，选出最好的或让不合格的重写。

核心原则： 监督者的评分标准必须提前定义。不能靠监督Agent“自己判断好不好”，那会把它的主观偏好引入系统。

风险： 多个Agent的多次重试，Token成本会迅速上升。需要给监督者设定重试上限。

“六部”——Agent的专业化分工

三省是流程，六部是职能。

在Agent系统中，“六部”对应的不是具体的Agent名称，而是专业化分工的原则：

职责边界清晰。 一个Agent只做一类事。不要让“数据分析Agent”顺便“写邮件”，因为边界越清晰，出错时越容易找到问题。
接口标准化。 每个Agent的输入和输出格式必须一致。Agent之间的“通信语言”应该是结构化的，如JSON Schema、固定字段、明确的类型，而不是自由文本。自由文本会让下游Agent“重新理解”上游的输出，而每次“理解”都是一次概率预测，增加了出错机会。
上下文隔离。 每个Agent有自己独立的上下文窗口。Agent A看到的对话历史不能让Agent B的上下文被污染。它们之间的信息传递，通过结构化的“传递包”进行，不是“你继续聊”，而是“这是你需要的三个字段，处理完返回”。
可替换。 如果“数据分析Agent”用的模型从GPT换成Claude，整个系统不需要改动其他Agent。这就是MCP和标准化接口的价值。
可观测。 每个Agent的运行状态应该能被“看见”：调用了什么工具、返回了什么结果、耗时多少、有没有异常。当一个多Agent系统出问题时，你不能一个个Agent去猜，你需要知道问题出在哪个环节。
全局上下文表。 这是多Agent系统最重要的基础设施。它不是某一个Agent的上下文窗口，而是一张所有Agent都能读写的共享数据表。

Agent A搜到了一条关键数据→写入全局表。

Agent B在处理时发现了一个需要确认的点→写入全局表。

调度Agent看到全局表里的待确认项→分配Agent C去核实。

全局上下文表是多Agent协作的“共享大脑”，没有它，Agent之间的信息传递只能靠把上一轮的对话全部复制给下一个，这不仅低效，而且每一轮复制都在引入新的上下文噪声。

什么时候不该拆

讲完了方法论，必须补一句警告：

多Agent不是越拆越“先进”。

很多人搭Agent系统的第一反应是：我拆成三个——一个管前端，一个管后端，一个管数据库。

这是用微服务的思维在设计Agent系统。但Agent和微服务有本质区别：微服务的输出是确定的（同一个输入永远同一个输出），Agent的输出是不确定的。

每增加一个Agent，你就在系统里增加了一个不确定性的节点。节点越多，不确定性链越长，全局失控的概率越高。

什么时候不该拆？

任务本身用单Agent能稳定完成。 不拆。多Agent的协调成本可能远超收益。
Agent之间的信息传递很复杂。 如果上游的输出是长篇自由文本，下游需要“自己理解”，不拆。你会在Agent之间的“翻译”中损失信息。
你没有为每个Agent建立独立的评价。 不拆。如果一个Agent的表现你都没法单独衡量，把它放进多Agent系统只会让问题更难定位。
你的全局上下文表还没搭好。 不拆。没有共享大脑的多Agent系统就是各自为政。

拆的时机是：单Agent在现有架构下已经无法稳定完成这个任务，不是因为模型不够强，而是因为任务复杂度天然需要分工。

2026年初，腾讯内部同时有8个团队在开发类似OpenClaw的Agent产品——外界叫它“八虾夺嫡”。腾讯的逻辑是：没人知道什么是最佳方法，那就多条路线同时跑。它背后的逻辑和我们在本章讨论的完全一致：不确定性越高的领域，越需要并行探索。只不过，多Agent系统用“监督者”裁决，多团队系统用“市场”裁决。

一个编排的例子

假设你要做一个“每日AI资讯”系统。

单Agent方案：一个Agent从早搜到晚，总结、排版、发送。它会遇到的问题：搜索返回的信息太多，上下文窗口不够；搜索和写作混在一个循环里，注意力被稀释；某次搜索失败会导致整个任务中断。

三省六部方案（举例）：

调度Agent（中书/总调度）
  │
  ├→ 搜索Agent × 3（六部·工）
  │   分别搜索“AI模型”“AI产品”“AI行业”
  │   每个Agent只搜一个领域或信源，输出结构化结果
  │
  ├→ 校验Agent（门下·审议）
  │   检查搜索结果：是否有重复？是否有不可靠来源？
  │   过滤后的结果写入全局上下文表
  │
  ├→ 摘要Agent（六部·礼）
  │   从全局表读取过滤后的结果
  │   每条信息压缩为100字摘要
  │   标注来源和发布时间
  │
  └→ 发送Agent（尚书·执行）
      从全局表读取摘要
      排版、生成最终文本、发送到指定渠道

这个系统的优势：

搜索和写作分离。搜索Agent只负责“找到”，不负责“写”。
校验在中间。搜索的结果不是直接喂给摘要。
全局表解耦。搜索Agent和摘要Agent不直接通信，它们通过全局表交换信息。
失败隔离。如果“AI产品”搜索Agent这次没搜到东西，不影响另外两个搜索Agent的产出。系统降级输出两个领域的内容，而不是整个崩溃。

编排的底层逻辑：不是代码，是设计

你不需要学任何特定框架来实践这一章的内容。三省六部是设计思想，不是技术栈。

你用Coze可以实现、你用Dify可以实现、你用LangChain可以实现。你甚至可以用几个独立的脚本+数据库来实现。

关键在于：你在设计Agent系统时，脑子里有没有“职责边界”“校验环节”“共享上下文”“失败隔离”这些概念。

有，你就是AI设计师。没有，你只是在堆Agent。

本章小结

多Agent编排的核心逻辑，在1300年前就已经被写进了三省六部制：

三省 = 规划-校验-执行的三段式流程。每一步有明确的职责边界和制衡关系。
六部 = 专业化分工六原则：边界清晰、接口标准、上下文隔离、可替换、可观测、全局表。
最关键的判断 = 什么时候不拆。多Agent放大系统复杂度，也放大出错概率。不必要时不拆。

下一章，我们要回到现实：不管你搭的是单Agent还是多Agent，你花的每一分钱，都值得被认真对待。

自查清单

我能说出三种编排模式
我能解释“三省”（规划-校验-执行）和Agent编排的对应关系
我理解专业化分工的六条原则
我能判断“什么时候不该拆”
我在设计多Agent系统前，会先问自己：单Agent真的稳不住吗？

参考链接

LangGraph 多Agent编排. https://www.langchain.com/langgraph
Anthropic, "Building Effective Agents", 2024. https://www.anthropic.com/research/building-effective-agents
Qingyun Wu et al., "AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation", arXiv:2308.08155, 2023. https://arxiv.org/abs/2308.08155

免费、付费、开源、本地部署。你花的每一分钱，对应的是什么？不花的那一分钱，代价又是什么？

下一章：天下没有免费的午餐