面试题 · Agent
搜索「并行」匹配到口述回答，相关段落已展开。查看匹配内容 ↓
在多Agent协作系统中，多个Agent可能并行或异步执行任务。请阐述为确保系统稳定性及最终结果一致性可采取的关键机制和技术手段。
多Agent并行/异步执行面临三大问题：竞态条件（同时修改共享状态）、部分失败（部分Agent成功部分失败）、结果不一致（各Agent对任务理解偏差）。
1. 状态管理与一致性
2. 任务编排与协调
学习内容与项目面试，在同一条路上。
4. 结果对齐
可提及其函数计算+EventBridge的异步事件驱动架构，或PAI-灵积平台的Agent调度能力。
建议系统学习该知识点
场景切入
假设你负责一个电商订单处理系统，多个Agent同时处理退款、发货和库存扣减，结果订单状态乱了。你会怎么设计机制来保证最终结果是一致的？
层层追问
多Agent协作时，你怎么保证它们看到的状态是一样的？……如果有的Agent执行失败了呢？……那多个Agent对同一任务输出不一致怎么办？
直球架构
在多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做编排、事件溯源做状态、投票做对齐，然后根据业务风险调整冗余度。