当 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 四阶段处理流程

阶段	输入	输出	核心动作
Workflow Mining	历史工单对话	结构化解决路径	从专家回复中提取"典型解决模式"
Tool Mining	工单中的工具调用	tools.json	识别高频工具，提取 schema
Knowledge Extraction	内部技术文档	参考文档集	搜索相关文档，提取领域知识
Skill Synthesis	以上所有	完整 Skill 包	填充预定义模板

3.2 Workflow Mining 是关键

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

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

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

3.3 初始质量对比

方法	平均 Strict CR	平均 Lenient CR	说明
S_generic（通用 Creator）	56.3%	63.4%	仅含工具 schema，无领域知识
S_domain（本文 Creator）	60.6%	67.0%	基于历史工单和知识库

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

---

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

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

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

维度	检查内容	典型问题
Knowledge	知识缺失 / 错误 / 矛盾 / 过时	不知道"有效签名 URL 可直接访问私有文件"
Tool	遗漏调用 / 错误参数 / 结果误读	该查 bucket ACL 时没查
Clarification	过度询问 / 不足询问 / 无关询问	客户已经给了 RequestID，还反复要
Style	机械 / 冗长 / 冷漠 / 不当语气	用清单式回复，不像人

聚合判定：

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（定向优化）

三层知识放置策略：

知识类型	放置位置	原因
高频、稳定知识	SKILL.md 相关章节	核心决策需要，必须常驻
长尾、无权威文档	FAQ	避免污染主 Skill，保持精简
有官方文档可用	引用源链接	运行时检索，保持 Skill 精简

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

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

---

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

5.1 五个真实场景

场景	产品	工单数	任务数
S1	账号（Account）	389	706
S2	域名（Domain）	527	1061
S3	DNS	256	572
S4	对象存储（OSS）	385	730
S5	云服务器（ECS）	326	668
合计		1883	3737

数据按时间顺序分成 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 更好

方法	Strict CR	Lenient CR
S_generic	56.3%	63.4%
S_domain	60.6%	67.0%

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

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

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

迭代	S_manual（专家编写）	S_domain（领域生成）	S_generic（通用生成）
v1	+4.09	+2.36	+7.70
v2	+9.64	+7.31	+8.40
v3	+10.99	+9.23	+11.60

三个核心发现：

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)

故障类别演变：

类别	v1→v2	v2→v3	原因
Tool	-14.5%	-18.2%	优化器有效改进工具调用指令
Style	-16.4%	-20.9%	响应语气指导有效
Clarification	-13.1%	-16.4%	信息收集策略持续优化
Knowledge	显著下降	0%	早期解决显著缺口，剩余问题难以通过 Skill 优化解决

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

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

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

---

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

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

6.1 聚合故障分布

类别	总数	High	Medium	Top 问题类型
Style	108	72	36	verbose(78), robotic(25)
Clarification	97	64	33	over_clarification(59)
Knowledge	76	48	28	missing(48)
Tool	59	43	16	missing_call(34)

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 #领域知识