A6 · Multi-Agent 设计
理解什么时候不应该使用 Multi-Agent，以及必须用时怎么控制隔离、预算与失败
本模块产出：日本电商运营多 Agent、单 Agent 对比报告 · 对应总课表：第 21 周
学前自测
1. 这个模块的学习目标写的是「理解什么时候不应该使用 Multi-Agent」。为什么反着说？
因为 Multi-Agent 是当前最容易被滥用的架构。它增加成本、延迟、调试难度和失败面，而收益在很多场景下并不存在。一个 Agent 加几个工具能解决的问题，拆成五个 Agent 只会让你多一堆协调 bug。面试里能主动说出这一点的候选人，可信度立刻不一样。
2. 单 Agent 的真实瓶颈是什么？什么信号说明该拆了？
主要瓶颈是上下文和工具集膨胀导致模型选错工具、以及不同子任务需要冲突的系统指令。信号是：工具超过二十个后准确率明显下降、或者一个 Agent 的 Prompt 里出现互相矛盾的角色要求。注意「任务复杂」本身不是信号，复杂任务用 Workflow 编排通常比 Multi-Agent 更好。
3. 子 Agent 的预算怎么算？父 Agent 的预算和它什么关系？
必须是父预算向下传播并扣减，不能各算各的。否则一个 Supervisor 派发五个子任务，每个子 Agent 都以为自己有完整预算，实际总花费是五倍。Budget Propagation 是 Multi-Agent 成本失控的头号原因。
4. 什么是递归派发失控？怎么防？
子 Agent 又派发了子 Agent，层层嵌套下去。极端情况是 A 派给 B，B 又派回 A，无限循环烧钱。防的手段是派发深度上限、调用链路径记录（检测环）、以及子 Agent 默认不给派发工具。这是 Multi-Agent 特有的失控模式，单 Agent 的 Max Steps 防不住它。
学习目标
理解什么时候不应该使用 Multi-Agent。
必须用的时候，把隔离、预算传播和部分失败处理做对。
课程内容
- Single Agent Limits
- Router
- Handoff
- Supervisor / Worker
- Planner / Executor
- Researcher / Analyst / Reviewer
- Shared State
- Isolated Context
- Subagent Tool
- Parallel Delegation
- Result Aggregation
- Conflict Resolution
- Multi-Agent Eval
- Cost Control
- Context、Tool、Memory 与 Credential Isolation
- Budget Propagation 与 Child Run Lineage
- Partial Failure、Circuit Breaker 与 Bulkhead
- Fan-out / Fan-in、Quorum 与 Straggler Control
- Recursive Delegation / Agent Loop Prevention
隔离与预算传播
实施任务
实现日本电商运营多 Agent：
- Supervisor
- Market Researcher
- Pricing Analyst
- Japanese Copywriter
- Compliance Reviewer
框架实验
- 任选 LangGraph Subgraph 或 Mastra Agent / Workflow 组合完成一个实现
- 对未选框架提交设计评估文档（可选做双实现并配对对比）
动手挑战
先做单 Agent 版本，再做 Multi-Agent 版本，然后诚实比较。
这个挑战的设计意图是让你有机会推翻自己的架构：
- 用一个 Agent 加全部工具实现同样的电商运营任务
- 用五个 Agent 实现
- 同一批 30 条测试用例跑两边，测四个维度：成功率、总成本、端到端延迟、代码行数
- 如果 Multi-Agent 在成功率上没有显著优势，回退单 Agent 并写清楚为什么
大多数人做完会发现 Multi-Agent 贵三到五倍、慢两倍，而成功率提升有限。这不是失败的实验，这是这个模块最有价值的产出：一份能证明你不盲目跟风的数据。
如果 Multi-Agent 确实赢了，也要能说清赢在哪个具体环节，通常是合规审查这类需要独立视角的子任务。
验收标准
- 子 Agent Context 隔离
- Supervisor 不重复派发
- 子任务可并行
- 失败子任务可重试
- Multi-Agent 相比单 Agent 有量化收益，否则回退单 Agent
- 子 Agent 只获得任务所需 Context、Tool、Memory 与短期凭据
- 父子 Run、预算、Trace、Artifact 和失败责任可关联
- 单个子 Agent 超时、失控或失败不会耗尽全局预算
- 在相同成功率下报告单 Agent 与 Multi-Agent 的成本、延迟和复杂度差异
学后自测
1. 五个子 Agent 里有一个超时了，Supervisor 应该怎么办？三种策略各适合什么？
等到底（适合结果必须完整的场景，但要有全局 deadline）、丢弃并降级（适合可选增强信息，比如竞品分析缺了也能出定价）、重试一次再降级（折中）。关键是这个策略要显式配置在每个子任务上，而不是全局一刀切，因为合规审查缺不得、竞品分析缺得起。
2. 两个子 Agent 给出了冲突结论，比如定价分析说卖 100，合规审查说这个价格违规。怎么解决？
冲突解决必须有明确规则，不能让 Supervisor 靠模型自由发挥。常见规则是优先级排序（合规永远高于定价）、或者升级给人。让模型自己调和冲突，结果不可预测且无法审计。
3. 你的对照实验结论是什么？如果 Multi-Agent 输了，你怎么向团队解释这两周没白干？
没白干的理由是：你现在有数据证明单 Agent 够用，团队不用再花三个月做一个更贵更慢的架构。证伪一个流行方案的价值不低于实现它。 这个回答本身在面试里就是加分项，因为它展示了工程判断而非技术炫耀。
本模块作业
- 单 Agent 版本 + Multi-Agent 版本两套实现
- 30 条测试用例的四维度对照数据
docs/multi-agent-decision.md：对照报告与架构结论（含回退决定，如果适用）- 隔离测试：Context、Tool、Memory、凭据四类隔离的验证
- 递归派发防护：深度上限与环检测
面试考点
这个模块对应面试里的架构判断力考察，是最容易翻车也最容易出彩的一题。
- 「你做过 Multi-Agent 吗？」：陷阱题。很多人急着展示做过，然后被追问收益时答不上来。正确开局是「做过，而且做了单 Agent 对照，结论是某某场景下不值得」，直接把话题引到你的数据上。
- 「什么时候该用 Multi-Agent？」：答工具集膨胀导致选错工具、以及子任务需要冲突的系统指令这两个信号。强调「任务复杂」不是信号，复杂任务优先用 Workflow。
- 「Multi-Agent 的成本怎么控制？」：答 Budget Propagation。讲清不做预算传播会导致五倍成本这个具体后果。
- 「子 Agent 之间怎么隔离？」：答四类隔离：Context、Tool、Memory、凭据。凭据隔离最容易被忽略，主动提它显得专业。
- 「一个子 Agent 挂了怎么办？」：答按子任务重要性分级配置降级策略，举合规缺不得、竞品缺得起的例子。一刀切的答案说明没做过真实业务。
- 加分动作：主动说出递归派发失控这个坑，以及你的深度上限和环检测方案。这个失败模式知道的人不多。
复习与延伸
官方文档与文章
- Anthropic：构建高效 Agent，其中关于何时不用 Agent 的部分是这个模块的思想来源
- Anthropic：多 Agent 研究系统
- LangGraph Subgraph
- Mastra Agents
本仓库对应源码
packages/contracts/src/agent.ts：父子 Run 关联所需的定义packages/eval-kit/src/evaluate.ts：对照实验的数据采集入口