先说一个我最近特别深的感受GitHub 上 Skill 类项目越来越多Claude Code、Codex、Cursor 这些 Agent 工具也都开始支持加载自定义 Skills但真正能把“某个 Skill 到底有没有用、值不值得装、会不会把别的任务搞坏”说清楚的项目少之又少。很多人装了一堆 Skills跑一次 demo 觉得“哇好强”用到真实任务上却翻车翻完车也不知道是模型的问题、Skill 编排的问题还是这个 Skill 本身的 prompt 写崩了。这个项目想解决的就是这件事——做一个专门负责Agent/Skills 专项能力评估的 agent把“评估”本身变成一个可运行、可量化、可回归的工程化流程而不是靠人类肉眼一个个试。这套东西适合谁两类人。一类是自己写 Skills 的开发者你需要知道每次改动是变好了还是变差了另一类是重度使用 Agent 工具的人你装了十几个冷门 Skills想在接新任务之前提前知道哪些能信、哪些是雷。下面的内容我完全按自己从零搭这套评估 agent 的实操过程来讲包括设计思路、数据怎么造、评估维度怎么定、运行流程怎么串以及我踩过的各种坑。项目本身不算难难点全在细节里。1. 为什么 Skill 的评估必须“专项”来做1.1 “跑通了”和“能稳定跑好”是两回事先说一个最常见的误区很多人评估 Skill 的方式就是拿一个任务跑一次看到了理想输出就说这个 Skill 可用。但 Agent 场景下的 Skill 调用本质上是一个带随机性的过程——同一个任务、同一个 Skill、同一个模型你跑十次结果大概率不是十个相同的输出而是五次成功、三次部分成功、两次完全跑歪了。我见过最典型的一个例子是某个让 Agent 画图表的 Skill。第一次调用时它正确地把数据转成了 SVG输出格式完美。第二次换了一组结构类似、但字段名不同的数据它开始自由发挥把列名张冠李戴生成了一张完全错误的图而且代码层面没有任何报错。这种情况单次人工验证永远发现不了。所以 Skill 评估的第一条铁律就是必须多次运行并统计成功率。至于跑多少次才有统计意义后面我会给出一个可操作的参考值。但这里先记住单次运行通过不等于 Skill 可用这是整个评估 agent 存在的基础。1.2 从 Agent 评估到 Skill 评估控制变量拆问题现在业界聊 Agent 评估更多是在聊端到端评测——给一个完整业务任务让 Agent 自己规划、选工具、调用、校正最后看任务完成度。这种方式有价值但它有一个天生缺陷它无法告诉你失败是因为 Agent 规划错了、模型理解错了还是某个 Skill 本身坏了。你想象一下你有一个“前端开发 Skill”Agent 拿着它去改一个 React 页面最终结果不对。端到端评估只能告诉你“失败了”但改页面这个链路里至少有三个环节可能出错Agent 没有正确分析需求、Agent 把问题拆错了子任务、或者 Skill 本身给出的代码模式有问题。你修完 Skill 再跑一次还是失败——因为你没搞清楚到底是谁在拖后腿。专项评估的思路就是把变量拆开。我评估某个 Skill 时会构建一个隔离环境固定的 Agent 行为模板、固定的任务集、只有这一个 Skill 可用。这样所有波动都归因到 Skill 自身。先把每个 Skill 的“单体能力”测准了再去看多 Skill 协同问题就好定位了。评估 agent 本质上就是一套自动化的控制变量实验装置。1.3 给评估 agent 一个明确的职责边界做这个项目之前我先把评估 agent 的职责边界划清楚了。它不是一个通用的测试平台也不是一个 Agent 开发框架它就是把“评估某个 Skill”这件事变成一条流水线。具体来说它做四件事加载被测 Skill 的定义文件、prompt、工具描述在受控的 Agent 运行时里让 Agent 利用这个 Skill 去执行一组测试任务收集执行过程中的所有中间信息模型输入输出、tool_call 参数、返回结果、异常堆栈按预定义的评价规则生成成功率、质量分、成本、延迟等指标输出一份可对比的评估报告。所以它本质上是一个Agent Eval 系统只不过瞄准的目标单位不是整个 Agent 应用而是可插拔的 Skill 单元。想把这个边界守住最关键的一点是评估 agent 自己不要直接参与业务决策——它不修改被测 Skill不做内容生成只做运行观测、数据采集和评分判定。把“裁判”和“运动员”分开结果才有参考价值。2. 评估数据与评测维度怎么定2.1 一份能落地的 Skills 评测集长什么样有了评估的框架思路接下来要解决的就是拿什么任务去考验一个 Skill这里面有个很容易犯的错误——大家习惯于拿“创造类任务”去测 Skill比如让它写一首诗、画一张图、写一段营销文案。这类任务没有唯一正确答案评分主观跑完你也不知道 Skill 是 80 分还是 60 分。我自己的经验是一份有效的评测集必须包含相当比例的“确定性任务”——也就是有明确输入、明确预期输出、可以客观判对错的任务。比如你有一个“前端组件生成 Skill”评测任务就可以是“给定一个数据表格的数据源生成一个能展示这些字段的 React 组件”预期输出里包含组件正确使用了哪些字段、 props 定义是否正确、是否包含必要的样式。这些都能程序化校验。评测集里每个用例至少需要这几个字段字段作用task_id用例唯一编号name简短的任务名称input给 Agent 的完整任务描述test_data任务执行需要的数据按固定格式传入checkers判分规则列表可以是规则脚本或评分 prompt 模板difficulty难度标签easy / medium / hard用于分层统计categorySkill 的功能分类如“代码生成”“图片处理”“数据分析”我一开始犯的错是只写 input不写 checkers结果跑完任务只能靠人工看日志打分效率极低。后来我强迫自己给每个用例配好“判分规则”哪怕是一条“输出中必须包含某个 JSON 字段”的简单规则评估的可自动化程度也会大幅提升。2.2 五大核心维度和打分思路我把 Skill 的打分维度定为五个功能正确性、稳定成功率、输出质量、资源消耗、回归风险。前两个最重要后三个根据场景可选。功能正确性是最直观的针对确定性任务看输出是否满足预设规则。比如生成一个代码文件就检查文件是否可编译、是否包含指定功能点、是否通过了对应的单元测试。这个维度我用“规则命中率”来量化先列出一组二值判断项逐项检查命中的比例就是该项得分。稳定性就是多次运行的成功率。评估 agent 会对同一个用例跑 N 次统计成功次数占比。N 的取值我建议是细粒度回归至少 5 次、发版前全量评估至少要 10 次。太少没统计意义太多成本扛不住。输出质量采用LLM-as-Judge来打分但这里的 Judge 模型必须和被测 Agent 使用的模型分开。如果你被测者是 Claude评分模型就尽量别再用 Claude换一个不同家的模型降低“自卖自夸”倾向。资源消耗记录的是单次任务消耗的 token 数、耗时和调用失败率。这个维度主要用于对比不同版本的 Skill如果改动后质量分提升但 token 消耗暴涨你得权衡是否值得。回归风险是一个比较进阶的维度。我会拿一个与当前 Skill 功能无关的“干扰任务集”测一下加载这个 Skill 后Agent 做无关任务时表现有没有下降。有些 Skill 的 prompt 写得很霸道会污染 Agent 的系统提示词导致原本正常的能力变差。这个维度就是为了抓这种隐蔽问题。2.3 概率性任务如何兜底确定性校验 LLM-as-Judge 双轨任何一个以 LLM 为核心的评估都会遇到“模型输出不可复现”的痛点。同一个评测用例你昨天跑是 90 分今天模型后端升级了一下变成 70 分你分不清是 Skill 改了还是模型变了。所以我最终的评分策略是双轨制先跑确定性校验规则再跑 LLM-as-Judge 的指令评分。确定性校验是硬指标比如输出不能缺关键字段、格式必须合法、不能有语法错误这类规则错了就是错了没有商量余地。只有通过确定性校验的输出才有资格进入 LLM-as-Judge 环节去评内容好不好、结构是否清晰、是否满足任务意图。这种双轨制的好处在于当分数出现明显波动时我能迅速区分问题的性质——是“无法执行”级别的硬错误增加了还是“执行了但不理想”的软性问题变多了。前者多半是代码报错、工具调用失败等工程问题后者多半是 prompt 设计、模型理解等语义问题。两类问题的修复手段完全不同分开统计才能少走弯路。3. 评估 Agent 的实现从运行到报告3.1 整体流程一句话说清评估环整个评估 agent 的运行流程可以浓缩成一句话从评测集读到任务描述放进一个受控的 Agent 执行环境里跑跑完把完整过程记录下来再用规则和 Judge 模型打分最后汇总成对比报告。受控执行环境是这里面最容易被低估的部分。它意味着固定的模型名称和版本、固定的 temperature 和 top_p、固定的系统提示词模板、固定的工具列表。我建评估环境时把所有可能影响结果的变量都写成了配置项每次评估跑完配置信息会一并存到结果文件里方便回溯。这里必须单独说明一下Agent 运行时和评估运行时不是一回事。日常开发 Agent 时核心是完成任务但做评估时核心是“可观测、可复现”。所以我在执行环境里做了两件增强一是完整记录每一次工具调用的参数和返回体包括 Agent 发起的重试二是给模型的每次回复都打上时间戳和 token 计数。没有这两层记录后面做失败归因基本就是靠猜。3.2 代码骨架一个最小可跑的评估 Agent下面给一个 Python 伪代码的评估循环骨架它不依赖具体某个 Agent 框架核心逻辑是通用的import json import time import random def run_single_eval(agent_runtime, test_case, model_config, max_retries3): # 1. 重置运行时到干净状态 agent_runtime.reset() agent_runtime.set_model( namemodel_config[name], temperaturemodel_config[temperature], ) # 2. 注入被测 Skill agent_runtime.load_skill(test_case[skill]) logs [] start_ts time.time() success False last_result None for attempt in range(max_retries): try: result agent_runtime.execute_task( tasktest_case[input], test_datatest_case[test_data], ) logs.append({ attempt: attempt, trace: agent_runtime.get_last_trace(), usage: agent_runtime.get_last_usage(), }) # 3. 先跑确定性校验 if run_deterministic_checks(test_case[checkers], result): success True last_result result break except Exception as exc: logs.append({attempt: attempt, error: str(exc)}) duration time.time() - start_ts return { task_id: test_case[task_id], success: success, duration: duration, attempts: len(logs), logs: logs, result: last_result, } def run_eval_suite(runtime, suite, model_config): results [] for test_case in suite: case_results [] for round_idx in range(suite[rounds]): case_results.append(run_single_eval(runtime, test_case, model_config)) results.append({ test_case: test_case[task_id], rounds: case_results, success_rate: sum(r[success] for r in case_results) / len(case_results), }) return results这个骨架里最值得注意的一点是我在execute_task前后强制重置了运行时状态避免上一个用例产生的上下文影响下一个用例。这也是“受控环境”的落地姿势之一每次测试都是新会话、干净上下文只有这样才能把变量压缩到最小。3.3 评判结果的日志结构与失败归因评估跑完日志信息非常多如果不做结构化整理复盘的时候就是一场灾难。我的日志结构分三层任务层、运行层、原子事件层。任务层记录的是这个用例的静态信息和最终结论运行层记录的是第几次运行、是否成功、耗时多久原子事件层记录的是运行过程中每一次模型调用和工具调用的详细内容。每经过一轮运行日志都会被序列化成 JSON 存下来。这是我的事件记录格式里一个小小的例子{ event: tool_call, tool_name: web_search, arguments: {query: Claude Skills 评估最佳实践}, result_summary: search_engine returned 8 results, latency_ms: 1240, token_usage: {input: 980, output: 240} }之所以要把原子事件都存下来是因为我在实际评估中遇到过太多“结果对了但过程完全错了”的情况——比如 Agent 最终输出的代码能跑但它是通过调用另一个不相关的内置工具碰巧生成的被测 Skill 压根没被触发。如果只看最终输出你会误判这个 Skill 是功臣只有看了原子事件你才会发现它是个旁观者。失败归因永远要基于过程数据而不是基于结果猜测。3.4 报告怎么出才有决策价值拿到了原始日志最后一步是生成可读的评估报告。报告不是简单地贴一堆数字而是要能回答三个问题这个 Skill 能用吗这个版本的改动是进步还是退步最该修的短板是什么我的报告格式类似这样第一块是总览成功率、平均耗时、平均 token 消耗、总体质量分。第二块是分用例明细每个任务的成功次数、失败次数、失败的那次卡在哪个环节。第三块是失败原因聚类把失败日志按特征聚合比如“JSON 解析失败”“超时”“模型拒绝调用工具”“输出格式不符合 schema”做成一个简单的排序表。这里有个小技巧——报告的用途不同颗粒度也应该不同。我自己开发时天天看的是 full trace 级的日志但发给团队或者留档时只会导出汇总报告和失败原因分布。颗粒度和阅读对象匹配上评估报告的利用率会高很多。4. 自己写还是用现成框架4.1 现成工具能解决什么这个方向不是没有现成的方案。现在很多 Agent 开发框架都内置了 eval 模块还有一些专门的 evals 工具、可观测性平台都能帮你在一定程度上做回归测试。对于有运维能力、非核心链路的项目直接用这些现成方案完全够用。但我把项目定位成“专项能力评估 agent”是因为现成方案普遍围绕“完整 Agent 任务”做设计很少做到 Skill 粒度。你装了一个第三方 Skill想在受控环境里单独拷打它用通用 eval 工具总觉得别扭——它们往往缺少“加载某个独立 Skill 包并隔离验证”的原生概念你必须在每次评估前手写一堆胶水代码去模拟这种隔离。4.2 Harness、Agent、Skill 三者的边界很多热词都提到“Agent”“Skill”“Harness”这三者的边界其实是理解评估架构的关键。我们日常碰到的 Agent 开发项目通常会同时包含这三个层面。Harness 是运行环境是一个脚手架负责串起模型调用、工具注册、上下文管理等基础能力。Agent 是上层调度者它接收任务拆解计划决定调用哪个工具。Skill 则是一类特殊的“预置专业能力包”它里面既包含一段精心设计的技能说明 prompt也包含配套的工具调用规格、参数 schema、后处理逻辑。评估 agent 要做的就是在一个受控 Harness 里把某个 Skill 安装进去然后看 Agent 在它的加持下表现如何。也就是说评估项目不是去重写一个 Agent 框架而是扩展一层“评测运行时”让 Harness 既能在生产环境里跑任务也能在评测环境里跑用例采集。理解了这个分层你就知道为什么很多现成 Agent 框架做 Skill 评估很别扭它们把 Harness 和业务 Agent 耦合得太紧刻意抽象出 Skill 隔离层的反而少见。4.3 我选择自研的理由和取舍当时我评估了几个方向最终决定自研一个轻量的评估 agent并且把它做成一个独立的服务通过 API 与业务 Agent 运行时打交道。这是因为我需要三份自由度第一是评分规则的自由度。我的评分体系里既有规则校验又有模型打分还有自定义的领域约束检查。现成 eval 工具大多把模型打分做得很重规则校验做得很浅很难满足我的双轨制需求。第二是报告结构的自由度。我希望报告本身就是给 Skill 开发和运维看的“体检单”而不是通用 dashboard。自己生成报告可以完全控制信息密度。第三是集成方式的自由度。我希望能一键对一批 Skills 批量跑评测然后把结果推给上游的 CI 系统。这种自动化集成在现成工具里配置起来往往更繁琐。自研的代价也是明显的评估 agent 本身也要维护它的日志机制、并发控制、失败恢复都得自己写。如果团队没有足够的工程人力我还是建议先从轻量自动化脚本做起等确实跑不通了再升级为完整自研系统。4.4 集成进 CI/CD 的实操评估 agent 如果你只在自己电脑上跑价值会小一半。真正让它发挥作用需要把它挂到 CI/CD 流程里让每次 Skill 更新都自动触发一轮回归评估。我的集成方式是这样的在 Git 仓库里每个 Skill 目录下放一个eval_suite.json文件里面声明这个 Skill 的评测用例和期望的量化阈值。当有 MR 修改任何一个 Skill 时CI 流水线会提取变更目录对变更的 Skill 跑完整评估评估报告回传到流水线里。如果成功率低于设定阈值比如低于 80%或关键质量分下降超过 5%流水线自动标红MR 不能被合并。这个流程看起来简单但有一个非常坑的细节CI 环境和本地环境性能差异很大模型调用延迟不同、并发能力不同所以“超时阈值”不能定得太死。我在 CI 里用的超时时间就比本地调试时放宽了 1.5 倍否则评估 agent 会频繁误报超时异常。5. 常见问题、踩坑与每日心得5.1 结果不稳定先查这几个变量我最早跑评估时遇到过同一个 Skill 连续三天成功率从 90% 掉到 60% 的情况当时一度怀疑是 Skill 被改坏了。排查了整整两天最后发现问题出在模型服务端的配置上。这是一个非常容易踩的坑简单梳理一下会导致评估结果不稳定的几个常见变量模型版本和实例同一个模型名后端可能指向不同版本或不同规格的实例输出分布差异巨大temperature 和 top_p这是最直接的随机性来源评估时必须固定上下文长度变化如果同一会话里塞入了不同数量的历史消息结果也会跟着变缓存策略有些服务端会对相似请求做缓存导致第二次运行直接返回缓存结果数据失真外挂系统提示词Agent 框架如果版本升级系统提示词可能悄悄变化而这种变化往往不显眼。我的经验是评估 agent 每次运行前先校验一下模型配置是否符合预期再把运行时版本一起记录进日志。这是我踩过坑之后的强制措施。5.2 “看起来对了”但实际没生效的幻觉结果这是第二个大坑也最隐蔽。Agent 在调用某些 Skill 时经常会出现一种“幻觉式成功”——它生成了看起来非常合理的输出但常识或领域规范上根本就是错的。举一个我真实遇到的有一个“数据分析报告生成 Skill”我给它的测试任务是“根据一份销售表数据生成周报”。Agent 输出的报告结构完全正确——有结论、有图表、有建议质量分我给了 90。但后来我仔细对比原始数据才发现报告里引用的关键数字和原始表根本对不上模型在编造数据。这就是为什么我把确定性校验放在 LLM-as-Judge 之前的另一个原因。对于这种任务我会额外加一条规则输出中出现的所有关键数字必须能在原始数据里找到一致来源否则判为硬性失败。光靠模型打分它只会觉得“写得挺好”但事实上这是一份有害的产出。5.3 多 Skill 联动时怎么定位回归评估单个 Skill 相对简单难的是多个 Skill 配合使用时出了问题你怎么定位是谁的锅。这个问题在 Skill 生态逐渐丰富后会越来越常见。比如你同时装了“图片生成 Skill”和“页面布局 Skill”Agent 做一张海报时两个 Skill 都要用结果页面错位了到底是谁的错我的办法是分层组合测试先各自测单个 Skill 的基线分再测“目标 Skill 基线 Skill”的配对分最后才测试完整组合。一旦组合测试失败就逐个拆掉参与组合的 Skill找到造成降分的元凶。这个思路其实就是软件工程里的二分排查法放到 Agent 场景下同样有效而且效果意外地好。5.4 成本与效率平衡的几个技巧评估本身很烧 token尤其是你要跑多轮、多个用例、好几十个 Skill 的时候。如果不加控制一个完整批次的评估可能花掉几千块 API 费用。我自己反复拿捏之后总结出了几条省钱的策略先跑冒烟集每个 Skill 上线前先跑 3 到 5 个低成本用例快速判断有没有明显问题通过后才跑完整评测集分难度采样如果评测集太大不一定每次全量跑可以按难度分层随机抽样先跑 easy 和 mediumhard 用例只在发版级别或定期全量评估时跑设置请求并发上限并发太高会导致偶发超时和限流反而增加重试次数成本更高控制 Judge 模型的输出长度LLM-as-Judge 的最终打分 prompt 里明确要求输出固定长度的 JSON不要让它自由发挥写长文本评价。5.5 测试用例的隔离与污染最后这条是关于测试数据本身的。最开始我构建评测集时比较随意后来发现某些 Skill 在评估时表现越来越好不是因为它变强了而是因为测试用例被写进了 Skill 的 prompt 或 Agent 的上下文缓存——也就是说它在“背答案”。这种情况在独立会话测试里可能不算严重但如果你用了共享上下文或长会话污染会越来越明显。我的对策是评估数据绝不直接引用线上真实业务数据而是构造一套和业务分布相似但不重合的模拟数据。测试用例文本也要做脱敏和改写避免 Agent 在“记忆”里直接匹配到训练样本。另外每次评估都强制使用干净上下文并在配置里禁止缓存相关选项。6. 还能再往后推一步6.1 从评估到 Skill 市场的信任机制现在各家平台都在推 Skills 市场、Skills 推荐站点各种热门 Skills 下载量很高但质量参差不齐。前端开发 Skills、图片生成 Skills、LaTeX 排版 Skills……数量一多用户根本不知道哪个值得信任、哪个装了是负优化。如果 Skill 的提供者在发布前就附上一份标准化的评估报告——包含成功率、质量分、回归风险、资源消耗——整个市场的信任度会完全不同。可以想象一个场景一个 Skills 市场的详情页里不只有 star 数和下载量还挂着由第三方评估 agent 生成的 avals 徽章。用户决策的成本会骤降。这个方向其实已经在往 “Agent Evals” 的边界靠。现阶段做 Skill 专项评估的团队还不多谁先把这个流程做标准谁就有机会定义 Skill 生态里的“质检通行证”。6.2 把评估 agent 变成日常开发提效工具后续我还想把评估 agent 做成一个常驻的“开发助手式”能力在本地写 Skill 时不用等到 CI 才跑评估而是检测到文件变更后自动跑冒烟集并给出实时反馈。本质上这类似一次“本地 lint 单元测试”组合只不过被测试的对象从代码函数变成了 Skill 的行为。我自己一开始只是想做一个小工具解决“这个 Skill 到底行不行”的疑问结果越做越发现Skill 这个概念的兴起把 Agent 生态里最需要经验的“评估”问题推到了台前。以后一定会有人做出更完善、更通用的 Skill 评测标准但这不妨碍我们现在就动手先把自己的“质检员”跑起来。最后再分享一个实操中反复验证过的体会评估 agent 最重要的不是复杂而是克制。克制住不要加太多花哨指标克制住不要用人眼替代规则克制住不要试图一次评估覆盖所有场景。先从单一 Skill、单一评分维度、五个用例跑起来再慢慢增加复杂度。这样你手上这套评估系统会越用越稳也更容易在团队里落地成为常规流程。