上一頁展示了如何將大型語言模型包裝在代理程式中，從而賦予你持久的身份、管理指令和會話。 但即使如此，客服人員只能產生內容（文字、圖片等）——無法查詢今日股價、發送電子郵件或查詢你的資料庫。 它會根據訓練時所建立的知識，以及你在提示中提供的背景來回答。
工具縮短了這個落差。 它們賦予代理以行動的能力——使其能超越訓練資料，與現實世界互動。 新增工具是讓經紀人真正有用的最具影響力的一步。
何時使用
在以下情況下，為你的經紀人新增工具：
- 客服人員需要存取模型訓練資料中不存在的即時 或外部資料 ——即時價格、天氣、資料庫紀錄、搜尋結果。
- 客服人員需要 採取行動 ——發送電子郵件、建立工單、呼叫 API、撰寫檔案——而不僅僅是產生內容。
考慮事項
| 考量事項 | 詳細資料 |
|---|---|
| Latency | 每次工具呼叫都會增加一次系統呼叫循環——模型生成工具請求，你的程式碼執行該請求，並將結果返回，然後模型才能繼續。 多工具轉彎更是雪上加霜。 |
| 代幣開銷 | 每個提示中都包含工具定義（名稱、描述、參數結構）。 工具越多，可用於對話歷史和模型回應的代幣就越少。 |
| 除錯複雜度 | 當出錯時，原因可能在於模型的工具選擇、所選參數，或工具的執行方式。 你是在同時除錯推理 和 程式碼。 |
| 可靠性 | 模型可能會錯誤呼叫工具、傳遞錯誤的參數，或在不該調用工具時卻調用工具。 良好的描述和 工具審核 可以減輕這個問題，但不要完全消除它。 |
為什麼客服人員需要工具
如 LLM 基礎課程所述，LLM 會被訓練產生代幣——包括一種特殊的結構化格式，代表工具呼叫。 但模型本身從不執行任何事情。 是你的應用程式（或代理框架）解析模型的輸出，執行實際函式，並將結果回饋回來。
這表示工具不會 改變模型本身 ——它們改變的是你的代理人能 做什麼。 缺少工具時，代理人就是會談者。 有了工具，它就成為了操作員。
考慮找旅遊訂票代理。 沒有工具，它只能根據一般知識討論航班並建議行程。 有了工具，它可以：
- 搜尋 航班 API 以獲取即時可用性與價格
- 代用戶預訂機票
每一項行動都需要一個工具——一段代理可以調用來與外界互動的程式碼。
工具呼叫迴路的運作方式
當你給代理工具時，代理框架會自動管理 一個工具呼叫迴圈：
┌──────────────────────────────────────────────────────┐
│ User: "What's the weather in Seattle?" │
└──────────────┬───────────────────────────────────────┘
▼
┌──────────────────────────────────────────────────────┐
│ Agent sends messages + tool definitions to LLM │
└──────────────┬───────────────────────────────────────┘
▼
┌───────────────┐
│ LLM responds │
└───┬───────┬───┘
│ │
Tool call? No ──────────────────────────┐
│ │
▼ ▼
┌─────────────────────────────┐ ┌─────────────────────────────┐
│ Agent Framework executes │ │ Final response: │
│ the tool (e.g., │ │ "It's cloudy in Seattle │
│ get_weather("Seattle")) │ │ with a high of 15°C." │
└──────────────┬──────────────┘ └─────────────────────────────┘
│
▼
┌─────────────────────────────┐
│ Agent sends tool result │
│ back to the LLM │
└──────────────┬──────────────┘
│
└──────► (back to "LLM responds")
關鍵點：
- 你不需要寫循環。 代理框架負責偵測模型回應中的工具呼叫、執行工具，並將結果回饋回來。 你定義工具;框架負責安排剩下的部分。
- 每回合呼叫多次工具。 模型可能會呼叫多個工具（有可能同時進行），然後產生最終答案——或是進行鏈式工具呼叫，其中一個工具的輸出用於下一個工具。
- 模型決定何時呼叫工具。 根據使用者的需求及你提供的工具描述，模型會判斷是否需要該工具。 良好的工具描述能帶來更好的工具選擇。
小提示
若想親手操作如何新增第一個工具並觀察這個循環的運作，請參考「入門」教學中的 步驟 2：新增工具 。
工具類型
代理框架支援多種工具類別。 選擇合適的方案取決於你需要代理人做什麼，以及該功能所在的位置。
功能工具
函式工具 是你寫入並註冊給代理的自訂函式。 它們會直接運行在你的流程中，讓你完全掌控邏輯、安全邊界和錯誤處理。
在以下情況下使用功能工具：
- 你有代理需要呼叫的自訂商業邏輯（查詢資料庫、呼叫內部 API、執行計算）
- 你需要一個工具能在你的環境中運行，並且能存取你的資源
- 你想要的是編譯時的安全性與可測試性
功能工具是最常見且具彈性的工具類型。 大多數經紀人都是從這裡開始。
MCP 工具（模型上下文協定）
MCP 是一個開放標準，定義應用程式如何為大型語言模型提供工具。 你不需要自己寫工具邏輯，而是連接到一個 MCP 伺服器 ，透過標準協定暴露一組工具——類似 REST API 暴露端點的方式。
代理框架支援兩種版本：
| 滋味 | 它是什麼 | 使用時機 |
|---|---|---|
| 託管 MCP 工具 | 由 Microsoft Foundry 或其他供應商托管和管理的 MCP 伺服器 | 你想要的是對常見功能（例如檔案搜尋、程式碼執行）的交鑰匙存取，而不必管理基礎設施 |
| 本地 MCP 工具 | 你可以自己運行或連接任何供應商的 MCP 伺服器 | 你有自訂或第三方的 MCP 伺服器，或者需要能在自己環境中執行的工具 |
在以下情況下使用 MCP 工具：
- 一台預建的 MCP 伺服器已經具備你所需的功能
- 你希望透過共用伺服器在多個代理或應用程式間重複使用工具
- 你正在與第三方服務整合，該服務會暴露 MCP 端點
由提供者主機代管的工具
有些供應商提供內建工具，可在供應商的基礎設施上運行——不需要本地程式碼。 這些包括：
| Tool | 其功能是什麼 |
|---|---|
| 程式碼解譯器 | 在供應商基礎設施上的沙盒環境中執行程式碼 |
| 檔案搜尋 | 搜尋你上傳給服務提供者的檔案 |
| 網路搜尋 | 在網路上搜尋即時資訊 |
以下情況下使用提供者託管工具：
- 你需要像程式碼執行或網頁搜尋這類功能，而不是自己開發或維護這些工具。
- 該服務提供者已經提供符合您需求的託管版本
備註
提供者託管工具的可用性因供應商而異。 完整提供者支援矩陣請參閱 工具概覽 。
備註
部分大型語言模型提供者在進行推論時，在其基礎架構上執行託管工具，例如 OpenAI 的 回應 API。 可以把這些推論服務想像成結合推理與工具執行的半代理服務。 這不會改變底層模型的運作方式，但代表工具的執行可以作為服務回應產生的一部分。 這些服務無法執行本地工具，必須在您自己的基礎設施上執行。
選擇合適的工具類型
| 問 | 建議 |
|---|---|
| 我有自訂的商業邏輯嗎？ | 函式工具 — 自行撰寫並註冊函式 |
| 有沒有已經能滿足我需求的 MCP 伺服器？ | MCP 工具 — 直接連接它，而非從零開始建置，例如 GitHub MCP 伺服器 |
| 我需要執行程式碼、檔案搜尋還是網頁搜尋？ | 服務提供者託管的工具 ——請確認你的服務提供者是否支援 |
| 我需要來自多個類別的工具嗎？ | 混合使用 ——代理可以同時使用功能工具、MCP 工具和提供者託管的工具 |
工具描述很重要
模型根據 工具名稱和描述選擇工具。 模糊的描述會導致工具選擇不佳——模型可能呼叫錯誤工具、跳過應該使用的工具，或傳遞錯誤參數。
寫工具描述就像寫 API 文件一樣：說明工具的功能、每個參數的意義，以及它回傳的內容。 描述越清楚，模型的判斷力就越好。
小提示
工具定義（名稱、描述、參數結構）包含在提示詞中，並在上下文視窗中消耗代幣。 如果你註冊很多工具，開銷可能會相當可觀。 只登記代理人真正需要的工具。
工具核准：人機互動
有些行為很敏感——轉帳、刪除紀錄、發送電子郵件。 你可能不希望代理自動執行這些工具。 工具核准 讓你在工具執行前需要人工確認。
當工具被標記為需要核准時，代理會在執行前暫停並回傳需要核准的回應。 你的應用程式負責向使用者呈現這些資訊並將他們的決定傳回去。
這種模式通常稱為人機互動，對於建立可信的代理來處理具影響力的行動至關重要。
常見陷阱
| 潛在問題 | 指導 |
|---|---|
| 工具太多了 | 每個工具定義都會消耗代幣。 只登記與代理人目的相關的工具。 |
| 模糊描述 | 「用資料做事」對模型沒有幫助。 具體說明：「在庫存資料庫中根據 SKU 檢索產品的可用性。」 |
| 沒有錯誤處理 | 工具可能會失效（網路錯誤、輸入無效）。 回傳明確的錯誤訊息，讓模型能推理出錯原因，再嘗試或通知使用者。 |
| 過於開放的工具 | 一個能「執行任何 SQL 查詢」的工具會帶來安全風險。 針對特定且明確定義的作業，將工具用於其範圍。 |
| 敏感行動未獲得批准 | 如果工具能做出不可逆的變更，就加入 工具審核 ，讓人工持續掌握進度。 |
特別提及：Code Interpreter Tool
如同《 LLM Fundamentals》中所述，LLMs 在精確計算與形式邏輯中可能會出錯。 這是因為大型語言模型（LLM）是根據模式匹配逐個詞元產生答案，實際上並不計算。 一個被要求將兩個大數字相乘的大型語言模型並不是在實際執行算術運算；它是在根據訓練數據預測出答案的「樣子」。 這種方法出乎意料地常有效，但在極端情況下卻無法預測地失效。
Code Interpreter 透過讓代理在沙盒環境中撰寫並執行程式碼來解決這個問題。 模型不是猜答案，而是寫出一個 Python 腳本，精確計算、執行，並在回應中使用已驗證的結果。
備註
模型每次被要求解決相同問題時，可能會寫出略有不同的腳本，但結果 應該大致一致 。
警告
程式碼解譯器並不能取代人類的謹慎推理。 務必檢查代理人的工作，必要時獨立驗證結果。
當需要時，為你的代理程式提供 Code Interpreter：
- 進行精確計算 ——財務建模、統計分析、單位換算——當近似的「最佳估計」無法被接受時。
- 轉換或分析資料 ——解析 CSV、彙整列、產生圖表或重塑結構化資料。
- 處理檔案 — 閱讀上傳的文件、擷取內容、轉換格式或產生新檔案。
- 驗證自身推理 ——撰寫測試程式碼驗證邏輯主張，再向使用者呈現。
小提示
Code Interpreter 可以是提供者託管的工具——程式碼會在提供者的基礎設施沙盒上運行，而非在你的環境中。 這樣一來，使用起來就很安全，不用擔心伺服器上會執行任意程式碼。 請參閱 程式碼解譯器參考資料 以了解設定細節。
下一步
當你的經紀人擁有工具後，下一步就是學習 技能 ——攜帶式的說明包、參考資料和腳本，讓經紀人能隨時載入領域專業知識。
深入探討：