你不需要多智能体架构
摘要
一篇文章指出多智能体架构常被过度使用，根据任务并行性和协调需求提供何时使用单智能体与多智能体架构的指南。
看到很多人默认使用多智能体，因为听起来更高级。实际上，这是一个可靠性/并行性的权衡，而不是能力升级。快速分析谁实际需要什么：
使用单智能体，如果：
- 你的工作流是一系列依赖步骤（研究 → 决定 → 下一步）
- 你正在处理简单到中等复杂度的任务
- 速度和简单性比规模更重要
- 你没有基础设施来干净地处理共享内存/编排
使用多智能体，如果：
- 任务可以自然地并行化（一个智能体研究，同时另一个审计，再另一个编码）
- 不同的子任务需要真正不同的“心智模型”（一个广泛的研究者与一个狭窄的合成器在同一个智能体内难以切换上下文）
- 你有一个编排器角色来根据需要委托、监控和启动智能体
- 你已经让共享内存/同步正常运行了，而不需要多智能体，多智能体只会增加协调开销而毫无益处
另外，多智能体需要像 gitagent（开源）这样的工具才能发挥最佳作用
经验法则：单个强大智能体用于多步骤的顺序工作。多智能体用于并行、可分离的工作。如果你的任务不能自然地分离，更多的智能体只意味着更大的调试面，而不是更强的能力。
来源：Google Research — > Towards a Science of Scaling Agent Systems: When and Why Agent Systems Work
相似文章
多智能体系统与单智能体系统
本文指出，大多数所谓的“智能体化”系统实际上只是配备工具的单智能体，并强调了多智能体架构带来的高昂成本和复杂性。文章梳理了三种有效的多智能体模式——编排者-工作者、流水线以及点对点模式，并提供了判断何时采用多智能体而非单智能体的标准。
停止构建多智能体系统
一篇观点文章认为，向系统中添加更多智能体通常是解决可靠性问题的错误方法，而一个精心设计的、具有更好上下文、工具、护栏和评估的单一智能体通常更优。
大多数所谓的“多智能体编排”不过是一个智能体在调用函数。停止将函数调用重新包装为智能体。
本文批评了“多智能体编排”这一术语的过度使用，指出许多实现实际上仅仅是单一智能体使用函数调用，而非真正的分布式系统。文章强调了一些经过生产环境验证的实用模式，如顺序流水线和人机协作工作流，作为复杂但低效架构的替代方案。
@shl: 一个智能体就够了
文章认为，单一的AI智能体架构足以应对复杂任务，呼应了'一个模型就够了'的范式。
多智能体系统是运行时问题，而非提示工程问题
文章认为多智能体系统需要运行时基础设施层，而非更好的提示，引用了 MiniMax、OpenAI、Google 和 Anthropic 的发布。文章强调了工作者与验证者角色的分离以及多智能体设置的开销成本。