七个AI代理从未互相发消息：直接通信在真实任务中崩盘

七个AI代理从未互相发消息：直接通信在真实任务中崩盘

七个AI代理在同一领域运行，却从未互相发送过一条消息。原本的协调器分派任务、代理互相调用和共享对话方案在演示中可行，但真实工作一展开就彻底失效。最终稳定的做法是每个代理只向一个共享记录写入声明，没有读取其他代理推理，也没有直接调用。

真实工作负载让代理直接通信彻底失效

演示阶段一切看起来都很理想。开发者先搭建了一个协调器，负责把任务拆解后交给不同专长的代理。代理之间可以互相调用，也能把输出追加到一个共享对话记录里。这种设计在小规模测试中运行顺畅，协调器能按计划把工作传递下去，代理也似乎在“对话”。

一旦切换到真实工作负载，情况立刻变了。代理不再发送消息，协调器也无法有效分派。真实任务的复杂度、长度和不确定性远超演示，代理生成的输出变得冗长且充满分支，协调器难以判断下一个该调用谁。调用链条一旦出现一次判断失误，后续代理就拿不到正确上下文，整个流程卡死。

更麻烦的是，代理之间的直接调用引入了大量状态依赖。一个代理的内部推理会影响下一个代理的决策，但真实场景下这些推理往往包含噪声或错误假设。调用机制没有足够容错能力，导致错误快速放大。开发者观察到，系统在演示中能完成简单流程，但在实际项目里，代理干脆停止了互相通信，协调器也形同虚设。

这种失效不是个别案例。真实工作负载带来的上下文膨胀、时序不一致和错误传播，让原本优雅的点对点通信变得不可靠。开发者最终放弃了让代理“说话”的想法，转向更简单的机制。这也说明，多代理系统在实验室和生产环境之间的差距，比想象中大得多。

（本节约420字）

共享记录成为唯一可靠的协作通道

替代方案简单到近乎无聊：每个代理只往一个共享记录里写入声明，除此之外不做任何事。代理不读取其他代理的推理过程，也不能直接调用对方。共享记录成了唯一的信息通道，所有输出都以声明形式追加进去。

这种设计的核心是解耦。每个代理只对当前任务和共享记录的最终状态负责，不需要维护与其他代理的会话状态。写入操作是单向的，避免了循环依赖和死锁。记录本身像一张公开的黑板，代理往上贴自己的结论，后续代理根据最新贴的内容决定下一步。

稳定性来自简化。去掉直接通信后，系统不再需要处理复杂的消息路由、格式转换和冲突解决。错误被限制在单个代理的声明里，不会通过调用链传染。开发者发现，这种“只写不读”的模式虽然看起来信息不充分，却在实际运行中比完整对话机制更持久。

共享记录还天然支持审计。所有声明按时间顺序排列，事后可以清楚看到每个代理贡献了什么。这在调试和合规场景中特别有用。相比之下，原来的多代理对话记录往往杂乱无章，难以追踪责任。

当然，这种方案也牺牲了一定程度的智能协作。代理无法基于其他代理的中间推理做动态调整，但换来了可预测性和可靠性。在当前阶段，稳定性显然比所谓的“智能涌现”更重要。

（本节约380字）

CrewAI和AutoGen的通信设计存在相同瓶颈

信号中暴露的问题在主流多代理框架里普遍存在。CrewAI和AutoGen都内置了协调器和代理间通信机制，允许代理互相调用或通过共享消息总线传递信息。演示效果通常很好，但放到真实复杂任务上，同样会出现通信中断或效率低下。

CrewAI强调角色分工和任务流水线，代理通过预定义的“船员”关系进行协作。但当任务分支增多、上下文长度超出模型窗口时，协调器难以维持连贯的调用序列。AutoGen则更侧重对话式交互，代理可以自由生成消息并回复对方。这在简单聊天场景中表现突出，可一旦涉及长链条推理和外部工具调用，对话质量就迅速下降。

两者共同的瓶颈在于对直接通信的依赖。框架假设代理能可靠地理解彼此输出、维护共享状态并做出合理调用。但实际中，大语言模型的输出具有随机性，微小的格式偏差或语义漂移就会导致后续代理误解。框架本身提供的错误处理和重试机制又不够强大，无法应对真实工作负载下的累积误差。

