1. 问题与动机

将 LLM 智能体部署到企业级技术支持（云客服）等场景时，"技能（skill）"的质量直接决定 Agent 表现。SkillForge 论文识别出现有技能创建器的两个具体缺陷：第一，已有数据 SkillsBench 显示"专家精心策划的技能可以让任务成功率平均提升 16.2pp，而 LLM 自动生成的通用技能几乎无收益"，说明缺乏领域 grounding 的通用技能创建器没有可用价值；第二，平行的客服 Agent 工作普遍依赖人工标注作为反馈信号，需要昂贵的人工逐条审核而无法做大规模自动演化。换句话说，「初始技能差 + 失败后无法机制化诊断」是 Agent 工程化落地的最大短板。这一点也呼应了搜索/推荐 Agent 长期面对的痛点：策略与提示词随业务而变，但缺乏从 bad case 自动反推到具体 prompt/规则缺陷并定向修复的通路。

2. 方法详解

SkillForge 是一个端到端的 "创建-评估-诊断-改写" 闭环框架，核心由一个领域化技能创建器 + 三阶段失败回流管线组成。

Domain-Contextualized Skill Creator 通过四步在私域数据上构造 Skill_v0：(1) Workflow Mining——LLM 反向工程历史工单，抽取问题描述、解决路径（澄清/取数/诊断/交付四阶段）、以及"正向 pattern + 负向告警 + 范例答复"；(2) Tool Mining——从工单操作日志按频率筛出高频工具，结合内部 schema 形成 tools.json；(3) Knowledge Extraction——同时拉取内部 KB 检索 + 工单引用文档，沉淀成 reference 文档；(4) Skill Synthesis——汇总后产出固定五段 SKILL.md：背景知识、case 类型分诊、case 类型处理（4–8 种 case 的分支工作流 + 工具指南 + 失败原因→应对）、长尾 FAQ、引用索引。约束：所有流程必须可追溯到挖掘出的 resolution path，且工作流需带条件分支。当 SKILL.md 超过 500 行时把详细内容下沉到 reference 文件，主文件保留决策逻辑。

执行与监控：Agent 把 SKILL.md 当作 "meta-tool" 动态加载（避免污染 system prompt）。响应通过 LLM-judge 跟专家参考答案做比对，分 Consistent / Partially Consistent / Inconsistent 三档，低一致性即为 bad case 进入回流管线。

Failure Analyzer 不做单一分类，而是同时跑四条诊断维度：知识（缺失/错误/矛盾）、工具（漏调用/参数错/结果误读）、澄清（多问/少问/无关）、风格（机械/啰嗦/冷漠）。任意维度高严重度或≥2 个维度中等即判失败，优先级 knowledge >> tool >> clarification >> style。

Skill Diagnostician 是基于 ReAct 的诊断 agent：先按维度聚合 batch、按严重度+多样性挑 top-k 代表性案例；再读 SKILL.md 摘要其结构（VFS 虚拟文件系统）；接着把 issue 映射回 SKILL.md 的具体位置，并给出缺陷类型（missing / insufficient / incorrect）；最后产出可被机器解析的 Optimization Plan（修改位置、改写内容、是否需要补示例/再检索、预期影响）。

Skill Optimizer 按"最小改动 + 不破坏既有正确行为 + 证据驱动"三原则在 VFS 上 patch：高频稳定知识入对应章节、长尾入 FAQ、有官方文档时仅留链接（避免膨胀），统一在工作流步骤里嵌入工具规则、在 response 模板旁嵌入风格指南。改完即提交 Skill_v_{n+1}。

训练设置：评测覆盖 5 个真实云支持场景（账号 / 域名 / DNS / OSS / ECS），共 1,883 张工单、3,737 个任务；按时间四等分，前三段轮流喂给 v1/v2/v3 模拟生产 batch 反馈，第四段为完全 holdout。LLM-judge 与两位独立领域专家在子集上一致性 >90%。

3. 核心技术贡献

(1) 领域化技能创建器——通过 workflow + tool + knowledge 三路挖掘，把"通用 LLM 不能看到的私有信号"显式注入初始技能。结果：S_domain 比仅给 schema 的 S_generic 在 5 个场景上 Strict CR 平均 +4.3pp / Lenient CR +3.6pp，最大单点 S5 上 +7.20pp，证明 schema 之外的工作流和知识 grounding 是真正的杠杆。

