何时使用多 Agent
本节目标
学会先证明复杂度的必要性。多 Agent 的正确问题不是“能不能拆出几个角色”，而是“拆分后是否在质量、上下文隔离、并行速度或权限隔离上获得可重复收益”。
从最简单基线开始
依次尝试四级基线：
- 一次模型调用：输入明确、输出一次完成。
- 单 Agent 加工具：步骤不确定，但一个控制循环足够。
- 确定性工作流：步骤、依赖和分支可由代码表达。
- 多 Agent：确有多个专长、相互隔离的上下文/权限，或存在可独立并行的开放任务。
“任务很复杂”不是充分理由。LangGraph 的官方多 Agent说明也明确提醒：单 Agent 配合合适的工具和提示，常能完成看似复杂的任务。增加 Agent 会带来额外模型调用、消息转换、错误传播、状态同步和调试面。
适合拆分的信号
| 信号 | 可验证问题 | 可能拓扑 |
|---|---|---|
| 专长冲突 | 同一提示无法同时稳定满足两组规则吗？ | 经理调用专家 |
| 上下文隔离 | 不同子任务材料混在一起会显著干扰吗？ | 专家子 Agent |
| 权限隔离 | 只读研究者与可写执行者必须分权吗？ | 审批式流水线 |
| 真并行 | 子任务无依赖，关键路径能缩短吗？ | 扇出—汇总 |
| 组织边界 | 外部 Agent 只暴露能力，不暴露内部工具吗？ | 对等协议 |
| 独立复核 | 高风险结果需要独立证据或反方审查吗？ | 生成—审查 |
每个信号都应落到指标。例如“并行更快”要比较端到端 P50/P95 延迟；“专家更准”要比较同一测试集的任务成功率，而不是展示一个成功案例。
不应使用的情形
- 任务可由稳定的代码规则解决，却把每个步骤包装成 Agent。
- 多个角色读写同一文件/记录，但没有唯一所有者和冲突协议。
- 所有 Agent 使用同一模型、同一上下文、同一权限，只是名字不同。
- 子任务强依赖前一步，所谓并行实际上不断等待。
- 预算、停止条件和人工接管未定义。
- 为“讨论得更充分”让 Agent 无限互评；这会放大成本和一致性偏差。
一个量化决策表
为候选方案评分，但不要把分数当真理：
| 维度 | 单 Agent | 多 Agent | 证据 |
|---|---|---|---|
| 成功率 | 0.78 | 0.82 | 固定 100 条测试 |
| 平均调用数 | 3.1 | 8.7 | 追踪记录 |
| P95 延迟 | 11 s | 16 s | 端到端计时 |
| 高风险越权 | 0 | 0 | 红队用例 |
若成功率只小幅提高，却让成本和延迟翻倍，应先优化单 Agent。多 Agent 的价值是“受约束的系统收益”，不是角色数量。
实践
选择一个真实任务，写出：
- 最简单可行基线；
- 拆分后预期改善的唯一主指标；
- 新增失败模式；
- 何种实验结果会让你放弃多 Agent。
常见错误与排查
- 把人格当能力：给角色不同名字不等于不同工具、数据或验收标准。检查其能力合同是否真的不同。
- 只测最终答案：增加跟踪后检查重复工作、消息量、失败恢复和关键路径。
- 先选框架再定义问题：先画数据和控制流，再决定框架。
自测
- 三个 Agent 顺序执行固定步骤，为什么通常更像工作流？
- 哪两类隔离最能支持拆分：上下文、权限、组织还是“说话风格”？
- 若多 Agent 准确率提高 2%，成本提高 180%，还缺什么决策信息？
下一步
继续 角色、拓扑与职责边界。
参考资料
- LangChain 官方文档：Multi-agent（访问于 2026-07-14）
- OpenAI Agents SDK：Agent orchestration（访问于 2026-07-14）