AI 工具调用部分成功怎么处理：结果状态、补偿动作与重试边界

订单履约 Agent 最容易被忽略的一类故障，不是全流程直接失败，而是执行到一半卡住：库存扣减已经生效，物流单也成功创建，偏偏最后给用户发通知的工具没等返回就超时了。这时候要是直接把整轮流程标成失败然后全量重试，很可能重复扣减库存；要是直接标成全流程成功，用户又压根收不到通知。稳妥的处理方式是把每一步工具动作的状态单独存入数据库，再根据这个动作是否可逆、是否自带幂等性、有没有拿到下游的确认回执，来判断该走补偿逻辑还是有限度重试。

为什么“整轮失败”会掩盖部分成功

假设一轮请求包含三个工具：reserve_stock 扣库存、create_shipment 创建运单、send_notice 发送通知。前两个工具已经收到下游确认，第三个请求在网关等待 8 秒后超时。模型或上层编排器看到的只是一个超时信号，但库存服务和物流服务已经完成了动作。

要是重试直接从第一个工具开始跑，第二次扣库存要么直接返回「库存不足」，更糟的情况是用没有幂等保护的旧接口，平白无故多生成一条库存流水。这里先别急着让模型直接「再试一次」，要先把每一步动作的执行事实提前写入工作流的落地记录里。

先把动作状态和工作流状态分开

工作流状态描述这一轮对用户的整体进度，动作状态描述某个工具调用本身。两者不能共用一个枚举，否则 notice=pending 很容易被错误地折叠成整轮失败。

动作状态至少要能区分 prepared、sent、confirmed、rejected、unknown 和 compensated。其中 unknown 很重要：它表示调用方没有拿到确定结果，不等于下游没有执行。

超时之后先查证据，再决定是否重试

就拿发通知这个动作来说，网关超时之后有三种可能性：请求根本没进到通知服务；通知服务已经收到请求但是返回的响应在半路丢了；通知已经成功发出去了，只是回执没能传回调用方。三种情况对应的补救动作完全不一样，不能统一按失败处理。

type ActionState string

const (
    Prepared    ActionState = "prepared"
    Confirmed   ActionState = "confirmed"
    Rejected    ActionState = "rejected"
    Unknown     ActionState = "unknown"
    Compensated ActionState = "compensated"
)

type ActionRecord struct {
    ID             string
    Name           string
    State          ActionState
    IdempotencyKey string
    ProviderRef    string
    Attempt        int
}

当状态是 unknown 时，编排器先用同一个 idempotency_key 查询通知服务的动作记录。查到 provider_ref，就把本地状态补成 confirmed；查到明确拒绝，才进入可重试分支；查询本身也超时，则保持 unknown，交给后台恢复任务，而不是立即从头重放。

补偿、重试和人工介入怎么选

选择后续动作之前可以用三个问题快速分流判断：下游有没有返回确定的结果？这个动作能不能安全重复执行？有没有可接受的反向抵消动作？这套判断逻辑比单纯看HTTP 500或者504状态码要靠谱得多。

• 已确认成功：直接跳过重试步骤；如果后续步骤执行失败，就处理后续动作或者安排对应的反向补偿。
• 明确拒绝：只有参数错误或者临时依赖故障可以安排重试，要是下游直接返回业务拒绝，就直接终止这个动作后续流程。
• 结果未知：先查历史动作记录；查不到就暂时保留未知状态放到恢复队列等待后续处理，不要随便放行重跑。
• 已产生不可逆副作用：优先走人工介入或者补偿队列处理，不要默认自动回滚一定能成功。

举个实际场景：库存扣减已经确认成功、通知动作结果未知的时候，正确的处理方式是先去查询通知服务的发送记录，或者用同一个幂等键再发一次通知；如果通知服务不支持历史记录查询，就把订单标记为「履约完成、通知待确认」，让用户看到真实的进度。绝对不能让模型把「通知状态未知」直接改写成「订单执行失败」。

让模型只负责解释，不负责裁定事实

模型可以根据已经落地的动作记录生成下一步的回复提示，比如告诉用户「订单已经出库，发货通知正在确认中」；但是状态的最终裁定必须由服务端完成。传给模型的上下文要是已经整理好的事实对象，不要直接返回工具抛出的原始异常堆栈：

{
  "workflow_state": "partially_completed",
  "actions": [
    {"name": "reserve_stock", "state": "confirmed", "provider_ref": "inv-7f2"},
    {"name": "create_shipment", "state": "confirmed", "provider_ref": "ship-31a"},
    {"name": "send_notice", "state": "unknown", "attempt": 1}
  ],
  "next_allowed": ["query_notice", "mark_pending", "manual_review"]
}

这样模型的可选动作被限制在 next_allowed 中，不能凭空发起第二次扣库存，也不能把未知动作说成已完成。服务端收到模型建议后仍要再次核对动作状态、权限和幂等键。

上线前用这些断言验收恢复链

测试用例不要只覆盖「所有工具调用都成功」的理想场景。至少要准备下面这几类样例，同时保存好动作日志、幂等键和下游返回凭证的脱敏版本：

回归测试还应验证恢复任务的并发行为：同一个 action_id 同时被两个 worker 取到时，只有一个能推进状态，其余任务必须重新读取最新记录后退出。恢复成功后再检查用户页面、后台动作表和下游凭证是否一致。

相关问题

HTTP 504 后能不能直接重试工具调用？

不能直接判定可以重试。504 只说明调用方等待超时，先用对应幂等键去下游查询状态；只有确认下游没收到请求，或者业务逻辑层面支持安全重复执行的时候才能安排重试。

为什么要保留 unknown 状态？

因为「没收到下游回执」和「动作完全没有发生」是完全独立的两件事。保留unknown状态既能阻止重复触发副作用，也能给后续的恢复任务留机会，通过下游凭证补齐完整的执行事实。

补偿失败后应该让模型继续尝试吗？

常规情况下不应该自动扩大动作范围。补偿执行失败的时候要保留原始动作记录、补偿错误信息和当前的余额或者订单状态，转入有明确边界的人工处理流程。

总结

AI 工具调用的可靠性，从来不是靠把整轮流程打包成一个统一的success状态就能实现的，核心是每个动作都有可追踪的状态、对应的幂等键和下游返回的有效凭证。出现部分成功的情况时，先查落地的执行证据，再在重试、补偿、人工介入三个选项里选最稳妥的方案；模型负责把已经确认的事实清晰传递给用户，服务端负责最终裁定事实的真实性和后续走向。