落地企業(yè)級(jí)AI Agent一年最顛覆我認(rèn)知的一點(diǎn)是模型能力從來不是真正的瓶頸。去年年初我們團(tuán)隊(duì)接到一個(gè)任務(wù)——在某制造集團(tuán)內(nèi)部落地企業(yè)級(jí)AI Agent覆蓋客服問答、供應(yīng)鏈協(xié)同、內(nèi)部知識(shí)檢索幾個(gè)方向。立項(xiàng)時(shí)團(tuán)隊(duì)吵得最兇的是模型選型用哪個(gè)開源模型、要不要私有化部署、多少參數(shù)才夠、是否需要領(lǐng)域微調(diào)。當(dāng)時(shí)的氣氛是好像選錯(cuò)模型整個(gè)項(xiàng)目就完了。結(jié)果一年干下來模型選型只花了兩周就定了真正耗盡我們心力、反復(fù)返工、差點(diǎn)讓項(xiàng)目中途夭折的是另外三件跟技術(shù)關(guān)系沒那么大的事。這篇文章不聊模型排行榜也不講各種花哨的Agent框架就用我自己踩過的一年坑聊聊真正攔住企業(yè)AI Agent落地的三件事。如果你正打算在企業(yè)里推Agent或者已經(jīng)在泥潭里掙扎這篇文章應(yīng)該能讓你少走不少彎路。1. 先潑一盆冷水模型不是最難的那一環(huán)1.1 為什么模型反而是最容易解決的部分先說個(gè)反直覺的結(jié)論今天的大模型基礎(chǔ)能力已經(jīng)遠(yuǎn)遠(yuǎn)超過多數(shù)企業(yè)場(chǎng)景的實(shí)際需求。我們當(dāng)時(shí)糾結(jié)了很久的私有化部署和微調(diào)最后只用了通用大模型的API就解決了90%的問題?？头柎稹⒅R(shí)檢索、流程輔助這類的任務(wù)主流模型之間的能力差距遠(yuǎn)沒有營銷號(hào)說得那么夸張業(yè)務(wù)部門根本感知不到你是用哪個(gè)模型支撐的他們只關(guān)心回答準(zhǔn)不準(zhǔn)、快不快、穩(wěn)不穩(wěn)。真正花時(shí)間的是數(shù)據(jù)整理、系統(tǒng)打通、權(quán)限對(duì)接、業(yè)務(wù)流程重構(gòu)以及讓人接受并愿意使用這套東西。這一年我最大的感受是企業(yè)級(jí)AI Agent落地的本質(zhì)是系統(tǒng)改造工程不是AI工程。一個(gè)Agent要在企業(yè)里穩(wěn)定跑起來至少要同時(shí)打通數(shù)據(jù)層、應(yīng)用層、組織層三層障礙數(shù)據(jù)層是原料應(yīng)用層是通道組織層是燃料。任何一層出問題Agent的表現(xiàn)都會(huì)非常拉胯。1.2 真正的戰(zhàn)場(chǎng)在企業(yè)內(nèi)部單獨(dú)看每一層好像都不算前沿技術(shù)但疊在一起就變成了一個(gè)極其復(fù)雜的系統(tǒng)問題。數(shù)據(jù)層的坑是歷史包袱重各個(gè)業(yè)務(wù)系統(tǒng)的數(shù)據(jù)格式、質(zhì)量、口徑都不一樣應(yīng)用層的坑是傳統(tǒng)企業(yè)系統(tǒng)封閉API能力弱權(quán)限模型復(fù)雜組織層的坑是預(yù)期管理難老板想要全自動(dòng)替代人一線員工害怕被替代中層管理擔(dān)心失控。這三個(gè)層面哪個(gè)最難以我的實(shí)際經(jīng)驗(yàn)排序最難的是數(shù)據(jù)其次是組織然后是系統(tǒng)集成。模型本身反而是最簡(jiǎn)單的。我見過很多團(tuán)隊(duì)把大量預(yù)算花在買更大的模型算力上結(jié)果上線后發(fā)現(xiàn)回答內(nèi)容完全正確但用戶根本用不起來因?yàn)閿?shù)據(jù)源沒接對(duì)或者業(yè)務(wù)流沒走通。方向從一開始就偏了。2. 第一件事企業(yè)數(shù)據(jù)的臟亂差才是Agent的隱形天花板2.1 數(shù)據(jù)孤島每個(gè)系統(tǒng)都是一座城堡我們的第一個(gè)場(chǎng)景是客服問答。當(dāng)時(shí)覺得這個(gè)場(chǎng)景簡(jiǎn)單把產(chǎn)品手冊(cè)、FAQ、歷史工單喂給Agent做一個(gè)內(nèi)部客服助手一線客服人員輸入問題就能秒回。產(chǎn)品手冊(cè)有現(xiàn)成的PDFFAQ有現(xiàn)成的文檔歷史工單在CRM系統(tǒng)里一切看起來都好辦。結(jié)果一開工就傻眼了。這些數(shù)據(jù)分散在至少四套系統(tǒng)里ERP、CRM、工單系統(tǒng)、共享盤。每套系統(tǒng)的數(shù)據(jù)結(jié)構(gòu)完全不一樣CRM里的客戶信息和ERP里的訂單信息用的是兩套客戶編碼工單系統(tǒng)的分類標(biāo)簽跟FAQ里的分類對(duì)不上。最折磨人的是這些系統(tǒng)之間還沒有打通有的靠人工導(dǎo)出Excel再導(dǎo)入另一個(gè)系統(tǒng)有的干脆就是各記各的。做知識(shí)檢索的同學(xué)應(yīng)該能理解這個(gè)痛苦你辛辛苦苦做了向量化、建立了索引結(jié)果發(fā)現(xiàn)數(shù)據(jù)源頭就是臟的、斷的。Agent檢索出來一段正確的文字順著引用去核對(duì)原始單據(jù)發(fā)現(xiàn)對(duì)不上號(hào)。這種問題模型解決不了只能靠人一層層去梳理、清洗、對(duì)齊。2.2 數(shù)據(jù)質(zhì)量口徑不一致會(huì)把Agent帶偏數(shù)據(jù)質(zhì)量問題比孤島問題更隱蔽。我們做供應(yīng)鏈協(xié)同場(chǎng)景的時(shí)候需要Agent根據(jù)歷史訂單數(shù)據(jù)輔助生成采購建議。剛開始測(cè)試效果很好但在小范圍試運(yùn)行的時(shí)候業(yè)務(wù)人員提出一個(gè)質(zhì)疑Agent給的數(shù)據(jù)跟財(cái)務(wù)部門統(tǒng)計(jì)的差了一大截。排查了半天原因是兩個(gè)部門對(duì)訂單金額的口徑定義不一致。業(yè)務(wù)部門說的訂單金額是含稅金額財(cái)務(wù)部門用的是凈額兩個(gè)數(shù)之間差了13%的稅點(diǎn)。Agent不知道這個(gè)背景它只是忠實(shí)地把數(shù)據(jù)取出來、算出來結(jié)果就錯(cuò)了。這個(gè)錯(cuò)誤如果模型來背鍋那真是冤枉了模型根子在于企業(yè)自身的指標(biāo)體系長期沒有拉齊。這類口徑問題在企業(yè)里比比皆是銷售額是含稅還是不含稅、庫存是實(shí)時(shí)庫存還是日結(jié)庫存、交付周期按自然日還是工作日算。任何一個(gè)沒對(duì)齊Agent給出的答案就是錯(cuò)的。而且這種錯(cuò)非常隱蔽因?yàn)樗皇敲黠@的事實(shí)錯(cuò)誤而是在特定業(yè)務(wù)語境下才看得出端的數(shù)值偏差業(yè)務(wù)部門對(duì)AI的信任感會(huì)因?yàn)檫@類錯(cuò)誤大打折扣。2.3 知識(shí)更新靜態(tài)知識(shí)庫上線三個(gè)月就發(fā)臭數(shù)據(jù)工程還有一個(gè)常被忽略的點(diǎn)知識(shí)是活的而知識(shí)庫是死的。我們上線客服助手時(shí)精心整理了三千多篇產(chǎn)品文檔和常見問題做得很細(xì)效果也滿意。結(jié)果上線三個(gè)月后產(chǎn)品部門發(fā)了一個(gè)新版本新增了好幾個(gè)功能修改了部分舊功能的使用方式。我們的知識(shí)庫沒有同步更新于是Agent開始一本正經(jīng)地按照舊版本文檔回答問題給出的操作步驟在新版本里根本不存在。更麻煩的是企業(yè)知識(shí)更新的節(jié)奏完全不可控。產(chǎn)品手冊(cè)可能會(huì)在月底更新價(jià)格表可能每周都在變庫存政策說調(diào)就調(diào)。我們的知識(shí)管線一開始是每周手動(dòng)更新一次后來被業(yè)務(wù)方反復(fù)投訴信息太舊才被迫做成自動(dòng)化。這里我想強(qiáng)調(diào)一個(gè)觀點(diǎn)企業(yè)級(jí)Agent的知識(shí)庫必須當(dāng)成一個(gè)持續(xù)運(yùn)轉(zhuǎn)的流水線來建設(shè)而不是一次性交付的靜態(tài)資產(chǎn)。要有數(shù)據(jù)接入的接口、定期更新的調(diào)度、變更日志的記錄最好還能對(duì)上線的Agent做知識(shí)版本回溯否則出了錯(cuò)你都不知道是哪份舊文檔害的。我推薦的做法是把知識(shí)管理前置到信息產(chǎn)生源頭。比如讓產(chǎn)品部門在發(fā)布文檔時(shí)同時(shí)推送一份結(jié)構(gòu)化版本給知識(shí)庫而不是等Agent團(tuán)隊(duì)自己去爬去抓。這需要流程上的協(xié)同但能省掉后面大量的維護(hù)返工。2.4 評(píng)測(cè)集沒有標(biāo)尺就談不上優(yōu)化再聊一個(gè)很多團(tuán)隊(duì)都會(huì)忽略的環(huán)節(jié)評(píng)測(cè)集建設(shè)。我們一開始評(píng)估Agent效果全靠產(chǎn)品經(jīng)理和業(yè)務(wù)方拿幾個(gè)典型問題試覺得回答得不錯(cuò)就算過。后來發(fā)現(xiàn)這種方式極度不可靠因?yàn)闃I(yè)務(wù)人員隨手問的問題通常都是他們熟悉的問題Agent回答對(duì)了說明不了什么換個(gè)真實(shí)的用戶來問各種千奇百怪的說法、上下文缺失、錯(cuò)別字Agent的表現(xiàn)立刻回落。后來我花了一個(gè)月時(shí)間拉著業(yè)務(wù)方一起從歷史工單里抽了八千多條真實(shí)用戶問題逐條清洗、打標(biāo)、歸類做成了一套分場(chǎng)景的評(píng)測(cè)集。每個(gè)場(chǎng)景又分三個(gè)難度級(jí)別直問直答型的簡(jiǎn)單題、需要多輪澄清的難題、需要跨系統(tǒng)整合資料的超難題。Agent每次更新都要在這套評(píng)測(cè)集上跑一遍給出準(zhǔn)確率、完整率、過時(shí)回答率三個(gè)指標(biāo)任何一次變更都能量化影響。這件事是枯燥的、非技術(shù)性的、看不到即時(shí)效果的但它決定了Agent能不能持續(xù)迭代。沒有一套可靠的評(píng)測(cè)集你后續(xù)所有的prompt調(diào)優(yōu)、RAG優(yōu)化、工具調(diào)用配置都是閉著眼睛開車撞了也不知道撞在哪里。3. 第二件事Agent要嵌進(jìn)業(yè)務(wù)流程而不是掛在旁邊當(dāng)擺設(shè)3.1 從問答機(jī)器人到流程參與者的安排采購部經(jīng)理跟我講了一句讓我印象很深的話我要的不是一個(gè)幫我查庫存的機(jī)器人我要的是一個(gè)在我提采購申請(qǐng)的同時(shí)幫我自動(dòng)核對(duì)庫存、檢查預(yù)算、生成采購單草稿的助手。這句話點(diǎn)醒了我。企業(yè)Agent的價(jià)值不在回答而在辦成事。你問客服助理這個(gè)訂單現(xiàn)在什么狀態(tài)它告訴你已發(fā)貨這是回答沒有解決任何問題但如果你跟它說幫我查查最近一周延遲發(fā)貨超過三天的訂單并給客戶生成一封致歉郵件草稿它在回答之外還能動(dòng)手操作這才是業(yè)務(wù)真正需要的。所以第二個(gè)核心難點(diǎn)來了Agent必須嵌入到真實(shí)的業(yè)務(wù)流程里成為流程中的一個(gè)參與者而不是懸浮在旁邊的問答面板。我們做的第一個(gè)真正意義上的流程型Agent是訂單取消審批助手。原來客戶申請(qǐng)取消訂單客服需要先查訂單狀態(tài)、判斷是否允許取消、再找主管審批、審批通過后在系統(tǒng)里做取消操作整個(gè)鏈條平均耗時(shí)四十多分鐘。Agent介入后自動(dòng)完成前面兩步并生成一個(gè)帶判斷依據(jù)的審批摘要主管只需要看摘要點(diǎn)同意或者否決。這個(gè)流程改造不復(fù)雜涉及的工具也不高大上但就是把Agent從場(chǎng)內(nèi)嘉賓變成了場(chǎng)上球員。3.2 權(quán)限模型必須復(fù)用企業(yè)原有的那一套流程型Agent帶來了一個(gè)此前沒有遇到的問題權(quán)限。問答機(jī)器人不需要權(quán)限控制它回答的內(nèi)容都是公開知識(shí)但流程型Agent要操作訂單、讀客戶信息、改工單狀態(tài)這就必須嚴(yán)格控制權(quán)限。我在這里吃過大虧。早期我們圖省事給Agent配了一個(gè)服務(wù)賬號(hào)權(quán)限范圍設(shè)置得很寬結(jié)果一個(gè)普通客服在對(duì)話里讓Agent調(diào)用導(dǎo)出全部客戶聯(lián)系方式的工具Agent憑服務(wù)賬號(hào)的權(quán)限真的做到了。雖然當(dāng)時(shí)只是測(cè)試環(huán)境但這件事讓我驚出一身冷汗。企業(yè)級(jí)Agent的權(quán)限模型必須遵循最小權(quán)限原則并且最好復(fù)用企業(yè)已有的統(tǒng)一身份認(rèn)證和權(quán)限體系而不是另起爐灶。我們最終的做法是用戶通過企業(yè)現(xiàn)有的身份系統(tǒng)登錄Agent在調(diào)用任何工具或讀取任何數(shù)據(jù)時(shí)都帶上用戶的身份上下文后端接口統(tǒng)一校驗(yàn)用戶是否有權(quán)做這個(gè)操作。也就是Agent只是一個(gè)執(zhí)行者它永遠(yuǎn)不能獲得超越當(dāng)前用戶身份的權(quán)限。用戶無權(quán)的操作Agent也必須拒絕。這樣一來權(quán)限規(guī)則、審計(jì)日志都能跟企業(yè)現(xiàn)有體系對(duì)齊安全合規(guī)部門才敢放行。3.3 老系統(tǒng)的API遠(yuǎn)比你想象的脆弱就算權(quán)限解決了還有另外一個(gè)攔路虎老系統(tǒng)的接口質(zhì)量。我們集團(tuán)里有一套用了十多年的訂單系統(tǒng)技術(shù)棧陳舊沒有REST接口只支持SOAP協(xié)議而且接口文檔早就過時(shí)了。我們的Agent要查詢訂單狀態(tài)只能通過中間服務(wù)去轉(zhuǎn)換協(xié)議、適配字段中間任何一步出錯(cuò)整個(gè)鏈路都會(huì)卡住。更麻煩的是老系統(tǒng)的穩(wěn)定性。有一個(gè)接口平均每調(diào)用十次就要超時(shí)一次Agent又不會(huì)自動(dòng)重試或者在等待超時(shí)的時(shí)候卡住了。用戶體驗(yàn)就是問Agent一個(gè)問題轉(zhuǎn)了十秒鐘沒反應(yīng)最后報(bào)錯(cuò)服務(wù)暫時(shí)不可用。業(yè)務(wù)部門只會(huì)覺得你這個(gè)AI系統(tǒng)很爛他們不會(huì)理解是老系統(tǒng)接口不穩(wěn)定。我的經(jīng)驗(yàn)是接入老系統(tǒng)時(shí)必須增加一個(gè)中間適配層負(fù)責(zé)協(xié)議轉(zhuǎn)換、字段映射、超時(shí)控制、重試機(jī)制、降級(jí)策略。在Agent本身的設(shè)計(jì)上也要給工具調(diào)用設(shè)置合理的超時(shí)時(shí)間超時(shí)后能自動(dòng)走備用路徑或者給出友好提示而不是一直傻等或者崩潰。3.4 多Agent協(xié)作與異常降級(jí)方案場(chǎng)景越復(fù)雜越不能指望一個(gè)Agent從頭干到尾。我們是逐步引入多Agent協(xié)作的比如在客服場(chǎng)景里拆成意圖識(shí)別Agent、業(yè)務(wù)查詢Agent、郵件撰寫Agent三個(gè)角色每個(gè)Agent負(fù)責(zé)一個(gè)環(huán)節(jié)通過一個(gè)簡(jiǎn)單的編排器串聯(lián)。但多Agent編排帶來一個(gè)新的問題錯(cuò)誤傳播。前一個(gè)Agent識(shí)別錯(cuò)了意圖后續(xù)所有環(huán)節(jié)都會(huì)跟著錯(cuò)而且錯(cuò)誤會(huì)被層層放大。比如意圖識(shí)別本來是退款咨詢結(jié)果被識(shí)別成投訴處理后面生成的郵件語氣和模板完全不對(duì)。我的建議是多Agent編排要從兩個(gè)維度做防護(hù)。一是每個(gè)Agent的輸出都要有獨(dú)立的校驗(yàn)節(jié)點(diǎn)識(shí)別Agent的輸出要經(jīng)過業(yè)務(wù)規(guī)則的校驗(yàn)不能直接透?jìng)鹘o下一個(gè)環(huán)節(jié)二是編排器要設(shè)計(jì)降級(jí)路徑某個(gè)Agent不可用時(shí)是走備用Agent還是降級(jí)到人工處理這個(gè)預(yù)案要在系統(tǒng)設(shè)計(jì)階段就定好不要上線后再補(bǔ)。4. 第三件事人的問題比技術(shù)更難解決4.1 老板的預(yù)期管理技術(shù)團(tuán)隊(duì)跟老板之間對(duì)AI Agent的預(yù)期幾乎從來不在一個(gè)頻道上。老板想看的是成本下降多少、人力節(jié)省幾個(gè)、審批周期縮短幾天技術(shù)團(tuán)隊(duì)關(guān)心的是準(zhǔn)確率提升幾個(gè)點(diǎn)、響應(yīng)速度優(yōu)化到幾秒。這兩個(gè)維度不是不能對(duì)齊就怕老板在項(xiàng)目啟動(dòng)初期就抱有不切實(shí)際的幻想。我們項(xiàng)目進(jìn)行到第三個(gè)月的時(shí)候大老板問了句這個(gè)Agent上線之后客服團(tuán)隊(duì)能不能裁掉一半當(dāng)時(shí)會(huì)議室里空氣凝固了。我沒有直接說不能而是拉了一組數(shù)據(jù)給他看現(xiàn)有客服工作量里真正能被Agent自動(dòng)化的部分大概占百分之三十剩下百分之七十涉及談判、安撫、復(fù)雜判斷Agent只是輔助提效而不是替代。這次對(duì)話之后我專門整理了一份Agent能力邊界的說明文檔用具體場(chǎng)景列出哪些能做、哪些做不了、哪些有條件做并跟管理層達(dá)成了幾條共識(shí)Agent先做提效工具不做替代工具上線的指標(biāo)按處理時(shí)長縮短、一次解決率提升來度量不按減了多少人頭來度量。這一步至關(guān)重要否則項(xiàng)目大概率會(huì)因?yàn)轭A(yù)期落空而中途夭折。4.2 一線員工的不信任和使用阻力如果說老板的預(yù)期是自上而下的壓力那一線員工的不信任就是自下而上的阻力。我們?cè)诳头F(tuán)隊(duì)推廣Agent助手的時(shí)候遇到的最典型反應(yīng)是他們覺得這東西就是要來監(jiān)控他們的或者遲早要頂替他們所以態(tài)度上很抵觸不愿意用甚至故意不用。有一個(gè)客服主管私下跟我們說她知道Agent能幫組員省很多事但她不敢讓組員太依賴Agent怕大家的業(yè)務(wù)能力退化。這個(gè)想法非常真實(shí)也很普遍。后來我們改變了推廣策略不再強(qiáng)調(diào)Agent能替代多少重復(fù)勞動(dòng)而是強(qiáng)調(diào)它能解放員工去做更有價(jià)值的溝通并且把Agent的錯(cuò)題集開放給客服團(tuán)隊(duì)看讓他們知道系統(tǒng)不是萬能的、人工判斷依然重要反而降低了對(duì)AI的戒心。另外我們還做了一件很關(guān)鍵的事讓一線員工參與到Agent的優(yōu)化反饋閉環(huán)里。系統(tǒng)每兩周根據(jù)他們的意見更新一批問題的答案并在群里公布這是采納了誰的建議。當(dāng)員工發(fā)現(xiàn)自己的反饋真的能改變系統(tǒng)的行為時(shí)抵觸情緒會(huì)大幅下降甚至?xí)鲃?dòng)幫系統(tǒng)挑毛病。4.3 持續(xù)運(yùn)營機(jī)制和Owner意識(shí)很多AI項(xiàng)目死在從項(xiàng)目到產(chǎn)品的過渡期。項(xiàng)目階段有專門的小組、有明確的責(zé)任人、有里程碑上線之后就作鳥獸散沒有一個(gè)人為Agent的長期效果負(fù)責(zé)。我們的Agent上線后也遇到了這個(gè)真空期知識(shí)庫沒人更新、業(yè)務(wù)規(guī)則變了沒人同步給Agent、用戶反饋沒人去看。后來集團(tuán)層面指定了一個(gè)數(shù)字化運(yùn)營團(tuán)隊(duì)作為Agent的長期Owner明確職責(zé)包括知識(shí)庫日常維護(hù)、指標(biāo)監(jiān)控、用戶反饋處理、定期復(fù)盤。同時(shí)建立了每月一次的Agent運(yùn)營例會(huì)業(yè)務(wù)方、技術(shù)方、運(yùn)營方三方到場(chǎng)看數(shù)據(jù)、過反饋、定優(yōu)先級(jí)。這套機(jī)制運(yùn)轉(zhuǎn)起來之前Agent的體驗(yàn)是逐月下降的運(yùn)轉(zhuǎn)起來之后慢慢開始逐月回升。4.4 落地節(jié)奏的把握最后一個(gè)心得是節(jié)奏。我強(qiáng)烈建議不要一口氣上太多場(chǎng)景。我們一開始想做六個(gè)場(chǎng)景后來被現(xiàn)實(shí)教育得老老實(shí)實(shí)砍到兩個(gè)客服助手和訂單審批助手。先把這兩個(gè)場(chǎng)景做到業(yè)務(wù)方愿意主動(dòng)用再逐步擴(kuò)張。每擴(kuò)張一個(gè)場(chǎng)景都要完成一次完整的數(shù)據(jù)梳理、接口適配、權(quán)限配置、評(píng)測(cè)集搭建、業(yè)務(wù)方宣導(dǎo)的閉環(huán)。擴(kuò)張?zhí)斓暮蠊沂怯H身體驗(yàn)過的多個(gè)場(chǎng)景同時(shí)上線運(yùn)維壓力巨大出問題找不到對(duì)應(yīng)負(fù)責(zé)人業(yè)務(wù)方抱怨聲此起彼伏差點(diǎn)把整個(gè)項(xiàng)目拖垮。慢一點(diǎn)穩(wěn)一點(diǎn)做一個(gè)成一個(gè)這種節(jié)奏在企業(yè)級(jí)AI落地里反而最快。5. 常見問題與排查技巧實(shí)錄5.1 知識(shí)庫檢索不準(zhǔn)這是RAG類應(yīng)用最經(jīng)典的問題。排查思路是先分階段定位是知識(shí)庫里沒有這段內(nèi)容還是有但沒檢索出來還是檢索出來了但Agent沒采用。我們經(jīng)常遇到的情況是知識(shí)庫里明明有標(biāo)準(zhǔn)答案Agent卻回答得偏了。后來發(fā)現(xiàn)是檢索到的片段不夠完整或者多個(gè)片段拼接時(shí)語義斷裂導(dǎo)致了歧義。解決方向包括優(yōu)化切分策略按章節(jié)、按語義單元切而不是按固定字?jǐn)?shù)切加大檢索召回?cái)?shù)量讓大模型在更多候選中做判斷對(duì)高頻問題做別名映射把用戶口語化的說法映射到標(biāo)準(zhǔn)術(shù)語上。還有一個(gè)容易被忽略的點(diǎn)是企業(yè)知識(shí)庫里很多文檔有多個(gè)版本檢索時(shí)一定要把版本信息也拼接給模型否則它很容易把舊版內(nèi)容當(dāng)代答。5.2 Agent一本正經(jīng)地胡說八道幻覺問題是繞不開的。我們的經(jīng)驗(yàn)是在流程型Agent里幻覺帶來的風(fēng)險(xiǎn)遠(yuǎn)比問答型Agent大。比如Agent自動(dòng)生成的訂單取消理由、審批摘要如果編造一個(gè)真實(shí)系統(tǒng)里不存在的編號(hào)那產(chǎn)生的后果是無法挽回的。治理幻覺不能只靠prompt提示不要編造更可靠的是做事實(shí)約束。我們的做法是所有涉及系統(tǒng)數(shù)據(jù)的字段必須通過工具調(diào)用從數(shù)據(jù)庫取到后拼接在上下文里禁止模型憑記憶直接生成對(duì)關(guān)鍵編號(hào)、金額等等字段在生成后還要加一道后置校驗(yàn)與數(shù)據(jù)源比對(duì)不一致就強(qiáng)制返回以數(shù)據(jù)源為準(zhǔn)。這套工具取數(shù)后置校驗(yàn)的雙保險(xiǎn)把流程型Agent的幻覺率降到了千分之一以下。5.3 響應(yīng)速度慢業(yè)務(wù)部門不買單Agent如果每次響應(yīng)要等十幾秒業(yè)務(wù)部門用幾天就會(huì)拋棄。性能優(yōu)化的優(yōu)先級(jí)應(yīng)該是先查鏈路瓶頸再談模型加速。我們碰到過一個(gè)卡點(diǎn)是Agent每次對(duì)話都要同步調(diào)用一個(gè)慢接口后來改成預(yù)熱緩存、異步刷新把單次響應(yīng)從十二秒壓到了四秒。如果你用的是大模型API可以考慮引入語義緩存對(duì)完全相同或者高度相似的問題走緩存應(yīng)答不走模型調(diào)用。我們的客服場(chǎng)景里大概有百分之三十的問題是重復(fù)的語義緩存上線后整體響應(yīng)速度和費(fèi)用都降了一大截。5.4 用戶覺得不如原來方便這個(gè)問題很扎心但也很常見。老系統(tǒng)的確難用但老用戶已經(jīng)習(xí)慣了Agent功能雖然先進(jìn)用戶要改變使用習(xí)慣天然有轉(zhuǎn)換成本。我們的解決辦法是在設(shè)計(jì)上盡量貼近原有的操作路徑不做顛覆式改變。比如客服原來要在工單系統(tǒng)里逐條填字段Agent助手就在工單頁面上做一個(gè)智能填充按鈕用戶點(diǎn)一下就自動(dòng)填好大部分字段然后人工確認(rèn)修改。這種漸進(jìn)增強(qiáng)比直接塞一個(gè)新對(duì)話框更容易被接受。6. 一年落地實(shí)踐的心得回頭看看這一年如果讓我用一個(gè)詞概括企業(yè)級(jí)AI Agent落地的核心那就是工程化三個(gè)字。Agent框架真是五花八門模型能力也早就夠用了但一個(gè)能在企業(yè)里穩(wěn)定運(yùn)行、業(yè)務(wù)方愿意用、老板覺得有價(jià)值的Agent背后是大量數(shù)據(jù)治理、流程梳理、權(quán)限適配、預(yù)期管理、運(yùn)營機(jī)制這類不起眼的工作。我個(gè)人覺得企業(yè)AI Agent落地的過程實(shí)際上是企業(yè)數(shù)字化成熟度的一次全面體檢。你以為是來搞AI的做著做著發(fā)現(xiàn)是在補(bǔ)數(shù)字化的課數(shù)據(jù)不干凈、系統(tǒng)不開放、流程不標(biāo)準(zhǔn)、組織不配合這些問題統(tǒng)統(tǒng)暴露出來。Agent就像一面鏡子把企業(yè)原本被掩蓋的內(nèi)部矛盾全照出來了。如果你正在推進(jìn)類似的項(xiàng)目我的建議是從第一天起就把精力重新分配一下花在模型上的心思控制在極其有限的范圍內(nèi)把更多時(shí)間放去摸清數(shù)據(jù)家底、理解業(yè)務(wù)流程、說服組織里的關(guān)鍵人。這三件事看著不如調(diào)模型那么過癮卻是決定項(xiàng)目能不能走下去的根本。前陣子有同行問我做了一年企業(yè)級(jí)AI Agent最大的感悟是什么。我說就一句模型負(fù)責(zé)聰明而數(shù)據(jù)、流程和人決定了一個(gè)聰明的模型在企業(yè)里能不能真正干活。這句話夠我再用幾年。