如何防止失控循环（上）
2026-03-20·ClawFirewall·5 分钟
醒来打开模型供应商控制台，看到昨晚数千美元的 API 调用。一个循环。在你睡觉时一直在跑。
对工程团队的调查显示，大多数都遇到过。平均超额约 7,200 美元。有的超过 20,000。对早期创业公司，单次循环曾让一些直接倒闭。
好消息：大多可以预防。这份指南讲成因和应对。
什么是失控循环
失控循环是指任何自主工作流陷入 API 调用的重复循环且没有内置出口。每轮产生更多调用、更多 token、更多成本。因为是自主的，可以跑几小时甚至几天。
常见类型：
- 重试循环：工具调用失败，Agent 无限重试
- 工作流重启循环：工作流失败，Agent 从头重启，周而复始
- 嵌套 Agent 循环：主 Agent 衍生次级，次级再衍生，形成级联
- 幻觉循环：模型编造工具调用或请求，不断尝试满足
- 上下文溢出循环：上下文每轮膨胀直到撞上限制，工作流重启，重复
它们都烧光预算却不产生价值。
为什么会发生
多数循环根因相同：团队只给「正常路径」做了防护。
你大部分时间在测一切顺利的情况。用户发清晰请求、工具成功、模型返回好结果、工作流完成。对边缘情况投入不够：工具失败会怎样？模型返回乱码呢？API 超时呢？Agent 无法完成请求呢？
团队加了重试逻辑，但没有硬限制、熔断器或退出条件。他们假定工作流终会成功。这个假定就是循环的起点。
之前那篇 1 万美元循环，是因为重试限制是按调用设的，不是按工作流。10 次重试失败后，Agent 重启整个工作流。没人加那道护栏。
步骤 1：每一层设硬性重试限制
重试逻辑是多数失控循环的根源。硬限制能拦住。
多数团队只限制 per 工具调用的重试。你需要在四个层面设限：
- Per 工具调用：最多 3 次重试。3 次失败后调用失败，工作流进入错误处理——不再重试
- Per 动作：最多 2 次重试。Agent 2 次尝试仍无法完成动作，升级给人
- Per 工作流：最多 1 次重启。工作流失败一次可允许重启一次。再失败就停止
- 全局：per 小时或 per 天的总重试上限。达到上限，该时段内禁用重试
在基础设施层、在请求到达供应商之前强制执行。如果只在 Agent 代码里，bug 或畸形响应可能绕过。ClawFirewall 在 API 网关层强制重试限制，即使有 bug 的 Agent 代码也无法突破。
步骤 2：每个工作流配熔断器
熔断器在工作流越过阈值时停止流程。触发时：工作流停止，不再发起 API 调用，升级给人。在有人复查前不重启。
建议的触发条件：
- 错误率：例如 10 分钟内错误率 >20%
- 重试量：例如 5 分钟内重试 >10 次
- Token 用量：例如单次运行 2 倍平均值
- 支出：例如单次成本 10 倍或日预算 50%
- API 调用量：例如每分钟 5 倍平均值
就算有东西绕过重试限制，熔断器也能在烧爆预算前叫停。ClawFirewall 内置可配置熔断器。