SkillForge：让技能自己学会进化

痛点一：冷启动难

通用技能生成器（比如Claude Code）写出来的SKILL.md，内容很泛，往往只有抽象的工作流描述："分析问题，调用工具，给出方案"。但企业场景需要的是具体的操作流程。以云技术支持为例，它有明确的工作流：DNS解析失败 → 检查DNS记录 → 检查防火墙 → 检查负载均衡。没有领域数据喂养，生成的技能就是空壳，无法指导Agent完成真实任务。

痛点二：部署后不改进

技能写好上线了，Agent跑任务，有时候成功有时候失败。失败的case呢？要么记录在日志里没人看，要么人工review但不会系统性改技能文件。时间久了，技能质量就停滞（stagnant）。明明积累了大量运营数据，却没办法把它们变成技能改进信号。这是一个巨大的浪费——数据在积累，但技能在腐烂。

❌ 旧方案：手工写技能 → 上线 → 失败积压在日志 → 技能质量停滞

传统模式下，技能是静态资产。专家写完，上线运行，失败case沉淀在日志里。偶尔有人看一眼，偶尔修个bug，但没有系统性机制把失败反馈回技能本身。技能质量在上线那一刻达到峰值，之后只可能退化。

✅ 新方案：领域初始化 → 上线 → 自动诊断失败 → 自动改技能 → 循环进化

SkillForge提出三阶段Pipeline（Analyzer → Diagnostician → Optimizer），自动把失败映射回技能缺陷并重写，迭代循环让技能自己进化。每一个失败case都成为技能改进的燃料。

Phase 0：领域初始化（Domain-Contextualized Skill Creator）

冷启动阶段，不是从零开始，而是从领域数据中挖掘初始技能。三个核心步骤：

• Workflow Mining：从历史工单中挖掘典型工作流
• Tool Mining：识别常用工具和调用模式
• Knowledge Extraction：提取领域知识点

输出是初始技能文件Skill_v0，质量比通用生成器高4.3个百分点。

Phase 1：执行与失败分析（Execution + Failure Analyzer）

Agent执行任务，系统识别Bad Cases。Failure Analyzer对每个失败进行四维度分析：

四维度分析是精准定位问题根源的关键。同一个"回答不对"，可能是知识缺，也可能是工具漏调用，诊断不同，改法不同。

Phase 2：聚合（Aggregation）

按类别聚合失败记录，选择代表性案例。不是每个失败都独立修复，而是聚类后找共性——改一处，解决一类。

类比：医生看病历，不是每个病人单独开药，而是找病根——10个病人同一个病因，开一个处方就够了。

Phase 3：诊断（Diagnostician）

诊断Agent用ReAct模式，边读技能边推理边映射。这是整个Pipeline的核心：

不是简单匹配，是推理。同一个"工具漏调用"失败，在不同场景下可能对应不同的技能缺陷位置，需要Agent自己判断。

Phase 4：优化（Optimizer）

技能优化器执行VFS（Virtual File System）修改，遵循Minimal Modification原则：只改必要的部分，保留已有的正确行为。

类比：像修房子——哪里漏水补哪里，不是拆了重盖。防止"改了A，坏了B"。每次修改只针对诊断出的缺陷，其他部分不动，保证技能质量稳步上升而不是剧烈波动。

⚠️ 知识失败在v1后plateau的原因

知识补完了技能文件里的缺口，但剩余的知识缺陷可能超出技能文件的能力边界。比如需要更强的检索系统、或知识库扩展。这是文本优化的自然边界。

启示：Tool、Style、Clarification是技能内的可修复项，Knowledge则可能需要外部能力支撑。

决策一：四维度失败分析

每个失败case从知识、工具、澄清、风格四个角度并行分析。类比考试复盘：知识错是公式记错，工具错是计算器没用，澄清错是题目没看清，风格错是字太潦草。四种错误，改法不同。

为什么重要：单一分类太粗，四维度能精准定位问题根源。

决策二：ReAct Diagnostician

诊断Agent用ReAct模式，边读技能边推理边映射。类比医生看病历：读病历（读SKILL.md）、看症状（看失败报告）、推理病因（映射失败到技能缺陷）、开处方（生成优化计划）。

为什么重要：不是简单匹配，是推理。同一个"工具漏调用"失败，在不同场景下可能对应不同的技能缺陷位置，需要Agent自己判断。

决策三：Minimal Modification原则

改技能文件时，只改必要的部分，保留已有的正确行为。类比修房子——哪里漏水补哪里，不是拆了重盖。

为什么重要：防止"改了A，坏了B"。每次修改只针对诊断出的缺陷，其他部分不动，保证技能质量稳步上升而不是剧烈波动。

批判一：四维度分析会不会有overlap？

"知识错误"和"工具结果误读"可能重叠。论文没有深入讨论这个问题。但实际影响可能有限——四维度是诊断框架，不是互斥分类，overlap意味着需要同时修复多个维度。

更深层问题：四维度的设计是否有理论支撑？还是经验驱动？论文没有给出消融实验来验证四维度的必要性。

批判二：五场景外推性存疑

实验只在五个云计算子领域进行，是否适用于其他领域（医疗、法律、金融）？但这是SIGIR Industry Track，聚焦真实场景比泛化更重要。工业价值明确。

更深层问题：演化过程是否会产生过拟合？技能会不会过度适应特定失败模式，牺牲泛化能力？论文没有讨论这个问题。

批判三：和Production Legacy System对比公平吗？

论文声称超越production legacy system 13.76pp。但legacy system可能是多年积累的技能库，SkillForge是全新训练的。这像是拿新车和旧车比油耗，不完全公平。

更深层问题：如果让legacy system也经过SkillForge演化，会不会更好？论文没有做这个对照实验。

✅ 1. 四维度分析框架可复用

当前很多技能系统只有"成功率"一个信号，但失败原因可能是知识缺、工具错、流程乱、风格差。分开诊断才能精准改。

迁移场景：多Agent协作场景——决策角色失败分析、工具调用失败分析、风格一致性检查。

✅ 2. Minimal Modification原则可借鉴

不只是技能优化，任何增量改进都可以用这个原则：只改必要的，保留已有的正确行为。防止"改了A，坏了B"。

迁移场景：多Provider成本路由场景——增量优化路由策略、动态调整模型选择。

✅ 3. 演化闭环思维可推广

技能写一次用多次是旧思维。更好的设计：写一次，用多次，演化多轮。每个失败case都是改进的燃料。

迁移场景：多数据源混合训练场景——从失败case中学习、动态调整数据配比。

✅ 4. 三角色分工模式可参考

一个Agent执行，一个Agent诊断，一个Agent改技能。三角色分工，形成演化闭环。避免了"又当运动员又当裁判员"的冲突。

迁移场景：多Agent Pipeline场景——执行Agent、评估Agent、优化Agent的角色分离。

我原来想：专家手工写的技能应该是最优的，自动改进只是锦上添花。

数据告诉我不一样：

原来自动演化不是锦上添花，它能超越专家的初始判断。