前八篇你造出了一个完整的单体 Agent。本篇回答两个高频问题：什么时候需要多个 Agent？多个 Agent 怎么协作？ 以及顺带回答：什么时候才真的需要框架？配套可运行示例：
zhiliao/examples/multi_agent_demo.py。
一、多 Agent 的第一性原理
先泼冷水：多 Agent 不是数量游戏。两个烂 Agent 不会等于一个好 Agent。多 Agent 的真正价值只有一个：
把"写"和"评"分开，让模型能客观地审视自己。
单一 Agent 自我修改的困境：它刚写完稿，你让它"检查一下自己的稿子"——同一份上下文里，作者视角会强烈污染审稿视角（自己刚写的都是对的）。而两个各自独立上下文的 Agent，审稿人拿到的是"一份没有作者的稿子"，批评就客观了。
这和人类组织一个道理：自己检查自己，永远不如交叉检查。
二、最小可运行示例：写手-审稿人模式
examples/multi_agent_demo.py 的完整骨架，50 行：
WRITER = "你是资深文案写手。只输出文案本身，不要解释。"
CRITIC = ("你是苛刻但建设性的编辑。指出文案的3个最主要问题"
"（吸引力/准确性/简洁度），每条给具体的修改建议。只输出问题清单。")
draft = llm.complete(topic, system=WRITER) # 写手初稿
for round_no in (1, 2): # 打磨两轮
critique = llm.complete(f"主题：{topic}\n\n文案：\n{draft}", system=CRITIC)
draft = llm.complete(
f"你的原稿：\n{draft}\n\n编辑意见：\n{critique}\n\n请吸收意见，输出修改后的完整文案。",
system=WRITER)
看清楚它的本质了吗？同一个 LLMClient，不同的 system prompt，不同的编排顺序。所谓"多 Agent"，就是：
多 Agent = 多个"角色（system prompt）+ 独立上下文"的 LLM 调用 + 人为编排的对话拓扑。
没有魔法。所有多 Agent 框架（AutoGen、CrewAI、MetaGPT）拆到底都是这句话。
运行看效果：
python examples/multi_agent_demo.py "为一款 AI 学习App写宣传语"
你会看到 v1 文稿 → 编辑意见 → v2 → 再意见 → v3 的完整迭代，通常 v3 的质量肉眼可见地高于 v1。
三、三种经典协作拓扑
1. 主管-工人（Supervisor）模式 —— 最常用
┌──→ 工人A（查资料）
主管 ────┼──→ 工人B（写代码） ──→ 主管汇总 → 输出
└──→ 工人C（做表格）
一个"主管 Agent"负责拆任务、分派、验收；工人各干各的。知了的核心循环其实已经能当主管用：给主 Agent 配一个"dispatch_task"工具，工具的实现就是"再起一个子 Agent"——这就是 Manus 类产品的骨架。
2. 流水线（Pipeline）模式 —— 确定性任务
需求 Agent → 架构 Agent → 编码 Agent → 测试 Agent
每个环节的输出是下一环节的输入，像工厂流水线。适合步骤固定、每步职责清晰的任务（写长文的"大纲→初稿→润色"）。简单可靠，缺点是上游错误会顺流而下。
3. 辩论/评审（Debate）模式 —— 质量敏感任务
方案 → 审稿人A（挑逻辑）┐
审稿人B（挑事实）┼→ 仲裁者综合意见 → 终稿
审稿人C（挑风格）┘
多个评审各自独立挑刺，再由一个角色仲裁。适合代码评审、风险评估、重要文案定稿。代价是 token 消耗成倍增长。
选型口诀：任务能拆成固定步骤用流水线；步骤要动态决定用主管-工人；质量要求高就上评审；都不需要就老老实实用单 Agent。
四、什么时候才真的需要框架？
裸写（本系列的做法）和框架（LangChain / LlamaIndex / AutoGen / CrewAI / OpenAI Agents SDK）的诚实对比：
| 裸写 | 框架 | |
|---|---|---|
| 学习成本 | 你已经付完了（10 篇教程） | 新的一套抽象要学 |
| 灵活性 | 100%，每行都是你的 | 受框架抽象限制，"抽象漏水"时要读它源码 |
| 集成便利 | 什么都要自己接 | 现成的模型/向量库/工具集成一大把 |
| 调试 | 栈浅，一眼到底 | 栈深，出问题在框架肚子里 |
| 适合 | 学习期、逻辑独特的核心系统 | 快速拼接常见模式的原型/中型应用 |
判断标准一句话：当你要的东西框架里有现成的、而且你理解它替你做了什么，用框架省时间；否则裸写。你已经裸写过核心循环、记忆、RAG、技能，所以你现在是"理解后使用"的那类人——本系列送你的正是这个。
五、四个值得知道的进阶概念
反思（Reflection）：让 Agent 对自己的产出再做一轮"批判性检查"再交付。本篇的 writer-critic 就是它的双 Agent 形态；单 Agent 版可以"写完→自检清单过一遍→修订"。
规划（Planning）：动手前先让模型输出分步计划（甚至用 write_file 把计划存下来），之后每步对照计划执行。任务越长，规划的价值越大。
并行（Parallelism）：互不依赖的子任务同时跑。还记得第 3 篇模型一次请求多个工具调用吗？那就是最细粒度的并行；主管模式下"同时派 3 个工人"是大粒度并行。
Human-in-the-loop（人机协同）：关键动作前停下来问人。实现思路：给 Agent 一个 ask_human 工具，调用它时把问题展示给用户、暂停循环等输入。删除文件、对外发消息、花钱这三类动作，永远应该过人。
六、给单体知了的三个升级练习
- 主管化：加一个
delegate_task工具，实现为"新建一个干净的 Memory + 复用主循环"，让知了学会派活。 - 自检技能：写一个
self_check技能（markdown），让它在交付长文档前按清单自检一遍。 - 人机协同：把
write_file的覆盖动作改成"先调 ask_human 征求同意"。
本篇作业
- 跑通
multi_agent_demo.py，换三个不同主题，观察审稿意见质量的波动。 - 给 CRITIC 加一条"必须挑出恰好3个问题，不许多也不许少"，观察输出稳定性变化。
- 思考：辩论模式里，如果三个审稿人的意见互相矛盾，仲裁者该按什么原则取舍？（这是真正的开放问题，没有标准答案）
下一篇预告：《10 · 部署上线与学习路线图》——最后一篇：Docker 打包、上云的路线选择、成本与安全红线、怎么评测你的 Agent 变好了，以及一张继续前进的学习地图。