1. 為什么我勸你把“3天落地”當(dāng)成一個(gè)認(rèn)真的工程目標(biāo)過去一年里我見過不少團(tuán)隊(duì)做Agent項(xiàng)目死法驚人地一致。有個(gè)做供應(yīng)鏈服務(wù)的項(xiàng)目組花了整整兩周搭了一個(gè)“綜合性智能助手”——能聊天、能寫周報(bào)、能解釋術(shù)語業(yè)務(wù)方看演示的時(shí)候都說“哇”。等真讓它對(duì)接WMS系統(tǒng)去查庫存、改單子就開始裝傻要么答非所問要么參數(shù)缺胳膊少腿要么直接編一個(gè)不存在的庫存數(shù)量。最后項(xiàng)目被砍復(fù)盤結(jié)論寫著“大模型能力不足”其實(shí)根本是需求模糊加上流程根本沒跑通。所以我特別想聊“3天落地”這個(gè)事。它不是讓你把半年的項(xiàng)目壓縮成3天去趕工而是逼著你只做一條最窄、最高價(jià)值、能跑通業(yè)務(wù)的鏈路——從需求拆解到上線全流程的所有環(huán)節(jié)全部在72小時(shí)內(nèi)走完。這個(gè)時(shí)間盒是很好的工程紀(jì)律它強(qiáng)制你放棄“做一個(gè)全能的Agent”這種不切實(shí)際的目標(biāo)老老實(shí)實(shí)把“一個(gè)場景里的一類任務(wù)”徹底做好。這篇內(nèi)容是給誰看的主要是兩類人第一類手里已經(jīng)有業(yè)務(wù)系統(tǒng)有API、有數(shù)據(jù)庫、有業(yè)務(wù)規(guī)則但團(tuán)隊(duì)還沒想清楚Agent該從哪里入手第二類正在做Agent POC但擔(dān)心做出來又是“能說不能干”的演示品。讀完之后你會(huì)得到一張可直接用的三天推進(jìn)清單以及我在多個(gè)企業(yè)級(jí)項(xiàng)目里踩過、填過的坑。先說一句結(jié)論放在前面Agent項(xiàng)目的真正難點(diǎn)從來不是模型不夠聰明而是工程化不夠結(jié)實(shí)。3天的目標(biāo)就是把這句話變成現(xiàn)實(shí)。1.1 一個(gè)失敗的樣本兩周Demo為什么被砍剛才提到的那個(gè)供應(yīng)鏈項(xiàng)目我再拆細(xì)一點(diǎn)。他們的需求是“做一個(gè)能處理訂單異常的智能助手”聽起來很明確但實(shí)際開發(fā)中所有人都在做加法。一開始只打算查訂單狀態(tài)后來業(yè)務(wù)方說“能不能順便把退換貨規(guī)則也答了”再后來產(chǎn)品經(jīng)理說“如果用戶問‘為什么我的貨還沒到’咱們能不能主動(dòng)查物流延遲原因”。需求面越鋪越寬到第10天時(shí)Agent需要理解30多種意圖調(diào)用8套內(nèi)部系統(tǒng)其中一半系統(tǒng)連穩(wěn)定的測試環(huán)境都沒有。最后的演示很熱鬧但懂行的人一看就知道沒有一個(gè)環(huán)節(jié)經(jīng)得起生產(chǎn)環(huán)境考驗(yàn)。沒有超時(shí)處理大模型卡住的時(shí)候用戶只能干等沒有工具調(diào)用的校驗(yàn)邏輯模型抽參數(shù)抽漏了系統(tǒng)照樣把空值發(fā)給下游沒有人工兜底答錯(cuò)就是答錯(cuò)連個(gè)“轉(zhuǎn)人工”的通道都沒設(shè)計(jì)。這個(gè)案例給我最大的教訓(xùn)是不是任務(wù)越復(fù)雜越有價(jià)值而是任務(wù)越閉環(huán)越有價(jià)值。1.2 “3天”背后的工程邏輯用Deadline逼出優(yōu)先級(jí)坦白說給項(xiàng)目設(shè)置3天時(shí)間本身就是一種需求篩選手段。我常用一個(gè)辦法叫“三問淘汰法”需求出現(xiàn)的時(shí)候連問三個(gè)問題這個(gè)需求每周出現(xiàn)多少次如果每周出現(xiàn)不足50次直接不進(jìn)首期范圍。這個(gè)需求是否依賴單一業(yè)務(wù)系統(tǒng)如果調(diào)用鏈超過兩個(gè)系統(tǒng)后移到二期。這個(gè)需求的結(jié)果是否可以明確驗(yàn)收如果“答得好不好”都沒有標(biāo)準(zhǔn)說明業(yè)務(wù)方自己也沒想清楚。用這三問過濾完之后你會(huì)發(fā)現(xiàn)真正值得做的Agent場景所剩無幾但留下來的每一個(gè)都是高確定性、高頻率、可驗(yàn)收的。我最近做一個(gè)零售行業(yè)的售后客訴Agent就是拿這套方法砍掉了8個(gè)候選場景中的7個(gè)只留下“查單催發(fā)貨”這一個(gè)場景第1天晚上就把端到端流程跑通了。剩下的2天全在打磨邊界條件、加工程保護(hù)最后業(yè)務(wù)方反而覺得這個(gè)Agent比那些大而全的Demo靠譜得多。2. 需求拆解的第一課先定義“不做清單”很多技術(shù)團(tuán)隊(duì)習(xí)慣拿到需求就畫架構(gòu)圖我建議反過來先寫“不做清單”。這事一旦做晚了代價(jià)會(huì)指數(shù)級(jí)上升。2.1 用“高頻、閉環(huán)、可驗(yàn)收”三把尺子篩需求關(guān)于這個(gè)問題我可以展開說說高頻不是“偶爾能幫上忙”而是“每天都會(huì)發(fā)生”。有真實(shí)業(yè)務(wù)數(shù)據(jù)的團(tuán)隊(duì)直接翻過去一個(gè)季度的客服工單、系統(tǒng)操作日志、業(yè)務(wù)報(bào)表把Top10高頻操作拉出來。沒有數(shù)據(jù)的就找業(yè)務(wù)方一起做“一周排演”把一周內(nèi)可能出現(xiàn)的用戶問題全部過一遍能寫滿一整墻便利貼的才是真需求。閉環(huán)這個(gè)任務(wù)從開始到結(jié)束Agent能不能獨(dú)立走完比如“查快遞到哪了”用戶問、Agent查、系統(tǒng)回三步閉環(huán)好做。而“幫我想想這周團(tuán)購選什么套餐”沒有明確的工具、數(shù)據(jù)和成功標(biāo)準(zhǔn)這就不是閉環(huán)任務(wù)是開放聊天先放一邊?？沈?yàn)收業(yè)務(wù)層面得有判斷依據(jù)。我一般會(huì)要求業(yè)務(wù)方回答一個(gè)問題“如果這個(gè)Agent明天上線你覺得好用還是不好用用什么例子來判斷”能舉出具體例子的場景才做。比如“客戶問發(fā)貨時(shí)間Agent必須在5秒內(nèi)給出準(zhǔn)確時(shí)間給錯(cuò)了算事故”——這種定義方式開發(fā)才知道往哪個(gè)方向努力。2.2 把業(yè)務(wù)語言翻譯成一張“決策表”需求拆解有一個(gè)非常實(shí)用的產(chǎn)出物我一般叫它“意圖決策表”。拿零售售后場景舉例拆完之后大概是這個(gè)樣子的用戶輸入特征意圖類型需要的參數(shù)調(diào)用的工具業(yè)務(wù)動(dòng)作包含“訂單號(hào)物流/到哪/發(fā)貨”物流查詢訂單號(hào)物流系統(tǒng)接口返回物流軌跡包含“訂單號(hào)退/換”售后請(qǐng)求訂單號(hào)原因售后工單系統(tǒng)生成工單轉(zhuǎn)人工審核包含“投訴/客服電話”人工客服無轉(zhuǎn)接模塊緊急轉(zhuǎn)人工輸入不匹配任何規(guī)則兜底意圖無無回復(fù)“我還沒學(xué)會(huì)已轉(zhuǎn)人工”這張表的作用不是拿給模型訓(xùn)練而是讓開發(fā)知道Agent的“大腦中軸線”是什么。模型不在這一步自由發(fā)揮它做的事情只是在有限意圖里做一次分類和參數(shù)抽取正確率會(huì)高很多。2.3 邊界條件清單寧可拒絕不能瞎猜企業(yè)級(jí)Agent和普通聊天機(jī)器人的分水嶺就在邊界條件的處理上。個(gè)人用戶的聊天機(jī)器人答錯(cuò)了用戶頂多罵一句然后自己重試。企業(yè)場景里Agent答錯(cuò)了可能直接引發(fā)客訴、造成庫存誤扣甚至觸發(fā)合規(guī)問題。所以從需求拆解的第一天起你就必須在每個(gè)意圖旁邊標(biāo)注“不確定時(shí)怎么辦”。我自己的硬性規(guī)則是模型置信度低于閾值通常設(shè)在0.6左右具體根據(jù)場景調(diào)整時(shí)允許的響應(yīng)方式只有兩種——要么直接轉(zhuǎn)人工要么明確告訴用戶“我沒有理解你的需求請(qǐng)重新描述”絕不強(qiáng)行給答案。這條規(guī)則寫進(jìn)需求文檔比寫進(jìn)代碼更重要因?yàn)闃I(yè)務(wù)方只有在需求階段同意了這條兜底策略后續(xù)驗(yàn)收才不會(huì)有分歧。3. 架構(gòu)落地選型不是越重越好編排層才是靈魂第1天下午開始進(jìn)入技術(shù)選型階段。很多團(tuán)隊(duì)一上來就在糾結(jié)“用哪個(gè)大模型”我說先別急畫清楚架構(gòu)邊界比選模型重要十倍。3.1 先畫一條清晰的分層線Agent系統(tǒng)只有5層我在企業(yè)項(xiàng)目里最常用的分層方式是這樣的接入層負(fù)責(zé)接收各種入口的統(tǒng)一請(qǐng)求——網(wǎng)頁對(duì)話、企業(yè)微信、客服系統(tǒng)接口對(duì)接入口可以有很多個(gè)但接入層后必須收斂成一種內(nèi)部統(tǒng)一協(xié)議。我通常用“消息對(duì)象”作為標(biāo)準(zhǔn)結(jié)構(gòu)里面至少包含用戶ID、會(huì)話ID、文本內(nèi)容、附帶參數(shù)比如訂單號(hào)、時(shí)間戳。這一步不做的話后面每個(gè)渠道都要單獨(dú)適配你會(huì)瘋掉。編排層是Agent的心臟也是整個(gè)架構(gòu)里最值得投入的地方。它的職責(zé)是意圖識(shí)別、參數(shù)抽取、工具選擇、結(jié)果校驗(yàn)、流程控制。這套邏輯一定寫在應(yīng)用代碼里由編程語言控制而不是讓模型自己去“想”。重復(fù)一遍這句話——不管多厲害的模型都別讓它獨(dú)立決定“該調(diào)用哪個(gè)API、參數(shù)填什么”至少初期不要。工具層把已有的內(nèi)部系統(tǒng)包裝成模型可調(diào)用的“函數(shù)”。需要重點(diǎn)設(shè)計(jì)的是每個(gè)工具的參數(shù)Schema下面第4章會(huì)細(xì)講。另外工具層的返回值無論內(nèi)部是什么數(shù)據(jù)結(jié)構(gòu)都要在外面加一層“展示摘要”——讓模型只看到精簡后的業(yè)務(wù)結(jié)果別把各種內(nèi)部狀態(tài)碼和原始日志喂進(jìn)去。記憶層負(fù)責(zé)上下文保持包含兩部分短期記憶當(dāng)前任務(wù)會(huì)話中的關(guān)鍵信息和長期記憶用戶偏好、歷史工單摘要。企業(yè)場景不推薦簡單堆對(duì)話歷史因?yàn)門oken成本和噪音都會(huì)被放大。更好的做法是設(shè)置“工作臺(tái)”結(jié)構(gòu)只維護(hù)當(dāng)前任務(wù)需要的參數(shù)和結(jié)果詳見第4.3節(jié)。審計(jì)層負(fù)責(zé)記錄一切輸入、輸出、工具入?yún)?、出參、模型返回的原始?nèi)容、耗時(shí)、成本。這層在Demo階段沒什么用一上線立刻變成剛需。業(yè)務(wù)有爭議的時(shí)候沒有審計(jì)日志你連自己答過什么都沒法證明。3.2 模型選型的幾個(gè)務(wù)實(shí)標(biāo)準(zhǔn)大模型選型我用的判斷維度是這樣的維度核心問題我的建議工具調(diào)用能力給定函數(shù)定義能否準(zhǔn)確抽出參數(shù)找3組臟數(shù)據(jù)實(shí)測錯(cuò)誤一次都換響應(yīng)延遲端到端時(shí)間里占比最大的就是模型推理同一場景下要求P95在2秒內(nèi)上下文長度夠裝下決策表工具定義工作臺(tái)信息4K到8K足夠貪大于心智負(fù)擔(dān)服務(wù)穩(wěn)定性高峰期會(huì)不會(huì)限流有無重試機(jī)制選型前先問SLA別在線上賭運(yùn)氣成本單次調(diào)用的綜合成本按日活和平均輪次估算月成本這里說一個(gè)很多團(tuán)隊(duì)容易踩的坑光看公開評(píng)測榜單選模型。你在公有能力排行榜看到的結(jié)果和你業(yè)務(wù)場景的實(shí)際情況完全是兩碼事。正確的做法是選型當(dāng)天就構(gòu)造一批你們業(yè)務(wù)特有的“臟輸入”——比如訂單號(hào)缺一位、用戶把收貨地址說了一半、用戶用語音轉(zhuǎn)文字所以有錯(cuò)別字——直接拿到各候選模型上跑一遍看誰最抗造。記住你是去干活的不是去評(píng)榜的。3.3 編排框架的三個(gè)選項(xiàng)我推薦哪一個(gè)當(dāng)前可選的路大致有三條。選項(xiàng)A使用較成熟的開源編排框架。這類框架幫你解決了很多通用問題比如多輪對(duì)話、工具調(diào)用循環(huán)、記憶持久化上手快。我大概評(píng)估過它們的定位適合團(tuán)隊(duì)對(duì)Agent還比較陌生、需要在短時(shí)間內(nèi)先跑通一版、同時(shí)不打算在基礎(chǔ)設(shè)施上花太多人力的情況。代價(jià)是框架本身有學(xué)習(xí)成本和一定的抽象膨脹很多邏輯被包在黑盒里出了問題排查起來稍微費(fèi)點(diǎn)工夫。選項(xiàng)B自研一個(gè)輕量編排器。這其實(shí)比很多人想象的要簡單。一個(gè)意圖識(shí)別函數(shù)、一個(gè)參數(shù)抽取函數(shù)、一個(gè)工具調(diào)用分發(fā)函數(shù)、一個(gè)校驗(yàn)與兜底函數(shù)——四個(gè)核心類撐死了兩三千行代碼卻能換來極高的可控性。我們用這種方案落地過不少項(xiàng)目好處是每一個(gè)環(huán)節(jié)都能打日志每一條錯(cuò)誤都能準(zhǔn)確定位。代價(jià)是基礎(chǔ)能力要自己搭比如多輪會(huì)話管理、調(diào)用重試、狀態(tài)機(jī)這類通用功能都得自己寫。選項(xiàng)C純提示詞派。讓模型直接看一大段提示詞要求它按流程調(diào)用工具。優(yōu)點(diǎn)是原型快缺點(diǎn)是生產(chǎn)環(huán)境極難控制稍微復(fù)雜一點(diǎn)的工具組合就可能亂套。我的建議很直接如果你以后要持續(xù)維護(hù)這個(gè)Agent別選C如果你團(tuán)隊(duì)里沒人深入了解過開源的編排框架也別A因?yàn)槌隽司€上事故你不知道該改框架源碼還是改自己的代碼。首選B用一個(gè)周末就能寫完的輕量編排器換來的是100%的可控性。3.4 可控性是第一原則給模型一條“窄路”走有一點(diǎn)我想特別強(qiáng)調(diào)企業(yè)級(jí)Agent和學(xué)術(shù)Demo之間最大的觀念差異是對(duì)“自由發(fā)揮”的態(tài)度。Demo喜歡讓模型自由發(fā)揮顯得“智能”企業(yè)生產(chǎn)要的是穩(wěn)定輸出智能是排在穩(wěn)定之后的。所以給模型的路越窄越好意圖列表固定、工具選擇固定、參數(shù)抽取有明確約束模型只在一個(gè)極小的決策空間里做選擇題和填空題。我們內(nèi)部有個(gè)說法叫“Model in a Box”意思是模型被裝進(jìn)一個(gè)邊界明確的框里框之外是業(yè)務(wù)代碼的絕對(duì)控制區(qū)。做到這一點(diǎn)你對(duì)系統(tǒng)的可預(yù)測性、可測試性、可審計(jì)性就都有了保障。而企業(yè)界的人其實(shí)不太喜歡把關(guān)鍵業(yè)務(wù)動(dòng)作全交給模型直接決策的——各個(gè)團(tuán)隊(duì)都有自己踩過“自由發(fā)揮”的坑最后得出的結(jié)論幾乎出奇一致。4. 第二天把“能聊天”的Agent改成“會(huì)辦事”的任務(wù)系統(tǒng)第一天結(jié)束的時(shí)候你應(yīng)該已經(jīng)完成了需求拆解表、技術(shù)選型、系統(tǒng)分層的設(shè)計(jì)并且搭好了工程骨架。第二天全天目標(biāo)只有一個(gè)讓Agent在一條真實(shí)業(yè)務(wù)鏈路上端到端跑通。4.1 最小閉環(huán)六個(gè)環(huán)節(jié)一個(gè)都不能少一個(gè)能“辦事”而不是“聊天”的Agent它的每次任務(wù)處理一定是結(jié)構(gòu)化的意圖識(shí)別把用戶輸入分類到預(yù)定義的意圖列表中。參數(shù)抽取從文本中提取調(diào)用工具所需的字段包括從對(duì)話歷史里補(bǔ)全缺失字段。工具選擇根據(jù)意圖和已抽到的參數(shù)由代碼邏輯決定調(diào)用哪個(gè)工具。工具調(diào)用執(zhí)行內(nèi)部API請(qǐng)求處理超時(shí)和重試。結(jié)果校驗(yàn)把工具返回的結(jié)果和用戶問題做一致性檢查判斷是否滿足回答條件?；貜?fù)生成基于工具返回結(jié)構(gòu)用模型生成面向用戶的自然語言回復(fù)。第2步和第5步是很多人最容易忽略的但它們恰恰是“會(huì)辦事”和“假裝會(huì)辦事”的關(guān)鍵區(qū)別。參數(shù)抽取得全工具調(diào)用才不會(huì)失敗結(jié)果校驗(yàn)做得好模型才不會(huì)把系統(tǒng)返回的“查無此單”硬生生編成“您的貨物正在運(yùn)輸途中”。4.2 工具調(diào)用的Schema才是Agent的“骨相”如果架構(gòu)有骨頭那工具調(diào)用的Schema就是骨相。參數(shù)定義得漂不漂亮直接決定模型抽參數(shù)能不能抽得準(zhǔn)。拿查詢訂單狀態(tài)舉例一個(gè)工具的函數(shù)定義大概長這樣{ name: query_order_status, description: 根據(jù)訂單號(hào)查詢訂單的最新狀態(tài)和物流信息。訂單號(hào)必須完整。, parameters: { type: object, properties: { order_no: { type: string, description: 用戶提供的訂單號(hào)一般為12位數(shù)字例如202501011234。如果用戶只提供部分訂單號(hào)不要嘗試拼接直接標(biāo)記為缺失。 }, user_id: { type: string, description: 當(dāng)前登錄用戶的ID從會(huì)話上下文中獲取不需要用戶重新提供 } }, required: [order_no, user_id] } }三個(gè)經(jīng)驗(yàn)之談。第一description不要寫教科書式的解釋要寫“給模型看的提示詞”。把業(yè)務(wù)判斷規(guī)則寫進(jìn)去比如“訂單號(hào)必須完整”“不要嘗試拼接”比你在prompt里反復(fù)強(qiáng)調(diào)有用得多。第二必填參數(shù)盡量少。能不依賴用戶輸入的字段就通過會(huì)話上下文注入比如登錄用戶的ID要用戶輸入的也要想清楚哪些是“可后續(xù)追問補(bǔ)全”的。第三返回值要做成“扁平摘要”。不要讓模型去讀一堆子表、嵌套字段、狀態(tài)碼直接匯總成一句類似“包裹已發(fā)出當(dāng)前位于某地轉(zhuǎn)運(yùn)中心預(yù)計(jì)明天送達(dá)”的文本或者一行結(jié)構(gòu)化的關(guān)鍵字段。模型拿到的信息越清爽最終回復(fù)質(zhì)量就越高。4.3 記憶和上下文給Agent一個(gè)“工作臺(tái)”而不是“聊天記錄”第二天的另一個(gè)重要工程是“工作臺(tái)”設(shè)計(jì)。一個(gè)對(duì)話半小時(shí)的用戶中間可能穿插各種問題如果指望模型從幾百句聊天記錄里自己找“剛才那個(gè)訂單號(hào)是多少”它一定會(huì)出錯(cuò)。所以我推薦每個(gè)會(huì)話維護(hù)一個(gè)結(jié)構(gòu)化的任務(wù)工作臺(tái)類似這樣字段內(nèi)容說明current_intent查詢物流當(dāng)前正在處理的意圖collected_paramsorder_no202501011234已確認(rèn)可用的參數(shù)pending_params無仍欠缺的參數(shù)tool_result已返回包裹到達(dá)某轉(zhuǎn)運(yùn)中心上一次工具調(diào)用的結(jié)果摘要statusWAITING_USER_INPUT任務(wù)狀態(tài)等待追問或等回復(fù)每一輪對(duì)話結(jié)束你的編排層按“先更新工作臺(tái)、再做決策”的順序處理。這種方式有兩個(gè)好處一是模型每次只需要看到工作臺(tái)里的關(guān)鍵信息不會(huì)迷失在歷史里二是所有參數(shù)的確認(rèn)鏈路清晰可控哪些是用戶說的、哪些是系統(tǒng)給的、哪些是模型猜的一目了然。4.4 讓流程可見人可以在中途接管企業(yè)級(jí)Agent還有一個(gè)標(biāo)配能力是好多Demo做不到的人在中途接管。所謂“接管”不是說一句“轉(zhuǎn)人工”就完事而是當(dāng)前任務(wù)得能完整交接。比如Agent正在推進(jìn)一個(gè)退貨流程抽到了訂單號(hào)但用戶糾結(jié)要不要留退貨原因這時(shí)候用戶說“算了不退了”Agent要能立刻終止當(dāng)前意圖重置工作臺(tái)而不是執(zhí)著地繼續(xù)追問退貨原因。更嚴(yán)謹(jǐn)?shù)南到y(tǒng)里任務(wù)狀態(tài)里還有“掛起待審核”這一類。有些操作在試運(yùn)行期或高風(fēng)控場景下必須有人工審批Assistant只負(fù)責(zé)把資料收集齊然后生成一個(gè)結(jié)構(gòu)化摘要推給業(yè)務(wù)人員審核。執(zhí)行權(quán)在人工手里Agent永遠(yuǎn)只是“建議者”而不是“行動(dòng)者”。5. 上線前的工程加固超時(shí)、重試、狀態(tài)機(jī)與安全邊界第3天上午開始進(jìn)入我稱之為“工程加固”的階段。這一天的任務(wù)不是加功能而是把最有可能會(huì)在線上炸掉的地方先補(bǔ)上。5.1 大模型接口的“三超”問題超時(shí)、超流量、超預(yù)算所有接過大模型API的人遲早都會(huì)在線上遇到下面的情況。模型服務(wù)商偶爾抽風(fēng)不是網(wǎng)絡(luò)問題就是服務(wù)端限流響應(yīng)時(shí)間波動(dòng)劇烈超時(shí)的時(shí)候看起來就像系統(tǒng)死了。應(yīng)對(duì)方案里最基礎(chǔ)但最有效的是三層控制書接上回我先說超時(shí)。我給系統(tǒng)定了三個(gè)時(shí)間閾值單次模型調(diào)用超時(shí)設(shè)為5秒整個(gè)Agent任務(wù)端到端時(shí)長不超過15秒超過閾值立即終止當(dāng)前流程并給出兜底回復(fù)“系統(tǒng)有點(diǎn)忙請(qǐng)稍后再試或轉(zhuǎn)人工”。別設(shè)得太長一個(gè)用戶如果盯著屏幕等30秒體驗(yàn)已經(jīng)崩了還不如快速失敗讓用戶重試。再說流量和預(yù)算。每次調(diào)用在編排層都要有“熔斷開關(guān)”——連續(xù)5次調(diào)用失敗自動(dòng)熔斷10分鐘期間所有請(qǐng)求直接走兜底文案。成本控制方面給模型單獨(dú)設(shè)置每日額度比如一天最多消耗預(yù)算X元超過之后自動(dòng)降級(jí)為只用簡單規(guī)則回復(fù)或轉(zhuǎn)人工。這套邏輯在第二行代碼就要加進(jìn)去。def call_llm_with_retry(prompt, max_retries2): for attempt in range(max_retries 1): try: # 單次超時(shí)設(shè)置為5秒不包含排隊(duì)等待時(shí)間 response llm_client.chat( messagesprompt, timeout5 ) return response except TimeoutError: if attempt max_retries: return generate_fallback_reply() time.sleep(0.5 * (attempt 1)) # 退避等待 except RateLimitError: if attempt max_retries: return generate_fallback_reply() time.sleep(2) # 限流常見多等一會(huì)兒 return generate_fallback_reply()這里要特別提醒一個(gè)細(xì)節(jié)重試只對(duì)“暫時(shí)性錯(cuò)誤”有意義對(duì)超過預(yù)算、鑒權(quán)失敗這類“永久性錯(cuò)誤”重試完全沒有價(jià)值白白浪費(fèi)時(shí)間和資源。所以重試邏輯里一定要區(qū)分錯(cuò)誤類型。5.2 從“一輪對(duì)話”到“任務(wù)狀態(tài)機(jī)”到了上線前這一步我會(huì)強(qiáng)制要求把Agent的任務(wù)從“無狀態(tài)對(duì)話”升級(jí)為“狀態(tài)機(jī)”。不要覺得這個(gè)重其實(shí)就是把會(huì)話生命周期里的幾個(gè)狀態(tài)顯式化。常規(guī)任務(wù)狀態(tài)至少應(yīng)該是這些狀態(tài)含義進(jìn)入方式PENDING等待用戶輸入或新任務(wù)開始新會(huì)話創(chuàng)建TOOL_CALLING正在調(diào)用內(nèi)部工具意圖識(shí)別完成參數(shù)已齊WAITING_USER_INPUT缺少參數(shù)正在追問用戶參數(shù)校驗(yàn)發(fā)現(xiàn)缺失項(xiàng)SUCCESS本任務(wù)已完成可發(fā)起新意圖工具返回成功且校驗(yàn)通過FAILED任務(wù)執(zhí)行失敗走兜底回復(fù)重試仍失敗或超時(shí)NEED_REVIEW需要人工審核或接管命中高風(fēng)控動(dòng)作或低置信度狀態(tài)機(jī)的意義在于它讓Agent的行為變得可預(yù)期。比如用戶在Agent查物流的路上突然問了一個(gè)新問題狀態(tài)機(jī)要能正確處理“意圖切換”當(dāng)前任務(wù)掛起新意圖入棧舊任務(wù)的參數(shù)保留在工作臺(tái)里等用戶回頭再說。沒有狀態(tài)機(jī)這種場景會(huì)讓Agent立刻精神分裂把兩個(gè)任務(wù)的信息混在一起回答。5.3 安全與審計(jì)Agent做出的是“建議”還是“動(dòng)作”最后一天還要認(rèn)真設(shè)計(jì)一個(gè)邊界問題哪些操作Agent可以直接執(zhí)行哪些必須走審批。我個(gè)人的原則是只讀操作可以自動(dòng)執(zhí)行比如查庫存、查訂單、看物流寫操作必須二次確認(rèn)比如改地址、改數(shù)量、提交工單涉及資金、刪除、權(quán)限變更這類高危動(dòng)作必須走人工審批鏈路。這個(gè)原則說給業(yè)務(wù)方聽對(duì)方基本都會(huì)同意因?yàn)闆]有人愿意讓一個(gè)還不能完全信任的Agent直接動(dòng)錢。審計(jì)日志的字段建議至少包含會(huì)話ID、用戶ID、時(shí)間戳、意圖名稱、模型輸入摘要、模型輸出全文、工具名稱、工具入?yún)ⅰ⒐ぞ叱鰠⒄?、耗時(shí)、消費(fèi)Token數(shù)、命中策略。落庫之后別只存著不看建議每天跑一個(gè)成本匯總和錯(cuò)誤輪次回看。6. 驗(yàn)收標(biāo)準(zhǔn)與灰度發(fā)布怎樣才算真正可以砍掉人工到第3天下午系統(tǒng)跑通、加固完成看起來一切正常了。但能不能真正上線還需要一套驗(yàn)收方法論。6.1 四個(gè)指標(biāo)一個(gè)都不能少我在所有Agent項(xiàng)目里都在用這四把尺子來衡量“能不能放量”指標(biāo)計(jì)算方式參考初值任務(wù)完成率成功完成任務(wù)數(shù) / 總請(qǐng)求數(shù)不低于85%工具調(diào)用準(zhǔn)確率工具返回結(jié)果正確/調(diào)用成功 / 工具總調(diào)用次數(shù)不低于90%端到端P95時(shí)延從發(fā)消息到收到回復(fù)的第95百分位耗時(shí)不超過8秒人工介入率需要人工接管/轉(zhuǎn)人工的請(qǐng)求 / 總請(qǐng)求數(shù)不超過20%任務(wù)完成率可以過濾那些“答了但沒辦成事”的對(duì)話工具調(diào)用準(zhǔn)確率單獨(dú)看是因?yàn)榧词谷蝿?wù)沒完成工具調(diào)用也不能有太多錯(cuò)P95時(shí)延決定用戶體驗(yàn)人工介入率是兜底策略執(zhí)行情況的度量太高說明Agent能力不足太低比如為0反而要警惕是不是業(yè)務(wù)規(guī)則的邊界設(shè)得太保守。驗(yàn)收的具體方式是準(zhǔn)備80條帶標(biāo)注的測試樣本覆蓋每個(gè)意圖的正例、反例、邊界情況比如訂單號(hào)缺失、重復(fù)追問、情緒化輸入跑完后按指標(biāo)逐條算。做這一步的時(shí)候有個(gè)心態(tài)要擺正測試樣本過了不代表上線穩(wěn)了但樣本都過不了上線一定會(huì)出事。6.2 灰度策略影子模式 → 小流量 → 人工復(fù)核 → 全量雖然只有3天時(shí)間但上線環(huán)節(jié)我也不會(huì)一把梭。標(biāo)準(zhǔn)的灰度鏈路是四段。影子模式把線上真實(shí)流量復(fù)制一份給AgentAgent的答復(fù)不觸達(dá)用戶只和人工客服的真實(shí)答復(fù)做對(duì)比目的是看它在真實(shí)數(shù)據(jù)上的表現(xiàn)。小流量比如放1%的真實(shí)用戶進(jìn)來Agent直接回復(fù)同時(shí)安排客服在旁邊待命。觀察剛才那四個(gè)指標(biāo)尤其關(guān)注任務(wù)完成率。人工復(fù)核把Agent已經(jīng)完成的任務(wù)按一定比例抽出來人工復(fù)查。我第一次做合作伙伴的Agent項(xiàng)目時(shí)這一步抓出了大量“看似成功實(shí)則答非所問”的樣本提前發(fā)現(xiàn)了上下文混亂的問題。全量放量指標(biāo)達(dá)標(biāo)后全量同時(shí)前兩周每天盯指標(biāo)。6.3 上線不是結(jié)束錯(cuò)題集回灌和模型無關(guān)項(xiàng)目上線以后真正開始產(chǎn)生價(jià)值的是“錯(cuò)題集”復(fù)盤機(jī)制。我比較建議每周做一次樣本評(píng)審把當(dāng)周的失敗案例撈出來分類記錄是意圖分類錯(cuò)了、參數(shù)抽錯(cuò)了、工具調(diào)用邏輯出問題了還是模型回復(fù)的時(shí)候跑偏了。評(píng)估過很多案例后我發(fā)現(xiàn)一件有意思的事六成以上的問題不在模型本身而在工具Schema描述不清、工作臺(tái)信息維護(hù)不完整、決策表的邊界定義太粗。換句話說你花再多錢換更聰明的模型效果都不一定比花半天時(shí)間把Schema里的描述寫得更清楚來得好。所以錯(cuò)題集回灌更新的優(yōu)先級(jí)排第一的是工具描述其次是決策表規(guī)則最后才是考慮換模型。這個(gè)順序不要搞反。對(duì)了最后提一個(gè)我自己每次都會(huì)做的小步驟第二天晚上找一個(gè)沒參與開發(fā)的人來當(dāng)“紅隊(duì)”讓他對(duì)著Agent自由提問專挑邊界情況。往往他問出來的問題比你自己準(zhǔn)備的所有測試用例都要刁鉆。這個(gè)環(huán)節(jié)最多花兩個(gè)小時(shí)但總能趕在上線前揪出一兩個(gè)漏網(wǎng)的“靈異問題”比上線后被用戶發(fā)現(xiàn)要體面得多。