大多数所谓的“多智能体编排”不过是一个智能体在调用函数。停止将函数调用重新包装为智能体。
摘要
本文批评了“多智能体编排”这一术语的过度使用，指出许多实现实际上仅仅是单一智能体使用函数调用，而非真正的分布式系统。文章强调了一些经过生产环境验证的实用模式，如顺序流水线和人机协作工作流，作为复杂但低效架构的替代方案。
每周都有新框架出现：“群体智能体网格！”“集群编排！”“多智能体监督模式！”但当你查看实际在生产环境中运行的系统时，你会发现：它只是一个智能体，其工具用于调用另一个具有不同系统提示的实例。这并非多智能体编排。这只是加了营销包装的函数调用。我在生产环境中看到的成功模式包括：
- 带有检查点的顺序流水线（执行步骤 1，审核，执行步骤 2，审核）
- 路由器 + 专家（选择合适的处理器，让其运行，返回结果）
- 涉及真实金钱成本的任何环节采用人机协作
除此之外的一切，都是架构宇航员在兜售复杂性。在这里，真正有效的模式是什么，与那些在图表中看起来漂亮的模式有何不同？
相似文章
多智能体系统与单智能体系统
本文指出，大多数所谓的“智能体化”系统实际上只是配备工具的单智能体，并强调了多智能体架构带来的高昂成本和复杂性。文章梳理了三种有效的多智能体模式——编排者-工作者、流水线以及点对点模式，并提供了判断何时采用多智能体而非单智能体的标准。
多代理框架的另一种选择：将编排放入文件夹结构中
提出了一种传统多代理框架的替代方案，通过使用文件夹结构来管理编排，简化协调并降低复杂性。
是否真的有人能良好地编排多智能体工作流，还是我们都在拼凑应付？
一篇反思性文章，质疑是否有人成功实现了多智能体AI工作流编排，而没有诉诸临时解决方案。
你不需要多智能体架构
一篇文章指出多智能体架构常被过度使用，根据任务并行性和协调需求提供何时使用单智能体与多智能体架构的指南。
子代理并非唯一方式
本文质疑多智能体系统中默认的子代理编排模式，主张通过共享消息板进行去中心化协调。它介绍了 Blueprint Bulletins 这一功能，允许智能体在共享板上发布自动过期笔记，以实现无需中央编排器的环境协调。