多智能体系统：规模化时消融的潜力
基于大语言模型的多智能体系统的承诺看起来很有吸引力：几个LLM智能体可以分担一个大任务，互相商量，共同找到解决方案。然而，实践显示的是反效果：接入协作的智能体越多，系统就越不稳定。直觉上，问题似乎出在协调上，但一组研究人员在arXiv上的一篇立场文章中提出，应该更深入地看待这个问题。
许多故障的根源在于智能体如何访问共享状态。每个智能体都在共享存储中读写数据——笔记、结果、事实版本。当访问次数增多时，就会出现经典的数据竞争。如果这只是一个普通的多线程程序，工程师们会立刻怀疑同步问题。但由于系统参与者看起来“很智能”，他们的错误常常被归咎于误解，而实际上，这是并行访问共享资源的典型行为。
漫长的“思考”——危险加倍
LLM智能体的特性增加了额外的复杂性。模型的推理过程需要相当长的时间，而在这整个过程中，智能体处理的是它在请求时看到的那个状态快照。当模型在“思考”时，其他智能体并没有闲着：它们在更新共享数据。带着准备好的解决方案返回时，智能体可能依赖的是一个过时的世界图景。
随着智能体数量的增加，这种漫长的思考窗口也越来越多，随之而来的是各种异常概率的上升。一个智能体没有注意到子任务已被同事完成，开始重复工作。两个智能体试图写入最终结果，后一次的写入毫无预警地覆盖了前一次。有人在另一个智能体还没完成数据更新时读取了数据，得到了不一致的中间版本。这一切看起来像混乱，但实际上遵循着数据库理论中已知的规律——过时读取、丢失更新和状态完整性破坏。
通信故障也只是表象
为什么诊断这么容易出错？以协调失败为例。智能体明确分配了角色，看似已经协调好了行动。但如果共享的事实库在不断变化，一个智能体可能会基于同事已经改写过的状态来行动。从外部看，这像是计划不一致或对指令理解不佳。然而，根本原因不是协调薄弱，而是缺乏对并发数据访问的控制。
通信也是如此。消息本身可能被完美地构造并准时送达。但如果接收方开始处理它时，共享数据已经改变，消息的含义就会被扭曲。这类故障极难复现：它们依赖于精确的时序。当智能体很少时，问题几乎不会显现，但随着规模化，重叠操作的数量增加，错误开始以惊人的频率出现。
并发控制——是基石，而非补丁
研究人员提出的解决方案在于将数据库领域经过验证的方法移植到多智能体系统的架构中。与其依赖LLM以某种方式“达成一致”，平台应该显式地管理并发访问。这实际上意味着三个工作方向：
- 冲突检测。 系统跟踪智能体同时尝试修改相同数据的行为，并在冲突导致结果损坏之前加以阻止。
- 隔离保证。 每个智能体必须处理一个完整的状态快照，或者拥有不允许读取未完成写入的机制。
- 结构化资源访问。 不再直接访问共享上下文，而是使用显式接口：锁、操作版本、写入队列或原子更新。
作者强调，并发控制不能在系统已经开始出现故障后事后添加。这必须是一个“第二层”级别的架构决策，所有其他设计都以此为基础。如果先设计好共享状态的处理规则，然后再在其上构建智能体协调，许多可靠性问题根本不会有机会出现。
结论
基于LLM的多智能体系统拥有巨大潜力，但它们的脆弱性不在于单个模型的能力不足，而在于我们试图让多个并行执行者在一个不断变化的状态上工作，却缺乏基本的保护机制。承认数据竞争是故障的主要来源后，开发者就能应用早已为人熟知的解决方案——隔离、冲突检测和访问排序。这可能不如改进提示词那样引人注目，但正是这种方法能让多智能体系统随着参与者数量的增长而保持可靠。
