Multi-Agent

Multi-Agent 是把复杂任务拆给多个独立 Agent 协作完成的架构。每个 Agent 有自己的角色、上下文窗口和决策循环，通过消息通信。它和前几篇的 ReAct、Plan-and-Execute、Reflection 不在一个维度：那些是单个 Agent 内部的推理范式，Multi-Agent 是架构层的组织方式。一个 Agent 内部照样可以跑 ReAct 循环，多个这样的 Agent 再组成团队。

先说结论，这句话面试必考：默认先用单 Agent，只有单 Agent 暴露出明确瓶颈时才拆。 Anthropic 的公开经验很直接，大多数团队并不需要 Multi-Agent。很多看起来该拆的问题，优化单 Agent 的 prompt、工具和上下文管理就能解决。Multi-Agent 的成本是数量级的：普通 Agent 的 token 消耗可能是聊天的数倍，Multi-Agent 会放大到十几倍。

什么时候拆

三种明确的适用信号：

1. 上下文污染。 多个子任务信息量大且相互独立，全塞进一个上下文，模型注意力被无关信息稀释，还会把一个子任务的中间结论错误迁移到另一个。拆开的收益不是“多人协作”，是上下文隔离
2. 天然可并行。 搜索空间太大必须多路同时探索，比如跨领域研究、多仓库并行分析。多个 Agent 并行，总耗时取决于最慢的那个
3. 工具选择失真。 工具超过 10 到 15 个，模型选工具的准确率明显下降。拆给专业 Agent，每个只维护 2 到 5 个高相关工具

三种明确不该拆的场景：

• 编码任务。 1 到 3 个文件的小中型修改，可并行部分远少于研究类任务，强拆得到的是重复理解代码和反复协调接口
• 简单查询。 几次工具调用能完成的事，主 Agent 拆分、子 Agent 执行、系统汇总，成本放大数倍，结果未必更好。成熟系统会给 Agent 数量加“缩放规则”，随任务复杂度缩放
• 按公司组织架构设计。 把 Agent 当同事而不是当工具，角色化分工持续产生协调开销，任务被改写成多轮角色间转述。合理的方式是把子 Agent 当函数调用：主 Agent 拉起一个临时子 Agent，干完返回结构化结果

五种协作拓扑

选型可以按任务结构走：流程能画成固定流程图用 Pipeline；大任务能拆成独立子任务用 Orchestrator；路径要动态调整用 Supervisor；错误代价高且需要多方论证才上 Debate；角色边界和转交条件都清楚才用 Swarm。主流生产系统大多采用 Orchestrator-Worker 形态。

Orchestrator-Worker 详解

Orchestrator 是一个 LLM 驱动的 Agent，不是规则脚本。它做三件事：把高层意图拆成可独立完成的子任务、决定每个子任务派给哪个 Worker 并传什么参数、聚合结果决定继续还是结束。它的输出必须结构化（JSON），不能是自由文本，这样上游代码能校验、能路由，也是它幻觉时的兜底。

Worker 有四个设计原则：

• 单一职责。检索的只检索，写作的只写作
• 独立上下文。只看自己的 system prompt、orchestrator 派给它的输入和工具结果，看不到其他 Worker 的内容
• 小工具集。每个 Worker 配 2 到 5 个相关工具，避免选择疲劳
• 结构化输出。返回 {summary, evidence, status} 这类固定 schema，方便聚合

和 Plan-and-Execute 的关系值得说清：P&E 是 O-W 的一个特例，orchestrator 开局规划一次就退场，Worker 按计划顺序执行。更一般的 O-W 允许每步动态决策、并行 fan-out、多层嵌套。判断标准：能不能在不看具体问题之前就画出计划模板，能就 P&E，不能就动态 supervisor。

状态共享有三种策略。 完全隔离（Worker 不知道其他 Worker 存在）上下文最小但协调全压在 orchestrator 身上；共享 blackboard 信息流通但上下文膨胀、Worker 隐式耦合；半隔离（orchestrator 精选前序结果传给 Worker）是业界主流，灵活可控，代价是 orchestrator 要会挑相关上下文。Anthropic 的研究系统用的就是半隔离：lead agent 派任务时只给“你这部分要查什么”，不给全局查了什么，subagent 上下文保持在 5 到 10K token，能并行起 5 到 10 个不爆限流。

