智能體優(yōu)化：多輪閉環(huán)中的規(guī)劃與工具使用實(shí)戰(zhàn))
1. 從標(biāo)題拆解AgentFlow到底想解決什么問題第一次看到“AgentFlow流內(nèi)智能體系統(tǒng)優(yōu)化多輪閉環(huán)中的規(guī)劃與工具使用”這個(gè)標(biāo)題我腦子里冒出來的第一個(gè)念頭是終于有人把“智能體不是一次性問答而是一個(gè)持續(xù)流動的過程”這件事擺到臺面上了。過去一年我陸陸續(xù)續(xù)搭過七八個(gè)基于大模型的智能體小系統(tǒng)從最簡單的“查天氣發(fā)郵件”到稍微復(fù)雜點(diǎn)的“多步數(shù)據(jù)分析報(bào)告生成”踩過的坑幾乎都指向同一個(gè)根源——我們把智能體當(dāng)成了函數(shù)調(diào)用但它本質(zhì)上更像是一個(gè)在時(shí)間軸上不斷演化的決策流。AgentFlow這個(gè)標(biāo)題里的關(guān)鍵詞拆開來看有三個(gè)層次值得細(xì)品。第一層是“流內(nèi)”它暗示智能體的規(guī)劃與工具調(diào)用不是割裂的兩個(gè)階段而是嵌入在同一條執(zhí)行流里的。第二層是“多輪閉環(huán)”說明系統(tǒng)會反復(fù)經(jīng)歷“規(guī)劃—執(zhí)行—觀察—再規(guī)劃”的循環(huán)而不是走完一次就結(jié)束。第三層是“規(guī)劃與工具使用”這是智能體最核心的兩個(gè)能力前者決定“下一步做什么”后者決定“怎么把事做成”。把這三層串起來AgentFlow想做的事情就清楚了讓智能體在多輪交互中把規(guī)劃能力和工具調(diào)用能力協(xié)同優(yōu)化而不是各管各的。為什么這件事值得單獨(dú)拿出來做優(yōu)化我舉個(gè)自己踩過的例子。早前我寫過一個(gè)自動整理會議紀(jì)要的智能體流程是“讀取錄音轉(zhuǎn)寫文本→提取待辦事項(xiàng)→調(diào)用日歷API創(chuàng)建提醒”。第一版跑得挺順但遇到一個(gè)情況就崩了轉(zhuǎn)寫文本里提到“下周三之前把方案發(fā)給老張”智能體提取出待辦后直接調(diào)日歷API結(jié)果因?yàn)闆]先查當(dāng)前日期把提醒建到了過去的時(shí)間。問題出在哪出在規(guī)劃和工具使用是脫節(jié)的——規(guī)劃階段沒有把“需要先獲取當(dāng)前時(shí)間”這個(gè)前置條件納入考慮工具調(diào)用階段就盲目執(zhí)行了。AgentFlow要解決的正是這類問題讓規(guī)劃在每一步都感知到工具的能力邊界和前置條件讓工具調(diào)用反過來修正規(guī)劃的粒度。適合讀這篇內(nèi)容的人我大致分三類。一類是正在做智能體應(yīng)用落地的開發(fā)者手里可能已經(jīng)有一個(gè)能跑但不夠穩(wěn)的demo想搞清楚怎么讓它在多輪場景下不崩。另一類是對智能體架構(gòu)感興趣的研究者想理解“流內(nèi)優(yōu)化”和傳統(tǒng)“分階段優(yōu)化”的差異在哪。還有一類是產(chǎn)品經(jīng)理或技術(shù)負(fù)責(zé)人需要判斷這套思路能不能遷移到自己的業(yè)務(wù)場景里。不管你是哪一類接下來的內(nèi)容我會盡量把原理講透、把實(shí)操步驟寫細(xì)同時(shí)把我在類似系統(tǒng)里踩過的坑一并倒出來。2. 智能體系統(tǒng)設(shè)計(jì)的核心思路與方案選型2.1 為什么“流內(nèi)優(yōu)化”比“分階段優(yōu)化”更貼合真實(shí)場景傳統(tǒng)做智能體系統(tǒng)很多人的第一反應(yīng)是分階段先做一個(gè)規(guī)劃模塊再做一個(gè)工具調(diào)用模塊中間用一個(gè)大模型輸出當(dāng)接口。這種架構(gòu)在簡單任務(wù)上沒問題但一旦任務(wù)需要多輪交互問題就暴露了。我把它叫做“接口失憶癥”——規(guī)劃模塊輸出一個(gè)計(jì)劃工具模塊執(zhí)行完把結(jié)果丟回來規(guī)劃模塊再基于結(jié)果重新規(guī)劃但兩次規(guī)劃之間規(guī)劃模塊對工具執(zhí)行過程中產(chǎn)生的中間狀態(tài)幾乎一無所知。AgentFlow的“流內(nèi)優(yōu)化”思路核心是把規(guī)劃、工具調(diào)用、結(jié)果觀察放在同一個(gè)上下文流里持續(xù)更新。打個(gè)比方分階段優(yōu)化像是兩個(gè)人接力跑交接棒的時(shí)候信息會丟失流內(nèi)優(yōu)化像是一個(gè)人邊跑邊調(diào)整呼吸和步伐身體各部分的協(xié)調(diào)是實(shí)時(shí)的。具體到技術(shù)實(shí)現(xiàn)上這意味著智能體的狀態(tài)不是“計(jì)劃列表執(zhí)行結(jié)果”兩個(gè)獨(dú)立變量而是一個(gè)持續(xù)演化的軌跡每一步的規(guī)劃都基于完整的軌跡歷史每一步的工具調(diào)用結(jié)果都會立即反饋到下一步的規(guī)劃中。這種設(shè)計(jì)帶來的直接好處是錯(cuò)誤可追溯且可修正。我實(shí)測過一個(gè)對比同樣一個(gè)“從多個(gè)數(shù)據(jù)源匯總銷售數(shù)據(jù)并生成圖表”的任務(wù)分階段架構(gòu)在第二個(gè)數(shù)據(jù)源返回格式異常時(shí)會繼續(xù)按原計(jì)劃調(diào)用第三個(gè)數(shù)據(jù)源最后生成圖表時(shí)才發(fā)現(xiàn)數(shù)據(jù)對不上而流內(nèi)架構(gòu)在第二個(gè)數(shù)據(jù)源返回異常時(shí)下一步規(guī)劃會立即插入一個(gè)“檢查數(shù)據(jù)格式并嘗試修復(fù)”的子步驟把問題在流內(nèi)消化掉。當(dāng)然流內(nèi)優(yōu)化的代價(jià)是上下文長度增長更快對模型的指令遵循能力要求也更高這是選型時(shí)必須權(quán)衡的。2.2 規(guī)劃與工具使用的耦合點(diǎn)在哪里規(guī)劃與工具使用的耦合不是簡單地在規(guī)劃里寫一句“調(diào)用某某工具”而是要解決三個(gè)層面的對齊問題。第一個(gè)層面是能力對齊規(guī)劃時(shí)要知道當(dāng)前有哪些工具可用、每個(gè)工具的輸入輸出格式是什么、有沒有調(diào)用頻率限制。我見過不少系統(tǒng)把工具描述寫得太粗比如只寫“搜索工具”結(jié)果規(guī)劃模塊讓它去搜一個(gè)需要認(rèn)證的內(nèi)部數(shù)據(jù)庫直接報(bào)錯(cuò)。第二個(gè)層面是時(shí)序?qū)R某些工具調(diào)用有先后依賴比如必須先創(chuàng)建文件夾再寫入文件規(guī)劃時(shí)如果沒把依賴關(guān)系理清執(zhí)行時(shí)就會亂序。第三個(gè)層面是狀態(tài)對齊工具執(zhí)行會改變環(huán)境狀態(tài)規(guī)劃必須基于最新狀態(tài)而不是基于初始狀態(tài)。AgentFlow在這三個(gè)對齊上給出的思路是把工具的描述信息作為規(guī)劃上下文的一部分動態(tài)注入而不是靜態(tài)寫在系統(tǒng)提示里。具體做法是在每一輪規(guī)劃前系統(tǒng)會先做一次“工具狀態(tài)快照”把當(dāng)前可用的工具、它們的健康狀態(tài)、最近一次調(diào)用的結(jié)果摘要一起喂給規(guī)劃模塊。這個(gè)快照機(jī)制聽起來簡單但實(shí)際效果很明顯。我在自己的系統(tǒng)里加了類似機(jī)制后工具調(diào)用失敗率從大概兩成降到了不到一成因?yàn)橐?guī)劃模塊能“看到”某個(gè)工具剛剛失敗過就會主動換一個(gè)備選方案而不是頭鐵繼續(xù)調(diào)。2.3 多輪閉環(huán)的終止條件怎么設(shè)計(jì)才不失控多輪閉環(huán)最怕的是兩件事一是死循環(huán)智能體反復(fù)規(guī)劃同一個(gè)步驟二是過早終止任務(wù)還沒完成就停了。AgentFlow標(biāo)題里強(qiáng)調(diào)“多輪閉環(huán)”說明終止條件的設(shè)計(jì)是核心難點(diǎn)之一。我的經(jīng)驗(yàn)是終止條件不能只靠“任務(wù)完成”這一個(gè)信號而要設(shè)計(jì)一個(gè)多層次的判斷機(jī)制。第一層是顯式完成信號工具調(diào)用返回了明確的成功狀態(tài)且規(guī)劃模塊判斷所有子目標(biāo)都已達(dá)成。第二層是預(yù)算耗盡信號設(shè)定最大輪次或最大token消耗到了就強(qiáng)制終止并輸出當(dāng)前最佳結(jié)果。第三層是停滯檢測信號如果連續(xù)兩輪規(guī)劃產(chǎn)生的動作高度相似且環(huán)境狀態(tài)沒有實(shí)質(zhì)變化就判定為停滯觸發(fā)終止或切換策略。我在一個(gè)自動寫周報(bào)的智能體里用過這套組合之前它偶爾會卡在“再補(bǔ)充一個(gè)數(shù)據(jù)點(diǎn)”的循環(huán)里加了停滯檢測后基本能在合理輪次內(nèi)收斂。注意終止條件里的預(yù)算閾值不要設(shè)得太死。我一開始把最大輪次設(shè)成5結(jié)果復(fù)雜任務(wù)根本跑不完后來改成動態(tài)預(yù)算簡單任務(wù)3輪內(nèi)結(jié)束復(fù)雜任務(wù)允許到15輪整體成功率反而更高。3. 核心細(xì)節(jié)解析與實(shí)操要點(diǎn)3.1 工具描述的結(jié)構(gòu)化寫法工具描述寫得好不好直接決定規(guī)劃模塊能不能用對工具。我見過太多系統(tǒng)把工具描述寫成一句話比如“這個(gè)工具用來查詢數(shù)據(jù)庫”這種描述對規(guī)劃模塊來說信息量幾乎為零。AgentFlow的思路是結(jié)構(gòu)化描述我把它落地成四個(gè)必填字段工具名稱、功能一句話、輸入?yún)?shù)說明、輸出格式說明再加兩個(gè)可選字段前置條件和調(diào)用示例。舉個(gè)例子一個(gè)“創(chuàng)建日歷事件”的工具結(jié)構(gòu)化描述大概是這樣{ name: create_calendar_event, description: 在用戶日歷中創(chuàng)建一個(gè)新的日程事件, input_params: { title: 事件標(biāo)題字符串必填, start_time: 開始時(shí)間ISO 8601格式字符串必填, end_time: 結(jié)束時(shí)間ISO 8601格式字符串必填, attendees: 參與人郵箱列表字符串?dāng)?shù)組可選 }, output_format: 返回創(chuàng)建成功的事件ID和事件鏈接, precondition: 調(diào)用前需確保start_time晚于當(dāng)前時(shí)間, example: create_calendar_event(title周會, start_time2026-03-01T10:00:00, end_time2026-03-01T11:00:00) }這個(gè)描述里precondition字段是關(guān)鍵。前面提到的“把提醒建到過去時(shí)間”的坑就是因?yàn)闆]有這個(gè)字段規(guī)劃模塊不知道要先查當(dāng)前時(shí)間。加上之后規(guī)劃模塊在調(diào)用這個(gè)工具前會自動插入一個(gè)“獲取當(dāng)前時(shí)間”的步驟。實(shí)測下來這類前置條件導(dǎo)致的錯(cuò)誤能減少七成以上。3.2 規(guī)劃粒度的動態(tài)調(diào)整策略規(guī)劃粒度太粗工具調(diào)用容易出錯(cuò)規(guī)劃粒度太細(xì)輪次消耗太快。AgentFlow在多輪閉環(huán)里做的一個(gè)優(yōu)化是讓規(guī)劃粒度根據(jù)任務(wù)復(fù)雜度和歷史執(zhí)行情況動態(tài)調(diào)整。我的實(shí)現(xiàn)方式是給規(guī)劃模塊一個(gè)“粒度提示”這個(gè)提示由三個(gè)因素決定任務(wù)類型、當(dāng)前輪次、最近一次工具調(diào)用的結(jié)果。具體來說任務(wù)類型如果是“信息查詢類”粒度可以粗一點(diǎn)一次規(guī)劃兩三個(gè)步驟如果是“多步操作類”粒度要細(xì)一次規(guī)劃一個(gè)步驟執(zhí)行完看結(jié)果再規(guī)劃下一步。當(dāng)前輪次如果已經(jīng)比較多說明任務(wù)復(fù)雜粒度也要相應(yīng)變細(xì)避免一次性規(guī)劃太多導(dǎo)致后面全錯(cuò)。最近一次工具調(diào)用如果失敗下一步規(guī)劃要更細(xì)把失敗原因排查也納入規(guī)劃。我做過一個(gè)粗略的統(tǒng)計(jì)在同一個(gè)多步數(shù)據(jù)處理任務(wù)上固定粗粒度規(guī)劃的失敗率大概是四成固定細(xì)粒度規(guī)劃的輪次消耗是粗粒度的兩倍多而動態(tài)粒度規(guī)劃在失敗率和輪次消耗上都接近最優(yōu)值。這個(gè)策略的代價(jià)是實(shí)現(xiàn)復(fù)雜度上升需要維護(hù)一個(gè)粒度決策的小邏輯但收益是實(shí)打?qū)嵉摹?.3 上下文流的管理與壓縮流內(nèi)優(yōu)化最大的工程挑戰(zhàn)是上下文越來越長。多輪閉環(huán)跑下來規(guī)劃歷史、工具調(diào)用記錄、觀察結(jié)果全堆在上下文里很快就會超出模型窗口。AgentFlow標(biāo)題里的“流內(nèi)”二字其實(shí)也隱含了對上下文流的管理要求。我的做法是分層管理近期上下文保留完整細(xì)節(jié)比如最近三輪的規(guī)劃和工具調(diào)用結(jié)果中期上下文做摘要壓縮把更早的輪次壓縮成一段簡短的狀態(tài)描述遠(yuǎn)期上下文只保留關(guān)鍵結(jié)論比如已經(jīng)確認(rèn)的事實(shí)和已經(jīng)排除的選項(xiàng)。壓縮的時(shí)機(jī)也很重要。我試過每輪都壓縮結(jié)果模型丟失了太多細(xì)節(jié)規(guī)劃質(zhì)量下降也試過只在快超窗口時(shí)才壓縮結(jié)果壓縮得太倉促關(guān)鍵信息被誤刪。后來改成“輪次閾值窗口閾值”雙觸發(fā)每五輪做一次輕度摘要窗口使用超過七成時(shí)做一次深度壓縮。這個(gè)節(jié)奏下一個(gè)原本只能跑五六輪的任務(wù)現(xiàn)在能穩(wěn)定跑到十五輪以上而且規(guī)劃質(zhì)量沒有明顯下降。提示摘要壓縮時(shí)讓模型輸出結(jié)構(gòu)化的狀態(tài)描述比如“已完成A、B進(jìn)行中C待處理D已知約束E”比讓它輸出一段自由文本更可靠后續(xù)規(guī)劃模塊也更容易解析。4. 實(shí)操過程與核心環(huán)節(jié)實(shí)現(xiàn)4.1 環(huán)境準(zhǔn)備與基礎(chǔ)框架搭建動手實(shí)現(xiàn)一個(gè)AgentFlow風(fēng)格的智能體系統(tǒng)第一步不是寫規(guī)劃邏輯而是把基礎(chǔ)框架搭穩(wěn)。我推薦的最小可行架構(gòu)包含四個(gè)模塊狀態(tài)管理器、規(guī)劃器、工具執(zhí)行器、觀察處理器。狀態(tài)管理器負(fù)責(zé)維護(hù)整個(gè)執(zhí)行流的狀態(tài)包括當(dāng)前輪次、歷史軌跡、上下文摘要規(guī)劃器負(fù)責(zé)基于當(dāng)前狀態(tài)生成下一步動作工具執(zhí)行器負(fù)責(zé)實(shí)際調(diào)用工具并捕獲結(jié)果觀察處理器負(fù)責(zé)把工具結(jié)果轉(zhuǎn)化成規(guī)劃器能理解的觀察信息。用Python搭的話狀態(tài)管理器可以用一個(gè)類來封裝核心字段包括round_count、trajectory、context_summary、available_tools。規(guī)劃器我建議先用一個(gè)獨(dú)立的函數(shù)實(shí)現(xiàn)輸入是狀態(tài)快照輸出是一個(gè)結(jié)構(gòu)化的動作比如{action_type: tool_call, tool_name: xxx, params: {...}}或者{action_type: finish, result: xxx}。工具執(zhí)行器用一個(gè)注冊表模式每個(gè)工具注冊時(shí)帶上前面說的結(jié)構(gòu)化描述。觀察處理器負(fù)責(zé)把工具返回的原始結(jié)果轉(zhuǎn)成自然語言觀察比如把API返回的JSON轉(zhuǎn)成“查詢成功返回了三條記錄第一條是……”。這個(gè)框架搭起來大概兩三百行代碼但它是后續(xù)所有優(yōu)化的基礎(chǔ)。我踩過的一個(gè)坑是一開始圖省事把狀態(tài)直接存在全局變量里結(jié)果多任務(wù)并發(fā)時(shí)狀態(tài)串了。后來改成每個(gè)任務(wù)一個(gè)獨(dú)立的狀態(tài)實(shí)例問題才解決。所以狀態(tài)管理一定要從一開始就做對不然后面改起來很痛苦。4.2 規(guī)劃器的提示詞設(shè)計(jì)與迭代規(guī)劃器的提示詞是整個(gè)系統(tǒng)里最需要反復(fù)打磨的部分。我的提示詞模板大致分四塊角色設(shè)定、當(dāng)前狀態(tài)描述、可用工具列表、輸出格式要求。角色設(shè)定不用太花哨一句話說清楚“你是一個(gè)任務(wù)規(guī)劃器負(fù)責(zé)決定下一步動作”就夠了。當(dāng)前狀態(tài)描述要包含輪次、已完成事項(xiàng)、當(dāng)前觀察、已知約束?？捎霉ぞ吡斜碇苯幼⑷肭懊嬲f的結(jié)構(gòu)化描述。輸出格式要求必須嚴(yán)格我一般要求模型輸出JSON并給出一個(gè)示例。迭代提示詞時(shí)我建議每次只改一個(gè)變量然后跑一組固定測試用例對比。我自己的測試用例集包含十來個(gè)任務(wù)從簡單到復(fù)雜都有每次改完提示詞就跑一遍記錄成功率和平均輪次。有一次我把“輸出格式要求”從“請輸出JSON”改成“請輸出JSON不要包含任何其他文字”成功率直接漲了一成多因?yàn)橹澳Ｐ团紶枙贘SON前后加解釋性文字導(dǎo)致解析失敗。還有一次我在狀態(tài)描述里加了“最近一次工具調(diào)用結(jié)果”的摘要規(guī)劃質(zhì)量明顯提升因?yàn)槟Ｐ湍芨兄缴弦徊降膶?shí)際效果。注意規(guī)劃器的提示詞里不要寫太多“不要做什么”模型對否定指令的遵循能力有限。更好的做法是寫“應(yīng)該做什么”比如與其寫“不要調(diào)用不存在的工具”不如寫“只能從以下工具列表中選擇”。4.3 工具執(zhí)行器的錯(cuò)誤處理與重試工具執(zhí)行器看起來簡單但錯(cuò)誤處理做不好整個(gè)流就會斷。我的經(jīng)驗(yàn)是給每個(gè)工具調(diào)用包三層保護(hù)。第一層是參數(shù)校驗(yàn)在調(diào)用前檢查參數(shù)類型和必填項(xiàng)不合法就直接返回錯(cuò)誤觀察不實(shí)際調(diào)用。第二層是超時(shí)控制每個(gè)工具調(diào)用設(shè)一個(gè)超時(shí)時(shí)間超時(shí)就中斷并返回超時(shí)觀察。第三層是異常捕獲捕獲工具內(nèi)部拋出的異常轉(zhuǎn)成結(jié)構(gòu)化的錯(cuò)誤觀察返回給規(guī)劃器。重試策略也要講究。不是所有錯(cuò)誤都值得重試參數(shù)錯(cuò)誤重試多少次都一樣網(wǎng)絡(luò)超時(shí)重試一次可能就成功。我的做法是給錯(cuò)誤分類retryable和non_retryable。可重試的錯(cuò)誤最多重試兩次每次間隔遞增不可重試的錯(cuò)誤直接返回讓規(guī)劃器決定下一步。這個(gè)分類邏輯我寫在工具注冊信息里每個(gè)工具自己聲明哪些錯(cuò)誤可重試。實(shí)測下來加了這三層保護(hù)后因?yàn)楣ぞ哒{(diào)用失敗導(dǎo)致整個(gè)任務(wù)中斷的情況基本消失了。之前有個(gè)調(diào)用外部API的工具偶爾會因?yàn)榫W(wǎng)絡(luò)抖動超時(shí)沒有超時(shí)控制時(shí)整個(gè)流就卡死加了超時(shí)和重試后大部分抖動都能自動恢復(fù)恢復(fù)不了的也會返回錯(cuò)誤觀察規(guī)劃器會嘗試換一個(gè)數(shù)據(jù)源。4.4 觀察處理器的信息提煉觀察處理器的核心任務(wù)是把工具返回的原始結(jié)果轉(zhuǎn)化成規(guī)劃器容易理解的觀察信息。原始結(jié)果可能是JSON、可能是長文本、可能是二進(jìn)制數(shù)據(jù)直接丟給規(guī)劃器會浪費(fèi)上下文還容易干擾判斷。我的做法是分類型處理結(jié)構(gòu)化數(shù)據(jù)提取關(guān)鍵字段長文本做摘要二進(jìn)制數(shù)據(jù)只返回元信息。舉個(gè)例子一個(gè)搜索工具返回了二十條結(jié)果每條結(jié)果有標(biāo)題、摘要、鏈接。觀察處理器不會把二十條全塞進(jìn)去而是提取前五條的標(biāo)題和摘要加上一句“共返回二十條結(jié)果已展示前五條”。這樣既保留了關(guān)鍵信息又控制了上下文長度。再比如一個(gè)代碼執(zhí)行工具返回了一大段日志觀察處理器會提取日志里的錯(cuò)誤行和最后幾行輸出而不是把整段日志塞進(jìn)去。這個(gè)提煉邏輯我建議用規(guī)則模型結(jié)合的方式。規(guī)則處理結(jié)構(gòu)化數(shù)據(jù)快且穩(wěn)模型處理非結(jié)構(gòu)化文本靈活但慢。我一開始全用模型做摘要結(jié)果每輪觀察處理都要多花一兩秒后來把結(jié)構(gòu)化部分改成規(guī)則處理整體速度提升明顯。5. 常見問題與排查技巧實(shí)錄5.1 規(guī)劃器反復(fù)輸出相同動作怎么辦這是多輪閉環(huán)里最常見的問題之一。表現(xiàn)是規(guī)劃器連續(xù)幾輪輸出幾乎一樣的動作工具執(zhí)行結(jié)果也差不多但任務(wù)就是推進(jìn)不下去。排查思路分三步。第一步看狀態(tài)描述是否更新如果狀態(tài)描述里沒有包含最近一輪的執(zhí)行結(jié)果規(guī)劃器相當(dāng)于在“失憶”狀態(tài)下做決策自然會重復(fù)。第二步看工具結(jié)果是否被正確解析有時(shí)候工具返回了有效結(jié)果但觀察處理器解析失敗返回了空觀察規(guī)劃器以為沒執(zhí)行成功就再試一次。第三步看提示詞是否有歧義某些提示詞會讓模型誤以為需要反復(fù)確認(rèn)比如“確保任務(wù)完成”這種表述模型可能會反復(fù)檢查。解決方法對應(yīng)也有三個(gè)。狀態(tài)描述里強(qiáng)制包含最近一輪的完整觀察觀察處理器加解析失敗的兜底邏輯解析失敗時(shí)返回原始結(jié)果的截?cái)喟姹咎崾驹~里把“確保任務(wù)完成”改成“如果當(dāng)前觀察顯示任務(wù)已完成輸出finish動作”。我遇到過一次特別隱蔽的情況工具返回的成功信息里包含“pending”這個(gè)詞觀察處理器誤判為未完成導(dǎo)致規(guī)劃器反復(fù)重試。后來在觀察處理器里加了一個(gè)狀態(tài)映射表把工具特定的狀態(tài)詞映射成統(tǒng)一語義問題才解決。5.2 工具調(diào)用參數(shù)格式錯(cuò)誤怎么快速定位參數(shù)格式錯(cuò)誤是另一類高頻問題。表現(xiàn)是工具執(zhí)行器返回參數(shù)校驗(yàn)失敗規(guī)劃器收到錯(cuò)誤觀察后重新規(guī)劃但往往還是輸出同樣格式錯(cuò)誤的參數(shù)。排查時(shí)我一般先看規(guī)劃器輸出的原始動作確認(rèn)參數(shù)錯(cuò)在哪。常見錯(cuò)誤有三類類型錯(cuò)誤比如該傳數(shù)組的傳了字符串格式錯(cuò)誤比如時(shí)間格式不對缺失必填項(xiàng)。定位到具體錯(cuò)誤后解決方法是在規(guī)劃器提示詞里強(qiáng)化參數(shù)格式說明。我習(xí)慣在工具描述里給每個(gè)參數(shù)加一個(gè)“示例值”模型看到示例后輸出正確格式的概率明顯提高。另外參數(shù)校驗(yàn)失敗時(shí)返回的錯(cuò)誤觀察要具體不要只說“參數(shù)錯(cuò)誤”要說“參數(shù)start_time格式錯(cuò)誤期望ISO 8601格式實(shí)際收到‘明天上午’”。具體的錯(cuò)誤信息能幫助規(guī)劃器在下一輪修正。下面這張表是我整理的高頻問題速查表覆蓋了大部分常見情況問題現(xiàn)象可能原因排查動作解決方向規(guī)劃器反復(fù)輸出相同動作狀態(tài)未更新或觀察解析失敗檢查狀態(tài)描述和觀察處理器強(qiáng)制更新狀態(tài)加解析兜底工具參數(shù)格式錯(cuò)誤提示詞參數(shù)說明不清查看規(guī)劃器原始輸出補(bǔ)充參數(shù)示例值任務(wù)過早終止完成判斷過于寬松檢查終止條件邏輯增加子目標(biāo)校驗(yàn)上下文超限壓縮策略不當(dāng)查看上下文增長曲線調(diào)整壓縮觸發(fā)閾值工具調(diào)用超時(shí)無超時(shí)控制或超時(shí)太短檢查工具執(zhí)行器配置加超時(shí)和重試機(jī)制規(guī)劃粒度不合適固定粒度不適應(yīng)任務(wù)統(tǒng)計(jì)輪次和失敗率改為動態(tài)粒度策略5.3 多輪閉環(huán)的輪次消耗過大怎么優(yōu)化輪次消耗過大通常有兩個(gè)原因規(guī)劃粒度太細(xì)或者存在無效輪次。優(yōu)化前先做一輪統(tǒng)計(jì)記錄每個(gè)任務(wù)的輪次分布和每輪的動作類型。如果發(fā)現(xiàn)大量輪次花在“確認(rèn)類”動作上比如反復(fù)查詢同一個(gè)信息說明規(guī)劃器缺乏記憶需要加強(qiáng)狀態(tài)描述。如果發(fā)現(xiàn)輪次花在“試錯(cuò)類”動作上比如反復(fù)嘗試不同參數(shù)說明工具描述不夠清晰需要補(bǔ)充示例和前置條件。我的優(yōu)化順序是先優(yōu)化工具描述再優(yōu)化狀態(tài)描述最后調(diào)整規(guī)劃粒度。工具描述優(yōu)化見效最快因?yàn)楹芏嘣囧e(cuò)輪次是因?yàn)槟Ｐ筒恢拦ぞ咴趺从?。狀態(tài)描述優(yōu)化次之能減少確認(rèn)類輪次。規(guī)劃粒度調(diào)整放在最后因?yàn)樗绊懨孀畲笳{(diào)不好容易引入新問題。經(jīng)過這三輪優(yōu)化我一個(gè)原本平均十二輪的任務(wù)降到了平均六輪左右而且成功率還有提升。提示優(yōu)化輪次時(shí)不要只看平均值要看分布。有些任務(wù)天生就需要多輪強(qiáng)行壓縮輪次可能導(dǎo)致成功率下降。我一般會設(shè)定一個(gè)目標(biāo)區(qū)間比如“簡單任務(wù)三到五輪復(fù)雜任務(wù)八到十二輪”在這個(gè)區(qū)間內(nèi)就算合理。5.4 工具執(zhí)行結(jié)果與規(guī)劃預(yù)期不符怎么處理這種情況在多輪閉環(huán)里很常見工具執(zhí)行成功了但返回的結(jié)果和規(guī)劃器預(yù)期的不一樣。比如規(guī)劃器以為搜索工具會返回十條結(jié)果實(shí)際只返回了三條。處理這類問題的關(guān)鍵是讓規(guī)劃器具備“預(yù)期管理”能力。我的做法是在規(guī)劃動作里加一個(gè)可選的expected_outcome字段規(guī)劃器在決定調(diào)用工具時(shí)順便描述一下它期望的結(jié)果。工具執(zhí)行后觀察處理器對比實(shí)際結(jié)果和預(yù)期結(jié)果如果不符在觀察信息里明確標(biāo)注“實(shí)際結(jié)果與預(yù)期不符預(yù)期是……實(shí)際是……”。這個(gè)機(jī)制的好處是規(guī)劃器在下一輪能立即感知到偏差并決定是調(diào)整預(yù)期還是換工具。我實(shí)測過一個(gè)場景規(guī)劃器調(diào)用一個(gè)數(shù)據(jù)查詢工具預(yù)期返回最近七天的數(shù)據(jù)實(shí)際只返回了三天因?yàn)閿?shù)據(jù)源只保留三天。有了預(yù)期對比后規(guī)劃器下一輪自動調(diào)整了分析范圍而不是繼續(xù)按七天做分析導(dǎo)致后面全錯(cuò)。這個(gè)字段是可選不強(qiáng)制規(guī)劃器每次都填但填了之后對流的穩(wěn)定性幫助很大。6. 影響范圍與遷移場景分析6.1 這套思路適合哪些類型的智能體AgentFlow這套流內(nèi)優(yōu)化的思路最適合的是多步操作類和長周期交互類的智能體。多步操作類比如自動數(shù)據(jù)處理、自動報(bào)告生成、自動代碼修復(fù)這些任務(wù)的特點(diǎn)是步驟之間有依賴前一步的結(jié)果影響后一步的決策流內(nèi)優(yōu)化能讓依賴關(guān)系在流內(nèi)自然傳遞。長周期交互類比如客服對話、教學(xué)輔導(dǎo)這些任務(wù)的特點(diǎn)是交互輪次多用戶意圖可能在過程中變化流內(nèi)優(yōu)化能讓智能體持續(xù)跟蹤意圖變化。相對而言單步查詢類的智能體用這套思路收益不大。比如一個(gè)簡單的“查天氣”智能體一次工具調(diào)用就結(jié)束了流內(nèi)優(yōu)化帶來的復(fù)雜度增加不劃算。高實(shí)時(shí)性要求的場景也要謹(jǐn)慎流內(nèi)優(yōu)化因?yàn)槊枯喍家鲆?guī)劃延遲比固定流程高如果業(yè)務(wù)要求毫秒級響應(yīng)可能不適合。我的判斷標(biāo)準(zhǔn)是如果任務(wù)的平均步驟數(shù)超過三步或者需要根據(jù)中間結(jié)果動態(tài)調(diào)整后續(xù)步驟就值得用流內(nèi)優(yōu)化。6.2 從單智能體到多智能體協(xié)作的擴(kuò)展流內(nèi)優(yōu)化的思路可以自然擴(kuò)展到多智能體協(xié)作。單智能體時(shí)流內(nèi)是“規(guī)劃—執(zhí)行—觀察”的循環(huán)多智能體時(shí)流內(nèi)可以變成“規(guī)劃—分派—執(zhí)行—匯總—再規(guī)劃”的循環(huán)。每個(gè)子智能體負(fù)責(zé)一個(gè)子任務(wù)主規(guī)劃器負(fù)責(zé)協(xié)調(diào)。擴(kuò)展時(shí)要注意的是子智能體的工具描述要匯總到主規(guī)劃器讓主規(guī)劃器知道每個(gè)子智能體的能力邊界。另外子智能體之間的狀態(tài)同步要設(shè)計(jì)好避免出現(xiàn)一個(gè)子智能體改了狀態(tài)另一個(gè)不知道的情況。我試過一個(gè)簡單的多智能體版本一個(gè)主規(guī)劃器加兩個(gè)子智能體一個(gè)負(fù)責(zé)數(shù)據(jù)查詢一個(gè)負(fù)責(zé)數(shù)據(jù)可視化。主規(guī)劃器把任務(wù)拆成“查詢數(shù)據(jù)”和“生成圖表”兩個(gè)子任務(wù)分派給對應(yīng)子智能體子智能體執(zhí)行完把結(jié)果返回主規(guī)劃器主規(guī)劃器再決定下一步。這個(gè)版本比單智能體版本在復(fù)雜任務(wù)上的成功率高一些但輪次消耗也更多因?yàn)槎嗔艘粚臃峙珊蛥R總。所以多智能體不是銀彈任務(wù)復(fù)雜度不夠時(shí)反而拖慢速度。6.3 工程落地時(shí)的性能與成本權(quán)衡流內(nèi)優(yōu)化在工程落地時(shí)最大的權(quán)衡是性能和成本。每輪規(guī)劃都要調(diào)用一次大模型輪次越多token消耗越大。我的經(jīng)驗(yàn)是在規(guī)劃器上可以用相對小一點(diǎn)的模型因?yàn)橐?guī)劃任務(wù)的復(fù)雜度通常低于生成任務(wù)在觀察處理器上能用規(guī)則就用規(guī)則規(guī)則處理不了的再用模型。這樣搭配下來整體成本能控制在一個(gè)可接受的范圍內(nèi)。另一個(gè)權(quán)衡是延遲。流內(nèi)優(yōu)化的延遲主要來自模型調(diào)用每輪規(guī)劃加觀察處理大概需要一到三秒。如果業(yè)務(wù)能接受這個(gè)延遲就沒問題如果不能可以考慮把規(guī)劃器做成流式輸出邊生成邊解析提前開始工具調(diào)用。我試過流式解析能把首輪延遲降低大概三成但實(shí)現(xiàn)復(fù)雜度上升不少需要處理部分解析和回滾的情況。注意成本優(yōu)化時(shí)不要犧牲可觀測性。我見過為了省token把中間狀態(tài)全刪了的做法結(jié)果出問題時(shí)完全沒法排查。我的做法是中間狀態(tài)照常記錄但只在調(diào)試模式下注入到規(guī)劃上下文生產(chǎn)模式下只注入摘要這樣既省了token又保留了排查能力。7. 我在這類系統(tǒng)上踩過的幾個(gè)真實(shí)坑第一個(gè)坑是過度依賴模型的自我修正能力。我一開始覺得只要把錯(cuò)誤信息返回給規(guī)劃器模型自己會修正。實(shí)際跑下來發(fā)現(xiàn)模型對某些類型的錯(cuò)誤確實(shí)能修正比如參數(shù)格式錯(cuò)誤但對另一些錯(cuò)誤比如邏輯錯(cuò)誤模型往往會沿著錯(cuò)誤方向繼續(xù)走。后來我在規(guī)劃器里加了一個(gè)“錯(cuò)誤分類”邏輯邏輯錯(cuò)誤直接觸發(fā)重新規(guī)劃而不是讓模型自己修。第二個(gè)坑是工具描述更新后沒有同步到規(guī)劃器。有一次我給一個(gè)工具加了新的必填參數(shù)但忘了更新規(guī)劃器里的工具描述結(jié)果規(guī)劃器還是按舊格式調(diào)用連續(xù)失敗了好幾輪。后來我改成工具描述和工具實(shí)現(xiàn)放在同一個(gè)注冊項(xiàng)里更新時(shí)一起更新避免不同步。第三個(gè)坑是終止條件過于依賴單一信號。早期我只用“任務(wù)完成”作為終止條件結(jié)果遇到模型誤判完成的情況任務(wù)沒做完就停了。后來加了預(yù)算耗盡和停滯檢測兩個(gè)信號三個(gè)信號任一觸發(fā)就終止穩(wěn)定性好了很多。第四個(gè)坑是上下文壓縮時(shí)把關(guān)鍵約束壓沒了。有一次壓縮后規(guī)劃器忘了“輸出必須是中文”這個(gè)約束生成了英文結(jié)果。后來我在壓縮邏輯里加了一個(gè)“關(guān)鍵約束保留”規(guī)則把用戶明確提出的約束單獨(dú)存一份不參與壓縮。這些坑說起來都不復(fù)雜但每一個(gè)都是實(shí)際跑起來才會遇到的。寫這類系統(tǒng)理論上的優(yōu)雅和工程上的穩(wěn)健往往是兩回事多跑、多記錄、多復(fù)盤比一開始就追求完美架構(gòu)更重要。 AgentFlow流內(nèi)智能體優(yōu)化：多輪閉環(huán)中的規(guī)劃與工具使用實(shí)戰(zhàn)
1. 從標(biāo)題拆解AgentFlow到底想解決什么問題第一次看到“AgentFlow流內(nèi)智能體系統(tǒng)優(yōu)化多輪閉環(huán)中的規(guī)劃與工具使用”這個(gè)標(biāo)題我腦子里冒出來的第一個(gè)念頭是終于有人把“智能體不是一次性問答而是一個(gè)持續(xù)流動的過程”這件事擺到臺面上了。過去一年我陸陸續(xù)續(xù)搭過七八個(gè)基于大模型的智能體小系統(tǒng)從最簡單的“查天氣發(fā)郵件”到稍微復(fù)雜點(diǎn)的“多步數(shù)據(jù)分析報(bào)告生成”踩過的坑幾乎都指向同一個(gè)根源——我們把智能體當(dāng)成了函數(shù)調(diào)用但它本質(zhì)上更像是一個(gè)在時(shí)間軸上不斷演化的決策流。AgentFlow這個(gè)標(biāo)題里的關(guān)鍵詞拆開來看有三個(gè)層次值得細(xì)品。第一層是“流內(nèi)”它暗示智能體的規(guī)劃與工具調(diào)用不是割裂的兩個(gè)階段而是嵌入在同一條執(zhí)行流里的。第二層是“多輪閉環(huán)”說明系統(tǒng)會反復(fù)經(jīng)歷“規(guī)劃—執(zhí)行—觀察—再規(guī)劃”的循環(huán)而不是走完一次就結(jié)束。第三層是“規(guī)劃與工具使用”這是智能體最核心的兩個(gè)能力前者決定“下一步做什么”后者決定“怎么把事做成”。把這三層串起來AgentFlow想做的事情就清楚了讓智能體在多輪交互中把規(guī)劃能力和工具調(diào)用能力協(xié)同優(yōu)化而不是各管各的。為什么這件事值得單獨(dú)拿出來做優(yōu)化我舉個(gè)自己踩過的例子。早前我寫過一個(gè)自動整理會議紀(jì)要的智能體流程是“讀取錄音轉(zhuǎn)寫文本→提取待辦事項(xiàng)→調(diào)用日歷API創(chuàng)建提醒”。第一版跑得挺順但遇到一個(gè)情況就崩了轉(zhuǎn)寫文本里提到“下周三之前把方案發(fā)給老張”智能體提取出待辦后直接調(diào)日歷API結(jié)果因?yàn)闆]先查當(dāng)前日期把提醒建到了過去的時(shí)間。問題出在哪出在規(guī)劃和工具使用是脫節(jié)的——規(guī)劃階段沒有把“需要先獲取當(dāng)前時(shí)間”這個(gè)前置條件納入考慮工具調(diào)用階段就盲目執(zhí)行了。AgentFlow要解決的正是這類問題讓規(guī)劃在每一步都感知到工具的能力邊界和前置條件讓工具調(diào)用反過來修正規(guī)劃的粒度。適合讀這篇內(nèi)容的人我大致分三類。一類是正在做智能體應(yīng)用落地的開發(fā)者手里可能已經(jīng)有一個(gè)能跑但不夠穩(wěn)的demo想搞清楚怎么讓它在多輪場景下不崩。另一類是對智能體架構(gòu)感興趣的研究者想理解“流內(nèi)優(yōu)化”和傳統(tǒng)“分階段優(yōu)化”的差異在哪。還有一類是產(chǎn)品經(jīng)理或技術(shù)負(fù)責(zé)人需要判斷這套思路能不能遷移到自己的業(yè)務(wù)場景里。不管你是哪一類接下來的內(nèi)容我會盡量把原理講透、把實(shí)操步驟寫細(xì)同時(shí)把我在類似系統(tǒng)里踩過的坑一并倒出來。2. 智能體系統(tǒng)設(shè)計(jì)的核心思路與方案選型2.1 為什么“流內(nèi)優(yōu)化”比“分階段優(yōu)化”更貼合真實(shí)場景傳統(tǒng)做智能體系統(tǒng)很多人的第一反應(yīng)是分階段先做一個(gè)規(guī)劃模塊再做一個(gè)工具調(diào)用模塊中間用一個(gè)大模型輸出當(dāng)接口。這種架構(gòu)在簡單任務(wù)上沒問題但一旦任務(wù)需要多輪交互問題就暴露了。我把它叫做“接口失憶癥”——規(guī)劃模塊輸出一個(gè)計(jì)劃工具模塊執(zhí)行完把結(jié)果丟回來規(guī)劃模塊再基于結(jié)果重新規(guī)劃但兩次規(guī)劃之間規(guī)劃模塊對工具執(zhí)行過程中產(chǎn)生的中間狀態(tài)幾乎一無所知。AgentFlow的“流內(nèi)優(yōu)化”思路核心是把規(guī)劃、工具調(diào)用、結(jié)果觀察放在同一個(gè)上下文流里持續(xù)更新。打個(gè)比方分階段優(yōu)化像是兩個(gè)人接力跑交接棒的時(shí)候信息會丟失流內(nèi)優(yōu)化像是一個(gè)人邊跑邊調(diào)整呼吸和步伐身體各部分的協(xié)調(diào)是實(shí)時(shí)的。具體到技術(shù)實(shí)現(xiàn)上這意味著智能體的狀態(tài)不是“計(jì)劃列表執(zhí)行結(jié)果”兩個(gè)獨(dú)立變量而是一個(gè)持續(xù)演化的軌跡每一步的規(guī)劃都基于完整的軌跡歷史每一步的工具調(diào)用結(jié)果都會立即反饋到下一步的規(guī)劃中。這種設(shè)計(jì)帶來的直接好處是錯(cuò)誤可追溯且可修正。我實(shí)測過一個(gè)對比同樣一個(gè)“從多個(gè)數(shù)據(jù)源匯總銷售數(shù)據(jù)并生成圖表”的任務(wù)分階段架構(gòu)在第二個(gè)數(shù)據(jù)源返回格式異常時(shí)會繼續(xù)按原計(jì)劃調(diào)用第三個(gè)數(shù)據(jù)源最后生成圖表時(shí)才發(fā)現(xiàn)數(shù)據(jù)對不上而流內(nèi)架構(gòu)在第二個(gè)數(shù)據(jù)源返回異常時(shí)下一步規(guī)劃會立即插入一個(gè)“檢查數(shù)據(jù)格式并嘗試修復(fù)”的子步驟把問題在流內(nèi)消化掉。當(dāng)然流內(nèi)優(yōu)化的代價(jià)是上下文長度增長更快對模型的指令遵循能力要求也更高這是選型時(shí)必須權(quán)衡的。2.2 規(guī)劃與工具使用的耦合點(diǎn)在哪里規(guī)劃與工具使用的耦合不是簡單地在規(guī)劃里寫一句“調(diào)用某某工具”而是要解決三個(gè)層面的對齊問題。第一個(gè)層面是能力對齊規(guī)劃時(shí)要知道當(dāng)前有哪些工具可用、每個(gè)工具的輸入輸出格式是什么、有沒有調(diào)用頻率限制。我見過不少系統(tǒng)把工具描述寫得太粗比如只寫“搜索工具”結(jié)果規(guī)劃模塊讓它去搜一個(gè)需要認(rèn)證的內(nèi)部數(shù)據(jù)庫直接報(bào)錯(cuò)。第二個(gè)層面是時(shí)序?qū)R某些工具調(diào)用有先后依賴比如必須先創(chuàng)建文件夾再寫入文件規(guī)劃時(shí)如果沒把依賴關(guān)系理清執(zhí)行時(shí)就會亂序。第三個(gè)層面是狀態(tài)對齊工具執(zhí)行會改變環(huán)境狀態(tài)規(guī)劃必須基于最新狀態(tài)而不是基于初始狀態(tài)。AgentFlow在這三個(gè)對齊上給出的思路是把工具的描述信息作為規(guī)劃上下文的一部分動態(tài)注入而不是靜態(tài)寫在系統(tǒng)提示里。具體做法是在每一輪規(guī)劃前系統(tǒng)會先做一次“工具狀態(tài)快照”把當(dāng)前可用的工具、它們的健康狀態(tài)、最近一次調(diào)用的結(jié)果摘要一起喂給規(guī)劃模塊。這個(gè)快照機(jī)制聽起來簡單但實(shí)際效果很明顯。我在自己的系統(tǒng)里加了類似機(jī)制后工具調(diào)用失敗率從大概兩成降到了不到一成因?yàn)橐?guī)劃模塊能“看到”某個(gè)工具剛剛失敗過就會主動換一個(gè)備選方案而不是頭鐵繼續(xù)調(diào)。2.3 多輪閉環(huán)的終止條件怎么設(shè)計(jì)才不失控多輪閉環(huán)最怕的是兩件事一是死循環(huán)智能體反復(fù)規(guī)劃同一個(gè)步驟二是過早終止任務(wù)還沒完成就停了。AgentFlow標(biāo)題里強(qiáng)調(diào)“多輪閉環(huán)”說明終止條件的設(shè)計(jì)是核心難點(diǎn)之一。我的經(jīng)驗(yàn)是終止條件不能只靠“任務(wù)完成”這一個(gè)信號而要設(shè)計(jì)一個(gè)多層次的判斷機(jī)制。第一層是顯式完成信號工具調(diào)用返回了明確的成功狀態(tài)且規(guī)劃模塊判斷所有子目標(biāo)都已達(dá)成。第二層是預(yù)算耗盡信號設(shè)定最大輪次或最大token消耗到了就強(qiáng)制終止并輸出當(dāng)前最佳結(jié)果。第三層是停滯檢測信號如果連續(xù)兩輪規(guī)劃產(chǎn)生的動作高度相似且環(huán)境狀態(tài)沒有實(shí)質(zhì)變化就判定為停滯觸發(fā)終止或切換策略。我在一個(gè)自動寫周報(bào)的智能體里用過這套組合之前它偶爾會卡在“再補(bǔ)充一個(gè)數(shù)據(jù)點(diǎn)”的循環(huán)里加了停滯檢測后基本能在合理輪次內(nèi)收斂。注意終止條件里的預(yù)算閾值不要設(shè)得太死。我一開始把最大輪次設(shè)成5結(jié)果復(fù)雜任務(wù)根本跑不完后來改成動態(tài)預(yù)算簡單任務(wù)3輪內(nèi)結(jié)束復(fù)雜任務(wù)允許到15輪整體成功率反而更高。3. 核心細(xì)節(jié)解析與實(shí)操要點(diǎn)3.1 工具描述的結(jié)構(gòu)化寫法工具描述寫得好不好直接決定規(guī)劃模塊能不能用對工具。我見過太多系統(tǒng)把工具描述寫成一句話比如“這個(gè)工具用來查詢數(shù)據(jù)庫”這種描述對規(guī)劃模塊來說信息量幾乎為零。AgentFlow的思路是結(jié)構(gòu)化描述我把它落地成四個(gè)必填字段工具名稱、功能一句話、輸入?yún)?shù)說明、輸出格式說明再加兩個(gè)可選字段前置條件和調(diào)用示例。舉個(gè)例子一個(gè)“創(chuàng)建日歷事件”的工具結(jié)構(gòu)化描述大概是這樣{ name: create_calendar_event, description: 在用戶日歷中創(chuàng)建一個(gè)新的日程事件, input_params: { title: 事件標(biāo)題字符串必填, start_time: 開始時(shí)間ISO 8601格式字符串必填, end_time: 結(jié)束時(shí)間ISO 8601格式字符串必填, attendees: 參與人郵箱列表字符串?dāng)?shù)組可選 }, output_format: 返回創(chuàng)建成功的事件ID和事件鏈接, precondition: 調(diào)用前需確保start_time晚于當(dāng)前時(shí)間, example: create_calendar_event(title周會, start_time2026-03-01T10:00:00, end_time2026-03-01T11:00:00) }這個(gè)描述里precondition字段是關(guān)鍵。前面提到的“把提醒建到過去時(shí)間”的坑就是因?yàn)闆]有這個(gè)字段規(guī)劃模塊不知道要先查當(dāng)前時(shí)間。加上之后規(guī)劃模塊在調(diào)用這個(gè)工具前會自動插入一個(gè)“獲取當(dāng)前時(shí)間”的步驟。實(shí)測下來這類前置條件導(dǎo)致的錯(cuò)誤能減少七成以上。3.2 規(guī)劃粒度的動態(tài)調(diào)整策略規(guī)劃粒度太粗工具調(diào)用容易出錯(cuò)規(guī)劃粒度太細(xì)輪次消耗太快。AgentFlow在多輪閉環(huán)里做的一個(gè)優(yōu)化是讓規(guī)劃粒度根據(jù)任務(wù)復(fù)雜度和歷史執(zhí)行情況動態(tài)調(diào)整。我的實(shí)現(xiàn)方式是給規(guī)劃模塊一個(gè)“粒度提示”這個(gè)提示由三個(gè)因素決定任務(wù)類型、當(dāng)前輪次、最近一次工具調(diào)用的結(jié)果。具體來說任務(wù)類型如果是“信息查詢類”粒度可以粗一點(diǎn)一次規(guī)劃兩三個(gè)步驟如果是“多步操作類”粒度要細(xì)一次規(guī)劃一個(gè)步驟執(zhí)行完看結(jié)果再規(guī)劃下一步。當(dāng)前輪次如果已經(jīng)比較多說明任務(wù)復(fù)雜粒度也要相應(yīng)變細(xì)避免一次性規(guī)劃太多導(dǎo)致后面全錯(cuò)。最近一次工具調(diào)用如果失敗下一步規(guī)劃要更細(xì)把失敗原因排查也納入規(guī)劃。我做過一個(gè)粗略的統(tǒng)計(jì)在同一個(gè)多步數(shù)據(jù)處理任務(wù)上固定粗粒度規(guī)劃的失敗率大概是四成固定細(xì)粒度規(guī)劃的輪次消耗是粗粒度的兩倍多而動態(tài)粒度規(guī)劃在失敗率和輪次消耗上都接近最優(yōu)值。這個(gè)策略的代價(jià)是實(shí)現(xiàn)復(fù)雜度上升需要維護(hù)一個(gè)粒度決策的小邏輯但收益是實(shí)打?qū)嵉摹?.3 上下文流的管理與壓縮流內(nèi)優(yōu)化最大的工程挑戰(zhàn)是上下文越來越長。多輪閉環(huán)跑下來規(guī)劃歷史、工具調(diào)用記錄、觀察結(jié)果全堆在上下文里很快就會超出模型窗口。AgentFlow標(biāo)題里的“流內(nèi)”二字其實(shí)也隱含了對上下文流的管理要求。我的做法是分層管理近期上下文保留完整細(xì)節(jié)比如最近三輪的規(guī)劃和工具調(diào)用結(jié)果中期上下文做摘要壓縮把更早的輪次壓縮成一段簡短的狀態(tài)描述遠(yuǎn)期上下文只保留關(guān)鍵結(jié)論比如已經(jīng)確認(rèn)的事實(shí)和已經(jīng)排除的選項(xiàng)。壓縮的時(shí)機(jī)也很重要。我試過每輪都壓縮結(jié)果模型丟失了太多細(xì)節(jié)規(guī)劃質(zhì)量下降也試過只在快超窗口時(shí)才壓縮結(jié)果壓縮得太倉促關(guān)鍵信息被誤刪。后來改成“輪次閾值窗口閾值”雙觸發(fā)每五輪做一次輕度摘要窗口使用超過七成時(shí)做一次深度壓縮。這個(gè)節(jié)奏下一個(gè)原本只能跑五六輪的任務(wù)現(xiàn)在能穩(wěn)定跑到十五輪以上而且規(guī)劃質(zhì)量沒有明顯下降。提示摘要壓縮時(shí)讓模型輸出結(jié)構(gòu)化的狀態(tài)描述比如“已完成A、B進(jìn)行中C待處理D已知約束E”比讓它輸出一段自由文本更可靠后續(xù)規(guī)劃模塊也更容易解析。4. 實(shí)操過程與核心環(huán)節(jié)實(shí)現(xiàn)4.1 環(huán)境準(zhǔn)備與基礎(chǔ)框架搭建動手實(shí)現(xiàn)一個(gè)AgentFlow風(fēng)格的智能體系統(tǒng)第一步不是寫規(guī)劃邏輯而是把基礎(chǔ)框架搭穩(wěn)。我推薦的最小可行架構(gòu)包含四個(gè)模塊狀態(tài)管理器、規(guī)劃器、工具執(zhí)行器、觀察處理器。狀態(tài)管理器負(fù)責(zé)維護(hù)整個(gè)執(zhí)行流的狀態(tài)包括當(dāng)前輪次、歷史軌跡、上下文摘要規(guī)劃器負(fù)責(zé)基于當(dāng)前狀態(tài)生成下一步動作工具執(zhí)行器負(fù)責(zé)實(shí)際調(diào)用工具并捕獲結(jié)果觀察處理器負(fù)責(zé)把工具結(jié)果轉(zhuǎn)化成規(guī)劃器能理解的觀察信息。用Python搭的話狀態(tài)管理器可以用一個(gè)類來封裝核心字段包括round_count、trajectory、context_summary、available_tools。規(guī)劃器我建議先用一個(gè)獨(dú)立的函數(shù)實(shí)現(xiàn)輸入是狀態(tài)快照輸出是一個(gè)結(jié)構(gòu)化的動作比如{action_type: tool_call, tool_name: xxx, params: {...}}或者{action_type: finish, result: xxx}。工具執(zhí)行器用一個(gè)注冊表模式每個(gè)工具注冊時(shí)帶上前面說的結(jié)構(gòu)化描述。觀察處理器負(fù)責(zé)把工具返回的原始結(jié)果轉(zhuǎn)成自然語言觀察比如把API返回的JSON轉(zhuǎn)成“查詢成功返回了三條記錄第一條是……”。這個(gè)框架搭起來大概兩三百行代碼但它是后續(xù)所有優(yōu)化的基礎(chǔ)。我踩過的一個(gè)坑是一開始圖省事把狀態(tài)直接存在全局變量里結(jié)果多任務(wù)并發(fā)時(shí)狀態(tài)串了。后來改成每個(gè)任務(wù)一個(gè)獨(dú)立的狀態(tài)實(shí)例問題才解決。所以狀態(tài)管理一定要從一開始就做對不然后面改起來很痛苦。4.2 規(guī)劃器的提示詞設(shè)計(jì)與迭代規(guī)劃器的提示詞是整個(gè)系統(tǒng)里最需要反復(fù)打磨的部分。我的提示詞模板大致分四塊角色設(shè)定、當(dāng)前狀態(tài)描述、可用工具列表、輸出格式要求。角色設(shè)定不用太花哨一句話說清楚“你是一個(gè)任務(wù)規(guī)劃器負(fù)責(zé)決定下一步動作”就夠了。當(dāng)前狀態(tài)描述要包含輪次、已完成事項(xiàng)、當(dāng)前觀察、已知約束?？捎霉ぞ吡斜碇苯幼⑷肭懊嬲f的結(jié)構(gòu)化描述。輸出格式要求必須嚴(yán)格我一般要求模型輸出JSON并給出一個(gè)示例。迭代提示詞時(shí)我建議每次只改一個(gè)變量然后跑一組固定測試用例對比。我自己的測試用例集包含十來個(gè)任務(wù)從簡單到復(fù)雜都有每次改完提示詞就跑一遍記錄成功率和平均輪次。有一次我把“輸出格式要求”從“請輸出JSON”改成“請輸出JSON不要包含任何其他文字”成功率直接漲了一成多因?yàn)橹澳Ｐ团紶枙贘SON前后加解釋性文字導(dǎo)致解析失敗。還有一次我在狀態(tài)描述里加了“最近一次工具調(diào)用結(jié)果”的摘要規(guī)劃質(zhì)量明顯提升因?yàn)槟Ｐ湍芨兄缴弦徊降膶?shí)際效果。注意規(guī)劃器的提示詞里不要寫太多“不要做什么”模型對否定指令的遵循能力有限。更好的做法是寫“應(yīng)該做什么”比如與其寫“不要調(diào)用不存在的工具”不如寫“只能從以下工具列表中選擇”。4.3 工具執(zhí)行器的錯(cuò)誤處理與重試工具執(zhí)行器看起來簡單但錯(cuò)誤處理做不好整個(gè)流就會斷。我的經(jīng)驗(yàn)是給每個(gè)工具調(diào)用包三層保護(hù)。第一層是參數(shù)校驗(yàn)在調(diào)用前檢查參數(shù)類型和必填項(xiàng)不合法就直接返回錯(cuò)誤觀察不實(shí)際調(diào)用。第二層是超時(shí)控制每個(gè)工具調(diào)用設(shè)一個(gè)超時(shí)時(shí)間超時(shí)就中斷并返回超時(shí)觀察。第三層是異常捕獲捕獲工具內(nèi)部拋出的異常轉(zhuǎn)成結(jié)構(gòu)化的錯(cuò)誤觀察返回給規(guī)劃器。重試策略也要講究。不是所有錯(cuò)誤都值得重試參數(shù)錯(cuò)誤重試多少次都一樣網(wǎng)絡(luò)超時(shí)重試一次可能就成功。我的做法是給錯(cuò)誤分類retryable和non_retryable。可重試的錯(cuò)誤最多重試兩次每次間隔遞增不可重試的錯(cuò)誤直接返回讓規(guī)劃器決定下一步。這個(gè)分類邏輯我寫在工具注冊信息里每個(gè)工具自己聲明哪些錯(cuò)誤可重試。實(shí)測下來加了這三層保護(hù)后因?yàn)楣ぞ哒{(diào)用失敗導(dǎo)致整個(gè)任務(wù)中斷的情況基本消失了。之前有個(gè)調(diào)用外部API的工具偶爾會因?yàn)榫W(wǎng)絡(luò)抖動超時(shí)沒有超時(shí)控制時(shí)整個(gè)流就卡死加了超時(shí)和重試后大部分抖動都能自動恢復(fù)恢復(fù)不了的也會返回錯(cuò)誤觀察規(guī)劃器會嘗試換一個(gè)數(shù)據(jù)源。4.4 觀察處理器的信息提煉觀察處理器的核心任務(wù)是把工具返回的原始結(jié)果轉(zhuǎn)化成規(guī)劃器容易理解的觀察信息。原始結(jié)果可能是JSON、可能是長文本、可能是二進(jìn)制數(shù)據(jù)直接丟給規(guī)劃器會浪費(fèi)上下文還容易干擾判斷。我的做法是分類型處理結(jié)構(gòu)化數(shù)據(jù)提取關(guān)鍵字段長文本做摘要二進(jìn)制數(shù)據(jù)只返回元信息。舉個(gè)例子一個(gè)搜索工具返回了二十條結(jié)果每條結(jié)果有標(biāo)題、摘要、鏈接。觀察處理器不會把二十條全塞進(jìn)去而是提取前五條的標(biāo)題和摘要加上一句“共返回二十條結(jié)果已展示前五條”。這樣既保留了關(guān)鍵信息又控制了上下文長度。再比如一個(gè)代碼執(zhí)行工具返回了一大段日志觀察處理器會提取日志里的錯(cuò)誤行和最后幾行輸出而不是把整段日志塞進(jìn)去。這個(gè)提煉邏輯我建議用規(guī)則模型結(jié)合的方式。規(guī)則處理結(jié)構(gòu)化數(shù)據(jù)快且穩(wěn)模型處理非結(jié)構(gòu)化文本靈活但慢。我一開始全用模型做摘要結(jié)果每輪觀察處理都要多花一兩秒后來把結(jié)構(gòu)化部分改成規(guī)則處理整體速度提升明顯。5. 常見問題與排查技巧實(shí)錄5.1 規(guī)劃器反復(fù)輸出相同動作怎么辦這是多輪閉環(huán)里最常見的問題之一。表現(xiàn)是規(guī)劃器連續(xù)幾輪輸出幾乎一樣的動作工具執(zhí)行結(jié)果也差不多但任務(wù)就是推進(jìn)不下去。排查思路分三步。第一步看狀態(tài)描述是否更新如果狀態(tài)描述里沒有包含最近一輪的執(zhí)行結(jié)果規(guī)劃器相當(dāng)于在“失憶”狀態(tài)下做決策自然會重復(fù)。第二步看工具結(jié)果是否被正確解析有時(shí)候工具返回了有效結(jié)果但觀察處理器解析失敗返回了空觀察規(guī)劃器以為沒執(zhí)行成功就再試一次。第三步看提示詞是否有歧義某些提示詞會讓模型誤以為需要反復(fù)確認(rèn)比如“確保任務(wù)完成”這種表述模型可能會反復(fù)檢查。解決方法對應(yīng)也有三個(gè)。狀態(tài)描述里強(qiáng)制包含最近一輪的完整觀察觀察處理器加解析失敗的兜底邏輯解析失敗時(shí)返回原始結(jié)果的截?cái)喟姹咎崾驹~里把“確保任務(wù)完成”改成“如果當(dāng)前觀察顯示任務(wù)已完成輸出finish動作”。我遇到過一次特別隱蔽的情況工具返回的成功信息里包含“pending”這個(gè)詞觀察處理器誤判為未完成導(dǎo)致規(guī)劃器反復(fù)重試。后來在觀察處理器里加了一個(gè)狀態(tài)映射表把工具特定的狀態(tài)詞映射成統(tǒng)一語義問題才解決。5.2 工具調(diào)用參數(shù)格式錯(cuò)誤怎么快速定位參數(shù)格式錯(cuò)誤是另一類高頻問題。表現(xiàn)是工具執(zhí)行器返回參數(shù)校驗(yàn)失敗規(guī)劃器收到錯(cuò)誤觀察后重新規(guī)劃但往往還是輸出同樣格式錯(cuò)誤的參數(shù)。排查時(shí)我一般先看規(guī)劃器輸出的原始動作確認(rèn)參數(shù)錯(cuò)在哪。常見錯(cuò)誤有三類類型錯(cuò)誤比如該傳數(shù)組的傳了字符串格式錯(cuò)誤比如時(shí)間格式不對缺失必填項(xiàng)。定位到具體錯(cuò)誤后解決方法是在規(guī)劃器提示詞里強(qiáng)化參數(shù)格式說明。我習(xí)慣在工具描述里給每個(gè)參數(shù)加一個(gè)“示例值”模型看到示例后輸出正確格式的概率明顯提高。另外參數(shù)校驗(yàn)失敗時(shí)返回的錯(cuò)誤觀察要具體不要只說“參數(shù)錯(cuò)誤”要說“參數(shù)start_time格式錯(cuò)誤期望ISO 8601格式實(shí)際收到‘明天上午’”。具體的錯(cuò)誤信息能幫助規(guī)劃器在下一輪修正。下面這張表是我整理的高頻問題速查表覆蓋了大部分常見情況問題現(xiàn)象可能原因排查動作解決方向規(guī)劃器反復(fù)輸出相同動作狀態(tài)未更新或觀察解析失敗檢查狀態(tài)描述和觀察處理器強(qiáng)制更新狀態(tài)加解析兜底工具參數(shù)格式錯(cuò)誤提示詞參數(shù)說明不清查看規(guī)劃器原始輸出補(bǔ)充參數(shù)示例值任務(wù)過早終止完成判斷過于寬松檢查終止條件邏輯增加子目標(biāo)校驗(yàn)上下文超限壓縮策略不當(dāng)查看上下文增長曲線調(diào)整壓縮觸發(fā)閾值工具調(diào)用超時(shí)無超時(shí)控制或超時(shí)太短檢查工具執(zhí)行器配置加超時(shí)和重試機(jī)制規(guī)劃粒度不合適固定粒度不適應(yīng)任務(wù)統(tǒng)計(jì)輪次和失敗率改為動態(tài)粒度策略5.3 多輪閉環(huán)的輪次消耗過大怎么優(yōu)化輪次消耗過大通常有兩個(gè)原因規(guī)劃粒度太細(xì)或者存在無效輪次。優(yōu)化前先做一輪統(tǒng)計(jì)記錄每個(gè)任務(wù)的輪次分布和每輪的動作類型。如果發(fā)現(xiàn)大量輪次花在“確認(rèn)類”動作上比如反復(fù)查詢同一個(gè)信息說明規(guī)劃器缺乏記憶需要加強(qiáng)狀態(tài)描述。如果發(fā)現(xiàn)輪次花在“試錯(cuò)類”動作上比如反復(fù)嘗試不同參數(shù)說明工具描述不夠清晰需要補(bǔ)充示例和前置條件。我的優(yōu)化順序是先優(yōu)化工具描述再優(yōu)化狀態(tài)描述最后調(diào)整規(guī)劃粒度。工具描述優(yōu)化見效最快因?yàn)楹芏嘣囧e(cuò)輪次是因?yàn)槟Ｐ筒恢拦ぞ咴趺从?。狀態(tài)描述優(yōu)化次之能減少確認(rèn)類輪次。規(guī)劃粒度調(diào)整放在最后因?yàn)樗绊懨孀畲笳{(diào)不好容易引入新問題。經(jīng)過這三輪優(yōu)化我一個(gè)原本平均十二輪的任務(wù)降到了平均六輪左右而且成功率還有提升。提示優(yōu)化輪次時(shí)不要只看平均值要看分布。有些任務(wù)天生就需要多輪強(qiáng)行壓縮輪次可能導(dǎo)致成功率下降。我一般會設(shè)定一個(gè)目標(biāo)區(qū)間比如“簡單任務(wù)三到五輪復(fù)雜任務(wù)八到十二輪”在這個(gè)區(qū)間內(nèi)就算合理。5.4 工具執(zhí)行結(jié)果與規(guī)劃預(yù)期不符怎么處理這種情況在多輪閉環(huán)里很常見工具執(zhí)行成功了但返回的結(jié)果和規(guī)劃器預(yù)期的不一樣。比如規(guī)劃器以為搜索工具會返回十條結(jié)果實(shí)際只返回了三條。處理這類問題的關(guān)鍵是讓規(guī)劃器具備“預(yù)期管理”能力。我的做法是在規(guī)劃動作里加一個(gè)可選的expected_outcome字段規(guī)劃器在決定調(diào)用工具時(shí)順便描述一下它期望的結(jié)果。工具執(zhí)行后觀察處理器對比實(shí)際結(jié)果和預(yù)期結(jié)果如果不符在觀察信息里明確標(biāo)注“實(shí)際結(jié)果與預(yù)期不符預(yù)期是……實(shí)際是……”。這個(gè)機(jī)制的好處是規(guī)劃器在下一輪能立即感知到偏差并決定是調(diào)整預(yù)期還是換工具。我實(shí)測過一個(gè)場景規(guī)劃器調(diào)用一個(gè)數(shù)據(jù)查詢工具預(yù)期返回最近七天的數(shù)據(jù)實(shí)際只返回了三天因?yàn)閿?shù)據(jù)源只保留三天。有了預(yù)期對比后規(guī)劃器下一輪自動調(diào)整了分析范圍而不是繼續(xù)按七天做分析導(dǎo)致后面全錯(cuò)。這個(gè)字段是可選不強(qiáng)制規(guī)劃器每次都填但填了之后對流的穩(wěn)定性幫助很大。6. 影響范圍與遷移場景分析6.1 這套思路適合哪些類型的智能體AgentFlow這套流內(nèi)優(yōu)化的思路最適合的是多步操作類和長周期交互類的智能體。多步操作類比如自動數(shù)據(jù)處理、自動報(bào)告生成、自動代碼修復(fù)這些任務(wù)的特點(diǎn)是步驟之間有依賴前一步的結(jié)果影響后一步的決策流內(nèi)優(yōu)化能讓依賴關(guān)系在流內(nèi)自然傳遞。長周期交互類比如客服對話、教學(xué)輔導(dǎo)這些任務(wù)的特點(diǎn)是交互輪次多用戶意圖可能在過程中變化流內(nèi)優(yōu)化能讓智能體持續(xù)跟蹤意圖變化。相對而言單步查詢類的智能體用這套思路收益不大。比如一個(gè)簡單的“查天氣”智能體一次工具調(diào)用就結(jié)束了流內(nèi)優(yōu)化帶來的復(fù)雜度增加不劃算。高實(shí)時(shí)性要求的場景也要謹(jǐn)慎流內(nèi)優(yōu)化因?yàn)槊枯喍家鲆?guī)劃延遲比固定流程高如果業(yè)務(wù)要求毫秒級響應(yīng)可能不適合。我的判斷標(biāo)準(zhǔn)是如果任務(wù)的平均步驟數(shù)超過三步或者需要根據(jù)中間結(jié)果動態(tài)調(diào)整后續(xù)步驟就值得用流內(nèi)優(yōu)化。6.2 從單智能體到多智能體協(xié)作的擴(kuò)展流內(nèi)優(yōu)化的思路可以自然擴(kuò)展到多智能體協(xié)作。單智能體時(shí)流內(nèi)是“規(guī)劃—執(zhí)行—觀察”的循環(huán)多智能體時(shí)流內(nèi)可以變成“規(guī)劃—分派—執(zhí)行—匯總—再規(guī)劃”的循環(huán)。每個(gè)子智能體負(fù)責(zé)一個(gè)子任務(wù)主規(guī)劃器負(fù)責(zé)協(xié)調(diào)。擴(kuò)展時(shí)要注意的是子智能體的工具描述要匯總到主規(guī)劃器讓主規(guī)劃器知道每個(gè)子智能體的能力邊界。另外子智能體之間的狀態(tài)同步要設(shè)計(jì)好避免出現(xiàn)一個(gè)子智能體改了狀態(tài)另一個(gè)不知道的情況。我試過一個(gè)簡單的多智能體版本一個(gè)主規(guī)劃器加兩個(gè)子智能體一個(gè)負(fù)責(zé)數(shù)據(jù)查詢一個(gè)負(fù)責(zé)數(shù)據(jù)可視化。主規(guī)劃器把任務(wù)拆成“查詢數(shù)據(jù)”和“生成圖表”兩個(gè)子任務(wù)分派給對應(yīng)子智能體子智能體執(zhí)行完把結(jié)果返回主規(guī)劃器主規(guī)劃器再決定下一步。這個(gè)版本比單智能體版本在復(fù)雜任務(wù)上的成功率高一些但輪次消耗也更多因?yàn)槎嗔艘粚臃峙珊蛥R總。所以多智能體不是銀彈任務(wù)復(fù)雜度不夠時(shí)反而拖慢速度。6.3 工程落地時(shí)的性能與成本權(quán)衡流內(nèi)優(yōu)化在工程落地時(shí)最大的權(quán)衡是性能和成本。每輪規(guī)劃都要調(diào)用一次大模型輪次越多token消耗越大。我的經(jīng)驗(yàn)是在規(guī)劃器上可以用相對小一點(diǎn)的模型因?yàn)橐?guī)劃任務(wù)的復(fù)雜度通常低于生成任務(wù)在觀察處理器上能用規(guī)則就用規(guī)則規(guī)則處理不了的再用模型。這樣搭配下來整體成本能控制在一個(gè)可接受的范圍內(nèi)。另一個(gè)權(quán)衡是延遲。流內(nèi)優(yōu)化的延遲主要來自模型調(diào)用每輪規(guī)劃加觀察處理大概需要一到三秒。如果業(yè)務(wù)能接受這個(gè)延遲就沒問題如果不能可以考慮把規(guī)劃器做成流式輸出邊生成邊解析提前開始工具調(diào)用。我試過流式解析能把首輪延遲降低大概三成但實(shí)現(xiàn)復(fù)雜度上升不少需要處理部分解析和回滾的情況。注意成本優(yōu)化時(shí)不要犧牲可觀測性。我見過為了省token把中間狀態(tài)全刪了的做法結(jié)果出問題時(shí)完全沒法排查。我的做法是中間狀態(tài)照常記錄但只在調(diào)試模式下注入到規(guī)劃上下文生產(chǎn)模式下只注入摘要這樣既省了token又保留了排查能力。7. 我在這類系統(tǒng)上踩過的幾個(gè)真實(shí)坑第一個(gè)坑是過度依賴模型的自我修正能力。我一開始覺得只要把錯(cuò)誤信息返回給規(guī)劃器模型自己會修正。實(shí)際跑下來發(fā)現(xiàn)模型對某些類型的錯(cuò)誤確實(shí)能修正比如參數(shù)格式錯(cuò)誤但對另一些錯(cuò)誤比如邏輯錯(cuò)誤模型往往會沿著錯(cuò)誤方向繼續(xù)走。后來我在規(guī)劃器里加了一個(gè)“錯(cuò)誤分類”邏輯邏輯錯(cuò)誤直接觸發(fā)重新規(guī)劃而不是讓模型自己修。第二個(gè)坑是工具描述更新后沒有同步到規(guī)劃器。有一次我給一個(gè)工具加了新的必填參數(shù)但忘了更新規(guī)劃器里的工具描述結(jié)果規(guī)劃器還是按舊格式調(diào)用連續(xù)失敗了好幾輪。后來我改成工具描述和工具實(shí)現(xiàn)放在同一個(gè)注冊項(xiàng)里更新時(shí)一起更新避免不同步。第三個(gè)坑是終止條件過于依賴單一信號。早期我只用“任務(wù)完成”作為終止條件結(jié)果遇到模型誤判完成的情況任務(wù)沒做完就停了。后來加了預(yù)算耗盡和停滯檢測兩個(gè)信號三個(gè)信號任一觸發(fā)就終止穩(wěn)定性好了很多。第四個(gè)坑是上下文壓縮時(shí)把關(guān)鍵約束壓沒了。有一次壓縮后規(guī)劃器忘了“輸出必須是中文”這個(gè)約束生成了英文結(jié)果。后來我在壓縮邏輯里加了一個(gè)“關(guān)鍵約束保留”規(guī)則把用戶明確提出的約束單獨(dú)存一份不參與壓縮。這些坑說起來都不復(fù)雜但每一個(gè)都是實(shí)際跑起來才會遇到的。寫這類系統(tǒng)理論上的優(yōu)雅和工程上的穩(wěn)健往往是兩回事多跑、多記錄、多復(fù)盤比一開始就追求完美架構(gòu)更重要。