一家电商企业把订单履约拆给几个子智能体分工处理库存扣减和发货单创建都收敛在同一个履约接口里完成。上线后出现了一个现象一笔订单被发货了两次、库存被扣减了两次客户收到两条相同的发货通知。排查发现两个子智能体都订阅了订单支付成功事件也都拥有调用这个履约接口的权限两边同时收到支付事件后各自调用了一次库存和发货就各发生了两遍。这类多智能体协作中的重复执行在AI Agent开发里并不少见。问题往往不在单个子智能体逻辑写错而在写权限重叠、事件重复投递时系统没在路由、执行权和幂等层面把重复拦下来。单个环节不出错并不代表多个环节拼在一起也不出错。一种常见的误判是以为给每个子智能体写清楚职责就够了。可职责描述往往用自然语言写两个子智能体对谁负责创建发货单的理解可能并不一致写权限一旦重叠同一动作就可能被执行两遍。另一种误判是以为只要最终结果对了就行中间重复几次无所谓。可库存扣减、发货、开票这类动作都带有真实的业务副作用重复一次就意味着多扣一次库存、多发一次货事后补救的成本往往更高。还有一种误判是以为多个子智能体之间会自己协调。可子智能体之间如果没有明确的执行权和仲裁约定往往各自按自己的判断往下走谁先执行、重复了听谁的并没有确定规则。拆开来看这类问题通常有三类原因。一类原因是副作用执行权重叠扣库存、创建发货单这类动作在多个子智能体那里都有写权限边界重叠同一动作就容易被重复触发。另一类原因是缺少动作级幂等与消息去重同一事件被重试投递、同一请求因网络超时被重发时系统没有在真正产生副作用的写入端按订单加动作的粒度做幂等也没有对重复消息去重重复到达就重复执行。还有一类原因是共享状态并发写缺少仲裁多个子智能体对同一份状态并发写入时没有状态机、版本检查或乐观并发控制约束合法状态迁移后写覆盖先写、状态矛盾。这与重复副作用是两个层面的问题。针对这些原因一种实现方式是沿着路由—执行权—状态—幂等—对账的链路治理。起始环节是任务路由与职责边界定义把每类任务和每个业务副作用动作明确归口到确定的子智能体让入口和职责边界不重叠。紧接着是副作用执行权约束扣库存、创建发货单、退款、开票这类真实副作用动作明确由一个组件负责执行其他组件只能请求不能同时拥有同一动作的写权限。再往后是业务状态机与并发控制为关键共享状态定义允许的状态迁移用状态机、版本检查或乐观并发控制约束并发写入解决并发状态冲突。随后是动作级幂等把幂等键绑定到具体业务动作例如订单ID加动作类型加业务阶段或命令ID同一幂等键对应的副作用只允许成功执行一次避免把同一订单的合法后续动作误挡。然后是消息去重消费端记录已处理的事件或命令标识对重复消息做幂等处理不依赖消息只投递一次关键写操作在持久化或业务接口层依据幂等键拒绝重复提交调用方和写入端共同支持幂等。再下来是结果对账执行后对关键资源做核对发现库存、发货、收款状态不一致或动作重复时及时暴露问题。最后是补偿与人工兜底根据业务能力执行取消、冲正、补偿或人工修复不可逆的副作用不假设能自动回退转人工处理。本文基于青山不语AI工作室在部分AI Agent开发项目方案中的实践将这套处理框架概括为多智能体任务路由与冲突仲裁。它要解决的不是让每个子智能体自己更强而是让多个子智能体组合在一起时路由清楚、执行权明确、幂等落到写入端协作起来不互相打架。这里有一道边界需要企业自己拿捏。哪些业务副作用动作必须确定单一执行方、幂等键按什么粒度设计、共享状态的并发控制规则如何设定都要结合企业自身的业务流程和系统现状来确定。服务方提供的是任务路由、执行权约束、并发控制和幂等对账的机制具体到每个动作的职责划分和写入规则需要企业的业务负责人和技术负责人确认。从行业观察来看企业评估AI Agent开发服务时值得多问一句对方交付的多智能体系统有没有把每个业务副作用动作的执行权定义清楚幂等有没有落到真正产生副作用的写入端。我的判断是多智能体协作的价值在于分工而不在于堆数量只有路由清楚、执行权明确、幂等落到写入端多智能体协作才能真正把复杂流程拆稳。