当 Agent Skill 学会自己进化：阿里云 SkillForge 的工业级实践

部署后 Skill 质量停滞不前？阿里云用 1883 张真实工单证明：自动化进化可以超越人工策划的专家知识。

一、为什么企业级 Agent 需要"会进化"的 Skill？

LLM Agent 的 Skill 系统——这个由 Anthropic 推广的概念——正在快速成为 AI 编程和自动化的基础设施。但当你把 Agent 从"写代码"场景搬到"云技术支持"场景时，问题突然变得复杂得多。

阿里云的技术支持团队每天处理成千上万张工单：账号权限问题、域名解析故障、OSS 上传失败、ECS 实例崩溃……每个问题都需要：

• 深厚的领域知识：DNS 记录类型、OSS 访问策略、ECS 安全组规则
• 程序性知识：标准化的诊断步骤、先查什么后查什么
• 组织上下文：内部工具 API、最佳实践、升级路径
• 正确的工具调用：查询日志、验证配置、检查配额

现有 Skill Creator 的问题是：它们生成的是通用模板，无法扎根于企业的真实数据和工具。就像让一个没有阿里云工作经验的人写阿里云的客服手册——他知道"要写手册"，但不知道"写什么内容"。

更致命的是第二个问题：一旦部署，Skill 就停滞了。执行失败无法自动追溯到 Skill 本身的缺陷，大量运营数据被浪费。

SkillForge 要解决的就是这两个问题：

1. 初始 Skill 要有领域接地（Domain Grounding）
2. 部署后要有系统化的自我进化机制

二、SkillForge 的完整架构：从创建到进化的闭环

2.1 整体流水线

┌─────────────┐    ┌─────────────┐    ┌─────────────┐
│  Domain-    │    │  Agent 执行  │    │  Failure    │
│ Contextualized│ → │  与监控      │ → │  Analyzer   │
│  Skill Creator│    │             │    │  多维分析    │
└─────────────┘    └─────────────┘    └──────┬──────┘
      ↑                                        ↓
      └─────────────┐    ┌─────────────┐    ┌─────────────┐
        VFS 版本化   │ ← │  Skill      │ ← │  Skill      │
        提交        │    │  Optimizer  │    │ Diagnostician│
                   │    │  定向优化   │    │  根因诊断    │
                   │    └─────────────┘    └─────────────┘

这个循环每轮都在真实部署数据上运行，Skill 质量随着每次迭代自动提升。

2.2 对"Skill"的严格定义（企业安全版）

SkillForge 对 Skill 的格式做了安全约束：

skill_name/
├── SKILL.md              # 核心指令和工作流（无脚本）
└── references/
    ├── tools.json        # 预定义、已验证的工具 schema
    ├── knowledge_*.md    # 领域知识文档
    └── ...

关键约束：排除 scripts/ 目录，仅使用预定义工具。所有操作通过**虚拟文件系统（VFS）**进行，禁止任意代码执行。

这个设计不是过度保守，而是基于企业生产的真实需求：高频客服任务可以通过"指令注入 + 预定义工具"解决，排除可执行脚本能提升稳定性，文本操作空间也简化了故障诊断和优化。

2.3 SKILL.md 的五段式结构

SkillForge 生成的 SKILL.md 不是自由格式的提示词，而是高度结构化的模板：

1. Background Knowledge      # 客户最常误解的概念
2. Case-Type Triage          # 决策树路由（先判断是什么类型的问题）
3. Per-Case-Type Handling    # 4-8 种 case 类型，每种包含：
   - 适用性描述
   - 分支工作流（非线性序列，带条件判断）
   - 工具调用指导（什么时候调用什么工具）
   - 故障原因 / 解决方案对
   - 升级回退路径（什么时候转人工）
4. FAQ                       # 频率 < 5% 的长尾问题
5. Reference Index           # 参考文档索引

结构化的价值： Failure Analyzer 可以精确判断"哪个 section 有问题"，Skill Optimizer 可以"只改那个 section"，而不是重写整个 Skill。

三、Domain-Contextualized Skill Creator：让 Skill 扎根于真实数据

3.1 四阶段处理流程

3.2 Workflow Mining 是关键

这是整个 Creator 的核心。它的假设是：历史工单中隐藏着专家解决问题的最佳实践。通过挖掘这些对话，可以提取出：

• "遇到 OSS 上传失败，先查 RequestID，再查 bucket ACL，再查网络策略"
• "域名解析问题，先判断是 DNS 配置还是备案问题，再分别处理"

这些不是写在文档里的，而是专家在实际工作中积累的非正式知识。

3.3 初始质量对比

平均提升 +4.3pp。关键洞察：即使 S_generic 已经包含了工具 schema，S_domain 仍然显著更好——说明工作流知识和知识提取超出了工具本身的价值。

四、三阶段自进化管道：核心创新

4.1 阶段一：Failure Analyzer（并行四维分析）

对每张执行失败的工单，从四个维度并行分析：

聚合判定：

• fail：任一维度 high，或至少两个 medium
• marginal：一个 medium，或至少两个 low
• acceptable：其他情况

优先级：knowledge > tool > clarification > style

