Tool Use（工具使用）是 Claude API 的一個核心功能，讓 Claude 在生成回答時能主動呼叫你定義的外部功能。在沒有 Tool Use 的情況下，Claude 只能輸出文字；有了 Tool Use，Claude 能搜尋網路、查詢資料庫、執行程式碼、存取文件系統——任何你能用函式實作的功能，Claude 都能在對話中直接使用。
Tool Use 的運作流程：
你在 API 請求裡定義工具清單（每個工具有名稱、描述、輸入參數的 JSON Schema）。Claude 讀取用戶的輸入，分析是否需要呼叫工具——如果需要，Claude 暫停生成文字，輸出一個「工具呼叫」（tool call），包含要呼叫的工具名稱和參數。你的應用程式接收這個工具呼叫、執行對應的函式、把結果回傳給 Claude。Claude 收到工具結果後，整合進上下文，繼續生成最終的回答。
這個流程可以在一次回應裡重複多次（Claude 呼叫一個工具、看結果、再決定呼叫另一個工具），形成多步驟的 Agent 行為。Claude 4 還支援「平行工具呼叫」——在一次回應裡同時呼叫多個工具，大幅提升複雜任務的執行效率。
工具定義的品質是 Tool Use 成敗的關鍵，特別是工具的 description 欄位。
Claude 決定「要不要呼叫這個工具、什麼時候呼叫」完全依賴它對工具描述的理解。一個模糊的描述（「執行操作」）讓 Claude 不知道什麼時候用它；一個精準的描述讓 Claude 能在對的時機做出正確的呼叫決策。
好的工具描述應包含：這個工具做什麼（功能說明）；什麼情況下應該使用它（適用場景）；什麼情況下不應該使用（排除場景）；輸入參數的含義和格式要求。
對比範例：
差的描述："Searches for information."
Claude 不知道這個工具是搜尋哪種資訊、什麼時候應該用它、和其他工具有什麼區別。
好的描述："Searches the web for current news and recent information published in the last 7 days. Use when the user needs up-to-date information that may not be in training data (recent events, current prices, latest releases). Do NOT use for general knowledge questions or historical information."
Claude 能精確理解這個工具的適用範圍，在對的時機用它，在不該用的時候忽略它。
工具名稱也很重要：用動詞開頭的清晰名稱（search_recent_news、get_stock_price、query_customer_db）比模糊的名稱（tool1、information）讓 Claude 更容易做出正確決策。
平行工具呼叫（Parallel Tool Calls）是 Claude 4 系列的重要能力升級，值得單獨說明。
在 Claude 3 時代，Tool Use 是串行的：Claude 呼叫一個工具、等結果、再決定是否呼叫下一個工具。這讓涉及多個工具的任務延遲很長（假設每個工具呼叫需要 500ms，10 個工具就要 5 秒）。
Claude 4 支援平行工具呼叫：在一次回應裡，Claude 可以同時輸出多個工具呼叫（例如同時呼叫 get_weather、get_news、get_stock_price），你的應用程式並行執行這些函式，把所有結果一起回傳，Claude 整合後生成回答。
實際效益：一個需要呼叫 5 個工具的任務，串行需要 2-3 秒（每個工具 400-600ms），平行只需要最慢那個工具的時間（通常 600-800ms）——速度提升 3-5 倍。
實作時的注意事項：確保你的工具執行程式碼能支援並發呼叫（使用 asyncio 或 ThreadPoolExecutor），否則平行呼叫實際上還是串行執行，沒有速度優勢。在 API 層面，平行工具呼叫不需要額外設定，Claude 4 會自動在它判斷可以並行的情況下輸出多個工具呼叫。
Tool Use 的錯誤處理和最佳實踐，這部分很多教學都沒有講清楚。
工具執行失敗的正確處理方式：工具執行時可能發生各種錯誤（網路超時、API 限流、資料不存在）。正確的做法是返回一個結構化的錯誤結果，而不是讓應用程式直接拋出異常：
{"error": true, "error_type": "rate_limit", "message": "API rate limit exceeded. Retry after 60 seconds.", "retry_after": 60}
Claude 收到這樣的結構化錯誤後，能做出有意義的回應（告訴用戶需要等待、嘗試替代方法、或者解釋為什麼無法完成），而不是輸出一個無意義的錯誤訊息。
工具結果的格式設計：返回足夠但不過多的資訊。工具返回 5,000 個字的原始 JSON，比工具返回精選的 300 字結構化摘要，往往讓 Claude 產生更差的輸出——太多資訊讓 Claude 難以識別哪些是真正重要的。
跟你的開發有什麼關係：如果你在用 Claude API 開發應用，Tool Use 是從「問答機器人」升級到「能完成任務的 Agent」的關鍵技術。最值得投入的優化點：精心設計工具的 description（這直接影響 Claude 的呼叫準確率），以及設計清晰的錯誤回傳格式（這讓 Claude 能優雅處理失敗情況）。
一個客服 AI 系統，說明 Tool Use 在實際應用裡的設計決策：
這個系統有三個工具：query_order_status（查詢訂單狀態）、search_faq（搜尋常見問答）、escalate_to_human（轉接人工客服）。
工具描述設計的好壞如何影響結果：
壞的 query_order_status 描述：「查詢訂單資訊。」
→ 客戶問「我的包裹什麼時候到？」，Claude 可能不確定該用這個工具還是直接回答，導致呼叫不穩定。
好的 query_order_status 描述：「查詢特定訂單的當前狀態、預計到達日期和物流追蹤資訊。當客戶詢問訂單進度、包裹位置、預計送達時間時使用。需要參數：order_id（從對話中提取）或 customer_email（當客戶沒有提供訂單號時用來查詢）。」
→ Claude 能在客戶問「我的包裹什麼時候到？」時，立刻決定呼叫這個工具、提取對話裡的 order_id 作為參數，準確率大幅提升。
平行工具呼叫的實際效益：當客戶說「我的訂單延誤了，這個問題你們官網有說明嗎？」，Claude 能同時呼叫 query_order_status（查訂單狀態）和 search_faq（搜尋延誤相關的常見問答），兩個查詢並行執行，整合後在一次回應裡同時告知訂單狀態和官網說明，延遲從 1.2 秒降到 0.7 秒。
Tool Use 的核心取捨是「能力擴展 vs 複雜度和延遲增加」。沒有工具的 Claude 只能輸出文字，但回應速度最快、實作最簡單；有工具的 Claude 能採取真實行動，但每次工具呼叫都增加延遲（工具執行時間 + 一次額外的 API 往返），實作複雜度也大幅提升（需要處理工具執行邏輯、錯誤處理、並發控制）。在這個取捨上，合理的選擇是「只給 Claude 它真正需要的工具」——工具越多，Claude 在選擇工具時的判斷負擔越大，反而可能降低整體準確率。一個有 3-5 個精心定義的工具的 Agent，通常比一個有 20 個工具但描述模糊的 Agent 效果更好。