外观
🎈 想读易懂版？
本章有易懂版（大白话讲重点，10 分钟读完）：[第 18 章 如何进行多 Agent 系统设计（易懂版）](../../easy/第18章 如何进行多 Agent 系统设计（易懂版）.md)
第 18 章 如何进行多 Agent 系统设计
本章目标：掌握多 Agent 系统设计的方法论——第一原则、适用判断、五步设计法、黄金结构与常见错误。多 Agent 系统设计，本质是组织结构设计：拆得好，是团队；拆得差，是团伙。
18.1 从"一个 Agent"到"一个系统"
第 8 章、第 16 章讲了怎么用团队。这一章讲设计：当你要解决一个复杂问题，怎么设计出一套多 Agent 协作的系统，而不是随手拉几个人。
18.1.1 设计 vs 使用
使用（第 8、16 章）：现成的团队怎么用起来
设计（本章）：面对新问题，怎么设计出合适的协作结构设计在前，使用在后——设计错了，怎么用都别扭。
18.2 设计的第一原则：能不拆就不拆
多 Agent 系统有成本：沟通开销、上下文割裂、结果不一致。所以：
单 Agent 能解决的 → 绝不拆
任务可串行完成 → 不必并行
只有拆分收益 > 协作成本 → 才拆多 Agent 是手段，不是目的。
18.2.1 拆分的成本清单
| 成本 | 说明 |
|---|---|
| 沟通开销 | 成员之间传递信息要花时间 |
| 上下文割裂 | 每个成员只看到部分信息，可能误判 |
| 结果不一致 | 不同成员产出风格/口径可能打架 |
| 管理开销 | Leader 要协调、验收、处理阻塞 |
18.3 什么样的任务值得多 Agent
√ 多个专业角色（设计、开发、测试）
√ 可并行（各部分互不依赖）
√ 单个 Agent 上下文装不下
√ 需要交叉验证（写的人不能同时验）
× 需求未定、探索阶段
× 任务小到一句话能说清18.3.1 判断流程
任务复杂吗？——否 → 单人
是 ↓
能拆成相对独立的子任务吗？——否 → 单人
是 ↓
拆分收益 > 协作成本？——否 → 单人
是 ↓
✅ 设计多 Agent 系统18.4 设计一个多 Agent 系统的五步法
第 1 步：定义目标与产出
目标：上线一个新功能
产出：代码 + 测试 + 文档 + 上线检查单先想清楚"最后要什么"，才谈怎么拆。
第 2 步：识别角色
按任务自然边界切：
规划（拆任务）→ 开发（写代码）→ 测试（验证）→ 文档（沉淀）→ 评审（把关）角色数量控制在 3～5 个——角色过细，沟通成本爆炸。
第 3 步：定义每个角色的输入输出
开发：输入=需求文档；输出=代码 + 自测说明
测试：输入=代码 + 需求；输出=测试报告（通过/问题清单）每个角色都要回答四个问题：
- 我的输入是什么？（谁给我什么）
- 我的输出是什么？（我交付什么）
- 我的验收标准是什么？（怎样算完成）
- 我依赖谁、谁依赖我？（协作关系）
第 4 步：设计协作关系
规划 → 开发 → 测试 → 评审
↘ 文档 ↙明确三件事：谁给谁交付、谁验证谁、谁有最终决定权。
| 关系 | 说明 |
|---|---|
| 依赖 | B 需要 A 的产出才能开工 |
| 验证 | 测试验证开发的产出 |
| 决策 | Leader 对最终交付有决定权 |
第 5 步：设定检查点与回退
检查点：开发完成 → 测试验收 → 评审通过 → 交付
回退：测试发现问题 → 打回开发，附问题清单检查点 = 质量闸门；回退路径 = 出错时的逃生通道。 两者缺一不可。
18.5 多 Agent 系统的黄金结构
Leader（我：拆解、协调、验收）
/ | \ \
规划 开发 测试 文档
\ \ / /
交叉验证 → 汇总交付核心规则：写的人不验，验的人不写。 这是质量的第一道保险。
18.5.1 为什么"写的人不验"
自己写的代码自己验，容易"验出自己想要的答案"（思维定式）。独立的验证者才能发现盲区——这是测试角色存在的根本原因。
18.6 常见设计错误
| 错误 | 后果 | 修正 |
|---|---|---|
| 角色过细 | 沟通成本爆炸 | 合并到 3～5 个角色 |
| 没有 Leader 验收 | 各做各的，没人对整体负责 | 明确唯一负责人 |
| 任务边界重叠 | 重复劳动 | 每个子任务唯一归属 |
| 全程并行 | 依赖没处理好 | 先画依赖图再排期 |
| 没有回退路径 | 出错就卡死 | 预设打回机制 |
18.6.1 依赖图先行
设计阶段先画依赖图，再排执行计划：
规划 ──→ 开发A ──→ 测试 ──→ 评审
│ 开发B ──↗
└──→ 文档（可与开发并行）- 有依赖的：串行，先做上游；
- 无依赖的：并行，同时开工；
- 并行不是目的，按依赖正确排序才是。
18.7 多 Agent 设计的进阶原则
18.7.1 从"静态结构"到"动态调整"
好的设计不是一次定死的，而是根据执行反馈动态调整：
发现开发任务太大 → 再拆成 2 个子任务
发现测试无事可做 → 调整测试介入时机
发现需求变化 → 重新评估拆分是否还合理18.7.2 设计文档的价值
多 Agent 系统的设计，本身就应该写成文档（角色表、依赖图、检查点）——它既是执行蓝图，也是复盘依据，还能沉淀为团队模板。
18.8 练习
- 选一个你熟悉的复杂任务，按五步法画出系统设计；
- 画出角色关系图，标出依赖和检查点；
- 用真实任务跑一轮，复盘：拆分是否合理？哪里协作成本最高？
- 把这份设计写成文档（角色表 + 依赖图 + 检查点），沉淀为模板。
18.9 延伸阅读
- 平台已经把"角色表 + 依赖图 + 检查点"做成了现成的团队模板，不必从零设计：读第 27 章，速查见附录 D；
- 想给某个角色配上"专业人格"（挑刺的、盯进度的、审代码的）：读第 26 章；
- 想看清整个平台的装备地图，再决定要不要拆团队：读第 23 章。
小结：多 Agent 系统设计，本质是组织结构设计。拆得好，是团队；拆得差，是团伙。能不拆就不拆 + 写的人不验 + 检查点与回退齐全，就是设计心法。下一章：自动化工作流的可靠性。