最近在折腾 Agent 应用圈子里聊得最多的其实已经不是模型本身了而是 Skill。模型的能力天花板就在那摆着真正决定一个 Agent 好不好用的往往是它调用的那些 Skill 稳不稳定、准不准、省不省 token。阿里开源了一个叫 skill-up 的 Agent Skill 评测工具我第一时间拿来试了试今天就把我对它的理解和实际体验整理出来聊聊为什么 Skill 需要评测以及 skill-up 这种工具到底解决了什么问题。先说结论如果你正在做 Agent 相关开发或者准备把一些常用能力沉淀成可复用的 Skill 给团队用那 skill-up 这个项目值得你花一个下午好好研究一下。它不是给你测模型的而是专门用来测那些“让模型变得更会做事”的技能模块的。这个定位很精准也正好补上了目前 Agent 工程化里一块很大的空白。1. Agent Skill 到底是个什么为什么它突然成了焦点1.1 Skill 和 Agent 的关系一个管决策一个管执行先说个最基础的问题Skill 和 Agent 到底有什么区别这个问题在很多技术群里反复被问我用自己的话解释一下。Agent 是一个完整的决策闭环。它接收用户请求理解意图规划步骤调用工具最后组织答案。它像是一个“项目经理”负责搞清楚要做什么、怎么做、什么时候做。而 Skill 是这个闭环里可复用的“执行能力单元”。比如“给 PDF 做摘要”“查询天气并组织成出行建议”“把一段文字翻译成多语言”。一个 Agent 可以拥有很多 Skill它根据任务类型动态选择调用哪个。用生活类比来说Agent 是厨师Skill 是菜谱。厨师Agent知道客人点了什么菜理解意图然后决定用哪本菜谱选择 Skill严格按照步骤做菜执行 Skill。菜谱好不好直接决定了菜做出来稳不稳定跟厨师聪不聪明是两码事。这个区分特别重要因为过去一年里很多人陷入一个误区Agent 效果不行就怪模型不行疯狂换更强的主模型但问题往往出在那些“看起来能用、实际很多边界 case 没覆盖”的 Skill 上。1.2 Skill 为什么突然需要被“认真评测”了以前大家做 Agent 都是写硬编码流程Scenario 很少几个 if else 就搞定了根本不需要单独评测 Skill直接看最终效果就行。现在不一样了。几个趋势叠加在一起让 Skill 评测变成了刚需第一Skill 的规模上来了。MCPModel Context Protocol出来后Skill 的获取成本变得极低一个仓库里可以集成几十个甚至上百个 Skill。你不可能逐个去手工验证必须有个自动化的评估机制把质量差、不稳定、描述有歧义的 Skill 过滤掉。第二Skill 的复杂度提升了。老的“给 LLM 一个 prompt 一个函数”的形态正在向“多步骤 workflow 子 Skill 嵌套 记忆状态”演进。复杂 Skill 的执行链路变长任何一环出错都会导致整体失败。这种系统性稳定性问题必须在脱离具体业务场景的情况下单独测试。第三Skill 会被分发复用。当一个 Skill 被上传到仓库、被团队里其他人或者社区用户拿去用时评测信息就成了别人选型时的重要参考。你总不能连个评测报告都拿不出来就让别人相信你的 Skill 好用吧。所以 skill-up 这类的评测工具本质上做的事情就是把“验证 Skill 好不好用”这件原本靠人工、靠感觉、靠某个具体 Agent 里的偶然表现来判断的事情变成一套可重复、可量化、可对比的工程化流程。2. skill-up 这个项目它想解决的到底是什么问题2.1 从项目定位看整体设计思路skill-up 是阿里开源的一个 Agent Skill 评测工具官方定位是评测和优化 Agent 的 Skill。我理解它的核心目标是回答三个问题这个 Skill 用起来效果到底怎么样它的表现随着模型版本升级、prompt 修改是变好了还是变差了的横向对比两个功能相似的 Skill哪个更值得集成到我的 Agent 里你注意它没有解决“如何写出一个好的 Skill”的问题它解决的是“如何知道一个 Skill 好不好”的问题。先有度量再有优化这符合工程上的一般规律。我看 skill-up 设计上比较有意思的一点是它不是一个简单的“拿一堆 case 跑一遍看成功率”的脚本而是把 Skill 评测拆成了一个可观测、可追踪、可持续积累数据资产的一套体系。2.2 Skill 评测和模型评测的本质差异为什么不能用评测模型的那套方式直接评测 Skill我在思考 skill-up 的设计时觉得这个差异是它整个架构的前提。评测模型本质上是在测“智能上限”。你给模型一个难题看它能不能答出来答案对了就是对了错了就是错了。评测 Skill本质上是在测“稳定交付能力”。同一个 Skill 要被反复调用每次调用输入都略有不同你必须保证它在各种各样的边界条件下都能返回可用结果。场景覆盖度决定了 Skill 评测的置信度。用 5 个 happy path 测出来的 100% 成功率没有参考价值500 个覆盖各种异常输入的 case 测出来的 80% 成功率反而更能说明问题。模型评测关心的是最终答案的正确性而 Skill 评测还必须关心调用过程的开销、失败后的恢复路径、对上下文长度的占用等“工程性指标”。毕竟一个 Skill 是要被集成到大系统里高频调用的不只是用来考试。这也就解释了为什么 skill-up 不能简单复用 LLM-as-a-Judge 或者 RAGAS 之类的现成评估库那些工具评估的是模型输出质量而 skill-up 需要从 Skill 的输入、执行过程、中间状态、最终输出、消费资源等多个维度去描述一次调用的完整画像。2.3 核心评测思路站在用户真实场景里模拟执行我用了 skill-up 之后有一个很深的感觉它在设计评测逻辑时刻意让被测 Skill “不知道自己正在被评测”。什么意思呢它不是简单地拿一堆静态指令发给 Skill 然后比对输出而是尽可能模拟一个真实 Agent 调用 Skill 的完整上下文。你提供一个用户目标比如“帮我把这份采购合同里的付款条款提炼出来”评测框架会构造出完整的对话历史和必要的环境状态然后 Skill 在这个仿真环境里去执行像真的被集成在 Agent 里一样去调工具、查资料、产出结果。这种仿真执行的评测方式比那种直接喂 prompt 然后看输出文本相似度的方案要靠谱得多。因为 Skill 执行过程中的状态管理、工具调用顺序、异常处理路径全都是影响最终效果的关键因素只有放到真实的执行环境里才能暴露出来。skill-up 默认支持两种测试类型我印象比较深一个是静态评测拿干净的 query 直接测试单一 Skill快速试错另一个是情景模拟测试让 Skill 在一个有前缀上下文、有环境变量的情况下执行更贴近真实调用场景。这个设计我认为是非常务实的因为实际上很多 Skill 在真实 Agent 里不会收到一个孤零零的请求前面往往跟着好几轮用户和 Agent 的交互如果 Skill 没有考虑到这些上下文里的隐含条件就很容易翻车。3. 用自己的场景跑通一次 skill-up 评测我做了什么3.1 先把评测目标和维度定义清楚我不太喜欢直接上来就动手跑工具习惯先把“要测什么”想清楚。Skill 评测最忌讳的就是目标模糊最后跑出来一堆指标但不知道该怎么解读。这次我用一个实际场景来练手。假设我要在公司内部做一个“合同关键条款审查助手”从用户上传的合同 PDF 里提取付款方式、违约责任、保密期限、管辖法院等结构化信息。但我不是直接测最终那个 Agent而是要测中间的“合同条款提取”这个 Skill——它负责读 PDF 内容按给定 schema 输出 JSON。在评测指标上我参考了 skill-up 的维度设计思路最终确定了四个功能正确性输出 JSON 里的各个字段是否和原文一致有没有遗漏或幻觉。鲁棒性输入文件的排版、长度、表格形式变了还能不能稳定提取。格式遵从度返回内容是不是严格符合预期的 schema能被下游直接消费。Token 开销效率同一个 case优化前后消耗的 token 数量有多大差别。这几项指标里“格式遵从度”在以前做模型评测时很少被单拎出来但在 Skill 评测里它极其重要。因为 Skill 的输出是要被下游程序解析的不是给人看的一个字段结构错了下游直接崩。3.2 评测用例怎么准备决定了评测有没有价值这个环节我花的时间最多也最想跟大家分享。skill-up 只提供评测机制不会替你思考该测什么场景。评测集的质量直接决定了你这份评测结果有没有人愿意信。我准备评测集时用了三层结构。第一层是“标准场景”覆盖了这个 Skill 最常见的使用方式比如标准五页合同、纯文字 PDF、字段分布清晰。第二层是“边缘场景”包括扫描版 PDF虽然后面发现需要 OCR 前置处理、带页眉页脚的复杂排版、表格里塞条款的、一段话里藏了多个关键信息的。第三层是“负向场景”输入根本就不是合同或者合同里没有条款看 Skill 会不会胡说八道。负向场景太容易被忽视了。很多团队评测 Skill 只测正向能不能跑通结果 Skill 上线后遇到无关输入时一本正经地瞎编用户体验极差。我这次专门加了几个“请求对方改合同”的邮件内容正确的行为应该是返回一个空的提取结果并提示“未识别到合同条款”而不是硬生生把邮件里的话脑补成条款。评测数据准备好之后我还做了一个很重要的事情把期望结果写得非常具体不只是“字段要正确”还会标注出“这个 case 里如果对方名称识别错了是通过哪句话判断的”之类的备注。这些备注在后续定位失败 case 时价值巨大能帮你快速搞清楚到底是 Skill 的指令理解出了问题还是信息抽取逻辑有 bug。3.3 跑评测、看报告然后定位失败原因skill-up 的执行机制走通之后会输出一份可视化的对比报告。我这次同时跑了三组配置来做对照实验基线组Skill 最原始的 prompt 版本正则规则也保持最初的样子。优化组 A给 prompt 增加了更详细的字段定义说明在“违约责任”字段里明确要求“包含甲方和乙方各自的违约条款金额数字需原样摘录”。优化组 B在 A 的基础上增加了对“输入文本过长时先分段再抽取”的处理逻辑。跑完结果我非常意外。原本对优化组 B 期望很高觉得多了一步分段处理应该会让准确率提升但实测效果反而比 A 更差。原因分析下来是分段逻辑在切断文本时经常把涉及“管辖法院”“合同期限”的句子拦腰截断导致后半段信息丢失。这个 case 让我意识到一个流程上的复杂化在没有充分考虑文本结构时反而会引入新的系统性问题而这种问题如果不做评测、靠人工凭感觉是极难发现的。评测报告里还有一个细节非常有用就是它会展示模型在幻觉输出和空输出之间的置信度分布。有些 case 的字段提取结果看着是对的但模型推理过程里已经出现了自我矛盾只是最终输出把矛盾掩盖了。这种隐藏的不确定性只有通过评估框架去分析才能提前暴露出来。4. 深度复盘Skill 评测的实际难点和解决思路4.1 评测数据怎么来从业务日志里挖而不是自己硬编我用 skill-up 的过程中遇到的最大瓶颈不是工具本身不好用而是高质量的评测用例太难搞。大家做 Agent 应用应该都有这种感觉手里有一堆业务日志但那个日志是乱糟糟的对话记录不是带标注的评测集。怎么把日志变成能用的评测数据我这段时间总结了一套比较有效的方法。首先把日志里 Agent 最终成功响应的 case 捞出来按 Skill 调用类型做一个聚类看一下每个 Skill 在实际用户请求中被触发的高频路径是什么。然后从高频路径里挑出典型样本结合业务方的反馈把那些用户实际满意、但 Agent 在多轮交互里绕了一大圈的 case 也挑出来这些是潜在的优化对象。第二步是让 AI 辅助做初筛和改写。用一个大模型先从原始对话里把与目标 Skill 相关的需求段落抽取出来做成一个干净的 query。然后人工再对这批 query 做一遍审查剔除那些表达有歧义的、存在个人信息风险的再补充一些变体。最后一步是建立评测集的版本机制。Skill 的评测集不是静态的每次发现了线上失败的 case都应该把这个 case 沉淀进评测集里形成一份持续增长的回归测试集合。这样每一次修改 skill 的 prompt 或代码都能立刻回归一遍所有历史问题防止“修了一个 bug引出两个新 bug”的恶性循环。4.2 别只看成功率效率和稳定性指标同样重要很多做 Agent 评测的人有一个惯性思维拿到评测工具就先看成功率其他指标全忽略。这样做在模型评测里问题不大但在 Skill 评测里会吃大亏。skill-up 这类评测工具输出的指标里token 消耗、步骤数、失败重试次数这些关于执行过程的数据很关键。Skill 是要被高频反复调用的一个在评测集上成功率很高的 Skill如果每次调用要消耗超出预期的 token、要经过多次失败重试才能成功那集成到线上系统后根本不划算还会拖慢 Agent 的整体响应速度。举个具体例子。我对比过一个用“一次大段 prompt 让模型输出全部字段”的方案和一个“先判断合同类型再按类型走不同提取分支”的方案。前者在标准场景下成功率略高成功率都在 95% 左右但后者在复杂合同上的成功率显著好于前者而且失败后不会爆出大量 token平均每次调用的损耗也低得多。综合评估下来后者才是最值得集成进 Agent 的。这就是评测的价值它让你看到的不只是一个最终结果而是这个结果背后付出的代价。如果一个 Skill 的成功是靠高 token 消耗堆出来的在实际业务里未必划算。4.3 LLM 作为评测者本身也有偏好结果需要交叉验证做 Skill 评测离不开 LLM 辅助打分也就是让一个能力更强的大模型来当“裁判”判断输出是否满足要求。但我在实践中发现LLM-as-a-Judge 在 Skill 评测场景里有一些特有的偏好问题如果你完全不加约束地使用评测结果会有系统性偏差。第一个问题是对格式错误的宽容度偏高。你让裁判模型判断输出是否包含所有关键字段它可能觉得字段名对了就行、字段值是否精确对应原文反而是小问题。但作为程序要消费这个结果时一个数字少了一个零后果可能是灾难性的。所以对于格式、类型、取值这类硬性要求我会尽量用代码校验规则去做强制判断而不是完全依赖大模型裁判。第二个问题是裁判模型容易被长度更长的输出带偏。两个输出里如果一个是简洁的 High-level 摘要另一个是把原文里所有相关内容都罗列了出来裁判模型经常会倾向于认为后者更完整、更好即使前者才真正符合调用方的需求。这种偏好会导致评测结果失真。我的处理方式是在评测标准里明确写清楚“只判断内容是否准确覆盖不因长度加分”并且在打分前让裁判模型先做一轮字段级的核对而不是整体给个直觉分。实测下来用混合评测方式效果最好——代码自动判断硬性格式LLM 只负责判断语义层面的准确性和完整性两类结果做交叉校验。这也是我在用 skill-up 的过程里学到的最重要的一件事。4.4 仿真环境做得越真评测结果的可信度越高我在前面提到 skill-up 会做“情景模拟测试”这个设计方向非常重要。如果你把一个 Skill 单独拿出来测试喂进去的是干净的查询那只能说明这个 Skill 本身还没有坏到不可用的程度并不代表它在真实的 Agent 系统里也能表现良好。现实情况是Agent 调用 Skill 时上下文中往往带着很多干扰信息。比如用户前几轮聊的是别的话题中间突然切到“对了帮我处理一下刚才那份合同”或者用户把合同直接粘贴在对话里又额外加了一句“你就简单看一下付款那块”。这种用户真实表达的场景和我们构造的干净 query 之间有一段不小的距离。我自己的做法是除了用 skill-up 做得比较标准的场景模拟还会额外用真实 Agent 的完整日志回放去跑一遍 Skill。也就是说把我线上 Agent 某一次真实对话的全部上下文截取下来在评测环境里重新触发一遍对应 Skill然后对比线上结果和评测环境里的结果是否一致。这个方式虽然比较原始、效果也看运气但对发现“上下文依赖问题”很有效。skill-up 的支持动态 prompt 构造也能帮你做一些类似的模拟。通过给评测任务设置不同的前缀提示和后缀干扰项能让同一个 Skill 在变化多样的上下文里被反复测试最终会筛选出那些在信息干扰下仍然能保持执行质量的高韧性 Skill。一个评测体系是否成熟核心就是看它的评测能不能逼近真实的大规模使用场景因为虚拟的“干净”永远替代不了真实的“杂乱”。5. 围绕 skill-up 做一套可落地的评测工作流我是怎么组织实践的5.1 整合进迭代周期让评测成为开发流程的一部分工具再好如果它被隔离在开发流程之外价值会大打折扣。我在看了 skill-up 之后做的第一件事就是把 Skill 评测的工作流固定到本地代码仓库的版本迭代里。现在每次要修改一个 Skill我会同步提交一份评测报告。哪怕改动只是 prompt 里加了一句约束也会把评测集完整跑一遍对比新老版本之间的差异。生成后的 JSON 输出还会放到代码库的指定目录里做版本管理。这一套流程跑顺之后每次提交的 Skill 质量是持续向上走的因为所有指标变化都变得有迹可循不会再出现前段时间加了个功能、性能却下滑了的情况。这也是我认为 skill-up 和那些“测一次就扔”的脚本之间最大的区别。一个评测工具要真正发挥作用必须配合合理的评测变更管理习惯才能沉淀出对团队有长期价值的基础设施。5.2 评测报告怎么解读才是高级用法很多人把评测报告当成一个打分结果来看但它的价值远不止于此。我自己习惯从报告里提取三类信息第一是不同类型的失败集中在哪几个 case 上它的指令表达能力是不是有盲区——比如对某些领域的术语总是理解错误第二是 Skill 对不同输入长度、不同难度等级的退化速度这能判断它的能力边界在哪里第三是修改前后变化的方向是否一致有没有可能模型的知识更新了之后原来适配的旧规则反而在阻碍新能力发挥。比如说我在优化一个“周报自动生成”的 Skill 时发现加了很详细的输出格式定义之后成功率反而下降了不少。进一步看错误 case 才发现新格式定义让模型在选择该放哪些信息时过度纠结频繁遗漏重要数据。后来我把格式要求拆成了两部分一部分用规范的模板结构硬约束另一部分用开放性的自由写作空间让模型发挥最终的结果才稳定下来。Skill 既然是模型指导下运行的代码它的语义解析对上下文和格式的要求就会异常敏感。评测的价值恰好就在于它能在你做出这类取舍之前先把可能产生的反作用给你预警出来。5.3 评测集持续运营记录哪些 Skill 会因模型升级而退化关于 Skill 评测还有一个容易被忽视的场景当你的底层模型从旧版升级到新版或者换了一个模型供应商原来表现不错的 Skill 很可能会突然失效。我在一次主模型升级后就遇到过这种问题原来对一个老模型很有效的“要求模型先摘录原文再看情况进行改写”的指令在升级之后反而不工作了新模型对指令的理解方式有所不同导致它总是直接输出改写后的内容把原文摘录这个中间步骤跳过了。如果那份 Skill 没有做好评测集准备和回归数据的积累这类问题在生产环境里很难第一时间被发现。skill-up 的一个很有价值的用法就在这里当你准备升级底层模型时先把关键 Skill 的评测集完整跑一遍基线再带着新模型跑同一套评测用对比报告快速定位那些出现性能变化的 Skill。这个验证成本极低却能把模型升级的稳定性风险大幅降低。我把这个环节固化成一个标准动作之后再面对模型版本升级时心里踏实多了。6. 什么情况下适合用 skill-up什么情况下不用急着上你可能会问是不是所有 Agent 项目都需要上 skill-up 这类评测工具我的建议是分情况来看。如果你只是在做一个个人的 Demo或者只写了几个简单 Skill 自己调试那确实不需要专门引入一套评测系统。这时候花费的精力搭评测配置可能比手工验证的次数还多。但如果你在做正式的 Agent 产品或者团队里有多个 Agent 依赖同一批 Skill又或者你计划把自己的 Skill 开放给社区使用那评测这一步就是必要的。skill-up 这类工具的投入产出比会随着 Skill 数量的增加而快速提高因为当你有了十几个 Skill你不可能靠手工去一一验证它们是否仍然工作正常而是需要一个能持续运行、能自动对比、能快速定位问题的评测体系来维护它们的健康状况。阿里这个开源项目对整个 Agent 生态还有一个更大的意义当 Skill 的评测变得标准化之后的 Skill 分发场景才会有更清晰的互信基础。以前 Skill 在仓库里看着像能用但真不真用只有自己跑了才知道以后有了相对统一的评测报告格式使用者能提前了解一个 Skill 的实测效果、适用边界、资源损耗大概是什么水平选型和集成的效率都会提高。我自己的习惯是如果要在两个实现思路相似的 Skill 里做选择我不会光靠看描述和 Manual 来拍板会拿手头一份有代表性的评测集分别跑一遍用数据说话让评测结果给判断增加实感。这个习惯一旦养成之后会反向推动你把自己内部那些 Skill 描述写得更加具体、严谨因为那些是定义评测用例时的重要参照评测不好做了才理解一份边界清晰的说明文档到底有多重要。如果你最近正好也在做 Agent Skill 的开发和维护建议你花点时间把 skill-up 装起来用自己手头的真实业务数据试一次。把第一次评测跑通把那些原本以为能用的 Skill 翻出来见见光大概率会对当前系统的一些隐藏问题有更直接的认识。评测不是给自己的项目找麻烦它是在给复杂的 Agent 系统建立心跳和体检中心让每一次升级和变更都能得到可量化的反馈而不是在真实生产环境里靠用户抱怨来发现问题。