跳到主要内容

从 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 平台。

参考资料​