多 Agent 协作一致性

这道题问的是多[[Agent]]并行异步协作时，怎么保证系统不崩、结果不乱。说白了就是一群AI程序各干各的，有的快有的慢，还可能挂掉，最终输出还得一致。我理解核心就两个问题：一是共享状态别抢坏，二是任务流程别走偏。

先说状态管理。最直接的办法是集中式状态服务，比如用Redis存全局状态，Agent更新时带版本号或乐观锁。但这里有个边界，如果Agent数量少、状态简单，集中式够用；一旦超过几十个Agent，或者状态频繁修改，Redis就成瓶颈了。这时候我更倾向事件溯源，把所有操作记成不可变事件流，需要的时候回放重建状态。代价是存储和查询开销大，适合审计需求强的场景，比如金融订单处理。真正落地往往是两者结合：日常用Redis查快照，审计或回滚时翻事件日志。

再一个重点是任务编排。当Agent之间有依赖关系，比如A先写数据库，B再发通知，我会用工作流引擎，像LangGraph或Temporal，显式定义DAG，控制执行顺序。但要是事务跨多个Agent，比如退款流程要扣库存、改订单状态、调用支付网关，我会用Saga模式，每个步骤配补偿操作，失败时反向回滚。举个例子，电商促销时多Agent并行处理订单，一个负责价格计算，一个负责库存扣减，一个负责优惠券核销。如果价格算错了，库存已经扣了，优惠券也用了，Saga就会依次触发补偿：释放库存、退回优惠券。这个模式的前提是每个操作都能补偿，有些操作比如发送短信无法撤销，就得靠最终一致性加人工兜底。

结果对齐是另一个容易翻车的地方。多个Agent对同一任务输出不同答案怎么办？我会做两层：第一层，强制输出Schema，比如JSON格式，这样容易聚合比对；第二层，对关键结果用投票或仲裁，比如三个Agent各自回答，取多数一致，不一致时让一个专门Agent做LLM仲裁。还有个技巧是反思验证，让一个Agent检查另一个的输出，发现矛盾就触发重试。不过这套东西计算成本高，我只在高风险场景用，比如风控合同审核，错了可能赔钱；日常问答就不需要。

最后是容错。超时重试必须带指数退避，不然一个Agent卡住会级联阻塞。再配合熔断，如果某个Agent连续失败率超过阈值，直接切到备用策略，比如降级为人工处理。上线前我会特别关注健康检查和隔离，心跳断了马上摘掉，避免拖死整个系统。

不过，这些机制组合起来有个隐含前提，Agent的行为是可预测的。如果Agent用了LLM，输出天然随机，那上述所有一致性保证都可能被绕过去。所以我会把一致性看成概率性的，靠冗余和校验逼近可靠，而不是追求绝对一致。

所以整体上，我会把多Agent系统看成分布式系统的一个特例，优先用成熟方案，比如Temporal做编排、事件溯源做状态、投票做对齐，然后根据业务风险调整冗余度。