# 搞定AI Agent死循环：防账单爆表的四层拦截方案

> 防住AIAgent死循环不能靠提示词自我修正，必须在应用层与网关层焊死断路器：通过指纹拦截重复调用、参数归一化、单次成本步数熔断及APIKey额度锁死四层防护。

来源：https://www.starboxai.ai/insights/ai-news/2026-11-12-ai-agent-infinite-loop-prevention/（星盒AI 知识中心，更新于 2026-11-12）

很多企业搭建自动化员工时，最怕遭遇 AI [Agent](/glossary/agent/)死循环 导致账单爆表。我见过一家做外贸的企业技术负责人，为了让智能体自动查账单，写了一句提示词「如果服务报错请重试直到成功」。当晚第三方财务系统服务中断，那个智能体不知疲倦地重试了整整一夜，把整段失败报错不断拼接进上下文，单次请求的上下文体积暴增了二十多倍，一夜之间白白烧掉几千美元。

2026 年 11 月 12 日，模型路由聚合服务商 OpenRouter 发布了一篇技术教程，专门拆解 AI Agent 因工具调用反复失败而陷入死循环的成因，并在六个主流模型上完成了实测验证。测试表明，仅靠模型自我修正根本拦不住重复调用；OpenRouter 提出了四层工程防护网，直接将测试中的工具调用总数从 314 次压缩到 64 次，成本从 0.29 美元降至 0.05 美元。

如果你正准备在企业内部推行自动化工作流，这个方案值得立刻落地到你的代码库里。

## 为什么会出现 AI Agent死循环 与工具调用失败？

智能体退出的唯一标志，是模型觉得任务完成了，直接输出最终文本而不发起工具调用。

一旦外部工具因接口超时、网络报错或权限不足而持续失败，模型就拿不到正向结果。错误信息被原封不动推回对话上下文，[系统提示词](/glossary/system-prompt/)又死死规定它「必须完成任务」，对大模型而言，重新发起一次请求依然是当前推理逻辑下的最优解。如果没有外部代码强制数次数，模型自己绝不会停下来。

更致命的是滚雪球效应。Agent 的每一次重试，都会把前面所有轮次的提问、工具调用参数、错误堆栈全部重新发回给模型。OpenRouter 在测试中记录了一个真实样本：随着重复调用持续，单轮输入的 [Token](/glossary/token/) 数量从 131 暴增到 3,262，单轮对话成本翻了近四倍。当几百个并发会话在深夜同时陷入这种无休止重试时，企业 Token 账户会被迅速抽干。

测试还揭示了一个残酷事实：哪怕完全相同的输入，模型的行为也是不可控的。在对 Grok 4.7 的三次相同测试中，两次跑到了 40 步强制上限，一次在 12 步停下。单次测试跑通，绝对不等于你的智能体在生产环境不会死循环。

## OpenRouter 工具调用的四层防线拆解

要把调用失控的口子彻底堵死，必须建立跨越智能体代码层和网络请求网关层的多重断路机制。

### 第一层：死循环检测（doom-loop detection）与梯级阻断

死循环检测的核心是给每次工具调用生成指纹。它抓取工具名称与传入参数，在规范化排序 JSON 键名后对比历史记录。如果模型已经看到了上一轮的失败结果，在下一轮又发出了完全一致的调用请求，系统就判定发生了一次重复。

这套机制设定了一个默认的拦截天梯：第 2 次重复时列入观察，第 3 次直接阻断执行，第 6 次彻底掐断整个会话。在第 3 次阻断时，系统不再去调外部接口，而是直接给模型返回明确的报错信息，告诉它「你在重复犯错，重试毫无意义」。在 OpenRouter 测试的六个模型中，开启该检测后，全部模型在第 3 次相同调用时被精准拦截，18 次测试中有 16 次在两次真实调用后就安全终止。

### 第二层：用 loopKey 识别微调参数的「伪重试」

简单的参数完全匹配很容易被模型绕过。测试发现，Mistral Large 4 和 GPT-6 Luna 在被系统拦截一次后，会自动在参数后加空格、换行符，或者把发票号从「INV-2291」改成全小写的「inv-2291」。

对模型来说，它以为换了个新方法；对死循环检测系统来说，参数字符串变了，指纹也就变了，导致重复计数器归零重新计算。在九次补充测试中，模型有五次通过微调大小写绕过了检测，其中三次一路消耗到了 40 步的兜底上限。

