工具调用的失败重试：怎么让 Agent 不重复扣费
Agent 的调用链比普通聊天长，一次任务里可能有六七个工具调用。链越长，失败的概率越高，重试带来的重复支出也越难发现。
规则一：幂等键写在请求里，不写在内存里
工具调用如果是写操作（下单、发邮件、生成任务），必须带一个由业务生成的幂等键。重试时复用同一个键，服务端才能识别这是同一次请求。把幂等键存在进程内存里是最常见的错法：进程重启之后，键就丢了。
规则二：用状态机管理每一次调用
每次工具调用只有四个合法状态：已提交、执行中、成功、失败。重试只能发生在「失败」状态，不能在「执行中」重试——那是最容易重复扣费的一种情况。
规则三：一次任务只允许一个在途调用
并行工具调用看起来更快，但在有预算约束的任务里，并行会让失败成本乘以并行度。除非工具之间真的无依赖，否则串行更可控。
媒体任务的处理方式
图片与视频这类长任务不是同步返回的，提交之后拿到 task_id，再用 GET /v1/media/status?task_id= 查询状态。这类任务的正确重试方式是「重查状态」，而不是「重新提交」。
自检清单
- 每个写操作工具都有幂等键。
- 只有失败状态才进入重试分支。
- 重试次数与退避间隔写在配置里，不写死在代码里。
- 长任务只重查、不重提。
- 失败请求是否计费，合同或文档里能找到明确口径。
媒体任务的完整两步流程见 媒体任务的提交与查询，四套协议的鉴权差异见 协议对照。