skill-up：把软件测试方法论搬进Agent Skill评测

当Agent Skill成为AI应用的标准配置，一个关键问题浮出水面：Skill的好坏由谁定义？评判标准是什么？很多团队已经积累了数十个自研Skill，从需求拆解到报告产出，覆盖完整工作流。但每次迭代更新时，改了几行提示词，行为是否漂移？跑一遍demo没报错就敢发布吗？这些问题长期缺乏系统性解答。Skill的本质是提示词工程，一字之差可能导致输出完全变形。官方评测指南虽有框架，但全手工操作难以持续。直到阿里开源的skill-up出现，这套评测流程才得以工具化和自动化。

Skill评测的核心痛点

当前Agent Skill领域面临评测标准缺失和手工效率低下的双重困境。官方提供的evaluating-skills指南虽然描述了正确流程——写真实用例、对比有无Skill的输出差异、评分汇总、迭代改进——但整个过程完全依赖人工执行。团队写完一个Skill，跑两下感觉没问题就发布，这种做法在传统软件开发中是不可想象的。软件测试有一条铁规：没有用例、没有回归、没有质量门禁的系统绝不能上线。但到了Skill这件事上，几乎所有人都在裸奔。根本原因在于Skill的输出是非确定性的，传统测试方法难以直接套用，而自动化工具的缺失让持续评测成为奢望。skill-up正是为解决这一空白而生。

skill-up的设计理念与核心功能

skill-up是阿里开源的Agent Skill评测工具，用一句话概括就是Skill的评测与演进工具。它将软件测试的完整方法论平移到Skill领域，支持在Claude Code、Codex等真实Agent Engine中验证功能正确性，将失败转化为有针对性的修复，并可在本地或CI中持续回归。该工具定义了标准化的项目结构：SKILL.md作为被测对象，evals/eval.yaml作为评测入口，cases/目录存放测试用例集，fixtures/管理测试资源和数据，scripts/放置评估脚本。这一结构与标准测试工程完全对应，测试背景的开发者几乎零学习成本。评测配置支持声明式YAML定义引擎、环境和判定方式，工作原理形成评测到进化的闭环。

三种判定器与用例设计实践

skill-up支持三种judge判定方式，对应测试中的不同校验需求。rule_based为规则匹配，验证文件是否存在、内容是否包含关键字，类似精确断言；script通过自定义脚本校验产物结构或运行语法检查；agent_judge则用另一个模型当裁判，按标准给输出打分，即LLM-as-a-Judge，这在大模型评测中已是标配手段。用例设计支持单轮和多轮对话两种模式。单轮对话适用于大多数场景，通过prompt发送输入，结合context加载仓库模板或补丁，constraints定义超时和轮次限制，expect设置must_contain/must_not_contain等门槛，judge指定判定类型。多轮对话通过input.turns处理顺序交互场景，例如迭代优化、阶段门控工作流和澄清循环，每个turn可设置post_condition和on_fail策略。这种设计让Skill评测既能覆盖基础成功路径，也能验证边界条件和回归场景。

skill-upper：用Skill测Skill的套娃实践

项目中最值得关注的是skill-upper这个Agent Skill的套娃设计。skill-upper本身是一个Skill，职责是给其他Skill做测试，形成完整的Eval-to-Evolution Loop。运行流程为：对话生成评测用例、skill-up运行评测产出结构化报告、skill-upper逐条读取失败用例、判断是Skill错误还是用例错误，若是Skill问题则修复SKILL.md和配套文件，若是用例问题则改进eval case和判定器，最后将修复沉淀为回归用例并持续迭代。这与AI测试实战中强调的bad case回流机制完全一致，只是将整个循环自动化了。上手方式有两种：推荐安装skill-upper后用自然语言对话驱动评测，或直接使用命令行工具运行skill-up run/report等命令。报告产物包含grading.json、benchmark对比、JUnit XML和HTML格式，可直接接入CI作为质量门禁。

skill-up的出现为Agent Skill质量保障提供了工程化路径。对于已积累Skill资产的团队，建议立即为高频Skill建立评测集并接入CI；团队应设立独立的质量门禁，避免既当运动员又当裁判。即使不直接编写Skill，这套评测设计——从用例设计、非确定性输出判定到多引擎对比——也是一份完整的Agent评测方法论参考。测试工程师在传统软件测试中积累的经验，在Agent Skill这个新战场上同样适用。