(2) 多维 Failure Analyzer——把"为什么错了"拆成知识 / 工具 / 澄清 / 风格四个独立维度并用确定规则合并，避免单分类器在多重缺陷上的混淆。这种分解让下游优化器知道"该改 SKILL.md 的哪一部分"，而不是只产出一个抽象 label。

(3) 诊断→优化两阶段闭环——Diagnostician 输出可机器解析的 Optimization Plan，Optimizer 在 VFS 上做最小化、可追溯的 patch。三原则（最小改动、不破坏正确行为、证据驱动）解决了 "LLM 自动改提示越改越烂" 的常见踩坑。

(4) 跨起点演化的可验证收益——同一个演化循环可以从 manual / domain / generic 三种起点全部稳定提升，最终甚至超过精雕细琢多年的线上系统（v3 比生产系统 +13.76pp Strict CR）。

4. 实验结果分析

Table 2 初始技能质量（Strict / Lenient CR %）：

Table 3 自演化迭代收益（相对初始 Strict CR / Lenient CR 的 Δ）：

关键观察：(1) 三种起点都能单调提升，证明框架不挑初始技能；(2) S_generic 起点提升幅度最大（+11.60），说明演化对低质量起点效果最显著；(3) S_manual（人工写）经过演化反超原版 +10.99 / +12.21，作者据此声称"自动演化可超越人工策划"。

失败类别消融：工具类错误三轮分别下降 −14.5% / −18.2%，风格类 −16.4% / −20.9%，澄清类 −13.1% / −16.4%，但知识类错误在 v2 之后 0% 进一步下降，出现明显平台期。作者将其归因于：参考答案本身不一致（不同客服回答差异大）、设计上不让技能膨胀 case-fact、专家答复中省略了大量隐性推理。

对比线上：v3 演化版相对生产线长期人工调过的"决策树+专家提示"组合 +13.76pp Strict CR，是论文最强的工业相关结论。

5. 局限与未来方向

作者明确列出的局限：(1) 不允许执行脚本——出于企业安全/稳定性考虑，技能定义仅依赖预审过的系统工具，不能跑 sandbox script，复杂的"实时执行+反馈"场景留作 future work；(2) 知识平台期——bad case 驱动的优化无法消除来自参考答案不一致、设计上拒绝塞 case fact、以及专家隐性知识缺失三个原因造成的长尾错误，这是"纯文本、全自动技能优化的固有上限"；(3) 仍需 human-in-the-loop——人审核作为长尾保险，并不被自动化取代。论文未公布线上 A/B 数字，所有指标都是离线 replay。这意味着真正部署后的客户满意度、人工修改率、acceptance rate 等关键工业指标暂时未知。

6. 工业实践意义

对搜索/推荐 Agent 团队的可借鉴点非常具体：

A. 复用"多维 Failure Analyzer + 诊断→优化"闭环。社区搜索的 query 改写、子查询拆解、多路召回每一环都会出错，传统做法靠埋点 + 人工归因。把 SkillForge 的"知识 / 工具 / 澄清 / 风格"四维替换为搜索 Agent 自己的失败维度（如"召回缺漏 / 排序错位 / 改写过度 / 拒答过度"），即可让 Agent 自动从 bad case 反推 prompt 缺陷并最小改动 patch。

B. 把 prompt/skill 当作可演化资产而非静态文件。SKILL.md + reference + VFS 的组织方式比"超长 system prompt"更易做局部修改与版本控制，特别适合 query 改写规则、长尾 query 处理 FAQ 等场景。

C. 用 LLM-judge + 专家答案做离线评估。论文显示 LLM-judge 与人评一致性 >90%，对于人评成本高的搜索 UGC 场景这是一个落地友好的离线指标方案，可替代或补充传统的 nDCG / 点击仿真。

D. 现实约束：(1) 该方法依赖大量历史 ticket/conversation，只有有沉淀的业务才能直接复用；(2) 知识层错误的平台期警示我们，纯靠 prompt 演化不能替代知识库/检索本身的优化，搜索系统中"召回 + 索引"仍需独立投入；(3) 不允许跑脚本的限制对线上 deploy 友好，但也意味着只能做"流程级"优化、做不了"在线学习参数"。综合看，框架的人力投入主要在前期 mining 与 LLM-judge 校准，演化阶段几乎全自动，对工程团队规模不大但工单/对话历史充足的搜索/推荐场景非常划算。