mk-brain

別再只談工具調用：Tool Use 的成敗關鍵在於 Runtime 執行管線

當業界還在為模型能否生成正確的 API 呼叫而驚嘆時，真正的產品挑戰早已轉移。決定一個 AI Agent 系統上限的，並非單次成功的工具調用，而是背後那條將意圖穩健轉化為結果的執行管線——它關乎權限、隔離、錯誤處理與回傳，是從脆弱展示到可靠服務的必經之路。

江中喬

22 6月 2026 • 6 min read

大型語言模型（LLM）的 Tool Use 能力已成為焦點，從 OpenAI 的 Function Calling 到 Google Gemini 的 Tool calling，模型生成結構化工具呼叫的能力日漸成熟。然而，業界過度關注模型能否「說對話」，卻忽略了更關鍵的後續挑戰：如何將模型的「意圖」穩健地轉化為可觀測的「結果」。真正的競爭核心，已不在於模型那一次成功的 API 呼叫，而在於建構一條能處理權限、隔離、錯誤與回傳的完整 Runtime 執行管線。這條管線的品質，直接決定了 AI 產品是停留在脆弱的展示，還是能邁向可靠的服務。

模型提案，系統執行：這個看似簡單的原則，藏著哪些陷阱？

在設計 AI Agent 系統時，一個非常重要的工程原則是「模型提案，系統執行」（Model proposes, system executes）。這意味著我們需要明確劃分邊界：模型的責任是理解使用者意圖，並以結構化的形式（例如 JSON）提出一個或多個工具執行計畫；而系統的責任，則是接收這些計畫，並在安全的環境中實際執行它們，最後將執行結果回傳給模型。

這個分界看似清晰，但魔鬼藏在細節裡。「模型提案」這部分，在 GPT-4o 或 Gemini 1.5 Pro 等頂尖模型的加持下，已經相對簡單。只要提供清楚的工具定義（function signatures），模型多半能生成格式正確的呼叫。然而，「系統執行」這部分，遠比多數人想像的複雜。它不是一個單純的函式，而是一整條充滿檢查點與安全閥的管線。

當模型說出 {"tool": "bash", "input": {"command": "npm test"}} 時，系統不能只是盲目地執行 npm test。一個生產級的系統，必須先回答一連串問題。

為什麼「系統執行」遠不只是一個函式呼叫？

以上述的 npm test 為例，一個穩健的 Runtime 在接收到這個指令後，至少需要處理以下四個階段，每個階段都可能失敗，也都需要被細緻地設計：

1. 驗證與消毒：指令安全嗎？

這個指令合法嗎？input 欄位中的參數是否符合預期格式？更重要的是，它安全嗎？如果指令是 rm -rf / 怎麼辦？系統必須有一層防禦機制，用白名單或更嚴格的規則來過濾掉潛在的惡意或破壞性指令。

2. 權限與隔離：誰能執行？在哪裡執行？

這個 Agent、這位使用者，是否有權限執行 npm test？它應該在哪裡執行？直接在主機上執行是極度危險的。一個負責任的作法，是將執行環境隔離在一個短生命週期的沙箱中，例如 Docker 容器或更輕量的 Firecracker microVM (Agache et al., 2020)。這能確保即便工具執行出錯或被惡意利用，也不會影響到系統的其他部分。

3. 執行與觀測：執行狀態如何？

指令開始執行後，系統需要監控其狀態。標準輸出（stdout）和標準錯誤（stderr）是什麼？執行時間是否超過了預設的 30 秒上限？程序是否無故掛起？系統必須能捕捉這一切「觀測結果」，而不僅僅是一個最終的成功或失敗狀態。

4. 解析與回傳：如何有效回報結果？

npm test 的輸出可能是數千行的日誌。直接將這 10MB 的原始文字丟回給模型，不僅浪費 token，也可能因為內容過於龐雜而干擾模型的後續判斷。一個好的 Runtime 會先對結果進行解析、摘要或截斷（例如只取最後 4KB 的內容），將最關鍵的資訊以清晰、簡潔的方式回傳給模型。這整個「Action-Observation」循環，正是 ReAct (Reasoning and Acting) 等 Agent 框架的核心 (Yao et al., 2022)。

這條從「意圖」到「觀測」的路徑，每一步都充滿了工程挑戰。任何一個環節的疏漏，都可能導致系統不穩定、不安全，或無法從錯誤中恢復。

如何建構一個更穩健的 Tool Use Runtime？

要將脆弱的工具調用，提升為穩健的系統能力，我認為開發者應將重心放在 Runtime 的設計上。這不僅僅是技術選型，更是一種思維模式的轉變。

首先，是徹底擁抱失敗。錯誤處理不是事後補救，而是 Runtime 的核心功能。當工具執行失敗時，系統回傳給模型的，不該只是一個冰冷的「Error」，而應是一個富含資訊的錯誤報告，例如「權限不足」、「指令超時」或「找不到指定檔案」。這樣的回饋，能讓模型有機會修正自己的計畫，嘗試另一種方法，從而提升任務的成功率。這也是 LangChain 等框架中 Agent Executor 設計的核心理念之一。

其次，是建立完善的驗證鏈路。驗證不應只發生在單一點，而應貫穿整個執行過程：從模型輸出時的 Schema 驗證，到傳入工具前的參數消毒，再到執行環境的權限檢查。每一層驗證都是一道防線，共同確保了系統的安全性與穩定性。

最後，我們必須意識到，Tool Use 的競爭力，最終將體現在這些看似枯燥的工程細節上。當所有人的模型都能生成相似的工具呼叫時，真正能拉開差距的，是誰的 Runtime 更安全、更有效率、更能從失敗中學習。一個能將 10MB 日誌精準摘要成 1KB 關鍵資訊的 Runtime，遠比一個只會盲目執行指令的系統，能賦予 AI Agent 更高的智慧上限。

總結來說，Tool Use 的浪潮才剛開始，但焦點需要轉移。與其不斷追求模型生成指令的精準度，不如將心力投入到建構一個能將這些指令穩健、安全地轉化為現實世界影響的 Runtime 執行管線上。這條「最後一哩路」，才是決定 AI 產品能否真正落地的關鍵。