跳至主要内容

從 SkillForge 看微語下一步：面向企業客服的自進化 Agent Skills

· 閱讀時間約 11 分鐘
Jack Ning
Jack Ning
Maintainer of Bytedesk

最近讀到一篇很值得做企業客服產品的人認真看的論文：SkillForge: Forging Domain-Specific, Self-Evolving Agent Skills in Cloud Technical Support。它討論的不是泛泛的「大模型更強了」，而是一個更落地的問題：當 Agent 真正進入企業技術支援、客服、工單、診斷這些高要求場景後，如何持續把「技能」做對、做穩、做深。

這篇論文給出的答案很直接：不要只盯著模型本身，而要把 Agent Skill 當成一個可版本化、可診斷、可優化的資產，圍繞它建立「建立 - 執行 - 評估 - 診斷 - 優化」的閉環。

對微語來說，這個方向非常有價值。因為微語本身已經具備多模型接入、知識庫檢索、機器人路由、工作流配置、人工接管這些基礎能力，下一步真正拉開差距的，不會只是「接了多少模型」，而是誰能先把客服機器人做成一個會自我沉澱、會利用失敗持續進化的系統。

這篇論文到底解決了什麼問題​

SkillForge 聚焦的是企業級雲端技術支援場景，但它的核心矛盾和客服系統高度相似。

論文認為，企業 Agent 往往會遇到兩個長期問題：

  • 初始技能寫得不夠貼近業務。通用的 Skill Creator 不理解企業內部知識、歷史工單、工具鏈和處理流程，所以生成出來的技能容易空泛。
  • 技能上線後不會真正成長。線上每天都會累積失敗樣本，但很多系統並沒有把這些失敗系統性地追溯到技能缺陷，再回寫到技能定義裡。

這也是很多 AI 客服專案「展示很好看，生產越跑越虛」的根源。模型能力也許夠強，但真正約束回答品質的，往往是領域知識、澄清策略、工具調用方式、回覆風格，以及這些能力有沒有隨著線上回饋持續修正。

SkillForge 的核心方法​

論文把 Agent Skill 當成一個可進化的軟體資產。它的核心流程可以概括為五步。

1. 用領域上下文生成初始技能​

不是拿一個通用模板直接寫 SKILL.md，而是先從三類材料中抽取上下文：

  • 歷史工單
  • 技術文件或知識庫
  • 人工專家常用工具與解決流程

然後再生成更貼近業務的初始技能。論文把這一層叫做 Domain-Contextualized Skill Creator。

2. 在線執行並持續收集壞樣本​

Agent 在真實任務中使用當前版本技能執行。只要發現輸出與專家參考答案不一致，或者人工沒有採用，就把這個 case 標記為 bad case。

這一步非常關鍵。因為自進化的起點不是「繼續調 prompt」，而是先持續穩定地定義和收集失敗。

3. 對失敗做多維歸因​

SkillForge 不是簡單地把失敗歸因為「模型答錯了」，而是拆成四個維度去分析：

  • Knowledge：知識缺失、知識錯誤、知識衝突
  • Tool：工具沒調、參數錯、結果理解錯
  • Clarification：該追問沒追問、不該追問卻追問、追問方向偏了
  • Style：語氣生硬、冗長、過冷、不符合客服場景

這一步的價值在於，它把「壞回答」變成了結構化缺陷，而不是一句抽象的「效果不好」。

4. 把失敗映射回技能定義​

論文裡的 Skill Diagnostician 會讀取壞樣本聚合報告和當前 SKILL.md，把問題具體定位到技能內容本身。

例如：

  • 某類 FAQ 總是漏關鍵前置條件，說明故障排查步驟不完整
  • 某類工單總是少調一個內部工具，說明工具調用規則沒寫清楚
  • 某類場景下回覆太機械，說明風格要求或優先級不明確

這一步把線上效果問題，轉成了「應該修改技能的哪一段」。