聚合时的信息经济学。 默认只看 Worker 返回的摘要，关键决策节点才按需拿全文。全部看全文，token 成本约等于单 Agent，等于白拆。摘要会漏细节，所以 orchestrator 要有一个按需取详情的通道，比如 get_full_output(worker_id)。

Anthropic Research System 是这套模式的公开案例：lead agent 用 Opus，把研究问题拆成 3 到 7 个子问题；subagent 用 Sonnet，各自独立检索，并行执行把端到端延迟从 20 多分钟压到 5 分钟；还有第三层 Citation Agent 专门核对引用正确性。token 消耗约单 Agent 的 4 倍，内部评测研究质量提升 90% 以上。这就是 multi-agent 的核心 ROI 数字：用钱换质量和延迟。

上下文隔离与通信

Multi-Agent 的核心价值一句话：通过通信共享上下文，而不是通过共享上下文来通信。 子 Agent 之间不直接传聊天记录，handoff 只传递最小上下文：任务目标、前置结论、当前职责、允许的工具、预期的输出结构。把整段对话丢给下一个 Agent，是 handoff 最常见的错误。

实现上通信走消息传递，不走函数调用。父 Agent 往子 Agent 的信箱写消息就返回，子 Agent 在自己的循环边界读取，天然支持并发，谁先完成谁先通知。跨进程的标准化协议有 A2A（Agent-to-Agent），用于不同框架、不同服务商构建的 Agent 互相通信；MCP 管 Agent 和工具之间的连接，A2A 管 Agent 和 Agent 之间，两者是嵌套关系。

循环检测不能省。 Agent 之间直接通信后，调用链可能成环：A 调 B，B 调 C，C 又回调 A。工程做法是调用图 DFS：每次跨 Agent 调用前检查目标是否已在当前调用链上，出现过就拒绝；同时维护调用深度上限（比如 10 层），超过就认为任务拆分出了问题。时间窗口辅助检测：同一调用对在 30 秒内被调了 3 次，说明系统异常。检测到循环后的处理分三级：降级返回已有结果、降频控制节奏、熔断跳过子任务。

生产实践

• 终止条件必须硬。 群聊式协作最容易失控：Writer 写完 Critic 还没看，Summarizer 抢先总结。做法是显式配置发言跳转白名单（Allowed Transitions），加上多层终止条件：最大轮数、超时、Token 预算、终止关键字。AutoGen 的 TerminationCondition 就是这个思路的组合
• HITL 是安全底线。 高风险工具（转账、对外发送）在工具层拦截，挂起当前执行流，人工批准后从检查点恢复。LangGraph 用 interrupt 机制，AutoGen 用 UserProxyAgent
• 可观测性要带层级。 trace 要有 “orchestrator → worker” 结构，哪个 Agent 出错、为什么路由错了、耗时分布，逐层可查。状态串线事故十有八九是 thread_id、session_id、user_id 隔离设计混乱，不是模型问题
• 框架选型看控制力需求。 LangGraph 是有状态图 + 原生 checkpoint，崩溃从断点恢复，适合生产长任务；AutoGen 是对话式协商，适合探索型原型；CrewAI 是角色流水线，上手最快。选型口诀：明确分支流程选 LangGraph，多 Agent 自由协商选 AutoGen
• 协调者必须理解，不能转发。 主 Agent 把 Worker 的 findings 读懂、写成具体规格再派下一步，而不是“based on your findings, implement the fix”式偷懒。协调者只会转发，就没有存在价值

面试追问

1. 为什么默认单 Agent？ 单 Agent 的上下文、状态、评估、故障定位都更简单。Multi-Agent 是十几倍成本量级的高开销架构，只有当 trace 证明单 Agent 在稳定边界上失败才拆。判断看四种独立性：上下文能否独立、能力权限能否独立、任务能否独立执行、结果能否独立验收
2. 子 Agent 和 Tool 的区别？ Tool 是被动单次调用；子 Agent 有独立上下文、独立规划循环，能中途调整策略，失败可单独重试降级。代价是协调开销
3. 上下文隔离怎么实现？ handoff 只传最小上下文，不传聊天记录。通过通信共享上下文，而不是通过共享上下文来通信
4. 怎么防死循环？ 多层终止条件（轮数、超时、token 预算、关键字）、发言跳转白名单、调用图 DFS 循环检测加深度上限、重复调用时间窗口检测
5. Multi-Agent 一定更准吗？ 不一定。它买的是上下文隔离、并行和专业化，代价是成本和协调复杂度。质量收益覆盖不了协调成本就退回单 Agent，这是合理的工程决策