25—AI Skill 测评结果能否跨次比较：SkillSentry 从一次性测评到质量基础设施

前几篇分别讲了状态机、断点续跑、Tool-as-Code 和工具箱化。把它们放在一起看，SkillSentry 的定位已经发生变化：它不再只是"帮你测一次"的工具，而是在向可复现、可比较、可接入 CI 的质量基础设施演进。

本文是架构可靠性专题的收束篇。它不强调某一个脚本，而是回答一个更大的问题：当今天测出来 91%、昨天测出来 87%，我们到底是在看真实进步，还是只是在看用例、模型和流程漂移？

核心结论：SkillSentry v1 每次测评用不同的 AI 生成用例，导致结果无法跨次比较、无法接入 CI、无法发现多 Skill 组合冲突。v2 通过四项工程化变化解决这三个问题：Eval Harness（用例 YAML 版本化）、精确触发率测量（接 CLI 环境）、Cross-Skill Coordinator（多 Skill 冲突检测）和生命周期管理（规则时效 + 模型版本扫描）。与 v1 完全兼容，零迁移开销。

[一、为什么 v1 不够用：三个根本问题](#一、为什么 v1 不够用：三个根本问题 "#%E4%B8%80%E4%B8%BA%E4%BB%80%E4%B9%88-v1-%E4%B8%8D%E5%A4%9F%E7%94%A8%E4%B8%89%E4%B8%AA%E6%A0%B9%E6%9C%AC%E9%97%AE%E9%A2%98")
二、外部研究给出的信号：问题比我们想的更普遍
[三、v2 的设计目标：从流程到基础设施](#三、v2 的设计目标：从流程到基础设施 "#%E4%B8%89v2-%E7%9A%84%E8%AE%BE%E8%AE%A1%E7%9B%AE%E6%A0%87")
[四、核心变化一：Eval Harness 化](#四、核心变化一：Eval Harness 化 "#%E5%9B%9B%E6%A0%B8%E5%BF%83%E5%8F%98%E5%8C%96%E4%B8%80eval-harness-%E5%8C%96")
五、核心变化二：精确触发率测量
[六、核心变化三：Cross-Skill 协调层](#六、核心变化三：Cross-Skill 协调层 "#%E5%85%AD%E6%A0%B8%E5%BF%83%E5%8F%98%E5%8C%96%E4%B8%89cross-skill-%E5%8D%8F%E8%B0%83%E5%B1%82")
[七、核心变化四：Skill 生命周期管理](#七、核心变化四：Skill 生命周期管理 "#%E4%B8%83%E6%A0%B8%E5%BF%83%E5%8F%98%E5%8C%96%E5%9B%9Bskill-%E7%94%9F%E5%91%BD%E5%91%A8%E6%9C%9F%E7%AE%A1%E7%90%86")
[八、v1 vs v2：一张对照表](#八、v1 vs v2：一张对照表 "#%E5%85%ABv1-vs-v2%E4%B8%80%E5%BC%A0%E5%AF%B9%E7%85%A7%E8%A1%A8")
[九、诚实面对：v2 也有局限性](#九、诚实面对：v2 也有局限性 "#%E4%B9%9D%E8%AF%9A%E5%AE%9E%E9%9D%A2%E5%AF%B9v2-%E4%B9%9F%E6%9C%89%E5%B1%80%E9%99%90%E6%80%A7")
参考文献

一、为什么 v1 不够用：三个根本问题

SkillSentry v1 解决了三个核心问题：自判卷偏差（执行者与评审者分离）、随机性（多次运行取均值）、负向增益（有/无 Skill 对比测试）。这三个问题在没有任何测评体系时是最大的障碍，v1 解决了它们。

但随着测评体系投入实际使用，另外三个问题开始浮现：

问题一：今天的测评结果无法与昨天比较

每次触发 SkillSentry v1，AI 都会从头生成测试用例。这意味着：

css 复制代码

第一次测评：AI 生成用例 A、B、C → 通过率 87%
修改 SKILL.md 后第二次测评：AI 生成用例 D、E、F → 通过率 91%

这 91% 比 87% 更好吗？不知道。因为两次测的根本不是同一件事。

这是测评体系最根本的可信度问题：没有固定基线，通过率的历史变化没有意义。

问题二：无法接入 CI

代码仓库里的 SKILL.md 改了，想自动触发测评、失败时阻断合并------这是软件工程的基本实践。但 v1 做不到，因为每次运行结果不稳定，"通过"的标准不固定，无法作为 CI gate。

问题三：单个 Skill 通过，多个 Skill 协作时的冲突无人发现

v1 只测单个 Skill。但生产环境里往往有多个 Skill 共存，会出现：

两个 Skill 的 description 语义重叠，同一句话触发两个
Skill A 在上下文里留下的状态影响了 Skill B 的判断
两个 Skill 的 P0 规则互相矛盾

这三类问题在 v1 的测评框架里完全不可见。

二、外部研究给出的信号

在开始设计 v2 之前，我们回顾了两篇相关研究，它们对上述问题提供了更广泛的视角。

SkillsBench（Li et al., arXiv:2602.12670, 2026）

这是迄今为止最系统化的 AI Skill 效果基准测试，覆盖 86 个任务、11 个领域、7 种模型配置、7,308 条执行轨迹。

核心数据：

Curated Skills（人工精心设计的 Skill）使平均通过率提升 16.2 个百分点
16/84 个任务（约 19%）出现负向增益------加了 Skill 之后通过率反而下降
Self-generated Skills 平均没有任何收益------模型无法可靠地撰写它自己能从中受益的程序性知识
Focused Skills（2-3 个模块）显著优于大而全的综合文档型 Skill

SkillsBench 的研究方法对 v2 有直接启示：它采用了固定的测试集（deterministic verifiers + curated task set），这正是 Eval Harness 化的学术依据------没有固定测试集，就没有可比较的通过率数字。

AI Agents That Matter（Kapoor et al., arXiv:2407.01502, 2024）

这篇来自普林斯顿的论文对 AI Agent 评测实践提出了系统性批评，其中与 SkillSentry 直接相关的两个发现：

"SOTA agents are needlessly complex and costly."（当前最优 Agent 过度复杂且昂贵）

这支持了 v2 在生命周期管理中加入复杂度检测的决策：通过率达标但复杂度过高的 Skill，应该被标注并提示优化。

"There is a lack of standardization in evaluation practices, leading to a pervasive lack of reproducibility."（评测实践缺乏标准化，导致普遍的不可重现性）

这是 Eval Harness 化最直接的外部支撑------不可重现是评测体系的设计缺陷，不是偶发问题。

这两篇研究指向同一个结论：可重现性不是"有更好"的加分项，而是测评结论能否被信任的前提条件。 一个每次测评用不同用例的系统，产出的通过率数字只是参考，不是证据。v2 的最高优先级由此确定：先解决可重现性，其他一切建立在它之上。

三、v2 的设计目标

基于上述分析，v2 确立了四个设计目标：

目标	对应问题	核心原则
测评结果可重现	每次用例不同，无法历史对比	Eval Harness：用例版本化，首次 AI 生成后固定
支持 CI 集成	结果不稳定，无法作为 CI gate	Git hook：SKILL.md 变更自动触发固定用例集测评
覆盖多 Skill 协作	单 Skill 通过不代表组合没问题	Cross-Skill Coordinator：分析冲突，生成组合用例
持续质量护栏	测评是一次性动作，不是持续监控	生命周期管理：规则有效期 + 模型版本兼容性扫描

一条贯穿全部设计的原则（来自工程实践资料）：

先使用能够解决问题的最简单方案，只有在简单方案不够时再增加复杂度。

v2 的所有变化都是在 v1 的 Orchestrator-Workers 架构上叠加，不重写，不引入 Swarm 或复杂的去中心化机制。v1 已经在用的四层验证体系（Executor → 精确校验 → 独立 Grader → 盲测对比）完整保留。

四、核心变化一：Eval Harness 化

这是 v2 最核心的架构变化，也是解决"不可重现"问题的直接手段。

什么是 Eval Harness

借用软件测试领域的概念：Eval Harness 是一套把测试用例、执行环境、评分逻辑打包在一起的测评脚手架，核心特征是可重现------同一个 Skill，用同一套测试集，今天跑和明天跑得到可比较的结果。

EleutherAI 的 lm-evaluation-harness 是 LLM 评测领域最著名的 harness 实现，SkillsBench 也采用了类似的设计（固定 benchmark + deterministic verifiers）。v2 将这个思路引入到 SkillSentry 的日常测评中。

具体实现

用例存储格式：YAML 文件，按用例类型分文件存放

bash 复制代码

inputs/
└── skill-name/
    └── cases/
        ├── happy-path.yaml       # 正常路径用例
        ├── business-logic.yaml   # 业务逻辑用例
        ├── e2e.yaml              # 端到端用例
        └── robustness.yaml       # 鲁棒性用例

每条用例包含固定的 id、assertions（带 precision 分级），以及自动更新的历史统计（run_count、last_pass_rate）：

yaml 复制代码

cases:
  - id: "HP-001"
    type: "happy_path"
    display_name: "标准日常餐费报销"
    priority: "P1"
    prompt: "帮我报销一张昨天的午餐发票，金额120元"
    assertions:
      - id: "HP-001-A1"
        precision: "exact_match"    # 精确断言：计入发布准入判断
        rule_ref: "R-03"
        description: "调用 saveExpenseDoc，docStatus 参数值为 '10'（草稿状态）"
    metadata:
      run_count: 3
      last_pass_rate: 0.89

执行逻辑的变化：

markdown 复制代码

v1 流程：
  触发测评 → AI 分析规则 → AI 生成用例 → 执行 → 报告
                                ↑
                          每次重新生成，不可重现

v2 流程：
  触发测评 → 检查 cases/ 目录是否存在
              ├── 存在：加载历史用例 → AI 仅补齐未覆盖路径 → 执行 → 报告 + 历史对比
              └── 不存在（首次）：AI 生成全量用例 → 执行 → 自动保存为 YAML → 报告

报告新增"历史对比"章节：

erlang 复制代码

历史通过率对比
┌──────────┬──────────┬──────────┬────────┐
│ 用例ID   │ 历史通过率 │ 本次通过率 │ 变化   │
├──────────┼──────────┼──────────┼────────┤
│ HP-001   │ 89%      │ 94%      │ ↑ +5%  │
│ BL-003   │ 100%     │ 100%     │ ---      │
│ E2E-001  │ 75%      │ 83%      │ ↑ +8%  │
└──────────┴──────────┴──────────┴────────┘
总体趋势：↑ 进步（本次 89% vs 历史均值 84%）

这一张表回答了一个 v1 无法回答的问题：这次改动，让 Skill 变好了还是变差了？

向后兼容 v1

v2 完全兼容 v1 的 custom.cases.md 格式，加载优先级为 YAML > Markdown。v1 用户不需要迁移任何文件，升级到 v2 后首次测评自动生成并保存 YAML 用例。

从 v1 迁移到 v2：三步完成

vbnet 复制代码

Step 1：安装 v2（独立目录，不覆盖 v1）
  获取 v2 发布包并放入独立目录
  将 SkillSentry-v2/ 目录放入 <skills-root>/

Step 2：触发首次测评（与 v1 语法完全相同）
  测评 [skill-name]
  → v2 自动检测无历史用例，生成并保存 YAML 用例集

Step 3：后续测评直接复用历史用例
  再次触发：测评 [skill-name]
  → 加载历史 YAML，结果自动对比历史通过率

迁移零风险：v1 的 sessions/、inputs/ 目录和所有历史报告完整保留，v2 在独立目录下运行。

五、核心变化二：精确触发率测量

v1 已有 AI 模拟触发率估算（阶段一），但它的局限性是：这是模型自己判断"自己会不会触发"，置信度有限。

v2 新增了一条精确测量路径，通过检测目标 CLI 是否可用来选择执行模式：

bash 复制代码

检测 CLI 环境
  ├── 可用 + 模式为 standard/full
  │   → trigger-eval.py：生成 20 条 eval query
  │     - 10 条「应触发」（TP，True Positive）：真实用户会说的触发语句
  │     - 10 条「不应触发」（TN，True Negative）：含相关词但意图不符的语句
  │     → 60/40 分成 train/test，按 test 分数输出精确触发率
  │     → 结果标注「精确测量」，写入 trigger_eval_precise.json
  │
  └── 不可用 或 quick 模式
      → 沿用 AI 模拟估算
      → 结果标注「AI 估算，建议 standard 模式精确测量」

这个设计（60/40 train/test 分割，确保按测试集而非训练集分数选最优 description，避免优化过度适配已知测试 prompt）复用了 skill-creator 的 run_eval.py 核心思路，而不是重新发明。

为什么触发率是最重要的指标之一：

触发率为 60% 的 Skill，哪怕触发后执行完美，实际用起来也是废的------40% 的场景根本不走这个 Skill。v1 的四层验证体系测的是"触发后的行为质量"，但触发率本身直到阶段一才有粗略估算，且置信度不稳定。v2 在这一点上有实质提升。

六、核心变化三：Cross-Skill 协调层

这是 v2 新增的最复杂能力，也是解决"多 Skill 协作盲区"的核心手段。

问题的本质

SkillsBench 的研究发现，19% 的 Skill 会产生负向增益。SkillsBench 原文（arXiv:2602.12670）指出，负向增益的成因包括三类：Skill 规则与模型本身的能力冲突、规则描述存在歧义、Skill 设计过度复杂。在 SkillSentry v1 的实际运行记录中，我们还观察到另一类来源：单个 Skill 的设计没问题，但它与其他 Skill 共存时会产生规则冲突或状态污染------这类问题在单 Skill 测评中完全不可见。

在软件工程里，单元测试全部通过不代表集成测试没问题------原因完全相同：组件间的交互会产生单元测试中不可见的新问题。

三类跨 Skill 冲突

在 SkillSentry v1 对多个生产 Skill 的测评记录中（包含报销、考勤、数据查询等业务场景），跨 Skill 冲突集中在三种模式：

冲突一：触发竞争 两个 Skill 的 description 语义重叠，同一句话可能同时触发两个：

css 复制代码

Skill A：帮用户处理报销相关事务
Skill B：帮用户查询财务数据
用户说："帮我查一下上个月的报销记录"
→ A 和 B 都认为该触发，模型随机选一个，行为不稳定

冲突二：上下文污染 Skill A 执行后留在上下文里的状态影响了 Skill B 的判断：

css 复制代码

Skill A（报销）收集了用户的部门信息
Skill B（考勤）触发时直接读取了这个部门信息
→ 用户换了部门但 Skill B 用了旧数据

冲突三：规则矛盾 两个 Skill 的 P0 规则在同一场景下要求相反的行为：

css 复制代码

Skill A P0："禁止直接 HTTP 请求，所有接口通过 MCP"
Skill B："调用外部天气 API 获取出差目的地天气"
→ Skill B 的行为违反了全局 P0 约束

Cross-Skill Coordinator 的工作方式

新增了一个 cross-skill-coordinator.md Agent，在用户触发"多 Skill 测评"时激活：

vbnet 复制代码

接收：多个 Skill 路径
    ↓
Step 1：description 语义重叠分析（生成 overlap_matrix.json）
    ↓
Step 2：P0 规则冲突检测（生成 rule_conflicts.json）
    ↓
Step 3：设计跨 Skill E2E 用例（针对每类风险）
    ↓
Step 4：协调各 Skill 的 SkillSentry 主 Agent 并行执行
    ↓
Step 5：生成组合风险报告（覆盖风险等级、修复建议）

架构选择说明：这是在现有 Orchestrator-Workers 架构上加了一层协调层，不是 Swarm（去中心化多 Agent）。Swarm 的核心优势是"任务边界不确定时的自适应"，而 SkillSentry 的任务边界非常确定（固定 6 阶段流程）。按简单性优先原则：先用最简单的解决方案，只在简单方案不够时才增加复杂度。

七、核心变化四：Skill 生命周期管理

测评不是发布前的一次性动作，而是持续运行的质量护栏。v2 用 lifecycle-scanner.py 实现了三项生命周期扫描：

7.1 规则时效性扫描

SKILL.md 中可以为规则标注有效期：

markdown 复制代码

## 超标校验规则（最后验证：2026-03，下次复核：2026-06）
checkExpenseItem 返回 exceededMoney 时，自动扣减...

扫描器定期检查这些标注，临近到期（30 天内）发出 ⚠️ 警告，过期后发出 ❌ 严重告警。这解决了一个现实问题：业务规则变了，但 Skill 没更新，导致测评通过了但线上行为是错的。

7.2 模型版本兼容性检测

将上次测评使用的模型版本（记录在 eval_environment.json 的 model 字段）与当前模型版本对比。版本变化时自动提醒重新运行 standard 测评。

这个设计的必要性：模型升级带来底层推理行为的静默变化，没有任何报错，表面功能看起来正常，但某些边界场景的处理已经悄悄改变。

7.3 陈旧测评检测

上次测评距今超过 90 天的 S/A 级 Skill 自动提醒复核。

运行方式：

bash 复制代码

# 手动触发（任意时间运行）
python3 <skills-root>/SkillSentry-v2/scripts/lifecycle-scanner.py \
  --skills-dir <skills-root> \
  --sessions-dir <skills-root>/SkillSentry-v2/sessions

# 定期触发（建议：每周一次，加入 crontab）
# crontab -e 中加入：
# 0 9 * * 1 python3 <skills-root>/SkillSentry-v2/scripts/lifecycle-scanner.py ...

# post-merge hook 中也会自动运行，merge 后无需手动执行

Git hook 集成

hooks/pre-push 和 hooks/post-merge 将上述检测接入 Git 工作流。

安装方式（在 skills 仓库根目录执行）：

bash 复制代码

# 复制 hook 文件
cp <skills-root>/SkillSentry-v2/hooks/pre-push .git/hooks/pre-push
cp <skills-root>/SkillSentry-v2/hooks/post-merge .git/hooks/post-merge

# 赋予可执行权限
chmod +x .git/hooks/pre-push .git/hooks/post-merge

触发行为：

bash 复制代码

# pre-push：检测 SKILL.md 变更，自动触发 quick 测评
# 任何 Skill 返回 FAIL → 阻断 push，输出失败 Skill 列表
# 全部 PASS/CONDITIONAL PASS → 允许 push

# post-merge：merge 后自动运行生命周期扫描
# 输出过期规则、模型版本变化、陈旧测评的汇总告警

八、v1 vs v2：一张对照表

维度	SkillSentry v1	SkillSentry v2
用例来源	AI 每次现生成	首次 AI 生成，此后加载历史 YAML
结果可重现性	❌ 每次用例不同	✅ 同一用例集，历史可对比
CI 集成	❌ 无法作为 CI gate	✅ git hook，FAIL 阻断 push
触发率	AI 模拟估算（阶段一）	AI 估算 + 精确测量（接 CLI 环境）
跨 Skill 协作	❌ 无覆盖	✅ Cross-Skill Coordinator
生命周期	❌ 发布后无跟踪	✅ 规则有效期 + 模型版本 + 陈旧告警
与 v1 兼容性	---	✅ 完全兼容，零迁移开销
架构复杂度	Orchestrator-Workers	Orchestrator-Workers + 协调层（叠加，不重写）

九、诚实面对：v2 也有局限性

权威的技术写作必须诚实说明局限性。v2 解决了 v1 的核心问题，但它仍然有边界：

1. 用例质量仍然依赖首次 AI 生成的质量

首次测评时，YAML 用例是由 AI 生成的。如果首次生成质量差（存在性断言过多，规则覆盖不全），后续的"历史复用"只会固化这些问题，而不是修复它们。定期人工审查用例质量仍然必要。

2. Cross-Skill Coordinator 是分析工具，不是执行保障

Coordinator 能发现 description 语义重叠和 P0 规则矛盾，但它不能阻止已发布的 Skill 在生产环境中互相干扰。真正的保障需要在系统层（P0 规则写在全局系统提示词，而非单个 Skill）实现。

3. 精确触发率测量依赖 CLI 环境

trigger-eval.py 的精确测量路径需要目标 CLI 已安装并正确认证。在不具备目标 CLI 的环境中，会自动回退到 AI 模拟估算，报告会标注这一点。

4. 生命周期管理需要人工维护规则有效期标注

lifecycle-scanner.py 只能扫描已标注了有效期的规则。如果 SKILL.md 中没有添加 最后验证: YYYY-MM 的注释，扫描器无法判断规则是否过期。这需要 Skill 作者养成标注习惯。

结语

SkillSentry v1 回答了"这个 Skill 有没有问题"。

SkillSentry v2 回答的是：

"这个 Skill 和上次相比，是进步了还是退步了？"
"这次代码提交，有没有破坏已有的 Skill 行为？"
"多个 Skill 共存时，会不会互相干扰？"
"这个规则三个月前验证的，现在还有效吗？"

这四个问题，是 Skill 从"能用"到"可持续维护"的分水岭。

v2 的完整实现保持独立目录结构，不修改任何现有文件。

参考文献

来源	作者	年份	本文关联
SkillsBench: Benchmarking How Well Agent Skills Work Across Diverse Tasks · arXiv:2602.12670	Li et al.	2026	第二节：固定测试集的必要性（19% 负向增益数据、16.2pp 提升数据）；Eval Harness 化的学术依据
AI Agents That Matter · arXiv:2407.01502	Kapoor et al.（普林斯顿）	2024	第二节：评测不可重现性的系统性问题；第七节：复杂度控制的理论依据
Building Effective Agents · 工程实践文章	Schluntz & Zhang	2024	第三节：简单性优先原则；第六节：Cross-Skill 架构选择（不用 Swarm 的依据）
SkillSentry v1 · 内部工程实践	SkillSentry 项目	2026	v1 的三个核心问题（不可重现、不可 CI、跨 Skill 盲区）均来自 v1 实际运行的直接观察，非推断