业务写入后超时，Agent 应先查明结果

ERP 写入超时后，AI agent 应该重试，还是先查结果？作者给出的答案是：先保留「结果未知」，再向接收系统核实。超时只能证明调用方没拿到响应，不能证明业务操作失败；直接重试，可能把一次采购或财务操作变成两次。

这篇文章的价值，在于把这类故障拆成了可执行的控制流程，并用本地测试验证了一部分行为。不过，测试通过不代表 SAP 生产环境已经验证通过，文中的 SAP BTP 方案仍待租户实测。

超时之后，为什么不能直接重试

最危险的故障发生在两个动作之间：接收系统已经提交业务变更，调用方却没收到回执。此时，界面显示失败，后台可能已经成功。

作者要求把执行结果分成三种：

• 已确认：拿到了权威业务引用，并核验了实际状态。
• 明确拒绝：有证据表明接收系统拒绝了操作。
• 结果未知：接收系统可能执行过，但调用方还无法证明结果。

「结果未知」必须成为独立状态，不能被归入「失败后重试」。

作者团队在 2026 年 11 月 3 日使用本地参考夹具，运行了 9 个已有测试。其中 7 个使用临时控制文件适配器和确定性 worker，2 个使用临时 SQLite 存储。进程防护阻止网络和子进程操作，记录到的尝试次数为 0。全部测试在 0.339 秒内通过。

关键用例先完成一次模拟写入，再在返回回执前抛出异常。控制器保留未知状态；下一轮调度时，写入次数仍为 1。随后，只读核对找回回执，验证后才进入已接受状态。另一个取消用例也确认，写入后恢复执行不会重复写入。

这些结果支持的是本地控制器的状态管理行为。真实 ERP 的提交机制、网络故障和业务过账规则，都还没有被这组测试覆盖。

防重复，要在发出请求之前准备什么

作者提出了一份小型动作契约：执行前记录目标环境、业务对象、操作、已批准的输入修订版，以及稳定的请求标识；同时保存谁授权了这个具体动作，以及授权有效期。

这份记录需要持久保存在模型之外。聊天中的一句「已经批准」或「刚才失败了」，不足以作为下一次执行的依据。

真正执行时，还要重新核对目标和授权。关键输入变了，就要针对变更后的请求重新取得决策，不能沿用旧批准。

本地测试覆盖了这条边界：相同动作复用已有意图；动作或载荷发生变化时拒绝复用；不同目标环境拥有不同意图。其他用例还检查了缺失授权、证据未被接受、worker 提案变化、目标不匹配，以及依赖步骤是否已被接受。成功路径写入了两条有依赖关系的本地记录，并分别读回验证。

请求发出后，如果结果未知，就通过稳定业务引用或接收系统支持的关联机制查询。查不清时，把原请求、最后已知状态和调查证据交给操作人员。

补偿操作也不能悄悄覆盖原记录。它应有自己的身份和授权，原始结果则继续保留，方便追溯。

SAP BTP 能接上流程，但不能替后台证明成功

作者建议先选择适用于具体业务操作和 SAP 版本的 released API，确认接收 API 如何处理重复请求、能否查询执行结果，再设计重试逻辑。

SAP Cloud Integration 提供 Idempotent Process Call 步骤，但文章指出，其文档也说明了接收应用未确认处理时的超时局限。中间件检查过重复，不等于已经确定后台业务写入是否提交。

因此，方案仍然需要持久动作记录，以及来自权威系统的读回验证。

SAP Build Process Automation action 可以通过配置好的 destination 暴露选定 API 操作。作者建议把范围限制到工作流所需操作，并检查认证、应用路由和适用的 CSRF 处理。destination 解决部分连接问题，业务权限仍需 SAP 后端执行。

Joule 的接入也有前提：租户必须支持所需的 skill 或 agent extension，还要确认 edition、entitlement 和集成支持情况。接入后，网页与对话入口应调用同一个受限业务动作，遵守相同的审批、恢复和核对规则。

这里描述的是待验证设计，没有给出真实租户上的成功运行结果。

我的判断

这套思路最有用的地方，是把「调用是否返回」和「业务是否发生」分开了。对会产生业务副作用的 AI 工具调用，这比让模型根据报错自行决定重试更容易审计。

不过，稳定请求标识不是万能钥匙。接收系统是否支持去重，能否按关联信息查询，以及查询结果是否足以确认业务状态，决定了恢复流程能走多远。原文没有给出具体 SAP API、字段或查询示例，落地时仍需逐项核实。

相较于只在中间件去重，这个方案多了业务结果核对；相较于单纯重试，多了持久状态和人工接管入口。代价是实现与运维工作增加。作者没有提供这些方案之间的对照数据，不能据此宣称效率或可靠性提升了多少。

0.339 秒也只是本地测试耗时，不是 ERP 性能指标。下一步真正有说服力的验证，是在授权测试环境中制造「接收方提交成功、响应丢失」，然后核对真实业务单据。

能拿来做什么

• 给调用业务写入接口的 Node 服务保留「结果未知」状态，并持久记录请求标识、目标、批准输入和授权有效期，让后续调度能继续核对。
• 在前端审批或操作页面展示原请求、最后已知状态和核对证据；遇到未知结果时，提供调查入口，避免用户只能反复点击提交。
• 把「提交成功后丢响应」加入验收，同时测试重放请求、修改载荷、发出后取消和受限角色调用，分别检查允许完成与安全拒绝。
• 除了完成耗时，还记录重复业务效果和未知结果的持续时间，并保存批准请求、技术响应、权威单据与核对决策，让下一次超时有据可查。