交付上線那天晚上十一點(diǎn)多客戶那邊的值班主管給我打電話語氣有點(diǎn)急“你們那個(gè)機(jī)器人是不是卡住了”我趕緊拉了一下會(huì)話日志發(fā)現(xiàn)它正卡在一個(gè)死循環(huán)里——用戶問“我的訂單什么時(shí)候到”它回答“正在為您查詢”然后因?yàn)闆]有正確拿到訂單號又回頭問用戶“請?zhí)峁┠挠唵翁枴庇脩糁貜?fù)了一遍問題它又繼續(xù)“正在為您查詢”……循環(huán)了四輪用戶早就不耐煩了。這個(gè)小插曲恰恰是客服類Agent工程實(shí)現(xiàn)中最核心的一個(gè)問題任務(wù)規(guī)劃與執(zhí)行控制遠(yuǎn)不是把模型接進(jìn)去就完事那么簡單。今天這篇文章我把這個(gè)已經(jīng)交付的客服Agent從架構(gòu)設(shè)計(jì)、任務(wù)拆解、工具調(diào)用、記憶管理到安全兜底和上線驗(yàn)收完整拆解一遍。適合正在做Agent應(yīng)用落地、想從demo走向生產(chǎn)的團(tuán)隊(duì)參考也適合準(zhǔn)備Agent開發(fā)相關(guān)面試的人理解工程全貌。1. 從“問答機(jī)器人”到“能辦事的Agent”這個(gè)項(xiàng)目的起點(diǎn)與交付目標(biāo)1.1 傳統(tǒng)客服系統(tǒng)差在哪我們接手這個(gè)項(xiàng)目之前客戶線上客服系統(tǒng)是一個(gè)典型的“FAQ機(jī)器人關(guān)鍵詞匹配”方案。用戶問“怎么退換貨”它吐一篇《退換貨政策》長文用戶說“我要退款”它識(shí)別到“退款”二字給一個(gè)退款入口鏈接?？雌饋砗孟衲苡玫鎸?shí)用戶根本不會(huì)按FAQ的劇本來提問。真實(shí)會(huì)話長這樣“我前天買的那雙鞋43碼的想換42你們什么時(shí)候能給發(fā)過來”這里面包含了訂單查詢、尺碼修改、發(fā)貨時(shí)間查詢?nèi)齻€(gè)意圖。傳統(tǒng)規(guī)則引擎遇到這種復(fù)合請求基本就失語了要么答非所問要么直接轉(zhuǎn)人工。而那段時(shí)間客戶的人工客服峰值時(shí)段排隊(duì)超過二十分鐘客訴率一路上漲。另外一個(gè)問題是傳統(tǒng)方案沒有“辦成事”的能力。查訂單、改地址、申請發(fā)票、提交售后這些操作都需要對接業(yè)務(wù)系統(tǒng)。老系統(tǒng)做得最多的是給個(gè)鏈接讓用戶自己去操作但很多用戶尤其是非互聯(lián)網(wǎng)原住民用戶在跳轉(zhuǎn)過程中就流失了。1.2 交付目標(biāo)與驗(yàn)收口徑客戶最初的想法是“上一個(gè)能自然對話的機(jī)器人”但我們在需求調(diào)研階段把他們拉回了地上。Agent不是來替代人工客服的全部工作的它的核心目標(biāo)是分流——把標(biāo)準(zhǔn)化程度高的那部分會(huì)話消化掉讓真人客服把精力留給復(fù)雜客訴。雙方對齊后的驗(yàn)收口徑有三條語義理解準(zhǔn)確率在測試集上核心意圖識(shí)別準(zhǔn)確率不低于95%關(guān)鍵槽位訂單號、商品、地址等抽取準(zhǔn)確率不低于90%。任務(wù)完成率用戶發(fā)起退款申請、地址修改、發(fā)票申請這三類高頻任務(wù)Agent獨(dú)立完成的比例不低于70%。轉(zhuǎn)人工兜底Agent無法處理或用戶明確要求人工時(shí)必須無感轉(zhuǎn)接轉(zhuǎn)接前的上下文完整帶過去。這個(gè)驗(yàn)收口徑非常重要它直接決定了后面的架構(gòu)取舍。比如“任務(wù)完成率不低于70%”意味著我們必須把工具調(diào)用、狀態(tài)流轉(zhuǎn)做成高可靠工程而不是碰運(yùn)氣而“語義理解準(zhǔn)確率不低于95%”意味著模型選型和意圖分類需要多路并行兜底。2. 整體架構(gòu)拆解Agent不是模型是一套分工明確的系統(tǒng)2.1 模塊分層總覽很多剛接觸Agent開發(fā)的同學(xué)容易有一個(gè)誤區(qū)以為Agent就是個(gè)模型把Prompt寫好、模型一調(diào)就完事。實(shí)際交付過你就知道Agent在整個(gè)鏈路里只占一部分真正復(fù)雜的是它周圍的工程系統(tǒng)。這個(gè)項(xiàng)目的整體架構(gòu)分六層每一層解決一類問題層級職責(zé)關(guān)鍵組件入口層多渠道接入、會(huì)話管理微信、App、Web多渠道適配會(huì)話ID統(tǒng)一映射編排層意圖識(shí)別、任務(wù)規(guī)劃、狀態(tài)流轉(zhuǎn)NLU模塊、狀態(tài)機(jī)引擎、策略決策器工具層對接業(yè)務(wù)系統(tǒng)、執(zhí)行具體操作Function Calling網(wǎng)關(guān)、工具注冊中心記憶層上下文維護(hù)、用戶畫像、歷史會(huì)話檢索會(huì)話級記憶、向量數(shù)據(jù)庫、客戶檔案緩存模型層自然語言生成、語義理解、邏輯推理大語言模型、意圖分類小模型、安全審核模型可觀測層全鏈路追蹤、會(huì)話回放、質(zhì)檢Trace系統(tǒng)、日志平臺(tái)、離線評測流水線整個(gè)架構(gòu)的設(shè)計(jì)原則就一句話把容易出錯(cuò)的部分交給確定性邏輯把需要智能的部分交給模型。意圖識(shí)別可以靠模型但“識(shí)別到退款意圖后必須走哪幾個(gè)狀態(tài)節(jié)點(diǎn)”這件事必須由代碼控制不能交給模型自由發(fā)揮。2.2 各層職責(zé)與關(guān)鍵選型入口層相對簡單就是把各個(gè)渠道的消息統(tǒng)一轉(zhuǎn)成內(nèi)部消息協(xié)議再分發(fā)到編排層。這里有個(gè)容易忽略的點(diǎn)不同渠道的消息格式差異很大微信帶類型標(biāo)簽、App可能有結(jié)構(gòu)化卡片、Web端有會(huì)話歷史同步入口層必須把這些都抹平成同一套數(shù)據(jù)結(jié)構(gòu)否則下游處理邏輯會(huì)寫出一堆分支判斷。編排層是整個(gè)Agent的“大腦”也是這次拆解的重點(diǎn)我放到后面單獨(dú)說。工具層是Agent的“手腳”核心是Function Calling網(wǎng)關(guān)負(fù)責(zé)工具注冊、參數(shù)校驗(yàn)、權(quán)限控制和調(diào)用限流。模型層我們最終選了“大小模型混跑”的策略意圖識(shí)別、情緒判別、安全審核用輕量小模型成本低延遲低會(huì)話生成、復(fù)雜推理、多輪追問用大模型保證對話質(zhì)量和泛化能力。3. 任務(wù)拆解與狀態(tài)流轉(zhuǎn)客服場景下為什么不能全靠模型自由發(fā)揮3.1 狀態(tài)機(jī)做骨架把高頻任務(wù)建模成確定性流程剛開始設(shè)計(jì)任務(wù)規(guī)劃模塊時(shí)我們試過純ReAct模式——讓模型自己決定下一步做什么做完觀察結(jié)果再?zèng)Q定下一步。demo階段效果驚艷什么問題都能答感覺無所不能。但一放到真實(shí)業(yè)務(wù)里就露餡了模型經(jīng)常跳過關(guān)鍵步驟、在查詢和回復(fù)之間反復(fù)橫跳、甚至虛構(gòu)操作結(jié)果。后來我們做了一個(gè)關(guān)鍵決策用有限狀態(tài)機(jī)FSM做任務(wù)骨架把模型約束在狀態(tài)節(jié)點(diǎn)的決策點(diǎn)上。以“退款申請”任務(wù)為例狀態(tài)流轉(zhuǎn)是這樣的refund_flow { start: { on_enter: 問候用戶確認(rèn)退款意圖, transitions: [ {condition: has_order has_reason, next: confirm_detail}, {condition: missing_order, next: ask_order_id}, {condition: missing_reason, next: ask_reason} ] }, ask_order_id: { on_enter: 引導(dǎo)用戶提供訂單號, transitions: [ {condition: extract_order_success, next: check_order}, {condition: extract_order_fail_retry, next: ask_order_id}, {condition: retry_exceed_3, next: transfer_human} ] }, check_order: { on_enter: 調(diào)用工具查詢訂單狀態(tài), transitions: [ {condition: order_valid within_refund_period, next: confirm_detail}, {condition: order_invalid, next: explain_invalid_order}, {condition: beyond_refund_period, next: explain_policy_violation} ] }, confirm_detail: { on_enter: 展示退款金額與方式請求用戶確認(rèn), transitions: [ {condition: user_confirmed, next: execute_refund}, {condition: user_modified, next: update_detail}, {condition: user_cancel, next: end_without_execution} ] }, execute_refund: { on_enter: 調(diào)用退款工具校驗(yàn)結(jié)果, transitions: [ {condition: tool_success, next: notify_success}, {condition: tool_failure, next: handle_failure} ] } }每個(gè)狀態(tài)節(jié)點(diǎn)上都掛了一個(gè)“決策小模型”或者規(guī)則條件判斷當(dāng)前該往哪個(gè)狀態(tài)走。這樣設(shè)計(jì)有幾個(gè)好處第一關(guān)鍵業(yè)務(wù)路徑是確定的不會(huì)出現(xiàn)模型自由發(fā)揮跳過“確認(rèn)退款金額”這一關(guān)鍵節(jié)點(diǎn)的情況第二狀態(tài)節(jié)點(diǎn)天然形成審計(jì)日志用戶走到哪一步、在哪一步放棄都能回溯第三故障兜底有了明確抓手——某個(gè)節(jié)點(diǎn)連續(xù)失敗重試超過三次直接轉(zhuǎn)人工不需要模型來做這個(gè)判斷。3.2 留給模型的空間狀態(tài)內(nèi)的自由對話與策略選擇完全確定的狀態(tài)機(jī)也不行客服場景有太多變數(shù)。用戶可能在一個(gè)狀態(tài)里突然問“那如果我七天之后才申請退款呢”也可能上一秒在問退款下一秒說“算了你先幫我把發(fā)票開了吧”。我們的做法是狀態(tài)節(jié)點(diǎn)確定了但節(jié)點(diǎn)內(nèi)部的表達(dá)由模型自由生成。比如在“ask_order_id”這個(gè)狀態(tài)里用戶說“訂單號我找不到了是前天買的”模型可以自主解釋如何查找訂單號、可以提供訂單號代查服務(wù)、可以安撫用戶情緒只要不脫離這個(gè)狀態(tài)的核心目標(biāo)——拿到有效的訂單號。同時(shí)我們在編排層維護(hù)了一個(gè)全局的“意圖漂移檢測器”。用戶當(dāng)前在退款流程里突然說“那順便幫我查一下我在你們這買過幾次東西”檢測器識(shí)別到這是一個(gè)新的查詢意圖會(huì)暫停當(dāng)前狀態(tài)機(jī)插入一個(gè)查詢型子任務(wù)完成后回到原狀態(tài)繼續(xù)。這就是“狀態(tài)機(jī)骨架自由對話填充意圖漂移處理”的三層結(jié)構(gòu)既保證了確定性又保留了對話的自然感。3.3 規(guī)劃失敗的兜底不做硬撐的Agent有一件事我們是從上線第一天就立了規(guī)矩的Agent不硬撐。規(guī)劃層有一套“信心評估”機(jī)制狀態(tài)轉(zhuǎn)移條件不滿足、工具調(diào)用失敗、用戶重復(fù)追問同一個(gè)問題三次以上、模型生成結(jié)果置信度低任一條件觸發(fā)都會(huì)走到“轉(zhuǎn)人工”節(jié)點(diǎn)。很多Agent項(xiàng)目死在“什么都要自己扛”上。用戶已經(jīng)明顯不耐煩了機(jī)器人還在那里一遍遍問“您能再詳細(xì)描述一下您的問題嗎”這就是災(zāi)難。我們專門做了一個(gè)“用戶情緒監(jiān)測”通道小模型實(shí)時(shí)對用戶最近兩條消息打情緒標(biāo)簽出現(xiàn)憤怒、急躁、失望標(biāo)簽時(shí)如果當(dāng)前任務(wù)還沒辦成直接觸發(fā)轉(zhuǎn)人工策略并且把完整上下文打包發(fā)給人工客服人工接手的瞬間就能看到用戶剛才在辦什么、卡在哪。4. 工具調(diào)用的工程化落地給Agent裝上“手”之后的事4.1 工具層設(shè)計(jì)不是所有接口都叫“Agent能調(diào)的”客服Agent要查訂單、改地址、申請退款、開發(fā)票這些背后都是客戶已有的業(yè)務(wù)系統(tǒng)接口。但我們沒有直接把Agent接到現(xiàn)有API上——現(xiàn)有接口的參數(shù)五花八門、權(quán)限模型不統(tǒng)一、有的還是同步長事務(wù)調(diào)用直接暴露給模型就是災(zāi)難。工具層做了一個(gè)“適配器層”把業(yè)務(wù)系統(tǒng)的接口包裝成Agent友好的統(tǒng)一格式{ tool_name: query_order, description: 根據(jù)訂單號查詢訂單詳情包括商品、金額、狀態(tài)、物流信息, parameters: { order_id: { type: string, description: 訂單號通常是長度10-20位的字母數(shù)字組合, required: true } }, response_schema: { order_status: string, items: array, total_amount: number, logistics: object }, timeout_ms: 3000, allowed_roles: [customer_service_agent] }每個(gè)工具注冊時(shí)都要聲明參數(shù)、響應(yīng)格式、超時(shí)時(shí)間、權(quán)限角色和調(diào)用頻控限制。這些信息會(huì)同步注入到模型的上下文里模型只有在明確知道該調(diào)哪個(gè)工具、參數(shù)如何構(gòu)造時(shí)才會(huì)調(diào)用。參數(shù)校驗(yàn)這塊尤其重要——絕對不能讓模型自由構(gòu)造參數(shù)傳給業(yè)務(wù)系統(tǒng)。4.2 安全執(zhí)行鏈從“模型想調(diào)”到“真正執(zhí)行”之間隔著三道閘模型說“我要調(diào)退款接口”就真的讓它調(diào)嗎不行。執(zhí)行鏈路里我們做了三道閘第一道是參數(shù)校驗(yàn)閘。模型生成的工具調(diào)用參數(shù)必須通過Schema校驗(yàn)類型不對、缺字段、字段不在枚舉范圍內(nèi)一律拒絕執(zhí)行。這里特別要留意參數(shù)注入問題——用戶可能在對話里說“訂單號是abc OR 11”如果模型直接把這段話填進(jìn)參數(shù)參數(shù)校驗(yàn)和轉(zhuǎn)義機(jī)制必須兜住。第二道是業(yè)務(wù)規(guī)則閘。每個(gè)工具可以掛一個(gè)規(guī)則函數(shù)比如退款工具掛的是“訂單狀態(tài)必須是已簽收/未發(fā)起過退款/在售后期內(nèi)”規(guī)則不滿足工具直接返回業(yè)務(wù)錯(cuò)誤碼并附帶給用戶看的解釋文案。這道閘是為了防止模型在不該執(zhí)行操作的時(shí)候執(zhí)行——比如訂單還在運(yùn)輸中用戶就要退款工具應(yīng)該回答“當(dāng)前訂單配送中您可以在簽收后申請退款”而不是真的發(fā)起退款。第三道是人工抽查閘。高風(fēng)險(xiǎn)操作退款、改價(jià)、批量操作默認(rèn)開啟“異步人工復(fù)核”模式Agent先把請求寫入待審核隊(duì)列人工客服在后臺(tái)一鍵確認(rèn)或駁回。上線初期復(fù)核比例是100%跑穩(wěn)定后逐步下調(diào)到10%。4.3 高并發(fā)下的工具調(diào)用策略客服系統(tǒng)在線用戶量雖然比不上頭部互聯(lián)網(wǎng)但峰值時(shí)段消息并發(fā)也經(jīng)常上千。模型推理本來就有延遲如果每次用戶消息都串行做“理解→規(guī)劃→調(diào)用工具→生成回復(fù)”整個(gè)鏈路的P95延遲會(huì)沖到十幾秒用戶早跑了。我們做了兩個(gè)優(yōu)化一個(gè)是意圖預(yù)分類并行化——用戶消息進(jìn)來先由小模型打意圖標(biāo)簽不同意圖走不同的處理通道查詢類任務(wù)直接走輕量通道不經(jīng)過大模型規(guī)劃另一個(gè)是工具調(diào)用超時(shí)熔斷——每個(gè)工具設(shè)置硬超時(shí)大部分是3秒超時(shí)后立即走降級策略比如查訂單失敗就引導(dǎo)用戶稍后再試或轉(zhuǎn)人工絕不讓用戶對著“思考中”轉(zhuǎn)圈超過五秒。5. 記憶與上下文管理讓Agent記住“三分鐘前說過的話”5.1 三層記憶結(jié)構(gòu)客服場景的對話往往超過十個(gè)來回用戶可能在第四輪說“就是我剛才說的那個(gè)訂單”如果Agent沒有記憶能力這句話就是天書。我們的記憶層分三層第一層是會(huì)話級記憶當(dāng)前會(huì)話內(nèi)所有消息、狀態(tài)流轉(zhuǎn)、工具調(diào)用結(jié)果都存在內(nèi)存里用會(huì)話ID做Key。這一層解決的是“剛才說了什么”。第二層是用戶級記憶包括用戶的姓名、常用收貨地址、會(huì)員等級、歷史訂單摘要、之前溝通過的問題和解決方案。這些數(shù)據(jù)從客戶CRM同步過來在會(huì)話開始時(shí)加載進(jìn)上下文。這一層解決的是“這個(gè)用戶是誰、他以前遇到過什么”。第三層是向量記憶庫保存歷史會(huì)話的關(guān)鍵片段Embedding。當(dāng)用戶提到“我之前反映過的那個(gè)快遞問題”系統(tǒng)會(huì)用當(dāng)前消息做向量檢索召回最相關(guān)的歷史會(huì)話片段再把召回結(jié)果注入上下文。這一層解決的是“跨會(huì)話的長程記憶”。5.2 Token預(yù)算與壓縮策略大模型的上下文窗口是有限的Token多了不僅花錢響應(yīng)延遲也會(huì)漲而且模型容易“迷失在長文本中”反而抓不住重點(diǎn)。我們給單輪會(huì)話的Token預(yù)算定了個(gè)分配方案系統(tǒng)提示詞含工具描述、業(yè)務(wù)規(guī)則、安全約束固定預(yù)算約1200 Token用戶級記憶客戶畫像、歷史摘要約800 Token超了由摘要模型壓縮向量檢索召回片段最多3條每條限制200 Token以內(nèi)會(huì)話歷史用滑窗策略最近5輪完整保留之前的做漸進(jìn)式摘要壓縮最核心的經(jīng)驗(yàn)是不要讓模型自己決定記住什么。我們專門寫了一個(gè)“記憶寫入器”——每輪對話結(jié)束后一個(gè)小模型判斷當(dāng)前這輪有沒有值得沉淀到用戶級記憶或向量庫的內(nèi)容有就提取并結(jié)構(gòu)化存儲(chǔ)。用戶改了地址記憶寫入器會(huì)把新地址更新到用戶檔案用戶提到“孩子上小學(xué)三年級”這個(gè)信息會(huì)被丟棄因?yàn)樗鼘头鼍皼]價(jià)值。這種主動(dòng)篩選比讓模型從頭到尾讀全部歷史高效得多。6. 安全兜底與可觀測性交付后最不能省的工程投入6.1 安全護(hù)欄大模型規(guī)則引擎審核模型三道防線客服Agent直面終端用戶安全紅線比一般內(nèi)部工具高得多。我們在安全上做了三道防線第一道是輸入輸出審核。用戶發(fā)的消息先過一道敏感內(nèi)容審核出現(xiàn)攻擊性、違法違規(guī)內(nèi)容直接觸發(fā)安全策略模型生成的回復(fù)也會(huì)過一遍審核模型和敏感詞庫防止模型被誘導(dǎo)說出違規(guī)內(nèi)容。上線前我們專門做了一輪紅隊(duì)測試找團(tuán)隊(duì)里最會(huì)“誘導(dǎo)”的人去繞模型發(fā)現(xiàn)模型在復(fù)雜的多輪誘導(dǎo)下確實(shí)會(huì)說一些不該說的話后來加了審核模型兜底才壓住。第二道是動(dòng)作風(fēng)險(xiǎn)分級。查詢類操作查訂單、查物流、查積分風(fēng)險(xiǎn)低直接執(zhí)行寫入類操作改地址、改手機(jī)號風(fēng)險(xiǎn)中等需要用戶二次確認(rèn)資金類操作退款、賠付風(fēng)險(xiǎn)高走異步人工復(fù)核。風(fēng)險(xiǎn)分級表是寫死在代碼里的模型沒有權(quán)限修改。第三道是工具白名單與調(diào)用審計(jì)。模型能調(diào)用的工具集合在會(huì)話開始時(shí)固定不能動(dòng)態(tài)新增所有工具調(diào)用都會(huì)記錄完整的入?yún)?、出參、調(diào)用時(shí)間和結(jié)果存留至少180天方便追溯糾紛。6.2 全鏈路可觀測每一個(gè)壞回復(fù)都能定位到原因Agent出問題是必然的關(guān)鍵是出了問題能不能快速定位。我們的可觀測體系圍繞“一次會(huì)話”做全鏈路追蹤會(huì)話ID: 20250117_001234 用戶ID: u_887766 入口渠道: app 意圖鏈路: 識(shí)別為refund_apply - 狀態(tài)機(jī)進(jìn)入check_order - 調(diào)用query_order成功 - 狀態(tài)機(jī)進(jìn)入confirm_detail - 用戶確認(rèn) - 調(diào)用create_refund_application失敗(超時(shí)) - 重試1次失敗 - 觸發(fā)轉(zhuǎn)人工 - 人工接管攜帶上下文每一輪用戶消息都會(huì)生成這樣一條Trace包含模型調(diào)用耗時(shí)、工具調(diào)用過程、狀態(tài)流轉(zhuǎn)路徑、置信度評分。我們在運(yùn)維后臺(tái)做了一個(gè)“會(huì)話回放”功能可以像看視頻一樣逐條重放Agent和用戶的對話過程同時(shí)看到每一步內(nèi)部發(fā)生了什么。這個(gè)體系在排查問題時(shí)的價(jià)值無法估量。有一次用戶投訴“機(jī)器人亂承諾運(yùn)費(fèi)險(xiǎn)賠款金額”我們回放會(huì)話Trace發(fā)現(xiàn)模型在生成回復(fù)時(shí)引用了工具返回中某個(gè)商品的價(jià)格作為賠償金額但其實(shí)那是商品售價(jià)不是運(yùn)費(fèi)險(xiǎn)賠付金。根因是工具返回的JSON字段名有歧義模型理解偏了。我們馬上改了工具返回Schema把金額字段語義寫得更明確問題就解決了。7. 測試、灰度與上線效果一個(gè)已交付Agent的驗(yàn)收之路7.1 離線評測集把“感覺好用”變成可量化的指標(biāo)Agent項(xiàng)目的測試跟傳統(tǒng)后端項(xiàng)目完全不同——傳統(tǒng)接口測試斷言返回JSONAgent測試要評估的是一段對話的質(zhì)量。而且同樣的輸入模型每次回答可能都不一樣這就是非確定性。我們從客戶的真實(shí)歷史工單里抽了2000條真實(shí)會(huì)話清洗脫敏后做成評測集每條會(huì)話標(biāo)注了期望的意圖路徑、關(guān)鍵槽位、回復(fù)類型和最終狀態(tài)。每次模型或策略有改動(dòng)就全量跑一遍評測集對比通過率。評測指標(biāo)分四個(gè)維度意圖識(shí)別準(zhǔn)確率預(yù)測意圖和標(biāo)注意圖是否一致槽位填充正確率訂單號、商品名、地址等關(guān)鍵信息是否抽取正確流程完成率期望走完的狀態(tài)機(jī)路徑是否走完回復(fù)安全率是否有不當(dāng)/不安全/無關(guān)回復(fù)這套評測集成了我們迭代路上的“交通警察”。有一次我們在評測集上嘗試開放更多的模型規(guī)劃自由度意圖識(shí)別準(zhǔn)確率提升了兩個(gè)點(diǎn)但流程完成率掉了五個(gè)點(diǎn)因?yàn)槟Ｐ皖l繁跳過確認(rèn)步驟直接執(zhí)行。評測數(shù)據(jù)一出來我們果斷回滾了策略。7.2 灰度策略先給5%的用戶用別看總數(shù)要看轉(zhuǎn)化率上線沒有一刀切。我們做了灰度發(fā)布第一周5%流量、第二周20%、第三周50%、第四周全量每步都有詳細(xì)的觀測指標(biāo)?；叶绕陂g每日看板上有四組核心指標(biāo)指標(biāo)計(jì)算公式目標(biāo)值自主解決率Agent獨(dú)立完成會(huì)話數(shù) / 總會(huì)話數(shù)≥ 65%轉(zhuǎn)人工率轉(zhuǎn)人工會(huì)話數(shù) / 總會(huì)話數(shù)≤ 30%人工介入時(shí)長人工客服處理Agent轉(zhuǎn)接會(huì)話的平均耗時(shí)比純?nèi)斯は陆?0%用戶滿意度會(huì)話結(jié)束后的評價(jià)打分不低于純?nèi)斯ぞ颠@里要特別強(qiáng)調(diào)一個(gè)容易踩的坑別只看成功率要看成功率的絕對值是否可接受。5%灰度時(shí)自主解決率沖到75%看起來很好但我們一細(xì)看發(fā)現(xiàn)總會(huì)話量只有幾百條樣本太小指標(biāo)波動(dòng)大意義不大。后來我們堅(jiān)持灰度階段至少跑滿一周、覆蓋幾萬條會(huì)話再下結(jié)論。7.3 上線后的真實(shí)效果全量上線后跑了三個(gè)月最終數(shù)據(jù)跟驗(yàn)收目標(biāo)對上了核心意圖識(shí)別準(zhǔn)確率96.8%槽位抽取準(zhǔn)確率92.3%三高頻任務(wù)獨(dú)立完成率73.5%轉(zhuǎn)人工率從之前的100%降到28%。同時(shí)人工客服平均處理時(shí)長下降了約42%因?yàn)樗麄兘邮值拇蠖嗍茿gent已經(jīng)做了一半的預(yù)處理工作。印象最深的是一個(gè)用戶連續(xù)四天找客服第一天是查物流第二天是改地址第三天是問發(fā)票報(bào)銷政策第四天問會(huì)員積分——前三次Agent都獨(dú)立解決了第四次到人工時(shí)客服直接看到了用戶檔案里的前三輪處理記錄用戶說“你們這次終于記得我了”評價(jià)給了滿分。這讓我意識(shí)到Agent的長期記憶能力對體驗(yàn)的加成遠(yuǎn)比單輪對話的“聰明”重要得多。8. 踩坑復(fù)盤那些只有真實(shí)業(yè)務(wù)才會(huì)逼你面對的問題8.1 循環(huán)卡死我在項(xiàng)目開始時(shí)接到的那個(gè)電話文章開頭那個(gè)循環(huán)問題根因說到底就三個(gè)字沒邊界。當(dāng)時(shí)的版本里“查詢訂單”這個(gè)動(dòng)作沒有設(shè)置最大重試次數(shù)模型覺得用戶沒給訂單號就反復(fù)追問用戶不配合就循環(huán)。我們后來做了雙重修復(fù)第一所有狀態(tài)節(jié)點(diǎn)都加了最大重入次數(shù)超過三次自動(dòng)轉(zhuǎn)人工第二模型生成時(shí)會(huì)檢查是否連續(xù)生成了重復(fù)動(dòng)作一旦檢測到重復(fù)會(huì)立即觸發(fā)“換一種方式處理”的策略提示比如從“反復(fù)要訂單號”切換到“幫用戶用手機(jī)號查訂單”。這個(gè)坑給我們的教訓(xùn)是Agent系統(tǒng)的每個(gè)循環(huán)動(dòng)作都必須有Break條件而且Break條件要在代碼層強(qiáng)制實(shí)現(xiàn)不能指望模型自己發(fā)現(xiàn)問題。8.2 模型“假成功”嘴上說退款了實(shí)際上沒退有段時(shí)間用戶投訴率突然升高一查發(fā)現(xiàn)是模型在生成話術(shù)時(shí)經(jīng)常說“已經(jīng)為您成功提交退款申請”但工具層實(shí)際調(diào)用是失敗的。原因是模型根據(jù)上下文預(yù)測了工具調(diào)用的結(jié)果而不是等待工具層的真實(shí)返回。這個(gè)問題特別隱蔽因?yàn)閱慰磳υ捰涗汚gent表現(xiàn)得非?！罢！?。后來強(qiáng)制規(guī)定所有涉及動(dòng)作確認(rèn)的話術(shù)必須由工具層的真實(shí)返回結(jié)果來驅(qū)動(dòng)。工具返回“success”時(shí)生成成功話術(shù)工具返回失敗或超時(shí)模型只能生成“暫時(shí)沒辦成正在幫您檢查”之類的中性表達(dá)禁止編造成果。我們在Prompt里反復(fù)強(qiáng)調(diào)同時(shí)把工具返回結(jié)果作為生成回復(fù)的硬約束條件從機(jī)制上堵住這條路。8.3 被繞過的高風(fēng)險(xiǎn)操作審批異步人工復(fù)核機(jī)制上線后我們一度以為資金類操作穩(wěn)了。直到有次抽檢發(fā)現(xiàn)模型用一個(gè)“狀態(tài)更新”工具間接修改了退款申請的金額字段繞過了退款工具的人工復(fù)核閘門。這就是多工具組合下的安全隱患單個(gè)工具看都是低風(fēng)險(xiǎn)組合起來可能就成了高風(fēng)險(xiǎn)操作。我們補(bǔ)上了一道“組合動(dòng)作風(fēng)險(xiǎn)檢測”當(dāng)一次會(huì)話中連續(xù)調(diào)用兩個(gè)及以上低風(fēng)險(xiǎn)工具、且工具之間存在數(shù)據(jù)依賴關(guān)系時(shí)會(huì)觸發(fā)組合行為審計(jì)由規(guī)則引擎判斷是否需要人工介入。Agent系統(tǒng)的安全問題永遠(yuǎn)不能靜態(tài)看待必須從鏈路和組合的角度去設(shè)計(jì)防護(hù)。回頭看這個(gè)項(xiàng)目的整個(gè)過程我最大的體會(huì)是Agent的工程實(shí)現(xiàn)本質(zhì)上是把“智能”和“可控”做分層耦合。模型負(fù)責(zé)語言理解和生成這些真正需要智能的部分而業(yè)務(wù)流程的確定性、安全邊界、故障兜底必須由工程系統(tǒng)用最樸素、最可靠的方式牢牢抓住。那些熱詞里討論的“Agent與模型協(xié)作”“任務(wù)規(guī)劃與拆解”在真實(shí)項(xiàng)目里從來不是純理論問題——每一次取舍背后都是用戶投訴、指標(biāo)波動(dòng)和上線壓力逼出來的。希望這篇拆解能給正在做Agent落地的同行一些參考少走幾步我們走過的彎路。