5. 只做最小必要修改，生成下一版技能​

Skill Optimizer 根據診斷報告修改 SKILL.md 和 references，生成新版本技能，然後進入下一輪執行。

論文特別強調兩點：

  • 盡量只做最小修改，避免破壞已有正確行為
  • 整個技能資產要可追蹤、可版本化、可回滾

這其實已經非常接近現代軟體工程思路，而不只是提示詞工程。

為什麼這件事對微語尤其重要​

微語不是一個單點聊天機器人，而是一個同時覆蓋訪客端、客服端、知識庫、工單、工作流、音視訊和企業接入場景的客服系統。系統越複雜，AI 能力越不能只靠一個「大模型回答介面」來支撐。

從目前程式碼能力看，微語已經具備幾塊很重要的基礎。

1. 已有多模型與多供應商接入能力​

在模型供應商配置裡，微語已經支援 OpenAI、Anthropic、Gemini、DeepSeek、通義、OpenRouter、Dify、n8n、Ragflow 等多個供應商。這意味著微語已經具備「技能運行時可切換模型底座」的基礎，不需要從零開始設計模型抽象。

2. 已有知識庫檢索與 LLM 拼接鏈路​

目前機器人回答鏈路已經支援知識庫搜尋結果聚合，並把 FAQ 檢索結果轉成上下文交給 LLM。也就是說，論文裡「Domain Context」最核心的一塊，微語並不缺，只是今天它主要還是停留在「回答時注入知識」，還沒有進一步沉澱成版本化的技能資產。

3. 已有機器人路由與人工兜底機制​

工作組側已經具備「是否轉機器人」「離線時是否優先備選人工／備選工作組」「強制轉人工」等路由邏輯。這意味著微語天然適合做論文裡的人機協同模式，而不是把 Agent 直接放到無人監管的全自動鏈路裡。

4. 已有工作流和服務設定入口​

服務設定裡已經能看到 workflow、faqKbUid、inputAssociation、showFaqs 等配置項。說明微語不是沒有編排入口，而是下一步可以把「技能」提升為與 workflow、knowledge base 並列的正式配置物件。

5. 已有回饋實體雛形，但還不夠厚​

訊息回饋實體目前已經存在，但欄位和處理鏈路還比較薄。它很適合作為 SkillForge 式閉環的起點，但距離「結構化失敗記錄 + 自動診斷 + 自動優化」還有明顯距離。

結合微語現狀，下一步最值得做的升級方向​

如果把這篇論文轉成微語的產品與架構路線，我認為最值得優先做的是下面五件事。

一，把技能從隱式 prompt 提升為顯式資產​

今天很多客服機器人系統雖然也有「提示詞」，但它往往分散在機器人設定、工作組設定、知識庫、FAQ、預設回覆等多個地方。長期看，這會導致能力難以沉澱。

更合適的做法是把 Skill 定義成一個一等公民物件，至少包含這些部分：

  • 指令層：適用場景、目標、邊界、澄清策略、回覆風格
  • 知識層：FAQ、文件切片、術語、示例工單、常見故障樹
  • 工具層：允許調用哪些工具、何時調用、輸入輸出約束
  • 流程層：不同場景的處理順序、升級條件、轉人工條件
  • 評估層：成功定義、失敗分類、人工回饋映射規則

這樣做之後，微語裡的 robot、workgroup、assistant、workflow 才能真正共享和複用同一套技能資產。

二，把失敗日誌升級成結構化 Failure Record​

如果沒有結構化失敗記錄，自進化就無從談起。微語下一步應該優先把以下訊號統一沉澱下來：

  • 使用者是否繼續追問同一問題
  • 使用者是否觸發「轉人工」
  • 客服是否重寫了 AI 建議
  • AI 回覆是否被坐席採納、部分採納或放棄
  • 使用者是否點踩、投訴、低滿意度
  • 工具調用是否失敗、超時或未命中

