天潤融通Agent實(shí)操指南：獨(dú)立接待率從40%提升到90%
如今，越來越多企業(yè)開始把Agent用在客服場景。
但上線后不少團(tuán)隊很快發(fā)現(xiàn)，同樣是Agent，有的獨(dú)立接待率接近90%，有的卻長期停留在40%～50%。
很多人會先懷疑模型、提示詞或系統(tǒng)能力。
但天潤融通在大量項(xiàng)目復(fù)盤后發(fā)現(xiàn)，問題往往沒那么復(fù)雜：企業(yè)上線了Agent，用的卻還是傳統(tǒng)機(jī)器人時代的FAQ知識庫。
比如，一套知識覆蓋多個產(chǎn)品，一條問答對應(yīng)多個場景。說到底，就是發(fā)動機(jī)升級了，燃料卻沒換。
那么問題就很直接了：企業(yè)應(yīng)該如何才能搭建一套真正面向Agent的知識庫，才能讓Agent的能力真正得以發(fā)揮？
一、為什么傳統(tǒng)FAQ知識庫無法支撐Agent？
要回答這個問題，首先需要弄清楚一件事：為什么傳統(tǒng)FAQ知識庫，在Agent時代反而會成為限制？
很多企業(yè)在上線Agent后，并沒有重新設(shè)計知識體系，而是繼續(xù)沿用過去為文本機(jī)器人構(gòu)建的FAQ結(jié)構(gòu)。但問題恰恰在這里——FAQ從一開始就不是為Agent設(shè)計的。
首先，傳統(tǒng)機(jī)器人是“匹配問題”，但Agent是“判斷場景”。
傳統(tǒng)文本機(jī)器人的工作方式很簡單：用戶提問→關(guān)鍵詞匹配→返回FAQ。
例如用戶問：“門鎖無法開門怎么辦？”系統(tǒng)匹配到“無法開門處理辦法”，然后直接返回答案。整個過程依賴的是問題匹配，而不是理解問題。
但Agent的邏輯完全不同。Agent在處理問題時，需要判斷用戶處于什么場景，分析問題可能的原因，并決定下一步應(yīng)該做什么。它要做的不是回答一句話，而是把問題一步一步處理完。
換句話說，Agent不是回答問題，而是在處理任務(wù)。如果按FAQ的結(jié)構(gòu)，Agent就只能在一堆問答里尋找答案，而無法真正做出判斷。
其次，一套FAQ覆蓋多個產(chǎn)品，很容易導(dǎo)致判斷混亂。
這個問題在在消費(fèi)電子行業(yè)尤其明顯，因?yàn)楹芏嗥髽I(yè)的知識庫結(jié)構(gòu)是：產(chǎn)品線→FAQ。例如智能鎖產(chǎn)品線FAQ，里面同時包含A型號、B型號、C型號等多個產(chǎn)品。
表面上看，問題是一樣的，比如“指紋識別失敗”。但不同型號的設(shè)備，處理方式往往不同。
當(dāng)Agent從這樣一套混合知識中尋找答案時，很容易出現(xiàn)判斷錯誤?；卮鸩粶?zhǔn)確，用戶繼續(xù)追問，系統(tǒng)最終只能轉(zhuǎn)人工。這也是為什么很多企業(yè)上線Agent后，攔截率始終上不去的原因。
最后，F(xiàn)AQ是碎片化知識，無法描述完整場景。
知識庫里可能有很多獨(dú)立問題，例如：如何重置設(shè)備、如何添加指紋、如何連接APP。但真實(shí)用戶的問題，往往不是一個單獨(dú)問題，而是一個完整場景。
例如用戶會說：“我剛買的鎖裝好了，但是APP連不上。”
這背后其實(shí)包含一整個流程：首次安裝→設(shè)備連接→網(wǎng)絡(luò)配置。
如果知識庫只有零散FAQ，Agent很難把這些步驟串起來。結(jié)果就是用戶問一步，機(jī)器人答一步，問題始終沒有被真正解決，體驗(yàn)非常割裂。
二、面向Agent 的知識庫，應(yīng)該如何重新設(shè)計？
如果說FAQ知識庫是為“回答問題”準(zhǔn)備的，那么Agent知識庫是為“處理任務(wù)”準(zhǔn)備的。兩者的結(jié)構(gòu)完全不同。所以，Agent知識庫不是FAQ的升級版，而是一套新的知識體系。
第一步：按產(chǎn)品拆知識
以消費(fèi)電子行業(yè)為例，知識首先要按產(chǎn)品拆開。很多企業(yè)過去是按產(chǎn)品線建知識庫，例如智能鎖一套知識、掃地機(jī)一套知識。但用戶遇到的問題，從來不是“產(chǎn)品線問問題”，而是按具體型號問問題。
而同樣是指紋識別失敗，不同型號的處理方式可能完全不同；同樣是App連不上，不同設(shè)備的配網(wǎng)流程也可能不同。如果一套知識同時覆蓋多個型號，Agent很難判斷應(yīng)該調(diào)用哪條答案。
所以為Agent配置知識庫，知識需要從產(chǎn)品線拆到具體型號。用戶一旦提到型號，Agent就能進(jìn)入對應(yīng)知識域，判斷會穩(wěn)定得多。
第二步：把“問題庫”變成“場景庫”
仍然以消費(fèi)電子場景為例，其FAQ的結(jié)構(gòu)通常是：如何重置設(shè)備、如何添加指紋、如何連接App......每條都是獨(dú)立問題，但真實(shí)用戶遇到的，往往是一個完整場景。
例如：“我剛買的鎖裝好了，但是App連不上。”這背后其實(shí)是一整套流程：首次安裝→設(shè)備連接→網(wǎng)絡(luò)配置。所以Agent知識庫需要按場景組織，比如：
· 首次安裝App
· 連接失敗
· 指紋識別異常
· 設(shè)備電量報警
每個場景不僅包含答案，還要包含排查步驟、處理流程，以及是否需要建單。這樣Agent才能像客服專家一樣，一步一步處理問題。
第三步：知識必須模塊化
除了按產(chǎn)品和場景拆分，知識還需要進(jìn)一步模塊化。因?yàn)锳gent處理問題時，不是返回一條固定FAQ，而是組合不同知識。
例如一個“App連不上”的場景，可能同時需要：
· 產(chǎn)品參數(shù)
· 操作步驟
· 排查流程
· 售后政策
因此知識通常會拆成更小模塊，例如：
· 產(chǎn)品參數(shù)模塊
· 操作步驟模塊
· 排查流程模塊
· 售后政策模塊
Agent可以根據(jù)對話情況動態(tài)組合這些模塊，而不是只返回一條答案。這也是Agent與傳統(tǒng)機(jī)器人的根本區(qū)別：機(jī)器人在找答案，Agent在解決問題。
所以，真正適合Agent的知識庫，不是把FAQ再整理一遍，而是把知識重新拆開、重組，讓它能夠被準(zhǔn)確調(diào)用、靈活組合、持續(xù)維護(hù)。
三、Agent的能力，取決于知識體系是否升級
很多企業(yè)在引入Agent時，最先關(guān)注的是技術(shù)：用哪個大模型、提示詞怎么寫、系統(tǒng)功能是否足夠強(qiáng)。但在實(shí)際落地中，越來越多團(tuán)隊發(fā)現(xiàn)，真正決定Agent效果的，往往不是模型能力，而是知識結(jié)構(gòu)。
如果知識仍然停留在FAQ時代，Agent很難擺脫“問答機(jī)器人”的模式。只有當(dāng)知識體系升級為按產(chǎn)品拆分、按場景組織、按模塊組合，Agent才真正具備處理復(fù)雜服務(wù)問題的能力。
如果你也在思考如何搭建一套真正面向Agent的知識庫，歡迎與我們交流，一起把Agent從“能回答”，變成“能解決”。
轉(zhuǎn)載請在文章開頭和結(jié)尾顯眼處標(biāo)注：作者、出處和鏈接。不按規(guī)范轉(zhuǎn)載侵權(quán)必究。
未經(jīng)授權(quán)嚴(yán)禁轉(zhuǎn)載，授權(quán)事宜請聯(lián)系作者本人，侵權(quán)必究。
本文禁止轉(zhuǎn)載，侵權(quán)必究。
授權(quán)事宜請至數(shù)英微信公眾號(ID: digitaling) 后臺授權(quán)，侵權(quán)必究。
評論
評論
推薦評論
暫無評論哦，快來評論一下吧！
全部評論（0條）