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