mk-brain

Claude 的「法庭迴圈」：一個 Bug 揭示的 Agent 介面脆弱性

近期 Anthropic Claude 模型的一個小 Bug，讓工具調用標籤變成無關的單字，導致 Agent 工作流中斷。這不僅是程式碼錯誤，更深刻暴露了當前 AI Agent 設計的根本弱點：過度依賴脆弱、隱含的格式假設。本文將從這個具體案例出發，深入探討為何穩健的介面契約與明確的協定設計，才是打造可信賴、可長期運作的 AI 系統不可或缺的關鍵。

江中喬

21 8月 2026 • 7 min read

近期 Anthropic Claude 模型的一個小錯誤，意外揭示了當前 AI Agent 架構普遍的脆弱面。當 Agent 與模型之間的溝通，過度依賴隱含且不穩定的文本格式時，任何微小的模型版本變動，都可能導致整個工作流程的災難性中斷。這提醒我們，要打造真正穩定、可信賴的 AI 系統，不能依賴脆弱的格式假設，而必須將介面契約（interface contract）設計成可驗證、可恢復、甚至可降級的明確協定。這不僅是工程實踐問題，更是系統設計哲學的根本差異。

失控的標籤：Claude 的 `court-loop` 事件

事件的主角是 Anthropic 專為程式碼生成的模型 Claude Code。在 2024 年 8 月釋出的 Opus 4.8 版本中，開發者社群開始回報一個奇怪的現象：當要求模型使用工具（tool use）時，理應輸出的 XML 標籤如 <code> 或 <call>，會被錯誤地替換成 <court>、<count> 等看似隨機的單字。這個問題被開發者戲稱為「court-loop」。

根據日本開發者ミトナ在 Zenn.dev 上的紀錄與 GitHub 上的多個回報，這個 Bug 會導致 Agent 的解析器無法識別工具調用指令，從而讓原始的 XML 標籤直接洩漏到對話本文中，未經處理就暴露出來，最終中斷整個自動化流程。有開發者在 GitHub 上回報，單一會話中就遭遇超過 30 次此類錯誤，嚴重影響了開發效率。

儘管這個問題在 Sonnet 等其他版本中並未出現，且看似只是暫時性的模型輸出瑕疵，實則暴露了一個更深層的結構性風險。

當我們依賴模型「心照不宣」地遵循一個鬆散的文本格式時，我們其實是在為系統的崩潰埋下伏筆。任何模型權重的微調，都可能成為破壞這個脆弱信任的單點故障。

為什麼一個標記錯誤，就足以癱瘓整個 Agent？

這個問題的核心，在於 Agent 與大型語言模型（LLM）之間的「介面契約」過於脆弱。許多早期的 Agent 設計，為了快速實現功能，採用了一種簡單直接的方式：透過提示工程（prompting），要求模型在需要調用工具時，輸出一串特定格式的文本，例如 XML 或 Markdown 標記。接著，Agent 的後端程式碼再用正規表示式（regex）或簡單的字串解析來捕捉這些標記，並觸發相應的工具函式。

這種方法的本質是一種「隱含契約」（implicit contract）。系統設計者「假設」模型會穩定地、精確地輸出約定好的格式。然而，這個假設在面對不斷演進的 LLM 時，顯得不堪一擊，隨時可能崩潰。LLM 的輸出本質上是機率性的，即使是微小的版本更新或模型微調，都可能改變其生成特定 token 的機率分佈，進而導致格式偏離預期。Claude 的 court-loop 事件就是一個血淋淋的例子：模型在生成與「code」或「call」相關的 token 時出現了偏差，而依賴這個脆弱標記的系統便應聲倒下。

從這個案例中，我們可以看到兩種截然不同的設計思路：

脆弱的隱含契約：依賴自然語言提示來約束輸出格式，並透過解析非結構化或半結構化的文本（如 XML/Markdown 標籤）來觸發功能。這種方式開發快速，但極度不穩定，且難以除錯。
穩健的顯式契約：使用明確、結構化的格式（如 JSON Schema）來定義介面，並在執行前進行嚴格的驗證。這種方式雖然前期投入較高，但提供了強大的穩定性與可預測性。

當 Agent 的任務越複雜、工作鏈越長，隱含契約的風險就越高。一個微小的解析錯誤，可能在多步驟任務的後期引發連鎖反應，最終導致整個任務失敗，且難以追溯問題根源。

如何設計更穩健的 Agent 介面契約？

從 court-loop 的教訓中，我們可以提煉出設計穩健 Agent 介面的三個關鍵原則：可驗證性、可恢復性與可降級性。這不僅是技術選擇，更是從「提示工程」邁向「協定工程」（protocol engineering）的思維轉變。

1. 可驗證性（Verifiability）

放棄解析鬆散的文本標籤，轉而採用業界標準的結構化資料格式。例如，OpenAI 的 Function Calling 與 Google 的 Gemini API 都允許開發者透過 JSON Schema 來定義工具的名稱、參數與格式。當模型決定調用工具時，它會生成一個符合該 Schema 的 JSON 物件。Agent 在接收到輸出後，可以先對其進行驗證，確保格式完全正確，才執行後續操作。這將溝通的基礎從「希望模型做對」轉變為「驗證模型做對了」。

2. 可恢復性（Recoverability）

即使有了結構化輸出，模型偶爾還是會生成格式錯誤或內容不合邏輯的結果。一個穩健的系統不應在此刻直接崩潰。它需要一個恢復機制。例如，當驗證失敗時，Agent 可以將錯誤訊息連同原始請求一起回傳給模型，並明確指示：「你提供的 JSON 格式錯誤，請根據以下 Schema 修正後重新提交。」這種帶有修復性回饋的對話循環，大幅提升了系統的容錯能力。

3. 可降級性（Graceful Degradation）

在某些情況下，即使經過多次嘗試，模型仍無法提供可用的工具調用指令。此時，系統應該能夠優雅地降級。與其讓 Agent 卡在一個無限迴圈或直接報錯終止，不如讓它轉向次優方案。例如，它可以放棄使用工具，轉而向使用者回報：「我目前無法完成此項自動化操作，但我可以為您提供相關資訊。」這種設計確保了即時在部分功能失效時，核心使用者體驗依然是連貫且可用的。

Claude 的 court-loop 事件雖然只是一個小插曲，卻敲響了一個重要的警鐘。隨著我們構建日益複雜、自主的 AI Agent 系統，其穩定性與可靠性將成為決定成敗的關鍵。我們必須超越單純的提示技巧，開始嚴肅地思考和設計 Agent 與模型之間的互動協定。從脆弱的隱含假設轉向穩健的顯式契約，是打造能夠在真實世界中長期、可靠運作的 AI 系統的必經之路，也是唯一出路。正如學術界在 Agent Protocol 相關研究中不斷探索的，我們需要為 AI Agent 建立標準化、可驗證的溝通框架，而非依賴沙上城堡般的臨時約定。

延伸閱讀

我是江中喬，專注於 AI Agent Architecture、Memory Governance 與 Cognitive Diversity，持續研究如何打造能夠長期協作、可信任且可治理的 AI 系統。

失控的標籤：Claude 的 court-loop 事件