profileName: youpingfang postId: 378 postType: post categories:
- 6
总结：多智能体系统只有在能解决单智能体无法克服的特定约束时才有价值，否则协调成本会超过收益。 https://claude.com/blog/building-multi-agent-systems-when-and-how-to-use-them
核心观点
- 多智能体系统会引入额外的开销（故障点、维护提示、意外行为、令牌消耗增加3-10倍）
- 在Anthropic的实践中，许多团队花费数月构建复杂多智能体架构，最终发现改进单智能体提示策略也能达到同样效果
三种值得使用多智能体的情况
1. 上下文保护
- 问题：智能体的上下文窗口有限，当积累了来自某子任务且与后续任务无关的信息时，响应质量下降
- 方案：每个子智能体在干净的上下文中运行，专注于特定任务
- 适用场景：子任务生成大量上下文（超过1000个token）但大部分信息与主任务无关；查找或检索操作在使用前需要过滤
2. 并行化
- 问题：单智能体无法探索足够大的搜索空间
- 方案：主智能体分析查询，生成多个子智能体并行调查不同方面
- 代价：消耗3-10倍token，总执行时间更长
- 优势：更全面的结果，并非速度提升
3. 专业化
三种需要专业化的信号： - 工具集：工具超过20个时，智能体难以选择正确工具 - 系统提示：不同任务需要冲突的角色/约束（如同理心与严谨性） - 领域知识：某些任务需要大量专业背景知识
何时该使用多智能体
- 接近上下文极限：频繁使用大量上下文且性能下降
- 工具过多：超过15-20个工具
- 可并行化的子任务
分解原则：以上下文为中心
- 错误做法（以问题为中心）：按工作类型划分（规划、实现、测试、审查），导致"传话游戏"，协调开销大于实际工作
- 正确做法（以上下文为中心）：按上下文边界划分，处理某特性也应处理其测试
有效分解边界：独立研究路径、独立组件和清晰接口、黑盒验证 有问题分解边界：同一工作的关联阶段、紧密耦合组件、需要共享状态的工作
验证子代理模式
- 定义：专门测试或验证主代理工作的子代理
- 成功原因：验证仅需极少的上下文信息传递，可以对系统进行黑盒测试
- 故障模式：验证器未进行全面测试就标记通过
- 缓解策略：明确要求"运行完整测试套件"，测试多种场景和极端情况，尝试应该失败的输入
建议
从最简单有效的方法入手，只有当证据支持时才增加复杂性。