解决方法是在工具上配置 loopKey，指定业务识别的核心字段。例如对发票查询工具，强制提取其中的数字「2291」作为归一化指纹，忽略英文字母大小写和前后空格。只要业务目标相同，无论模型怎么变换花样，都会被死锁在重复调用计数器中。对于本身就需要反复轮询的工具（例如查询任务进度），则显式配置关闭该检查。

### 第三层：单次运行的步数与成本双重熔断（stopWhen）

指纹检测只能抓住重复行为，抓不住一直在换新花样犯错的模型。如果一个模型每次都捏造一个完全不同的参数继续试错，指纹检测就会失效。

必须在工作流引擎中加入硬性熔断（stopWhen），同时监控执行轮数（stepCountIs）和累计实际消耗金额（maxCost）。任何一项超标，立即终止执行。在实际业务中，金额熔断远比步数熔断更关键，因为智能体越跑到后面，由于历史上下文堆积，后几步的成本往往是前面几步的数倍甚至数十倍。通常根据正常业务消耗设置阈值，如果一个任务平时四到六步就能完成、花费约 0.005 美元，把上限卡在 15 步和 0.01 美元就是合理的防线。

### 第四层：API Key 级别的网关信用额度控制

前三层防护全部运行在企业自己的 Agent 应用代码里。一旦代码出现 Bug、上线时漏传了配置，或者有人绕过逻辑并发起上千个并发会话，内部断路器就会全部失效。

最后一层必须放在模型调用服务商（如 OpenRouter）的网关层。企业应为每一个独立的 Agent 或业务场景分配独立的 API Key，并设置硬性信用额度（Credit Limit，可按日、按周或按月重置）。网关在真正把请求路由给模型底层之前，会先根据输入长度加上最大输出 Token 计算最坏情况开销。如果余额不足，网关直接返回 402 错误并拒绝分发。哪怕本地应用彻底崩溃进入死循环，网络层也会把损失钉死在分配给该 Key 的预算之内。

## 智能体死循环防护 与 企业 AI 工作流熔断 配置清单

下表为工程防护配置清单与建议阈值（示例测算）：

| 防护层级 | 防控目标 | 核心配置与检测指标 | 推荐拦截阈值（示例） | 触发后动作 |
|---|---|---|---|---|
| 第一层：重复检测 | 拦截相同工具及相同参数的无效重试 | 计算调用指纹（工具名 + 参数排序后的 Hash） | 第 2 次标记，第 3 次阻断，第 6 次终止 | 跳过真实接口，返回不可恢复错误 |
| 第二层：参数归一 | 防止模型通过修改空格、大小写绕过拦截 | 配置业务主键 loopKey，抹平格式噪声 | 统一转小写、去首尾空字符、提取核心 ID | 归一后合并计入重复计数器 |
| 第三层：单会话熔断 | 防止模型不断捏造新参数导致长程跑飞 | 监控单轮 stepCount 与累计 usage.cost | 假设设为 15 步 / 0.01 美元上限 | 终止会话，返回超限日志并告警 |
| 第四层：网关额度锁 | 防止代码缺陷导致全量并发失控烧穿预算 | 独立 API Key 设置 limit 与重置周期 | 按单业务线单日最大允许亏损设硬顶 | 网关返回 402，拒绝路由请求 |

## 从星盒实践看 Agent 成本控制：安全边界是自动化落地的第一前提

在星盒AI 服务 500+ 家企业落地数字员工和营销智能体的过程中，我经常遇到企业管理层的一个常见误区：认为只要把提示词打磨得足够严密，写上「请不要重复犯错」「思考清楚再调用」，智能体就能听话。

现实往往相反。在复杂的企业生产环境中，提示词只是对模型意图的软性引导，面对网络断连、数据库响应延迟或脏数据输入，软性引导必然失效。在星盒AI 的智能体体系中，无论是新媒体内容工厂的批量生成，还是微信端运行的「星盒星盒！」企业全能 AI 营销智能体，我们从不把流程稳定性押注在模型表现上，而是统一通过底层工程系统来做严格限制。

把防护网焊死在架构里，企业才有底气放手让智能体做深度自动化。当每一笔 Token 消耗都有上限、每一次重复调用都有断路器时，AI 落地才不会从提高效率的工具变成随时可能爆单的隐患。