智能体协同的严肃性：从演示到生产之间那道鸿沟
这一年，多智能体（multi-agent）成了最热的关键词之一。一个"编排者"派任务，一群"执行者"各司其职，彼此发消息、传结果、来回若干轮，最后交出一份像模像样的成果。演示视频里一切行云流水，仿佛把几个大模型串在一起，就自动获得了分工与协作的能力。
但把任何一个 demo 从笔记本挪进生产环境，几乎立刻会撞上同一堵墙：智能体协同，在工程意义上远没有演示里那么牢靠。它天然是"非确定性"“难以观测"“无法回滚"的结合体。这篇不谈怎么搭一个花哨的编排框架，只谈那些被演示掩盖的严肃问题。
第一个问题是状态。多个智能体协同的前提，是它们共享一份对世界的理解。可大模型是无状态的，每一条消息都从零开始推理，唯一的"记忆"就是上下文窗口里堆着的历史。于是协同的"共享状态"退化成了"共享上下文”。这会引出两个麻烦：一是上下文会膨胀，每多一个智能体、多一轮对话，token 就多一层，最终要么截断，要么超限，而截断发生在哪一行、丢的是哪一段，完全不可控；二是上下文会漂移，不同智能体对同一事实的表述可能相互矛盾，却没有一个机制说"谁的记录才是对的”。分布式系统里那句老话——状态必须被显式管理，否则它就是隐式 bug——在这里完全适用，只是换了个更隐蔽的形式。
第二个问题是通信。我们倾向于把智能体之间的消息想象成"可靠的函数调用"，但它们本质上是"概率性地生成文本"。这意味着：消息可能被误解，可能被截断，可能被重复，甚至可能根本没有被对方"读到"——只是语义上相似。工程上默默依赖的那些假设，比如"发出去就送达"“收到就理解"“顺序一定一致”，在文本信道里统统不成立。没有明确的协议、没有消息格式的强约束、没有反复确认的握手，一堆智能体协作得越久，产生的歧义就越多，最后的产出就越不可托付。
第三是失败与恢复。传统系统崩溃了，可以重启、可以回滚、可以重放日志。智能体协同几乎没有这些安全的退路：一次推理没有"确定性重放”，同一输入两次跑，结果可能不同；一个环节的失败也不会留下干净的日志，只留下一串语义模糊的对话记录。更糟的是错误会累积——一个智能体基于另一个智能体"大概可能是"的输出继续推理，错误就这样被层层放大，直到最后交付一个看起来合理、实则全盘皆错的结果。这种"看起来对"的失败，比"明显错"的失败危险得多，因为它几乎无法被下游发现。
第四是可观测性与审计。想要弄清楚"这个结论是怎么来的"，传统系统靠日志、链路追踪、血缘分析。而智能体协同里，一个决策背后是几十轮、可能跨多个模型的对话，没有标准的 trace 格式，没有统一的采样，没有可复现的逐步记录。当合规、当安全、当责任归属需要一份"确凿的证据链"时，你拿不出任何东西。这在严肃场景里是致命的：一个工具链可能跑得堪称完美，却因为无法证明"它为什么这么做"，而永远上不了线。
第五是安全与约束。把多个智能体连起来，等于是把多个"不可控的推理入口"缝合在一起。权限、凭证、外部工具的调用，在单智能体里尚可层层把关，一旦进入协同，信任边界就变得模糊：一个智能体拿到的中间结果，会不会被另一个"越权"使用？一条来自协同者的消息，会不会被当成可信指令而触发危险操作？没有严格的权限下沉、没有输入输出校验、没有护栏，协同就越发像一场失控的接龙，而不是可控的流水线。
那么，严肃的协同长什么样？我倾向认为，答案不是"让智能体更自由"，恰恰相反，是"给它更多约束"。把共享状态显式地建模成结构化的数据，而不是任其在上下文里漂移；把消息定义成强类型的协议，而不是自由文本；给每个环节加确定性的快照与显式的确认点；把整个流程当作一个可观测、可回放、可审计的事件流来管理，而不是一段黑盒对话。智能体唯一该自由发挥的，是"做什么"的推理，而不是"怎么协作"的机制。
多智能体的价值是真实的：它能拆解复杂任务、并行推进、各展所长。但它的工程代价同样真实：它把分布式系统里所有经典难题，用大模型的方式重新演绎了一遍——一致性、可观测性、失败恢复、安全边界，一个都没少。承认这一点不是泼冷水，而是让协同真正可用的开始。演示负责让人心动，工程负责让人放心。在把多个智能体交给生产之前，先想清楚这两件事，远比急着把它们串起来重要得多。