上一篇我们聊了人为 Skill（人工技能）相比裸模型和自生成 Skill 究竟有没有价值。只要进入对比评估，就会遇到一个很棘手的问题：评审者一旦清楚哪份输出来自 `with_skill`，就容易把预期直接写进结论里，导致评估结果出现偏差。

所以 SkillSentry 在 standard/full 模式下，将对比过程拆成了两个步骤：首先由 Comparator 进行盲测，比较 A/B 两份输出的质量；再由 Analyzer 解盲，将结果归因到 SKILL.md 的具体规则。这篇文章就专门聊聊，这两个步骤为什么需要分开执行。 说明一下：本文中的 A/B 是 Comparator 随机分配的盲测标签，与上一篇三条件对比中的条件 A（without）、B（curated）、C（self-generated）不是同一概念。这里的 A/B 仅表示“两份待比较的输出”，目的是隐藏哪份来自 `with_skill`。

先问一个根本问题：凭什么判断一个 Skill 真的有用？

SkillSentry 的核心命题其实很直观：这个 Skill 到底有没有实际价值？ 通过率能够告诉你的是“Skill 是否完成了任务”，但它回答不了另一个关键问题——没有这个 Skill 的时候，AI 是否也能完成同样的任务？ 如果 AI 裸跑也能做对，那这个 Skill 的价值就是零。三条件对比范式的核心逻辑就在这里，但对比本身存在一个大坑：确认偏误（confirmation bias）。

确认偏误：为什么“直接比”不靠谱

假设你同时看到两份输出，并且知道哪份是 `with_skill`： > Output A（with_skill）：格式整齐，字段完整 > Output B（without_skill）：格式稍乱，但信息基本正确 你的第一反应很可能是：“A 明显更好——格式规范、结构清晰。”但如果你不知道哪份有 Skill，你可能会注意到另一个细节：“B 虽然格式乱了点，但回答了一些 A 压根没涉及的边界问题。” 这就是确认偏误的核心陷阱——你以为是客观评判，其实已经戴着有色眼镜了。当你知道预期答案时，会无意识地对预期答案放低标准，同时对非预期答案抬高标准。 Comparator 的解法很干脆：在不揭盲的情况下做判断，把这种偏误直接扼杀在摇篮里。

Comparator：盲测怎么玩

核心设计

``` 输入： - output_a_path：标记为 A 的输出 - output_b_path：标记为 B 的输出 - eval_prompt：原始测评 prompt - expectations：断言列表（可为空） 关键约束： - Comparator 不知道 A 和 B 哪个是 with_skill - A/B 的分配是随机的（有时 with_skill 是 A，有时是 B） ``` 随机分配 A/B 标签进一步确保了盲性——如果 with_skill 永远都是 A，评判者难免会无意识地偏向 A。

评分体系：10 分制 rubric

Comparator 从两个维度打分： **内容维度（Content）**： - 正确性（1-5）：信息是否准确 - 完整性（1-5）：是否回答了所有要素 - 准确性（1-5）：细节是否精确 **结构维度（Structure）**： - 组织性（1-5）：信息是否有逻辑层次 - 格式规范（1-5）：格式是否清晰易读 - 可用性（1-5）：用户能否直接上手使用 综合得分 = (内容均值 + 结构均值) / 2 × 2 → 10 分制

按 Skill 类型调整评分维度

skill_type	额外维度
mcp_based	字段完整性、工具调用正确性、链接可用性
text_generation	规则遵守度、内容准确性、格式规范
code_execution	命令执行正确性、文件生成完整性、错误处理

这样能保证评分对不同类型的 Skill 都有针对性，不是一套模板走天下。

Verdict：三档判决

``` A 得分 > B 得分 → winner: "A" B 得分 > A 得分 → winner: "B" 差距 < 0.5 分 → winner: "TIE" ``` 设计原则很明确：要有决断力。TIE 应该是极少数情况——如果两份输出真的无法区分，那本身就是一个重要发现：说明这个 Skill 对这个用例的增益为零。

text_generation Skill 的特殊处理

纯文本生成的 Skill（比如写邮件、生成报告）评判起来最棘手——两份输出表面上可能都挺通顺，看不出太大区别。 Comparator 对这类 Skill 的判决标准： - 有没有 H2 章节结构（如果 SKILL.md 有要求的话） - 是否在字数限制内 - 是否遵守了“不得出现 XX”的禁止规则 - 如果两份在规则遵守度上完全没差异，那 TIE 就是合理结论

Analyzer：解盲以后做什么

角色转换

