1. Skill 为什么突然值得被单独拿出来评测先说一个这两年 Agent 圈特别拧巴的现象大家都在做 AgentDemo 跑得飞起一聊到这个 Agent 到底好不好用、那个 Skill 靠不靠谱基本都是体感还行试了几个 case 挺顺这种模糊说法。问成功率是多少答不上来问哪些场景会崩也说不清楚。Agent 的测评多少还有个通用榜单能对一对Skill 呢基本处于三不管地带。Skill 在 Agent 体系里是很重要的一层它本质上是让大模型完成某一个特定子任务的封装能力。拆下来看它可以是一个工具调用的完整逻辑可以是一段可复用的 Prompt 模板也可以是一个带前置校验、后置兜底的流程编排。一个复杂的 Agent 往往要串联五六个甚至十几个这样的 Skill。问题就来了Agent 整体跑得好不代表每个 Skill 都好整体跑崩了你也不一定能快速定位是哪一环出了问题。这就必须把 Skill 单独拎出来测。阿里开源的 skill-up 做的正是这件事把 Agent Skill 当作独立的评测对象用一套标准化的流程给它打分、找问题、盯回归。它不是一个炫技的项目而是一个研发流程里的基础工具。我的理解是想让 Agent 从能跑走向靠谱Skill 评测是躲不开的一步。这篇文章我打算把它讲透——Skill 和 Agent 的边界到底怎么分、评测该看哪些数、用 skill-up 跑一轮评测要经历什么以及我在实际整理评测集时踩过的几个真实大坑。2. 拆清楚Skill 和 Agent 到底是什么关系很多刚开始接触 Agent 的朋友看到搜索引擎里天天挂着agent skillskill 和 agent 的区别说明这个基本概念的确挡了不少人。我在带团队做 Agent 项目时被问得最多的问题也是我写了个工具函数它算 Skill 吗我起了个 Agent它能算好几个任务里面是藏着多个 Skill 吗2.1 一个被低估的概念边界先说结论Agent 是决策和执行的主体它负责理解目标、拆解计划、调用资源、判断结果、决定下一步做什么Skill 则是 Agent 可以调用的、封装好的能力单元解决的是某一个具体任务怎么做好这件事。打个比方。Agent 像是一个项目经理Skill 像是一线工程师。项目经理拿到一个目标搭建一个线上展馆他不会自己把所有活都干完而是把任务拆成设计页面结构处理用户登录写商品列表接口做数据埋点每个任务丢给对应的一线工程师。每一个工程师就是独立的 Skill他们各有专攻可以单独考核页面结构能不能按时交付接口在高并发下会不会挂Skill 评测就是给每个一线工程师做 KPI 考核。具体到技术形态上一个 Skill 是包含 Prompt 模板、工具调用约定、输入输出 Schema、错误处理策略的完整单元。它不应该被写死在 Agent 的主流程里而应该是可注册、可复用、可单独调用的。我见过团队把大量逻辑堆在 Agent 的 system prompt 里最后 2000 行的 Prompt 根本没法测出了 bug 只能用重新调一下 prompt来解决这其实就是没有按 Skill 来组织能力的反面教材。2.2 评测粒度不同带来的本质差异区分 Skill 和 Agent不只是为了概念上聊得清它直接决定了评测怎么设计Agent 评测侧重全链路能力。给 Agent 一个开放式目标看它能不能自己规划、自己纠错、自己达成目标。输入通常是一个自然语言任务输出是整个任务的完成结果。Agent 评测关心的是任务级成功率、多轮交互的拟人度、规划合理性等偶然性和上下文累积影响很大。Skill 评测侧重点是单点能力的稳定性和边界。输入是符合 Skill 定义的调用请求输出是 Skill 的执行结果。它关心的是一百个同类请求里有多少个成功、多少个失败失败是集中在某一类输入上还是随机散布遇到边界输入时会优雅拒绝还是直接报错。两者测出来的数据用途也不一样。Agent 评测告诉你这哥们整体能不能处Skill 评测告诉你他扛事情的时候哪块能力是你的短板。2.3 不区分评测粒度会踩什么坑如果评测不区分粒度最常见的后果是完美的模糊归因Agent 最终输出崩了你可以怪最新的那个模型 prompt 写得差也可以怪某个工具的返回格式变了还可以怪编排逻辑判断失误。多个变量同时变化根本没法定位。而把每个 Skill 拆开单独测相当于给系统装了独立的仪表盘每个 Skill 有自己的成功率和延迟曲线哪个环节劣化数据会告诉你。这也是 skill-up 这类工具存在的意义——做 Skill 粒度的事实度量。它默认你手头有几个编好的 Skill然后帮你回答这个 Skill 到底能不能打。3. 评测 Agent Skill 到底该看哪些数评测工具的价值一半在流程框架一半在指标体系。Skill 评测如果只盯一个成功率那跟没测没什么区别。我按自己的实践经验把指标拆成五层每一层解决不同的问题。3.1 核心五层指标体系第一层是任务成功率。这是最基础的数定义是所有评测用例中Skill 按预期完成任务的占比。注意按预期三个字是灵魂Agent Skill 普遍有 JSON 输出、有工具调用输出格式对了但业务逻辑算错了算不算成功必须通过评测集的判定逻辑来确定而不能只看模型没报错。第二层是鲁棒性。一个成熟的 Skill 不能只在标准输入下工作。鲁棒性评测要看输入里带无关干扰信息时能不能提取关键参数输入缺失某个非必填字段时会不会崩输入是极端长度超短、超长时表现如何输入语言混杂时是否还能稳定处理。鲁棒性一般用一个边界用例集来跑和正常用例分开统计。第三层是稳定性和可复现性。同一组用例重复跑多次结果一致吗大模型推理有随机性完全一致不现实但一个负责任的 Skill 应该在核心决策上保持稳定而不是同一道题一会儿答对一会儿答错。稳定性通常用三次以上重复实验的通过率波动幅度来衡量。第四层是资源消耗和延迟。Skill 本质上是一个在线的能力调用每多一次模型推理就多一分成本和延迟。评测至少要关注三个数单次调用平均延迟 P50/P95、Token 消耗总 token 和有效 token 占比、额外工具调用次数说明这个 Skill 是否依赖多次重试才成功。第五层是错误处理质量。Skill 面对不能处理的输入时是给出一个标准化的错误协议还是糊里糊涂输出一堆幻觉内容好的 Skill 应该知道自己的边界在哪里遇到符合条件的输入说我做不了并给出原因而不是硬做一个错误结果。这个指标在常规评测里最容易被忽略但在真实生产环境里最容易炸雷。3.2 评测集应该长什么样指标体系定完接下来就是评测集设计。这是我认为 skill-up 这类工具能不能真正发挥作用的关键因为工具本身只会忠实地执行评测和统计数据评测集定义得好不好直接影响结果的可信度。评测集建议至少包含四类用例正向标准用例60%覆盖 Skill 设计范围内的典型场景数据是干净、完整的。边界用例15%输入长度逼近上限、字段值接近空值、字符串包含特殊符号和转义字符等。异常用例15%输入不符合 Schema、传入恶意或攻击性内容、目标无法实现的任务。对抗/干扰用例10%输入包含大量无关上下文、用户中途改需求、多轮对话中信息前后矛盾等考察 Skill 在复杂对话流中的定位能力。我带团队做评测集时第一版几乎全是正向用例结果一次大版本重构之后单测全绿在线一用就崩。后来排查发现崩的场景全在输入字段少传了一个字符串里有引号这种边界情况。自那以后我把边界用例和异常用例当作必选项宁可正向用例少一些也要保证边界覆盖。3.3 怎么读评测结果评测跑完会得到一张带指标的表。我一般按下面的思路读数先看成功率是否高于 90%。低于 90% 的 Skill 不应该被合入主流程这是红线。然后看失败用例的分布。如果失败集中在某一种输入类型上说明这是能力缺陷而不是随机波动。接着看 P95 延迟和 Token 消耗如果一个 Skill 的正常成功率很高但延迟和 Token 消耗是同类模型平均水平的 1.5 倍以上要考虑是不是 Prompt 里塞了太多无关内容或者依赖多次试错路径。最后看错误处理是否规范失败时是否返回了结构化错误码是直接抛异常让上游 Agent 无法处理。4. 用 skill-up 跑一遍真实的 Skill 评测理解了指标下面进入实操环节。skill-up 的大致工作模式是你把一个 Skill 接进来定义好评测集配置好判定方式它就会批量跑用例、汇总指标最后给出一份结构化报告。整个过程不需要自己写一个评测调度框架你只需要专注做一件事把你的 Skill 和你的评测用例准备好。4.1 环境准备与概念对应我在落地一套评测环境时习惯先把工具里的核心概念和自己的代码对应起来。基于我对这类工具的通用理解它的核心概念通常包括评测任务用例集执行器和判定器对应关系如下工具概念对应你自己的实现需要准备的内容评测目标被评测的 Skill把 Skill 的调用接口包装成一个统一的函数或服务用例集评测数据集覆盖正向/边界/异常/对抗四类输入且含预期结果或判定规则执行器调起 Skill 的逻辑决定是本地直接调用还是通过 HTTP/服务化方式触发判定器校验输出对错的逻辑可以是精确匹配、语义相似度、规则校验或 LLM 裁判报告输出指标成功率、延迟、Token 消耗、失败原因聚类等第一次接触评测工具的人容易犯一个错误直接拿网上现成的数据集塞进去跑。Skill 评测不是通用的问答评测任何一个 Skill 的输入输出都和你的具体实现强相关。别人评测集里的用户输入对你来说可能根本不符合 Schema。所以评测用例集最好基于你上线的真实场景来构造。4.2 绑定 Skill 和用例时的关键操作先做 Skill 适配。大部分 Skill 对外是一个函数入参是结构化的输入出参是结构化的结果。评测框架一般会要求你把它包装成一个可被统一调用的形式。注意到一个最常见的坑是Skill 的输入类型太宽泛。比如你的 Skill 入参是用户问题看起来很简单但真正上线时入参还应该包含上下文、用户身份、时间、会话历史等。如果评测时只传一个裸的用户问题测出来的成功率会明显高于实际因为真实场景里的干扰上下文完全没有进入评测。因此我在创建评测任务时一定会做一件事构造一个输入工厂它能批量生成符合真实分布的输入实例。比如做一个客服回复 Skill我的人工用例虽然只有 100 条但每次跑评测我会用模板在里面注入不同的用户名、商品名、时间字段生成 300 条变体避免 Skill 在固定写法上过拟合。然后是配置判定器。判定器是评测可信度的核心。有四种常见选择精确匹配适合输出是固定枚举的场景比如返回一个状态码。规则匹配检查输出里是否包含/不包含某些关键字段适合格式化输出。语义相似度适合自然语言回答用嵌入模型算相似度分数超过阈值即判对。LLM 裁判输入任务描述、模型输出和标准答案让裁判 LLM 判定结果对不对。我实际使用时的经验是不要只用一种判定器。举个例子一个工单摘要 Skill精确匹配完全不适用语义相似度能拦住大部分答非所问但对摘要里漏掉了关键结论这类问题语义相似度可能仍然因为整体句子结构相似而给了高分。这时候叠加一个 LLM 裁判把是否包含关键要素作为判定标准效果会好很多。4.3 执行评测与结果解读用例和判定器准备好后就能执行评测了。整个过程往往需要运行几十到几百个用例每个用例都要走一遍模型推理。执行阶段主要注意两点第一并发控制。如果底层调用的是大模型 API一次性并发太高容易被限流导致超时和重试率飙升污染评测结果。我自己一般会先跑一个 10 个用例的小测试确认流程通了再开全量评测并发数控制在 API 限量阈值的一半以下。第二记录原始输入输出。评测报告只会给你打分和统计真正的问题分析必须回到原始日志。我通常会导出每一条评测用例的输入、输出、判定详情和耗时方便失败之后逐条分析。结果报告出来之后重点看三块总体通过率、按用例类别的分组通过率、失败样本列表。如果正向用例通过率高但边界用例崩了说明 Skill 的主路径写得不错但防御性不足如果正向和边界都行但对抗用例夸了可能要检查 Skill 提示词里有没有对输入来源的约束或者它在面对一段明显偏离主题的内容时是否缺少拒答和纠正的机制。5. 实际操作中容易翻车的四个细节评测 Skill 不是把工具串联起来就能直接得到好用结果的事中间有不少零散的坑。这几条是我在给 Agent 项目搭评测流程时踩过或亲眼见别人踩过的专门拎出来说。5.1 评测集污染问题跑过两轮评测之后最常见的问题就是评测集污染。第一轮失败了几个 case你为了修复评测结果悄悄调整了 Skill 的 Prompt加了针对这些失败样例的特化描述。第二次跑这几个 case 过了通过率从 85% 涨到 95%你很高兴但这时候测试集已经不再代表真实分布了它代表的是你记下来的那几条历史考题。这种行为的本质是让模型背题而不是掌握能力。解决思路很简单用一个固定开发集 定期滚动的保留集。开发集可以反复用来调试和迭代但最终上线前必须跑一遍保留集——保留集是放在一边没被调试过程用过的数据在它上面的通过率才是真正接近线上效果的数。skill-up 这类工具建议你按业务模块多建几个用例集不要永远复用同一个。5.2 随机性导致的短线波动大模型推理有随机性同一个 Skill 同一批用例今天跑通过率 93%明天可能掉到 88%。这不是 Skill 出现回归而是模型采样带来的正常波动。我自己在前 100 条用例的小评测集上尤其明显用例少了哪怕只有一两条结果波动通过率的百分比都会跳得很厉害。建议是固定随机种子如果底层模型支持、温度调成 0 或接近 0、在可能的情况下同一用例重复跑 3 次取多数票作为判定结果。同时在报告里应该记录每次运行的参数快照模型版本、Prompt 版本、温度、判定器版本否则两周之后你看到一份通过率 90% 的报告根本不知道它是用哪个版本跑出来的也就失去回归对比的价值。5.3 外部依赖不稳定Skill 如果要调用外部 API——比如查询天气、搜索数据库、调用某个内部服务——评测结果很容易被外部依赖的状态带跑。外部服务一抖动Skill 的成功率就会假性下跌你以为是自己改坏了白排查半天。应对方法是在评测环境里对 Skill 的外部依赖做 Mock 或者录流重放。只要被测对象不是外部服务本身外部服务就应该提供稳定的打桩数据。Skill 评测的边界要画清楚你测的是Skill 的逻辑在给定外部响应下能否正确完成任务不是外部服务是否在线。如果你真的要测外部服务的可用性那是另一套监控体系的事情。5.4 判定器本身的误差LLM 裁判能解决很多传统判定搞不定的语义问题但它本身也是一个模型也有误判率。我在早期就遇到过裁判给分过于宽松的情况模型输出的回答几乎完全不含关键信息但句子结构完整流畅裁判给了一个高分。对这个问题我把裁判 Prompt 写成了强制要求它先列出关键检查点逐项打勾再给出最终结论并在评测集里放了几个已知的错误样本用来定期核对裁判自身的准确率。如果裁判连验证样本都判不对就要调整裁判 Prompt 或者换更强的裁判模型。工具本身不会提醒你裁判是错的所以这个检查你得自己去做。6. 从评测到改进skill-up 在研发流程里的位置评测工具最大的价值不在于测出问题了而在于它把问题变成了结构化的输入喂给研发流程。Skill 评测如果不跟迭代流程绑定那就是一份好看但没人看的报告。6.1 评测结果如何驱动 Skill 迭代拿到评测报告后我的处理顺序一般是先看失败模式再看失败样本。举例评测报告里异常用例的通过率只有 60%点开失败样本发现所有失败都是用户输入里包含超出上下文窗口的长文本Skill 没有做好截断直接报错。那你要做的不是改 Prompt 里的某个措辞而是在 Skill 的前置处理里加一层输入长度超限时自动截断并按分块处理的逻辑。这类结构性缺陷只靠调整提示词是修不好的。比较相邻版本的数据。从第三轮评测开始我会把每次报告的通过率、平均延迟、Token 消耗做成一张简单的趋势表。凡是某一个指标连续两轮下滑就要立刻排查这期间改了什么。比如 Delay 和 Token 同时上升大概率是 Prompt 里多了不少检索回来但没有被有效压缩的参考材料。重视一次都没改过的指标。有一种情况某个 Skill 的成功率一直维持在 90% 左右但你在它上面做的各种尝试都换不来提升。这通常说明瓶颈不在 Skill 自身而在底层模型的能力边界或者输入数据的质量上限。这时候硬调的意义不大可以考虑换更强的基础模型或者在更前端的流程里加一个预筛模块把难处理的输入提前分流给其他方案。6.2 评测集也要持续运营评测集不是建完一次就永久使用的静态资产它需要随真实业务持续更新。我建议每次上线一个重要的新功能同步往评测集里补充对应的用例让评测集一直在反映最新的生产语义。同时定期检查现有用例是否已经过时。例如业务变了、某个字段废弃了旧的评测用例如果不删Skill 每轮都会在这些已经不可能发生的场景上扣分白白拉低通过率还误导改进方向。另外线上产生的 bad case 是评测集最好的素材来源。我在线上 Agent 的日志里定期捞取用户反馈不靠谱的记录挑选有代表性的脱敏之后加入评测集的对抗用例组。这能让评测体系与真实用户体验始终保持一致。你不用一天加几十条一周加 3-5 条高质量样本就够。6.3 把评测接入持续集成的实际收益对工程团队来说把 Skill 评测接入 CI 流程收益非常直接。每次 Skill 代码或 Prompt 有变更自动触发一轮冒烟评测跑核心用例集的子集通过率低于基线阈值就阻止合并。这相当于给改 Prompt这种以前完全靠人工确认的操作加了一道自动门禁。Prompt 调优是最容易顺手破坏其他场景的改动手动测试很难覆盖到回归影响。CI 全量评测虽然每个版本都跑会有点耗时但我会分成两级提交级跑核心 30-50 条用例确保大方向不崩发版前跑完整几百条用例数据归档留档。这样既保证了迭代速度又不会漏掉回归风险。7. 我的几点真实体会回到标题上阿里开源 skill-up 这件事本身我认为是在一个正确的时间点做了一个正确的工具。Agent 开发社区现在最缺的不是更多花哨的 Agent 框架而是把工程化基础打牢的能力。Skill 评测正是这个基础里很重要的一块拼图。从我实际操作的经验看Skill 评测能不能在你的团队里落地更多靠的是流程和习惯而不是工具本身你是否愿意把评测集当作代码一样维护你是否能容忍评测报告给出不达标的结果并以此为准阻断发版你是否能坚持在出问题时先定位数据而不是凭感觉去调整提示词这些问题工具帮不了你只有自己下决心才能解决。skill-up 这类工具给了你一个可以开始的基础框架但评测集的质量、指标的解读、迭代的闭环这些还是得靠你在真实业务里一点点打磨。把 Skill 测到数据可查、回归可控、问题可定位Agent 的可靠性才算真正有了底线。我希望这篇分享能帮你减少一些起步阶段的无从下手感至于后面能把这套流程用到什么深度就看你的项目需要了。