多 Agent 协作复杂度

这道题其实是在问一个很核心的工程问题：什么时候应该把一个系统拆成多个独立模块来协作，什么时候一个整体就够了。[[多智能体]]系统，说白了就是让多个大模型[[Agent]]各司其职，通过通信和协调来完成单一Agent搞不定的复杂任务。

我先说优势。最直观的好处是专业分工。一个Agent搞定所有事，就像让一个全科医生做开颅手术，不是不行，但容易出错。多Agent可以把任务拆开，比如一个Agent专门做规划，一个做执行，一个做验证。每个Agent的prompt和工具可以高度定制，效果更好。其次是并行效率，子任务可以同时跑，整体耗时从串行的加法变成并行的最大值。还有就是容错，一个Agent挂了，别的可以顶上去或者降级处理，系统不会完全瘫掉。

举个例子，在客服退款场景里，单Agent要同时理解用户情绪、查订单状态、核对退款政策、生成回复，一个[[幻觉]]就能把整条链路带偏。多Agent就可以拆开：一个专注对话理解，一个专门查数据库，一个调用规则引擎做决策，最后汇总输出。每个Agent只做自己最擅长的事，错误率大大降低。

但多Agent不是银弹，它引入的复杂性才是真正的挑战。

先说通信。Agent之间怎么说话？得定协议，比如用JSON schema定义消息格式，是同步等结果还是异步发出去不管。N个Agent两两通信复杂度是O(N²)，所以得引入消息总线或者分层路由，不然信息会爆炸。

然后是协调。任务谁来做？依赖关系怎么处理？比如一个Agent要等另一个的结果才能继续，如果没调度好就会死锁。这里需要DAG调度或者一个中央协调器来仲裁。

再一个坑是一致性。共享上下文的时候，多个Agent同时读写会冲突，得用事务机制或者最终一致性。更隐蔽的是目标对齐：每个Agent局部最优可能偏离全局目标，比如验证Agent太严格，把所有结果都毙了，导致任务永远完不成。

LLM特有的挑战更头疼。幻觉传播，一个Agent产生了幻觉，通过通信污染其他Agent，错误会像滚雪球一样放大。还有成本，多轮交互的token消耗是指数级增长，上线前必须设计early exit或者缓存策略，不然账单会吓死人。