AI智能代理工具使用：函式呼叫、結構描述與安全執行

AI智能代理工具使用是LLM請求執行外部函式的機制 — 網路搜尋、資料庫查詢、API呼叫、檔案操作 — 透過輸出結構化工具呼叫JSON，執行期攔截並對JSON Schema進行驗證，在返回工具結果前執行。LLM從不執行任何操作；它只是發出請求。執行期在任何執行前強制執行結構描述驗證、ACL檢查和步驟預算。tau-bench（2025年）顯示，參數建構錯誤是工具使用的最大失敗模式。

AI智能代理工具使用是大型語言模型請求執行外部函式的機制 — 網路搜尋、資料庫查詢、API呼叫、檔案操作或自訂業務邏輯 — 透過在其輸出中發出結構化工具呼叫，執行期攔截該呼叫，對JSON Schema定義進行驗證，執行並在下一個上下文輪次中作為工具結果返回。

工具呼叫的運作原理：請求-執行-返回迴圈

工具呼叫生命週期

每個工具呼叫都遵循相同的五步迴圈，無論使用哪個框架或提供商：

上下文設定 — 代理接收任務和可用工具清單，每個工具由名稱、自然語言描述和參數的JSON Schema定義來描述。
LLM決策 — 模型在其輸出中發出工具呼叫區塊：一個函式名稱和與聲明結構描述匹配的JSON參數物件。
執行期攔截 — 框架在任何執行發生前攔截工具呼叫。參數針對結構描述進行驗證。檢查代理的ACL：此代理是否被允許呼叫此工具？
執行 — 如果驗證和權限檢查通過，執行期執行該函式並收集其輸出。
上下文注入 — 工具結果作為工具結果輪次注入回對話上下文。LLM從這個豐富的上下文繼續推理。

關鍵架構事實：LLM從不執行任何操作。它只是請求。每個不安全的操作 — 寫入檔案、呼叫API、發送電子郵件 — 都由執行期控制。這種請求和執行之間的分離是安全代理工具使用的基礎。

提供商格式差異：OpenAI vs Anthropic vs Google

三大主要LLM提供商都原生支援工具使用，但JSON格式不同：

OpenAI（openai/openai-python，30,941顆星，Apache-2.0）：工具定義以JSON Schema物件陣列的形式放入tools參數。模型在助手訊息的tool_calls欄位中返回工具呼叫。客戶端以role: "tool"的訊息發送回工具結果。Responses API（2025年3月）新增了伺服器端執行的內建工具（web_search、file_search、computer_use）。

Anthropic（anthropic-sdk-python，3,595顆星，MIT）：工具定義放入頂層tools參數。模型在助手輪次中返回tool_use內容區塊。客戶端必須解析這些區塊並在下一個人類輪次中返回tool_result內容區塊。

Google Gemini：工具定義在tools參數內使用functionDeclarations。模型返回functionCall部分；客戶端發送functionResponse部分。Gemini支援帶有ANY模式和AUTO模式的tool_config。

這些格式在語義上等價，但在語法上足夠不同，以至於硬編碼一個提供商的約定在模型切換時會失敗。

誰真正執行工具（以及為何對安全至關重要）

LLM無法執行工具。它只能請求。當執行期在每次工具執行前強制執行ACL門時，沒有任何LLM輸出能夠繞過權限檢查。模型可以用任何參數請求delete_all_records()；如果代理的權限矩陣不包含該工具，執行期將在任何執行前拒絕該請求。

定義LLM能正確使用的工具結構描述

tau-bench（ServiceNow Research，2025年）測量GPT-4o在零售工具使用任務上的44% pass@1。最大的失敗類別不是工具選擇 — 模型選擇了正確的工具 — 而是參數建構。結構描述品質是主要的可靠性槓桿。

工具定義的JSON Schema結構

最小有效的工具結構描述需要四個欄位：

{
  "name": "search_web",
  "description": "搜尋公共網路獲取當前資訊。當任務需要訓練截止日期後的事實、即時資料或訓練資料中沒有的來源時使用。",
  "parameters": {
    "type": "object",
    "properties": {
      "query": {
        "type": "string",
        "description": "搜尋查詢。使用具體、有針對性的術語，而非完整句子。"
      },
      "max_results": {
        "type": "integer",
        "description": "要返回的最大結果數。預設為5，最多20。",
        "default": 5
      }
    },
    "required": ["query"]
  }
}

required陣列很重要：不在required中的參數是可選的。經常被省略的必要參數表明結構描述描述有問題。

編寫減少參數錯誤的描述

改善參數建構精度的工具描述三條規則：

