退款工具在客户端看来已经 Timeout，但 Provider 最终完成了操作；Agent 随后自动 Retry，又执行了一次。重新开放流量之前，这个 Runtime 归你负责。
先处理问题，再阅读解释。
你是当前值班的 AI / Backend Engineer。
退款 Provider 在 5.2 秒后完成了请求，但 Client 在第 4 秒已经 Timeout，于是 Agent 开始第二次尝试。按照当前交易规模，重复操作对应 47,000 美元 Gross Exposure。
在维持瞬时故障恢复能力的同时，让重复 Intent 变得安全，并把延迟、成本和人工审核控制在预算内。
当远端系统可以在 Client 放弃等待后继续完成操作时，Timeout 从来不等于失败。
当工具存在不可逆副作用时，Retry Policy 与 Idempotency Policy 本质上是同一个可靠性设计问题。
把结果整理成可以复用的判断。
工程复盘
当工具会产生不可逆副作用时，Retry Policy 与 Idempotency Policy 必须一起设计。
Client 看到了 Timeout，但 Provider 实际已经完成第一次退款。业务 Intent 没有 Operation-level Idempotency 边界时，Retry 会再次制造副作用。Compensation 可以事后减少损失，却不能把重复执行变成安全行为；完全关闭 Retry 则会牺牲本来可以恢复的任务。
远端系统可能在调用方停止等待之后继续成功完成。
只设计恢复策略、不设计重复 Intent 的安全边界，就会把恢复机制变成事故放大器。
冲正可以降低财务损失，但不能证明 Runtime 的重复执行契约已经正确。
把这次体验连接到概念、参考与迁移。
LEARNING CONTEXT
Timeout 只说明你观察到了什么；Idempotency 才决定重复同一个 Intent 是否安全。
Mental Model
建议补充前置
迁移这个模型
创建订单的 API Timeout 了，但 Provider 可能已经提交订单。请设计安全的恢复路径。
把这个判断带到另一个问题或构建中。