AI 工具呼叫失敗怎麼查？從 Tool Calling 到權限、重試與錯誤回覆的完整診斷

專題編輯：Iris Hsieh｜AI 資安與治理編輯

下載 Tool Calling 故障測試矩陣（ZIP，內含 CSV）

一句「幫我新增」，其實經過數個責任邊界

使用者輸入「請為這位客戶建立客服工單」後，模型可能選擇 create_ticket 工具，並產出客戶識別、問題摘要與優先順序等參數。但在典型的應用程式整合中，模型提出的只是請求。真正檢查使用者身分、驗證參數、呼叫後端及回傳結果的是應用程式及其受控工具。OpenAI 與 Anthropic 的官方工具呼叫文件均區分模型與工具執行的角色。參考：OpenAI Function Calling、Claude Tool Use。

企業不能把「模型看起來知道怎麼操作」理解為「模型已有合法存取權」。同樣，也不能把工具設定中的說明文字當作身分驗證。後端應以受信任的登入資訊確認使用者、組織租戶與資源範圍，而不是相信模型自行產出的 user_id。

把失敗分成 5 層，比反覆改 Prompt 有效

第一層是工具選擇。模型是否選了正確工具？原本只需查詢，卻錯誤選用會寫入資料的工具，代表工具描述與可用功能需要調整。第二層是輸入驗證。即使工具名稱正確，缺漏必填參數、格式錯誤或不合規值，也應明確拒絕。第三層是權限。輸入格式正確，不代表可以跨客戶、跨部門或跨租戶讀寫。

第四層是外部系統。API 可能逾時、傳回錯誤或資料版本不同步。第五層是回覆。應用程式回傳失敗後，模型是否仍把「已提出申請」說成「已建立成功」？這是對交易狀態的不實表述，不應只當成文案細節。查清楚每一層的證據，才知道應修改模型提示、工具契約、後端權限還是整體流程。

為什麼重試會把一個錯誤放大成兩個？

若建立工單的請求送出後，網路在回覆前中斷，前端無法確定後端是否已成功。使用者按下重試，模型也可能再次呼叫工具。如果每一次請求都建立新工單，就會出現重複資料。處理有副作用的操作時，應考慮冪等性（Idempotency）：同一業務意圖的重試，在既定契約下不會產生第二次不必要的效果。

一種常見做法是由受控服務產生或驗證 idempotency key，後端將它與特定請求及處理結果關聯。當相同請求重送時，依規則回傳先前結果或辨識衝突。這不是要求所有操作都使用同一把鑰匙，也不表示不需要資料庫交易與同步控制；具體設計要符合服務的業務語意。

只讀工具與寫入工具，應採不同的審查強度

查詢公開商品資訊與建立退款申請的風險並不相同。讀取工具需處理授權、資料範圍、快取及個資遮罩；寫入工具則需額外確認業務規則、是否不可逆、重複操作、批准人與失敗補償。高風險異動不應只靠使用者在聊天中打一個「同意」就省略正式交易控管。

為了追溯問題，日誌可以記錄請求識別碼、工具名稱、匿名化參數摘要、授權判定、後端結果、耗時與重試識別碼。不要為了除錯而無限制保存完整敏感對話、客戶資料或金鑰。詳細欄位、保留期間與可查閱角色，仍應依企業政策訂定。

可複用的 Tool Calling 故障測試矩陣

上表為建議測試設計，不是已在特定企業系統完成的測試結果。應在隔離測試環境以合成資料實作，再依安全規則逐步驗證。

與既有 Tool Calling 入門文章的差別

天地人已刊的 客服 AI 為什麼答不出最新訂單？ 說明即時資料查詢與應用場景。本篇則將視角改為失敗診斷：當工具呼叫沒有完成預期動作時，要查哪一層、採取哪種修復，以及如何留下可驗收證據。二者可以交互連結，但不應在 SEO 上使用完全相同的搜尋承諾。

組織真正需要的不是「更多工具」，而是受控的工具契約

導入前先選一個低風險任務，寫清楚名稱、輸入欄位、輸出格式、授權來源、資料可見範圍、失敗碼、重試規則與核准需求。再用正常、錯誤、逾時、越權與重送的資料進行測試。達標後才逐步增加工具數量。對管理者而言，衡量指標應是正確完成率、未授權操作攔阻率、重複操作事故與人工補救比例，而非模型總共呼叫幾次 API。

Tool Calling 的核心能力，不是 AI 可以要求做多少事，而是每次要求都能被正確授權、執行、拒絕、記錄與驗收。

對同一個錯誤，四個團隊可能提出四種修法

客服主管看到 AI 回答「已建立工單」，可能認為需要修改文字；開發人員看到 API 回傳 500，認為需要修後端；資安人員發現模型可以替其他部門建立工單，認為缺少授權；營運主管則發現同一客戶有兩張重複單，認為是業務流程不一致。四種看法可能同時成立，但若沒把事件時間線拼起來，就無法知道哪一個環節先出錯。

因此應為每一個外部呼叫保存可追溯的請求識別碼，在不違反隱私政策下串起「使用者請求、工具選擇、參數驗證、後端授權、外部執行、實際回覆、模型總結」。若請求沒有真正送出，修資料庫沒用；若交易已成功但模型沒收到確認，直接重試反而可能製造重複。可觀測性不是為了蒐集更多對話，而是為了讓團隊能指出何時、何處、哪一個受控元件需要修復。

將工具契約寫成可檢查的內容

以 create_ticket 為例，工具契約至少要定義名稱與用途、必要欄位、欄位格式、可使用身分的來源、成功回傳內容及失敗碼。例如 INVALID_INPUT 代表資料格式錯誤，FORBIDDEN 代表未獲授權，UNAVAILABLE 代表服務暫時不可用。這些錯誤碼只是示意命名，正式使用應與實際 API 文件一致。

模型應根據回傳狀態採取相應動作。資料缺漏就請使用者補充；權限不足就停止操作並提供適當的處理管道；系統不可用就明確表示未能確認完成，必要時交給人工。對高風險工作，還要防止外部工具回傳內容把模型導向違規操作。工具的回傳值應被當成資料，不是無條件可信的新指令。

人工批准和權限檢查，不是同一件事

一名員工說「我同意建立退款」，不代表他具有核准退款的組織權限。批准流程通常需要確定操作人、可批准金額、客戶及訂單歸屬、交易狀態及權責分離。使用者在對話中確認一次可以是流程的一部分，但交易系統仍要驗證角色、業務規則與重複請求。對不可逆或高價值操作，可以採取先建議、再人工覆核、最後由受控服務執行的方式。

PoC 驗收如何避免只測出好看的對話？

建立一組固定的測試案例，從「正確查詢本人資料」到「要求存取他人資料」、「刻意傳入缺漏參數」、「重送同一請求」、「後端模擬逾時」都要涵蓋。測試者除了閱讀模型文字，也須核對資料庫或受控測試系統的狀態。若模型說成功但交易不存在，應判定失敗；若系統正確拒絕越權，則即使使用者沒有拿到想要的資料，也應視為安全防護正常發揮作用。

在這樣的框架下，模型版本更換只影響部分風險。工具授權、後端交易規則、網路可靠性與觀測證據仍由企業負責。這正是 Tool Calling 和「單純把聊天機器人接上 API」的治理差異。

參考資料

1. OpenAI：Function Calling。
2. Anthropic：Tool Use。
3. 天地人：Tool Calling 與企業即時資料。

圖片與素材說明

封面為原創系統關係示意，非真實監控平台畫面；節點與錯誤狀態用於說明架構。