某企业的报销审批智能体在上线后第三周遇到一次棘手故障。用户提交一笔差旅报销，智能体按预设流程依次调用三个内部接口：先调费用录入接口创建报销单，返回单号；再调预算扣减接口冻结对应部门预算；最后调审批流引擎提交审批。前两步都成功了，第三步却返回错误------该部门审批流未配置负责人。报销单已经建好，预算也被冻结，审批却没有推进，业务数据停在半途。用户以为提交失败，刷新后重新提交，结果又生成了一笔重复的报销单，预算被冻结了两次。
团队通常会把问题归到接口可用性上，要求对审批流引擎加重试逻辑。但重试只能解决临时网络抖动这类瞬时故障，如果失败原因是业务配置缺失（部门负责人未设置），重试多少次都不会成功。真正的问题不在于单个接口能不能调通，而在于多个工具串联执行时缺少事务边界和补偿机制------前序步骤已经写入了数据，后续步骤失败后，系统没有能力回退已经产生的副作用。
拆开来看，这类故障通常有三层技术原因。一类是工具调用之间没有事务边界定义。智能体在编排多个工具时，每个工具调用都是独立执行、独立提交的，系统没有把创建报销单、冻结预算、提交审批这三个操作绑定为一个业务事务。缺少事务边界意味着任何一个环节失败，前面已提交的操作不会自动触发补偿，业务系统之间出现不一致。在异构业务系统、第三方接口和无法共享统一事务管理器的场景中，通常难以采用数据库式两阶段提交，因此更常使用事务状态机和补偿式编排。补偿动作可能是作废、解冻、冲正或撤销，目标是把业务带到一个可接受的一致性终点，不一定完全恢复到调用前的原始状态。
另一类是失败后缺少补偿路径。工具调用失败时，系统只返回一个错误码给用户，没有触发已执行操作的逆向补偿。理想情况下，审批流提交失败后应该自动执行解冻预算和作废报销单的补偿操作，把业务系统恢复到可接受状态。但补偿路径的工程实现不只是写几行逆向逻辑------每个补偿动作本身也需要幂等键和前置状态检查，否则网络重试或补偿器重启可能导致重复解冻、重复作废，在修复一处不一致的同时制造新的不一致。
还有一类是重复提交缺少幂等控制。用户遇到失败后重新提交，系统没有识别这是同一个请求的重复发起，而是当作全新请求处理，于是又创建了一笔报销单、又冻结了一次预算。幂等控制不只在接口层做，还要在业务编排层做------但幂等键不应该由用户标识和报销内容拼接而来，因为同一个人在不同时间提交金额相同的报销是合法的不同请求，拼接键会误判为重复。更合理的做法是用客户端请求标识、业务申请单号或服务端下发的提交令牌作为幂等键，同时保存请求载荷摘要，重复请求直接返回当前事务状态而非重新执行。
本文基于青山不语AI工作室在部分项目中的多工具编排治理实践，将这套处理框架概括为跨工具事务编排与补偿机制。需要说明，这里的补偿是业务补偿，不是数据库事务意义上的原子回滚。其机制分为六个环节，分别解决事务定义、前置校验、检查点记录、状态机流转、失败补偿和重复防护的问题。
事务边界定义解决哪些操作属于同一笔业务的问题。开发团队在编排工具调用时，需要明确哪些工具调用构成一个业务事务。事务中某一步失败后，系统根据检查点和业务依赖关系执行补偿。多数情况下补偿顺序与正向操作相反，但最终顺序应由业务依赖明确规定。补偿可能是作废单据、解冻预算、冲正流水或撤销操作，目标不一定是完全恢复原状态，而是把业务带到一个业务侧可接受的一致性终点。事务边界以业务语义为准，不是以技术调用顺序为准。报销场景中，创建报销单、冻结预算、提交审批属于同一事务；发送通知的步骤如果失败，不应触发前三个操作补偿，通知可以异步重试或降级为站内信。事务边界的划分由业务团队确认，开发团队负责在编排层实现。
执行前预检解决能不能在执行前就拦住注定失败的请求的问题。事务开始执行前，先检查所有前置条件：审批流是否配置了负责人、预算余额是否充足、报销类型是否在允许范围内。预检可以调用只读接口查询配置和状态，但不执行任何写入副作用。前置条件不满足时直接返回失败原因，不启动事务执行。需要说明的是，预检不能消除并发竞态------在预检通过到实际写入之间，预算、库存和额度仍可能被其他请求消耗，因此写入环节仍然需要条件更新、预留额度或版本校验来兜底。预检覆盖的范围由业务团队定义，哪些条件属于必须前置检查的硬性条件、哪些可以在执行中处理，需要业务侧确认。
检查点记录解决执行到哪一步、失败在哪一步的问题。事务内每个工具调用执行后，记录检查点信息：调用了哪个工具、执行时间、业务状态变化和补偿所需的最小信息。检查点不只是日志，更是补偿的依据------系统需要知道当前已经产生了哪些副作用，才能在失败时按正确顺序执行补偿。检查点存储在独立于业务系统的事务表中。需要留意的是，检查点记录的参数和返回内容可能包含敏感数据，写入前应做脱敏处理，只保留补偿和审计所需的最小字段。
事务状态机解决执行过程中状态不清晰的问题。每个事务至少区分六种状态：处理中、已成功、已失败、补偿中、补偿失败和需人工处理。状态流转由编排器驱动，不依赖模型判断。对于异步接口------比如审批流引擎接受请求后异步处理，调用返回成功不代表业务真的生效------需要通过回调通知、主动查询或定时对账来确认最终结果，在此之前事务停留在处理中状态，不做终态判定。状态机的设计使得任何一次重试、补偿或人工介入都能基于明确的当前状态决策，而不是靠日志猜测。
失败补偿解决已经写入的数据怎么回退的问题。事务中任何一步失败后，系统根据检查点和业务依赖关系执行补偿。多数情况下补偿顺序与正向操作相反，但最终顺序应由业务依赖明确规定。创建报销单的补偿是作废单据，冻结预算的补偿是解冻。每个补偿动作必须携带自己的幂等键和前置状态检查：补偿动作执行前先确认当前事务确实处于需要补偿的状态，补偿动作执行后再更新事务状态，避免重复解冻、重复作废或重复冲正。补偿操作本身也可能失败，因此需要重试机制和人工兜底：补偿重试若干次仍失败时，事务进入需人工处理状态，通知运维人员手动处理，同时冻结该事务关联的所有后续操作。补偿逻辑由开发团队按业务规则编写，补偿动作的业务语义（作废还是删除、解冻还是退还、冲正还是撤销）由业务团队确认。
幂等控制解决用户重复提交会不会产生多笔的问题。事务提交时携带客户端请求标识、业务申请单号或服务端下发的提交令牌作为幂等键，同时保存请求载荷摘要。收到重复幂等键时，同时比对请求载荷摘要。键和内容均一致时返回当前事务状态；键相同但内容不同时，拒绝执行并返回幂等键冲突。幂等键的设计由业务团队定义，核心原则是同一业务请求对应一个固定且不会碰撞的键，不同请求之间不串用。用报销内容拼接做幂等键的做法存在风险------同一个人在不同时间提交金额相同的报销是合法的不同请求，不应被幂等逻辑误判为重复。
这套机制的责任边界需要划清。业务团队负责定义什么属于同一业务请求，以及事务边界划分、预检条件清单、补偿动作的业务语义；开发团队负责幂等键生成、存储、载荷摘要比对和状态返回机制，以及事务编排、状态机流转、检查点存储和补偿执行。模型只负责理解用户意图和填充工具参数，事务的执行顺序、状态流转、幂等控制和补偿必须由确定性工作流或事务编排器控制，不能交给模型自行决定。工具接口本身的可用性和数据一致性由各业务系统负责。
多工具串联执行中途失败这个问题，不能只靠接口重试解决，更要看事务边界是否定义、状态机是否清晰、补偿路径是否覆盖、每个补偿动作是否有独立幂等、预检与写入校验是否配合。六个环节缺少任一环节都可能增加跨系统状态不一致和重复执行的风险。补偿操作可能失败、异步接口需要确认、人工兜底需要响应时间，这些限制在设计时就要纳入考量，而不是等故障发生后再补。