AI Agent 对接业务系统：接口限流后如何退避而不误报结果

员工让 AI Agent 查询一批 ERP 库存，接口却返回 HTTP 429。此时最危险的回答不是“稍后再试”，而是把限流当作“库存为零”，或在后台无上限地重发请求。企业智能体对接业务系统时，应把限流视为独立的查询状态：先确认配额边界，再按可等待时间退避，仍取不到可靠结果就明确告知用户。

先区分限流、权限错误和业务失败

HTTP 429 表示调用方在一段时间内发送了过多请求；它不是业务数据为空，也不证明账号没有权限。权限不足、参数错误、接口超时、源系统返回成功但字段缺失，各有不同处理路径。智能体应先记录 HTTP 状态、接口、请求标识、调用方和发生时间，再决定是否重试，不能把所有非 200 响应统一改写成“未查到”。RFC 6585 对 429 的定义并不规定限额必然按用户、令牌还是整个平台计算，这一点必须向接口提供方核实。

例如构造的库存查询：用户要求查看某物料在三个仓库的当前可用量，前两个仓库成功，第三个仓库返回 429。回答应说明“第三个仓库本次未取得实时结果”，并标注前两项数据的查询时点；不能把第三项填成零，也不能把部分结果描述成完整汇总。若业务必须全量一致，应等待全部取得后再给出合计。

先摸清配额作用域和查询成本

设计退避前，先列出接口契约：限额作用于租户、应用、访问令牌、用户、具体端点，还是共享出口？窗口是固定时间段、并发数，还是每次请求消耗不同权重？这些不能从一次 429 推断。还要问清分页、批量查询、缓存和条件查询是否受支持，以及接口是否返回剩余额度或重试提示。没有文档时，应与源系统负责人共同做小规模观察，而不是靠高频探测反推上限。

从任务链路看，一次自然语言问题可能拆成多次检索、字段补全和分页。应给每个用户请求设置总调用预算，优先合并合法查询、缩小字段与时间范围，避免同一个答案在多个工具层重复拉取全表。本站系统集成页面公开将只读、限流、缓存与错峰作为集成评估策略；具体接口配额和实现仍取决于项目与源系统，本文不声称本站已经内置某个限流组件。

读懂 429 与 Retry-After

收到 429 后，先检查响应是否提供 Retry-After。按 RFC 9110，这个字段可以是 HTTP 日期，也可以是秒数；429 响应可以带它，但不是每次都有。若有可信提示，调度器应按该提示和本任务的最大等待预算选择下一次尝试，而不是立即循环重发。日期形式还应考虑本机时钟与服务端时间的偏差。

没有提示时，可以采用有限次数、逐次拉长等待并加入随机抖动的退避策略。数字阈值不宜抄成通用规则：一个交互式问答可接受的等待，与夜间批处理完全不同。若源系统要求等待的时间已经超过用户愿意等的时长，应结束本轮交互，清楚说明暂未取得新数据；只有用户同意且产品支持可靠的异步任务时，才考虑后续通知。

限定重试预算，避免多层放大

重试应有单一负责层。调用库、网关和智能体编排器如果各自自动尝试三次，一次用户请求可能被放大成九次甚至更多，恰好在源系统最拥挤时制造额外负载。Microsoft 的瞬态故障指南建议检查 SDK 是否已内置重试，并给重试设上限、退避和整体延迟预算。遇到持续 429 时，应停止即时尝试，向上游传播“受限、可稍后重试”的状态。

本文的有限重试只针对确认可安全重复的只读查询。写入 ERP 单据、提交 OA 审批或触发设备动作，不能因为收到 429 或超时就擅自重发；请求是否已经被接收、操作是否幂等，需要另一套确认机制。有关写操作边界参看ERP 写入幂等文章。即使只读请求最终成功，也要按接口返回校验文章检查字段、单位与时间，不能只看 HTTP 200。

排队、缓存与用户可见的等待状态

多位员工同时查询同一类数据时，可在项目允许的边界内做请求合并、队列限速或错峰；先保护源系统，再改善单个请求的等待体验。缓存只适用于权限、租户、参数和有效期都能隔离的查询结果。展示缓存值时要明示“截至何时”，并确认该业务允许使用非实时数据；库存、审批结果等会影响决策的信息，不应悄悄以旧值冒充当前状态。权限撤销后，旧缓存也不得继续对原用户开放。

前端与智能体回复至少区分四种状态：正在查询、受限等待、仅有部分结果、未取得可靠结果。若采取异步排队，还需有任务标识、取消或过期规则、结果权限复核和通知失败处理。若没有这些保障，简单说明“本次查询受限，请稍后重新发起”比假装任务仍在后台执行更诚实。

用峰值与故障用例做验收

验收不只测一条查询成功。可以用隔离的测试环境和源系统同意的负载，覆盖单人连续查询、多人同时查询、分页放大、部分端点返回 429、带秒数和日期形式的 Retry-After、没有该字段、权限错误、长时间受限以及恢复后的第一轮请求。测试环境的限额并不自动等于生产限额，结果需要注明配置。

• 负载保护：统计原始用户请求数、实际下游调用数、重试次数和排队时长，确认没有重试风暴。
• 结果正确：429 时不输出零值或“无记录”；部分结果、缓存时点与失败范围能够被读者辨认。
• 预算可控：超出最大等待时间或次数后及时停止，不在用户结束会话后无期限占用配额。
• 恢复可观测：记录受限比例、等待分布、最终成功和放弃原因，用于与源系统负责人调整调用方式。

Microsoft 的 Retry Storm 反模式说明强调避免无限重试、尊重服务端等待提示并区分可重试故障。验收结论应写清实际接口、调用身份与环境，不能把示例策略宣传为所有业务系统的统一阈值。

参考资料与适用边界

• RFC 6585 §4：429 Too Many Requests，用于 429 的语义和非固定的限额作用域。
• RFC 9110 §10.2.3：Retry-After，用于等待提示的两种格式。
• Microsoft Learn：Transient fault handling，用于有限重试、退避、抖动和整体延迟预算。
• Microsoft Learn：Retry Storm antipattern，用于多层重试放大与负载保护。

资料查阅日期：2026 年 9 月 30 日。本文是企业智能体集成的设计与验收方法，不是某个源系统或本站产品的实测报告；限额、缓存有效期、任务等待时长和数据权限必须以项目契约与实际验收为准。