开发者在信号中遇到的“演示成功、生产失败”现象，几乎是这些框架用户的共同经历。许多团队在初期搭建多代理系统时，都选择了类似的协调器加直接调用方案，结果在上线后不得不大幅简化架构。这表明问题不是某个框架的实现缺陷，而是当前多代理通信范式本身的局限。

（本节约410字）

标准化协议或中间件可能绕过直接调用

共享记录方案虽然稳定，但本质上是一种退化协作。要想在保持解耦的同时提升智能程度，标准化协议或专用中间件可能是可行路径。

协议可以定义代理之间交换信息的统一格式，包括声明类型、置信度、依赖关系和版本控制。这样代理无需直接调用，只需向中间件发布结构化事件，中间件负责路由和一致性检查。相比当前完全不通信的记录方式，协议能让代理间接感知其他参与者的状态，而不会陷入点对点耦合。

中间件还可以增加调解层。它可以对代理输出进行验证、去噪和摘要，只把精炼后的信息传递给下游。这能显著降低噪声传播，同时保留必要的上下文。一些研究方向已经开始探索类似的事件总线或声明式协作语言，目标是让多代理系统像微服务一样，通过明确契约实现松耦合协作。

与纯共享记录方案相比，协议和中间件增加了可扩展性。记录只适合少量代理和简单任务，当代理数量上升到几十个、任务类型多样时，结构化路由和自动调解就变得必要。不过这些方案目前仍处于早期，缺乏行业标准，落地还需要解决性能开销和模型适配问题。

（本节约350字）

中国企业可在中间件层抓住应用机会

多代理协作的通信难题对中国开发者与企业而言，既是挑战也是切入点。国内企业在落地大模型应用时，经常面临复杂业务流程和多角色协同需求，现有框架的通信瓶颈直接制约了规模化部署。

中间件层是一个相对空白但战略意义明显的领域。企业可以开发针对中文语境、特定行业知识的协议适配器，或提供可视化协调工具，帮助用户快速配置代理间的声明交换规则。相比直接竞争基础模型，中间件的技术门槛适中，更容易结合本土数据和业务场景形成差异化优势。

一些大型互联网公司已经在内部尝试构建自己的多代理平台。如果能在通信层实现标准化封装，并开放给中小企业使用，将形成明显的生态带动效应。创业团队也可以聚焦垂直领域，例如金融风控或智能制造中的多代理协同，开发专属中间件，解决特定场景下的通信可靠性问题。

中国市场对落地稳定性的要求高于前沿探索，这与信号中“简单记录胜过复杂对话”的结论高度吻合。抓住中间件机会，既能解决真实痛点，又能避开基础模型的激烈竞争，形成中层基础设施优势。

（本节约340字）

简单记录方案的边界仍未完全明确

尽管共享记录在当前案例中表现稳定，但它的适用边界仍不清楚。信号没有说明当代理数量进一步增加、任务依赖关系更加复杂时，这种只写不读的模式是否还能维持效率。

在高度动态的环境中，代理可能需要及时获知其他代理的最新状态。纯记录方式依赖代理主动轮询或外部触发，如果记录更新频率高，轮询开销会上升；如果依赖事件通知，又会重新引入一定的耦合。

另外，记录本身的内容组织也缺乏规范。当前方案只是简单追加声明，没有提及如何处理冲突声明、如何做版本控制、如何为不同代理提供差异化视图。这些问题在小规模时不明显，一旦系统承担关键业务，就可能成为新的瓶颈。

信号也未讨论长期维护性。随着时间推移，共享记录会不断膨胀，如何压缩历史、提取关键事实、为新代理提供启动上下文，都是尚未解决的实际问题。对更复杂的多跳推理或需要深度协作的任务，这种简单方案是否足够，仍需更多真实案例验证。

目前能确定的是，在追求稳定性的阶段，简单记录方案是可靠的起点。但要走向更成熟的多代理系统，仍然需要对通信机制进行更系统性的改进。

（本节约360字）

参考来源