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