Skill 写完怎么证明它没坏？阿里开源 skill-up 把 Agent 拽进「评测回归」时代

2026 年 7 月 23 日，阿里开源了 skill-up（github.com/alibaba/skill-up）。一个专给 Agent Skill 跑评测的命令行框架，它没发明任何新 Skill，但它想做一件事：让你今天写好的 Skill，明天改了 SKILL.md 一行字，依然能被验证还能跑。

<!-- 配图：Skill 月考试卷的趣味图（AI 渲染） -->

过去一年，Agent Skill 成了 AI 应用的核心基建。一段 SKILL.md、几个脚本、一组工具声明，就能让 Agent 具备一项新能力：写发布计划、做代码评审、跑数据分析。

但写一个能「跑起来」的 Skill 已经不难，难的是回答另一个问题：装上它之后，Agent 的行为真的符合预期吗？下次有人改了一行描述，它会不会悄悄退化？换一个 Agent 引擎，它还表现一致吗？

对传统软件，单元测试、集成测试、CI 门禁回答「改动有没有破坏原有行为」。Skill 是 prompt、文件、工具声明的组合，行为对模型版本、引擎实现、输入措辞都高度敏感，长期以来却缺少「声明一次、随时回放」的方式来固化我们对它的预期。预期不被显式写下来，Skill 的质量就只能靠肉眼和人工记忆维护——这恰恰是软件工程里最容易出问题的环节。

skill-up 解决的就是这个问题：把 Skill 的每一次迭代变得可验证、可回归。

一、「感觉流」测试，该终结了

你去翻 GitHub 上那些热门的 Agent 框架，Skill 目录长得一个比一个专业。prompt 写得像诗，工具调用链画得像地铁线路图。

但你看测试部分——要么空着，要么截几张图配文「效果不错」。

这叫测试吗？

软件工程搞了几十年，单元测试、集成测试、回归测试这套方法论是构建可靠系统的唯一路径。结果到了 Agent 时代，大家集体失忆，又退回到「我觉得没问题」的手工作坊模式。

开发者不是不想测，是根本不知道该怎么测一个自然语言输出的玩意儿。

你说一个客服 Skill「态度要友好」——什么叫友好？今天调了一版 prompt，友好度升级了还是崩塌了，有数字吗？

skill-up 做的事，就是把这种模糊的「感觉」，拉回到可量化的「指标」上。它定义了一套评测范式：你写完 Skill 必须配对评测集。输入是什么、期望输出是什么、判定标准是什么，全部结构化，跑完给你一个分。坏没坏、退步了多少，一目了然。

原文里举了三个大概率会发生的场景，每个做 Skill 的团队都逃不过：

• 场景一：Skill 悄悄退化，评审阶段没人察觉。 你给团队发布系统写了个 publish-plan Skill，本地跑几遍觉得「差不多了」就发布。两周后，同事改了 SKILL.md 里一段描述，Skill 在某些输入下不再调用预期工具，退化成了纯文本回答。代码评审时没人发现，直到用户报障才暴露。
• 场景二：换个引擎，行为就变。 你写的 code-review Skill 在某个 Agent 引擎上跑得不错，团队同事换了另一个引擎，反馈同样的提示语下输出结构完全不一样。你想系统验证在两个引擎下的真实差异，但每次都得手工触发、手工对比、手工记笔记，最后这件事被无限期搁置。 这三个例子的本质是同一个：Skill 缺少标准化评测框架，把「加载用例 → 启动 Agent → 发送输入 → 收集回复 → 判定通过 → 生成报告」整条流程串起来，本地开发和 CI 流水线都能复用。 skill-up 把这个缺失的中间层补齐。

二、四个核心设计：把 Skill 拽回软件工程

skill-up 不再造 Skill 框架，做的是 Skill 之上的评测层，能力拆成四块相互配合的设计。

其一，声明式评测配置。 评测的环境、引擎、模型、用例、判定策略全部写在 YAML 里。打开 eval.yaml 和 case YAML 就能顺着看清「这条用例要做什么、整体怎么判」，不必从一堆 Shell 反推。新增一条用例，往往只是一份几十行的 YAML。

其二，expect + judge 分层判定，降低 LLM 抖动对 CI 的影响： 是本地零成本确定性检查（文件是否存在、输出是否包含关键词、退出码是否为零），先跑；通过后才执行更深一层的 ，策略有 、、 三种。