Comparator 做完盲测后，就该 Analyzer 上场“解盲”了——知道了 A/B 对应关系之后，做因果分析： ``` 输入： - winner + winner_is_with_skill（解盲信息） - evaluated_skill_path（被测 Skill） - with_skill_transcript_path（完整执行记录） - without_skill_transcript_path - comparison_result_path（Comparator 的盲测结论） ```

两种解盲结果

**正常情况：winner_is_with_skill = true** ``` with_skill 赢了 → Skill 有正面增益 分析方向： - 为什么赢了？Skill 中哪些指令导致了更好的行为？ - 改进建议：锦上添花，进一步优化 ``` **异常情况：winner_is_with_skill = false** ``` without_skill 赢了 → Skill 反而拖累了输出 ⚠️ 分析方向： - 为什么输了？Skill 中哪些规则是有害的？ - 改进建议：优先级最高（Skill 里有明确有害规则，需要立刻移除） ```

分析流程

``` Step 1：读取 Comparator 盲测结论（理解评判维度和理由） Step 2：读取 SKILL.md（理解指令设计意图） Step 3：读取双方 transcript（对比执行模式差异） Step 4：识别胜出原因（Skill 的哪些指令产生了正面效果） Step 5：识别失败原因（缺少什么导致了更差的行为） Step 6：生成改进建议（优先级排序，可操作） ```

改进建议的结构

每条建议包含四个要素： ``` { "priority": "high", // high/medium/low "category": "instructions", // instructions/tools/examples/error_handling/structure/references "suggestion": "在 sa veExpenseDoc 调用前加断言：docStatus 必须为 '10'", "expected_impact": "防止 Agent 误将草稿提交为正式审批" } ``` 六个 category 的详细解释：

类别	含义	示例
instructions	SKILL.md 文字指令改动	「增加约束：禁止使用 CSV 中的静态编码」
tools	增加/修改脚本或工具	「增加 validate_input.py 校验输入格式」
examples	补充示例	「增加边界情况的正确输出示例」
error_handling	错误处理指导	「MCP 超时时应重试一次，而非直接放弃」
structure	SKILL.md 结构重组	「将硬性前置检查从文档中间移到开头」
references	新增参考文件	「增加 field_mapping.json 避免 Agent 猜测字段名」

指令遵循率

Analyzer 还会输出一个“指令遵循率”评分（1-10）： ``` "instruction_following": { "winner": { "score": 9, "issues": ["Step 1.2 文件上传后验证被跳过（非关键）"] }, "loser": { "score": 3, "issues": [ "未调用 queryExpenseItems，直接使用 CSV 静态编码", "docStatus 设为 20 而非 10", "sa veExpenseDoc 成功后未构建详情链接" ] } } ``` 这个分数直接反映了 Skill 的指令清晰度——如果 with_skill 的指令遵循率只有 5 分，说明 SKILL.md 写得不够清晰，AI 读了但没做对。

在 Pipeline 中的位置

Comparator 和 Analyzer 只在 standard/full 模式下触发： ``` Pipeline: smoke: [...] → grader-report → done quick: [...] → grader-report → done standard: [...] → executor-without → comparator → grader-report → gate → publish full: [...] → executor-without → comparator → analyzer → grader-report → gate → publish ``` 为什么 quick 不跑对比？因为对比需要 without_skill 的执行记录——这意味着每个 eval 要跑两遍（一遍有 Skill、一遍无 Skill），时间和开销直接翻倍。quick 模式定位是“快速验证”，翻倍显然不可接受。 当前版本的 baseline 规则更精确： | 模式 | without_skill | Delta | |------|--------------|-------| | `smoke` | `mcp_based` 默认跳过 | `N/A` | | `quick` | `mcp_based` 默认跳过 | `N/A` | | `standard` | 默认保留可比较 baseline | computed / partial / N/A | | `full` | 默认保留可比较 baseline | computed / partial / N/A | 所以这篇文章讨论的是“如何量化增益”，并不是说每次测评都必须跑 comparator/analyzer。

数据流

``` executor 产出： eval-N/run-R/with_skill/outputs/transcript.md + response.md eval-N/run-R/without_skill/outputs/transcript.md + response.md comparator 输入： 随机选择一个 run 的 with_skill 和 without_skill 输出 随机分配为 A/B comparator 输出： eval-N/comparison.json（盲测结论） analyzer 输入： comparison.json + 解盲信息 + SKILL.md + 双方 transcript analyzer 输出： eval-N/analysis.json（因果分析 + 改进建议） ```

