生产级 Agent 如何控制访问故障与成本

Agent 上线后，麻烦往往出在模型之外：网站拒绝访问、任务重复执行、并发挤爆限流、工具调用持续花钱。dev.to 的这篇文章围绕身份、预算和故障影响范围，讨论如何给 Agent 加上工程约束。现有节选给出了抓取、任务队列和工作区隔离的具体做法，但身份管理部分尚未完整呈现。

目前能确认什么

作者建议优先使用带密钥的正式 API，并区分访问失败的原因：对 403 按策略拒绝处理，停止盲目重试；对 429 采用带随机抖动的退避，并遵循 Retry-After。通用 HTTP 语义中，前者表示服务器拒绝请求，后者表示请求过于频繁，两者不能共用一套重试逻辑。

故障隔离要落到域名级别。作者提出按域名熔断、缓存页面，并让调用链接受「blocked」这种结果，避免一个站点拖住整批任务。

并行 Agent 则需要队列、并发上限和幂等键。幂等是指重复执行不会产生额外效果，发邮件、创建工单等操作尤其需要在工具边界去重。代码任务还可使用独立 git worktree，产物落盘，通过 diff 审查改动。

我的判断

上线前更该检查的是失败后会做什么，而不只是成功时能做什么。

对抓取或研究类 Agent，我会优先检查拒绝访问能否结束该分支、单站失败能否隔离，以及重试是否重复产生副作用。这些机制直接决定批处理能否收尾。

节选中的预算代码还有一个边界：它在请求完成后累计 token，再判断是否超额。因此，它能阻止后续循环，却不能单凭这段代码保证本次请求绝不突破预算。

身份如何映射到权限、密钥怎样隔离，以及工具费用是否计入总预算，目前都没说清。仅凭节选，还不能把这套示例当作完整的生产安全与成本控制方案。