4.2 阶段二：Skill Diagnostician（批量聚合 + 根因诊断）

批量聚合：把 100+ 张 bad case 的故障分析结果按类别汇总，统计高频问题。

ReAct 诊断代理：

1. 理解 Skill：读取 SKILL.md，总结结构
2. 收集证据：解析聚合的故障分析结果
3. 根因归因：把问题映射到 SKILL.md 的具体位置，分类为 missing / insufficient / incorrect
4. 生成计划：产出优化计划（机器可解析，指定修改位置、内容变更、是否需要示例 / 知识搜索）

4.3 阶段三：Skill Optimizer（定向优化）

三层知识放置策略：

三大核心原则：

1. Minimal Modification：只改必要内容
2. Do No Harm：增量修改保留正确行为，绝不删除有效内容
3. Evidence-Based：每次变更追溯到具体故障分析证据

版本控制：修改后的 VFS 状态提交为 Skill_v_n+1，确保完全可追溯。

五、实验结果：1883 张工单，3737 个任务的真实验证

5.1 五个真实场景

数据按时间顺序分成 4 份，模拟真实部署：25% → v1 进化，25% → v2，25% → v3，25% 作为 held-out 评估集（从未见过）。

5.2 评估方式：LLM-Judge

用 LLM 评判 Agent 回复与专家参考回复的一致性：

• Consistent（一致）：澄清问题和解决方案与参考一致
• Partially Consistent（部分一致）：与参考重叠无矛盾，但可能遗漏细节
• Inconsistent（不一致）：缺少关键澄清、遗漏核心解决方案、或冲突

验证：与 5 名领域专家标注对比，LLM-Judge 达成 > 90% 一致性。

5.3 结果一：领域化 Creator 比通用 Creator 更好

平均提升 +4.3pp Strict CR，+3.6pp Lenient CR。最大提升在 ECS 场景（+7.2pp）。

5.4 结果二：自进化循环有效，且对所有起点有效

held-out 评估集上的进化增益（Δ）：

三个核心发现：

1. 普适改进：所有起点均受益——包括专家编写的 Skill
2. 单调递增：每轮累积增益增加，确认正向价值
3. 起点效应：S_generic 增益最大（+11.60），说明进化循环对低质量起点尤其有效；但 S_manual 仍有 +10.99 增益，表明自动化进化可超越人工策划的知识

5.5 结果三：超越生产遗留系统

• v3 vs 生产遗留系统：+13.76pp Strict CR
• 遗留系统：预定义决策树 + 人工策划专家提示，经长期调优
• 结论：领域化创建 + 自动化进化可以超越成熟的人工工程化生产系统

5.6 收敛分析：Knowledge Plateau

进化增益不是无限增长的。边际增益递减：

S_manual: +4.09 → +5.55 → +1.35 (v1→v2→v3)

故障类别演变：

**Knowledge Plateau（知识平台期）**的三重根源：

1. 参考不一致性：不同人工代理对相似工单给出矛盾回复，数据本身存在真实歧义
2. 设计约束：故意限制 Skill 膨胀——高频稳定知识入 SKILL.md，长尾入 FAQ，其余运行时检索
3. 隐性专家经验：专家回复常省略隐性推理链和经验直觉，低频率长尾模式难以从文本恢复

结论：纯文本、全自动的 Skill 优化存在固有天花板。人机协同审查（human-in-the-loop）是必要的补充。

六、案例研究：OSS 错误诊断 Skill 的进化过程

论文附录 F 提供了一个完整的案例：OSS 错误诊断 Skill，108 个 bad case。

6.1 聚合故障分布

6.2 三个代表性案例

案例 1：签名 URL 访问私有 Bucket

• Knowledge High：缺失"有效签名 URL 可直接访问私有文件"的核心知识
• Tool High：未调用 bucket 信息查询工具验证 ACL；缺少签名 URL 验证工具
• Clarification High：在已有完整签名 URL + 过期时间时，仍要求错误代码和 RequestID
• 优化：添加规则 + 补充签名 URL 生命周期知识 + 修复澄清策略 + 添加工具触发条件

案例 2：镜像回源配置（知识错误）

• 核心错误：Agent 错误断言镜像回源配置不能包含 https:// 前缀或 /* 通配符，指示客户修改（实际合法的）配置
• 级联效应：知识错误 → 错误澄清策略（否认有效配置）→ 遗漏工具调用 → 权威但错误的指令
• 优化：纠正格式规则 + 添加源站响应状态码验证知识 + 添加工具触发

案例 3：资源包计费诊断（工具缺失）

• 核心差距：缺少计费资源包查询工具
• Agent 不知道：如何判断客户是否购买了资源包、资源包是否过期、是否还有剩余额度
• 优化：添加工具调用 + 补充计费知识到 SKILL.md

七、工业启示：为什么这篇论文重要？

7.1 从"写 Skill"到"养 Skill"

SkillForge 的核心理念是：Skill 不是一次性产物，而是需要持续喂养的生命体。

当前行业的主流做法是：

1. 专家手写 SKILL.md
2. 部署到生产环境
3. 发现问题 → 人工修复 → 重新部署

