AI Agent 调用 ERP 写接口：超时、重试与重复单据怎么处理

ERP 写接口返回超时，只能说明调用端没有及时拿到结果，不能据此认定单据没有创建。对于会改变业务数据的 AI Agent 工具调用，关键不是让模型“再试一次”，而是让接口层能够识别同一个业务动作，并查清它最终做成了什么。

本文讨论已获授权的 ERP 写入场景，给出通用设计与验收建议。具体实现取决于 ERP 的接口约定和项目适配，不代表任何平台默认具备下述全部机制。

超时后，先区分失败和结果未知

假设采购员已经确认了一次建单动作。ERP 收到请求并保存了单据，但响应在返回途中丢失。此时页面显示超时，后台却可能已经有了业务结果。如果智能体把它解释为“创建失败”，再发一次建单请求，就可能产生第二张单据。Microsoft 的 Retry pattern明确讨论了服务已处理成功、响应却没有送达的情况。

因此，调用记录至少要能区分“已确认成功”“已确认未执行或被拒绝”和“结果未知”。这不是文案差异：前者应返回已有单据信息，明确被拒绝的动作要按原因处理，未知状态则需要结果查询或人工核对，不能直接转成一次新的写入。

也不要只看接口用了什么 HTTP 方法。RFC 9110 第 9.2.2 节指出，非幂等方法不应被自动重试，除非调用方知道该操作实际上具有幂等语义，或能够确认原请求没有生效。一个 POST 接口不会因为被包装成智能体工具，就自动变得可安全重试。

幂等键对应业务动作，不是每次请求

幂等设计要识别的是“同一个动作被再次传送”，而不是“又来了一次网络请求”。建议由可信的业务服务为经确认的动作生成稳定标识；同一动作的重试复用它，而不是每次调用都由模型生成一个新编号。

例如，同一个采购申请因为响应丢失而再次提交，应沿用原动作标识；用户确实要新建另一份内容相同的申请，则是另一个动作。单纯比较两份请求的字段是否相同，不能可靠区分这两种意图。AWS 关于幂等 API 的设计说明采用了显式请求标识，并讨论了同标识、不同参数的校验。

• 限定作用域：明确组织或租户、操作类型和业务动作标识的组合，避免不同主体意外共用一条去重记录。
• 绑定业务参数：保存经过校验的关键参数或其规范化摘要。同一个标识对应了不同物料、数量或目标单据时，应拒绝混用，不能返回上次的成功结果来掩盖差异。
• 处理并发：记录动作与取得执行权需要可靠的原子约束。“先查没有，再各自执行”仍可能让两个并发请求同时通过。
• 约定保留期限：去重记录应覆盖业务允许的重试与补偿窗口。记录过期后，不能仍假定旧请求可以无限次安全重放。

适配层不能凭一张日志表保证只执行一次

如果 ERP 原生支持幂等请求，应先确认它的键作用域、参数冲突处理、并发行为与有效期。如果 ERP 只提供普通建单接口，在前面增加一张调用日志表，并不等于解决了跨系统一致性。

一个需要单独处理的窗口是：ERP 已经落单，但适配层还没来得及保存成功回执就中断了。重启后的适配层只看到“处理中”，无法仅凭本地记录判断 ERP 的实际结果。

下面是面向这种情况的工程建议，而不是通用的“恰好执行一次”保证：

• 若 ERP 支持带唯一外部业务编号建单，并能按该编号查询结果，可以把本地动作标识与 ERP 单据建立可核对的关联；唯一性是否真的由 ERP 约束，需要看接口合同和实际验证。
• 若只能查询结果但不能阻止重复建单，要保留“原请求可能还在处理”的判断。一次查询为空，不足以证明原请求永远不会成功。
• 如果既没有可信的防重约定，也无法确认原请求是否生效，就暂停该动作的自动重试，进入核对流程。不要更换标识、重新创建，再把它当成恢复成功。

界面可以显示“已提交，结果待核对”，并提供可追溯的动作编号。不要让智能体在缺少回执时生成一个看似确定的单据号。

重试要有边界，人工确认不能被绕过

只有在重试安全性已经明确之后，才讨论次数、间隔和总时限。短暂的网络故障或服务繁忙，可以按接口约定进行有上限的延迟重试；参数校验失败、权限不足、审批失效等原因，不应靠重复发送解决。也要盘点 SDK、网关和业务层各自的重试，避免多层叠加放大请求量。Microsoft 的重试设计建议强调按故障性质处理，并避免缺少协调的多层重试。

幂等键不是授权凭据。可信服务仍需控制谁能执行哪类单据操作，确认界面应展示物料、数量、目标组织等关键数据，而不是只问一句“是否继续”。执行前要核验批准与待执行动作一致；业务参数变化后，先处理旧动作的状态，再重新确认新动作。

这些授权与状态约束应由服务端执行，不能只写进模型提示词。OWASP 的交易授权指南要求保护待授权的数据，并在实际执行前设置授权检查。本文将这一原则用于 ERP 写入设计，并不要求所有 ERP 操作采用相同的认证方式。

把异常结果写进验收用例

下面是建议在隔离测试环境中执行的用例，不是本站客户项目的实测结果。验收应同时观察调用记录与 ERP 侧的单据，而不只看聊天窗口是否提示成功。

1. 重复传送同一动作：在约定的有效期内，携带相同标识和相同参数多次请求，检查是否只形成预期的一份业务结果，以及回执是否能关联到它。
2. 并发重复请求：让同一个动作同时到达，检查是否只有一个请求获得执行权，其余请求是否按约定等待、查询或返回已有结果。
3. 同标识但参数不同：改变物料或数量，检查是否明确报出冲突，而不是再次写入或静默返回旧结果。
4. 写入成功后丢失响应：模拟 ERP 已落单、调用端超时，检查系统能否通过原动作关联查回结果，而不是再次建单。
5. 处理中查询为空：让原请求延迟完成，检查系统是否会错误地把暂时查不到当成未执行，并启动另一笔写入。
6. 批准内容变化或授权失效：检查待执行参数与已批准参数是否一致，失效批准是否被拦截，查看已有回执也是否遵循访问权限。
7. 超出重试或去重窗口：检查系统是否停止自动尝试、保留可核对状态并交给明确的处理人，而不是无限重试。

上线前需要约定的最小清单

在接口清单之外，还应共同确认：动作标识由谁生成、关键参数如何绑定、ERP 是否有业务唯一性约束、用什么接口查询结果、未知状态如何处理、重试窗口多长，以及人工核对由谁负责。审计记录保留必要的关联标识、参数摘要、状态变化和回执，敏感数据按实际访问与留存要求处理。

如果这些条件还不具备，先保留查询与材料准备能力，比让智能体在结果不明时不断建单更稳妥。整体实施顺序可继续阅读《AI Agent 对接 ERP：实施步骤与常见问题》；如何把检查项整理成可复核的验收表，可参考《AI Agent POC 验收指标设计》。

参考资料

• RFC 9110：HTTP 幂等方法与自动重试边界
• Amazon Builders' Library：幂等 API 与重试语义
• Microsoft Azure Architecture Center：Retry pattern
• OWASP：交易授权设计指南

资料查阅日期：2026 年 9 月 7 日。本文中的 ERP 处理流程和验收用例是基于上述原则整理的应用建议，实际执行以目标系统的接口约定为准。