做AI Agent開發(fā)的這幾年有一個問題被反復問到也貫穿了幾乎所有項目從原型到落地的全過程面對LLM一次模型請求到底應該怎么發(fā)是直接扔一段自然語言讓它返回文本還是把工具清單塞給它讓它在里面選又或者在一開始就告訴它“你必須給我吐出一份符合固定Schema的JSON”標題里的“單次模型請求”指的是Agent在執(zhí)行一個原子步驟時對LLM發(fā)起的那一次獨立調(diào)用。這個問題看起來基礎到不值一提但我在好幾個項目里都發(fā)現(xiàn)不同的請求方式直接決定了下游代碼是穩(wěn)定得讓人放心還是間歇性抽風。這幾種方式本質上是三類完全不同的接口形態(tài)。這篇文章不準備講“Agent框架怎么搭建”這種大而全的東西只想把單次請求這件事拆開揉碎講講三種主流方式各自的原理、適用邊界、以及我在實際項目中踩過的坑和最終沉淀下來的選型思路。如果你正在寫Agent的編排層或者被模型輸出解析搞得焦頭爛額這篇應該能給你省不少時間。1. 為什么單次模型請求能決定一個Agent的下限很多剛接觸Agent的開發(fā)者都有一個錯覺既然LLM這么聰明那Agent的核心競爭力肯定在“聰明”上面。但實際做下來你會發(fā)現(xiàn)真正決定一個Agent系統(tǒng)穩(wěn)定性的往往不是模型多聰明而是每一次請求的輸出是否“可預期、可解析、可流程化”。調(diào)用LLM的方式就是那個把不可控的“聰明”翻譯成可控代碼行為的關鍵接口。1.1 從“對話生成器”到“決策循環(huán)器”接口思維的轉變傳統(tǒng)聊天機器人調(diào)用LLM本質上是“生成一段好看的文本”。用戶問一句模型答一段只要文字通順、語氣自然這個請求就算成功了。但Agent的場景完全不一樣它的核心是一個循環(huán)感知當前狀態(tài)決定下一步動作執(zhí)行動作觀察結果再決定下一步。在這個循環(huán)里LLM的輸出不再是一個終點而是一個被代碼消費的中間產(chǎn)物它可能是“調(diào)用哪個工具”也可能是“從這段文本里抽取出的結構化參數(shù)”還可能是“對當前狀態(tài)的分類判斷”。這就帶來一個本質變化模型的輸出必須能被程序可靠地解析和分發(fā)而不是被用戶閱讀。如果你用“生成文本”的方式去驅動一個“決策循環(huán)”就好像要求一個相聲演員同時兼任流程控制語句——他能說但他不知道你什么時候該斷句。三種主流請求方式本質上就是三種把大腦輸出“降維”成程序輸入的語言協(xié)議。1.2 單次請求承載的三類任務形態(tài)決策、抽取、并聯(lián)工具在具體項目里我把Agent的單次請求任務歸納成三種形態(tài)它們對應了三種請求方式的“用戶意圖”。第一類是決策型任務輸入當前上下文輸出一個對后續(xù)流程的走向判斷。比如判斷用戶這句話是閑聊還是要下單或者判斷當前狀態(tài)是否滿足某個終止條件。這類任務對輸出的要求是“少數(shù)幾個確定的候選值”。第二類是抽取型任務從一段非結構化文本中提取結構化信息比如從郵件里抽取時間、地點、參與人最后轉成一個標準的事件對象。第三類是執(zhí)行型任務模型需要從一堆可用工具中挑選合適的一個或多個并生成對應的調(diào)用參數(shù)這一步最接近傳統(tǒng)程序中“函數(shù)分派”的邏輯。有意思的是這三種任務形態(tài)并不是互斥的一個真實Agent的同一輪請求里經(jīng)常同時包含“判斷”和“抽取”的成分。后面要聊的三種請求方式剛好能覆蓋它們的不同側重。而你的任務就是根據(jù)當前節(jié)點更需要“穩(wěn)定的協(xié)議”還是“開放的語義”去選擇對應的請求方式。2. 方式一自然語言補全式簡單場景下的夠用方案先說最傳統(tǒng)的方式把對話歷史、系統(tǒng)提示詞、用戶輸入拼成一個消息數(shù)組發(fā)給模型然后拿到一段完整的文本回復。這是大多數(shù)開發(fā)者最熟悉的一條路徑也是最容易糊弄過去的一條因為它的輸出“看起來”最自然。2.1 補全式請求的原理與使用邊界這種方式的核心原理就是讓模型根據(jù)已有的上下文做“最合理的續(xù)寫”。你給它一個系統(tǒng)提示“你是一個意圖判斷助手只輸出買家或者賣家”再把用戶問題拼接進去模型會接著這個續(xù)寫趨勢輸出“買家”或“賣家”。代碼寫出來大概是這樣的示范結構response client.chat.completions.create( model合適的模型標識, messages[ {role: system, content: 你是一個意圖判斷助手。只輸出字母A或B不要輸出其他內(nèi)容。}, {role: user, content: 用戶說我想把閑置的衣服賣出去。請判斷意圖。} ], temperature0.2, max_tokens20 )這種方式最大的優(yōu)勢是簡單、無依賴不需要維護工具Schema也不需要額外的結構化約束。在項目早期或者單點小判斷的場景下非常夠用比如一個客服機器人需要判斷用戶的情緒極性或者一個信息錄入腳本需要判斷一段文本里有沒有包含聯(lián)系方式。只要輸出空間極小、判斷標準明確補全式請求就是性價比最高的方式。但它的適用邊界也特別清晰一旦輸出空間是開放式的或者輸出結果需要被程序精確消費補全式就開始變得脆弱。模型可能在你要的JSON前后加一句“好的以下是您需要的JSON”也可能突然把鍵名里的下劃線改成駝峰更別說偶爾摻雜的Markdown代碼塊標記了。2.2 格式漂移問題與重試兜底策略我用補全式請求踩過最典型的坑是讓模型輸出一段JSON然后直接用json.loads()去解析。本地測試二十次全都正常一上生產(chǎn)環(huán)境就偶爾出現(xiàn)解析失敗。后來查日志發(fā)現(xiàn)同一個模型在過長的系統(tǒng)提示詞下會產(chǎn)生“格式漂移”有時多了一個尾逗號有時把布爾值寫成了字符串最離譜的一次是把整個JSON放進了Markdown的json代碼塊里。穩(wěn)定性和格式解析的矛盾在補全式上基本無解只能靠兜底策略。我的做法是寫一個“寬容解析器”先用正則去掉可能的代碼塊包裹和首尾噪聲再嘗試標準解析如果失敗就提取最長的大括號對再試一次兩次都失敗才把解析失敗信息和原始輸出拼回消息列表讓模型自己修正一次同時把溫度調(diào)到0。這套策略能把解析成功率從大概80%拉到99%但代價是多耗時而且增加了代碼復雜度。所以我在后面做Agent的時候只要輸出需要被程序反序列化就堅決不用裸補全式。3. 方式二函數(shù)/工具調(diào)用式讓模型輸出可編程的意圖第二種方式是現(xiàn)在Agent開發(fā)里最主流、也最值得你花時間研究的一種函數(shù)調(diào)用式請求。它在技術上的正式叫法是工具調(diào)用核心思路是你事先把可用工具的名稱、描述、參數(shù)Schema告訴模型然后模型在需要時把自己的意圖表達成“我要調(diào)用哪個工具參數(shù)是什么”的結構化數(shù)據(jù)真正執(zhí)行動作的還是你的代碼。3.1 tool_calls的調(diào)用流程與最小示例從請求方的視角看函數(shù)調(diào)用式請求其實分兩步第一步是帶著工具清單發(fā)起請求模型返回一個“工具調(diào)用請求”第二步是你執(zhí)行代碼再把結果作為新的消息傳回去讓模型繼續(xù)推進。這里的重點在于第一次請求的返回實際上并沒有真正把函數(shù)跑出來它只是把“模型決定要做的事”以結構化形式交到你手里。tools [ { type: function, function: { name: query_inventory, description: 查詢指定商品的實時庫存, parameters: { type: object, properties: { sku_id: {type: string, description: 商品的SKU編號} }, required: [sku_id] } } } ] resp client.chat.completions.create( model合適的模型標識, messages[{role: user, content: 幫我查一下SKU編號為A1001的庫存還剩多少}], toolstools, tool_choiceauto ) tool_call resp.choices[0].message.tool_calls[0] print(tool_call.function.name) print(tool_call.function.arguments)這種請求方式之所以能成為主流是因為它把“模型聰明地決定”和“程序可靠地執(zhí)行”完美切開模型的輸出被嚴格限制在“選擇工具 生成參數(shù)”這個動作空間里程序只需要根據(jù)function.name做分派就能精確控制Agent的行為邊界。比起自然語言返回它的輸出可解析性、可校驗性都有了質的提升。3.2 Schema質量極大影響正確率怎么寫才穩(wěn)函數(shù)調(diào)用式的效果好壞很大程度不取決于模型而取決于你寫的工具Schema。很多人以為Schema只是給模型看的一份“使用說明書”隨便寫寫就行實際上它才是決定模型能不能正確選工具的第一要素。我見過太多因為工具描述含糊導致模型反復選錯工具甚至完全拒絕調(diào)用的案例。寫好Schema有幾條我總結出來的實踐經(jīng)驗第一參數(shù)的description必須寫清楚這個參數(shù)的業(yè)務含義和取值范圍而不是只寫字段名比如sku_id的描述最好寫成“商品在ERP系統(tǒng)中的唯一標識通常以大寫字母A開頭后跟四位數(shù)字”這比寫“商品編號”有用得多。第二不要在參數(shù)Schema里塞太多可選的“方便字段”每多一個可選字段模型就需要多做一次決策正確率就會下降一點。第三如果某些參數(shù)之間存在依賴關系盡量在描述里用一句話說清楚比嘗試在Schema層面做嵌套約束要可靠得多。還有一個容易忽略的細節(jié)工具的數(shù)量不要一上來就堆四十個。模型在選擇工具時工具列表越長注意力分散得越厲害尤其當工具之間的功能有重疊時選錯率會顯著上升。我通常會先在代碼層做工具歸類把“查詢類工具也分成庫存、物流、價格”合并成一個“查詢綜合信息根據(jù)參數(shù)路由到子查詢”讓模型只做一次粗粒度選擇。3.3 三個高頻踩坑點并行調(diào)用、重試消息、空響應判空函數(shù)調(diào)用式在實戰(zhàn)中有一個特別容易讓人誤解的能力并行調(diào)用。很多模型支持在一次響應里返回多個tool_calls這本身是好事但它會帶來一個隱蔽問題——并行調(diào)用的多個工具之間如果有依賴關系比如“先查庫存再下訂單”模型并不會幫你保證順序。它只是把所有它覺得該做的事一次性列出來真正的順序和依賴判斷還得你在編排層去做。第二個坑是重試時的消息組裝。如果你對一個函數(shù)調(diào)用結果不滿意想讓模型重新生成很多人會把tool_call原樣塞回消息列表就完事了。但正確的做法是你先要追加一條tool角色消息內(nèi)容是模型上一次調(diào)用的返回結果然后才能發(fā)起下一次請求。如果你漏掉了這條tool消息模型會完全丟失“剛才那次調(diào)用發(fā)生了”的上下文重試出來的結果往往答非所問。第三個坑是空響應判空。雖然函數(shù)調(diào)用式請求一般會返回tool_calls但模型仍然有可能在極端情況下不選擇任何工具直接返回一段自然語言說“抱歉我無法處理”。這時候你的代碼如果沒有對tool_calls為空做兜底直接去索引[0]就會拋異常。我習慣在拿到響應后的第一件事就是判斷如果tool_calls為空且消息內(nèi)容為普通文本就直接把這個文本返回給上層而不是強行讓Agent“繼續(xù)走流程”。4. 方式三結構化輸出約束式給模型輸出上“格式鎖”第三種方式也是目前模型服務端支持度越來越高的一種結構化輸出約束式請求。它的核心是直接在請求時聲明“響應必須滿足某個JSON Schema”模型在生成過程中就會受到嚴格約束不會輸出任何不符合格式的內(nèi)容。它和前面兩種最大的區(qū)別是更嚴格、更接近傳統(tǒng)API協(xié)議幾乎完全犧牲了文本自由度。4.1 用JSON Schema鎖死輸出協(xié)議結構化輸出式的運作方式非常直白你定義一個JSON Schema把它傳給模型服務端然后模型生成的所有token都會在這個Schema的框架內(nèi)進行采樣。比如你想讓模型返回一個包含status和reason字段的JSON對象其中status只能取成功與失敗兩個值reason是字符串你的請求可以寫成這樣resp client.chat.completions.create( model合適的模型標識, messages[{role: user, content: 判斷這句話的情感傾向今天天氣真不錯}], response_format{ type: json_schema, json_schema: { name: sentiment_result, schema: { type: object, properties: { status: {type: string, enum: [成功, 失敗]}, reason: {type: string} }, required: [status, reason] } } } )請求發(fā)出去之后你拿到的響應就一定是合法JSON且一定包含status和reason兩個字段status的值一定會落在預先定義的枚舉里。這意味著什么意味著你的代碼可以徹底扔掉那些“寬容解析”“正則剝殼”“失敗重試”等各種丑陋的防御邏輯直接信任解析結果。我最早把這種方式用在一個Agent和外部系統(tǒng)對接的接口上從那以后基本再沒有因為JSON格式問題半夜爬起來過。從原理上看結構化輸出之所以能做到“絕對合規(guī)”是因為它在采樣階段就做了約束而不是生成后再去校驗修改。相當于你請了一個廚師他炒菜的時候每一勺鹽都不能偏離固定配方成品自然不需要返工。4.2 嚴格模式的好處與代價但結構化輸出也不是銀彈。它最直接的代價是靈活性下降。當你把輸出鎖定在一個Schema里模型就失去了“超綱回答”的能力一旦輸入的內(nèi)容超出了你的Schema設計范圍它只能硬著頭皮把內(nèi)容塞進有限的字段里很多時候塞出來的結果語義是錯的。比如我只定義了status和reason兩個字段用戶卻問了一個跟情感判斷無關的問題模型會在status里寫“失敗”在reason里寫“該問題不在支持范圍內(nèi)”確實合規(guī)但對用戶來說毫無價值。另一個代價是對模型和Schema設計的雙重要求。結構化輸出在很多在線模型上有服務端約束支持的模型數(shù)量有限而且如果你的Schema嵌套層級太深、數(shù)組里套對象、對象里再套數(shù)組部分模型會直接報錯或者生成速度明顯變慢。我在一個實際項目里就遇到過一個五六層嵌套的復雜Schema模型每次生成都要耗時接近普通請求的三倍因為約束條件下的采樣路徑變長且選擇空間變小了。所以我的判斷是結構化輸出最適合的地方是Agent和數(shù)據(jù)層/服務協(xié)議之間的“最后一公里”而不是Agent內(nèi)部所有環(huán)節(jié)的通吃方案。換句話說當你在實現(xiàn)“把模型輸出轉成下游系統(tǒng)能接受的規(guī)范格式”這一步時結構化輸出是無可替代的但在Agent做自由判斷、生成想法的時候強行上Schema約束反而會適得其反。5. 三種方式的選型邏輯與混合使用聊完三種方式各自的原理和坑接下來是這個話題最有價值的部分到底該怎么選以及怎么把它們組合起來用。我在多個Agent項目里一次次調(diào)試、回滾、重構之后基本沉淀出了一套自己的選型標準和混合架構。5.1 一套選型標準與對照表很多人一上來就問“哪個方式最好”這其實是個偽命題它們的目標根本不是同一件事。我從四個維度做了個橫向對照對比維度自然語言補全式函數(shù)調(diào)用式結構化輸出式輸出確定性低可能格式漂移中高意圖可結構化高格式嚴格受控開發(fā)與解析成本低但兜底邏輯復雜中需維護Schema中高Schema設計工作量最大適合的任務類型小范圍分類、情感判斷工具選擇、動作決策固定協(xié)議數(shù)據(jù)交換、下游對接模型兼容性最高較高較低依賴服務端能力Agent內(nèi)部節(jié)點適用性早期原型、低頻判斷核心決策環(huán)節(jié)數(shù)據(jù)出境/入境的守門環(huán)節(jié)我的選型標準很簡單如果這個節(jié)點的輸出只是局部判斷不需要被下游精細化消費用補全式如果這個節(jié)點的輸出將驅動Agent執(zhí)行動作用函數(shù)調(diào)用式如果這個節(jié)點的輸出會寫入外部系統(tǒng)或者參與到嚴格的多方協(xié)議中用結構化輸出式。這個判斷標準基本沒有失手過。5.2 混合請求示例用tool搭建算子用結構化輸出接服務協(xié)議在實際系統(tǒng)里我習慣把這三種方式組合成兩個明顯分層。內(nèi)部Agent的決策循環(huán)全部走函數(shù)調(diào)用式模型選工具、生成參數(shù)、代碼執(zhí)行形成內(nèi)部閉環(huán)。而這個閉環(huán)一旦需要把結果輸出給外部業(yè)務系統(tǒng)就在出口處加一層結構化輸出式請求把內(nèi)部那個“語義化、不規(guī)整”的中間結果重新整理成符合外部接口規(guī)范的JSON。這樣既保住了Agent內(nèi)部決策的靈活性也保住了對外交互的協(xié)議穩(wěn)定性。比如一個模擬的訂單履約Agent它內(nèi)部會通過函數(shù)調(diào)用式去調(diào)用“查詢庫存”“計算運費”“生成訂單號”這些算子每個算子返回的都是一段靈活的JSON或文本。當Agent最終需要“創(chuàng)建正式訂單”并把結果提交到訂單中心時我不會直接把它內(nèi)部的臨時JSON轉過去而是發(fā)一次結構化輸出請求Schema直接按訂單中心的接口規(guī)范來定義模型會把所有內(nèi)部信息整理成一份字段完整、類型正確的正式訂單報文。這一層轉換讓Agent的“雜亂內(nèi)部對話”和“嚴謹外部接口”之間有了一個干凈的防火墻?；旌鲜褂眠€有一個隱藏的好處降本。大模型調(diào)用是按token計費的結構化輸出請求如果每次都帶著復雜的Schema去處理和校驗開銷并不小。所以我在Agent內(nèi)部盡量用補全式做低成本的簡單判斷用函數(shù)調(diào)用式做核心決策只在真正需要嚴格協(xié)議的出口才動用結構化輸出。三種方式各司其職整體成本比“全鏈路都用結構化輸出”低很多穩(wěn)定性也不差。關于這三種方式我最后想說的體會如果把Agent比作一間公司自然語言補全式像“口頭溝通”函數(shù)調(diào)用式像“各部門提交工單”結構化輸出式像“法律合同文本”。三者在不同場合各有不可替代的價值關鍵是你得知道你現(xiàn)在正在處理的是哪種溝通。我自己在不同項目里反復調(diào)整過很多次參數(shù)、Schema和兜底邏輯最后得出的體會是模型的能力當然重要但你對“請求方式”的選擇才是決定Agent系統(tǒng)上限和下限的真正分界線。下限由解析穩(wěn)定性決定上限由決策靈活度決定而兩種特性天然有張力要處理好就只能在這三種請求方式之間做清醒的取舍與組合。最后分享一個非常具體的實操建議在你開始寫Agent編排代碼之前先給項目里每一個需要調(diào)用模型的節(jié)點畫一張小表標明這個節(jié)點的輸入是什么、輸出要給誰消費、允許的輸出空間有多大。然后照著這三種方式做一次分類你會發(fā)現(xiàn)整個系統(tǒng)的架構瞬間清晰了該用哪種方式也基本一目了然。這一步前置思考花的時間后面一定能從調(diào)試和兜底代碼里省回來。