為什麼 Tool Use 是 Agentic AI 的核心？
如果說 LLM 是 Agent 的「大腦」，那麼工具（Tools）就是它的「手腳」。沒有工具使用能力，AI 只能在對話框內打轉；有了工具，它才能真正採取行動——查詢資料庫、呼叫 API、執行程式、甚至控制瀏覽器。
這個轉變，讓 AI 從「知道怎麼做」進化到「真的去做」。
什麼是 Function Calling？
Function Calling 是目前主流 LLM（如 GPT-4o、Claude 3.5、Gemini 1.5）實現工具使用的標準機制。其運作流程如下：
- 開發者定義工具清單：以 JSON Schema 描述每個工具的名稱、參數與說明
- LLM 判斷是否需要呼叫工具：根據使用者的請求與上下文決定
- LLM 回傳結構化的工具呼叫請求：包含工具名稱與參數值
- 應用層執行工具：由外部程式實際執行並取得結果
- 結果回饋給 LLM：模型根據工具回傳繼續生成最終回應
💡 關鍵重點：LLM 本身不執行工具，它只負責「決定要呼叫哪個工具、帶什麼參數」。實際執行永遠在應用層。
工具設計的三大原則
1. 單一職責（Single Responsibility）
每個工具只做一件事，且做好一件事。避免設計「萬能工具」——這會讓模型難以判斷何時使用，也增加出錯機率。
- ✅
search_web(query)— 搜尋網路 - ✅
read_file(path)— 讀取檔案 - ❌
do_everything(instruction)— 模糊不清
2. 清晰的描述（Clear Description）
工具的描述直接影響 LLM 的判斷品質。好的描述應該包含：
- 做什麼：工具的核心功能
- 什麼時候用：適用場景
- 回傳什麼：輸出格式與內容
3. 可預測的輸出（Predictable Output）
工具回傳的結果要穩定、結構化。隨機的錯誤訊息或不一致的格式，會讓 Agent 陷入困惑甚至無限重試迴圈。
Tool Use 與 MCP 的關係
隨著 Agentic AI 生態成熟，工具整合的碎片化問題越來越嚴重——每家 Agent 框架都有自己的工具格式，難以互通。
Model Context Protocol（MCP） 正是為了解決這個問題而生。它定義了一套標準的工具描述與呼叫協議，讓工具可以跨 Agent、跨框架複用。
你可以把 MCP 想像成工具界的「USB-C 標準」——不管什麼裝置，插上去就能用。
詳細的 MCP 介紹可參考：MCP 協議完整解析
實戰範例：一個簡單的資料查詢 Agent
tools = [
{
"name": "query_database",
"description": "查詢產品資料庫，回傳符合條件的產品清單。適合用於搜尋特定產品或篩選條件。",
"parameters": {
"type": "object",
"properties": {
"keyword": {"type": "string", "description": "搜尋關鍵字"},
"category": {"type": "string", "description": "產品分類（可選）"}
},
"required": ["keyword"]
}
}
]
# Agent 會自動判斷何時呼叫 query_database
# 並將結果整合進最終回覆
常見陷阱與解法
| 陷阱 | 症狀 | 解法 |
|---|---|---|
| 工具太多 | 模型不知道選哪個 | 分組、加強描述、動態載入 |
| 描述模糊 | 工具被誤用 | 加入使用範例與禁用場景 |
| 錯誤處理不足 | Agent 無限重試 | 統一錯誤格式，加入 fallback |
| 工具回傳過多資訊 | Token 爆炸、回應變慢 | 截斷、摘要、分頁 |
小結
Tool Use 是讓 AI Agent 真正「有用」的關鍵能力。設計好的工具清單，搭配清晰的描述與可靠的執行層，才能讓 Agent 在複雜任務中穩定發揮。
下一步，你可以進一步了解 Agentic RAG 如何結合工具使用與動態檢索，或參考 Multi-Agent Orchestration 來設計多 Agent 協作的工具分工策略。