SkillForge 的做法是：

1. 基于历史数据自动生成初始 Skill
2. 部署到生产环境
3. 收集执行失败 → 自动诊断 → 自动优化 → 版本化提交 → 下一周期

这不是"替代专家"，而是把专家从"重复修 bug"解放到"处理 Knowledge Plateau"。

7.2 领域接地是门槛，不是选项

论文的一个重要发现：即使通用 Creator 已经包含了工具 schema，领域化 Creator 仍然显著更好（+4.3pp）。

这意味着：工具调用能力不是 Skill 质量的瓶颈，领域知识才是。在阿里云的场景中，知道"什么时候查什么"比"知道怎么查"更重要。

这对所有企业级 Agent 部署都有启示：

• 不要期望通用 Skill 框架直接解决你的业务问题
• 必须投入精力做领域数据整理（历史工单、知识库、专家回复）
• 初始 Skill 质量决定了进化循环的"起点高度"

7.3 自动化的天花板在哪里？

Knowledge Plateau 是一个诚实的结论。论文没有宣称"全自动进化可以无限提升"，而是明确指出：

长尾知识错误无法仅通过 bad-case 驱动消除。

这是因为：

• 数据本身有歧义（不同专家给出矛盾回复）
• 专家经验中有大量隐性知识（未写出口的推理链）
• 低频模式无法从有限数据中恢复

解决方案：人机协同。自动进化处理 80% 的高频问题，专家审查处理 20% 的长尾问题。

7.4 安全约束的设计智慧

SkillForge 排除 scripts/ 的做法看似限制了功能，但实际上是安全与可维护性的权衡：

• 排除可执行脚本 → 消除了代码注入和任意执行的风险
• 纯文本 Skill → 故障诊断和优化变得简单（不需要分析代码逻辑）
• 预定义工具 → 工具调用可以被精确追踪和优化

这个设计哲学值得所有企业级 Agent 系统借鉴：功能完整性不是第一目标，可诊断性和可维护性才是。

八、局限与未来方向

8.1 当前局限

1. 仅适用于高频、结构化任务：云技术支持是高重复性场景，每个问题类型有标准化处理流程。对于高度创造性的任务（如架构设计、代码重构），Workflow Mining 可能无法提取有效模式。

2. 依赖高质量的参考回复：Workflow Mining 和 Knowledge Extraction 都假设历史数据中有"专家级"的参考回复。如果历史数据质量不高（如新手客服的回复），挖掘出的模式可能反而有害。

3. Knowledge Plateau 未解决：长尾知识错误的处理仍需要人工介入，自动化循环无法完全替代专家审查。

4. 评估依赖 LLM-Judge：虽然验证了与 5 名专家 > 90% 一致性，但 LLM-Judge 本身可能引入系统性偏差。

8.2 可能的演进方向

1. 多模态输入：当前仅处理文本工单，未来可以处理日志文件、截图、监控图表
2. 跨 Skill 协同：当前每个 Skill 独立进化，未来可以处理 Skill 之间的依赖和冲突
3. 主动知识发现：不仅从 bad case 学习，还可以从 good case 中主动发现"为什么好"
4. Human-in-the-Loop 的自动化：把专家审查也纳入循环，减少人工负担

结语：Skill 的工业化之路

SkillForge 的论文标题用了"Forging"（锻造）这个词，非常贴切。锻造不是一次成型的，而是反复加热、锤打、淬火的过程。Skill 也是如此：

初始创建是"加热"——把原材料（历史数据、知识库）熔化成型。
部署执行是"锤打"——在真实环境中检验形状是否合格。
故障分析是"诊断"——找出哪里开裂、哪里过薄。
定向优化是"回炉"——精确修复缺陷，再次锻造。
版本化提交是"淬火"——固定当前状态，准备下一轮。

阿里云用 1883 张工单和 3737 个任务证明：这个循环可以自动化运行，且效果超越人工策划的专家知识。但论文也诚实地指出了天花板——Knowledge Plateau 是全自动进化无法逾越的障碍，人机协同才是终极答案。

对于正在构建企业级 Agent 系统的团队来说，SkillForge 提供了一套可以直接借鉴的方法论：

1. 不要从零写 Skill，从历史数据挖掘
2. 不要部署后就不管，建立进化循环
3. 不要追求全自动，在合适的地方引入人工审查
4. 不要追求功能完整，优先保证可诊断和可维护

Skill 的工业化时代，才刚刚开始。

参考

• 论文：SkillForge: Forging Domain-Specific, Self-Evolving Agent Skills in Cloud Technical Support (arXiv:2604.08618)
• 作者：Xingyan Liu, Xiyue Luo, Linyu Li, Ganghong Huang, Jianfeng Liu, Honglin Qiao（阿里云）
• 会议：ACM SIGIR 2026 Industry Track
• 数据：5 个云支持场景，1883 tickets，3737 tasks
• 代码与数据：尚未开源（工业论文，数据敏感）

#Skill #Agent #阿里云 #云技术支持 #自进化 #LLM #企业级Agent #工业论文 #SIGIR2026 #领域知识