让Agent Skill迭代可验证、可回归——开源评测框架深度解析

过去一年，Agent Skill迅速成为AI应用领域的核心基础设施。一段SKILL.md、几个脚本、一组工具声明，就能让Agent具备一项新的专业能力——写发布计划、做代码评审、升级依赖、跑数据分析。然而，写一个能「跑起来」的Skill已经不难，难的是回答另一个问题：它到底好不好用？ 传统软件有单元测试、集成测试、CI门禁来回答「改动有没有破坏原有行为」，但Skill作为prompt、文件与工具配置的组合，其行为对模型版本、引擎实现、输入措辞都高度敏感，长期以来却缺少一种「声明一次、随时回放」的方式来固化我们对它的预期。一旦预期没有被显式写下来，Skill的质量就只能靠肉眼检查和人工记忆维护，而这恰恰是软件工程里最容易出问题的环节。

三大典型痛点与解决方案

skill-up正是为解决这一痛点而生：让Agent Skill的每一次迭代都可被验证、可被回归。这是一个独立的命令行评测框架，开发者在Skill目录下放置声明式配置文件，即可自动化执行完整的评测流程——从加载用例、启动Agent、发送输入，到收集回复、判定通过、生成报告，全部可通过一条命令完成。

四大核心设计

在实际开发中，Skill质量保障面临三个高频痛点场景： **痛点一：Skill悄悄退化，无人察觉**。为团队写的publish-plan Skill，本地跑了几遍觉得「差不多了」就发布。两周后同事改了SKILL.md里的一段描述，Skill在某些输入下却不再调用预期工具，而是退化成了纯文本回答。这个变化没有任何人在代码评审阶段发现，直到用户报障才暴露。 **痛点二：换个引擎，行为就变了**。code-review Skill在某个Agent引擎上运行良好，切换到另一个引擎后，同样的提示语却输出了完全不同的结构。想系统验证Skill在不同引擎下的真实差异，每次都要手工触发、手工对比、手工记录，最终不了了之。 **痛点三：评测逻辑散落各处，无法复用**。为复杂Skill做评测写了一堆脚本：安装Skill、调用Agent、解析输出、对比结果、生成报告。评测语义散落在多个脚本和中间文件里，本地一套、CI又一套，新增一条用例要同时改好几处，新人根本看不懂「这条评测到底在判什么」。 这三个问题的本质是同一个：Skill缺少一个标准化的评测框架，把完整流程稳定地串起来，并且能

声明式配置与分层判定

skill-up的能力可拆解为四个相互配合的设计： **声明式评测配置**：评测的环境、引擎、模型、用例、判定策略全部写在YAML里，读者打开配置文件就能顺着结构看清「这条用例要做什么、整体怎么判」，不必从一堆脚本里反推评测语义。新增一条用例，往往只是新增一份几十行的YAML。 **expect + judge分层判定**：skill-up把断言拆成两层——expect是本地零成本的确定性检查（文件是否存在、输出是否包含关键词、退出码是否为零），作为门槛先跑；只有通过之后，才执行更深一层的judge。judge提供三种策略：rule_based（规则匹配）、script（脚本退出码）、agent_judge（由评审Agent做语义判断）。这种分层让大部分明显失败在不消耗token的本地阶段就被拦截，CI也不会因为大模型固有的偶发抖动被无端阻断。 **多引擎支持**：skill-up内置了对多种主流Agent引擎的适配，切换引擎只是一个命令行参数的事。同一份评测集在多个引擎上跑完，取最大公约数，就是这个Skill真正稳定的行为边界。对于自研或第三方Agent，也可以按标

多引擎支持与CI友好

除了单轮评测，skill-up还支持多轮会话评测。真实的用户交互是一句一句地说、Agent一步一步地做，很多行为单条prompt根本测不清楚。比如「必须先Research再Implement、用户要求跳步时应该拒绝」这样的流程约束，或者「危险操作要先确认、用户点头后才执行」这样的安全行为，都需要多轮交互才能验证。 skill-up支持在一个用例里定义多条连续的用户消息，逐条发送给Agent，并在每轮回复后检查结果。它提供了几个关键能力：真实的会话保持（每轮都在同一个Agent会话中）、逐轮质量门控（post_condition在每轮回复后立即检查，不达标可以早停省token）、跨轮值传递（用正则从某轮回复里提取token，自动填入后续消息）、精确到轮的最终判定。 对于更复杂的重型端到端评测场景（如代码工程升级类Skill），skill-up用逐层收窄的判定漏斗来承接：expect层检查最便宜、最确定的信号；证据脚本层提供确定性diff证据；agent_judge层结合diff判断差异是否合理。这种设计既保证了评测的严谨性，又避免了不必要的资源消耗。

如有侵权，请联系删除。