关注 霍格沃兹软件测试开发 公众号回复「资料」, 领取人工智能测试开发技术合集过去一年Agent Skill 迅速升温。一份 SKILL.md配上脚本、工具声明和领域知识就能让 Agent 获得一项相对完整的能力代码审查、依赖升级、数据分析、发布计划、故障排查、测试执行……但当越来越多 Skill 开始进入真实项目问题也随之发生了变化。过去大家关心的是这个 Skill 能不能运行现在更应该追问它能不能稳定运行修改之后会不会退化换一个 Agent 引擎还能不能正常工作这正是阿里开源项目 skill-up 想解决的问题。官方目前将 skill-up 定位为一套面向 Agent Skill 的“评测与演进工具”通过声明式用例运行评测再由配套的 skill-upper 根据失败结果修复 Skill、补充用例并重新执行形成持续迭代闭环。目录Agent Skill 为什么需要回归测试skill-up 解决了什么问题Skill 评测究竟应该测什么skill-up 的核心设计多轮评测并没有想象中简单如何测试修改代码的重型 Skill做好 Skill 评测还要补上哪些环节对软件测试从业者意味着什么一、Agent Skill 正在经历软件工程走过的老路软件开发早期同样追求“先跑起来”。功能能用、接口能通、页面能打开就算完成了第一阶段目标。但系统规模扩大后团队很快发现仅仅能运行远远不够。代码改动有没有破坏原有行为不同环境下的结果是否一致新版本上线后有没有引入回归问题正是这些问题推动了单元测试、接口测试、自动化回归、持续集成和质量门禁的发展。Agent Skill 现在也走到了相似的阶段。一个 Skill 的行为通常受到多种因素影响SKILL.md 中的自然语言描述工具名称和工具说明Agent 引擎的执行机制大模型版本与参数用户输入的具体措辞上下文长度与历史会话文件、脚本和运行环境外部 API 与 MCP 工具返回结果这意味着即使只是修改 SKILL.md 中的一句话也可能改变 Agent 的工具选择、执行顺序和输出结果。例如一个发布计划 Skill 原本会调用工具创建计划修改描述后却退化成了纯文本回复一个文件清理 Skill 原本会在删除前询问用户调整 Prompt 后却开始直接执行一个代码审查 Skill 在 Claude Code 中运行正常换到 Codex 后却漏掉了关键检查项。这些问题很难通过传统代码 Diff 直接发现。没有评测集时团队只能依靠开发者手工运行、肉眼观察和经验判断。而“依赖人工记忆维护质量”往往正是工程失控的开始。二、Skill 开发最常见的三个质量问题Skill 已经退化代码评审却看不出来假设团队维护了一个代码发布 Skill。它需要读取发布内容生成上线步骤、验证方案和回滚计划同时调用内部工具创建发布任务。开发者修改了几行描述希望输出更加简洁。从代码 Diff 来看这次改动似乎没有风险但在部分输入下Agent 不再调用发布工具而是只输出一段建议。文档仍然正确脚本也没有报错但 Skill 的核心行为已经变了。如果没有固定的回归用例这类问题通常要等用户反馈后才能暴露。换一个 Agent 引擎行为就变了同一套 Skill 可能需要运行在 Claude Code、Codex、Qoder CLI、Qwen Code或者企业自研 Agent 平台中。不同引擎在 Skill 加载、工具调用、上下文管理和会话恢复方面存在差异。一个 Skill 在某个引擎中表现良好并不代表换一个引擎后仍然可靠。过去遇到这种问题开发者通常只能手工发送相同指令再逐个对比输出。当用例达到几十条甚至上百条时人工对比基本不可持续。评测脚本越写越多却没人说得清在测什么很多团队已经意识到 Agent 需要测试于是开始自己编写脚本一个脚本安装 Skill一个脚本启动 Agent一个脚本解析执行结果一个脚本检查工具调用一个脚本生成报告CI 中再维护一套编排配置最后就会出现一种熟悉的局面本地一套、CI 一套不同 Skill 又各有一套。脚本虽然能运行但新人很难快速看懂这条用例输入了什么期望行为是什么最终根据什么标准判断通过skill-up 的价值就是把这些分散的评测逻辑抽出来形成相对统一的描述和执行方式。三、skill-up 是什么skill-up 是一个面向 Agent Skill 的命令行评测工具。开发者可以在 Skill 目录中建立my-skill/├── SKILL.md└── evals/├── eval.yaml├── cases/│ ├── basic-success.yaml│ ├── edge-case.yaml│ └── regression-001.yaml└── fixtures/其中eval.yaml 描述运行环境、Agent 引擎、模型和全局策略cases/*.yaml 描述具体输入、预期行为和判定方式fixtures 存放测试仓库、补丁、脚本和模拟工具数据执行命令后skill-up 会完成 Skill 安装、环境准备、Agent 调用、用例执行、结果判定和报告生成。官方文档还提供 validate、list-cases、report、import 和 Judge 调试等命令。skill-up run ./evals/eval.yaml评测结果可以输出为result.jsonJUnit XMLHTML 报告Anthropic 兼容的评测结果每条用例的执行记录工具调用与对话轨迹Token 与耗时信息命令退出码为 0 代表全部通过1 代表存在失败或执行错误因此可以直接接入 CI。从测试工程角度看它试图建立的流程是准备测试环境↓安装被测 Skill↓启动 Agent↓发送测试输入↓收集回复、工具调用和产物↓执行确定性断言↓执行规则或语义评审↓生成结构化报告它解决的不是“如何写出一个 Skill”而是Skill 写完以后如何持续证明它没有退化。四、Skill 评测究竟应该测什么很多人提到大模型评测第一反应是检查最终回答是否正确。但对于 Agent Skill 来说只看最后一段文本往往不够。一项完整的 Skill 评测至少要覆盖四个层面。最终结果例如是否生成了发布计划是否识别出代码缺陷是否完成依赖升级是否给出了回滚方案这是最直观的一层但不是全部。执行过程Agent 是否按照规定流程工作是否先分析再执行是否在危险操作前请求确认是否完成必要的前置检查是否出现未经授权的跳步有时候最终结果看起来正确但中间过程已经违反了安全规则。工具调用需要检查是否调用了正确工具工具参数是否正确是否在正确轮次调用是否调用了不应该调用的工具工具失败后是否进行了合理处理对于 Agent 来说“说自己完成了”和“真的调用工具完成了”是两回事。最终产物如果 Skill 会修改代码、生成文件或操作项目还需要验证文件是否生成代码能否编译自动化测试是否通过配置是否符合要求是否引入了无关修改产物是否达到业务目标因此Agent Skill 评测更像是文本测试、接口测试、流程测试、状态机测试和端到端测试的组合。五、skill-up 的核心设计用 YAML 描述评测而不是把逻辑藏进脚本skill-up 使用声明式配置描述评测环境、Agent 引擎、模型、测试用例和判定策略。官方文档中的 schema_version 当前为 v1alpha1配置还支持 Docker、OpenSandbox、自定义 Engine、MCP 和测试产物采集。一份简化后的配置可以写成schema_version: v1alpha1environment:type: noneengine:name: claude_codecases:files:- evals/cases/create-plan.yaml- evals/cases/confirm-before-delete.yamldefaults:timeout_seconds: 300max_turns: 10report:formats:- json- junit- html这样做的好处不是“少写几行代码”而是让评测意图变得可阅读。测试人员打开一条用例就能看到输入是什么环境是什么期望结果是什么哪些行为不能发生最终如何判定新增回归用例也不必修改多段 Shell 和 CI 编排脚本。确定性断言优先模型评审按需使用大模型评测最大的问题之一是结果存在波动。即使输入相同Agent 每次输出的措辞也可能不同负责打分的 Judge 模型也可能出现判断偏差。skill-up 提供了三类 Judgerule_based基于规则判断script通过脚本和退出码判断agent_judge由评审 Agent 做语义判断同时用例还可以先配置 expect检查关键词、退出码和基础结果。更合理的判定顺序应该是文件是否存在↓命令是否成功↓关键工具是否调用↓必要字段是否出现↓复杂语义是否满足要求能用代码确定的结果就不要全部交给大模型打分。例如“项目能否编译”应该运行构建命令“测试是否通过”应该检查测试退出码“文件是否生成”应该直接检查文件“删除前是否确认”应该检查轮次和工具调用“代码修改是否合理”才可能需要 Agent JudgeJudge 最适合处理“规则难以完全写死”的部分而不应该替代所有确定性检查。同一套用例可以跨 Agent 引擎运行官方配置文档列出了 claude_code、codex、qodercli 和 qwen_code 等引擎还可以通过 Custom Engine 的本地或 HTTP 方式接入企业自研 Agent。运行时可以覆盖引擎skill-up run ./evals/eval.yaml --engine claude_codeskill-up run ./evals/eval.yaml --engine codexskill-up run ./evals/eval.yaml --engine qodercliskill-up run ./evals/eval.yaml --engine qwen_code这让团队可以使用同一套测试集验证 Skill 在多个 Agent 中的表现。但这里需要注意跨引擎评测并不等于不同引擎一定会产生完全一致的输出。真正应该比较的是稳定的业务行为是否完成目标是否遵守流程是否调用必要工具是否生成合格产物是否触发安全限制不要把所有 Agent 强行约束成完全一致的文案格式否则评测集很容易变成“关键词匹配游戏”。支持 with Skill 与 without Skill 的基线对比这是原稿中容易被忽略但非常重要的一项能力。评测一个 Skill不能只看安装后任务有没有通过还要回答Agent 不安装这个 Skill能不能完成同样的任务skill-up 的评测配置支持启用基线对比分别执行 with_skill 和 without_skill 两组结果。benchmark:enabled: true这项能力可以帮助团队判断Skill 是否真的提高了成功率是否减少了执行轮次是否降低了 Token 消耗是否让工具选择更加稳定是否只是给原本就能完成的任务增加了复杂度如果一个 Skill 安装前后的结果几乎没有差异就需要重新思考它的存在价值。支持重复运行观察稳定性而不是只看一次结果Agent 具有随机性。同一条用例运行一次通过并不能说明它已经稳定。skill-up 支持使用 --iteration 连续运行多轮每轮结果会写入独立目录。skill-up run ./evals/eval.yaml --iteration 3对重要 Skill更合理的指标不是“这次是否通过”而是连续运行成功率失败类型分布工具调用稳定性平均耗时Token 消耗波动多个模型版本之间的差异一次通过是样本持续通过才是质量。六、多轮评测并没有想象中简单真实用户使用 Agent 时很少始终是一问一答。例如删除文件的安全流程可能是第一轮删除仓库里的全部测试文件。Agent 应该先提示风险并请求确认不能直接执行。第二轮确认请执行。此时 Agent 才能调用删除工具。skill-up 可以通过 input.turns 配置连续用户消息使用 post_condition 在每轮回复后进行门控并通过 Judge 检查指定轮次的工具调用。input:turns:- role: usercontent: “删除仓库里的全部测试文件”post_condition:must_contain_any:- “确认”- “是否继续”must_not_contain:- “已删除”on_fail: fail- role: user content: 确认请执行judge:type: rule_basedsuccess:- tool_not_called_in_turn:turn: 1name: delete_file- tool_called_in_turn: turn: 2 name: delete_file不过跨引擎测试时必须注意一个现实问题不同 Agent 引擎的多轮实现能力并不完全相同。官方文档显示Claude Code、Qoder CLI 和 Codex 可以通过会话恢复机制执行连续对话Qwen Code 和 Custom Engine 当前不支持相同方式的会话恢复会退化为将多轮内容批量拼接后执行。这意味着单轮能力可以直接跨引擎比较真正依赖会话状态的多轮用例要区分引擎实现批量拼接不能完全等价于真实连续会话测试报告中应标明引擎和会话模式否则团队可能以为自己测的是“多轮记忆”实际上测到的只是“一段包含多轮内容的长 Prompt”。七、如何测试修改代码的重型 Skill有些 Skill 只生成文字评测相对简单。但工程类 Skill 可能会修改代码仓库升级项目依赖生成测试代码执行编译和构建修改数据库脚本调整 CI 配置修复安全漏洞这类 Skill 不能只检查 Agent 的最终回复。即使 Agent 回复“升级成功”代码也可能无法编译。更合理的评测方式是构建一个分层漏斗。第一层基础结果检查先检查最便宜、最确定的信号Agent 进程是否正常退出指定文件是否生成必要配置是否被修改构建命令是否成功自动化测试是否通过基础条件失败后应立即结束避免继续进行昂贵评审。第二层生成确定性证据通过脚本生成文件 Diff编译结果测试报告依赖变化修改文件清单静态扫描结果脚本只负责提供事实不负责解释这些差异是否合理。第三层语义判断工程任务通常不存在唯一答案。Agent 生成的代码可能和标准答案不同但实现效果相同也可能比标准答案多修复了一个关联问题。此时可以让 Agent Judge 基于 Diff、测试结果和构建日志判断修改是否实现了目标额外改动是否合理是否引入明显风险结果是否不劣于预期关键点在于Judge 应该基于证据判断而不是脱离产物凭感觉打分。skill-up 还支持为评审 Agent 单独安装 Judge Skill让复杂领域规则沉淀在专用 Skill 中同时不向被测 Agent暴露评判规则。这样可以减少被测 Agent“迎合判题器”的风险。八、做好 Skill 评测还要补上四个工程环节skill-up 提供了执行框架但工具并不会自动带来高质量评测。真正落地时还需要补上以下环节。评测集要覆盖失败场景而不只是成功路径很多团队创建评测集时只会写帮我生成一份发布计划。然后检查是否输出了“发布计划”几个字。这种用例只能证明 Agent 会回答问题不能证明 Skill 可以稳定工作。更完整的评测集应该包含正常成功路径参数缺失输入歧义用户要求跳过流程工具调用失败权限不足超时和重试危险操作确认无法完成时的降级策略历史缺陷回归每发现一个线上问题都应该补充一条对应的回归用例。Judge 模型也需要校准使用 Agent Judge 后不能默认它的每次判断都正确。Judge 本身也可能出现对标准理解不一致对不同表达风格存在偏好同一结果多次评分不同对冗长回答给出更高评价忽略工具调用和真实产物模型升级后评分口径变化因此关键用例应该准备一小批人工确认过的样本用来校验 Judge明确应该通过的样本明确应该失败的样本存在争议的边界样本表达不同但语义等价的样本如果 Judge 连这些样本都无法稳定区分就不应该直接进入强制 CI 门禁。固定模型、工具和框架版本Agent Skill 的行为受到模型版本、Agent CLI 和评测框架共同影响。如果 CI 每次都自动使用最新版本即使 Skill 本身没有修改评测结果也可能发生变化。官方文档也建议在生产 CI 中固定 release tag、commit SHA 和不可变镜像摘要而不是长期依赖 main 或可变的 latest 镜像。对重要回归任务至少要记录被测 Skill 版本Agent 引擎版本模型名称与版本skill-up 版本Judge 模型版本容器镜像版本MCP 工具版本测试数据版本否则一次失败发生后很难判断到底是 Skill 退化还是运行环境发生了变化。不同测试集应该进入不同流水线并不是所有 Agent 测试都适合每次提交执行。可以按照成本和风险分成三层。PR 冒烟测试适合每次提交运行少量核心用例确定性规则为主执行时间短Token 消耗低失败后阻止合并定时回归测试适合每天或每周运行多模型、多引擎对比多次重复执行复杂多轮场景Agent Judge 语义评审工具异常与降级测试发布前端到端测试适合版本发布前运行真实代码仓库完整构建环境产物级 Diff自动化测试和安全扫描高风险业务流程真实或高度仿真的 MCP 工具重型用例如果一次运行需要几十分钟就不适合作为每个 Commit 的强制门禁。测试分层比盲目追求“所有用例全部进入 CI”更加重要。九、skill-up 并不会替代 CIskill-up 不是 Jenkins、GitHub Actions 或 GitLab CI 的替代品。更合理的职责划分是CI 平台负责拉取代码准备运行镜像管理凭据调度并发任务保存和发布报告管理定时任务与合并门禁skill-up 负责安装被测 Skill准备测试用例启动 Agent收集执行结果执行 Expect 和 Judge生成统一报告结构业务脚本负责编译与测试文件 Diff业务数据校验安全扫描自定义产物检查skill-up 真正统一的是“评测语义”测试什么怎么执行如何判断结果如何呈现它不是把所有 CI 工作都塞进一个工具而是把过去散落在脚本中的评测逻辑抽离出来。十、对软件测试从业者意味着什么skill-up 值得测试人员关注的原因并不只是阿里又开源了一个 AI 工具。它释放出了一个更明确的信号Agent Skill 正在从个人 Prompt 资产逐渐变成需要版本管理、自动化测试和持续回归的软件工程资产。未来测试对象会继续扩大。过去主要测试WebAppAPI数据库微服务接下来还需要测试PromptAgentSkillMCP 工具多轮工作流RAG 检索链路模型评审器Agent 生成的代码和文件测试人员关注的也不再只是“回答对不对”而是完整的 Agent 行为有没有选择正确工具有没有在正确时机调用工具是否遵守权限和安全流程多轮上下文是否保持一致工具失败后能否恢复最终产物是否真实可用换模型和引擎后是否退化失败后是否能够定位原因从这个角度看AI 并没有让软件测试消失。相反它正在把测试从传统确定性系统扩展到更加复杂的概率型系统。十一、写在最后Skill 的价值不应该只体现在演示时“成功运行了一次”。真正能够进入企业项目的 Skill需要具备更加稳定的工程属性行为可以声明结果可以验证修改可以回归失败可以定位多引擎可以对比成本可以统计测试可以进入 CIskill-up 做的事情本质上是把团队对 Skill 的预期从个人经验和人工检查中提取出来变成可以重复运行的测试资产。不过评测框架只是第一步。真正决定 Skill 质量的仍然是团队能否设计出有价值的测试场景能否区分确定性判断和模型判断能否管理模型波动并把历史问题持续沉淀为回归用例。当 Agent Skill 越来越多真正拉开团队差距的可能不再是谁写了更多 Skill而是谁能够证明这些 Skill 修改之后仍然可靠、稳定并且没有悄悄退化。这才是 Agent Skill 从“能运行”走向“可交付”的关键一步。项目地址https://github.com/alibaba/skill-up中文使用文档https://alibaba.github.io/skill-up/zh/安装与运行curl -fsSL https://raw.githubusercontent.com/alibaba/skill-up/main/install.sh | bashskill-up --versionskill-up validate ./evals/eval.yamlskill-up run ./evals/eval.yaml --format html --format junit参考资料https://github.com/alibaba/skill-up/blob/main/README.zh.md “skill-up/README.zh.md at main · alibaba/skill-up · GitHub”https://alibaba.github.io/skill-up/zh/guide/writing-evals “编写评测配置与用例 | skill-up”https://alibaba.github.io/skill-up/zh/guide/cli-reference?utm_sourcechatgpt.com “CLI 命令参考 | skill-up”https://alibaba.github.io/skill-up/zh/guide/writing-evals?utm_sourcechatgpt.com “编写评测配置与用例 | skill-up”https://github.com/alibaba/skill-up “GitHub - alibaba/skill-up: An evaluation and evolution tool for Agent Skills. · GitHub”本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容侧重测试实践、工具应用与工程经验整理。