1. 先搞清楚“工具調(diào)用”到底在解決什么問題如果你正在接觸大模型應用開發(fā)尤其是想讓它幫你查天氣、訂機票、發(fā)郵件或者連接數(shù)據(jù)庫、調(diào)用外部API那你一定會遇到“工具調(diào)用”這個概念。很多人一上來就去看代碼結(jié)果被各種框架、協(xié)議和術語繞暈。其實工具調(diào)用要解決的核心問題就一個讓大模型從“聊天機器人”變成“能替你干活的智能助手”。一個只會聊天的模型你問它“北京明天天氣怎么樣”它能給你編一段像模像樣的回答但它沒法真的去查天氣預報網(wǎng)站。工具調(diào)用就是給模型裝上了“手”和“腳”讓它能根據(jù)你的指令去執(zhí)行一個具體的動作比如調(diào)用一個查詢天氣的API然后把真實的結(jié)果返回給你。在安全領域比如“AI紅隊”的視角下研究工具調(diào)用有雙重意義。對開發(fā)者而言是讓應用更強大對安全研究者而言則是要審視當模型獲得了執(zhí)行外部動作的能力它會帶來哪些新的風險模型會不會被誘導去調(diào)用一個危險的命令它如何判斷一個工具調(diào)用請求是否安全這就是“大模型安全”在工具調(diào)用層面需要關注的核心。所以這篇文章不會只講怎么調(diào)用我會結(jié)合一線開發(fā)和安全評估的經(jīng)驗帶你走通從理解、配置、開發(fā)到安全考量的完整路徑。你會發(fā)現(xiàn)很多調(diào)用失敗的問題根源不在于代碼而在于對流程和權(quán)限的理解。2. 理解工具調(diào)用的標準流程從用戶指令到動作執(zhí)行別被那些復雜的架構(gòu)圖嚇到。一個完整的工具調(diào)用流程可以拆解成下面幾個環(huán)環(huán)相扣的步驟。理解這個流程是解決一切問題的起點。2.1 第一步定義工具你有什么“手”和“腳”首先你得告訴模型它現(xiàn)在有哪些工具可以用。每個工具都需要被清晰地定義。通常一個工具定義包括工具名稱一個唯一的標識符比如get_weather。工具描述用自然語言告訴模型這個工具是干什么的。例如“根據(jù)城市名稱查詢該城市的實時天氣情況?！?這個描述至關重要模型主要靠它來決定是否以及何時調(diào)用這個工具。參數(shù)列表調(diào)用這個工具需要提供哪些信息。比如city_name城市名并且要定義它的類型字符串以及是否必需。這通常以一個“工具列表”的形式在對話開始時或系統(tǒng)提示詞中提供給模型。在OpenAI的API中這就是tools參數(shù)在開源框架里也可能是類似的配置。2.2 第二步模型決策與生成調(diào)用請求模型說“我要動手了”用戶發(fā)出指令比如“幫我看看上海和北京的天氣對比”。理解與規(guī)劃模型結(jié)合你的指令和可用的工具列表進行思考。它會判斷“用戶需要兩個城市的天氣信息我手頭有get_weather工具這個工具一次只能查一個城市所以我需要調(diào)用它兩次?！鄙山Y(jié)構(gòu)化請求模型不會直接去調(diào)用API而是會生成一個標準的、結(jié)構(gòu)化的“工具調(diào)用請求”。這個請求會明確指出來“我要調(diào)用get_weather工具參數(shù)是city_name: “上?！??！?在API響應中這體現(xiàn)為tool_calls字段。關鍵點在這一步模型只是“表達意圖”它生成的是一個待執(zhí)行的調(diào)用指令而不是執(zhí)行結(jié)果。這個指令會返回給你的應用程序。2.3 第三步應用端執(zhí)行工具你的代碼真正干活你的應用程序后端服務收到了模型返回的tool_calls?，F(xiàn)在輪到你寫的代碼上場了解析請求你的代碼需要解析這個結(jié)構(gòu)化請求提取出工具名get_weather和參數(shù){“city_name”: “上海”}。安全與權(quán)限校驗重要在執(zhí)行前必須進行校驗。這個工具允許調(diào)用嗎參數(shù)是否合法比如城市名是否在服務范圍內(nèi)這一步是安全的關鍵防線絕不能省略。執(zhí)行調(diào)用根據(jù)工具名找到對應的函數(shù)或服務傳入?yún)?shù)真正去執(zhí)行。比如調(diào)用一個內(nèi)部函數(shù)或者向一個真實的天氣API發(fā)送HTTP請求。獲取結(jié)果等待執(zhí)行完成拿到返回結(jié)果。比如{“city”: “上?！? “temperature”: “22°C”, “condition”: “晴”}。2.4 第四步將結(jié)果反饋給模型告訴模型“事情辦完了”工具執(zhí)行完后你會得到一個結(jié)果。但這個結(jié)果需要再次交給模型來處理。格式化結(jié)果將工具執(zhí)行的結(jié)果可能是JSON、文本等整理好。提交給模型在后續(xù)的API請求中將上一次模型的tool_calls和對應的tool_outputs工具輸出一起發(fā)送回去。這相當于告訴模型“你上次讓我調(diào)用的工具我已經(jīng)執(zhí)行了結(jié)果是這個?！蹦Ｐ驼吓c回復模型接收到工具執(zhí)行的真實結(jié)果后會結(jié)合最初的用戶問題和這個結(jié)果生成最終面向用戶的自然語言回答。例如“上海目前天氣晴朗氣溫22攝氏度北京則是多云氣溫18攝氏度。兩地溫差4度。”這個“用戶提問 - 模型建議調(diào)用 - 應用執(zhí)行 - 結(jié)果返回 - 模型總結(jié)”的循環(huán)是工具調(diào)用的核心交互模式。很多開發(fā)者在第二步和第三步之間脫節(jié)或者在第四步忘記把結(jié)果傳回導致對話卡住。3. 動手實現(xiàn)一個簡單的天氣查詢工具調(diào)用我們用一個最經(jīng)典的例子——天氣查詢來把上面的流程跑通。這里我會以 OpenAI API 的格式為例因為它的定義最通用理解了它再看其他框架如 LangChain、Dify就會輕松很多。3.1 環(huán)境與依賴準備首先你需要一個能訪問大模型API的環(huán)境。這里假設你使用 OpenAI 的模型如 gpt-3.5-turbo 或 gpt-4。安裝必要的庫主要是 OpenAI 的官方 Python 包。pip install openai準備API密鑰從 OpenAI 平臺獲取你的OPENAI_API_KEY并設置為環(huán)境變量或在代碼中配置。模擬工具函數(shù)由于我們不可能真的去接一個天氣API我們先在本地寫一個模擬函數(shù)。在生產(chǎn)中這個函數(shù)會被替換為真正的外部服務調(diào)用。3.2 定義工具與模擬執(zhí)行函數(shù)我們先在代碼里定義工具列表和對應的執(zhí)行函數(shù)。import json from openai import OpenAI # 初始化客戶端請?zhí)鎿Q為你的API密鑰 client OpenAI(api_key“你的API密鑰”) # 1. 定義工具列表 tools [ { “type”: “function”, “function”: { “name”: “get_current_weather”, “description”: “獲取指定城市的當前天氣”, “parameters”: { “type”: “object”, “properties”: { “l(fā)ocation”: { “type”: “string”, “description”: “城市名稱例如北京上?！? }, “unit”: {“type”: “string”, “enum”: [“celsius”, “fahrenheit”], “default”: “celsius”}, }, “required”: [“l(fā)ocation”], }, }, } ] # 2. 模擬工具執(zhí)行函數(shù) def execute_tool(tool_name, arguments): “”“模擬執(zhí)行工具實際項目中這里會調(diào)用真實API或服務。”“” if tool_name “get_current_weather”: location arguments.get(“l(fā)ocation”) unit arguments.get(“unit”, “celsius”) # 模擬返回結(jié)果 return json.dumps({“l(fā)ocation”: location, “temperature”: “22”, “unit”: unit, “forecast”: [“sunny”]}) else: return json.dumps({“error”: f“Unknown tool: {tool_name}”})3.3 實現(xiàn)主對話循環(huán)接下來是實現(xiàn)核心的循環(huán)邏輯發(fā)送消息、檢查工具調(diào)用、執(zhí)行工具、返回結(jié)果。def run_conversation(user_query): “”“運行一個支持工具調(diào)用的對話。”“” messages [{“role”: “user”, “content”: user_query}] # 第一輪發(fā)送用戶查詢并告知模型可用的工具 response client.chat.completions.create( model“gpt-3.5-turbo”, # 或 “gpt-4” messagesmessages, toolstools, tool_choice“auto”, # 讓模型自行決定是否調(diào)用工具 ) response_message response.choices[0].message messages.append(response_message) # 將模型的回復添加到消息歷史 # 檢查模型是否想要調(diào)用工具 tool_calls response_message.tool_calls if tool_calls: print(f“模型請求調(diào)用工具: {tool_calls}”) # 遍歷所有工具調(diào)用請求模型可能一次請求調(diào)用多個工具 for tool_call in tool_calls: tool_name tool_call.function.name tool_args json.loads(tool_call.function.arguments) # 3. 應用端執(zhí)行工具 tool_result execute_tool(tool_name, tool_args) print(f“執(zhí)行工具 {tool_name} 結(jié)果: {tool_result}”) # 4. 將工具執(zhí)行結(jié)果作為新消息追加回對話歷史 messages.append({ “role”: “tool”, “tool_call_id”: tool_call.id, # 必須對應之前的調(diào)用ID “content”: tool_result, }) # 將工具結(jié)果反饋給模型讓它生成最終回答 second_response client.chat.completions.create( model“gpt-3.5-turbo”, messagesmessages, ) final_message second_response.choices[0].message messages.append(final_message) return final_message.content else: # 模型沒有調(diào)用工具直接返回回答 return response_message.content # 測試一下 if __name__ “__main__”: user_input “北京今天的天氣怎么樣” answer run_conversation(user_input) print(“最終回答:”, answer)運行這段代碼你會看到類似以下的輸出模型請求調(diào)用工具: [ChatCompletionMessageToolCall(id‘call_abc123’, functionFunction(arguments‘{“l(fā)ocation”: “北京”, “unit”: “celsius”}’, name‘get_current_weather’), type‘function’)] 執(zhí)行工具 get_current_weather 結(jié)果: {“l(fā)ocation”: “北京”, “temperature”: “22”, “unit”: “celsius”, “forecast”: [“sunny”]} 最終回答: 北京今天天氣晴朗氣溫大約22攝氏度。這個簡單的例子清晰地展示了整個流程。關鍵點在于tool_calls是模型的想法execute_tool是你的代碼在行動而把結(jié)果以role: “tool”的消息傳回去是讓模型完成思考閉環(huán)的必要步驟。4. 從Demo到生產(chǎn)必須考慮的工程與安全問題能跑通一個Demo只是開始。當你打算把工具調(diào)用用到實際項目中時下面這些工程化和安全層面的問題會一個接一個跳出來。4.1 工具定義的質(zhì)量決定模型調(diào)用的準確性工具的描述 (description) 和參數(shù)定義 (parameters) 不是隨便寫寫的注釋它們是模型決策的“說明書”。描述要清晰具體“獲取天氣”就不如“根據(jù)城市名稱查詢該城市的實時溫度、天氣狀況和濕度”來得好。模糊的描述會導致模型誤調(diào)用或不敢調(diào)用。參數(shù)要約束明確使用enum枚舉有效值用default設置合理默認值。如果參數(shù)是“日期”就應定義好格式如“YYYY-MM-DD”避免模型自由發(fā)揮導致你的后端解析失敗。工具數(shù)量不宜過多一次性給模型幾百個工具定義會嚴重影響其判斷速度和準確性。應該根據(jù)對話上下文動態(tài)管理工具列表。4.2 執(zhí)行環(huán)節(jié)的安全校驗是生命線在execute_tool函數(shù)里直接執(zhí)行代碼是極其危險的。你必須建立一個安全層。輸入驗證對模型傳來的參數(shù)進行嚴格檢查。比如location參數(shù)是否只允許中英文城市名是否要防止SQL注入或命令注入如果參數(shù)會用于拼接命令權(quán)限校驗這個用戶有權(quán)調(diào)用這個工具嗎這個工具在當前會話上下文中是否可用例如一個“發(fā)送郵件”的工具不應該被用來查詢天氣。沙箱與環(huán)境隔離對于執(zhí)行代碼、訪問文件系統(tǒng)或網(wǎng)絡這類高風險工具必須在沙箱環(huán)境中運行限制其資源CPU、內(nèi)存、網(wǎng)絡和權(quán)限。操作確認與審批對于關鍵操作如刪除數(shù)據(jù)、支付可以設計“二次確認”流程即模型生成請求后由用戶確認后再執(zhí)行。4.3 錯誤處理與穩(wěn)定性保障工具調(diào)用引入了外部依賴失敗是常態(tài)。網(wǎng)絡超時與重試調(diào)用外部API可能超時。你的代碼需要設置合理的超時時間并設計重試邏輯如最多3次且有退避策略。工具執(zhí)行失敗如果工具執(zhí)行出錯返回錯誤碼或異常你應該將清晰的錯誤信息而非堆棧跟蹤作為tool_output返回給模型。模型有時能根據(jù)錯誤信息調(diào)整策略或向用戶解釋。上下文管理復雜的多輪對話中工具調(diào)用可能有多個。你需要妥善管理tool_call_id和消息順序確保每個工具結(jié)果都能準確對應到最初的調(diào)用請求上。4.4 從安全視角審視工具調(diào)用AI紅隊的關注點作為安全研究者或AI紅隊成員看待工具調(diào)用時視角會完全不同。我們的目標是發(fā)現(xiàn)和利用其中的脆弱性。提示詞注入與越獄能否通過精心構(gòu)造的用戶輸入誘導模型繞過你設定的工具調(diào)用規(guī)則去調(diào)用一個未被允許的、甚至危險的工具例如誘導模型將“刪除所有文件”這個指令解釋為符合“文件管理工具”的描述而發(fā)起調(diào)用。這就是為什么工具描述和參數(shù)校驗如此重要。工具濫用即使調(diào)用的是合法工具參數(shù)是否可能被濫用例如一個“搜索網(wǎng)頁”的工具是否可能被用來反復搜索大量內(nèi)容造成DoS攻擊或者搜索敏感內(nèi)容信息泄露工具執(zhí)行的結(jié)果如數(shù)據(jù)庫查詢結(jié)果、API響應在返回給模型并最終呈現(xiàn)給用戶時是否可能包含未經(jīng)過濾的敏感信息如錯誤信息中的系統(tǒng)路徑、SQL語句供應鏈攻擊如果工具本身依賴第三方庫或服務這些依賴是否存在漏洞攻擊者能否通過污染這些依賴來間接控制工具的行為評估一個基于工具調(diào)用的AI應用是否安全不能只看它功能是否實現(xiàn)必須系統(tǒng)性地審視工具定義是否精確、參數(shù)校驗是否嚴格、執(zhí)行環(huán)境是否隔離、錯誤信息是否無害、整個調(diào)用鏈路是否存在邏輯缺陷可被利用。5. 主流框架與開源模型中的工具調(diào)用實踐了解了底層原理和安全考量后我們再看看在具體的框架和開源模型中如何實踐。5.1 使用 LangChain 實現(xiàn)工具調(diào)用LangChain 通過Tool類和bind_tools方法將工具調(diào)用流程高度抽象化簡化了開發(fā)。from langchain_openai import ChatOpenAI from langchain.agents import AgentExecutor, create_tool_calling_agent from langchain.tools import Tool from langchain_core.prompts import ChatPromptTemplate # 1. 定義工具函數(shù) def get_weather(location: str) - str: “”“模擬獲取天氣?！薄啊?return f“{location}的天氣是晴朗22度?！?# 2. 包裝成 LangChain Tool 對象 tools [ Tool( name“WeatherTool”, funcget_weather, description“根據(jù)城市名查詢天氣輸入是一個字符串格式的城市名?！?) ] # 3. 創(chuàng)建提示詞模板 prompt ChatPromptTemplate.from_messages([ (“system”, “你是一個有用的助手可以調(diào)用工具來回答問題?！?, (“placeholder”, “{chat_history}”), (“human”, “{input}”), (“placeholder”, “{agent_scratchpad}”), ]) # 4. 初始化模型并綁定工具 llm ChatOpenAI(model“gpt-3.5-turbo”) llm_with_tools llm.bind_tools(tools) # 5. 創(chuàng)建Agent并執(zhí)行 agent create_tool_calling_agent(llm_with_tools, tools, prompt) agent_executor AgentExecutor(agentagent, toolstools, verboseTrue) result agent_executor.invoke({“input”: “北京天氣如何”}) print(result[“output”])LangChain 幫你自動處理了消息歷史、工具調(diào)用解析和結(jié)果回傳的循環(huán)你只需要關注工具函數(shù)本身和提示詞。verboseTrue可以讓你看到詳細的決策過程對調(diào)試非常有幫助。5.2 在 Ollama 本地模型中使用工具調(diào)用對于部署在本地的開源模型如通過 Ollama 運行的 Llama 3、Qwen 等工具調(diào)用支持取決于模型本身的能力和 Ollama 的版本。目前許多較新的開源模型也開始支持類似 OpenAI 的 function calling 格式。確認模型支持首先你需要一個明確支持工具調(diào)用的模型版本。例如llama3.1:8b的某些版本或qwen2.5:7b。使用兼容的APIOllama 提供了與 OpenAI API 兼容的端點。你可以將上面 OpenAI 的示例代碼中的base_url指向你的 Ollama 服務地址。from openai import OpenAI client OpenAI( base_url“http://localhost:11434/v1”, # Ollama 的兼容API地址 api_key“ollama”, # 可任意填寫非空即可 ) # 后續(xù)代碼與使用OpenAI API完全相同 model_name “l(fā)lama3.1:8b” # 替換為你本地運行的模型名注意性能與準確性同等參數(shù)規(guī)模下開源模型的工具調(diào)用準確性和穩(wěn)定性可能不如頂級商用模型。需要進行更多的測試和提示詞優(yōu)化。5.3 工具調(diào)用與 RAG、Agent、Workflow 的關系在搜索熱詞中?？吹絉AG、Agent、工具調(diào)用、記憶、Workflow被并列提及。它們的關系是這樣的工具調(diào)用是Agent的核心能力之一。一個智能體Agent之所以能“自主”完成任務正是因為它可以規(guī)劃并調(diào)用一系列工具。RAG為模型提供了從外部知識庫獲取信息的能力。你可以把 RAG 的“檢索-生成”過程本身也看作一個特殊的“工具”。Agent 可以調(diào)用 RAG 工具來獲取它不知道的知識再基于此進行決策或調(diào)用其他工具。記憶讓 Agent 或?qū)υ捪到y(tǒng)能夠記住之前的交互歷史包括工具調(diào)用的結(jié)果從而進行更連貫的多輪任務。Workflow則是將多個工具調(diào)用、條件判斷、RAG 檢索等步驟編排成一個自動化業(yè)務流程。例如一個客服工單處理 Workflow 可能包含調(diào)用 RAG 查詢知識庫 - 調(diào)用工具分類問題 - 調(diào)用工具生成回復草稿 - 調(diào)用工具發(fā)送給人工審核。工具調(diào)用是構(gòu)建復雜 AI 應用的基石它使得模型能夠突破其靜態(tài)知識的限制與動態(tài)世界進行交互。6. 常見問題排查與調(diào)試指南當你開發(fā)的工具調(diào)用功能不工作時可以按照以下順序進行排查能解決90%的問題。6.1 模型根本不調(diào)用工具檢查工具描述描述是否足夠清晰是否與用戶問題高度相關嘗試用更詳細、更貼近用戶場景的語言重寫description。檢查模型能力你用的模型版本是否支持工具調(diào)用gpt-3.5-turbo和gpt-4都支持。對于開源模型務必查閱其文檔。檢查tool_choice參數(shù)如果你明確希望模型調(diào)用某個工具可以設置tool_choice{“type”: “function”, “function”: {“name”: “xxx”}}來強制調(diào)用。設為“auto”是讓模型自己決定。簡化問題先用一個極其簡單、明確的用戶指令如“用get_weather工具查一下北京天氣”測試排除指令歧義的影響。6.2 模型調(diào)用了工具但參數(shù)不對檢查參數(shù)定義parameters中的properties定義是否清晰type、description是否準確使用enum可以極大減少模型“瞎猜”的情況。提供示例在系統(tǒng)提示詞或工具描述中可以加入一兩個調(diào)用示例指導模型如何生成參數(shù)。查看原始響應打印出模型返回的response_message.tool_calls[0].function.arguments看看它到底生成了什么。很多時候是 JSON 格式錯誤或多了些奇怪字符。6.3 工具執(zhí)行失敗或結(jié)果模型無法理解執(zhí)行端日志在execute_tool函數(shù)內(nèi)部加入詳細日志打印輸入?yún)?shù)和最終返回結(jié)果確認你的代碼邏輯正確。結(jié)果格式化確保返回給模型的結(jié)果是字符串格式。如果是復雜對象先json.dumps()。模型需要能“讀懂”這個結(jié)果。錯誤信息反饋如果工具執(zhí)行出錯返回一個對模型友好的錯誤信息如{“error”: “City not found”}而不是 Python 的異常堆棧。模型有時能根據(jù)錯誤信息調(diào)整后續(xù)行為。6.4 多輪對話中工具調(diào)用混亂維護完整的消息歷史確保每一次請求都包含了之前所有的user、assistant和tool消息。丟失歷史會導致模型失憶。正確關聯(lián)tool_call_id在返回工具結(jié)果時tool_call_id必須與請求中的id嚴格對應。這是模型區(qū)分不同調(diào)用的關鍵。管理上下文長度過長的對話歷史會消耗大量 Token可能導致模型性能下降或遺忘早期工具調(diào)用。需要設計合理的上下文窗口管理策略例如只保留最近N輪對話或總結(jié)歷史。工具調(diào)用是把大模型從“智庫”變成“執(zhí)行者”的關鍵一步。它的實現(xiàn)不難難在把它做得可靠、安全、易維護。我的建議是先從單個工具、簡單場景跑通整個流程深刻理解每一步的數(shù)據(jù)流轉(zhuǎn)。然后再逐步加入權(quán)限校驗、錯誤處理、復雜工具鏈。最后一定要從攻擊者的角度思考你的設計看看哪些環(huán)節(jié)可能被繞過或濫用。這才是真正負責任的大模型應用開發(fā)。