告别Skill'盲盒'！Skill-insight三招让Agent精准可迭代
核心观点：在智能运维场景中，Skill作为Agent执行运维任务的核心载体，其标准化、可观测、可优化的程度，直接决定Agent从“能运维”到“善运维”的跨越；Skill-insight的核心价值的是：让智能运维Agent的Skill从“模糊不可控”走向“精准可迭代”，实现运维效率、稳定性与成本的三重最优。
一、背景：智能运维时代，高质量Skill是Agent成功落地的关键
在AI时代，Agent已成为企业解决各类运维自动化任务、提升效率的重要方式，而Skill更是辅助Agent完成运维任务的核心标准化能力。从服务器故障诊断、容器卡顿排查，到系统配置优化，Agent的每一次精准高效响应，本质上都有其背后高质量Skill的作用。
然而在实际落地中，Skill的应用却面临着一些核心问题，这些问题源于运维场景的复杂性和高要求，而当前Skill相关的生成、评测与优化工程等能力还不足以与之匹配，使得Skill的使用就像开“盲盒”，影响Agent落地的效果、效率和成本：
问题1：运维文档繁多，生成Skill数量冗余，导致召回率下降、token消耗高
智能运维场景中，同一类运维问题（如Docker应用卡顿）往往存在多种处理方案，以案例文档、操作手册等多种方式的文档承载。这些文档虽然细节不同，但核心解决路径非常相似。然而，现有生成方式（例如直接通过大模型或skill-creator生成），往往无法精准去除冗余和相似部分，从而形成大量语义高度相似的Skill。
这在智能运维场景中会带来两个核心问题：
- Token成本飙升：大量相似Skill被加载，即使默认使用渐进式披露原则加载，由于数量庞大，token成本仍然显著增加
- 召回能力下降：有研究表明[1]，当Agent所使用的Skill数量超过40-50个后，召回率从95%急剧下降至30%以下。
问题2：评测维度单一，缺乏对评测结果的可追溯能力
智能运维场景对Agent的核心要求是“精准、可靠、可追溯”，但当前Skill评测大多停留在“任务是否完成”的结果导向层面，远远无法满足运维场景的严苛需求。
首先，企业智能运维关注的不仅是“解决问题”，更关注“高效、低成本地解决问题”——即运维ROI（投资回报率）。一个Skill即使能完成故障修复，但如果Token消耗过高、执行时延过长，会增加运维成本，其实际运维价值会大幅降低，而当前缺乏针对运维场景的ROI评测指标，无法量化Skill的实际运维价值。
其次，运维任务多涉及系统配置修改、故障排查等关键操作，执行过程的准确性直接影响系统稳定性。例如，在内核参数修改、配置文件调整等运维场景中，Skill的执行往往包含多个分支判断、前置检查步骤，即使最终故障得以解决，但如果Agent未按Skill预定义的安全流程执行（如跳过备份步骤直接修改配置），也可能埋下系统崩溃、数据丢失的隐患。而当前的评测方式无法追溯执行过程，无法判断执行路径是否合规、哪一步出现偏差，更无法解释“结果正确但过程偏差”的潜在风险。
换句话说：智能运维场景需要的是“面向运维执行过程的多维评测与可追溯体系”，而非单纯的“结果级判断”，这是保障运维可靠性的核心前提。
问题3：优化缺乏运维执行过程数据，Skill能力难以持续提升
智能运维的核心目标是“持续优化、降低人工干预”，但当前Skill优化工具主要依赖“任务结果是否正确”这一单一信号，缺乏对运维执行过程数据的采集与利用，导致Skill优化陷入“浅层调整、无法突破”的困境。
关键问题在于，Skill优化所需的关键信息不仅需要结果类数据，更需要执行过程数据，但这类过程数据往往未被记录和结构化，导致优化缺乏精准支撑。例如，某Skill执行耗时超长，却无分步骤时延数据，无法定位瓶颈；某Skill存在安全流程漏洞（如未要求备份配置），因缺乏过程记录，其行为无法被发现且难以纳入优化闭环。
这种“过程数据缺失”，导致Skill优化只能停留在“修改文本描述、调整结果判断”的浅层，无法基于运维实际执行数据进行深度优化，难以适配不断变化的运维场景（如新型内核缺陷、新的容器故障类型），最终导致Agent的运维能力无法持续提升，无法满足智能运维长期演进诉求。
针对以上三大核心痛点，openEuler社区Intelligence SIG组推出了开源项目Skill-insight——一个面向Skill全生命周期管理的开源工具，提供Skill标准化生成、多维评测、数据驱动优化等能力，可满足各类Agent场景需求，同时在智能运维场景重点落地，让Agent开发者能够高效打造高质量Skill，让Agent从“能执行”走向“善执行”。
二、Skill-insight：让Agent Skill可管、可溯、可优，赋能Agent高效执行
Skill-insight并非简单的Skill生成工具，而是覆盖Skill“生成-评测-优化”全生命周期的通用能力体系,其核心价值在于打通Skill生成、多维评测与优化的闭环，让Agent的执行能力更精准、更可靠、更经济。 Skill-insight提供三大通用核心能力：
1. 基于语义聚合的模式抽取：有效去除冗余Skill，提升召回率
针对运维文档繁多，生成Skill数量冗余，导致召回率下降、token消耗高的问题，Skill-insight的核心思路是：去冗余、合相似、抽模式。
- 去冗余：从企业沉淀的碎片化案例文档、操作手册中，剔除无关上下文、重复操作描述与噪声信息，保留问题的核心特征、前置检查与标准处理步骤；
- 合相似：基于文本聚类相似度算法结合大模型语义理解能力，聚焦同类问题（如容器卡顿、内核缺陷等），将相似的Skill进行合并，提炼共性逻辑；
- 抽模式：在合并基础上，结合各类场景的安全规范、操作标准，提炼通用问题模式与标准化执行路径，生成符合多场景需求的可复用、标准化Skill。
通过以上方法，将每一类共性问题的领域经验、操作规范，提炼为一个标准化、可复用的Skill，使得能够保证在不丢失关键信息的前提下，有效去除冗余Skill，提升召回率的同时并有效降低Token消耗成本。
2. 多维评测与过程级可追溯：保障执行可靠、风险可控
针对评测维度单一、缺乏对评测结果可追溯能力的问题，Skill-insight的核心思路是：构建多维评测体系 + 引入标准数据集 + 提供过程级可追溯能力，让Skill的执行效果可量化、执行过程可监测。
- 多维评测体系：构建涵盖准确率、执行时延、Token成本、ROI等多维度的评测体系，其中ROI指标重点量化“执行成本与任务收益”的平衡，贴合各类企业场景的核心诉求，全面刻画Skill的实际价值；
- 内置标准评测数据集：集成SkillsBench等行业标准Skill评测数据集，并支持用户扩展自定义数据集（如企业内部的各类故障、任务案例集），构建统一的Skill评测基准，确保评测结果客观、可用；
- 过程级可追溯：在Agent执行各类任务过程中，实时生成动态执行流程图，与Skill预定义的执行流程进行精准对比，清晰标识未按预期执行的步骤、违规操作与流程偏差，让执行过程“看得见、可追溯”，同时支持在执行记录中逐步回溯，辅助开发者分析流程偏移的根本原因,为后续优化提供精准方向。
通过以上方法，将评测从结果层提升到“结果+过程”的多维度评测，既保证了执行结果的准确性，又能帮助及时发现“过程偏差”带来的各类风险，让各类Agent的执行更可靠、更可控。
3. 全链路数据驱动优化：使Skill可持续自进化
针对Skill优化缺乏过程数据支撑、能力难以提升的问题，Skill-insight的核心思路是：收集执行全链路数据，形成“数据采集-分析-反馈-优化”的自动化闭环，让Skill能够基于实际执行场景持续迭代。
- 全链路数据追踪：全面记录Agent执行各类任务的每一步操作、模型推理、工具调用与参数修改，重点捕捉执行瓶颈（如Token消耗过高、耗时最长的执行步骤）、违规操作与流程偏差，形成结构化的执行过程数据集；
- 数据驱动的自优化闭环：将结构化的执行过程数据，自动反馈至Skill优化环节，结合各类场景的安全规范、效率需求，辅助开发者定位Skill的流程缺陷、成本漏洞与安全隐患，实现针对性优化；
通过上述方法，让Skill能够基于实际执行数据进行深度优化——例如补充缺失的安全步骤、优化冗余的执行流程、调整参数设置以降低成本，让Skill能够持续适配新型场景，驱动各类Agent执行能力不断提升，真正实现Agent的“自进化”。
三、案例：使用Skill-insight进行应用卡顿故障诊断场景Skill优化
场景背景： 某企业在生产环境中频繁出现 Docker 应用卡顿问题，历史上沉淀了大量故障排除方法文档，但人工处理问题效率低，希望将这些文档固化为Skill。
步骤1：Skill生成
使用Skill-insight基于数十个相似案例生成Skill，对其中的技能描述、使用场景、核心指令与工作流程做了去冗余和模式抽取，统一沉淀为1个“docker应用卡顿问题诊断Skill”，如下（部分内容从略）：
---
name: openEuler-docker-hang
description:
此技能用于诊断和修复在EulerOS 2.9操作系统上，由于特定内核版本存在调度缺陷，导致虚拟机（或容器节点）概率性卡住的故障。核心修复方案是通过修改kernel.printk内核参数，调整内核日志输出级别，以规避触发死锁的代码路径。适用于用户报告EulerOS 2.9节点上的虚拟机或Pod无响应、卡住，且故障现象表现为系统进程调度异常，可能与CPU cgroup带宽设置相关的场景。……
---
# EulerOS 2.9内核缺陷导致虚拟机卡住
## 概述 (Overview)
此技能用于处理在EulerOS 2.9操作系统上，由于特定内核版本存在调度缺陷，导致虚拟机（或容器节点）概率性卡住的故障。核心修复方案是通过修改 `kernel.printk` 内核参数，调整内核日志输出级别，以规避触发死锁的代码路径。
## 何时使用此技能 (When to Use)
- 用户报告EulerOS 2.9节点上的虚拟机或Pod无响应、卡住。
- 故障现象表现为系统进程调度异常，可能与CPU cgroup带宽设置相关。
- 需要根据特定内核版本（x86_64或aarch64）应用不同的修复参数。
## 核心指令 (Core Instructions)
> 本技能遵循**条件分支工作流**。首先必须确认内核版本，然后根据架构分支执行不同的修复命令。修复操作涉及系统配置更改，需由用户自行执行或在授权下操作。
### 步骤 1：确认内核版本与架构
**目标**：验证当前节点是否属于受影响的确切版本范围。
……（略）
### 步骤 2：检查并修复 kernel.printk 配置
**目标**：查看并移除 `/etc/sysctl.conf` 中已有的 `kernel.printk` 设置。
> 此步骤为两个分支的公共前置步骤。
……（略）
### 步骤 3：应用修复配置（条件分支）
**目标**：根据系统架构，动态设置正确的 `kernel.printk` 参数值。
……（略）
步骤2：Skill评测
随后将生成的skill安装到Agent（已支持OpenClaw/OpenCode/ClaudeCode等主流Agent）上，并开始执行故障排除任务，过程中Skill-insight将自动采集与追踪各种数据，可展示准确率、时延、Token、价格成本等核心指标，如下图：
同时可生成动态执行流程图，并与Skill中定义的流程进行对比，清晰标识未按预期执行的步骤，对于本例中Skill定义的10个步骤中，实际执行时被跳过1个步骤、非预期调用3个步骤，并有1个步骤发生部分偏离。
同时，可对评测结果中发现的缺陷自动分析原因，例如，在本案例中分析到主要不足在于“Skill中缺少备份与回滚操作”导致。
步骤3：数据驱动的Skill优化
基于上一步中捕捉到的过程数据与缺陷原因，Skill-insight能够自动进行优化，从优化前后对比结果中可以看到，在Skill.md中自动加入了“备份与回滚”操作的内容。 优化前的Skill.md：
### 步骤 2：检查并修复 kernel.printk 配置
**目标**：修改 `kernel.printk` 内核参数，以规避已知的内核死锁路径。
1. **执行检查**：查看当前 `/etc/sysctl.conf` 文件中的 `kernel.printk` 配置。
```bash
grep \"kernel.printk\" /etc/sysctl.conf
```
优化后的Skill.md：
## 步骤 2：检查并修复 kernel.printk 配置
**目标**：修改 `kernel.printk` 内核参数，以规避已知的内核死锁路径。
1. **执行检查与备份**：查看当前 `/etc/sysctl.conf` 文件中的 `kernel.printk` 配置，并备份原始值。
```bash
# 检查当前配置
grep "kernel.printk" /etc/sysctl.conf
# 备份当前运行时参数（用于可能的回滚）
CURRENT_PRINTK=$(sysctl -n kernel.printk)
echo "当前 kernel.printk 运行时参数为: $CURRENT_PRINTK"
echo "如需回滚，可执行: sysctl -w kernel.printk=\"$CURRENT_PRINTK\""
```
同时，对于优化后的Skill执行同一任务，由于增加了备份与回滚操作，可在指标趋势图中清晰看到效果类核心指标的提升，本例中准确率得分从0.7提升到0.8（满分为1）。
结语：告别Skill“盲盒”，让Agent精准可迭代
智能运维的未来，不在于Agent能处理多少种故障，而在于能否以标准化、可追溯、可优化的方式来开发和运行Skill，从而稳定、高效、低成本地解决故障，从Agent精准可迭代，从“能执行”走向“善执行”——这正是Skill-insight的核心思路：
- 以语义聚合去除Skill冗余，解决召回率与成本难题；
- 以多维评测与过程追溯，保障Agent执行可靠、风险可控；
- 以全链路数据驱动优化，让Skill实现持续自进化；
如果你正在构建各类Agent、优化Skill，探索AI在各行业中的落地： 欢迎加入 openEuler 社区，一起让Agent真正落地，降低执行成本、提升执行可靠性。
👉 项目地址：atomgit.com/openeuler/w…
参考资料：
[1] When Single-Agent with Skills Replace Multi-Agent Systems and When They Fail (arxiv.org/abs/2601.04…)
