写评测脚本、造评测数据到头来发现最大的瓶颈根本不是模型能力而是没法量化评估“这组配置到底比之前好在哪里”。尤其是Agent应用里大量使用Skill技能的时候问题更明显同一个问题今天跑是这个结果明天跑是另一个结果参数调了一版又一版上线还是翻车。阿里开源了一款叫skill-up的Agent Skill评测工具专门解决“Skill到底行不行”这个问题。这篇文章我会从“为什么需要它”开始讲把它解决的核心问题、评测框架、实际跑通的步骤、以及我踩过的坑一次说清楚。1. 为什么Agent开发越深入越绕不开skill评测这个环节1.1 从“能跑通”到“稳定交付”差距全在评测上接触Agent开发的头一个月绝大多数人是“能跑通就行”的状态调一个模型接口写两段Prompt封装成一个工具函数Demo演示给同事看效果惊艳全场鼓掌。这个阶段根本不需要评测工具因为你的判断标准是“有没有反应”。但一旦进入真实业务哪怕是内部效率工具要求立刻变成另一个维度正确率必须可度量、延迟必须可控、异常输入不能被带偏。这时候你会发现评测不是“加分项”而是“保命项”。拿我自己做过的一个项目举例给一个客服系统接入Agent让它在回答前先调用订单查询Skill。最初版本只测了3个case全过觉得自己已经搞定了。结果小范围上线第一天就出事——用户问“我上周买的东西到哪了”Skill里定义的参数是order_id模型死活提取不出来最后返回了一堆无关的物流公告。这类问题靠“多跑几个case肉眼核对”根本查不出来因为你不可能手动跑几百次话术变体。你需要的是系统性的评测工具把“模型在特定Skill上的表现”变成一组有说服力的数字。skill-up这类工具瞄准的正是这个缺口它不直接帮你调Prompt也不帮你写业务代码而是把“评测Skill”这件事本身做成一套可复用的流程。1.2 一个评测工具要解决的问题清单很多人在刚接触评测工具时会误以为它就是个“跑分脚本”。真上手之后你才发现一份合格的Skill评测方案至少要回答下面这些问题调用是否成功给定一组输入Skill是否能正常被触发并执行完毕这里不只是看模型有没有调用工具还要看参数提取对不对、返回格式是否符合下游解析要求。输出是否可靠同样的问题换个说法结果还成立吗评测需要覆盖同义改写、噪声插入、边界条件不然你只是在测“背题能力”。多轮场景下是否走样真实业务几乎没有“一问一答”的用户会追问、会补充条件、会临时改需求。Skill评测如果只测单轮上线必翻车。同一评测集跑多次是否稳定大模型输出天生有随机性评测工具得能跑出统计意义不能凭一两次结果下结论。多个Skill之间是否有干扰Agent系统里一般挂好几个Skill模型会不会在不需要的时候乱触发或者在需要的时候选错这属于编排层面的评测但也必须有数据支撑。这些问题单靠人工抽检只能发现“有毛病”没法量化“有多严重”。skill-up把这些维度拆成指标用统一流程跑完产出可对比的报告让你在做优化决策时有据可依。2. skill和agent到底是什么关系做项目真需要一堆skill吗2.1 先厘清概念agent是调度者skill是能力单元最近技术社区里“skill和agent的区别”这类问题热度很高。很多新人会把“Agent”理解成一个什么都能干的超级智能体把“Skill”理解成某几个Prompt模板这其实偏差很大。我的理解是这样的Agent是大脑加调度器负责理解目标、拆解任务、决定调用什么能力Skill是能力单元负责把某一类事情做得专业、稳定、可复用。举一个生活化的例子Agent像一家公司的项目经理Skill像公司里的各个专业部门。项目经理需要懂业务、懂资源调配但他不需要亲自会写代码、画设计图Skill部门则要能保证“活儿交过来按规范交付”。从实现层面看一个Skill一般包含三个要素触发描述什么样的问题应该调用这个Skill模型靠它做路由判断执行逻辑可能是纯Prompt也可能是Prompt加外部工具调用API、数据库、代码执行等输出契约返回结构长什么样方便Agent下一步决策或直接回复用户你品一下这个结构就会明白为什么评测Skill不能只看“最终答案对不对”还得看“该触发时是否触发”“不该触发时是否误触”。这两项恰恰是真实项目里最头疼的。2.2 “skills数量焦虑”背后的真实问题网上有个热门问题“Agent做项目是不是需要很多个skill”我的回答可能会让一些人意外技能的多少从来不重要重要的是边界清楚、质量可控。我见过有人一个Agent挂了15个Skill结果模型经常不知道该用哪个同一个问题在不同轮次选择不一样也见过只挂2个Skill但每个都打磨得很精细的Agent表现非常稳定。这和代码工程里“函数不是越多越好而是职责越单一越好”是同一个道理。Skill就是一个给大模型调用的“函数”它的命名、描述、参数定义、返回值都必须清楚到让模型一看就懂该怎么用、什么时候用。如果技能边界重叠、触发条件含糊模型犯错是必然的评测工具就是用来帮你发现这类问题的。所以“需要多少个skill”这个问题应该被替换成另一个问题我现有Skill的质量有没有被量化验证过没有评测你连“边界清楚”这四个字都无从谈起。2.3 skill-up在技能工程里扮演什么角色放到整个Agent开发链路里看skill-up处在“开发完成”和“部署上线”之间的位置。你写了一个新Skill或者改了某个Skill的Prompt下一步不是直接上线而是先跑评测效果达标再发布效果回退就继续调。这种“评测驱动开发”的思路在机器学习领域很成熟现在被引入到Agent工程里skill-up做的就是这件事的标准化。它可以当CI流程里的一环和代码提交挂钩也可以当一个独立调试工具在开发期反复用。它的输入是你定义好的评测用例和待测Skill输出是结构化的报告报告里每一个指标都对应着“这个Skill在哪个维度上达标或者不达标”。3. 拆开skill-up它从哪几个维度衡量一个skill好不好3.1 评测框架的三层结构skill-up的整体设计可以拆成三层理解这三层结构是使用它的前提评测对象层你要测的Skill。它可以是注册到Agent框架里的标准Skill也可以是一个临时定义的工具函数。关键是暴露统一的调用接口让评测引擎可以无差别地调度。执行引擎层评测引擎会把“输入样例”喂给Agent由Agent自行决定是否调用待测Skill、怎么调用、怎么利用返回结果。引擎只负责记录不做主观判断。评估层把执行过程记录的轨迹和结果交给评估器产出量化指标。评估器既有规则检查比如返回的JSON是否能被正常解析是否包含必填字段也有模型打分用另一个大模型当裁判判断回答质量两部分结合。我自己一开始犯的错误是只看“最终正确率”这一个数后面才发现执行轨迹里的信息量更大模型有没有在没必要时乱调Skill调的时候参数提取错了几个返回结果模型读懂没这些链条上的问题单看结果数字根本发现不了。3.2 核心指标到底在测什么skill-up给出的指标我按自己的理解做了个归类指标维度实际含义典型问题功能正确率输出结果本身对不对答案算错、答非所问调用准确率该调用时调用、不该调用时不调用无关问题误触Skill、该触发时不触发参数提取完整度模型能不能从用户话术中提取出Skill要求的参数缺参数、参数值错误、格式不对鲁棒性面对同义改写、噪声、长句表现是否稳定换个说法结果大变稳定一致性同一评测集多次运行结果的波动程度同一问题两次答案不一样延迟与成本完成评测耗时和Token消耗多次无效调用、上下文过长这些指标不是孤立的它们经常联合作案。比如参数提取完整度低会导致功能正确率下降而模型为了强行补齐参数又会产生幻觉进一步拉低输出质量。评测报告的价值在于把因果链条拆开哪个环节是源头哪个环节只是结果一目了然。3.3 评测结果怎么呈现与对比skill-up会生成一份结构化报告包含总分、各维度指标分、失败用例明细以及每次运行的详细轨迹。报告支持做“对比模式”这是我用得最多的功能同一条Skill在修改前后各跑一遍评测直接看指标是涨是跌。这种对比模式在做回归测试的时候特别重要。AI应用的项目负责人都会遇到一个类似场景优化了A类问题结果B类问题变差了。没有评测集和对比报告这种回退只能靠用户投诉反馈出来有了对比报告你可以在发布前就发现及时回滚。4. 上手实测从安装到跑通一个完整评测case4.1 环境准备最省心的安装路径skill-up本身是一个Python包依赖比较轻建议在隔离环境里装。我实测的版本是Python 3.10直接跑# 创建并激活虚拟环境 python3.10 -m venv .venv-skillup source .venv-skillup/bin/activate # 安装 skill-up pip install skill-up安装完成后用skill-up --version确认是否装好。如果你要在评测里调用大模型还需要把模型API的密钥配置到环境变量里。这里有一个很容易忽略的点skill-up本身不绑定特定模型厂商它兼容OpenAI格式的API这意味着无论是通义、DeepSeek还是本地部署的支持OpenAI协议模型服务只要把base_url和api_key配置好就能用。提示第一次跑评测时先用最小的数据集验证链路通不通别上来就上几百条用例。我曾经一次配了300条用例直接开跑结果API Key配置错了报错后白白等了几分钟才暴露浪费时间。4.2 编写Skill定义与评测清单假设我要评测一个“订单查询Skill”它的输入是用户原始问题输出是结构化的订单状态。我会先写一个Skill定义文件描述这个Skill的能力、触发条件、参数规范# skill_definition.yaml name: order_query description: | 当用户询问订单状态、物流进度、发货时间、签收情况时使用。 用户必须提供订单号若未提供主动询问。 parameters: type: object properties: order_id: type: string description: 用户订单号通常是数字串可能以字母开头 required: - order_id output_schema: type: object properties: order_status: string estimated_arrival: string tracking_info: string这个文件会被加载进测试环境模拟Agent系统里的Skill注册流程。注意description里我写的是“必须”Skill触发条件描述得越精确实测效果越好模型在路由阶段越不容易误判。然后是评测清单定义用户问题、期望行为、期望结果# case_orders.yaml evaluation_set: - id: order_case_001 user_query: 你好帮我查一下订单20250315001到哪了 expected: trigger_skill: true skill_name: order_query param_check: order_id: 20250315001 output_check: contains: [运输中, 已发货] - id: order_case_002 user_query: 你们有什么优惠活动吗 expected: trigger_skill: false - id: order_case_003 user_query: 我的订单怎么还没到单号发你了快查查 # 无明确订单号 expected: trigger_skill: true param_check: order_id: null assistant_behavior: 应主动追问订单号不应编造查询结果case_001是标准命中场景case_002是防误触场景case_003是参数缺失场景。每个case都刻意覆盖不同类型的问题评测集的设计决定了你评测结果的有效性。4.3 运行评测与报告解读执行评测命令skill-up evaluate \ --skill skill_definition.yaml \ --cases case_orders.yaml \ --model qwen-plus \ --output report.json跑完后report.json里能看到每个指标的得分我挑几个典型结果说说功能正确率80%说明5个case里有1个最终答案不对参数提取完整度100%说明模型都能提取出order_id调用准确率只有60%说明case_002误触发了看到这个结果问题指向就非常明确模型在“识别不该调用场景”上不够准而不是参数提取得不好。那你的优化方向就应该集中在路由Prompt、Skill触发描述上而不是去调参数解析逻辑。这就是评测工具和“肉眼观察”的本质区别它把模糊的感觉变成可定位的问题。4.4 评测报告怎么接回开发流程对我来说评测报告不仅仅是开发阶段看。我更习惯让评测在每次修改后自动跑一遍把结果当代码测试一样对待。如果你用Git做版本管理可以在Commit前跑一次如果你有CI流程甚至可以把它挂到流水线里。有一个务实的建议初始评测集不用追求大追求覆盖度。50条精心设计的用例覆盖面足够的话评测效果比200条重复相似的强得多。往评测集里补充你在真实对话中发现的新问题让评测集跟着业务一起更新它才有长期价值。5. 理解评测逻辑才能优化skill实测中的几个关键点5.1 评测不是单元测试黑盒观察更接近真实刚开始用skill-up时我总是不自觉地把评测当成单元测试来写期望每个case都有明确断言要么过要么不过。现实很残酷——大模型输出是概率性的评测结果天然有无损波动。所以后来我把评测分成两类来设计硬性断言断言输出的JSON结构能否被解析必填字段是否存在。这类结果稳定、可直接拦截。软性评估断言回答是否贴合用户意图、有没有幻觉。这类用打分制1~5分用模型裁判评估。硬性断言用来解决“系统崩没崩”的问题软性评估用来解决“质量好不好”的问题两者分工不同。skill-up两种都支持但你得在写case时明确每个case属于哪一类不要混在一个期望里否则结果出来都不知道该按什么标准看。5.2 评测成本控制既要够用又不烧钱评测是要花钱的模型调用有成本尤其是每次评测都要用模型做裁判打分时成本会翻倍。我测算过一个中等规模的评测集200条case跑一次大约消耗30万Token左右商业模型按定价算下来是几块钱看着不贵但如果每天迭代跑10次一个月也是不小的一笔。控制成本有几个技巧按变更范围裁剪评测集只动了参数提取逻辑就重点跑参数相关case没必要全量跑一遍。先规则后模型能用正则、JSON Schema校验判断结果就别让模型打分省钱且稳定。失败优先重跑修改后的首次评测只跑上一次失败的case通过后再跑全量缩短反馈周期。我干活时会准备两份评测集一份mini集30条快速检验一份full集全量回归。先跑mini再根据情况决定要不要跑full效率高很多。5.3 case设计容易踩的三个坑第一用例语言太单一。如果你的业务既有中文又有英文或者有几种方言口音评测集要覆盖到。我见过一个团队只写中文case上线后发现英文提问触发不了对应技能非常尴尬。第二忽略上下文依赖型问题。真实对话里用户常常不把条件说全而是用“那这个呢”“不对我说的是另一个”这种指代。评测集要多设计这种前置多轮场景而不是每轮都独立提问。skill-up支持多轮对话的case录制这个能力一定要用起来。第三期望断言写得太死。比如期望输出“运输中”三个字模型回答“包裹正在运输途中”就被判错这种过度严格会让评测失去参考价值。期望应该按语义设定而不是按字符串匹配除非你是做严格的机器解析。6. 从会用工具到会写skill评测驱动下的skill工程化心得6.1 好skill是“设计”出来的评测只是验证用skill-up一段时间后我最大的变化不是更会看报告而是更会写Skill。评测指标倒推回设计原则很多问题在写Skill的那一刻就可以规避名称和描述里必须写清触发边界。描述里明确“不要用于售后”“不要处理退款”比在Prompt里反复强调更有用。参数定义要贴合用户真实表达方式。比如订单号在用户嘴里可能是“订单”“单号”“物流单”而不是你系统里的order_id。参数描述写得越贴近用户话术提取成功率越高。输出契约要让Agent好接。返回的JSON结构要包含Agent组装回复所需的全部信息缺失一个字段Agent就可能开始编。一个Skill如果有三处以上参数还指望模型一次全部提对这在评测里大概率过不了。这时你要么拆Skill要么设计成多轮追问而不是硬扛。6.2 迭代循环写case、跑评测、改定义、做回归我现在的标准流程是四步循环写case新Skill写好先随手写10到20条边界case压测“不该触发时莫乱动”。跑评测用mini集快速验证基本链路。改定义根据指标短板改Skill的description、参数schema或内部Prompt。回归跑full集确保优化里没有回退。这四步循环迭代跑上三轮左右Skill的稳定度通常会有显著提升。评测工具解决的根本问题不是“怎么改”而是“改哪里、改完之后到底变好了没有”。6.3 团队协作评测集是团队的共同资产最后说一个容易被忽视的点Skill评测集应该是一个团队资产而不是个人临时文件。团队里每个人都跑一份自己的评测集指标没法横向对比这个工具的价值就少了一大半。我们团队现在把评测集放在仓库里统一管理任何改动Skill的人必须更新对应case并且附带评测对比报告。这个做法带来两个好处一是新人能快速了解每个Skill的设计意图和边界二是版本迭代有据可循不会出现“我改了但我也不知道改坏了没有”的状态。skill-up的价值就在于此让Agent开发从“手工作坊”往“工程化”走了一步。它不神秘但真的有用尤其是当你被各种玄学级故障折磨到崩溃的时候一份清晰的评测报告往往能把你拉回正轨。先花半小时把评测集建起来后面省下的时间绝对远超这个投入。 
长河君 · 2026/9/8 20:49:52 · 阅读 1.2k 阿里开源skill-up：Agent Skill评测工具实战指南
写评测脚本、造评测数据到头来发现最大的瓶颈根本不是模型能力而是没法量化评估“这组配置到底比之前好在哪里”。尤其是Agent应用里大量使用Skill技能的时候问题更明显同一个问题今天跑是这个结果明天跑是另一个结果参数调了一版又一版上线还是翻车。阿里开源了一款叫skill-up的Agent Skill评测工具专门解决“Skill到底行不行”这个问题。这篇文章我会从“为什么需要它”开始讲把它解决的核心问题、评测框架、实际跑通的步骤、以及我踩过的坑一次说清楚。1. 为什么Agent开发越深入越绕不开skill评测这个环节1.1 从“能跑通”到“稳定交付”差距全在评测上接触Agent开发的头一个月绝大多数人是“能跑通就行”的状态调一个模型接口写两段Prompt封装成一个工具函数Demo演示给同事看效果惊艳全场鼓掌。这个阶段根本不需要评测工具因为你的判断标准是“有没有反应”。但一旦进入真实业务哪怕是内部效率工具要求立刻变成另一个维度正确率必须可度量、延迟必须可控、异常输入不能被带偏。这时候你会发现评测不是“加分项”而是“保命项”。拿我自己做过的一个项目举例给一个客服系统接入Agent让它在回答前先调用订单查询Skill。最初版本只测了3个case全过觉得自己已经搞定了。结果小范围上线第一天就出事——用户问“我上周买的东西到哪了”Skill里定义的参数是order_id模型死活提取不出来最后返回了一堆无关的物流公告。这类问题靠“多跑几个case肉眼核对”根本查不出来因为你不可能手动跑几百次话术变体。你需要的是系统性的评测工具把“模型在特定Skill上的表现”变成一组有说服力的数字。skill-up这类工具瞄准的正是这个缺口它不直接帮你调Prompt也不帮你写业务代码而是把“评测Skill”这件事本身做成一套可复用的流程。1.2 一个评测工具要解决的问题清单很多人在刚接触评测工具时会误以为它就是个“跑分脚本”。真上手之后你才发现一份合格的Skill评测方案至少要回答下面这些问题调用是否成功给定一组输入Skill是否能正常被触发并执行完毕这里不只是看模型有没有调用工具还要看参数提取对不对、返回格式是否符合下游解析要求。输出是否可靠同样的问题换个说法结果还成立吗评测需要覆盖同义改写、噪声插入、边界条件不然你只是在测“背题能力”。多轮场景下是否走样真实业务几乎没有“一问一答”的用户会追问、会补充条件、会临时改需求。Skill评测如果只测单轮上线必翻车。同一评测集跑多次是否稳定大模型输出天生有随机性评测工具得能跑出统计意义不能凭一两次结果下结论。多个Skill之间是否有干扰Agent系统里一般挂好几个Skill模型会不会在不需要的时候乱触发或者在需要的时候选错这属于编排层面的评测但也必须有数据支撑。这些问题单靠人工抽检只能发现“有毛病”没法量化“有多严重”。skill-up把这些维度拆成指标用统一流程跑完产出可对比的报告让你在做优化决策时有据可依。2. skill和agent到底是什么关系做项目真需要一堆skill吗2.1 先厘清概念agent是调度者skill是能力单元最近技术社区里“skill和agent的区别”这类问题热度很高。很多新人会把“Agent”理解成一个什么都能干的超级智能体把“Skill”理解成某几个Prompt模板这其实偏差很大。我的理解是这样的Agent是大脑加调度器负责理解目标、拆解任务、决定调用什么能力Skill是能力单元负责把某一类事情做得专业、稳定、可复用。举一个生活化的例子Agent像一家公司的项目经理Skill像公司里的各个专业部门。项目经理需要懂业务、懂资源调配但他不需要亲自会写代码、画设计图Skill部门则要能保证“活儿交过来按规范交付”。从实现层面看一个Skill一般包含三个要素触发描述什么样的问题应该调用这个Skill模型靠它做路由判断执行逻辑可能是纯Prompt也可能是Prompt加外部工具调用API、数据库、代码执行等输出契约返回结构长什么样方便Agent下一步决策或直接回复用户你品一下这个结构就会明白为什么评测Skill不能只看“最终答案对不对”还得看“该触发时是否触发”“不该触发时是否误触”。这两项恰恰是真实项目里最头疼的。2.2 “skills数量焦虑”背后的真实问题网上有个热门问题“Agent做项目是不是需要很多个skill”我的回答可能会让一些人意外技能的多少从来不重要重要的是边界清楚、质量可控。我见过有人一个Agent挂了15个Skill结果模型经常不知道该用哪个同一个问题在不同轮次选择不一样也见过只挂2个Skill但每个都打磨得很精细的Agent表现非常稳定。这和代码工程里“函数不是越多越好而是职责越单一越好”是同一个道理。Skill就是一个给大模型调用的“函数”它的命名、描述、参数定义、返回值都必须清楚到让模型一看就懂该怎么用、什么时候用。如果技能边界重叠、触发条件含糊模型犯错是必然的评测工具就是用来帮你发现这类问题的。所以“需要多少个skill”这个问题应该被替换成另一个问题我现有Skill的质量有没有被量化验证过没有评测你连“边界清楚”这四个字都无从谈起。2.3 skill-up在技能工程里扮演什么角色放到整个Agent开发链路里看skill-up处在“开发完成”和“部署上线”之间的位置。你写了一个新Skill或者改了某个Skill的Prompt下一步不是直接上线而是先跑评测效果达标再发布效果回退就继续调。这种“评测驱动开发”的思路在机器学习领域很成熟现在被引入到Agent工程里skill-up做的就是这件事的标准化。它可以当CI流程里的一环和代码提交挂钩也可以当一个独立调试工具在开发期反复用。它的输入是你定义好的评测用例和待测Skill输出是结构化的报告报告里每一个指标都对应着“这个Skill在哪个维度上达标或者不达标”。3. 拆开skill-up它从哪几个维度衡量一个skill好不好3.1 评测框架的三层结构skill-up的整体设计可以拆成三层理解这三层结构是使用它的前提评测对象层你要测的Skill。它可以是注册到Agent框架里的标准Skill也可以是一个临时定义的工具函数。关键是暴露统一的调用接口让评测引擎可以无差别地调度。执行引擎层评测引擎会把“输入样例”喂给Agent由Agent自行决定是否调用待测Skill、怎么调用、怎么利用返回结果。引擎只负责记录不做主观判断。评估层把执行过程记录的轨迹和结果交给评估器产出量化指标。评估器既有规则检查比如返回的JSON是否能被正常解析是否包含必填字段也有模型打分用另一个大模型当裁判判断回答质量两部分结合。我自己一开始犯的错误是只看“最终正确率”这一个数后面才发现执行轨迹里的信息量更大模型有没有在没必要时乱调Skill调的时候参数提取错了几个返回结果模型读懂没这些链条上的问题单看结果数字根本发现不了。3.2 核心指标到底在测什么skill-up给出的指标我按自己的理解做了个归类指标维度实际含义典型问题功能正确率输出结果本身对不对答案算错、答非所问调用准确率该调用时调用、不该调用时不调用无关问题误触Skill、该触发时不触发参数提取完整度模型能不能从用户话术中提取出Skill要求的参数缺参数、参数值错误、格式不对鲁棒性面对同义改写、噪声、长句表现是否稳定换个说法结果大变稳定一致性同一评测集多次运行结果的波动程度同一问题两次答案不一样延迟与成本完成评测耗时和Token消耗多次无效调用、上下文过长这些指标不是孤立的它们经常联合作案。比如参数提取完整度低会导致功能正确率下降而模型为了强行补齐参数又会产生幻觉进一步拉低输出质量。评测报告的价值在于把因果链条拆开哪个环节是源头哪个环节只是结果一目了然。3.3 评测结果怎么呈现与对比skill-up会生成一份结构化报告包含总分、各维度指标分、失败用例明细以及每次运行的详细轨迹。报告支持做“对比模式”这是我用得最多的功能同一条Skill在修改前后各跑一遍评测直接看指标是涨是跌。这种对比模式在做回归测试的时候特别重要。AI应用的项目负责人都会遇到一个类似场景优化了A类问题结果B类问题变差了。没有评测集和对比报告这种回退只能靠用户投诉反馈出来有了对比报告你可以在发布前就发现及时回滚。4. 上手实测从安装到跑通一个完整评测case4.1 环境准备最省心的安装路径skill-up本身是一个Python包依赖比较轻建议在隔离环境里装。我实测的版本是Python 3.10直接跑# 创建并激活虚拟环境 python3.10 -m venv .venv-skillup source .venv-skillup/bin/activate # 安装 skill-up pip install skill-up安装完成后用skill-up --version确认是否装好。如果你要在评测里调用大模型还需要把模型API的密钥配置到环境变量里。这里有一个很容易忽略的点skill-up本身不绑定特定模型厂商它兼容OpenAI格式的API这意味着无论是通义、DeepSeek还是本地部署的支持OpenAI协议模型服务只要把base_url和api_key配置好就能用。提示第一次跑评测时先用最小的数据集验证链路通不通别上来就上几百条用例。我曾经一次配了300条用例直接开跑结果API Key配置错了报错后白白等了几分钟才暴露浪费时间。4.2 编写Skill定义与评测清单假设我要评测一个“订单查询Skill”它的输入是用户原始问题输出是结构化的订单状态。我会先写一个Skill定义文件描述这个Skill的能力、触发条件、参数规范# skill_definition.yaml name: order_query description: | 当用户询问订单状态、物流进度、发货时间、签收情况时使用。 用户必须提供订单号若未提供主动询问。 parameters: type: object properties: order_id: type: string description: 用户订单号通常是数字串可能以字母开头 required: - order_id output_schema: type: object properties: order_status: string estimated_arrival: string tracking_info: string这个文件会被加载进测试环境模拟Agent系统里的Skill注册流程。注意description里我写的是“必须”Skill触发条件描述得越精确实测效果越好模型在路由阶段越不容易误判。然后是评测清单定义用户问题、期望行为、期望结果# case_orders.yaml evaluation_set: - id: order_case_001 user_query: 你好帮我查一下订单20250315001到哪了 expected: trigger_skill: true skill_name: order_query param_check: order_id: 20250315001 output_check: contains: [运输中, 已发货] - id: order_case_002 user_query: 你们有什么优惠活动吗 expected: trigger_skill: false - id: order_case_003 user_query: 我的订单怎么还没到单号发你了快查查 # 无明确订单号 expected: trigger_skill: true param_check: order_id: null assistant_behavior: 应主动追问订单号不应编造查询结果case_001是标准命中场景case_002是防误触场景case_003是参数缺失场景。每个case都刻意覆盖不同类型的问题评测集的设计决定了你评测结果的有效性。4.3 运行评测与报告解读执行评测命令skill-up evaluate \ --skill skill_definition.yaml \ --cases case_orders.yaml \ --model qwen-plus \ --output report.json跑完后report.json里能看到每个指标的得分我挑几个典型结果说说功能正确率80%说明5个case里有1个最终答案不对参数提取完整度100%说明模型都能提取出order_id调用准确率只有60%说明case_002误触发了看到这个结果问题指向就非常明确模型在“识别不该调用场景”上不够准而不是参数提取得不好。那你的优化方向就应该集中在路由Prompt、Skill触发描述上而不是去调参数解析逻辑。这就是评测工具和“肉眼观察”的本质区别它把模糊的感觉变成可定位的问题。4.4 评测报告怎么接回开发流程对我来说评测报告不仅仅是开发阶段看。我更习惯让评测在每次修改后自动跑一遍把结果当代码测试一样对待。如果你用Git做版本管理可以在Commit前跑一次如果你有CI流程甚至可以把它挂到流水线里。有一个务实的建议初始评测集不用追求大追求覆盖度。50条精心设计的用例覆盖面足够的话评测效果比200条重复相似的强得多。往评测集里补充你在真实对话中发现的新问题让评测集跟着业务一起更新它才有长期价值。5. 理解评测逻辑才能优化skill实测中的几个关键点5.1 评测不是单元测试黑盒观察更接近真实刚开始用skill-up时我总是不自觉地把评测当成单元测试来写期望每个case都有明确断言要么过要么不过。现实很残酷——大模型输出是概率性的评测结果天然有无损波动。所以后来我把评测分成两类来设计硬性断言断言输出的JSON结构能否被解析必填字段是否存在。这类结果稳定、可直接拦截。软性评估断言回答是否贴合用户意图、有没有幻觉。这类用打分制1~5分用模型裁判评估。硬性断言用来解决“系统崩没崩”的问题软性评估用来解决“质量好不好”的问题两者分工不同。skill-up两种都支持但你得在写case时明确每个case属于哪一类不要混在一个期望里否则结果出来都不知道该按什么标准看。5.2 评测成本控制既要够用又不烧钱评测是要花钱的模型调用有成本尤其是每次评测都要用模型做裁判打分时成本会翻倍。我测算过一个中等规模的评测集200条case跑一次大约消耗30万Token左右商业模型按定价算下来是几块钱看着不贵但如果每天迭代跑10次一个月也是不小的一笔。控制成本有几个技巧按变更范围裁剪评测集只动了参数提取逻辑就重点跑参数相关case没必要全量跑一遍。先规则后模型能用正则、JSON Schema校验判断结果就别让模型打分省钱且稳定。失败优先重跑修改后的首次评测只跑上一次失败的case通过后再跑全量缩短反馈周期。我干活时会准备两份评测集一份mini集30条快速检验一份full集全量回归。先跑mini再根据情况决定要不要跑full效率高很多。5.3 case设计容易踩的三个坑第一用例语言太单一。如果你的业务既有中文又有英文或者有几种方言口音评测集要覆盖到。我见过一个团队只写中文case上线后发现英文提问触发不了对应技能非常尴尬。第二忽略上下文依赖型问题。真实对话里用户常常不把条件说全而是用“那这个呢”“不对我说的是另一个”这种指代。评测集要多设计这种前置多轮场景而不是每轮都独立提问。skill-up支持多轮对话的case录制这个能力一定要用起来。第三期望断言写得太死。比如期望输出“运输中”三个字模型回答“包裹正在运输途中”就被判错这种过度严格会让评测失去参考价值。期望应该按语义设定而不是按字符串匹配除非你是做严格的机器解析。6. 从会用工具到会写skill评测驱动下的skill工程化心得6.1 好skill是“设计”出来的评测只是验证用skill-up一段时间后我最大的变化不是更会看报告而是更会写Skill。评测指标倒推回设计原则很多问题在写Skill的那一刻就可以规避名称和描述里必须写清触发边界。描述里明确“不要用于售后”“不要处理退款”比在Prompt里反复强调更有用。参数定义要贴合用户真实表达方式。比如订单号在用户嘴里可能是“订单”“单号”“物流单”而不是你系统里的order_id。参数描述写得越贴近用户话术提取成功率越高。输出契约要让Agent好接。返回的JSON结构要包含Agent组装回复所需的全部信息缺失一个字段Agent就可能开始编。一个Skill如果有三处以上参数还指望模型一次全部提对这在评测里大概率过不了。这时你要么拆Skill要么设计成多轮追问而不是硬扛。6.2 迭代循环写case、跑评测、改定义、做回归我现在的标准流程是四步循环写case新Skill写好先随手写10到20条边界case压测“不该触发时莫乱动”。跑评测用mini集快速验证基本链路。改定义根据指标短板改Skill的description、参数schema或内部Prompt。回归跑full集确保优化里没有回退。这四步循环迭代跑上三轮左右Skill的稳定度通常会有显著提升。评测工具解决的根本问题不是“怎么改”而是“改哪里、改完之后到底变好了没有”。6.3 团队协作评测集是团队的共同资产最后说一个容易被忽视的点Skill评测集应该是一个团队资产而不是个人临时文件。团队里每个人都跑一份自己的评测集指标没法横向对比这个工具的价值就少了一大半。我们团队现在把评测集放在仓库里统一管理任何改动Skill的人必须更新对应case并且附带评测对比报告。这个做法带来两个好处一是新人能快速了解每个Skill的设计意图和边界二是版本迭代有据可循不会出现“我改了但我也不知道改坏了没有”的状态。skill-up的价值就在于此让Agent开发从“手工作坊”往“工程化”走了一步。它不神秘但真的有用尤其是当你被各种玄学级故障折磨到崩溃的时候一份清晰的评测报告往往能把你拉回正轨。先花半小时把评测集建起来后面省下的时间绝对远超这个投入。