mk-brain

模型 Tool Call 的失靈模式有家族性，這如何改變我們對 Agent 可KO性的診斷框架？

當 AI Agent 的工具調用（Tool Call）失敗時，我們常視為隨機錯誤。但近期實驗揭示，這些錯誤模式其實帶有「家族特徵」，與模型系出同源。這意味著，修復工具的有效性，取決於它與特定模型「家族」的錯誤模式是否匹配。本文將探討如何從單點修補，轉向建立一套系統性的診斷框架，打造真正可維護的 AI 系統。

江中喬

12 7月 2026 • 7 min read

在建構 AI Agent 時，我們常將模型 Tool Call 的失敗視為一種隨機、難以預測的雜訊，並試圖用通用的修復器（repairer）來解決。然而，這種方法忽略了一個根本問題：模型的錯誤模式並非隨機，而是帶有深刻的「家族特徵」。近期一項針對多款模型的橫斷測試揭示，修復工具的成效，高度取決於它和特定模型家族「失靈模式」的相容性。這意味著，我們需要超越單點的修補技巧，建立一套更系統性的診斷框架，才能打造出真正可維護、可信任的 Agent 工具鏈。這不僅是技術選擇，更是架構思維的轉變。

為什麼 Agent 的工具調用總是壞得莫名其妙？

任何投入過 AI Agent 開發的工程師，都可能遇過類似的挫折：一個在 GPT-4o 上運行順暢的工具調用邏輯，換到 Llama 3 或 Qwen2 上就可能出現各種預料之外的格式錯誤。有時是 JSON 格式不完整，有時是參數被遺漏，有時甚至是模型產生了幻覺般的工具名稱。我們通常的反應是加上更多的防錯、重試機制，或導入一個外部的語法修正工具，期望能「一勞永逸」。然而，這些看似獨立的、隨機的錯誤，背後往往隱藏著更深層的規律。模型的行為，深受其訓練資料、架構設計與微調策略的影響。

就像人類的兄弟姐妹會有相似的口音或慣用詞，來自同一個基礎模型家族（例如 Mistral-7B 與其微調變體）或採用相似訓練方法的模型，在處理結構化輸出（如 Tool Call）時，也傾向於犯下類似的錯誤。把這些錯誤當作獨立事件來處理，就像只治療症狀而不探究病因，效果自然有限，且系統會變得越來越脆弱、難以維護。

實驗如何揭示 Tool Call 的「家族性失靈」？

日本開發者 zephel01 進行的一項橫斷測試，為「錯誤家系」這個觀點提供了具體的數據支持。該實驗測試了 6 款以「Tool Call 不穩定」著稱的模型，並比較了三代不同版本的修復器對其錯誤的修正效果。結果相當驚人：

高度的選擇性： 同一個修復器，對不同模型的改善效果天差地別。例如，某個版本的修復器能將 Qwen2.5-Coder (1.5B) 和 Mistral (7B) 的 Tool Call 成功率從 0% 一舉提升到 100%。
版本敏感性： 實驗中，由於一次意外使用了較舊版本的修復器（v2.7.0），發現它對某些模型的錯誤完全無效；但更新到新版（v2.7.1 或 R4）後，成功率卻能大幅提升。這證明修復器並非越新越好，而是需要與目標模型的特定錯誤模式「配對」。
非線性改善： 對於 Phi-3-mini，修復器能將其成功率從 0% 提升至 80%，但無法達到完美。這暗示了某些模型的錯誤模式更為複雜或獨特，需要更具針對性的修復策略。

這個實驗最關鍵的啟示是，Tool Call 的失敗與修復，不是一個簡單的「成功/失敗」二元問題，而是一個關於「匹配度」的系統工程問題。模型的錯誤模式有其「血統」，而修復器也必須針對這些特定的「遺傳缺陷」來設計。

我們應該停止尋找萬能的「銀彈」，而是開始繪製一份模型錯誤模式與修復策略之間的「相容性地圖」。

如何建立一套 Agent 可靠性的診斷框架？

理解了「錯誤家系」的概念後，我們應該如何將它應用於實務，打造更穩健的 Agent 系統？關鍵在於從「被動修補」轉向「主動診斷」。這需要建立一個包含以下元素的框架：

1. 錯誤模式的定性與定量分析

當選擇一個模型用於 Agent 任務時，第一步不應是直接開發功能，而是對其在目標任務上的錯誤模式進行系統性分析。這類似於軟體工程中的壓力測試。我們可以使用像 ToolBench 或 Gorilla 這類評測基準，針對性地生成大量 Tool Call 請求，並將失敗案例分類。是 JSON 語法錯誤？參數類型錯誤？還是邏輯層面的幻覺？將這些錯誤模式量化，就能為每個模型建立一份獨特的「體檢報告」。

2. 修復器的版本化與模組化

不要將修復邏輯視為一個單一、龐大的黑盒子。應該將其拆解成針對特定錯誤模式的模組化元件。例如，一個模組專門處理括號不匹配，另一個處理多餘的結尾逗號。每個模組都應該有清晰的版本號。這樣，我們就可以根據模型的「體檢報告」，像組裝樂高一樣，為它配置一個最適合的修復器組合。這種方法遠比試圖用一個通用工具解決所有問題來得更有效且可控。

3. 建立模型與修復器的相容性矩陣

隨著團隊測試的模型和開發的修復器模組增加，應該建立並維護一份「相容性矩陣」。這個矩陣的橫軸是模型（如 Qwen2-7B-Instruct、Mistral-7B-Instruct-v0.2），縱軸是修復器模組及其版本。矩陣中的數值可以是測試出的修復成功率。這份矩陣將成為團隊的寶貴資產，讓新專案在技術選型時，能基於數據做出明智決策，而不是依賴直覺或反覆試錯。

從根本上說，這種框架是將 LLM Agent 的可靠性工程，從一門「藝術」轉變為一門「科學」。我們不再是面對著一個喜怒無常的黑盒子祈禱它正常工作，而是像醫生一樣，透過診斷、分析，為它開出精準的「處方」。這或許會增加前期的投入，但從長遠來看，它能大幅降低系統的維護成本，並為打造真正能夠在生產環境中穩定運行的 AI Agent 奠定堅實的基礎。這也是從學術研究（如 OpenAI 的 Function Calling）走向工業級應用的必經之路。