第 11 章 · 收尾：一张可复用的「多 Agent 协调设计清单」
一句话结论：把前面十章的所有决策点收拢成一张表，就是你「造自己的 agent 框架」时的检查清单。每一个决策点，都不是「唯一正确」，而是「你要基于自己的任务，主动选一个并承担它的代价」。
1. 一张贯穿全文的决策地图
| # | 决策点 | 可选方向 | DeerFlow 的选型 | 选它的核心理由 | 对应章节 |
|---|---|---|---|---|---|
| 1 | 要不要多 agent | 单 agent / 多 agent / 写死 pipeline | 多 agent | 把「上下文溢出」这个不可控的全局瓶颈，拆成可逐个优化的局部瓶颈 | 1 |
| 2 | 按什么拆 | 按步骤 / 按职责 | 按职责 | 每个角色拥有「恰好内聚的工具集 + 上下文」，最小权限 | 2 |
| 3 | 协调靠什么对表 | 自由聊天 / 显式结构化契约 | 显式 Plan（树形、类型化） | 结构化的代价换来「可收敛、可并行、可追溯」 | 3 |
| 4 | 流程承载载体 | if-else / 群聊 / 状态图 | 状态图（LangGraph） | 同时给「可中断、可追溯、可持久化」三样刚需 | 4 |
| 5 | 调度结构 | 协作式平级 / 监督式层级 | 监督式（Supervisor） | 必须有一个节点对「干没干完」负最终责任 | 5 |
| 6 | 执行顺序 | 全串行 / 无脑并行 / 按依赖并行 | 按依赖并行 | Plan 树已编码依赖，并行免费得到 | 5 |
| 7 | Worker 内部 | 一步出结果 / 先规划再执行 / ReAct | 外层 Plan + 内层 ReAct | 大结构保证收敛，小执行保证灵活，分层嵌套 | 6 |
| 8 | 上下文管理 | 全量塞 / 有损压缩 / 事实叙事分层 | 句柄化 + 事实外置 + 渐进加载 | 「事实」和「叙事」必须分家，否则会幻觉 | 7 |
| 9 | 人机协作 | 全程审批 / 全自动 / 关键点插人 | 计划后、执行前插闸门 | 在「杠杆最高 + 可逆性最低」的点，用最小人工换最大纠错 | 8 |
| 10 | 容错粒度 | 整体重来 / 分层重试 | 分层重试 + 重规划 | 检查点让你能「精确到一格」地恢复 | 9 |
| 11 | 角色形态 | 写死代码 / 可配置实体 | 1.x 写死 → 2.0 数据化 | 角色本质是「prompt+工具+上下文」，应做成数据 | 10 |
2. 三条「第一性原理」——比任何具体选型都重要
如果你只从这份教程带走三句话，我希望是这三句：
-
协调靠显式状态，不靠心照不宣。 无论是 Plan 契约、共享 State、还是「完成/未完成」的一等状态，协调的本质都是把隐式的东西显式化。凡是要靠模型「自己记住、自己领会」的地方，都是 bug 的温床。
-
拆分是为「上下文聚焦」服务，不是为拆分而拆分。 拆得太粗，退化成单 agent；拆得太细，协调成本吃掉收益。拆的边界是「职责的自然边界」，判断标准是「这个角色是否拥有完成它那类工作的完整工具集」。
-
架构选择是「你最不能容忍哪种失败」的映射。 协作式 vs 监督式、全自动 vs 人机闸门、灵活 vs 可控——没有绝对的正确，只有「你这个任务，最不能接受哪种失败」的对号入座。
3. 用 Go 造一个的最小骨架（思路级）
不写具体代码，只给你「如果是 Go，这些概念落到哪些原语」的映射，帮你打破语言隔层：
| DeerFlow 概念 | Go 的落点 |
|---|---|
| 角色（prompt + 工具白名单） | interface Agent { Run(ctx, task) Result }，每个实现封装自己的工具集 |
| Plan 契约（树形、类型化） | struct Plan { Steps []Step }，Step 含 []Step 子节点；用 JSON schema 校验 |
| 共享 State | 一个 *State 结构，各 agent 通过传入的同一指针读写 |
| 状态图 + checkpoint | 邻接表存图；每个节点跑完把 State 序列化存盘（可 gob/json 落 SQLite） |
| 调度循环 | 一个 Supervisor.Run，遍历 Plan，用 goroutine + WaitGroup 做兄弟步骤并行 |
| ReAct 循环 | 一个 for rounds < max { llm → tool → observe } 的循环，context.Context 控超时 |
| 事实外置 / 句柄 | 「精确保真」写数据库，上下文里只传 handle（文件路径 / 主键） |
| 人机闸门 | 跑完 planner 后，把状态落盘、返回「待确认」，等外部事件再 invoke 续跑 |
核心提示：别一开始就想「复刻 LangGraph」。 先用手里的原语，把「Plan 契约 + 共享状态 + 监督调度 + 分层容错」这四件套跑通，你就已经掌握了多 agent 协调的 80% 精髓。LangGraph 只是把这些思想做成了工业级的库而已。
4. 如果你想继续深挖
- 读源码：
github.com/bytedance/deer-flow，重点看main-1.x分支的src/（图定义、agents、plan 结构）和main分支的 harness 抽象。 - 追 issue：搜 #4652（任务 ID 蒸发）、#4665/#4690/#4833（持久化任务运行时），这些是「上下文管理」和「容错」最生动的实战教材。
- 横向对比：把 DeerFlow 1.x（监督式 + Plan）和 AutoGen GroupChat（协作式）、CrewAI（角色 + 协作）放一起看，你会更清楚地看到「监督式 vs 协作式」这条分叉线在真实框架里是怎么各自展开的。
结语
多 agent 协调，说到底是**「把一群聪明但健忘、会幻觉、会跑偏的执行单元，用显式的契约、状态和容错，组织成一个可靠的团队」**。
DeerFlow 最值得学的，不是它用了 LangGraph，也不是它拆了五个角色，而是它把「协调」当成一等公民的工程问题来对待——有契约、有载体、有调度、有带宽管理、有容错、有观测。这每一层，都是「让 agent 从 demo 走向生产」的必经之路。
你现在脑子里应该已经有了一张完整的图：从「为什么拆」到「拆成什么」到「怎么对表」到「怎么调度」到「怎么容错」到「怎么抽象」。剩下的，就是动手造一个你自己的——哪怕只造一个跑通四件套的最小版本，你对 agent 开发的认识也会从此上一个台阶。
祝造轮子愉快。