戰(zhàn)：給大模型裝上雙手，實(shí)現(xiàn)真正的AI Agent)
做 Agent 開發(fā)的朋友大概率都遇到過同一個(gè)尷尬大模型嘴上功夫一流寫文案、做總結(jié)、編代碼樣樣都行可一讓它去“做事”立刻就露餡了。你讓它查個(gè)天氣、查個(gè)訂單、算個(gè)運(yùn)費(fèi)它要么給你編一堆看起來像模像樣其實(shí)完全不能用的假數(shù)據(jù)要么直接攤手說“我沒有這個(gè)能力”。不是我黑大模型這是它的架構(gòu)決定的——它壓根沒有長出“手”。今天這篇要講的 Function Call就是給大模型補(bǔ)上這雙手的關(guān)鍵技術(shù)。標(biāo)題里寫的“1.26 Function Call實(shí)戰(zhàn)讓大模型調(diào)用函數(shù)實(shí)現(xiàn)真正的AI Agent”說白了就是解決一個(gè)問題怎么把模型輸出的意圖變成程序里真實(shí)可執(zhí)行的函數(shù)調(diào)用再把函數(shù)結(jié)果回傳給模型形成一個(gè)閉環(huán)。我前后折騰過不少 Agent 項(xiàng)目經(jīng)歷過模型亂填參數(shù)、循環(huán)死磕、上下文爆炸各種坑這輪把完整實(shí)戰(zhàn)過程重新梳理一遍包括設(shè)計(jì)思路、代碼骨架、踩坑記錄盡量一次講透。適合的讀者很明確對 Agent 有基本概念但沒真正跑通 Function Call 的開發(fā)者以及跑通過單個(gè)工具但想把多工具切換、參數(shù)校驗(yàn)、循環(huán)控制做扎實(shí)的朋友。1. 為什么說 Function Call 才是 Agent 的靈魂先把一個(gè)認(rèn)知掰扯清楚很多人做 Agent 的第一反應(yīng)是把所有邏輯塞進(jìn)系統(tǒng)提示詞里讓模型“扮演”一個(gè)角色按固定格式輸出 JSON。這種方式不是不行但天花板非常低。模型自由發(fā)揮生成的 JSON字段命名、嵌套結(jié)構(gòu)、值類型全靠它臨場理解稍微復(fù)雜一點(diǎn)的結(jié)構(gòu)就翻車就算你僥幸讓它輸出對了它也根本沒有真正觸發(fā)任何程序邏輯給用戶的數(shù)據(jù)全是模型自己“腦補(bǔ)”出來的。Function Call 解決的痛點(diǎn)非常直接它讓模型不再自由輸出一段文本而是輸出一個(gè)“結(jié)構(gòu)化調(diào)用意圖”。程序收到這個(gè)意圖后負(fù)責(zé)去執(zhí)行真實(shí)的函數(shù)把結(jié)果拿回來再交給模型繼續(xù)推理。這個(gè)動(dòng)作不是提示詞能穩(wěn)定約束出來的它是模型在訓(xùn)練階段就被專門對齊過的能力輸出的參數(shù)會(huì)嚴(yán)格跟隨你聲明的 JSON Schema甚至字段類型不對它還會(huì)自動(dòng)修正。1.1 模型為什么天生夠不到外部世界稍微回顧一下大模型的推理過程模型接收的是 token 序列輸出的也是 token 序列從頭到尾它沒有任何途徑去發(fā) HTTP 請求、讀寫數(shù)據(jù)庫、執(zhí)行系統(tǒng)命令。模型內(nèi)部沒有一個(gè)“操作系統(tǒng)”的概念它不知道現(xiàn)在是幾點(diǎn)幾分不知道某個(gè)接口正在返回什么數(shù)據(jù)更不可能去感知你業(yè)務(wù)系統(tǒng)里的實(shí)時(shí)狀態(tài)。你問它“今天市場大盤怎么樣”它給出的答案來自訓(xùn)練數(shù)據(jù)里的歷史記憶運(yùn)氣好能對上運(yùn)氣不好就是一本正經(jīng)地胡說八道。所以如果你希望模型具備“感知能力”“行動(dòng)能力”就必須在模型之外搭一條通路。Function Call 正是這條通路的“協(xié)議層”你提前聲明一批函數(shù)告訴模型這些函數(shù)各自長什么樣、需要什么參數(shù)、能干什么事。當(dāng)模型在推理過程中發(fā)現(xiàn)自己缺信息、缺動(dòng)作時(shí)它會(huì)生成一個(gè)特定格式的輸出表示“我需要調(diào)用 get_weather參數(shù)是 city北京”。真正執(zhí)行天氣接口的是宿主代碼不是模型。執(zhí)行完了宿主把結(jié)果作為一條新的消息塞回對話歷史模型看到結(jié)果后才能繼續(xù)組織最終答案。這條通路一旦打通模型就從“只讀記憶庫”升級成了“可操作智能體”。這也是為什么幾乎所有主流的大模型服務(wù)都在原生接口里支持了工具調(diào)用能力。1.2 它和普通 JSON 輸出的關(guān)鍵差異不少人問過我我讓模型“輸出 JSON”和“調(diào)用函數(shù)”到底有什么區(qū)別區(qū)別非常大。普通 JSON 輸出本質(zhì)上還是文本生成。模型在生成 token 的時(shí)候它只對“這段文字長得像不像 JSON”有粗糙的判斷并不保證字段一定齊全類型一定正確枚舉值一定合法。更麻煩的是模型并不知道這段 JSON 會(huì)被拿去干什么它不會(huì)主動(dòng)“記得”自己剛才說要調(diào)用某個(gè)函數(shù)后續(xù)對話也不會(huì)圍繞這個(gè)函數(shù)結(jié)果展開。Function Call 則不同。平臺(tái)層面有一套專門的機(jī)制約束模型輸出模型生成的是一個(gè)結(jié)構(gòu)化的“函數(shù)調(diào)用對象”里面包含函數(shù)名和平臺(tái)按參數(shù) Schema 解析好的參數(shù)對象。模型清楚自己發(fā)出了調(diào)用也清楚函數(shù)結(jié)果會(huì)在下一輪回到對話里所以它的推理狀態(tài)是連續(xù)的。這種“意圖執(zhí)行反饋”的閉環(huán)結(jié)構(gòu)才是 Agent 循環(huán)真正的基礎(chǔ)。2. 動(dòng)手寫代碼前先把設(shè)計(jì)骨架想清楚我在這個(gè)專題里踩過最大的坑就是沒想清楚全局結(jié)構(gòu)就急著抄代碼最后各個(gè)函數(shù)之間耦合得一團(tuán)糟。建議你動(dòng)手之前先把四個(gè)問題想明白工具從哪來、描述怎么寫、參數(shù)怎么定、調(diào)用結(jié)果怎么回喂。這四個(gè)問題直接決定代碼長什么樣別指望后面能隨便糊弄過去。2.1 別再硬編碼工具列表了用注冊表模式實(shí)際項(xiàng)目里Agent 不可能只調(diào)一個(gè)函數(shù)。查天氣、查庫存、算運(yùn)費(fèi)、寫工單、查日歷動(dòng)輒十幾個(gè)工具。如果你在每次請求前手動(dòng)組裝一份 JSON Schema 數(shù)組改一次工具加一次代碼維護(hù)起來太痛苦了。更合理的方式是做一個(gè)工具注冊表用一個(gè)字典維護(hù)“工具名”到“函數(shù)本體參數(shù)Schema”的映射提供一個(gè)裝飾器或者注冊函數(shù)讓各模塊自行注冊自己的工具主循環(huán)統(tǒng)一遍歷注冊表動(dòng)態(tài)生成所有 Schema 提交給模型。我用這個(gè)模式很久了最大的好處是工具之間互不干擾。某個(gè)模塊想新增一個(gè)工具只需要在模塊內(nèi)部調(diào)用注冊器主流程一行代碼都不用改。而且這個(gè)注冊表是可以熱更新的工具下線直接摘掉對應(yīng)條目模型下一輪對話就感知不到這個(gè)工具了不用重新部署整個(gè)服務(wù)。2.2 參數(shù) Schema 的寫法決定了成功率先強(qiáng)調(diào)一句Function Call 里最容易翻車的不是代碼邏輯是工具描述和參數(shù) Schema 寫得太爛。模型非常依賴你給出的文本描述來理解這個(gè)工具該不該用、參數(shù)該怎么填。比如你寫“查詢天氣”模型可能模模糊糊知道用如果你寫“根據(jù)城市名返回實(shí)時(shí)天氣數(shù)據(jù)適用于需要告知用戶當(dāng)前戶外溫度、風(fēng)力、降水概率的場景”模型就知道得很清楚。參數(shù)描述也一樣。不是只聲明一個(gè)字段類型就完事每個(gè)字段的 description 最好寫清楚取值范圍和填寫規(guī)則。比如城市字段你要注明“必須是標(biāo)準(zhǔn)的城市中文名稱例如北京、上海不接受拼音”。我發(fā)現(xiàn)加了這類約束以后參數(shù)亂填的概率直線下降。不要給模型太多自由發(fā)揮的余地能收斂盡量收斂。能用枚舉約束的值就列枚舉能用字符串模板約束的就寫正則提示能拆成多個(gè)小參數(shù)的就別合成一個(gè)大 JSON 對象。2.3 溫度參數(shù)和工具選擇策略要提前定模型服務(wù)的配置里temperature 和工具選擇策略都會(huì)顯著影響工具調(diào)用質(zhì)量。temperature 決定隨機(jī)性寫代碼類、檢索類任務(wù)我一般壓到 0.2 以下不然模型可能同一個(gè)意圖輸出不同的參數(shù)導(dǎo)致結(jié)果不穩(wěn)定。工具選擇策略一般有三檔自動(dòng)選擇、強(qiáng)制調(diào)用指定工具、完全不調(diào)用本批工具。自動(dòng)模式下模型根據(jù)用戶輸入判斷要不要調(diào)用工具適合通用對話場景強(qiáng)制模式適合做結(jié)構(gòu)化提取任務(wù)比如你明確希望模型把用戶的一段話轉(zhuǎn)成“創(chuàng)建工單”的函數(shù)調(diào)用那就直接指定必須調(diào)用這個(gè)工具。還有一種情況是某些敏感場景你希望模型堅(jiān)決不碰工具比如純閑聊模式那就把工具列表傳空就行。這個(gè)策略在代碼里一般叫 tool_choice動(dòng)手前想清楚你的核心場景偏哪一邊能少走很多彎路。3. 完整實(shí)操從零跑通第一次函數(shù)調(diào)用下面直接進(jìn)入代碼環(huán)節(jié)。我以兼容主流接口的 SDK 寫法來演示你可以把 client 替換成自己項(xiàng)目里的服務(wù)端實(shí)例。整個(gè)流程分四步定義函數(shù)、聲明 Schema、發(fā)起帶工具請求、解析并執(zhí)行函數(shù)調(diào)用。3.1 先定義兩個(gè)實(shí)實(shí)在在的業(yè)務(wù)函數(shù)為了方便演示我寫兩個(gè)最常見的函數(shù)一個(gè)是查天氣一個(gè)是查某商品庫存。這兩個(gè)函數(shù)體本身不重要關(guān)鍵是它們要能被宿主代碼真正執(zhí)行并且返回給模型的結(jié)果得是便于閱讀的文本結(jié)構(gòu)。import json import urllib.request from typing import Any def get_weather(city: str) - str: 根據(jù)城市名返回真實(shí)的天氣快訊這里用模擬接口示意。 # 實(shí)際項(xiàng)目中這里會(huì)請求天氣服務(wù)商接口 mock_data { 北京: {temp: 17, wind: 3級, condition: 晴}, 上海: {temp: 22, wind: 2級, condition: 多云}, } info mock_data.get(city) if info is None: return f未找到城市 {city} 的天氣數(shù)據(jù) return f{city}氣溫 {info[temp]}℃風(fēng)力 {info[wind]}天氣 {info[condition]} def get_inventory(product_id: str) - str: 根據(jù)商品ID查詢實(shí)時(shí)庫存。 mock_data { A001: {name: 無線鍵盤, stock: 120}, A002: {name: 顯示器支架, stock: 45}, } info mock_data.get(product_id) if info is None: return f商品 {product_id} 不存在 return f商品 {info[name]} 當(dāng)前庫存 {info[stock]} 件函數(shù)返回字符串這個(gè)地方我是刻意這么設(shè)計(jì)的。函數(shù)返回結(jié)構(gòu)最好提前約定成“人類可讀的一句話摘要”或者“緊湊的結(jié)構(gòu)化數(shù)據(jù)”因?yàn)槟Ｐ蜁?huì)把這串文本當(dāng)作上下文來推理。如果函數(shù)返回一個(gè)巨大無比的對象不僅浪費(fèi) token還容易把模型的注意力帶偏。3.2 把函數(shù)聲明成模型能理解的工具 Schema下一步是把函數(shù)轉(zhuǎn)換成平臺(tái)要求的結(jié)構(gòu)。每家平臺(tái)大同小異核心是四個(gè)字段type、function、name、description、parameters。parameters 內(nèi)部是 JSON Schema 格式。TOOLS [ { type: function, function: { name: get_weather, description: 查詢指定城市當(dāng)前天氣、氣溫、風(fēng)力與天氣現(xiàn)象。適用于用戶詢問天氣、出行建議、戶外活動(dòng)安排等場景。, parameters: { type: object, properties: { city: { type: string, description: 標(biāo)準(zhǔn)中文城市名例如北京、上海不接受拼音/縮寫。 } }, required: [city] } } }, { type: function, function: { name: get_inventory, description: 根據(jù)商品ID查詢商品當(dāng)前庫存數(shù)量與名稱。適用于用戶咨詢現(xiàn)貨、下單前確認(rèn)庫存等場景。, parameters: { type: object, properties: { product_id: { type: string, description: 商品唯一編號(hào)格式為大寫字母加三位數(shù)字例如A001。 } }, required: [product_id] } } } ]這里我要特意強(qiáng)調(diào)下 description 的寫法。不要寫“查詢天氣”這種一句話最好帶上“約束條件使用范圍”。模型判斷一個(gè)工具要不要用依據(jù)就是 description 的語義信號(hào)。描述越明確誤調(diào)用率越低。我見過把 description 寫得含糊導(dǎo)致模型把所有問題都往某一個(gè)大而全的工具上套排查半天才發(fā)現(xiàn)是描述歧義。3.3 帶工具發(fā)起第一輪請求并解析調(diào)用意圖建立好清單之后就可以發(fā)起請求了。這里給你看最核心的請求代碼和響應(yīng)解析邏輯。def call_llm(messages: list[dict], tools: list[dict] | None None, tool_choice: str auto): 封裝一次模型請求。 payload { model: your-model-name, messages: messages, tools: tools or [], tool_choice: tool_choice, temperature: 0.1, } resp client.chat.completions.create(**payload) return resp.choices[0].message第一輪對話用戶說“上海天氣怎么樣順便看看 A001 還有沒有貨”。這時(shí) messages 里只有 user 一條消息。模型拿到工具列表后會(huì)返回一個(gè) assistant 消息里面帶 tool_calls 數(shù)組結(jié)構(gòu)大致是這樣的message.tool_calls [ { id: call_abc123, function: { name: get_weather, arguments: {city: 上海} } }, { id: call_def456, function: { name: get_inventory, arguments: {product_id: A001} } } ]現(xiàn)在你需要做的是根據(jù)這個(gè)名字去注冊表里找到真實(shí)函數(shù)再把 arguments 里的 JSON 字符串解析成 Python 字典進(jìn)行函數(shù)調(diào)用。def execute_tool_call(tool_call): 執(zhí)行單個(gè)工具調(diào)用返回 (tool_name, tool_response)。 name tool_call.function.name args json.loads(tool_call.function.arguments) if name get_weather: result get_weather(**args) elif name get_inventory: result get_inventory(**args) else: result f未注冊的工具: {name} return name, result真實(shí)項(xiàng)目里“elif 堆一長串”顯然很蠢。配合前面說的注冊表模式這個(gè)函數(shù)應(yīng)該變成從注冊表查表執(zhí)行而不是手寫一堆分支。我這里是為了看得直觀實(shí)際生產(chǎn)環(huán)境請務(wù)必用注冊表。3.4 將函數(shù)結(jié)果回傳給模型生成最終回復(fù)函數(shù)執(zhí)行完了結(jié)果不能偷偷摸摸丟掉必須組裝回服務(wù)器的對話上下文。設(shè)計(jì)是這樣的先把 assistant 消息原樣 append 進(jìn) messages然后對每一個(gè) tool_calls 里的調(diào)用都 append 一條 role 為 tool 的消息tool_call_id 對應(yīng)調(diào)用里的 idcontent 放函數(shù)結(jié)果字符串。def agent_once(user_text: str): messages [{role: user, content: user_text}] assistant_msg call_llm(messages, TOOLS) messages.append({ role: assistant, content: assistant_msg.content or , tool_calls: [{ id: tc.id, type: function, function: {name: tc.function.name, arguments: tc.function.arguments} } for tc in (assistant_msg.tool_calls or [])] }) for tc in assistant_msg.tool_calls: name, result execute_tool_call(tc) messages.append({ role: tool, tool_call_id: tc.id, name: name, content: result }) final_msg call_llm(messages, TOOLS) return final_msg.content這輪關(guān)鍵點(diǎn)在于模型的第二次請求能看到“它自己剛才說要調(diào)哪些函數(shù)”以及“這些函數(shù)執(zhí)行后的真實(shí)結(jié)果”。它必須同時(shí)掌握這兩部分信息才能摒棄編造基于真實(shí)返回值組織最終回答。我最初寫代碼時(shí)有一版只回傳結(jié)果不回傳 assistant 的 tool_calls結(jié)果模型完全不知道結(jié)果對應(yīng)哪個(gè)函數(shù)邏輯直接錯(cuò)亂這個(gè)坑大家別踩。到這里一輪最基本的 Function Call 閉環(huán)就通了。是不是感覺原理上不難難的其實(shí)是把它擴(kuò)展成一個(gè)穩(wěn)定的 Agent 循環(huán)。4. 從單次調(diào)用升級成完整 Agent 循環(huán)單次調(diào)用只能解決“一次性工具請求”。但真實(shí) Agent 場景里用戶的第一句話往往不能一步到位。比如用戶說“幫我規(guī)劃一份周末出行方案”模型可能需要先查天氣再查目的地門票還要查周邊餐廳又或者一次工具執(zhí)行完模型發(fā)現(xiàn)還缺信息需要二次調(diào)用。這就需要一個(gè) while 循環(huán)讓模型反復(fù)“思考-調(diào)用-觀察-再思考”直到它不再產(chǎn)生新的 tool_calls 為止。4.1 一個(gè)足夠穩(wěn)健的 Agent 主循環(huán)核心思路不復(fù)雜每次請求之后檢查返回的 assistant 消息里有沒有 tool_calls。如果有就執(zhí)行把結(jié)果追加到 messages然后帶著最新上下文繼續(xù)請求如果沒有說明模型已經(jīng)拿到足夠信息當(dāng)前輪的 content 就是最終答案。下面是核心循環(huán)骨架def run_agent(user_text: str, max_steps: int 8): messages [{role: user, content: user_text}] for step in range(max_steps): assistant_msg call_llm(messages, TOOLS) if not assistant_msg.tool_calls: return assistant_msg.content, messages # 記錄 assistant 的工具調(diào)用意圖 messages.append({ role: assistant, content: assistant_msg.content or , tool_calls: [{ id: tc.id, type: function, function: {name: tc.function.name, arguments: tc.function.arguments} } for tc in assistant_msg.tool_calls] }) # 逐個(gè)執(zhí)行并把結(jié)果追加到上下文 for tc in assistant_msg.tool_calls: name, result execute_tool_call(tc) messages.append({ role: tool, tool_call_id: tc.id, name: name, content: result }) print(f[step-{step1}] 調(diào)用函數(shù): {[tc.function.name for tc in assistant_msg.tool_calls]}) return 達(dá)到最大步驟限制未獲得最終答復(fù), messagesmax_steps 這個(gè)參數(shù)是個(gè)保險(xiǎn)絲。沒有它模型可能在一個(gè)問題上反復(fù)調(diào)用工具停不下來既浪費(fèi) token 又拖慢響應(yīng)。我一般給 610具體看業(yè)務(wù)復(fù)雜度。日志里把每一步調(diào)用了什么函數(shù)打出來調(diào)試時(shí)救命。4.2 支持并行工具調(diào)用但別強(qiáng)求順序現(xiàn)在主流模型服務(wù)基本都支持一次返回多個(gè)并行 tool_calls。比如前面那個(gè)例子“查上海天氣”和“查 A001 庫存”兩個(gè)調(diào)用之間沒有任何依賴關(guān)系同時(shí)發(fā)起效率更高。循環(huán)里逐個(gè)執(zhí)行沒有問題因?yàn)閷τ跊]有依賴的工具先執(zhí)行后執(zhí)行不影響最終結(jié)果?？晌冶仨毺嵝岩坏┠硞€(gè)工具的輸出要被另一個(gè)工具當(dāng)輸入并行就會(huì)出問題。比如“查詢某倉庫的庫存并為庫存不足的商品生成補(bǔ)貨訂單”第一個(gè)函數(shù)的輸出決定了第二個(gè)函數(shù)的參數(shù)這兩個(gè)就不能并行必須先執(zhí)行第一個(gè)把結(jié)果作為新消息塞回去讓模型看到之后再去調(diào)用第二個(gè)工具。不要指望模型在這個(gè)問題上替你判斷你可以把參數(shù)描述里寫清楚依賴關(guān)系或者干脆把兩步合并成一個(gè)函數(shù)。4.3 上下文管理是 Agent 循環(huán)里最大的暗坑每一輪工具調(diào)用的返回結(jié)果都會(huì)追加到 messages 里。理論上循環(huán)步數(shù)一多上下文就會(huì)越來越長token 消耗呈線性上漲。更麻煩的是有些工具返回結(jié)果特別長比如查詢數(shù)據(jù)庫返回幾百條記錄全部塞進(jìn)上下文既浪費(fèi) token又會(huì)讓模型“記”不住真正重要的信息。我處理這個(gè)問題的思路有三條。一是讓工具的返回結(jié)果盡量精煉函數(shù)內(nèi)部做好匯總只返回模型需要的那幾項(xiàng)關(guān)鍵信息別動(dòng)不動(dòng)就返回一整個(gè)原始報(bào)文。二是對歷史消息做截?cái)喑^一定輪數(shù)就把早期消息折疊成摘要比如用模型對已完成對話生成壓縮摘要替換掉原始消息。三是針對長文本工具結(jié)果做二次提煉先把原始結(jié)果喂給一個(gè)小模型生成結(jié)構(gòu)化摘要再丟回主上下文。這三種策略按需組合實(shí)測下來能省掉不少開銷。4.4 進(jìn)階用工具協(xié)議把 Agent 能力標(biāo)準(zhǔn)化等你的 Function Call 架構(gòu)跑穩(wěn)之后你會(huì)發(fā)現(xiàn)不同 Agent 項(xiàng)目之間的大量工具邏輯是重復(fù)的。這時(shí)候可以考慮引入標(biāo)準(zhǔn)化工具協(xié)議比如 MCP把工具注冊、參數(shù)聲明、調(diào)用執(zhí)行的方式統(tǒng)一起來。我不是勸所有團(tuán)隊(duì)都第一時(shí)間上 MCP而是想說你的架構(gòu)理應(yīng)做到“工具與主流程解耦”這樣將來無論接哪種協(xié)議遷移成本都很低。先把注冊表和主循環(huán)寫好后續(xù)就是換一個(gè)加載后端的問題。我這里沒有展開講協(xié)議細(xì)節(jié)因?yàn)楫?dāng)前專題的重點(diǎn)是把 Function Call 實(shí)戰(zhàn)跑通但架構(gòu)上你務(wù)必留好擴(kuò)展位。5. 高頻問題與排查技巧實(shí)錄這部分內(nèi)容基本都是我在項(xiàng)目里一條一條填坑填出來的。每一個(gè)問題都真實(shí)到讓人血壓升高列成速查表方便你遇到直接翻?，F(xiàn)象可能原因排查與調(diào)整思路模型就是不返回 tool_calls工具描述語義不清晰或用戶問題與工具關(guān)聯(lián)性太弱加強(qiáng) description把“什么時(shí)候用、什么時(shí)候不用”寫明白也可以直接調(diào)整 tool_choice 為 required返回的 arguments 不是合法 JSON模型服務(wù)解析異?；騾?shù) Schema 過于復(fù)雜檢查 Schema 是否嵌套過深盡量拍平某些模型對嵌套對象類型支持不穩(wěn)定參數(shù)值不符合預(yù)期比如城市名填了拼音字段 description 約束不夠在描述里寫死格式要求能用枚舉用枚舉并提供示例值同一功能重復(fù)調(diào)用多輪停不下來函數(shù)返回結(jié)果沒讓模型得到充分信息或者缺失終止條件檢查工具返回值是否說清楚了“成功/失敗/缺什么”給循環(huán)加 max_steps 保險(xiǎn)絲應(yīng)答中混入了工具返回原始報(bào)文返回值太長模型直接復(fù)述精簡返回值函數(shù)內(nèi)部先做匯總或摘要工具報(bào)錯(cuò)但模型還在繼續(xù)沒有設(shè)計(jì)錯(cuò)誤回傳機(jī)制函數(shù)異常要捕獲把錯(cuò)誤信息作為 tool 消息回傳給模型讓它有機(jī)會(huì)修復(fù)或向用戶說明換一個(gè)模型服務(wù)后調(diào)用風(fēng)格變了各家平臺(tái)的 tool_calls 字段名、結(jié)構(gòu)有細(xì)微差異抽象一層適配器解析統(tǒng)一轉(zhuǎn)成內(nèi)部結(jié)構(gòu)避免業(yè)務(wù)代碼散落解析邏輯5.1 模型返回了工具調(diào)用但函數(shù)報(bào)錯(cuò)了怎么辦千萬別把異常吞掉就完事。我推薦的做法是函數(shù)體內(nèi)做嚴(yán)格 try-except一旦出錯(cuò)把錯(cuò)誤說明直接作為該工具的返回內(nèi)容。模型看到“當(dāng)前接口超時(shí)請稍后重試”之后通常會(huì)自己組織一句對用戶更友好的回復(fù)或者干脆重新發(fā)起一次調(diào)用。這個(gè)設(shè)計(jì)比你在宿主代碼里寫一堆重試邏輯簡單有效得多。不過要注意模型自行重試不能無限重試所以外層 while 循環(huán)的 step 上限還是要把控。5.2 參數(shù)校驗(yàn)到底該放在模型側(cè)還是函數(shù)側(cè)答案很明確兩側(cè)都要。模型側(cè)靠 Schema 和 description 盡量防止錯(cuò)誤產(chǎn)生函數(shù)側(cè)則用強(qiáng)校驗(yàn)兜底接收參數(shù)后立刻做類型檢查、取值校驗(yàn)防止臟數(shù)據(jù)流入業(yè)務(wù)邏輯。比如 get_weather 的 city 參數(shù)函數(shù)內(nèi)要檢查它是字符串且去掉首尾空格后非空如果為空就返回固定錯(cuò)誤而不是直接拋 KeyError。這一層保護(hù)看起來冗余但能顯著提升 Agent 的穩(wěn)定性。5.3 如何避免模型“猜”參數(shù)模型在沒有足夠信息時(shí)傾向于根據(jù)上下文猜一個(gè)值。比如用戶說“幫我查一下天氣”沒說城市模型很可能自己腦補(bǔ)一個(gè)默認(rèn)城市調(diào)函數(shù)。解決辦法是把“缺信息就要反問用戶”的邏輯寫進(jìn) description或者干脆在參數(shù)校驗(yàn)時(shí)發(fā)現(xiàn)缺了核心參數(shù)返回“參數(shù)缺失城市名請向用戶確認(rèn)城市”。甚至可以考慮在函數(shù)體內(nèi)檢查參數(shù)當(dāng)檢測到可疑默認(rèn)值時(shí)強(qiáng)制讓模型回問。我在一個(gè)模擬項(xiàng)目里就是靠這套機(jī)制把無效調(diào)用率從三成壓到了不到一成。5.4 嚴(yán)格模式下每次產(chǎn)生的日志要留好日志不建議只記最終回復(fù)。每一輪的 tool_calls 內(nèi)容、函數(shù)執(zhí)行結(jié)果、耗時(shí)、token 數(shù)最好都結(jié)構(gòu)化落盤。排查問題的時(shí)候你會(huì)發(fā)現(xiàn)錯(cuò)誤往往出現(xiàn)在交互的第三輪、第四輪沒有中間過程日志你根本沒法定位。我一般會(huì)把 messages 快照打成 JSON 存到日志系統(tǒng)方便事后回放。這屬于看起來不起眼、但真正救命的設(shè)計(jì)。6. 從單函數(shù)到工具生態(tài)一次實(shí)戰(zhàn)引發(fā)的延伸思考Function Call 跑通只是起點(diǎn)。我在實(shí)際項(xiàng)目里體會(huì)最深的是它把大模型從“對話機(jī)器”解放成了“任務(wù)編排器”。但工具一旦多起來新的問題跟著就來模型面對幾十個(gè)工具選錯(cuò)工具的概率會(huì)明顯上升。這時(shí)候就要對工具做分類分組或者子路由先讓模型選定領(lǐng)域再在該領(lǐng)域的工具子集里做二次選擇類似路由網(wǎng)關(guān)的概念。也就是說Agent 自身就是一個(gè)分層系統(tǒng)不是把一堆工具平鋪給模型就完事。另一個(gè)體面是工具的設(shè)計(jì)要以“模型能理解”為前提。很多團(tuán)隊(duì)把給程序用的 API 直接拿來當(dāng)工具參數(shù)非常工程化字段名全是縮寫比如 prodId、sku 之類。模型對這種參數(shù)名是很懵的。做工具的 Schema 前應(yīng)該像寫產(chǎn)品文案一樣把每個(gè)字段講明白必要時(shí)為 Agent 封裝一層“翻譯層”把內(nèi)部參數(shù)形式轉(zhuǎn)化成模型好理解的語義形式。這一步做好整個(gè) Agent 的成功率都會(huì)有明顯提升反而是很多人忽略的細(xì)節(jié)。還有Function Call 與內(nèi)容審核也有關(guān)聯(lián)。工具一旦能操作真實(shí)業(yè)務(wù)系統(tǒng)就意味著模型權(quán)限和用戶權(quán)限都要受管控。不是所有工具都該無條件暴露給所有用戶函數(shù)執(zhí)行前要有一層鑒權(quán)至少要校驗(yàn)當(dāng)前會(huì)話是否允許調(diào)用該工具。安全設(shè)計(jì)一定要前置別等出了事故再補(bǔ)這個(gè)不是恐嚇是干過的人都懂的教訓(xùn)。7. 最后分享一點(diǎn)我的個(gè)人實(shí)操心得如果只留一句話我想說Function Call 的難點(diǎn)從來不在“把接口調(diào)通”而在“把工具聲明設(shè)計(jì)得像人話、把循環(huán)寫穩(wěn)、把異常想全”。我在第一次做多函數(shù) Agent 的時(shí)候犯過最蠢的錯(cuò)誤就是在函數(shù)返回里塞入大量無關(guān)字段結(jié)果模型在后續(xù)回答里一本正經(jīng)地復(fù)述了那一堆亂碼。后來我把每個(gè)工具的結(jié)果全部改成“面向模型重新組織的摘要文案”質(zhì)量立刻上去了。這個(gè)思路你們可以直接抄。另外建議你從今天就開始積累自己的“工具描述語料庫”。哪類描述命中率高、哪些詞容易讓模型誤判這些都是跑出來的經(jīng)驗(yàn)多記錄多對比多迭代比照搬任何一份現(xiàn)成模板都管用。Agent 這個(gè)方向才剛剛開始Function Call 是地基地基穩(wěn)了后面無論是接新的模型服務(wù)、擴(kuò)展工具協(xié)議都會(huì)順手很多。 Function Call實(shí)戰(zhàn)：給大模型裝上雙手，實(shí)現(xiàn)真正的AI Agent
做 Agent 開發(fā)的朋友大概率都遇到過同一個(gè)尷尬大模型嘴上功夫一流寫文案、做總結(jié)、編代碼樣樣都行可一讓它去“做事”立刻就露餡了。你讓它查個(gè)天氣、查個(gè)訂單、算個(gè)運(yùn)費(fèi)它要么給你編一堆看起來像模像樣其實(shí)完全不能用的假數(shù)據(jù)要么直接攤手說“我沒有這個(gè)能力”。不是我黑大模型這是它的架構(gòu)決定的——它壓根沒有長出“手”。今天這篇要講的 Function Call就是給大模型補(bǔ)上這雙手的關(guān)鍵技術(shù)。標(biāo)題里寫的“1.26 Function Call實(shí)戰(zhàn)讓大模型調(diào)用函數(shù)實(shí)現(xiàn)真正的AI Agent”說白了就是解決一個(gè)問題怎么把模型輸出的意圖變成程序里真實(shí)可執(zhí)行的函數(shù)調(diào)用再把函數(shù)結(jié)果回傳給模型形成一個(gè)閉環(huán)。我前后折騰過不少 Agent 項(xiàng)目經(jīng)歷過模型亂填參數(shù)、循環(huán)死磕、上下文爆炸各種坑這輪把完整實(shí)戰(zhàn)過程重新梳理一遍包括設(shè)計(jì)思路、代碼骨架、踩坑記錄盡量一次講透。適合的讀者很明確對 Agent 有基本概念但沒真正跑通 Function Call 的開發(fā)者以及跑通過單個(gè)工具但想把多工具切換、參數(shù)校驗(yàn)、循環(huán)控制做扎實(shí)的朋友。1. 為什么說 Function Call 才是 Agent 的靈魂先把一個(gè)認(rèn)知掰扯清楚很多人做 Agent 的第一反應(yīng)是把所有邏輯塞進(jìn)系統(tǒng)提示詞里讓模型“扮演”一個(gè)角色按固定格式輸出 JSON。這種方式不是不行但天花板非常低。模型自由發(fā)揮生成的 JSON字段命名、嵌套結(jié)構(gòu)、值類型全靠它臨場理解稍微復(fù)雜一點(diǎn)的結(jié)構(gòu)就翻車就算你僥幸讓它輸出對了它也根本沒有真正觸發(fā)任何程序邏輯給用戶的數(shù)據(jù)全是模型自己“腦補(bǔ)”出來的。Function Call 解決的痛點(diǎn)非常直接它讓模型不再自由輸出一段文本而是輸出一個(gè)“結(jié)構(gòu)化調(diào)用意圖”。程序收到這個(gè)意圖后負(fù)責(zé)去執(zhí)行真實(shí)的函數(shù)把結(jié)果拿回來再交給模型繼續(xù)推理。這個(gè)動(dòng)作不是提示詞能穩(wěn)定約束出來的它是模型在訓(xùn)練階段就被專門對齊過的能力輸出的參數(shù)會(huì)嚴(yán)格跟隨你聲明的 JSON Schema甚至字段類型不對它還會(huì)自動(dòng)修正。1.1 模型為什么天生夠不到外部世界稍微回顧一下大模型的推理過程模型接收的是 token 序列輸出的也是 token 序列從頭到尾它沒有任何途徑去發(fā) HTTP 請求、讀寫數(shù)據(jù)庫、執(zhí)行系統(tǒng)命令。模型內(nèi)部沒有一個(gè)“操作系統(tǒng)”的概念它不知道現(xiàn)在是幾點(diǎn)幾分不知道某個(gè)接口正在返回什么數(shù)據(jù)更不可能去感知你業(yè)務(wù)系統(tǒng)里的實(shí)時(shí)狀態(tài)。你問它“今天市場大盤怎么樣”它給出的答案來自訓(xùn)練數(shù)據(jù)里的歷史記憶運(yùn)氣好能對上運(yùn)氣不好就是一本正經(jīng)地胡說八道。所以如果你希望模型具備“感知能力”“行動(dòng)能力”就必須在模型之外搭一條通路。Function Call 正是這條通路的“協(xié)議層”你提前聲明一批函數(shù)告訴模型這些函數(shù)各自長什么樣、需要什么參數(shù)、能干什么事。當(dāng)模型在推理過程中發(fā)現(xiàn)自己缺信息、缺動(dòng)作時(shí)它會(huì)生成一個(gè)特定格式的輸出表示“我需要調(diào)用 get_weather參數(shù)是 city北京”。真正執(zhí)行天氣接口的是宿主代碼不是模型。執(zhí)行完了宿主把結(jié)果作為一條新的消息塞回對話歷史模型看到結(jié)果后才能繼續(xù)組織最終答案。這條通路一旦打通模型就從“只讀記憶庫”升級成了“可操作智能體”。這也是為什么幾乎所有主流的大模型服務(wù)都在原生接口里支持了工具調(diào)用能力。1.2 它和普通 JSON 輸出的關(guān)鍵差異不少人問過我我讓模型“輸出 JSON”和“調(diào)用函數(shù)”到底有什么區(qū)別區(qū)別非常大。普通 JSON 輸出本質(zhì)上還是文本生成。模型在生成 token 的時(shí)候它只對“這段文字長得像不像 JSON”有粗糙的判斷并不保證字段一定齊全類型一定正確枚舉值一定合法。更麻煩的是模型并不知道這段 JSON 會(huì)被拿去干什么它不會(huì)主動(dòng)“記得”自己剛才說要調(diào)用某個(gè)函數(shù)后續(xù)對話也不會(huì)圍繞這個(gè)函數(shù)結(jié)果展開。Function Call 則不同。平臺(tái)層面有一套專門的機(jī)制約束模型輸出模型生成的是一個(gè)結(jié)構(gòu)化的“函數(shù)調(diào)用對象”里面包含函數(shù)名和平臺(tái)按參數(shù) Schema 解析好的參數(shù)對象。模型清楚自己發(fā)出了調(diào)用也清楚函數(shù)結(jié)果會(huì)在下一輪回到對話里所以它的推理狀態(tài)是連續(xù)的。這種“意圖執(zhí)行反饋”的閉環(huán)結(jié)構(gòu)才是 Agent 循環(huán)真正的基礎(chǔ)。2. 動(dòng)手寫代碼前先把設(shè)計(jì)骨架想清楚我在這個(gè)專題里踩過最大的坑就是沒想清楚全局結(jié)構(gòu)就急著抄代碼最后各個(gè)函數(shù)之間耦合得一團(tuán)糟。建議你動(dòng)手之前先把四個(gè)問題想明白工具從哪來、描述怎么寫、參數(shù)怎么定、調(diào)用結(jié)果怎么回喂。這四個(gè)問題直接決定代碼長什么樣別指望后面能隨便糊弄過去。2.1 別再硬編碼工具列表了用注冊表模式實(shí)際項(xiàng)目里Agent 不可能只調(diào)一個(gè)函數(shù)。查天氣、查庫存、算運(yùn)費(fèi)、寫工單、查日歷動(dòng)輒十幾個(gè)工具。如果你在每次請求前手動(dòng)組裝一份 JSON Schema 數(shù)組改一次工具加一次代碼維護(hù)起來太痛苦了。更合理的方式是做一個(gè)工具注冊表用一個(gè)字典維護(hù)“工具名”到“函數(shù)本體參數(shù)Schema”的映射提供一個(gè)裝飾器或者注冊函數(shù)讓各模塊自行注冊自己的工具主循環(huán)統(tǒng)一遍歷注冊表動(dòng)態(tài)生成所有 Schema 提交給模型。我用這個(gè)模式很久了最大的好處是工具之間互不干擾。某個(gè)模塊想新增一個(gè)工具只需要在模塊內(nèi)部調(diào)用注冊器主流程一行代碼都不用改。而且這個(gè)注冊表是可以熱更新的工具下線直接摘掉對應(yīng)條目模型下一輪對話就感知不到這個(gè)工具了不用重新部署整個(gè)服務(wù)。2.2 參數(shù) Schema 的寫法決定了成功率先強(qiáng)調(diào)一句Function Call 里最容易翻車的不是代碼邏輯是工具描述和參數(shù) Schema 寫得太爛。模型非常依賴你給出的文本描述來理解這個(gè)工具該不該用、參數(shù)該怎么填。比如你寫“查詢天氣”模型可能模模糊糊知道用如果你寫“根據(jù)城市名返回實(shí)時(shí)天氣數(shù)據(jù)適用于需要告知用戶當(dāng)前戶外溫度、風(fēng)力、降水概率的場景”模型就知道得很清楚。參數(shù)描述也一樣。不是只聲明一個(gè)字段類型就完事每個(gè)字段的 description 最好寫清楚取值范圍和填寫規(guī)則。比如城市字段你要注明“必須是標(biāo)準(zhǔn)的城市中文名稱例如北京、上海不接受拼音”。我發(fā)現(xiàn)加了這類約束以后參數(shù)亂填的概率直線下降。不要給模型太多自由發(fā)揮的余地能收斂盡量收斂。能用枚舉約束的值就列枚舉能用字符串模板約束的就寫正則提示能拆成多個(gè)小參數(shù)的就別合成一個(gè)大 JSON 對象。2.3 溫度參數(shù)和工具選擇策略要提前定模型服務(wù)的配置里temperature 和工具選擇策略都會(huì)顯著影響工具調(diào)用質(zhì)量。temperature 決定隨機(jī)性寫代碼類、檢索類任務(wù)我一般壓到 0.2 以下不然模型可能同一個(gè)意圖輸出不同的參數(shù)導(dǎo)致結(jié)果不穩(wěn)定。工具選擇策略一般有三檔自動(dòng)選擇、強(qiáng)制調(diào)用指定工具、完全不調(diào)用本批工具。自動(dòng)模式下模型根據(jù)用戶輸入判斷要不要調(diào)用工具適合通用對話場景強(qiáng)制模式適合做結(jié)構(gòu)化提取任務(wù)比如你明確希望模型把用戶的一段話轉(zhuǎn)成“創(chuàng)建工單”的函數(shù)調(diào)用那就直接指定必須調(diào)用這個(gè)工具。還有一種情況是某些敏感場景你希望模型堅(jiān)決不碰工具比如純閑聊模式那就把工具列表傳空就行。這個(gè)策略在代碼里一般叫 tool_choice動(dòng)手前想清楚你的核心場景偏哪一邊能少走很多彎路。3. 完整實(shí)操從零跑通第一次函數(shù)調(diào)用下面直接進(jìn)入代碼環(huán)節(jié)。我以兼容主流接口的 SDK 寫法來演示你可以把 client 替換成自己項(xiàng)目里的服務(wù)端實(shí)例。整個(gè)流程分四步定義函數(shù)、聲明 Schema、發(fā)起帶工具請求、解析并執(zhí)行函數(shù)調(diào)用。3.1 先定義兩個(gè)實(shí)實(shí)在在的業(yè)務(wù)函數(shù)為了方便演示我寫兩個(gè)最常見的函數(shù)一個(gè)是查天氣一個(gè)是查某商品庫存。這兩個(gè)函數(shù)體本身不重要關(guān)鍵是它們要能被宿主代碼真正執(zhí)行并且返回給模型的結(jié)果得是便于閱讀的文本結(jié)構(gòu)。import json import urllib.request from typing import Any def get_weather(city: str) - str: 根據(jù)城市名返回真實(shí)的天氣快訊這里用模擬接口示意。 # 實(shí)際項(xiàng)目中這里會(huì)請求天氣服務(wù)商接口 mock_data { 北京: {temp: 17, wind: 3級, condition: 晴}, 上海: {temp: 22, wind: 2級, condition: 多云}, } info mock_data.get(city) if info is None: return f未找到城市 {city} 的天氣數(shù)據(jù) return f{city}氣溫 {info[temp]}℃風(fēng)力 {info[wind]}天氣 {info[condition]} def get_inventory(product_id: str) - str: 根據(jù)商品ID查詢實(shí)時(shí)庫存。 mock_data { A001: {name: 無線鍵盤, stock: 120}, A002: {name: 顯示器支架, stock: 45}, } info mock_data.get(product_id) if info is None: return f商品 {product_id} 不存在 return f商品 {info[name]} 當(dāng)前庫存 {info[stock]} 件函數(shù)返回字符串這個(gè)地方我是刻意這么設(shè)計(jì)的。函數(shù)返回結(jié)構(gòu)最好提前約定成“人類可讀的一句話摘要”或者“緊湊的結(jié)構(gòu)化數(shù)據(jù)”因?yàn)槟Ｐ蜁?huì)把這串文本當(dāng)作上下文來推理。如果函數(shù)返回一個(gè)巨大無比的對象不僅浪費(fèi) token還容易把模型的注意力帶偏。3.2 把函數(shù)聲明成模型能理解的工具 Schema下一步是把函數(shù)轉(zhuǎn)換成平臺(tái)要求的結(jié)構(gòu)。每家平臺(tái)大同小異核心是四個(gè)字段type、function、name、description、parameters。parameters 內(nèi)部是 JSON Schema 格式。TOOLS [ { type: function, function: { name: get_weather, description: 查詢指定城市當(dāng)前天氣、氣溫、風(fēng)力與天氣現(xiàn)象。適用于用戶詢問天氣、出行建議、戶外活動(dòng)安排等場景。, parameters: { type: object, properties: { city: { type: string, description: 標(biāo)準(zhǔn)中文城市名例如北京、上海不接受拼音/縮寫。 } }, required: [city] } } }, { type: function, function: { name: get_inventory, description: 根據(jù)商品ID查詢商品當(dāng)前庫存數(shù)量與名稱。適用于用戶咨詢現(xiàn)貨、下單前確認(rèn)庫存等場景。, parameters: { type: object, properties: { product_id: { type: string, description: 商品唯一編號(hào)格式為大寫字母加三位數(shù)字例如A001。 } }, required: [product_id] } } } ]這里我要特意強(qiáng)調(diào)下 description 的寫法。不要寫“查詢天氣”這種一句話最好帶上“約束條件使用范圍”。模型判斷一個(gè)工具要不要用依據(jù)就是 description 的語義信號(hào)。描述越明確誤調(diào)用率越低。我見過把 description 寫得含糊導(dǎo)致模型把所有問題都往某一個(gè)大而全的工具上套排查半天才發(fā)現(xiàn)是描述歧義。3.3 帶工具發(fā)起第一輪請求并解析調(diào)用意圖建立好清單之后就可以發(fā)起請求了。這里給你看最核心的請求代碼和響應(yīng)解析邏輯。def call_llm(messages: list[dict], tools: list[dict] | None None, tool_choice: str auto): 封裝一次模型請求。 payload { model: your-model-name, messages: messages, tools: tools or [], tool_choice: tool_choice, temperature: 0.1, } resp client.chat.completions.create(**payload) return resp.choices[0].message第一輪對話用戶說“上海天氣怎么樣順便看看 A001 還有沒有貨”。這時(shí) messages 里只有 user 一條消息。模型拿到工具列表后會(huì)返回一個(gè) assistant 消息里面帶 tool_calls 數(shù)組結(jié)構(gòu)大致是這樣的message.tool_calls [ { id: call_abc123, function: { name: get_weather, arguments: {city: 上海} } }, { id: call_def456, function: { name: get_inventory, arguments: {product_id: A001} } } ]現(xiàn)在你需要做的是根據(jù)這個(gè)名字去注冊表里找到真實(shí)函數(shù)再把 arguments 里的 JSON 字符串解析成 Python 字典進(jìn)行函數(shù)調(diào)用。def execute_tool_call(tool_call): 執(zhí)行單個(gè)工具調(diào)用返回 (tool_name, tool_response)。 name tool_call.function.name args json.loads(tool_call.function.arguments) if name get_weather: result get_weather(**args) elif name get_inventory: result get_inventory(**args) else: result f未注冊的工具: {name} return name, result真實(shí)項(xiàng)目里“elif 堆一長串”顯然很蠢。配合前面說的注冊表模式這個(gè)函數(shù)應(yīng)該變成從注冊表查表執(zhí)行而不是手寫一堆分支。我這里是為了看得直觀實(shí)際生產(chǎn)環(huán)境請務(wù)必用注冊表。3.4 將函數(shù)結(jié)果回傳給模型生成最終回復(fù)函數(shù)執(zhí)行完了結(jié)果不能偷偷摸摸丟掉必須組裝回服務(wù)器的對話上下文。設(shè)計(jì)是這樣的先把 assistant 消息原樣 append 進(jìn) messages然后對每一個(gè) tool_calls 里的調(diào)用都 append 一條 role 為 tool 的消息tool_call_id 對應(yīng)調(diào)用里的 idcontent 放函數(shù)結(jié)果字符串。def agent_once(user_text: str): messages [{role: user, content: user_text}] assistant_msg call_llm(messages, TOOLS) messages.append({ role: assistant, content: assistant_msg.content or , tool_calls: [{ id: tc.id, type: function, function: {name: tc.function.name, arguments: tc.function.arguments} } for tc in (assistant_msg.tool_calls or [])] }) for tc in assistant_msg.tool_calls: name, result execute_tool_call(tc) messages.append({ role: tool, tool_call_id: tc.id, name: name, content: result }) final_msg call_llm(messages, TOOLS) return final_msg.content這輪關(guān)鍵點(diǎn)在于模型的第二次請求能看到“它自己剛才說要調(diào)哪些函數(shù)”以及“這些函數(shù)執(zhí)行后的真實(shí)結(jié)果”。它必須同時(shí)掌握這兩部分信息才能摒棄編造基于真實(shí)返回值組織最終回答。我最初寫代碼時(shí)有一版只回傳結(jié)果不回傳 assistant 的 tool_calls結(jié)果模型完全不知道結(jié)果對應(yīng)哪個(gè)函數(shù)邏輯直接錯(cuò)亂這個(gè)坑大家別踩。到這里一輪最基本的 Function Call 閉環(huán)就通了。是不是感覺原理上不難難的其實(shí)是把它擴(kuò)展成一個(gè)穩(wěn)定的 Agent 循環(huán)。4. 從單次調(diào)用升級成完整 Agent 循環(huán)單次調(diào)用只能解決“一次性工具請求”。但真實(shí) Agent 場景里用戶的第一句話往往不能一步到位。比如用戶說“幫我規(guī)劃一份周末出行方案”模型可能需要先查天氣再查目的地門票還要查周邊餐廳又或者一次工具執(zhí)行完模型發(fā)現(xiàn)還缺信息需要二次調(diào)用。這就需要一個(gè) while 循環(huán)讓模型反復(fù)“思考-調(diào)用-觀察-再思考”直到它不再產(chǎn)生新的 tool_calls 為止。4.1 一個(gè)足夠穩(wěn)健的 Agent 主循環(huán)核心思路不復(fù)雜每次請求之后檢查返回的 assistant 消息里有沒有 tool_calls。如果有就執(zhí)行把結(jié)果追加到 messages然后帶著最新上下文繼續(xù)請求如果沒有說明模型已經(jīng)拿到足夠信息當(dāng)前輪的 content 就是最終答案。下面是核心循環(huán)骨架def run_agent(user_text: str, max_steps: int 8): messages [{role: user, content: user_text}] for step in range(max_steps): assistant_msg call_llm(messages, TOOLS) if not assistant_msg.tool_calls: return assistant_msg.content, messages # 記錄 assistant 的工具調(diào)用意圖 messages.append({ role: assistant, content: assistant_msg.content or , tool_calls: [{ id: tc.id, type: function, function: {name: tc.function.name, arguments: tc.function.arguments} } for tc in assistant_msg.tool_calls] }) # 逐個(gè)執(zhí)行并把結(jié)果追加到上下文 for tc in assistant_msg.tool_calls: name, result execute_tool_call(tc) messages.append({ role: tool, tool_call_id: tc.id, name: name, content: result }) print(f[step-{step1}] 調(diào)用函數(shù): {[tc.function.name for tc in assistant_msg.tool_calls]}) return 達(dá)到最大步驟限制未獲得最終答復(fù), messagesmax_steps 這個(gè)參數(shù)是個(gè)保險(xiǎn)絲。沒有它模型可能在一個(gè)問題上反復(fù)調(diào)用工具停不下來既浪費(fèi) token 又拖慢響應(yīng)。我一般給 610具體看業(yè)務(wù)復(fù)雜度。日志里把每一步調(diào)用了什么函數(shù)打出來調(diào)試時(shí)救命。4.2 支持并行工具調(diào)用但別強(qiáng)求順序現(xiàn)在主流模型服務(wù)基本都支持一次返回多個(gè)并行 tool_calls。比如前面那個(gè)例子“查上海天氣”和“查 A001 庫存”兩個(gè)調(diào)用之間沒有任何依賴關(guān)系同時(shí)發(fā)起效率更高。循環(huán)里逐個(gè)執(zhí)行沒有問題因?yàn)閷τ跊]有依賴的工具先執(zhí)行后執(zhí)行不影響最終結(jié)果?？晌冶仨毺嵝岩坏┠硞€(gè)工具的輸出要被另一個(gè)工具當(dāng)輸入并行就會(huì)出問題。比如“查詢某倉庫的庫存并為庫存不足的商品生成補(bǔ)貨訂單”第一個(gè)函數(shù)的輸出決定了第二個(gè)函數(shù)的參數(shù)這兩個(gè)就不能并行必須先執(zhí)行第一個(gè)把結(jié)果作為新消息塞回去讓模型看到之后再去調(diào)用第二個(gè)工具。不要指望模型在這個(gè)問題上替你判斷你可以把參數(shù)描述里寫清楚依賴關(guān)系或者干脆把兩步合并成一個(gè)函數(shù)。4.3 上下文管理是 Agent 循環(huán)里最大的暗坑每一輪工具調(diào)用的返回結(jié)果都會(huì)追加到 messages 里。理論上循環(huán)步數(shù)一多上下文就會(huì)越來越長token 消耗呈線性上漲。更麻煩的是有些工具返回結(jié)果特別長比如查詢數(shù)據(jù)庫返回幾百條記錄全部塞進(jìn)上下文既浪費(fèi) token又會(huì)讓模型“記”不住真正重要的信息。我處理這個(gè)問題的思路有三條。一是讓工具的返回結(jié)果盡量精煉函數(shù)內(nèi)部做好匯總只返回模型需要的那幾項(xiàng)關(guān)鍵信息別動(dòng)不動(dòng)就返回一整個(gè)原始報(bào)文。二是對歷史消息做截?cái)喑^一定輪數(shù)就把早期消息折疊成摘要比如用模型對已完成對話生成壓縮摘要替換掉原始消息。三是針對長文本工具結(jié)果做二次提煉先把原始結(jié)果喂給一個(gè)小模型生成結(jié)構(gòu)化摘要再丟回主上下文。這三種策略按需組合實(shí)測下來能省掉不少開銷。4.4 進(jìn)階用工具協(xié)議把 Agent 能力標(biāo)準(zhǔn)化等你的 Function Call 架構(gòu)跑穩(wěn)之后你會(huì)發(fā)現(xiàn)不同 Agent 項(xiàng)目之間的大量工具邏輯是重復(fù)的。這時(shí)候可以考慮引入標(biāo)準(zhǔn)化工具協(xié)議比如 MCP把工具注冊、參數(shù)聲明、調(diào)用執(zhí)行的方式統(tǒng)一起來。我不是勸所有團(tuán)隊(duì)都第一時(shí)間上 MCP而是想說你的架構(gòu)理應(yīng)做到“工具與主流程解耦”這樣將來無論接哪種協(xié)議遷移成本都很低。先把注冊表和主循環(huán)寫好后續(xù)就是換一個(gè)加載后端的問題。我這里沒有展開講協(xié)議細(xì)節(jié)因?yàn)楫?dāng)前專題的重點(diǎn)是把 Function Call 實(shí)戰(zhàn)跑通但架構(gòu)上你務(wù)必留好擴(kuò)展位。5. 高頻問題與排查技巧實(shí)錄這部分內(nèi)容基本都是我在項(xiàng)目里一條一條填坑填出來的。每一個(gè)問題都真實(shí)到讓人血壓升高列成速查表方便你遇到直接翻?，F(xiàn)象可能原因排查與調(diào)整思路模型就是不返回 tool_calls工具描述語義不清晰或用戶問題與工具關(guān)聯(lián)性太弱加強(qiáng) description把“什么時(shí)候用、什么時(shí)候不用”寫明白也可以直接調(diào)整 tool_choice 為 required返回的 arguments 不是合法 JSON模型服務(wù)解析異?；騾?shù) Schema 過于復(fù)雜檢查 Schema 是否嵌套過深盡量拍平某些模型對嵌套對象類型支持不穩(wěn)定參數(shù)值不符合預(yù)期比如城市名填了拼音字段 description 約束不夠在描述里寫死格式要求能用枚舉用枚舉并提供示例值同一功能重復(fù)調(diào)用多輪停不下來函數(shù)返回結(jié)果沒讓模型得到充分信息或者缺失終止條件檢查工具返回值是否說清楚了“成功/失敗/缺什么”給循環(huán)加 max_steps 保險(xiǎn)絲應(yīng)答中混入了工具返回原始報(bào)文返回值太長模型直接復(fù)述精簡返回值函數(shù)內(nèi)部先做匯總或摘要工具報(bào)錯(cuò)但模型還在繼續(xù)沒有設(shè)計(jì)錯(cuò)誤回傳機(jī)制函數(shù)異常要捕獲把錯(cuò)誤信息作為 tool 消息回傳給模型讓它有機(jī)會(huì)修復(fù)或向用戶說明換一個(gè)模型服務(wù)后調(diào)用風(fēng)格變了各家平臺(tái)的 tool_calls 字段名、結(jié)構(gòu)有細(xì)微差異抽象一層適配器解析統(tǒng)一轉(zhuǎn)成內(nèi)部結(jié)構(gòu)避免業(yè)務(wù)代碼散落解析邏輯5.1 模型返回了工具調(diào)用但函數(shù)報(bào)錯(cuò)了怎么辦千萬別把異常吞掉就完事。我推薦的做法是函數(shù)體內(nèi)做嚴(yán)格 try-except一旦出錯(cuò)把錯(cuò)誤說明直接作為該工具的返回內(nèi)容。模型看到“當(dāng)前接口超時(shí)請稍后重試”之后通常會(huì)自己組織一句對用戶更友好的回復(fù)或者干脆重新發(fā)起一次調(diào)用。這個(gè)設(shè)計(jì)比你在宿主代碼里寫一堆重試邏輯簡單有效得多。不過要注意模型自行重試不能無限重試所以外層 while 循環(huán)的 step 上限還是要把控。5.2 參數(shù)校驗(yàn)到底該放在模型側(cè)還是函數(shù)側(cè)答案很明確兩側(cè)都要。模型側(cè)靠 Schema 和 description 盡量防止錯(cuò)誤產(chǎn)生函數(shù)側(cè)則用強(qiáng)校驗(yàn)兜底接收參數(shù)后立刻做類型檢查、取值校驗(yàn)防止臟數(shù)據(jù)流入業(yè)務(wù)邏輯。比如 get_weather 的 city 參數(shù)函數(shù)內(nèi)要檢查它是字符串且去掉首尾空格后非空如果為空就返回固定錯(cuò)誤而不是直接拋 KeyError。這一層保護(hù)看起來冗余但能顯著提升 Agent 的穩(wěn)定性。5.3 如何避免模型“猜”參數(shù)模型在沒有足夠信息時(shí)傾向于根據(jù)上下文猜一個(gè)值。比如用戶說“幫我查一下天氣”沒說城市模型很可能自己腦補(bǔ)一個(gè)默認(rèn)城市調(diào)函數(shù)。解決辦法是把“缺信息就要反問用戶”的邏輯寫進(jìn) description或者干脆在參數(shù)校驗(yàn)時(shí)發(fā)現(xiàn)缺了核心參數(shù)返回“參數(shù)缺失城市名請向用戶確認(rèn)城市”。甚至可以考慮在函數(shù)體內(nèi)檢查參數(shù)當(dāng)檢測到可疑默認(rèn)值時(shí)強(qiáng)制讓模型回問。我在一個(gè)模擬項(xiàng)目里就是靠這套機(jī)制把無效調(diào)用率從三成壓到了不到一成。5.4 嚴(yán)格模式下每次產(chǎn)生的日志要留好日志不建議只記最終回復(fù)。每一輪的 tool_calls 內(nèi)容、函數(shù)執(zhí)行結(jié)果、耗時(shí)、token 數(shù)最好都結(jié)構(gòu)化落盤。排查問題的時(shí)候你會(huì)發(fā)現(xiàn)錯(cuò)誤往往出現(xiàn)在交互的第三輪、第四輪沒有中間過程日志你根本沒法定位。我一般會(huì)把 messages 快照打成 JSON 存到日志系統(tǒng)方便事后回放。這屬于看起來不起眼、但真正救命的設(shè)計(jì)。6. 從單函數(shù)到工具生態(tài)一次實(shí)戰(zhàn)引發(fā)的延伸思考Function Call 跑通只是起點(diǎn)。我在實(shí)際項(xiàng)目里體會(huì)最深的是它把大模型從“對話機(jī)器”解放成了“任務(wù)編排器”。但工具一旦多起來新的問題跟著就來模型面對幾十個(gè)工具選錯(cuò)工具的概率會(huì)明顯上升。這時(shí)候就要對工具做分類分組或者子路由先讓模型選定領(lǐng)域再在該領(lǐng)域的工具子集里做二次選擇類似路由網(wǎng)關(guān)的概念。也就是說Agent 自身就是一個(gè)分層系統(tǒng)不是把一堆工具平鋪給模型就完事。另一個(gè)體面是工具的設(shè)計(jì)要以“模型能理解”為前提。很多團(tuán)隊(duì)把給程序用的 API 直接拿來當(dāng)工具參數(shù)非常工程化字段名全是縮寫比如 prodId、sku 之類。模型對這種參數(shù)名是很懵的。做工具的 Schema 前應(yīng)該像寫產(chǎn)品文案一樣把每個(gè)字段講明白必要時(shí)為 Agent 封裝一層“翻譯層”把內(nèi)部參數(shù)形式轉(zhuǎn)化成模型好理解的語義形式。這一步做好整個(gè) Agent 的成功率都會(huì)有明顯提升反而是很多人忽略的細(xì)節(jié)。還有Function Call 與內(nèi)容審核也有關(guān)聯(lián)。工具一旦能操作真實(shí)業(yè)務(wù)系統(tǒng)就意味著模型權(quán)限和用戶權(quán)限都要受管控。不是所有工具都該無條件暴露給所有用戶函數(shù)執(zhí)行前要有一層鑒權(quán)至少要校驗(yàn)當(dāng)前會(huì)話是否允許調(diào)用該工具。安全設(shè)計(jì)一定要前置別等出了事故再補(bǔ)這個(gè)不是恐嚇是干過的人都懂的教訓(xùn)。7. 最后分享一點(diǎn)我的個(gè)人實(shí)操心得如果只留一句話我想說Function Call 的難點(diǎn)從來不在“把接口調(diào)通”而在“把工具聲明設(shè)計(jì)得像人話、把循環(huán)寫穩(wěn)、把異常想全”。我在第一次做多函數(shù) Agent 的時(shí)候犯過最蠢的錯(cuò)誤就是在函數(shù)返回里塞入大量無關(guān)字段結(jié)果模型在后續(xù)回答里一本正經(jīng)地復(fù)述了那一堆亂碼。后來我把每個(gè)工具的結(jié)果全部改成“面向模型重新組織的摘要文案”質(zhì)量立刻上去了。這個(gè)思路你們可以直接抄。另外建議你從今天就開始積累自己的“工具描述語料庫”。哪類描述命中率高、哪些詞容易讓模型誤判這些都是跑出來的經(jīng)驗(yàn)多記錄多對比多迭代比照搬任何一份現(xiàn)成模板都管用。Agent 這個(gè)方向才剛剛開始Function Call 是地基地基穩(wěn)了后面無論是接新的模型服務(wù)、擴(kuò)展工具協(xié)議都會(huì)順手很多。