做 Agent 开发的人应该都有过类似的体验Skill 越攒越多但哪个 Skill 真正靠谱、哪个该迭代、哪个干脆该删基本靠感觉和拍脑袋。要么是线上跑挂了才反应过来要么是换了模型后效果忽上忽下查不出原因。阿里最近开源的skill-up就是冲着这个痛点来的——一款专门给 Agent Skill 做“体检”的评测工具。这篇文章我会从 Agent 与 Skill 的关系讲起拆解 skill-up 的设计思路和核心评测逻辑再带大家走一遍实际评测 Skill 的完整流程最后整理一些我在技能工程实践中踩过的坑和排查经验希望对正在做 Agent 项目的朋友有帮助。1. 先搞清楚Agent 和 Skill 到底什么关系1.1 Skill 不是“插件的换皮”它是一种能力契约现在很多人一提到 Agent 的 Skill下意识会拿“插件”来类比。这个理解方向没错但如果只停留在“插件”这个层面后面做评测、做优化都会很别扭。我的理解是Skill 的本质是 Agent 和大模型之间的一种“能力契约”。它对 Agent 暴露的是一组可被调用的原子能力比如“根据城市名查天气”“按关键词搜论文”“把一个 Markdown 文件转成 PDF”对模型来说Skill 在 prompt 层表现为一套清晰的使用说明包括这个能力做什么、什么时候该用、参数有哪些约束、返回什么格式。插件强调的是“外部功能接入”Skill 强调的则是“可被模型正确调用的能力边界”。这个区别很重要。因为评测 Skill本质是在评测两层东西能力本身的执行质量以及模型理解和调用这个能力的准确率。两层都是变量如果不分开看出了问题根本不知道是模型不会用工具还是工具本身做坏了。1.2 为什么 Skill 质量直接决定 Agent 上限大模型本身的推理能力再好落到具体任务上最终还是要靠 Skill 去接触真实世界的数据和操作。一个 Agent 能不能稳定完成“查资料—写报告—发邮件”这类串联任务拼的不是模型有多聪明而是每个环节的 Skill 有多稳。一个典型的场景你给 Agent 配了一个“网页内容抓取” Skill单测的时候抓静态页面一切正常但线上跑到需要登录的站点或者动态渲染的页面就直接返回空内容。这时候如果模型已经把这个 Skill 纳入了调用计划那整个任务链都会断掉。更难受的是这类问题往往是概率性的——不是每次都会失败而是十次里挂两三次。没有评测工具之前这类问题只能靠用户投诉和日志捞取去被动发现周期长、定位慢。所以结论很直接Agent 的能力上限由模型决定但能力的稳定性下限由 Skill 决定。评测 Skill就是在守住这个下限。1.3 Agent 做项目真的需要一堆 Skill 吗这是最近群里热议的话题。我的答案是需要但要严重克制。从任务覆盖的角度看一个 Agent 承接的项目越复杂需要拆解出的原子能力自然越多。比如做一个“行业研究报告生成器”至少需要搜索、网页抓取、PDF 解析、表格生成、文档排版这几个基础 Skill再往上可能还要接数据库查询、API 调用。一个都不行。但 Skill 多和 Agent 强之间绝对不能画等号Skill 越多模型在每一步做工具选择的难度就越大评测和运维的成本也越高。实际操作中我非常建议大家遵循两个原则一个 Agent 的活跃 Skill 控制在 8 到 12 个以内。超出这个范围模型频繁选错工具的概率会显著上升评测报告里会看到大量“Skill 调用不匹配”类问题。Skill 要能“合并同类项”。“查天气”和“查空气质量”完全可以合成一个“查询城市环境信息”的 Skill通过参数区分。Skill 的粒度越合理Agent 越容易学得会、调得准。Skill 不是越多越好而是越贴越好。怎么判断“贴不贴”这就是评测工具要回答的问题。2. skill-up 的评测逻辑与设计思路2.1 评测到底在测什么五个核心维度在用过几款评测工具之后我觉得 skill-up 对评测维度的划分是相对清楚的一套逻辑。它至少覆盖了五个维度这五个维度基本把 Skill 从“能用”到“好用”的差距都囊括进去了。第一个是成功率也就是 Skill 在限定条件下完成任务的概率。这个很好理解但是要注意“完成”的定义得提前定好。比如一个“发送邮件” Skill只要邮件发出去了就算成功还是必须等收件方真正收到才算成功不同定义下结果可能差很多。第二个是稳定性。同一个 Skill 用同样的输入跑十次结果是不是一致的有些 Skill 依赖外部服务网络抖动、API 限流、第三方接口返回值变化都会让结果漂移。稳定性的价值在于它暴露了 Skill 对外部环境的敏感度这是压力测试下最容易率先崩掉的环节。第三个是质量分。成功率只回答“做了没有”质量分回答“做得好不好”。同样是“摘要生成” Skill一个输出是逻辑通顺的段落另一个输出是关键词堆砌两者都可以算作执行成功但质量天差地别。质量分一般需要借助评测集里的标准答案或规则引擎来综合打分。第四个是效率。包括端到端耗时和 token 消耗。现在团队都在控成本一个 Skill 如果每次调用都要多烧几百个 token日活一上来成本差距就是千级别以上的。评测工具如果能记录 token 消耗就能帮我们精准找到那些“功能没问题但亏钱”的 Skill。第五个是鲁棒性。换一种说法就是抗干扰能力。输入稍微不规范比如日期格式从2025-01-01变成了1月1号Skill 还能不能正常跑第三方 API 返回了意料之外的字段Skill 会不会直接抛异常鲁棒性不够的 Skill在真实场景里就是一颗定时炸弹。2.2 评测集怎么来结果怎么算评测设计里最容易被忽略但其实最关键的就是评测集的建设。没有一份够好的评测集评测工具本身再强也发挥不出来。skill-up 这类工具的评测集一般建议大家至少包含三类数据真实历史请求从线上日志里抽样这部分数据最贴近真实用户的使用习惯覆盖面广是评测集的底座。人工构造边界用例针对 Skill 的输入约束设计极端情况比如空参数、超长字符串、特殊字符、并发调用等目的是把 Skill 的弱点炸出来。对抗性样本故意构造容易被模型误解的请求。比如调用“删除文件” Skill 时描述里加一些模糊表达“把那个不要的文档处理掉”看看模型能不能正确映射到删除操作而不是去调用“归档” Skill。结果的计算逻辑通用的做法是把单次评测拆成“执行是否完成”和“结果是否达标”两步。前者对应成功率后者对应质量分。如果一次执行完成了但结果质量不达标只算完成不算通过。这样能把那些“答非所问但强行返回”的 Skill 暴露出来。2.3 为什么评测工具一定要“可复现”我对评测工具的底线要求只有四个字可复现。不可复现的评测没有意义。你周一跑出来成功率和周五跑出来的不一样如果排除不了是代码改动、数据漂移、还是环境变化引起的那这个评测结果就无法指导任何决策。skill-up 在这方面的思路是尽量减少对实时外部服务的依赖评测时可以通过 mock 第三方接口或者固定返回值来隔离外部噪音跑出来的数据真正做到“同一条用例、同一个版本、同一组结果”。我自己在实际使用中也有个习惯每次评测前都记录下三个东西Skill 的版本号、评测集文件版本号、评测环境的依赖锁文件。这三样信息缺一不可没有它们就算评测报告再漂亮也无法定位回归问题。3. 实操用 skill-up 给 Skill 做一次体检3.1 环境准备与快速起步skill-up 的安装方式遵循常见的开源工具习惯。它通常是一个基于 Python 的命令行工具通过包管理器安装即可。具体安装命令建议以官方 README 为准这里分享几个安装和起步时容易忽略的点。第一准备好 Python 虚拟环境。这是老生常谈但我真心建议别偷懒。评测工具往往要装很多依赖直接装在全局环境里很容易和项目其他依赖打架虚拟环境可以省掉很多后续麻烦。第二第一次运行建议先跑一个最小的示例 Skill不要一上来就把自己的复杂 Skill 接进去。先把工具本身的流程跑通理解配置项都有什么作用再逐步替换成自己的内容排查起来会轻松得多。第三确认是否有内置的 mock 服务或录制回放能力。这个对可复现评测非常重要能大幅降低外部依赖带来的波动。3.2 配置评测任务的三要素评测任务的配置一般围绕三样东西展开评测集、被测 Skill 的启动方式、评测后端的模型与服务参数。评测集是第一步。常见的组织方式是维护一个包含多个用例的文件每个用例至少包含输入、期望输出或判定规则、用例类别。这里我强调一下“判定规则”的作用。有些场景我们能写出明确的期望输出比如“返回的 JSON 必须包含字段 code 且 code 的值为 200”但很多生成式任务没有标准答案比如“根据材料生成一份摘要”这时候就得靠规则来判分比如检查摘要长度是否符合范围、是否包含关键信息点、有没有明显的重复语句。在设计判定规则时量化指标越多越好这样报告中呈现的质量评分解释性才更强。被测 Skill 的启动方式也很重要。skill-up 一般支持直接加载 Skill 的入口函数或通过 API 方式访问。我的建议是优先走 API 方式因为更贴近真实生产环境评测结果更有说服力。但同时要保证环境隔离评测的时候不能去操作生产数据否则风险太高。模型与服务参数主要影响评测成本。同一组评测用例在不同模型上跑结果会有差异甚至不同 temperature 参数都会导致结果不同。评测时务必固定参数否则结果之间没有可比性。3.3 跑完结果怎么看读懂评测报告评测跑完会生成一份报告一般包含总体得分、每个维度的分项得分以及每个用例的执行详情。很多人只看一个总分这是浪费了报告里最有价值的信息。我会按三步来读报告先看分项得分。哪个维度拖了后腿优先级就最高。比如成功率 98% 但效率分只有 60说明 Skill 功能上是 OK 的但耗时或 token 消耗有优化空间。再翻用例级别的失败记录。逐个看失败的输入是什么、Skill 返回了什么、错误出在哪一步。这个环节非常关键它是定位 bug 的直接线索。最后看稳定性相关数据。如果某个用例在多次执行中结果不一致报告里一般会有波动标记这类问题就是典型的隐藏雷区。3.4 评测场景的进阶玩法当你对整个流程熟了以后可以尝试一些进阶用法。第一个是回归评测。每改一次 Skill就把完整评测集跑一遍确保没有改坏已有功能。这在团队协作中尤其重要经常出现一个人改了 A 功能B 功能悄悄挂掉的情况。回归评测跑得勤一点这类问题就能在合入前被拦住。第二个是多模型矩阵评测。同一个 Skill分别用几款主流模型去评测横向对比调用成功率和质量分。别指望一个 Skill 在所有模型上表现一致实际结果经常是有些模型更擅长调用工具有些更容易误解参数。带着评测数据去选型和优化 prompt会更有依据。第三个是评测集本身的分层。把用例按紧急程度或使用频率分层核心链路用例每次必跑边缘扩展用例每周跑一次长尾用例每月跑一次。这样既能保证核心质量又不会占用太多机器资源。4. 评测结果不好怎么办Skill 优化实战4.1 失败样本归因先分清是 Skill 的问题还是编排的问题拿到失败的评测用例后第一件事不是急着改代码而是做归因。经常有这种情况评测报告显示某个用例失败但仔细看下来不是 Skill 的功能坏了而是整个 Agent 链路里模型把参数传错了。比如模型调用“天气查询” Skill 时把“城市”参数传成了“省份”Skill 本身没问题但它收到的输入就是错的。归因时我习惯用一个很简单的判断方法把出问题的输入直接通过脚本调用一次 Skill 的底层函数绕过模型。如果函数自己执行正确那问题出在模型对 Skill 的理解上应该去优化 Skill 的功能描述和参数说明如果函数自己也执行失败那才是 Skill 的代码或依赖出了问题。这个区分能省掉大量无效排查时间。4.2 常见翻车现场与修复方法先整理一个我实测中高频出现的翻车场景表格方便大家对照排查。现象大概率原因处理方式成功率波动大外部 API 依赖太强限流或网络抖动直接传导增加超时重试同时对第三方接口做降级或缓存模型总是选错 SkillSkill 描述模糊功能边界不清晰重写 skill 描述明确“什么时候该用”和“什么时候不该用”参数传递总是错参数格式复杂模型无法正确映射精简参数数量给出参数示例值使用枚举而不是开放文本token 消耗过高每次调用都传入了超长上下文裁剪无关上下文只传当前任务所需的最小信息边界输入就崩缺少入参校验和异常兜底在 Skill 入口做参数校验非法输入返回友好的错误信息拿“参数传递总是错”来说很多时候不是因为模型笨而是参数定义太抽象了。举个实际例子一个“生成图表” Skill 的参数如果叫type可选值范围是数字 1 到 5模型大概率会困惑如果你把参数改成chart_type可选值直接写bar, line, pie再给一个示例值chart_typebar模型基本不会出错。Skill 的 prompt 设计核心就是降低模型的理解成本。4.3 Skill 的“最小可用集”经验最后聊一个团队管理层面的经验到底一个项目配多少 Skill 合适。我的建议是先做减法再做加法。第一版只保留任务链路里真正绕不开的 3 到 5 个 Skill用评测工具跑通核心链路确保每一步的调用成功率和质量分都达标。然后在这个底子上逐步加 Skill每加一个都要回答两个问题这个 Skill 是不是现有 Skill 的变体没有它任务链路会不会断实测下来多数常规的 Agent 项目8 到 12 个 Skill 已经覆盖得很好了。超过这个数评测报告里会出现一类新的失败模式——模型本身开始“选择困难”频繁在相近的 Skill 之间选错。这时候不是继续堆 Skill而是回过头合并、收敛。5. 常见问题速查与避坑清单5.1 评测过程中的高频问题Q1评测集用多少条用例合适没有绝对标准但经验上核心 Skill 至少要有 30 到 50 条用例覆盖正常路径、边界路径和异常路径。用例太少评测结果不具统计意义用例太多每次回归耗时和成本暴涨。建议分核心、扩展、长尾三层管理。Q2评测结果不稳定怎么办先检查评测环境是否受外部网络或服务影响优先用 mock 或录制回放隔离外部依赖。再检查模型参数是否每次都一致比如 temperature、max_tokens 这些设置会直接改变生成结果。排除这两项后仍不稳定大概率是 Skill 本身对外部环境敏感需要在 Skill 内部做兜底。Q3一个 Skill 在开发环境评测全过上生产就出问题怎么回事最常见的原因是开发环境和生产环境的依赖不一致。另一个原因是生产环境的并发量更高触发了外部 API 的限流。建议评测时在测试环境里制造一定的并发压力同时把依赖锁文件维护好。Q4评测报告显示质量分低但功能看起来正常这就要回头检查判定规则是不是太严格或者不合理了。比如生成内容长度限制设得过短或者规则依赖了错误栏位。先把失败用例拎出来人工复核一遍看是对结果误判还是真的有质量问题。5.2 评测工具使用中的额外提醒用 skill-up 这类评测工具时有几个坑提醒大家注意。第一个是评测集污染。不要直接在评测集里混合真实用户敏感数据。评测集需要脱敏处理否则存在隐私风险。建议在评测集生成阶段就建立脱敏流程把身份证、电话、地址等字段替换成模拟数据。第二个是过度拟合评测集。如果评测集长期不变Skill 的开发会不自觉地“针对评测集调优”看起来分数很高但一遇到真实数据就原形毕露。建议每个月从线上日志中抽样补充评测集保持数据的新鲜度。第三个是忽略评测成本。跑一次完整评测集的算力和 token 成本不是小数尤其是大模型矩阵评测场景。建议按频率分层执行核心数据集高频跑全量数据集低频跑成本和风险之间取一个平衡。5.3 团队落地 Skill 评测的三点建议最后给想在公司内部落地 Skill 评测机制的朋友三个建议。第一把评测结果接入开发流程。不要把评测变成“上线的最后一步”而是每次提交代码都触发一次快速评测让开发人员在提交阶段就拿到质量反馈尽早发现问题。第二建立评测基线基线版本化。每次评测完把报告和对应的代码版本、评测集版本、依赖版本一起归档。后面一旦出现线上问题可以快速回溯是哪个版本引入了回归。第三让写 Skill 的人参与到判分规则制定里。判分规则如果只由平台同学写很容易和实际场景脱节。外面写 Skill 模块的人最清楚哪些输出是不能接受的、哪些误差在合理范围内他们参与进判定规则设计评测结果才具备真正的业务指导价值。关于 Skill 评测和技能工程我试过的路子还有很多方向没聊透比如 Skill 的动态加载、基于评测结果自动优化描述、多 Agent 场景下 Skill 的协作评测等这些话题以后有机会再单独展开。如果你正在做 Agent 项目我的建议是把 Skill 评测当成基础设施来建设越早投入后面的坑就越少。