議本質(zhì)到手寫(xiě)實(shí)現(xiàn)大模型工具調(diào)用)
1. 從“笨辦法”開(kāi)始為什么Function Calling不是你想的那樣如果你最近在折騰大模型應(yīng)用尤其是想搞點(diǎn)能聯(lián)網(wǎng)、能查天氣、能操作數(shù)據(jù)庫(kù)的“智能體”那你大概率被“Function Calling”這個(gè)詞刷屏了。各種教程、框架文檔里都在提它好像不會(huì)這個(gè)你的AI應(yīng)用就缺了靈魂。但說(shuō)實(shí)話(huà)我第一次看到這個(gè)詞的時(shí)候腦子里也是一團(tuán)漿糊。它聽(tīng)起來(lái)像是一個(gè)具體的函數(shù)調(diào)用動(dòng)作又像是一種協(xié)議還像是一種開(kāi)發(fā)模式。網(wǎng)上的文章要么講得太玄乎要么直接甩給你OpenAI API的JSON格式定義看完之后的感覺(jué)是懂了但又沒(méi)完全懂。今天我們不搞那些云里霧里的概念堆砌就從最“笨”的辦法開(kāi)始親手寫(xiě)一遍。我的核心觀點(diǎn)是Function Calling本質(zhì)上是一種“約定”是大模型LLM和我們寫(xiě)的程序你的代碼之間的一種“對(duì)話(huà)協(xié)議”。它的目的極其單純讓大模型這個(gè)“黑盒子”能明確地告訴我們——“嘿人類(lèi)我現(xiàn)在需要你幫我執(zhí)行某個(gè)具體操作這是操作的名字和參數(shù)你準(zhǔn)備好就告訴我結(jié)果?！焙芏嗳苏`以為Function Calling是大模型“主動(dòng)”調(diào)用了我們的代碼這是一種錯(cuò)覺(jué)。大模型本身只是一段概率預(yù)測(cè)程序它沒(méi)有手不會(huì)執(zhí)行curl命令也不會(huì)寫(xiě)數(shù)據(jù)庫(kù)。它唯一能做的就是根據(jù)我們的“約定”在對(duì)話(huà)的某個(gè)時(shí)刻輸出一段符合特定格式的文本。而我們作為程序的真正控制者需要去“監(jiān)聽(tīng)”這段文本解析它然后才去真正地執(zhí)行函數(shù)最后把執(zhí)行結(jié)果再“喂”回給大模型讓它繼續(xù)思考。所以這個(gè)“笨辦法”就是我們先忘掉LangChain、Dify、各種Agent框架。我們就用最原始的HTTP請(qǐng)求和字符串處理來(lái)模擬一遍這個(gè)“約定”是如何從無(wú)到有建立起來(lái)的。當(dāng)你親手用幾十行代碼把這個(gè)流程跑通你就會(huì)發(fā)現(xiàn)那些高級(jí)框架只不過(guò)是把這個(gè)流程包裝得更優(yōu)雅、更自動(dòng)化而已其核心骨架我們今天就能把它搭出來(lái)。2. 拆解核心一次完整的Function Calling對(duì)話(huà)回合要理解Function Calling我們必須把它放到一次完整的“人-模型-工具”交互回合中去看。這個(gè)回合通常包含四個(gè)清晰的步驟我把它畫(huà)成了一個(gè)簡(jiǎn)單的循環(huán)用戶(hù)提問(wèn) - 模型思考并請(qǐng)求工具 - 程序執(zhí)行工具 - 模型整合結(jié)果并回復(fù)讓我們用一個(gè)最經(jīng)典的例子貫穿始終用戶(hù)問(wèn)“北京今天天氣怎么樣”2.1 第一步我們?nèi)绾巍案嬖V”模型有哪些工具可用大模型不是全知全能的它不知道你的程序里有個(gè)叫g(shù)et_weather的函數(shù)。所以對(duì)話(huà)開(kāi)始前我們必須先“注冊(cè)”工具。在Function Calling的約定里這通常是通過(guò)在發(fā)送給模型的系統(tǒng)提示System Prompt或用戶(hù)消息中附帶一個(gè)“工具列表”來(lái)實(shí)現(xiàn)的。這個(gè)列表不是一個(gè)簡(jiǎn)單的函數(shù)名數(shù)組而是一個(gè)結(jié)構(gòu)化的描述。我們來(lái)看一個(gè)最“笨”的表示方法假設(shè)我們用純文本約定你可以使用的工具 1. 函數(shù)名get_weather - 描述查詢(xún)指定城市的天氣情況。 - 參數(shù)city字符串必需表示城市名稱(chēng)例如“北京”。在實(shí)際的OpenAI API中這個(gè)列表會(huì)被格式化成更機(jī)器可讀的JSON Schema。但本質(zhì)沒(méi)變我們是在用自然語(yǔ)言或結(jié)構(gòu)化數(shù)據(jù)向模型描述一個(gè)“能力”的接口規(guī)范。這就像你給一個(gè)新同事一份操作手冊(cè)告訴他“如果你需要查天氣就告訴我你要調(diào)用‘get_weather’手冊(cè)并且把城市名告訴我?！?.2 第二步模型如何“請(qǐng)求”調(diào)用工具模型收到了用戶(hù)的問(wèn)題“北京今天天氣怎么樣”以及我們提供的工具列表。它開(kāi)始“思考”即進(jìn)行概率計(jì)算。根據(jù)訓(xùn)練數(shù)據(jù)中對(duì)“天氣”和“北京”的關(guān)聯(lián)它很可能判斷出需要調(diào)用get_weather這個(gè)工具。關(guān)鍵來(lái)了模型不會(huì)直接說(shuō)“幫我執(zhí)行g(shù)et_weather(‘北京’)”。在Function Calling的約定下它會(huì)輸出一段嚴(yán)格符合我們約定格式的文本。如果我們約定用JSON它可能會(huì)在回復(fù)中生成一個(gè)特殊的結(jié)構(gòu)塊{ “function_call”: { “name”: “get_weather”, “arguments”: “{ \”city\”: \”北京\” }” } }請(qǐng)注意這里的arguments是一個(gè)字符串里面包裹著一個(gè)JSON對(duì)象。為什么是字符串因?yàn)閷?duì)于模型來(lái)說(shuō)它的一切輸出都是文本流。它只是在按照我們描述的格式生成一段看起來(lái)像JSON的文本。它并不“理解”JSON也不“執(zhí)行”JSON解析。這個(gè)步驟模型僅僅是在說(shuō)“根據(jù)我們的約定我現(xiàn)在需要get_weather功能相關(guān)參數(shù)是city北京我把這個(gè)請(qǐng)求按格式寫(xiě)好了請(qǐng)你指我們的程序來(lái)處理?！弊⒁膺@是最容易產(chǎn)生誤解的地方。模型輸出的{“city”: “北京”}只是一個(gè)文本片段不是可操作的字典。我們的程序必須主動(dòng)去解析這段文本將其轉(zhuǎn)化為真正的數(shù)據(jù)結(jié)構(gòu)。2.3 第三步我們的程序如何“執(zhí)行”并返回結(jié)果我們的程序一直在監(jiān)聽(tīng)模型的回復(fù)。當(dāng)檢測(cè)到回復(fù)中包含”function_call”這個(gè)關(guān)鍵字段時(shí)就知道模型在請(qǐng)求調(diào)用函數(shù)了。這時(shí)我們的程序需要解析從arguments字符串中提取出city的值“北京”。分派根據(jù)name字段的值“get_weather”在我們的代碼中找到對(duì)應(yīng)的真實(shí)函數(shù)。執(zhí)行調(diào)用真實(shí)的get_weather(“北京”)函數(shù)。這個(gè)函數(shù)內(nèi)部可能去調(diào)用一個(gè)天氣API比如心知天氣、和風(fēng)天氣等獲取到真實(shí)的天氣數(shù)據(jù)例如{“temperature”: “22°C”, “condition”: “晴”, “humidity”: “40%”}。格式化將執(zhí)行結(jié)果再次按照約定格式準(zhǔn)備好以便發(fā)回給模型。通常這個(gè)結(jié)果也需要被包裝一下。2.4 第四步模型如何“消化”結(jié)果并給出最終回復(fù)我們將上一步得到的天氣結(jié)果連同最初的對(duì)話(huà)歷史再次發(fā)送給模型。這次發(fā)送的消息很關(guān)鍵通常包含一個(gè)“角色”為”function”的消息內(nèi)容就是我們的執(zhí)行結(jié)果。例如角色: function 名稱(chēng): get_weather 內(nèi)容: {“temperature”: “22°C”, “condition”: “晴”, “humidity”: “40%”}模型看到這條消息后就明白了“哦我之前請(qǐng)求的get_weather工具已經(jīng)執(zhí)行完畢結(jié)果是北京晴22度?！?于是它就能基于這個(gè)真實(shí)、具體的數(shù)據(jù)生成面向用戶(hù)的、自然流暢的最終回復(fù)“北京今天天氣晴朗氣溫22攝氏度濕度40%是個(gè)好天氣?！敝链艘粋€(gè)完整的Function Calling回合結(jié)束。你會(huì)發(fā)現(xiàn)模型始終在它的文本世界里工作而“調(diào)用函數(shù)”這個(gè)物理世界的動(dòng)作是由我們的程序根據(jù)約定“代理”執(zhí)行的。這就是為什么它更準(zhǔn)確的叫法應(yīng)該是“工具調(diào)用”或“函數(shù)調(diào)用請(qǐng)求”。3. 拋開(kāi)框架手寫(xiě)一個(gè)極簡(jiǎn)Function Calling流程現(xiàn)在我們不用任何AI框架只用Python標(biāo)準(zhǔn)庫(kù)和requests庫(kù)來(lái)模擬這個(gè)流程。我們會(huì)創(chuàng)建一個(gè)“虛擬大模型”——一個(gè)簡(jiǎn)單的判斷邏輯來(lái)模擬LLM的決策過(guò)程。3.1 第一步定義工具與虛擬模型首先我們定義真實(shí)的工具函數(shù)和工具描述# 真實(shí)的工具函數(shù) def get_weather(city: str) - str: 模擬查詢(xún)天氣的API調(diào)用 # 這里應(yīng)該是真實(shí)的HTTP請(qǐng)求我們模擬數(shù)據(jù) weather_data { “北京”: “晴朗25°C”, “上?！? “多云28°C”, “深圳”: “陣雨30°C” } return weather_data.get(city, “未找到該城市天氣信息”) # 工具描述我們的“約定” tools_description “”” 你可以使用的工具 - get_weather(city): 查詢(xún)城市天氣。參數(shù)city是字符串如‘北京’。 “”” # 一個(gè)極其簡(jiǎn)陋的“虛擬大模型” def virtual_llm(user_query: str, tools_desc: str) - str: 模擬LLM根據(jù)用戶(hù)輸入和工具描述決定是否調(diào)用工具。 # 簡(jiǎn)單的關(guān)鍵詞匹配來(lái)模擬LLM的“思考” if “天氣” in user_query: # 模擬提取城市實(shí)際LLM會(huì)用更復(fù)雜的方式 city “北京” if “北京” in user_query else “上?！?# 簡(jiǎn)單演示 # 按照我們約定的格式返回工具調(diào)用請(qǐng)求 return f”FUNCTION_CALL: get_weather ARGS: {city}” else: return f”ANSWER: 我不知道如何回答這個(gè)問(wèn)題?！边@個(gè)virtual_llm函數(shù)模擬了核心環(huán)節(jié)它看到了“天氣”關(guān)鍵詞結(jié)合工具描述決定調(diào)用get_weather并以我們自定義的簡(jiǎn)單格式FUNCTION_CALL: func_name ARGS: arg輸出了請(qǐng)求。3.2 第二步構(gòu)建主控循環(huán)接下來(lái)我們編寫(xiě)主程序它負(fù)責(zé)協(xié)調(diào)整個(gè)對(duì)話(huà)流程def main(): print(“系統(tǒng)啟動(dòng)工具已就緒...”) print(f“工具列表\n{tools_description}\n”) # 模擬用戶(hù)輸入 user_query “北京今天天氣怎么樣” print(f“用戶(hù): {user_query}”) # 第一步將用戶(hù)問(wèn)題和工具描述一起交給“模型” llm_response virtual_llm(user_query, tools_description) print(f“虛擬模型回復(fù): {llm_response}”) # 第二步解析模型回復(fù)檢查是否是工具調(diào)用請(qǐng)求 if llm_response.startswith(“FUNCTION_CALL:”): # 解析出函數(shù)名和參數(shù) _, func_info llm_response.split(“FUNCTION_CALL: “) func_name, args_str func_info.split(“ ARGS: “) func_name func_name.strip() args_value args_str.strip() print(f“\n檢測(cè)到工具調(diào)用請(qǐng)求”) print(f“- 函數(shù)名: {func_name}”) print(f“- 參數(shù): {args_value}”) # 第三步根據(jù)函數(shù)名映射并執(zhí)行真實(shí)的函數(shù) if func_name “get_weather”: # 執(zhí)行真正的函數(shù) result get_weather(args_value) print(f“- 執(zhí)行結(jié)果: {result}”) # 第四步將結(jié)果格式化成“函數(shù)響應(yīng)”的格式準(zhǔn)備反饋給模型 func_response f”FUNCTION_RESULT: {result}” print(f“\n將結(jié)果反饋給模型: {func_response}”) # 這里本應(yīng)再次調(diào)用virtual_llm傳入原始問(wèn)題和函數(shù)結(jié)果讓模型生成最終回答。 # 為了簡(jiǎn)化我們直接模擬最終回復(fù)。 final_answer f”根據(jù)查詢(xún)結(jié)果{args_value}的天氣是{result}?！?print(f“\n模型最終回復(fù)用戶(hù): {final_answer}”) else: print(f“錯(cuò)誤未知的函數(shù) {func_name}”) else: # 如果不是工具調(diào)用直接輸出模型回復(fù) print(f“模型直接回復(fù): {llm_response.replace(‘ANSWER: ‘, ”)}”) if __name__ “__main__”: main()運(yùn)行這段代碼你會(huì)看到如下輸出系統(tǒng)啟動(dòng)工具已就緒... 工具列表 你可以使用的工具 - get_weather(city): 查詢(xún)城市天氣。參數(shù)city是字符串如‘北京’。 用戶(hù): 北京今天天氣怎么樣 虛擬模型回復(fù): FUNCTION_CALL: get_weather ARGS: 北京 檢測(cè)到工具調(diào)用請(qǐng)求 - 函數(shù)名: get_weather - 參數(shù): 北京 - 執(zhí)行結(jié)果: 晴朗25°C 將結(jié)果反饋給模型: FUNCTION_RESULT: 晴朗25°C 模型最終回復(fù)用戶(hù): 根據(jù)查詢(xún)結(jié)果北京的天氣是晴朗25°C。3.3 第三步理解這個(gè)“笨辦法”的價(jià)值雖然這個(gè)例子簡(jiǎn)陋到可笑但它完整還原了Function Calling的核心骨架約定我們和“模型”約定了工具描述格式和調(diào)用請(qǐng)求格式FUNCTION_CALL:。請(qǐng)求“模型”按約定格式輸出請(qǐng)求文本。解析與執(zhí)行我們的主程序主動(dòng)解析這段文本并主動(dòng)調(diào)用對(duì)應(yīng)的真實(shí)函數(shù)?；卣{(diào)將執(zhí)行結(jié)果按約定格式返回完成閉環(huán)。OpenAI的Function Calling、Google的Tool Calling乃至所有AI Agent框架如LangChain的Tools、Dify的Workflow都是在將這個(gè)流程標(biāo)準(zhǔn)化、自動(dòng)化、魯棒化。它們定義了更嚴(yán)謹(jǐn)?shù)腏SON Schema來(lái)描述工具提供了自動(dòng)解析和分派調(diào)用的機(jī)制并管理復(fù)雜的多輪對(duì)話(huà)狀態(tài)。但萬(wàn)變不離其宗底層模式就是我們剛才手寫(xiě)的這個(gè)循環(huán)。4. 邁向?qū)崙?zhàn)對(duì)接真實(shí)大模型API理解了本質(zhì)我們?cè)賮?lái)看看如何與真實(shí)的OpenAI API協(xié)作。這里的關(guān)鍵是使用正確的消息格式。4.1 定義符合OpenAI格式的工具OpenAI要求工具定義是一個(gè)JSON Schema列表。我們升級(jí)之前的工具描述tools_for_openai [ { “type”: “function”, “function”: { “name”: “get_weather”, “description”: “Get the current weather in a given location”, “parameters”: { “type”: “object”, “properties”: { “l(fā)ocation”: { “type”: “string”, “description”: “The city and state, e.g. San Francisco, CA”, }, “unit”: {“type”: “string”, “enum”: [“celsius”, “fahrenheit”]}, }, “required”: [“l(fā)ocation”], }, }, } ]這個(gè)結(jié)構(gòu)比我們的純文本描述復(fù)雜得多但它提供了機(jī)器可讀的嚴(yán)格規(guī)范包括參數(shù)類(lèi)型、是否必需、枚舉值等這讓模型能更準(zhǔn)確地生成參數(shù)。4.2 發(fā)起包含工具定義的對(duì)話(huà)請(qǐng)求當(dāng)我們向ChatGPT API發(fā)送請(qǐng)求時(shí)需要將tools參數(shù)傳入import openai response openai.chat.completions.create( model“gpt-3.5-turbo”, messages[ {“role”: “user”, “content”: “What‘s the weather like in Boston?”} ], toolstools_for_openai, # 關(guān)鍵告訴模型可用的工具 tool_choice“auto”, # 讓模型自行決定是否調(diào)用工具 )4.3 解析模型的工具調(diào)用請(qǐng)求模型的回復(fù)response.choices[0].message會(huì)包含一個(gè)tool_calls字段如果它決定調(diào)用工具的話(huà)。我們需要檢查這個(gè)字段message response.choices[0].message if message.tool_calls: # 遍歷所有工具調(diào)用請(qǐng)求理論上一次可以請(qǐng)求多個(gè) for tool_call in message.tool_calls: func_name tool_call.function.name # 注意arguments 是字符串需要解析成字典 import json func_args json.loads(tool_call.function.arguments) location func_args.get(“l(fā)ocation”) print(f“模型請(qǐng)求調(diào)用函數(shù): {func_name}”) print(f“參數(shù): {func_args}”) # 接下來(lái)根據(jù)func_name執(zhí)行你的真實(shí)函數(shù)... # result get_weather(location)4.4 執(zhí)行函數(shù)并將結(jié)果返回給模型執(zhí)行完函數(shù)后我們必須將結(jié)果以特定的“function”角色消息追加到對(duì)話(huà)歷史中并再次請(qǐng)求模型# 假設(shè)我們已經(jīng)獲取了結(jié)果 weather_result {“temperature”: “22”, “unit”: “celsius”, “condition”: “sunny”} # 將函數(shù)執(zhí)行結(jié)果作為一條新消息 messages.append(message) # 先把模型的上一條消息包含tool_calls加入歷史 messages.append({ “role”: “tool”, “tool_call_id”: tool_call.id, # 必須對(duì)應(yīng)之前的調(diào)用ID “content”: json.dumps(weather_result), # 結(jié)果需要是JSON字符串 }) # 再次調(diào)用API讓模型基于結(jié)果生成最終回復(fù) second_response openai.chat.completions.create( model“gpt-3.5-turbo”, messagesmessages, ) final_answer second_response.choices[0].message.content print(f“最終回答: {final_answer}”) # 例如: “It‘s currently sunny and 22°C in Boston.”這個(gè)流程和我們手寫(xiě)的“笨辦法”邏輯完全一致只是消息格式和API調(diào)用被標(biāo)準(zhǔn)化了。框架的價(jià)值就在于幫你自動(dòng)化管理messages數(shù)組的拼接、tool_call_id的匹配、錯(cuò)誤處理等瑣碎細(xì)節(jié)。5. 深入原理大模型是如何“學(xué)會(huì)”調(diào)用函數(shù)的你可能會(huì)有疑問(wèn)大模型是怎么知道在什么時(shí)候、以什么格式來(lái)請(qǐng)求調(diào)用函數(shù)的它并沒(méi)有被“編程”啊。這背后的核心是指令微調(diào)。在模型訓(xùn)練的最后階段研究人員會(huì)使用大量精心構(gòu)造的“對(duì)話(huà)-工具調(diào)用”配對(duì)數(shù)據(jù)對(duì)模型進(jìn)行微調(diào)。這些數(shù)據(jù)的格式就像我們前面演示的完整回合用戶(hù): 北京天氣 助手: 思考我需要調(diào)用get_weather工具。調(diào)用{name: get_weather, arguments: {city: 北京}} 系統(tǒng)(模擬函數(shù)執(zhí)行): {temp: 22°C} 助手: 北京今天氣溫22攝氏度天氣晴朗。模型通過(guò)學(xué)習(xí)海量這樣的例子逐漸掌握了模式“當(dāng)用戶(hù)問(wèn)題涉及某個(gè)領(lǐng)域如天氣而我自身知識(shí)無(wú)法給出具體實(shí)時(shí)數(shù)據(jù)時(shí)我應(yīng)該輸出那個(gè)特定的JSON結(jié)構(gòu)來(lái)‘請(qǐng)求幫助’然后在收到一段結(jié)構(gòu)化的數(shù)據(jù)后再將其組織成自然語(yǔ)言回答?！彼訤unction Calling能力不是魔法而是通過(guò)數(shù)據(jù)訓(xùn)練出來(lái)的、一種對(duì)特定文本模式的條件反射。模型學(xué)到的是一種“溝通協(xié)議”而不是真正的代碼執(zhí)行能力。6. 避坑指南Function Calling實(shí)戰(zhàn)中的常見(jiàn)問(wèn)題在實(shí)際項(xiàng)目中集成Function Calling你會(huì)遇到一些教科書(shū)里不提的坑。這里分享幾個(gè)我踩過(guò)的雷。6.1 參數(shù)格式的“幻覺(jué)”與校驗(yàn)大模型在生成arguments的JSON字符串時(shí)有時(shí)會(huì)產(chǎn)生“幻覺(jué)”輸出格式錯(cuò)誤或參數(shù)值不合理。例如要求數(shù)字它給字符串要求枚舉值它給一個(gè)不在列表里的值。避坑策略永遠(yuǎn)不要信任模型輸出的參數(shù)。必須在你的代碼中進(jìn)行嚴(yán)格的二次校驗(yàn)。JSON解析容錯(cuò)用try-except包裹json.loads()準(zhǔn)備好處理格式錯(cuò)誤的JSON。參數(shù)類(lèi)型轉(zhuǎn)換與驗(yàn)證即使Schema里定義了type: “integer”模型也可能輸出”twenty two”。你需要做類(lèi)型轉(zhuǎn)換和有效性檢查。對(duì)于枚舉值檢查輸入是否在允許列表中。設(shè)置默認(rèn)值與回退對(duì)于非必需參數(shù)如果模型未提供或提供錯(cuò)誤應(yīng)使用合理的默認(rèn)值。def safe_execute_function(func_name, arguments_str): try: args_dict json.loads(arguments_str) except json.JSONDecodeError: return {“error”: “Invalid JSON format from model”} if func_name “get_weather”: location args_dict.get(“l(fā)ocation”) unit args_dict.get(“unit”, “celsius”) # 提供默認(rèn)值 if not location: return {“error”: “Missing required parameter: location”} if unit not in [“celsius”, “fahrenheit”]: unit “celsius” # 糾正錯(cuò)誤的枚舉值 # 然后才調(diào)用真正的API return call_real_weather_api(location, unit)6.2 工具描述的“藝術(shù)”工具的描述description和參數(shù)描述至關(guān)重要它直接指導(dǎo)模型的行為。描述不清會(huì)導(dǎo)致模型不理解何時(shí)調(diào)用或如何傳參。實(shí)操心得描述要具體、場(chǎng)景化不要寫(xiě)“獲取數(shù)據(jù)”要寫(xiě)“查詢(xún)用戶(hù)最近30天的訂單列表”。好的描述能讓模型準(zhǔn)確判斷調(diào)用時(shí)機(jī)。參數(shù)描述要明確對(duì)于location參數(shù)描述成“城市名如‘北京’或‘San Francisco, CA’”比單純寫(xiě)“地點(diǎn)”要好得多。使用枚舉限制選項(xiàng)如果參數(shù)只有幾個(gè)固定值一定要用enum列出。這能極大減少模型出錯(cuò)的概率。6.3 處理模型的“拒絕”與“多輪”調(diào)用有時(shí)即使用戶(hù)問(wèn)題相關(guān)模型也可能不觸發(fā)工具調(diào)用而是嘗試直接回答可能答錯(cuò)。或者一次對(duì)話(huà)中可能需要連續(xù)調(diào)用多個(gè)工具。應(yīng)對(duì)方案控制tool_choice參數(shù)如果你確定必須調(diào)用某個(gè)工具可以設(shè)置tool_choice{“type”: “function”, “function”: {“name”: “get_weather”}}來(lái)強(qiáng)制模型調(diào)用。通常設(shè)為”auto”即可。設(shè)計(jì)系統(tǒng)提示詞在系統(tǒng)消息中明確指令如“你是一個(gè)天氣助手當(dāng)用戶(hù)詢(xún)問(wèn)天氣時(shí)你必須使用get_weather工具來(lái)獲取最新信息。”管理對(duì)話(huà)歷史在多輪工具調(diào)用中務(wù)必完整、準(zhǔn)確地維護(hù)messages列表確保每次請(qǐng)求都包含完整的上下文用戶(hù)消息、之前的工具調(diào)用、工具返回結(jié)果。這是Agent框架如LangGraph的核心價(jià)值之一。6.4 錯(cuò)誤處理與用戶(hù)體驗(yàn)工具執(zhí)行可能失敗如網(wǎng)絡(luò)超時(shí)、API限流。你不能把一個(gè)Python異常堆棧直接返回給模型。技巧設(shè)計(jì)友好的錯(cuò)誤信息格式返回給模型。例如不要返回{“error”: “HTTP 500”}而是返回{“error”: “Weather service is temporarily unavailable. Please try again later.”}。模型可以基于這個(gè)信息生成面向用戶(hù)的友好提示如“抱歉天氣服務(wù)暫時(shí)不可用請(qǐng)稍后再試。”這比直接拋出技術(shù)錯(cuò)誤要優(yōu)雅得多。7. 超越基礎(chǔ)從Function Calling到AI Agent理解了Function Calling你就拿到了構(gòu)建AI Agent的基石。一個(gè)簡(jiǎn)單的Agent可以看作是一個(gè)永不停歇的循環(huán)While (問(wèn)題未解決): 1. 將當(dāng)前狀態(tài)用戶(hù)目標(biāo)、歷史、可用工具送給LLM。 2. LLM決定下一步行動(dòng)思考、調(diào)用工具、或給出最終答案。 3. 如果調(diào)用工具則執(zhí)行并更新?tīng)顟B(tài)。 4. 重復(fù)步驟1。Function Calling就是這個(gè)循環(huán)中“調(diào)用工具”的標(biāo)準(zhǔn)化接口。而更復(fù)雜的Agent框架如LangGraph, AutoGen則在此基礎(chǔ)上增加了規(guī)劃拆解復(fù)雜目標(biāo)為子任務(wù)。記憶管理長(zhǎng)期和短期對(duì)話(huà)歷史。工具路由從大量工具中自動(dòng)選擇最合適的一個(gè)。多Agent協(xié)作讓多個(gè)具備不同技能的Agent共同完成任務(wù)。例如一個(gè)“旅行規(guī)劃Agent”可能內(nèi)部流程是先調(diào)用“搜索航班”工具再調(diào)用“查詢(xún)酒店”工具然后調(diào)用“計(jì)算預(yù)算”工具最后調(diào)用“生成行程摘要”工具。每一次調(diào)用都是通過(guò)Function Calling協(xié)議來(lái)完成的。所以當(dāng)你下次看到“AI Agent開(kāi)發(fā)”時(shí)可以把它理解為基于LLM大腦和Function Calling手和腳通過(guò)一套調(diào)度邏輯Agent框架來(lái)協(xié)調(diào)完成一系列復(fù)雜任務(wù)目標(biāo)的系統(tǒng)。而這一切的起點(diǎn)就是今天我們從最底層搞明白的這次“請(qǐng)求-執(zhí)行-回調(diào)”的握手。親手寫(xiě)一遍那個(gè)簡(jiǎn)陋的流程勝過(guò)讀十篇概念文章。它讓你看清了華麗外衣下的簡(jiǎn)單骨架。接下來(lái)無(wú)論是使用LangChain快速搭建原型還是深入研究如何用Dify Workflow編排復(fù)雜的業(yè)務(wù)邏輯你都會(huì)心中有數(shù)知道每一步背后究竟在發(fā)生什么。這就是“笨辦法”的力量——它給你的是理解而不僅僅是使用。 深入解析Function Calling：從協(xié)議本質(zhì)到手寫(xiě)實(shí)現(xiàn)大模型工具調(diào)用
1. 從“笨辦法”開(kāi)始為什么Function Calling不是你想的那樣如果你最近在折騰大模型應(yīng)用尤其是想搞點(diǎn)能聯(lián)網(wǎng)、能查天氣、能操作數(shù)據(jù)庫(kù)的“智能體”那你大概率被“Function Calling”這個(gè)詞刷屏了。各種教程、框架文檔里都在提它好像不會(huì)這個(gè)你的AI應(yīng)用就缺了靈魂。但說(shuō)實(shí)話(huà)我第一次看到這個(gè)詞的時(shí)候腦子里也是一團(tuán)漿糊。它聽(tīng)起來(lái)像是一個(gè)具體的函數(shù)調(diào)用動(dòng)作又像是一種協(xié)議還像是一種開(kāi)發(fā)模式。網(wǎng)上的文章要么講得太玄乎要么直接甩給你OpenAI API的JSON格式定義看完之后的感覺(jué)是懂了但又沒(méi)完全懂。今天我們不搞那些云里霧里的概念堆砌就從最“笨”的辦法開(kāi)始親手寫(xiě)一遍。我的核心觀點(diǎn)是Function Calling本質(zhì)上是一種“約定”是大模型LLM和我們寫(xiě)的程序你的代碼之間的一種“對(duì)話(huà)協(xié)議”。它的目的極其單純讓大模型這個(gè)“黑盒子”能明確地告訴我們——“嘿人類(lèi)我現(xiàn)在需要你幫我執(zhí)行某個(gè)具體操作這是操作的名字和參數(shù)你準(zhǔn)備好就告訴我結(jié)果?！焙芏嗳苏`以為Function Calling是大模型“主動(dòng)”調(diào)用了我們的代碼這是一種錯(cuò)覺(jué)。大模型本身只是一段概率預(yù)測(cè)程序它沒(méi)有手不會(huì)執(zhí)行curl命令也不會(huì)寫(xiě)數(shù)據(jù)庫(kù)。它唯一能做的就是根據(jù)我們的“約定”在對(duì)話(huà)的某個(gè)時(shí)刻輸出一段符合特定格式的文本。而我們作為程序的真正控制者需要去“監(jiān)聽(tīng)”這段文本解析它然后才去真正地執(zhí)行函數(shù)最后把執(zhí)行結(jié)果再“喂”回給大模型讓它繼續(xù)思考。所以這個(gè)“笨辦法”就是我們先忘掉LangChain、Dify、各種Agent框架。我們就用最原始的HTTP請(qǐng)求和字符串處理來(lái)模擬一遍這個(gè)“約定”是如何從無(wú)到有建立起來(lái)的。當(dāng)你親手用幾十行代碼把這個(gè)流程跑通你就會(huì)發(fā)現(xiàn)那些高級(jí)框架只不過(guò)是把這個(gè)流程包裝得更優(yōu)雅、更自動(dòng)化而已其核心骨架我們今天就能把它搭出來(lái)。2. 拆解核心一次完整的Function Calling對(duì)話(huà)回合要理解Function Calling我們必須把它放到一次完整的“人-模型-工具”交互回合中去看。這個(gè)回合通常包含四個(gè)清晰的步驟我把它畫(huà)成了一個(gè)簡(jiǎn)單的循環(huán)用戶(hù)提問(wèn) - 模型思考并請(qǐng)求工具 - 程序執(zhí)行工具 - 模型整合結(jié)果并回復(fù)讓我們用一個(gè)最經(jīng)典的例子貫穿始終用戶(hù)問(wèn)“北京今天天氣怎么樣”2.1 第一步我們?nèi)绾巍案嬖V”模型有哪些工具可用大模型不是全知全能的它不知道你的程序里有個(gè)叫g(shù)et_weather的函數(shù)。所以對(duì)話(huà)開(kāi)始前我們必須先“注冊(cè)”工具。在Function Calling的約定里這通常是通過(guò)在發(fā)送給模型的系統(tǒng)提示System Prompt或用戶(hù)消息中附帶一個(gè)“工具列表”來(lái)實(shí)現(xiàn)的。這個(gè)列表不是一個(gè)簡(jiǎn)單的函數(shù)名數(shù)組而是一個(gè)結(jié)構(gòu)化的描述。我們來(lái)看一個(gè)最“笨”的表示方法假設(shè)我們用純文本約定你可以使用的工具 1. 函數(shù)名get_weather - 描述查詢(xún)指定城市的天氣情況。 - 參數(shù)city字符串必需表示城市名稱(chēng)例如“北京”。在實(shí)際的OpenAI API中這個(gè)列表會(huì)被格式化成更機(jī)器可讀的JSON Schema。但本質(zhì)沒(méi)變我們是在用自然語(yǔ)言或結(jié)構(gòu)化數(shù)據(jù)向模型描述一個(gè)“能力”的接口規(guī)范。這就像你給一個(gè)新同事一份操作手冊(cè)告訴他“如果你需要查天氣就告訴我你要調(diào)用‘get_weather’手冊(cè)并且把城市名告訴我?！?.2 第二步模型如何“請(qǐng)求”調(diào)用工具模型收到了用戶(hù)的問(wèn)題“北京今天天氣怎么樣”以及我們提供的工具列表。它開(kāi)始“思考”即進(jìn)行概率計(jì)算。根據(jù)訓(xùn)練數(shù)據(jù)中對(duì)“天氣”和“北京”的關(guān)聯(lián)它很可能判斷出需要調(diào)用get_weather這個(gè)工具。關(guān)鍵來(lái)了模型不會(huì)直接說(shuō)“幫我執(zhí)行g(shù)et_weather(‘北京’)”。在Function Calling的約定下它會(huì)輸出一段嚴(yán)格符合我們約定格式的文本。如果我們約定用JSON它可能會(huì)在回復(fù)中生成一個(gè)特殊的結(jié)構(gòu)塊{ “function_call”: { “name”: “get_weather”, “arguments”: “{ \”city\”: \”北京\” }” } }請(qǐng)注意這里的arguments是一個(gè)字符串里面包裹著一個(gè)JSON對(duì)象。為什么是字符串因?yàn)閷?duì)于模型來(lái)說(shuō)它的一切輸出都是文本流。它只是在按照我們描述的格式生成一段看起來(lái)像JSON的文本。它并不“理解”JSON也不“執(zhí)行”JSON解析。這個(gè)步驟模型僅僅是在說(shuō)“根據(jù)我們的約定我現(xiàn)在需要get_weather功能相關(guān)參數(shù)是city北京我把這個(gè)請(qǐng)求按格式寫(xiě)好了請(qǐng)你指我們的程序來(lái)處理?！弊⒁膺@是最容易產(chǎn)生誤解的地方。模型輸出的{“city”: “北京”}只是一個(gè)文本片段不是可操作的字典。我們的程序必須主動(dòng)去解析這段文本將其轉(zhuǎn)化為真正的數(shù)據(jù)結(jié)構(gòu)。2.3 第三步我們的程序如何“執(zhí)行”并返回結(jié)果我們的程序一直在監(jiān)聽(tīng)模型的回復(fù)。當(dāng)檢測(cè)到回復(fù)中包含”function_call”這個(gè)關(guān)鍵字段時(shí)就知道模型在請(qǐng)求調(diào)用函數(shù)了。這時(shí)我們的程序需要解析從arguments字符串中提取出city的值“北京”。分派根據(jù)name字段的值“get_weather”在我們的代碼中找到對(duì)應(yīng)的真實(shí)函數(shù)。執(zhí)行調(diào)用真實(shí)的get_weather(“北京”)函數(shù)。這個(gè)函數(shù)內(nèi)部可能去調(diào)用一個(gè)天氣API比如心知天氣、和風(fēng)天氣等獲取到真實(shí)的天氣數(shù)據(jù)例如{“temperature”: “22°C”, “condition”: “晴”, “humidity”: “40%”}。格式化將執(zhí)行結(jié)果再次按照約定格式準(zhǔn)備好以便發(fā)回給模型。通常這個(gè)結(jié)果也需要被包裝一下。2.4 第四步模型如何“消化”結(jié)果并給出最終回復(fù)我們將上一步得到的天氣結(jié)果連同最初的對(duì)話(huà)歷史再次發(fā)送給模型。這次發(fā)送的消息很關(guān)鍵通常包含一個(gè)“角色”為”function”的消息內(nèi)容就是我們的執(zhí)行結(jié)果。例如角色: function 名稱(chēng): get_weather 內(nèi)容: {“temperature”: “22°C”, “condition”: “晴”, “humidity”: “40%”}模型看到這條消息后就明白了“哦我之前請(qǐng)求的get_weather工具已經(jīng)執(zhí)行完畢結(jié)果是北京晴22度?！?于是它就能基于這個(gè)真實(shí)、具體的數(shù)據(jù)生成面向用戶(hù)的、自然流暢的最終回復(fù)“北京今天天氣晴朗氣溫22攝氏度濕度40%是個(gè)好天氣?！敝链艘粋€(gè)完整的Function Calling回合結(jié)束。你會(huì)發(fā)現(xiàn)模型始終在它的文本世界里工作而“調(diào)用函數(shù)”這個(gè)物理世界的動(dòng)作是由我們的程序根據(jù)約定“代理”執(zhí)行的。這就是為什么它更準(zhǔn)確的叫法應(yīng)該是“工具調(diào)用”或“函數(shù)調(diào)用請(qǐng)求”。3. 拋開(kāi)框架手寫(xiě)一個(gè)極簡(jiǎn)Function Calling流程現(xiàn)在我們不用任何AI框架只用Python標(biāo)準(zhǔn)庫(kù)和requests庫(kù)來(lái)模擬這個(gè)流程。我們會(huì)創(chuàng)建一個(gè)“虛擬大模型”——一個(gè)簡(jiǎn)單的判斷邏輯來(lái)模擬LLM的決策過(guò)程。3.1 第一步定義工具與虛擬模型首先我們定義真實(shí)的工具函數(shù)和工具描述# 真實(shí)的工具函數(shù) def get_weather(city: str) - str: 模擬查詢(xún)天氣的API調(diào)用 # 這里應(yīng)該是真實(shí)的HTTP請(qǐng)求我們模擬數(shù)據(jù) weather_data { “北京”: “晴朗25°C”, “上?！? “多云28°C”, “深圳”: “陣雨30°C” } return weather_data.get(city, “未找到該城市天氣信息”) # 工具描述我們的“約定” tools_description “”” 你可以使用的工具 - get_weather(city): 查詢(xún)城市天氣。參數(shù)city是字符串如‘北京’。 “”” # 一個(gè)極其簡(jiǎn)陋的“虛擬大模型” def virtual_llm(user_query: str, tools_desc: str) - str: 模擬LLM根據(jù)用戶(hù)輸入和工具描述決定是否調(diào)用工具。 # 簡(jiǎn)單的關(guān)鍵詞匹配來(lái)模擬LLM的“思考” if “天氣” in user_query: # 模擬提取城市實(shí)際LLM會(huì)用更復(fù)雜的方式 city “北京” if “北京” in user_query else “上?！?# 簡(jiǎn)單演示 # 按照我們約定的格式返回工具調(diào)用請(qǐng)求 return f”FUNCTION_CALL: get_weather ARGS: {city}” else: return f”ANSWER: 我不知道如何回答這個(gè)問(wèn)題?！边@個(gè)virtual_llm函數(shù)模擬了核心環(huán)節(jié)它看到了“天氣”關(guān)鍵詞結(jié)合工具描述決定調(diào)用get_weather并以我們自定義的簡(jiǎn)單格式FUNCTION_CALL: func_name ARGS: arg輸出了請(qǐng)求。3.2 第二步構(gòu)建主控循環(huán)接下來(lái)我們編寫(xiě)主程序它負(fù)責(zé)協(xié)調(diào)整個(gè)對(duì)話(huà)流程def main(): print(“系統(tǒng)啟動(dòng)工具已就緒...”) print(f“工具列表\n{tools_description}\n”) # 模擬用戶(hù)輸入 user_query “北京今天天氣怎么樣” print(f“用戶(hù): {user_query}”) # 第一步將用戶(hù)問(wèn)題和工具描述一起交給“模型” llm_response virtual_llm(user_query, tools_description) print(f“虛擬模型回復(fù): {llm_response}”) # 第二步解析模型回復(fù)檢查是否是工具調(diào)用請(qǐng)求 if llm_response.startswith(“FUNCTION_CALL:”): # 解析出函數(shù)名和參數(shù) _, func_info llm_response.split(“FUNCTION_CALL: “) func_name, args_str func_info.split(“ ARGS: “) func_name func_name.strip() args_value args_str.strip() print(f“\n檢測(cè)到工具調(diào)用請(qǐng)求”) print(f“- 函數(shù)名: {func_name}”) print(f“- 參數(shù): {args_value}”) # 第三步根據(jù)函數(shù)名映射并執(zhí)行真實(shí)的函數(shù) if func_name “get_weather”: # 執(zhí)行真正的函數(shù) result get_weather(args_value) print(f“- 執(zhí)行結(jié)果: {result}”) # 第四步將結(jié)果格式化成“函數(shù)響應(yīng)”的格式準(zhǔn)備反饋給模型 func_response f”FUNCTION_RESULT: {result}” print(f“\n將結(jié)果反饋給模型: {func_response}”) # 這里本應(yīng)再次調(diào)用virtual_llm傳入原始問(wèn)題和函數(shù)結(jié)果讓模型生成最終回答。 # 為了簡(jiǎn)化我們直接模擬最終回復(fù)。 final_answer f”根據(jù)查詢(xún)結(jié)果{args_value}的天氣是{result}?！?print(f“\n模型最終回復(fù)用戶(hù): {final_answer}”) else: print(f“錯(cuò)誤未知的函數(shù) {func_name}”) else: # 如果不是工具調(diào)用直接輸出模型回復(fù) print(f“模型直接回復(fù): {llm_response.replace(‘ANSWER: ‘, ”)}”) if __name__ “__main__”: main()運(yùn)行這段代碼你會(huì)看到如下輸出系統(tǒng)啟動(dòng)工具已就緒... 工具列表 你可以使用的工具 - get_weather(city): 查詢(xún)城市天氣。參數(shù)city是字符串如‘北京’。 用戶(hù): 北京今天天氣怎么樣 虛擬模型回復(fù): FUNCTION_CALL: get_weather ARGS: 北京 檢測(cè)到工具調(diào)用請(qǐng)求 - 函數(shù)名: get_weather - 參數(shù): 北京 - 執(zhí)行結(jié)果: 晴朗25°C 將結(jié)果反饋給模型: FUNCTION_RESULT: 晴朗25°C 模型最終回復(fù)用戶(hù): 根據(jù)查詢(xún)結(jié)果北京的天氣是晴朗25°C。3.3 第三步理解這個(gè)“笨辦法”的價(jià)值雖然這個(gè)例子簡(jiǎn)陋到可笑但它完整還原了Function Calling的核心骨架約定我們和“模型”約定了工具描述格式和調(diào)用請(qǐng)求格式FUNCTION_CALL:。請(qǐng)求“模型”按約定格式輸出請(qǐng)求文本。解析與執(zhí)行我們的主程序主動(dòng)解析這段文本并主動(dòng)調(diào)用對(duì)應(yīng)的真實(shí)函數(shù)?；卣{(diào)將執(zhí)行結(jié)果按約定格式返回完成閉環(huán)。OpenAI的Function Calling、Google的Tool Calling乃至所有AI Agent框架如LangChain的Tools、Dify的Workflow都是在將這個(gè)流程標(biāo)準(zhǔn)化、自動(dòng)化、魯棒化。它們定義了更嚴(yán)謹(jǐn)?shù)腏SON Schema來(lái)描述工具提供了自動(dòng)解析和分派調(diào)用的機(jī)制并管理復(fù)雜的多輪對(duì)話(huà)狀態(tài)。但萬(wàn)變不離其宗底層模式就是我們剛才手寫(xiě)的這個(gè)循環(huán)。4. 邁向?qū)崙?zhàn)對(duì)接真實(shí)大模型API理解了本質(zhì)我們?cè)賮?lái)看看如何與真實(shí)的OpenAI API協(xié)作。這里的關(guān)鍵是使用正確的消息格式。4.1 定義符合OpenAI格式的工具OpenAI要求工具定義是一個(gè)JSON Schema列表。我們升級(jí)之前的工具描述tools_for_openai [ { “type”: “function”, “function”: { “name”: “get_weather”, “description”: “Get the current weather in a given location”, “parameters”: { “type”: “object”, “properties”: { “l(fā)ocation”: { “type”: “string”, “description”: “The city and state, e.g. San Francisco, CA”, }, “unit”: {“type”: “string”, “enum”: [“celsius”, “fahrenheit”]}, }, “required”: [“l(fā)ocation”], }, }, } ]這個(gè)結(jié)構(gòu)比我們的純文本描述復(fù)雜得多但它提供了機(jī)器可讀的嚴(yán)格規(guī)范包括參數(shù)類(lèi)型、是否必需、枚舉值等這讓模型能更準(zhǔn)確地生成參數(shù)。4.2 發(fā)起包含工具定義的對(duì)話(huà)請(qǐng)求當(dāng)我們向ChatGPT API發(fā)送請(qǐng)求時(shí)需要將tools參數(shù)傳入import openai response openai.chat.completions.create( model“gpt-3.5-turbo”, messages[ {“role”: “user”, “content”: “What‘s the weather like in Boston?”} ], toolstools_for_openai, # 關(guān)鍵告訴模型可用的工具 tool_choice“auto”, # 讓模型自行決定是否調(diào)用工具 )4.3 解析模型的工具調(diào)用請(qǐng)求模型的回復(fù)response.choices[0].message會(huì)包含一個(gè)tool_calls字段如果它決定調(diào)用工具的話(huà)。我們需要檢查這個(gè)字段message response.choices[0].message if message.tool_calls: # 遍歷所有工具調(diào)用請(qǐng)求理論上一次可以請(qǐng)求多個(gè) for tool_call in message.tool_calls: func_name tool_call.function.name # 注意arguments 是字符串需要解析成字典 import json func_args json.loads(tool_call.function.arguments) location func_args.get(“l(fā)ocation”) print(f“模型請(qǐng)求調(diào)用函數(shù): {func_name}”) print(f“參數(shù): {func_args}”) # 接下來(lái)根據(jù)func_name執(zhí)行你的真實(shí)函數(shù)... # result get_weather(location)4.4 執(zhí)行函數(shù)并將結(jié)果返回給模型執(zhí)行完函數(shù)后我們必須將結(jié)果以特定的“function”角色消息追加到對(duì)話(huà)歷史中并再次請(qǐng)求模型# 假設(shè)我們已經(jīng)獲取了結(jié)果 weather_result {“temperature”: “22”, “unit”: “celsius”, “condition”: “sunny”} # 將函數(shù)執(zhí)行結(jié)果作為一條新消息 messages.append(message) # 先把模型的上一條消息包含tool_calls加入歷史 messages.append({ “role”: “tool”, “tool_call_id”: tool_call.id, # 必須對(duì)應(yīng)之前的調(diào)用ID “content”: json.dumps(weather_result), # 結(jié)果需要是JSON字符串 }) # 再次調(diào)用API讓模型基于結(jié)果生成最終回復(fù) second_response openai.chat.completions.create( model“gpt-3.5-turbo”, messagesmessages, ) final_answer second_response.choices[0].message.content print(f“最終回答: {final_answer}”) # 例如: “It‘s currently sunny and 22°C in Boston.”這個(gè)流程和我們手寫(xiě)的“笨辦法”邏輯完全一致只是消息格式和API調(diào)用被標(biāo)準(zhǔn)化了。框架的價(jià)值就在于幫你自動(dòng)化管理messages數(shù)組的拼接、tool_call_id的匹配、錯(cuò)誤處理等瑣碎細(xì)節(jié)。5. 深入原理大模型是如何“學(xué)會(huì)”調(diào)用函數(shù)的你可能會(huì)有疑問(wèn)大模型是怎么知道在什么時(shí)候、以什么格式來(lái)請(qǐng)求調(diào)用函數(shù)的它并沒(méi)有被“編程”啊。這背后的核心是指令微調(diào)。在模型訓(xùn)練的最后階段研究人員會(huì)使用大量精心構(gòu)造的“對(duì)話(huà)-工具調(diào)用”配對(duì)數(shù)據(jù)對(duì)模型進(jìn)行微調(diào)。這些數(shù)據(jù)的格式就像我們前面演示的完整回合用戶(hù): 北京天氣 助手: 思考我需要調(diào)用get_weather工具。調(diào)用{name: get_weather, arguments: {city: 北京}} 系統(tǒng)(模擬函數(shù)執(zhí)行): {temp: 22°C} 助手: 北京今天氣溫22攝氏度天氣晴朗。模型通過(guò)學(xué)習(xí)海量這樣的例子逐漸掌握了模式“當(dāng)用戶(hù)問(wèn)題涉及某個(gè)領(lǐng)域如天氣而我自身知識(shí)無(wú)法給出具體實(shí)時(shí)數(shù)據(jù)時(shí)我應(yīng)該輸出那個(gè)特定的JSON結(jié)構(gòu)來(lái)‘請(qǐng)求幫助’然后在收到一段結(jié)構(gòu)化的數(shù)據(jù)后再將其組織成自然語(yǔ)言回答?！彼訤unction Calling能力不是魔法而是通過(guò)數(shù)據(jù)訓(xùn)練出來(lái)的、一種對(duì)特定文本模式的條件反射。模型學(xué)到的是一種“溝通協(xié)議”而不是真正的代碼執(zhí)行能力。6. 避坑指南Function Calling實(shí)戰(zhàn)中的常見(jiàn)問(wèn)題在實(shí)際項(xiàng)目中集成Function Calling你會(huì)遇到一些教科書(shū)里不提的坑。這里分享幾個(gè)我踩過(guò)的雷。6.1 參數(shù)格式的“幻覺(jué)”與校驗(yàn)大模型在生成arguments的JSON字符串時(shí)有時(shí)會(huì)產(chǎn)生“幻覺(jué)”輸出格式錯(cuò)誤或參數(shù)值不合理。例如要求數(shù)字它給字符串要求枚舉值它給一個(gè)不在列表里的值。避坑策略永遠(yuǎn)不要信任模型輸出的參數(shù)。必須在你的代碼中進(jìn)行嚴(yán)格的二次校驗(yàn)。JSON解析容錯(cuò)用try-except包裹json.loads()準(zhǔn)備好處理格式錯(cuò)誤的JSON。參數(shù)類(lèi)型轉(zhuǎn)換與驗(yàn)證即使Schema里定義了type: “integer”模型也可能輸出”twenty two”。你需要做類(lèi)型轉(zhuǎn)換和有效性檢查。對(duì)于枚舉值檢查輸入是否在允許列表中。設(shè)置默認(rèn)值與回退對(duì)于非必需參數(shù)如果模型未提供或提供錯(cuò)誤應(yīng)使用合理的默認(rèn)值。def safe_execute_function(func_name, arguments_str): try: args_dict json.loads(arguments_str) except json.JSONDecodeError: return {“error”: “Invalid JSON format from model”} if func_name “get_weather”: location args_dict.get(“l(fā)ocation”) unit args_dict.get(“unit”, “celsius”) # 提供默認(rèn)值 if not location: return {“error”: “Missing required parameter: location”} if unit not in [“celsius”, “fahrenheit”]: unit “celsius” # 糾正錯(cuò)誤的枚舉值 # 然后才調(diào)用真正的API return call_real_weather_api(location, unit)6.2 工具描述的“藝術(shù)”工具的描述description和參數(shù)描述至關(guān)重要它直接指導(dǎo)模型的行為。描述不清會(huì)導(dǎo)致模型不理解何時(shí)調(diào)用或如何傳參。實(shí)操心得描述要具體、場(chǎng)景化不要寫(xiě)“獲取數(shù)據(jù)”要寫(xiě)“查詢(xún)用戶(hù)最近30天的訂單列表”。好的描述能讓模型準(zhǔn)確判斷調(diào)用時(shí)機(jī)。參數(shù)描述要明確對(duì)于location參數(shù)描述成“城市名如‘北京’或‘San Francisco, CA’”比單純寫(xiě)“地點(diǎn)”要好得多。使用枚舉限制選項(xiàng)如果參數(shù)只有幾個(gè)固定值一定要用enum列出。這能極大減少模型出錯(cuò)的概率。6.3 處理模型的“拒絕”與“多輪”調(diào)用有時(shí)即使用戶(hù)問(wèn)題相關(guān)模型也可能不觸發(fā)工具調(diào)用而是嘗試直接回答可能答錯(cuò)。或者一次對(duì)話(huà)中可能需要連續(xù)調(diào)用多個(gè)工具。應(yīng)對(duì)方案控制tool_choice參數(shù)如果你確定必須調(diào)用某個(gè)工具可以設(shè)置tool_choice{“type”: “function”, “function”: {“name”: “get_weather”}}來(lái)強(qiáng)制模型調(diào)用。通常設(shè)為”auto”即可。設(shè)計(jì)系統(tǒng)提示詞在系統(tǒng)消息中明確指令如“你是一個(gè)天氣助手當(dāng)用戶(hù)詢(xún)問(wèn)天氣時(shí)你必須使用get_weather工具來(lái)獲取最新信息。”管理對(duì)話(huà)歷史在多輪工具調(diào)用中務(wù)必完整、準(zhǔn)確地維護(hù)messages列表確保每次請(qǐng)求都包含完整的上下文用戶(hù)消息、之前的工具調(diào)用、工具返回結(jié)果。這是Agent框架如LangGraph的核心價(jià)值之一。6.4 錯(cuò)誤處理與用戶(hù)體驗(yàn)工具執(zhí)行可能失敗如網(wǎng)絡(luò)超時(shí)、API限流。你不能把一個(gè)Python異常堆棧直接返回給模型。技巧設(shè)計(jì)友好的錯(cuò)誤信息格式返回給模型。例如不要返回{“error”: “HTTP 500”}而是返回{“error”: “Weather service is temporarily unavailable. Please try again later.”}。模型可以基于這個(gè)信息生成面向用戶(hù)的友好提示如“抱歉天氣服務(wù)暫時(shí)不可用請(qǐng)稍后再試。”這比直接拋出技術(shù)錯(cuò)誤要優(yōu)雅得多。7. 超越基礎(chǔ)從Function Calling到AI Agent理解了Function Calling你就拿到了構(gòu)建AI Agent的基石。一個(gè)簡(jiǎn)單的Agent可以看作是一個(gè)永不停歇的循環(huán)While (問(wèn)題未解決): 1. 將當(dāng)前狀態(tài)用戶(hù)目標(biāo)、歷史、可用工具送給LLM。 2. LLM決定下一步行動(dòng)思考、調(diào)用工具、或給出最終答案。 3. 如果調(diào)用工具則執(zhí)行并更新?tīng)顟B(tài)。 4. 重復(fù)步驟1。Function Calling就是這個(gè)循環(huán)中“調(diào)用工具”的標(biāo)準(zhǔn)化接口。而更復(fù)雜的Agent框架如LangGraph, AutoGen則在此基礎(chǔ)上增加了規(guī)劃拆解復(fù)雜目標(biāo)為子任務(wù)。記憶管理長(zhǎng)期和短期對(duì)話(huà)歷史。工具路由從大量工具中自動(dòng)選擇最合適的一個(gè)。多Agent協(xié)作讓多個(gè)具備不同技能的Agent共同完成任務(wù)。例如一個(gè)“旅行規(guī)劃Agent”可能內(nèi)部流程是先調(diào)用“搜索航班”工具再調(diào)用“查詢(xún)酒店”工具然后調(diào)用“計(jì)算預(yù)算”工具最后調(diào)用“生成行程摘要”工具。每一次調(diào)用都是通過(guò)Function Calling協(xié)議來(lái)完成的。所以當(dāng)你下次看到“AI Agent開(kāi)發(fā)”時(shí)可以把它理解為基于LLM大腦和Function Calling手和腳通過(guò)一套調(diào)度邏輯Agent框架來(lái)協(xié)調(diào)完成一系列復(fù)雜任務(wù)目標(biāo)的系統(tǒng)。而這一切的起點(diǎn)就是今天我們從最底層搞明白的這次“請(qǐng)求-執(zhí)行-回調(diào)”的握手。親手寫(xiě)一遍那個(gè)簡(jiǎn)陋的流程勝過(guò)讀十篇概念文章。它讓你看清了華麗外衣下的簡(jiǎn)單骨架。接下來(lái)無(wú)論是使用LangChain快速搭建原型還是深入研究如何用Dify Workflow編排復(fù)雜的業(yè)務(wù)邏輯你都會(huì)心中有數(shù)知道每一步背后究竟在發(fā)生什么。這就是“笨辦法”的力量——它給你的是理解而不僅僅是使用。