实际案例

以报销 Skill 测评为例：

Comparator 盲测结论

``` { "winner": "A", "reasoning": "A 的输出包含完整的报销主题、金额、收款账户、资源用量明细和可用的详情链接。B 缺少收款账户字段，详情链接含字面占位符 {fdId}，无法直接使用。", "rubric": { "A": { "overall_score": 9.0 }, "B": { "overall_score": 5.4 } } } ```

解盲后得知：A = with_skill

Analyzer 输出

``` { "winner_strengths": [ "SKILL.md Step5 S3 明确断言『链接中不得包含 {fdId} 字面占位符』，Agent 因此在输出前做了校验", "workflow.md 提供了 fdMonthOfOccurrence 精确计算公式，避免了计算错误" ], "loser_weaknesses": [ "无 Skill 指导时 Agent 不知道需要调用 queryExpenseItems，直接用 CSV 静态编码", "无 docStatus 约束，Agent 将 docStatus 设为 20（直接提交），违反只保存草稿要求" ], "improvement_suggestions": [ { "priority": "high", "category": "instructions", "suggestion": "明确：资源用量类型 fdExpenseItemId 必须来自 queryExpenseItems 接口，禁止使用 CSV 编码", "expected_impact": "消除直接使用 CSV 编码的行为" } ] } ``` 这个案例的价值在于：它从“A 比 B 好”推到了“好在哪里、因为 SKILL.md 的哪条指令”——这才是真正可操作的洞察。

与 Grader 的关系

	Grader	Comparator + Analyzer
问的问题	「这个输出满足断言吗？」	「两个输出哪个更好？为什么？」
评判方式	逐条断言 pass/fail	整体质量 10 分制
是否需要对照	不需要（只看 with_skill）	需要（比较 with vs without）
输出	通过率	胜负 + 归因 + 建议
用途	准入判定（能不能上线）	增益量化（值不值得上线）

两者互补： - 通过率高 + 对比赢 = 放心上线 - 通过率高 + 对比输/平 = Skill 可能有冗余规则（做对了不是因为 Skill） - 通过率低 + 对比赢 = Skill 方向对但断言太严 - 通过率低 + 对比输 = Skill 有问题，需要修

设计决策：为什么分成两步

为什么不让一个 Agent 同时做盲测 + 分析？这里有几个关键原因： **1. 保证盲性的纯粹性** 如果同一个 Agent 先盲测再解盲，它很可能在盲测阶段就“猜到”哪个是 with_skill（比如输出格式明显更规范的那个）。分成两个独立的 Agent，物理上就隔离了盲性。 **2. Comparator 的判断可以被审计** 独立的 comparison.json 是可审计的——如果解盲后发现 Comparator 判错了（盲测说 B 好，但 B 是 without_skill），这本身就是一个重要信号：说明 Skill 在这个用例上没有增益。 **3. 串行依赖是自然的** Analyzer 必须知道 Comparator 的结论才能做归因分析——这是逻辑上的依赖，不是人为拆分。

FAQ

**Q：如果 Comparator 判了 TIE，Analyzer 还需要跑吗？** 需要。TIE 意味着“Skill 对这个用例没有可观测的增益”——Analyzer 需要分析为什么没有增益，是 Skill 覆盖不到这类场景，还是 AI 本身就能做好。 **Q：随机分配 A/B 的种子是什么？** 用 `eval_id + run_id` 作为种子的 hash。保证同一个 eval 的不同 run 分配一致，但不同 eval 之间随机。 **Q：对比测试的开销大吗？** Comparator 读两份输出 + 做评分：约 3K token/eval Analyzer 读 transcript + 做分析：约 5K token/eval 33 个 eval 全跑：约 264K token，属于中等资源用量。实际消耗会随输出长度、transcript 大小和模型上下文变化，这里只作为量级估算。 这就是为什么只在 standard/full 模式下才触发——在完整测评已有较高 token 消耗的基础上增加一次对比分析，用来换取增益量化和改进建议。

下一篇：用外部框架校准自己的测评链路

盲测和解盲解决的是“对比结论如何减少偏见”。但一套测评体系是否完整，还需要放到更通用的 Agent Skill 评估实践里自查：原始 transcript 是否是唯一证据源、硬规则是否能脱离 LLM 验证、报告是否能回溯、版本变化是否能检测退化。 下一篇会用一个四层评估框架来反查 SkillSentry：哪些地方已经做对了，哪些地方还需要补齐。 来源：agents/comparator.md、agents/analyzer.md、SkillSentry contract。