Agent 调业务接口超时后，怎样确认操作到底有没有完成

Agent 调业务接口超时后，先确认目标系统到底有没有完成操作，再决定重试或补偿。网络超时只说明调用方没有及时拿到答案，不能证明订单没建、付款没受理或消息没发出。本文用合成建单记录设计核对流程，重点是结果未知时如何停止扩大影响；不会真实创建、撤销或冲销任何业务对象。

请求发出前就准备好核对线索

为每个有副作用的动作生成稳定业务请求号，保存目标、参数摘要、请求人、确认人和发送时间。目标接口支持幂等键时按其契约使用，不随重试换号；不支持时询问能否按外部业务号查询结果。不要等超时之后才临时想办法找单据，届时用客户名或金额模糊搜索可能匹配到另一笔合法业务。

写入前由有权限的人确认对象与参数，执行时再次检查授权和版本。确认记录与请求号绑定，后续核对只寻找这次操作的结果，不允许自动扩大到别的单据。保存发出前状态与允许的补偿方式，避免恢复人员看到“失败”就点重跑。业务界面应有待核对状态，明确提示用户暂勿重复提交，而不是简单显示一个红色失败按钮。

查询到目标单据且参数相符，记为已完成，并补回单号；目标系统明确证明请求未执行，才可记为未执行；查询暂时无结果、接口不具备一致性保证或状态服务不可用时，继续保持未知。没有查到不是同义于不存在，异步队列和索引延迟可能让刚完成的单据暂时不可见。核对要遵循目标系统的状态语义和等待窗口。

HTTP 语义规范的幂等与自动重试章节说明了不同方法的重试语义，业务接口还需自己的契约。不能仅因为请求采用某个 HTTP 方法就推导整项业务一定可安全重发，尤其是创建类动作。若目标系统返回异步受理，保存受理号并查询最终状态，不把受理成功当作业务已经生效。

下载超时、查单与补偿决策表。第一条写入后响应丢失，随后按请求号查到目标单，直接补记结果；第二条目标明确拒绝且未执行，可在修正条件并重新确认后重试；第三条查单服务不可用，保留未知并转人工。每条记录都写证据来源，不用模型推测的“应该成功”填状态栏。

在隔离模拟接口中，分别控制写入发生与响应返回的顺序。让客户端在写后断线，验证恢复流程不会再建第二张单；让查询延迟返回，验证首次查无结果时不会立即重发；让确认过期，验证核对可以继续但新的写动作必须重新批准。查询已有操作结果与发起新操作是两种权限需求，应分别处理。

作废订单、撤销预留、发更正消息都可能产生新的业务后果，不是技术上把一段代码反向执行。补偿前先确认原操作已发生、目标对象正确、允许撤回且尚未进入不可逆阶段。展示补偿预览、原因与影响，由具备权限的人确认；原始批准不自动授权所有补偿。补偿本身同样需要请求号、状态核对和审计，不能把它当作无风险清理。

如果原操作仍未知，不应先发一个反向操作“抵消可能成功”。这样可能在原操作未执行时制造新的错误。对于不能撤回的动作，应采用业务认可的后续处理，例如由责任人联系接收方或登记更正，具体做法由业务规则决定。开发方不能替财务、采购或客服定义法律或业务效力，只能把核对与确认链路做清楚。

浏览器、Agent 平台、适配层和目标 SDK 都可能重试，实际请求次数可能多于界面显示。让各层传递同一业务请求号，并记录每次尝试与最终目标结果。接口的超时预算、队列截止时间与用户等待界面相互协调，用户离开页面也不代表后台任务已经取消。取消请求应有自己的状态，说明已停止发送还是目标已撤销。

为长期未知任务安排责任人、查询节奏和升级时限，参数按业务影响确定，不给通用固定分钟数。通知只带脱敏业务号与状态，详细资料通过受控入口查看。值班人员处理后记录证据与决定，不能直接编辑日志把未知改成成功。数据责任人应能从一个请求号查到所有尝试、确认、查询与补偿，形成完整链路。

若查到的单据参数与原批准摘要不一致，不能直接归为成功。先标为结果冲突，保留目标回执并由业务负责人核对是否匹配了错误对象、目标系统做了转换，或发生并发修改。冲突处置同样不自动覆盖目标数据，需要新的明确决定。

验收至少覆盖写后断线、明确未执行、延迟可见、查单失败、重复提交与补偿失败。业务单数与不同请求号集合要对账，所有未知项都有去向，才可结束演练。更多背景见流程自动化专题和平台能力边界，系统接入可查看集成服务。通过定制咨询提供脱敏超时记录、状态查询能力和业务撤回规则，可评估核对与补偿的实现范围。