使用動詞-名詞對命名：search_web、create_ticket、read_file。避免類似工具之間的歧義。
在描述中消除歧義：如果兩個工具看起來相似，明確說明何時使用每個工具。
用範例描述參數："搜尋查詢。範例：'LangGraph v0.2 並行工具呼叫'" 在參數準確性上優於 "查詢字串"。

常見結構描述錯誤及修復方法

錯誤	效果	修復
對分類值使用無約束的`"type": "string"`	模型發明無效值	使用`"enum": ["option_a", "option_b"]`
參數上缺少`description`	模型猜測參數語義	編寫帶範例的明確描述
所有參數都在`required`中	可選欄位未知時模型拒絕呼叫	只列出真正必要的參數
模糊的工具名稱（`process`、`handle`）	模型無法區分相似工具	使用動詞-名詞：`submit_form`、`parse_date`
沒有`required`陣列	JSON Schema無效	始終包含`required`，即使為空（`[]`）

嚴格模式：強制精確的結構描述遵守

OpenAI的結構化輸出嚴格模式（工具定義上的"strict": true）保證模型的輸出JSON與聲明的結構描述完全匹配，消除整個參數建構錯誤類別。

並行和循序工具呼叫

何時使用並行工具呼叫

OpenAI的Responses API（2025年3月）將並行工具呼叫設為預設。在單個LLM輪次中，模型可以同時請求多個工具執行。對於獨立工具，並行調度將往返次數從N個循序輪次減少到一個並發批次。

範例：研究代理需要當前股價、最新新聞和公司的SEC文件。三者都是獨立的。循序：3個LLM輪次 x 10秒 = 30秒。並行：1個LLM輪次 + max（工具延遲）約10秒。

前提條件：工具必須真正獨立。如果工具B需要工具A的輸出作為參數，它們必須是循序的。

依賴操作的循序工具呼叫

工具鏈接 — 使用一個工具的輸出作為下一個工具的輸入 — 需要循序執行。模式：search_web(查詢) → fetch_page(搜尋結果中的URL) → extract_data(頁面內容) → summarize(提取的資料)。

有狀態資源的並發風險

對有狀態資源的並行工具呼叫需要排序保證。規則：當工具是唯讀的或寫入獨立資源時，並行調度是安全的。

工具輸出解析和錯誤恢復

工具呼叫會失敗。外部API返回503。資料庫查詢逾時。設計良好的工具使用實作可以在不需要人工介入的情況下處理可恢復錯誤的失敗。

驗證工具輸出

返回HTTP 200的工具與返回正確、有用結果的工具不同。在將輸出注入代理上下文之前，根據預期結構描述驗證輸出。

重試策略：何時以及如何重新呼叫

針對不同失敗模式的三種重試模式：

暫時性失敗重試（網路逾時、速率限制）：在短暫退避後用相同參數重新呼叫相同工具。
參數澄清重試：向LLM返回解釋為何參數被拒絕的結構化錯誤。
備援工具：如果工具A在N次重試後失敗，路由到具有等效功能的工具B。

向協調器報告工具失敗

不可恢復的錯誤必須向協調器報告。對於多代理管道，協調器需要結構化的失敗訊號。對於AI智能代理協調模式，這是升級路徑。

工具權限範圍和安全性

最小權限工具分配

每個代理應該只持有其特定任務所需的工具。成功提示注入的代理的爆炸半徑受其許可工具集的限制。OWASP LLM Top 10 v1.1（2025年）將提示注入（LLM01）列為LLM應用程式的最大風險。

執行前的輸入驗證

在兩個層面驗證工具呼叫參數：結構描述驗證和語義驗證。fetch_page工具應拒絕帶有file://或localhost URL的參數以防止SSRF。

有關工具層級攻擊向量的完整分類，請參閱AI智能代理安全威脅模型。

不可逆操作：人在迴路門控

具有不可逆副作用的工具呼叫 — 發送電子郵件、刪除記錄、轉帳、發布內容 — 在執行前需要明確的人工確認門或冪等性檢查。

OpenLegion的觀點：工具登錄表和ACL門

每個主要LLM提供商都有不同的工具呼叫API。正確的抽象：定義一次工具，讓框架在呼叫時將其轉換為正確的提供商約定。

OpenLegion的工具登錄表實作了這種抽象。定義一次search_web。網格根據設定的模型將定義轉換為OpenAI tools、Anthropic tools或Gemini functionDeclarations。ACL門不是可選的。每個工具呼叫 — 內建的、MCP的或自訂的 — 在執行前都要經過每代理權限矩陣。

