多智能体的价值不在于「三个模型比一个聪明」，而在于上下文隔离、职责分离和并行。如果这三样你都不需要，多 Agent 只会让你多付几倍的钱。
什么时候值得拆分
多 Agent 真正有效的场景：
- 子任务需要读大量材料：让子 Agent 读完 40 页文档，只回传结论，主上下文不被污染。
- 职责差异很大：研究、写作、审查需要不同的提示、工具和标准。
- 可以并行：三个独立数据源同时查，延迟从 3 倍降到 1 倍。
- 需要独立验证：一个 Agent 做，另一个 Agent 挑错，减少自我肯定。
- 权限不同：只读研究 Agent 与可写执行 Agent 分离，降低越权风险。
不该拆的场景：
- 任务只有两三步；
- 子任务之间高度耦合、需要频繁共享中间状态；
- 预算紧张、延迟敏感；
- 你只是想让架构「看起来更先进」。
多 Agent 系统通常比单 Agent 更难评估、更难调试、更贵。先证明单 Agent 不够用，再拆。
四种拓扑
主管（Supervisor）
中心节点拆解任务、分派给子 Agent、汇总结果。最常用，边界清晰。
流水线（Pipeline）
研究 → 写作 → 审查，顺序执行。每一步有明确输入输出，适合内容生产。
辩论（Debate）
多个 Agent 独立作答、互相批评，由裁判收敛。适合高风险判断，成本高。
蜂群（Swarm）
Agent 之间直接交接，没有固定主管。灵活，但全局目标与可观测性难保证。
主管模式：默认选择
Supervisor
├─ Researcher 只读，负责收集与核实
├─ Analyst 负责计算与对比
└─ Writer 负责组织与表达主管持有全局目标、计划和预算；子 Agent 拿到的是局部任务 + 必要背景 + 输出要求，而不是全部历史。子 Agent 完成后只回传结构化结果。
一个最小实现：
def supervise(goal: str, max_rounds: int = 6):
state = {"goal": goal, "results": {}, "notes": []}
for _ in range(max_rounds):
decision = supervisor.decide(state) # 返回 next_agent / task / done
if decision.kind == "done":
return supervisor.finalize(state)
agent = AGENTS[decision.agent]
brief = {
"task": decision.task,
"context": decision.context, # 主管筛选过的必要背景
"constraints": decision.constraints,
"output_schema": agent.output_schema,
}
result = agent.run(brief)
state["results"][decision.agent] = result
state["notes"].append(decision.note)
return escalate(state, "超过最大协调轮数")注意：主管的 decide 也是模型调用。协调本身有成本，轮数越多越贵。
交接契约
多 Agent 最常见的失败是「交接丢信息」。一个可用的交接结构：
{
"from": "researcher",
"to": "writer",
"reason": "资料收集完成，进入写作",
"goal": "写一份 800 字风险简报",
"completed": ["获取 10-K", "抽取四项指标", "对比三家同行"],
"findings": [
{ "fact": "毛利率同比下降 4.2pp", "source": "10-K p.42" }
],
"open_questions": ["一次性费用的具体构成尚未核实"],
"constraints": ["必须引用来源", "不包含投资建议"],
"deadline_seconds": 120
}重点字段：
reason：为什么交接，避免接收方重复判断；completed：已经做了什么，避免重复劳动；findings：带来源的事实，而不是原始材料；open_questions：明确未完成的部分；constraints：接收方必须遵守的边界。
没有这份契约，子 Agent 只能从消息历史里猜，信息损失会非常严重。
共享状态还是消息传递
| 方式 | 优点 | 缺点 | 适用 |
|---|---|---|---|
| 消息传递 | 解耦、可并行、上下文隔离 | 信息可能丢失、需要契约 | 主管、流水线 |
| 共享状态 | 信息完整、易恢复 | 上下文膨胀、并发冲突 | 图编排、短流程 |
| 混合 | 共享关键事实，消息传任务 | 设计复杂 | 生产系统常用 |
推荐做法：共享一份结构化的事实表与任务状态，消息只传任务和结论。原始材料放外部存储，需要时按 ID 读取。
成本为什么会爆炸
假设 4 个 Agent，每个都要：
- 系统提示 1k token；
- 工具定义 2k token；
- 任务背景 1k token；
- 平均 3 轮。
仅输入就是 4 × 3 × 4k = 48k token，还没算主管的协调调用和最终汇总。对比单 Agent 的 12k，贵了 4 倍，而任务成功率可能只提升几个百分点。
更隐蔽的成本是错误传播：研究 Agent 给了一个错误事实，分析 Agent 基于它计算，写作 Agent 把它写进报告，审查 Agent 只检查格式。最终错误被三层放大。
失败模式
信息在 Agent 之间逐层转述，细节丢失。解决：传递结构化事实与来源，而不是自然语言摘要。
一个子 Agent 的错误被下游当作事实。解决：关键事实必须带来源，下游可回查；重要结论由独立 Agent 验证。
两个子 Agent 查了同一份资料。解决：主管维护「已完成/已获取」清单，分派前检查。
所有 Agent 用同一个模型、相似的提示，辩论时一起错。解决：引入不同模型、不同角色、外部证据。
主管反复分派、汇总、重派，轮数比单 Agent 还多。解决：限制协调轮数，能并行就并行，能合并就合并。
最终结果错了，不知道是哪个 Agent 的问题。解决：每个子 Agent 独立 trace，交接记录完整。
如何评估多 Agent
除了单 Agent 的指标，还要看：
- 协调效率：完成同样任务，总步数/总 token 比单 Agent 多多少；
- 交接质量：下游是否需要重新获取上游已有的信息；
- 错误归因率：失败时能否定位到具体 Agent 与步骤；
- 并行收益：延迟是否真的下降；
- 一致性：多个 Agent 的事实是否冲突。
一个实用实验：同一批 30 个任务，分别用单 Agent 和多 Agent 跑，比较通过率、成本、P95 延迟。如果多 Agent 只提升 5% 通过率却贵 4 倍，答案通常是不值得。
什么时候该退回单 Agent
- 子任务无法独立定义输入输出；
- 交接成本高于任务本身；
- 大部分时间花在协调而不是执行；
- 评估显示提升不足以覆盖成本；
- 团队还没有能力调试分布式 trace。
小结
- 多 Agent 的收益来自上下文隔离、专业化、并行和独立验证，不是「更聪明」。
- 主管模式是默认选择；流水线适合内容生产；辩论适合高风险判断；蜂群慎用。
- 交接必须有结构化契约：目标、已完成、发现、未决、约束。
- 共享事实、传递任务，原始材料放外部。
- 成本与错误传播会被层数放大，必须用数据证明拆分值得。
下一篇把流程装进确定性骨架：工作流、状态机与图编排。