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