这是2026年的第40篇原创文章
（ 本文阅读时长：约 15 分钟 ）
01
Agent Skill 备受瞩目，但「它究竟好不好用」尚无明确答案
过去一年，Agent Skill 已迅速崛起为 AI 应用生态中的关键基础设施。通过一段 SKILL.md、几个脚本、一组工具声明，就能让智能体掌握一项全新的专业能力：撰写发布计划、执行代码审查、升级依赖库、分析数据等。如今，编写一个能「顺利运行」的 Skill 已非难事，真正的挑战在于回答另一个问题：它的实际表现究竟如何？安装后，Agent 的行为是否完全符合预期？倘若有人修改了一行描述，它是否会不知不觉地退化？切换到另一个 Agent 引擎时，它还能保持一致性吗？
对于传统软件，我们拥有单元测试、集成测试以及 CI 门禁来回答「改动是否破坏了原有功能」。然而，Skill 是提示词、文件与工具配置的复合体，其行为对模型版本、引擎实现以及输入措辞极为敏感。长期以来，我们一直缺少一种「声明一次、随时回放」的机制来固化对它的预期。一旦预期未被明确记录，Skill 的质量就只能依赖肉眼检查和人工记忆来维护，而这恰恰是软件工程中最容易出问题的环节。
为此，阿里巴巴开源了 skill-up：一个专为 Agent Skill 开发者设计的命令行评测框架。它的核心理念是「让 Agent Skill 的每一次迭代都可被验证、可被回归」。
本文将详细阐述四个核心要点：
- skill-up 是什么；
- 它解决了哪些现实中的关键痛点；
- 其设计原理是什么；
- 它在阿里集团内部的真实应用场景。
项目开源地址：github.com/alibaba/skill-up
用户手册：alibaba.github.io/skill-up/zh
02
三个大概率会遇到的典型场景
如果正在编写或维护 Agent Skill，你很可能遭遇以下问题：
场景一：Skill 悄然退化，但评审环节无人察觉。你为团队的发布系统开发了一个 publish-plan Skill，本地测试几次后感觉「差不多了」便发布上线。两周后，同事修改了 SKILL.md 中的一段描述，导致 Skill 在某些输入下不再调用预期的工具，而是退化为纯文本回答。这一变化在代码评审时无人发现，直到用户反馈问题才暴露出来。
场景二：更换引擎，行为随之改变。你编写了一个 code-review Skill，在某个 Agent 引擎上运行良好。团队另一位同事换用另一个引擎后，反馈在相同的提示词下输出结构截然不同。你希望系统性地验证 Skill 在两个引擎下的真实差异，但每次都需要手动触发、人工对比、手工记录，最终这项任务被无限期搁置。
场景三：评测逻辑分散各处，难以复用。为了对一个复杂 Skill 进行评测，你编写了一堆脚本：安装 Skill、调用 Agent、解析输出、对比结果、生成报告。脚本虽然能运行，但评测语义分散在多个脚本和中间文件中，本地一套逻辑、CI 又一套逻辑，新增一条测试用例需要同时修改多处，新人根本无法理解「这条评测究竟在判断什么」。
上述三个场景其实指向同一个核心问题：Skill 缺少一个标准化的评测框架，能够将「加载用例→启动 Agent→发送输入→收集回复→判定是否通过→生成报告」这一整套流程稳定地串联起来，并且可以被本地开发和 CI 流水线共同复用。
03
skill-up 是什么
skill-up 是一个独立的命令行评测框架。你只需在 Skill 目录下放置一份 evals/eval.yaml 和若干 evals/cases/*.yaml 文件，以声明式的方式清晰描述：评测在什么环境中运行、使用哪个 Agent 引擎、执行哪些用例、以及如何判定通过。然后执行一条命令，它便会逐条用例执行并生成结构化的评测报告。
一份最小化的 eval.yaml 示例如下：
schema_version: v1alpha1
environment:
type: none # 本地直接运行；也可选择沙箱化隔离环境
engine:
name: claude_code # 内置多种引擎，一个参数即可切换
cases:
files:
- evals/cases/create_plan.yaml
defaults:
timeout_seconds: 300
max_turns: 10
每条用例是一份独立的 case YAML 文件，描述输入、预期检查项和判定方式：
id: case_create_plan
title: 验证发布计划生成能力
input:
prompt: "请为今天上午 10:30 的 web 系统发布生成一份发布计划"
expect:
must_contain:
- "发布计划"
- "10:30"
judge:
type: agent_judge
criteria:
- "回答是否提供了完整的发布步骤与回滚方案"
- "是否正确调用了发布计划生成工具"
声明完成后，运行：
skill-up run ./evals/eval.yaml
它会逐条用例执行，并产出三类结果：
- 每条断言的通过情况及相关证据（工具是否被调用、输出是否包含关键字段、判定理由）；
- 本次评测的整体通过率、耗时与 token 消耗；
- 一个进程退出码：0 表示全部通过，非0 表示存在失败用例，可直接接入 CI 作为合并门禁。
此外，它还能同时输出 JUnit XML 格式报告和一份可视化的 HTML 报告。
| 维度 | 迁移前（手工搭建流水线） | 迁移后（skill-up） |
|---|---|---|
| 通用执行编排 | 多个 Shell 脚本，约数百行 | 删除，交由框架处理 |
| 判定方式 | 结论解析脚本 + 源码 diff 脚本硬判 | expect + 证据脚本 + agent_judge / judge skill |
| 引擎支持 | 仅锁定单一引擎 | 一个参数即可切换多引擎回归 |
| 本地 / CI 一致性 | 两套独立逻辑，改动不同步 | 共享同一份评测声明 |
| 快速失败 | 无，明显失败也要跑完整对比 | expect 失败即跳过昂贵阶段 |
| 复杂语义判断 | 难以表达 | agent_judge 结合证据判断 |
| 新增用例成本 | 修改 CI 配置 + 确认脚本兼容 | 新增一份约 40 行的 YAML |
| 结果可达性 | 下载制品、解压、读取原始文件 | 一个链接直达可视化报告 |
这次迁移带来的收益，体现在多个方面同时发生：声明式结构让「这条用例要做什么、整体如何判断」从「需要读完好几个脚本才能拼凑出来」转变为「打开 YAML 就能一目了然」；分层判定机制让廉价失败快速返回、确定性证据稳定产出、复杂差异交给评审 Agent；跨引擎回归从「重写整套安装脚本」简化为「修改一个参数」；本地和 CI 共享同一份评测语义，不再「本地一套、CI 一套」。
其中体验变化最大的，其实并非评测本身，而是报告。过去，评测产物只是存放在 CI 制品中的原始文件，想看结果的人需要进入 CI、找到构建、下载、解压、读取 JSON，这个门槛对创建者本人尚可接受，但对团队其他成员（评审人、技术负责人、协作者）来说太高，许多人看到「需要下载」就放弃了。迁移后，每次评测的 HTML 报告会被发布为一个可访问的链接，无论是评审、验收还是争议解决，都可以直接分享链接。这并非一个技术问题，而是一个协作问题：评测只有被看见才有价值，而被看见的前提是路径足够短。
这个案例也修正了一个此前不太确定的判断：对于「真实代码仓库输入、真实环境执行、产物级 diff 验证、允许合理差异并需要语义评审」的重型 Skill 端到端评测，skill-up 已有的原语是完全可以承接的。它并非将 CI、业务镜像、标准答案等问题全部替你解决，而是将原本散落在脚本中的评测语义提取出来，用一套稳定的结构承载起来。
08
五分钟快速上手
skill-up 提供两条快速上手路径。
路径A：让 Agent 自动生成评测集（推荐）。skill-up 随仓库开源了一个名为 skill-upper 的 Agent Skill，专门用于帮助 Agent 读取 SKILL.md 和相关脚本，推断该 Skill 适合如何进行评测。安装后，在 Skill 仓库根目录下打开任意支持的 Agent，直接说一句「评测当前 Skill」，skill-upper 就会自动生成 evals/eval.yaml 和 evals/cases/*.yaml 文件，并调用 skill-up 运行一遍，将初始结果和 HTML 报告返回给你。它的价值并非替你完成评测建模，而是先搭建好「从 0 到 1 的样板」，让你可以围绕真实预期继续迭代优化。
# 以全局安装到 Claude Code 为例
npx skills add https://github.com/alibaba/skill-up/tree/main/skills/skill-upper -g -a claude-code -y
路径B：纯 CLI 上手。适合需要在 CI 中运行、对评测集有精细控制的场景。
# 安装
curl -fsSL https://raw.githubusercontent.com/alibaba/skill-up/main/install.sh | bash
skill-up --version
# 在 Skill 目录下创建 evals/eval.yaml 与 evals/cases/*.yaml 后运行
skill-up run
无论选择哪条路径，产出都是同一套结构化结果：逐条断言的通过情况、整体通过率、可接入 CI 的退出码，以及一份可视化的 HTML 报告。
09
写在最后
skill-up 的定位可以用一句话概括：通过简单易懂的声明式配置，固化我们对 Agent Skill 的预期，让代码评审和 CI 流水线都能有效验证它。从「一问一答」的单轮断言，到贴近真实交互的多轮会话，再到承接真实业务的重型端到端评测，它始终致力于同一件事：将 Skill 的质量从「依赖肉眼和记忆维护」转变为「可声明、可回放、可回归」。
它也有清晰的边界，值得提前说明。如果你的判定标准是「产物必须逐字节完全一致」，使用 script_judge 通过退出码硬判会更加省成本，无需动用 agent_judge；skill-up 不替你解决真实环境的可复现问题，工具链、镜像、标准答案仍需你自己准备；对于单条需要运行几十分钟的重型用例，更合适的方式是定时回归而非每次提交都卡门禁——将其视为一层「质量基线」，而不是「每个 commit 的强阻断」。认清这些边界，才能更好地将 skill-up 用在它真正擅长的地方。
那么，最直接的上手方式，就是打开你自己的 Skill 仓库，安装 skill-upper，说一句「评测当前 Skill」，几分钟后你就能拿到第一份 HTML 报告，然后围绕它持续迭代优化。
如果你也在编写或维护 Agent Skill，欢迎试用并参与共建：
- 开源仓库：github.com/alibaba/skill-up
- 中文用户手册：alibaba.github.io/skill-up/zh
- 反馈渠道：github.com/alibaba/skill-up/issues