# 搞定AI Agent死循環：防賬單爆表的四層攔截方案

> 防住AIAgent死循環不能靠提示詞自我修正，必須在應用層與網關層焊死斷路器：通過指紋攔截重複調用、參數歸一化、單次成本步數熔斷及APIKey額度鎖死四層防護。

來源：https://www.starboxai.ai/zh-hant/insights/ai-news/2026-11-12-ai-agent-infinite-loop-prevention/（星盒AI 知識中心，更新於 2026-11-12）

很多企業搭建自動化員工時，最怕遭遇 AI [Agent](/zh-hant/glossary/agent/)死循環 導致賬單爆表。我見過一家做外貿的企業技術負責人，為了讓智能體自動查賬單，寫了一句提示詞「如果服務報錯請重試直到成功」。當晚第三方財務系統服務中斷，那個智能體不知疲倦地重試了整整一夜，把整段失敗報錯不斷拼接進上下文，單次請求的上下文體積暴增了二十多倍，一夜之間白白燒掉幾千美元。

2026 年 11 月 12 日，模型路由聚合服務商 OpenRouter 發佈了一篇技術教程，專門拆解 AI Agent 因工具調用反覆失敗而陷入死循環的成因，並在六個主流模型上完成了實測驗證。測試表明，僅靠模型自我修正根本攔不住重複調用；OpenRouter 提出了四層工程防護網，直接將測試中的工具調用總數從 314 次壓縮到 64 次，成本從 0.29 美元降至 0.05 美元。

如果你正準備在企業內部推行自動化工作流，這個方案值得立刻落地到你的代碼庫裏。

## 為什麼會出現 AI Agent死循環 與工具調用失敗？

智能體退出的唯一標誌，是模型覺得任務完成了，直接輸出最終文本而不發起工具調用。

一旦外部工具因接口超時、網絡報錯或權限不足而持續失敗，模型就拿不到正向結果。錯誤資訊被原封不動推回對話上下文，[系統提示詞](/zh-hant/glossary/system-prompt/)又死死規定它「必須完成任務」，對大模型而言，重新發起一次請求依然是當前推理邏輯下的最優解。如果沒有外部代碼強制數次數，模型自己絕不會停下來。

更致命的是滾雪球效應。Agent 的每一次重試，都會把前面所有輪次的提問、工具調用參數、錯誤堆棧全部重新發回給模型。OpenRouter 在測試中記錄了一個真實樣本：隨着重複調用持續，單輪輸入的 [Token](/zh-hant/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 落地才不會從提高效率的工具變成隨時可能爆單的隱患。