然後按照論文的四個主維度去歸因：Knowledge、Tool、Clarification、Style。這樣後面無論是做人工復盤、規則分析，還是做自動診斷，資料基礎才是統一的。

三，把知識庫升級成「技能知識庫」，而不只是 FAQ 檢索​

微語現在已經有 FAQ、向量檢索、來源引用，這是好基礎。但論文提醒了一個很關鍵的點：企業 Agent 的知識不只是「文件內容」，還有「怎麼處理事情」的經驗。

所以更值得做的是把知識源分成兩類：

  • 靜態知識：FAQ、產品文件、介面說明、制度規則
  • 動態經驗：歷史工單中的高品質解決路徑、澄清話術、升級判斷、常用工具組合

如果只做靜態 RAG，系統會回答「知道的內容」；如果把優秀工單和處置路徑也納入技能參考，系統才更接近「像資深客服一樣處理問題」。

四，引入技能診斷器與技能優化器​

這是論文最有啟發性的部分，也是微語現在最缺的一段。

微語完全可以在現有 AI 模組之上新增兩類背景任務：

  • Skill Diagnostician：週期性讀取失敗樣本，輸出「哪些技能段落有問題」的診斷報告
  • Skill Optimizer：在人工審核後，自動生成新的技能草案或 references 更新建議

注意這裡不一定要一步做到全自動上線。更現實的第一階段路徑是：

  1. 自動生成診斷報告
  2. 自動生成技能修訂草案
  3. 由營運、質檢或管理員審核
  4. 審核通過後發布新版本

這會比現在很多系統「人工看聊天紀錄，再手改 prompt」高效得多，也更可追蹤。

五，把技能營運做成後台可視化能力​

如果技能只是寫在文件裡，企業最終用不起來。微語更適合把它做成後台裡的營運物件：

  • 查看技能版本歷史
  • 對比兩個技能版本差異
  • 查看每個版本上線後的命中率、轉人工率、滿意度變化
  • 支援按租戶、工作組、機器人做 A/B 測試
  • 支援按行業導入行業技能模板

一旦走到這一步，微語的競爭力就不再只是「有機器人」，而是「有一套可持續營運的企業 Agent Skill 平台」。

一個更現實的微語落地順序​

如果按照投入產出比來排優先級，我更建議分三期推進。

第一期：先把資料閉環打通​

  • 補全訊息回饋實體與失敗記錄結構
  • 統一記錄 AI 建議、人工採納、轉人工、使用者追問、使用者評價
  • 建立基礎失敗分類看板

第二期：把技能變成正式配置物件​

  • 在 robot settings、workgroup settings、agent settings 中引入 skill 配置
  • 支援技能模板、技能版本、技能發布與回滾
  • 將優秀 FAQ、歷史工單摘要、工作流節點說明沉澱到技能 references

第三期：引入半自動進化能力​

  • 定期跑技能診斷任務
  • 自動生成優化建議與新版本草案
  • 審核後灰度發布
  • 對比上線前後的核心指標變化

這條路線最大的好處是，不要求一開始就相信「AI 自動改技能一定靠譜」。它允許微語先把證據鏈、診斷鏈、審核鏈做好，再逐步把優化自動化程度提高。

SkillForge 給微語的真正啟發​

這篇論文最有價值的地方，不是又提出了一個新框架名字，而是把一個常被忽視的問題講清楚了：企業 Agent 的核心資產，正在從「模型參數」轉向「技能系統」。

誰能把領域知識、工具規範、工作流、失敗回饋、人工經驗沉澱成可進化的技能，誰就更有機會把 AI 從「能聊天」做成「能穩定解決問題」。

微語已經具備了這條路線的多個基礎模組。下一步如果能把知識庫、機器人、工作流、訊息回饋、質檢和後台配置真正串成一個 SkillForge 式閉環，那麼微語做的就不再只是一個接入大模型的客服系統，而會更接近一個面向企業服務場景的自成長 Agent 平台。

參考資料​