維度	OpenLegion	LangChain / LangGraph	OpenAI Agents SDK	CrewAI	Anthropic直接
工具定義格式	單一結構描述，提供商轉換	需要特定於提供商的包裝器	僅OpenAI格式	CrewAI工具裝飾器	僅Anthropic tool_use格式
提供商抽象	是 — GPT-4o、Claude、Gemini統一	部分 — 透過LangChain整合	否 — 僅OpenAI模型	部分	否 — 僅Anthropic
ACL執行	每代理權限矩陣，結構性	未內建	未內建	未內建	未內建
並行工具呼叫	支援	支援（依賴提供商）	是 — Responses API預設值	支援	是 — Claude支援
內建工具	瀏覽器、檔案、HTTP、Shell、影像生成	透過LangChain社群工具	web_search、file_search、computer_use	未內建	未內建
MCP整合	原生 — 相同的ACL/預算管道	透過LangChain MCP介面卡	實驗性	非原生	非原生

有關MCP規範、伺服器架構和每伺服器權限要求，請參閱模型上下文協議指南。

內建工具 vs MCP工具 vs 自訂工具

內建執行期工具

內建工具由執行期預先強化：瀏覽器自動化、檔案操作、HTTP請求、Shell命令、影像生成。首先使用內建工具。

MCP工具伺服器

MCP工具由透過stdio或HTTP上的JSON-RPC公開工具的模型上下文協議伺服器提供。MCP工具需要明確的沙箱化和每伺服器權限範圍設定。

自訂工具登錄

自訂工具是您在代理工具登錄表中編寫和登錄的Python（或TypeScript）函式。提供完全的靈活性；取捨是您擁有驗證、錯誤處理、冪等性和安全控制。

常見問題

什麼是AI智能代理工具使用？

AI智能代理工具使用是大型語言模型請求執行外部函式的機制 — 網路搜尋、API呼叫、資料庫查詢、檔案操作 — 透過輸出執行期攔截、驗證並執行的結構化工具呼叫JSON。LLM從不直接執行任何操作；它只描述想要呼叫什麼以及使用什麼參數。

函式呼叫在AI智能代理中如何運作？

函式呼叫在請求-執行-返回迴圈中運作：代理接收任務和可用工具清單；LLM發出命名函式並提供參數的工具呼叫；執行期驗證這些參數，執行函式，並將結果作為工具結果注入上下文。

對AI智能代理來說什麼是好的工具結構描述？

好的工具結構描述使用動詞-名詞名稱（search_web、create_ticket），明確說明何時使用及每個參數含義的描述，盡可能使用列舉的強型別參數，以及列出必要參數的required陣列。tau-bench（2025年）顯示不正確的參數建構是最常見的失敗模式。

什麼是並行工具呼叫，何時應該使用？

並行工具呼叫讓代理在單個LLM輪次中請求多個工具執行，由執行期並發調度。當工具獨立時使用並行呼叫 — 它們的輸出不相互依賴，且不寫入共享有狀態資源。

如何防止AI智能代理中的工具呼叫迴圈？

工具呼叫迴圈發生在代理持續呼叫工具而不收斂到最終答案時。唯一可靠的預防措施是在基礎設施層面強制執行步驟預算：由協調器強制執行的每次代理執行的工具呼叫硬性最大值。

AI智能代理工具使用的安全風險是什麼？

主要風險是工具結果注入：當代理呼叫返回可重定向代理行為的攻擊者控制內容的工具時。OWASP LLM Top 10 v1.1（2025年）將提示注入列為LLM應用程式的首要風險。緩解措施包括輸出淨化、最小權限工具分配以及針對不可逆操作的人在迴路門控。

內建工具、MCP工具和自訂工具之間有什麼區別？

內建工具由代理執行期提供，已應用ACL執行。MCP工具由透過JSON-RPC公開外部功能的模型上下文協議伺服器提供；需要沙箱化和每伺服器權限範圍設定。自訂工具是您編寫和登錄的函式，提供完全的靈活性，但需要負責驗證和安全性。

不同的LLM提供商如何實作工具使用？

OpenAI透過tools參數、助手回應中的tool_calls、role: "tool"結果訊息實作工具使用。Anthropic使用帶有在下一個人類輪次中的tool_result區塊的tool_use內容區塊。Google Gemini使用帶有回應中的functionCall部分和後續輪次中的functionResponse部分的functionDeclarations。三種格式在語義上等價，但在語法上不同。

定義一次工具，在任何地方安全執行

tau-bench（2025年）將GPT-4o定位在工具使用任務的44% pass@1，將參數建構作為主要失敗類別。帶有動詞-名詞名稱、型別化列舉和參數範例的精確結構描述彌合了這一差距的大部分。

有關涵蓋步驟預算和迴圈預防的智能代理工作流程模式，以及衡量工具使用可靠性的AI智能代理評估基準，這些指南擴展了本頁涵蓋的基礎。

在OpenLegion上建構具有每代理ACL執行的工具使用智能代理 →