Agent重试如何避免重复执行与额度超支

Agent 调用失败后重试，真正棘手的是：上一次操作到底有没有生效？dev.to 的一篇文章用可复现实验拆解了并发额度、响应丢失和崩溃恢复问题，并分别在额度预留端和执行目标端补强保护。目前拿到的节选能确认 SDK 的保护边界，但后续修复细节尚不完整。

目前能确认什么

作者基于 strands-agents 1.63.0 做了实验。同一个 Agent 实例默认拒绝并发调用；在默认模式下，两个调用使用相同的 idempotency_token，后来的调用会等待正在执行的请求，并取得其结果，实验中没有重复调用模型。

这项保护有明确范围：状态和锁属于单个实例。两个独立实例各自携带 limits 执行时，不会共享预算。单次请求的限制，不能直接充当多个 worker 的总额度。

同一实例内的请求去重，不等于跨实例的共享额度控制。

租约（lease）则给额度预留设置有效期，便于回收失联 worker 占用的容量。但从通用机制看，租约到期只说明预留过期，不能证明外部操作未执行；查询返回「未找到」，也未必能排除仍在途中的请求。

作者明确限定了实验范围：单机线程、真实时钟租约，外部系统由加锁对象模拟。这能提供状态转换的时序证据，不能当作真实分布式部署的验证。

我的判断

排查 Agent 重复扣款、重复建单或额度超支时，应分别检查请求去重、共享额度预留和目标端副作用保护。一个 idempotency_token 不能自动覆盖这三层。

最需要警惕的是「查询未找到，于是退还额度并重试」这条恢复路径。如果旧请求仍可能完成，退还额度就可能让新旧请求同时产生副作用。

摘要提到作者在两端补强了保护，但现有节选没有展示完整协议。它如何处理迟到请求、怎样确认容量可以安全归还、崩溃后状态如何恢复，仍要等完整原文确认，不能据此认定已有可直接用于生产的方案。