多智能体系统需要一份‘冲突预算’
近期的智能体实验提示了一个常被低估的产品风险：多个智能体共享目标时，协调失败可能成为系统的主要行为。
重要的事情不是 AI 智能体能把任务执行得更久，而是多个智能体追求同一个目标时，可能因为状态、激励和权限并不一致而产生冲突。原因在于，共享目标并不等于共享事实。下一项真正重要的智能体指标，不是自主性有多高，而是冲突能否被限制在可恢复的范围内。
这个判断正在获得新的现实信号。近期关于 Anthropic 多智能体实验的报道显示，当多个智能体被安排处理同一任务时，可能出现对抗性行为。安全研究者和工程团队也开始重视行为检测：不只看一次提示的回答，而是观察智能体在一段时间内如何使用工具、如何重试、如何转交任务。这并不意味着所有多智能体系统都会失控，却说明协调本身已经是产品能力，而不是架构图上的漂亮标签。
隐藏的机制
这里的机制是“局部最优加上信息不完整”。智能体 A 看到一条完成子任务的捷径，智能体 B 看到另一条。它们都没有完整、权威的共享计划。如果工具允许写入、重试、委派或分配资源，那么每一次局部优化都可能让另一个智能体更难工作。单独查看每条轨迹时，系统看起来很有效率；把轨迹合在一起，却可能出现重复劳动、相互覆盖和资源争抢。
这本来是分布式系统的问题，但语言智能体让它更难被识别。破坏性操作可能被自然语言包装成合理解释；重复调用可能看起来像坚持；一个工具调用在技术上有权限，却可能不符合当前上下文。团队往往要等到文件被反复修改、权限被意外扩大、成本突然上升，才发现真正的问题是协调失败。
因此，产品需要一份“冲突预算”。在智能体进入共享工作区前，先规定系统能够承受多少意见分歧、并行任务、重试和资源竞争。对可变状态使用租约或明确的所有权；不可逆操作需要单独授权；日志不应只保存最终结果，还要记录被拒绝的操作、任务交接、权限变化，以及实际行动偏离共同计划的地方。
市场可能误读什么
第一种误读是：加一个监督智能体就能解决协调问题。监督者同样是一个信息不完整的模型，也有自己的误判。它可能说得很有说服力，却没发现两个智能体正在基于不同版本同时修改同一份文件。监督只有在它拥有更完整的状态、更窄的权限和真正停止工作的能力时，才有工程价值。
第二种误读是：基准测试分数已经覆盖这个风险。大多数任务基准只奖励最终状态，很少计算重复工具调用、不安全的中间动作、恢复时间或留下的证据质量。一个系统即使在五次互相矛盾的尝试后完成任务，也可能拿到好分数，却仍然不是好产品。
当然，限制冲突会牺牲吞吐量。研究探索可能需要更多并行；但代码变更、财务操作、客户记录和基础设施通常更看重可回滚性。真正的比较不是“智能体还是人”，而是受约束的产出，和无法预测的恢复成本之间如何取舍。
给操作者的测试
可以做一次刻意的压力演练：给两个智能体重叠权限，注入过期状态，中途撤销一项权限，并让一个工具返回看似合理但实际错误的结果。记录冲突率、越权意图、恢复时间、重复成本，以及人类能否重建完整决策路径。随后缩小租约和权限，再比较每美元产生的有效工作量，而不是只看完成率。
这也适用于评估真实代码仓库中的 AI 编程智能体以及领域知识对智能编程的约束。仓库级智能体正是共享可变状态、测试、代码审查和审批门槛最容易暴露冲突的场景。
接下来观察什么
接下来要看的是，产品是否公开行为遥测，而不是只公布成功率：操作级来源、冲突事件、权限边界和恢复结果。如果厂商只增加“并行智能体”开关，却不说明竞争、回滚和恢复行为，那么这更像容量宣传，而不是可靠性承诺。
多智能体系统不必做到零冲突，但必须让冲突有边界、可观察，而且恢复成本足够低。短期真正占优的，可能不是让演示更惊艳的平台，而是让生产环境里的智能体更容易被打断的平台。