多智能体系统缺乏真正的通信基底
摘要
这篇文章讨论了多智能体系统缺乏生产级通信层的问题，批评了当前解决方案如Kafka、Redis和智能体框架的不足，并寻求社区对替代方案的输入。
如果你在生产环境中运行多智能体系统，你可能已经遇到了这堵墙：没有专门为智能体工作负载设计的生产级通信层。大多数团队最终拼凑不同的解决方案：- Kafka + Redis + 自定义粘合代码：功能强大，但带来巨大的运营开销。对于缺乏专门平台或基础设施团队的AI团队来说，设置和管理Kafka集群与Redis是不切实际的。- 自研队列或数据库作为消息总线：低保真度、无重放能力、高维护性——它们很快因技术债务变成没人愿意维护的脆弱系统。- 智能体框架原语（LangGraph、CrewAI、AutoGen）：它们导致框架锁定并无法扩展。依赖整体共享状态的框架强制在每个步骤传递完整上下文。对于长时间运行的任务或跨越数千轮的对话功能，这会导致状态爆炸和延迟增加。所有这些方法都存在相同的严重缺陷：零开箱即用的可重放性、缺失审计跟踪，以及没有内置的语义搜索或对智能体决策的总结。虽然你可以使用第三方可观测性工具如Langfuse或Opik来添加这些功能，但这会引入另一个需要维护的脱节系统。很好奇其他人是如何处理这个问题的：在生产环境中，你使用什么进行智能体间通信？当事情出错时，你如何调试状态和消息流？
相似文章
多智能体系统是运行时问题，而非提示工程问题
文章认为多智能体系统需要运行时基础设施层，而非更好的提示，引用了 MiniMax、OpenAI、Google 和 Anthropic 的发布。文章强调了工作者与验证者角色的分离以及多智能体设置的开销成本。
多智能体系统是否已准备好投入生产？
一位开发者分享了对多智能体系统的挫败感，指出它们比单智能体系统复杂得多，且结果往往更差，并寻求关于协调和减少复杂性的工具建议。
停止构建多智能体系统
一篇观点文章认为，向系统中添加更多智能体通常是解决可靠性问题的错误方法，而一个精心设计的、具有更好上下文、工具、护栏和评估的单一智能体通常更优。
子代理并非唯一方式
本文质疑多智能体系统中默认的子代理编排模式，主张通过共享消息板进行去中心化协调。它介绍了 Blueprint Bulletins 这一功能，允许智能体在共享板上发布自动过期笔记，以实现无需中央编排器的环境协调。
多智能体系统与单智能体系统
本文指出，大多数所谓的“智能体化”系统实际上只是配备工具的单智能体，并强调了多智能体架构带来的高昂成本和复杂性。文章梳理了三种有效的多智能体模式——编排者-工作者、流水线以及点对点模式，并提供了判断何时采用多智能体而非单智能体的标准。