Agent 表現不如預期？問題可能不在模型，而在你的 Tool Schema

在建構 AI Agent 時，我們常將效能不彰歸咎於底層大型語言模型（LLM）的能力，期待更強的模型能解決一切。然而，根據我的實務經驗，真正的效能瓶頸——無論是推理成本還是執行精度——往往深藏在更前端的「工具定義」（Tool Schema）之中。精細設計工具的名稱、描述、參數與回傳格式，才是決定 Agent 系統能否穩定高效運作的關鍵，也是工程上最值得投入的槓桿點。這篇文章將深入探討如何透過優化 Tool Schema，從根本上提升 Agent 的表現。

為什麼 Tool Schema 是 Agent 效能的關鍵槓桿？

要理解這個問題，我們必須回到 LLM 運作的第一性原理。當我們為 Agent 提供一組工具時，模型並不是真的「理解」了這些工具的程式碼邏輯。實際上，模型是透過我們提供的 JSON Schema，在每一次的推理中進行「脈絡內學習」（In-Context Learning）。換句話說，你寫的工具 schema，會被直接注入到 prompt 的系統訊息中，成為模型決策的唯一依據。

一份模糊、冗長或有歧義的 schema，就像是給一位聰明的員工一份寫得不清不楚的工作指南。他或許能猜對幾次，但更多時候會犯錯、會需要反覆確認，甚至會選擇一個完全錯誤的工具。這不僅會導致任務失敗，更會在過程中消耗大量的 token，直接拉高了 API 的呼叫成本。反之，一份精準、簡潔且具備良好約束的 schema，則能有效引導模型的「思緒」，讓它在龐大的可能性中，快速鎖定正確的工具與參數組合。這正是OpenAI 官方文件中不斷強調「提供詳細的工具描述」的核心原因。

精準的 Tool Schema 該如何設計？掌握命名與參數約束的原則

一份好的 Tool Schema 設計，應該像是在撰寫一份給機器的「契約」。契約條款越清晰，雙方（模型與工具）的協作就越順暢。根據業界的最佳實踐，我們可以歸納出幾個關鍵的設計原則：

首先，明確且無歧義的命名是基礎。工具名稱（function name）與參數名稱（parameter name）應直觀反映其用途，例如 get_current_stock_price 就遠比 fetch_data 更能讓模型理解其功能。務必避免使用內部行話或縮寫，讓模型能僅從名稱就大致猜到工具的意圖。

其次，為模型撰寫精準的描述至關重要。工具與參數的 description 欄位是整個 schema 的核心，因為它的讀者不是人類，而是 LLM。因此，描述應清楚說明「這個工具/參數是什麼」、「什麼時候該使用它」，以及「它接受什麼樣的輸入」。舉例來說，在一個查詢訂單的工具中，參數 order_id 的描述不應僅是「訂單 ID」，而應是「用戶想查詢的訂單編號，必須是符合 ORD-XXXX-XXXX 格式的字串」，提供具體的格式要求。

最後，善用強型別與約束能大幅提升模型的準確性。盡可能使用最嚴格的資料型別，例如當參數只接受固定選項時，應使用 enum 來明確定義，而非讓模型自由猜測。例如，unit 參數可定義為 {"type": "string", "enum": ["celsius", "fahrenheit"]}。對於數值，可設定 minimum 和 maximum 範圍；對於字串，則可透過正規表達式 pattern 進行格式約束。這些嚴謹的約束能有效縮小模型的推理空間，避免生成無效的 API 呼叫，從而減少錯誤與重試成本。

請記住，Tool Schema 中的每一個欄位，都是在為模型的推理過程提供「線索」與「護欄」。你給的線索越清晰、護欄越穩固，模型走錯路的機率就越低。

如何設計 Tool Response 來大幅降低 Token 成本？

除了工具的「輸入」定義，工具執行後的「輸出」（回傳值）同樣是影響成本與效能的關鍵。當一個工具被呼叫後，其回傳結果會被重新注入到對話歷史中，成為模型下一步決策的依據。如果這個回傳值是一個未經處理、包含大量無用資訊的巨大 JSON 物件，將會迅速佔滿模型的 context window。

根據日本技術部落格 zenn.dev 的實證分享，僅僅是透過精簡化工具的回傳內容，就能夠將整趟 Agent 任務的 Token 消耗降低超過 60%。關鍵在於，回傳給模型的，不應該是 API 的原始響應（raw response），而應該是經過處理、僅保留「模型下一步決策所需的最少資訊」的結果。

例如，一個查詢使用者資訊的 API 可能會回傳包含註冊時間、登入 IP、個人頭像 URL 等 20 個欄位。但如果 Agent 的當前任務只是為了確認使用者的會員等級，那麼工具的回傳值就應該只是一個簡單的字串，如「使用者 John Doe 的會員等級為：Gold」。這種作法不僅能省下大量 token，也能避免無關資訊干擾模型的後續判斷。

當工具越來越多，如何維持高準確度？

隨著 Agent 系統變得複雜，工具的數量也可能從個位數增長到數十甚至上百個。當工具集超過一定規模（例如 30 個以上）時，將所有工具的 schema 一次性塞給模型，會導致兩個嚴重問題：一是 prompt 長度暴增，成本急遽上升；二是資訊過載，模型在眾多工具中進行選擇的準確度會顯著下降，這種現象在學術界被稱為「Lost in the Middle」。

對此，目前主流的解決方案是引入「動態工具發現」（Dynamic Tool Discovery）或稱 「Tool Search」機制。這是一種巧妙的兩階段作法：首先是檢索（Retrieval）階段，當使用者提出請求時，系統會利用一個更輕量級的模型或常見的向量搜尋（Vector Search）技術，根據請求的語意，從整個工具庫中檢索出一個小規模、最相關的候選工具子集（例如 3-5 個）。接著進入執行（Execution）階段，系統才將這個精選過的小型候選工具子集，連同使用者的原始請求，一起提交給主要的大型語言模型（如 GPT-4o 或 Claude 3.5 Sonnet）進行推理與工具呼叫。

這種分層式的作法，確保了主要模型總是在一個乾淨、低噪音的環境中做決策，從而能在維持高精度的同時，有效管理大規模工具集。這也是如 Toolformer 和 Gorilla 等研究中所探討的核心思想之一，並被 Anthropic 的官方文件所推薦。

總結來說，打造一個高效能的 AI Agent，與其不斷追求更大、更新的模型，不如將心力投注在更基礎的工程設計上。從工具的命名、描述、參數約束，到回傳值的管理，再到大規模工具集的檢索策略，每一個環節都是我們可以施力的槓桿。這些看似微小的細節，最終將會決定你的 Agent 系統是穩定可靠，還是充滿意外。

延伸閱讀

• OpenAI: Function calling guide
• Anthropic: Tool use (function calling) documentation
• Gorilla: Large Language Model Connected with Massive APIs
• AIエージェントのツール定義設計原則 by 0h_n0 on Zenn

我是江中喬，一位具有 TPM 與產品管理背景的 AI 系統建構者，目前專注於 AI 認知增強系統與多 Agent 協作架構的設計與實踐。