8
什么时候需要不止一个大脑
参考：来源 F · Gulli 第 7 章
学完你能做到
- 说清"拆成多个 agent"要用专业化收益换什么代价
- 区分共享状态和消息传递两种协作方式,各自的风险点
- 知道多 agent 系统出错时,应该先查哪里
m6 的已经是"多个模型协作"的一种形式,但那只是其中一种拓扑——一个头,几个手下,层级分明。
真实的多 agent 系统经常没有这么整齐:几个 agent 平级协作,谁都不完全听谁的。这一节讲这种更松散的协作该怎么设计、怎么出错、怎么查。
为什么要拆成多个 agent
先建立直觉
一个人身兼产品经理、程序员、测试、客服四个角色,脑子里同时装着四套完全不同的知识和判断标准,很容易顾此失彼。
拆成四个专人各管一块,每个人的脑子更清爽,但多了"开会对齐"这道工序。
两种协作方式
| 方式 | 优点 | 风险 |
|---|---|---|
| 信息天然共享,不用互相通知;新加一个 agent 很容易接进来 | 谁都能改,容易出现两个 agent 同时改同一处、后写的把先写的覆盖掉 | |
| 职责边界清楚,每个 agent 的输入输出都是明确的 | 协调本身要花和时间;消息设计不当会互相等待、卡住 |
调试多 agent 系统最容易踩的坑
这一段和 m7 讲的是同一个问题在多 agent 场景下的放大版。单个 agent 出错,你至少知道是它自己的问题;多个 agent 出错,第一个问题永远是"到底是哪一个的锅"。
几种最常见的坑:
- 上游的数据没传到下游。 A 算出来的结果,B 用的时候发现是空的或者是旧的——往往不是 A 算错了,是传递环节丢了数据。
- 上游的结论被下游悄悄改写。 A 判断"这个有风险",走到 C 那一步,结论变成了"正常"——中间某个环节把判断覆盖了,却没有留下痕迹。
- 信号没有门控就被当成结论。 某个 agent 输出了一个数字或者一个标签,后面的环节直接拿它当定论使用,没有校验这个数字本身合不合理。
- 旧数据被当成新数据。 某个 agent 缓存或复用了之前的结果,而系统以为这是当前这一轮重新算出来的。
常见误解
多个 agent 一起干活,肯定比一个 agent 更聪明、更靠谱。
实际上
不一定。是真实存在的成本——协调失败带来的问题(数据没传到、结论被覆盖),在单 agent 系统里根本不会发生。
能用一个 agent 解决的,先别拆。 拆分应该是"专业化收益明显大于协调成本"之后的选择,不是默认做法。
课堂练习
20 分钟- 给一个需求:"审核一批论文投稿,既要查重复率,又要查格式规范,还要写审稿意见。"让学生判断:这个任务该拆成几个 agent?为什么?拆分点在哪?
- 追问:如果拆成三个 agent(查重、查格式、写意见),它们之间该用共享状态还是消息传递?假设"查重"和"查格式"的结果都要给"写意见"用,但两者互相不需要知道对方的细节。
查看参考答案
第一题:三块知识确实互相独立(查重是技术比对,查格式是规则检查,写意见需要综合判断和语言表达),专业化收益明显,值得拆分为三个 agent。
第二题:消息传递更合适。 查重和查格式各自完成后,把结果作为明确的消息发给"写意见"那个 agent,不需要共享一块大黑板——它们的中间过程互不相关,共享反而增加互相干扰的风险。
案例推演：一份研究报告真的需要五个 Agent 吗
团队设计“经理、搜索员、阅读员、写作者、审稿人”五角色。若只是把同一材料依次传递，会增加延迟与信息损失；只有可并行专长或独立验证才可能值得。
本节追问：多 Agent 带来的信息增益能否覆盖协调成本？ 先不要急着看结论。沿着下面四步，逐项区分输入、决策、证据和失败信号。
| 阶段 | 本步要做的决定 | 什么算证据 | 最常见的失败 |
|---|---|---|---|
| 测单体基线 | 先让一个 Agent 使用全部工具完成任务 | 有质量、成本、耗时和失败样本 | 未经比较直接上多 Agent |
| 寻找分工 | 只拆可并行、上下文隔离或需独立视角的子任务 | 每个角色拥有不同输入、工具或评价标准 | 只给角色换名字，能力完全相同 |
| 定义协议 | 规定输入输出 Schema、超时和冲突处理 | 交接可机器校验且有负责人 | Agent 用长篇自然语言相互聊天 |
| 评估收益 | 比较覆盖率提升与 token、延迟、协调错误 | 多 Agent 在目标指标上显著胜出 | 只展示一次成功 Demo |
阅读方式：先遮住后两列自己回答，再用“证据”和“失败”两列检查理解。
常见误解
把组织架构照搬成 Agent 架构
实际上
可观察症状：角色多、会议多，但没有新的证据或能力。
更可靠的修复：以信息边界和任务依赖设计拓扑，能单体完成就优先单体。
案例工作坊 · 建议真正动手完成
25 分钟- 为研究报告找出两个值得并行和两个不值得拆分的步骤。
- 写出搜索员到阅读员的交接 Schema。
- 设计单体与多 Agent 的对照评估。
查看参考答案
多 Agent 适合并行探索、专业工具隔离、独立验证和上下文分区。它不是默认升级；协调、共享状态和冲突会引入新失败面。
迁移检查：换一个场景还会不会
以下哪项最能支持拆成两个 Agent？
检查一下
判断"要不要把一个任务拆成多个 agent",最核心的依据是什么?
多 agent 系统里,"结果不对"这个现象最常见的真实原因出在哪?