给 Agent 技能打分乍看是个标准的测评话题但我系统性啃完 9 篇和技能评测相关的前沿论文后最大的感触是这件事根本不是出题、考试、给分的线性流程而是一道必须分层拆解的工程题。技能评测要同时处理任务设计、环境搭建、交互数据采集、指标口径和失败归因任何一层没做扎实最后那个分数都会失真。这里我按工程分层把那 9 篇论文重新组织了一遍把每一层在解决什么、有哪些坑、论文里是怎么处理的都串起来讲。适合正在给 Agent 做应用的研发团队、想搭建内部评测平台的同学也包括所有不想被 Benchmark 表面分数带偏的人。1. 为什么给 Agent 技能打分突然成了硬需求1.1 从模型考试到技能评测变的不只是题目形态传统大模型评测的核心是一问一答出题、让模型答、拿参考答案比对。这个范式在文本能力评测上很成熟但用到 Agent 身上立刻露馅。Agent 的典型任务是一个多轮交互过程用户丢一句帮我把这周三个数据源合并成一张报表Agent 要先判断需要哪些工具逐个调用处理中间报错最后产出结果文件。整个过程可能是十几轮对话、几十次工具调用任何一个环节卡住任务都可能功亏一篑。我现在看到越来越多的团队在自建评测集但大多数做法是拿一个 Benchmark 跑一下出一个总分然后就没有然后了。总分高到底高在规划能力还是工具调用熟练度总分低是任务太难还是环境有问题单看一个数什么都回答不了。这就是为什么技能评测这四个字必须从考试题的思维切换成工程系统的思维。1.2 九篇论文的共同主线评测是流水线不是考试我读的这 9 篇论文来源比较杂有学术实验室的工作也有产业研究团队的产出但它们有一条高度一致的主线都把评测当成一条流水线而不是一次考试。流程大致是先构造任务集合和仿真环境再让 Agent 和环境交互并完整记录轨迹然后把轨迹喂给指标层计算得分最后把分数和错误样本一起送进分析模块做归因。有意思的是这 9 篇论文没有一篇是从头到尾覆盖整条流水线的而是各管一段。有的专注任务难度标定有的专注环境仿真度有的专门打磨指标口径有的死磕失败归因。这本身就说明问题技能评测已经大到单篇论文装不下必须分层协作。这个观察直接印证了我后来的判断——用分层工程的方式来组织评测工作是成本最低、最容易迭代的结构。2. 整体拆解把技能评测分成四层工程2.1 四层结构长什么样我把这 9 篇论文按职责归成了四层分别是任务构建层、交互观测层、指标计算层、结果分析层每层回答一个核心问题。层级核心问题对应论文数代表性工作方向任务构建层测什么题目和场景是否合理3任务难度标定、环境仿真度、数据污染检测交互观测层怎么记录 Agent 的一举一动2轨迹格式标准化、观测粒度设计指标计算层怎么给过程与结果打分2过程指标与结果指标、裁判口径一致性结果分析层分数背后的原因是什么2失败归因、能力画像、回归机制这个分层不是拍脑袋分的。我读论文时发现不少评测系统的失败案例都出在相邻层的边界上。比如任务层的题目设计得很好但观测层没记录关键中间状态导致指标层无法判断 Agent 是否走了合理路径又比如指标层定义得很严格但结果分析层没把错误样本按模式聚类迭代时只能瞎猜。四层划分本质上是在给评测系统画清晰的职责边界让每一层可以独立替换、独立优化而不是牵一发而动全身。2.2 分层带来的工程收益分层最直接的好处是可维护性。评测系统不是搭完就完事的Agent 在迭代、环境在升级、任务集合在扩展如果所有逻辑揉在一起改一处崩一片。分层之后换一个任务生成器不影响指标计算升级指标口径不需要重跑整个环境观测协议调整也不会牵动结果分析的代码。第二个收益是可解释性。当两个 Agent 版本对比时如果总分下降我可以逐层定位是任务分布变了、还是观测有缺失、还是 Agent 本身在某个技能维度退化了。我在实际项目中见过一个相关案例某团队某次发版后所有任务成功率掉了十几个点排查了半天最后发现不是模型退化而是仿真环境里一个第三方接口的返回格式变了。如果评测系统没有分层这种事故几乎不可能快速定位。能三分钟定位到环境层问题和折腾三天只能通过回滚代码来试错差别就是分层带来的。3. 第一层任务构建与环境搭建3 篇论文的重点3.1 任务设计的三个原则覆盖度、难度梯度、语义真实性任务构建层是整个评测系统的地基。3 篇论文切入点不同但总结下来都在强调三个原则。第一是覆盖度。Agent 的技能不是单一的至少要覆盖规划、工具选择、参数填充、错误恢复、多步推理这几类。很多评测集在覆盖度上很偏科工具调用占了八成题目规划类任务稀疏结果模型只把工具调用练好了放到真实场景还是经常卡在中间步骤。论文里的做法是把技能清单前置定义好要测的技能再把任务分配到技能网格上保证每个格子都有样本。第二是难度梯度。如果一个评测集里 90% 的任务所有模型都能做对这个评测集对你已经没有区分度了反过来如果 90% 的任务所有模型都做不对评测就成了纯粹的挫败体验也拿不到有效信息。难度梯度要像考试卷一样有基础题、有进阶题、有压轴题这样才能把不同水平的 Agent 拉开让每次迭代的进步或退步都看得见。第三是语义真实性。任务描述必须贴近真实用户的话术。我见过不少评测任务为了让标准答案更容易匹配把用户指令写成了结构化文档格式——这测的根本不是 Agent 的理解能力而是模型对文档模板的检索能力。有篇论文专门做了统计把任务指令从口语化表达改成书面化结构表达后同样的 Agent 指标可以差出一大截。任务表述方式的真实度直接决定了评测结论在真实场景里的参考价值。3.2 环境仿真度做到 80% 还是 100%任务有了还得有让 Agent 跑起来的考场也就是仿真环境。这类场景通常是模拟 API 集合、模拟数据库、模拟网页。这里有个经典问题仿真到底要做到多真有篇论文的结论很有意思环境仿真度和评测有效性的关系不是线性的而是存在一个阈值。低于某个仿真度Agent 在评测里学到的东西和真实场景里需要的策略会脱节高于某个仿真度边际收益急剧下降但搭建和维护成本持续上升。原因也简单真实系统里有大量噪音、延迟、随机报错、边界数据仿真度不够时Agent 在评测里表现完美一上真实环境就原形毕露但仿真度够了之后多模拟一个奇葩报错场景对评测结论的影响其实很小。我个人的建议是把仿真度重点投向三个方面接口返回格式的真实性、错误分支的覆盖率、状态的一致性和可恢复性。接口格式不真实Agent 学的就是一套假的解析逻辑错误分支太少Agent 的兜底能力完全测不出来状态不一致评测结果根本不可复现。至于 UI 像素级还原、网络延迟的精确模拟属于边际收益比较低的投入可以往后放。3.3 数据污染任务层的第一道防线任务构建层还有一个容易被忽视的环节数据污染检测。很多评测任务是拿大模型辅助生成的生成过程本身就可能把已有模型的答题模式带进去如果生成时用了包含答案的上下文评测就失效了。更隐蔽的一种污染是评测任务和训练语料有高度相似的内容模型不是会做而是背过。论文里比较通用的做法是查重加扰动。首先做 n-gram 级别的相似度筛查把和训练语料大面积重合的题目剔除其次对保留的任务做语义扰动比如改写人名、数字、时间线确保任务虽然结构相同但模型不能靠记忆作答。实操里我经常用一个土办法拿一个能力明显不够格的小模型跑一遍整套评测如果它在某类任务上得分异常高就要警惕那类题目是不是存在泄漏。这个方法不是论文教的但实测下来特别能暴露问题。4. 第二层交互观测与数据采集2 篇论文的重点4.1 观测粒度决定你能做什么分析第二层负责记录 Agent 和环境的每一次交互。听起来无非是打日志但论文里反复提醒一个词观测粒度。粒度太粗只有最终结果和对话文本那你能做的分析就非常有限。你没法知道 Agent 是在哪一步开始跑偏的也没法判断工具参数填错和工具选错到底谁更频繁而这些恰恰是迭代模型最重要的输入。粒度太细每一步都记录全部系统状态存储和加工成本爆炸而且大量中间状态根本用不上。合适的粒度我自己的经验是至少记录四类内容用户输入、Agent 的决策输出包括思考过程、工具调用、参数、环境返回的结果、时间戳和成本信息。有篇论文专门对比过加了思考过程的观测之后失败归因的准确率明显提升因为很多错误发生在Agent 想错了而不是执行错了看不到思考过程分析时就只能靠猜。观测层漏掉的信息后面任何一层都没法补救这是把观测设计放在前面位置的根本原因。4.2 轨迹格式与对齐问题两篇论文里都提到了轨迹数据标准化的问题。Agent 评测里一次任务会产生一条轨迹由多轮观测—决策—执行—反馈组成。如果不定义统一格式指标计算层每次都要重新适配而且不同来源的实验结果没法直接对比。我建议团队内部尽早定一个简单的轨迹协议至少包含会话 ID、任务 ID、每一步的角色、内容、时间戳、token 消耗、工具名和参数快照。有了协议无论是做离线指标计算、失败模式聚类还是后续接入自动分析模块都省力得多。实操中最容易踩的坑是时间戳和参数快照缺失等到要分析哪一步最耗时或者参数填错长什么样的时候想补都补不回来。5. 第三层指标计算与口径设计2 篇论文的重点5.1 结果指标成功率之外还有四类大多数团队评测 Agent 只看一个指标任务成功率。这两篇论文都明确指出这在技能评测里是极其单薄的。我见过两个 Agent任务成功率一模一样但一个是大部分任务慢慢磨成功另一个是快速失败但成功率高两者在实际业务里的体验天差地别。结果指标至少应该包含四类任务成功率、完成质量、完成时间、资源成本。完成质量解决的不只是快慢问题比如生成一份报表结果文件里数据算错了但格式齐全算成功吗完成时间衡量效率。资源成本关乎 token 消耗和 API 调用次数Agent 在真实生产里是要算钱的。还有一类安全性指标比如是否访问了越权资源、是否侧漏了敏感信息在涉及真实业务的评测中必须纳入。只拿成功率一个指标做决策等于拿单科成绩给综合素质下结论。5.2 过程指标能看到失败发生的位置结果指标说明成没成过程指标说明怎么走的。论文里强调最多的过程指标有三个步骤完整率、工具调用正确率、错误恢复率。步骤完整率衡量 Agent 有没有漏掉关键步骤工具调用正确率可以再细化为工具选对率、参数填对率错误恢复率则衡量 Agent 在遇到异常反馈时能否自动修正而不是直接放弃或死循环。我在实践中体会到这三个过程指标的诊断价值远超结果指标。一个多步骤任务Agent 前两步全对、第三步工具参数填错、后面整体崩盘结果指标只能告诉你失败了过程指标能精确告诉你挂在参数填充上这是两个完全不同的信息层级。有了过程指标评测结果才真正具备可操作性。5.3 定义对指标口径一致性指标口径是最乏味但最致命的环节。什么算任务成功是最终输出和参考答案字符串完全一致还是由 LLM 裁判判定语义一致判定标准是结果正确即可还是路径也要正确不同定义下同一个评测集能得出完全相反的结论。有一篇论文专门研究 LLM 裁判的口径漂移问题同一个裁判模型在不同提示词、不同温度、不同时间点下对同一批答案的打分稳定性并不高。应对方法包括多次采样取多数票、给裁判明确的评分 rubrics、定期校准裁判的输出分布。这些操作不性感但评测系统一旦上线口径漂移就是持续存在且必须管理的风险。我自己的经验是把评分 rubrics 写成可运行的正则式规则和关键字约束先把客观部分卡死再让 LLM 裁判只处理语义层面的主观判断漂移会小很多。6. 第四层结果分析与迭代闭环2 篇论文的重点6.1 失败归因把错误样本聚类成能力短板评测的终点不是出分而是回答接下来改什么。这两篇论文的核心方法是一致的先对失败样本做错误类型标注再做聚类最后映射回能力维度。错误类型至少可以分为工具选择错误、参数生成错误、规划顺序错误、信息检索不全、错误恢复失败、指令理解偏差。标注完几百个失败样本后你会看到明显的长尾集中可能 60% 的失败集中在参数生成错误上。这个结论会直接改变团队的迭代优先级——参数填错是提示词问题、是模型能力问题、还是工具本身的参数定义不清楚每一步都对应不同的解法。我记得一个很典型的案例某团队在评测某 Agent 的一个内部工具调用时发现参数错误率高达 40%所有人都以为是模型能力不行结果把参数 schema 拿出来一看有两个参数名极度相似且含义有重叠模型怎么调都容易混淆。改了 schema 之后参数错误率直接降了一半。没有失败模式聚类这类问题靠猜不知道要猜多久。6.2 能力画像从单点分数到结构化结果结果分析层的另一个关键产物是能力画像。论文里的做法是不把技能评测结果压缩成一个总分而是按照技能维度输出结构化画像规划能力、工具调用能力、错误恢复能力、多轮保持能力、指令遵循能力每个维度配一个得分和一个置信区间。能力画像的工程价值在于它能指导回归测试的重点。如果某个版本的目标是提升规划能力评测回归就应该增加规划类任务的权重同时要防止工具调用类、恢复类得分明显下滑。这个能力维度—任务样本—评测指标三层映射关系是评测系统能够精准服务模型迭代的关键。我强烈建议团队在搭建评测系统的第一天就同步维护这份映射关系表后面所有分析工作都会建在这张表上。6.3 回归机制评测要跟着模型一起迭代还有一篇论文的内容偏工程实践把评测系统接到开发流程里做成持续的回归机制。做法是每次模型发版前自动跑一遍精选评测集输出各能力维度的偏移报告如果某个维度得分下降超过阈值就阻断发布。这里面最讲究的是精选评测集的维护。全部任务都跑成本太高只跑固定的抽样子集又会漏掉回归问题。论文推荐的做法是把评测任务按能力维度分层抽样每个维度保留一定基数的必测任务再加上随机采样的覆盖任务既控制成本又保证覆盖面。我在工程落地时也采用了类似策略实测下来发布前回归从全量跑 6 小时压缩到 40 分钟漏召回率完全在可接受范围内。7. 实操中的典型问题与避坑实录7.1 难度标定翻车现场我见过最典型的翻车是评测集刚搭好用一个强模型试跑全对拿一个弱模型试跑全错拿目标模型试跑得分在 70% 上下波动。你以为这是理想的有区分度其实可能是任务难度分布过于两极分化中间梯度缺失。解法是引入多基线校准至少用强、中、弱三个参考模型跑通全量任务用它们的得分分布把任务分成若干个难度桶再检查每个桶里是否有足够样本。没有合理难度梯度的情况下任何两个模型之间的差异分析都会被噪音淹没。7.2 环境漂移导致结果不可复现这是持续运维中最磨人的问题。仿真环境依赖的外部模拟服务一旦有人改了返回格式或者加了随机延迟评测结果就可能产生系统性偏移。我踩过的坑是一次评测回归中某个能力维度得分集体下降排查了两天才发现是模拟支付接口的返回码从 3 位变成了 4 位模型的解析逻辑没跟上。规避方法是给仿真环境做版本管理每一个评测任务固定绑定一个环境版本环境变更必须走评审流程并同步重跑基线。听起来很重但评测系统的信任一旦崩了所有人都会不再看评测结果那才是真正的大浪费。7.3 部分完成的任务怎么打分Agent 任务经常是完成了 80%但最后一步交互失败。给满分显然不合理给零分则丢失了中间有效信息。我见过比较务实的做法是引入分级打分任务完成度在 A 级要求全部步骤正确且结果质量达标B 级允许次要步骤缺失或结果有小瑕疵C 级则是主要目标未实现。分级打分配合过程指标能让评测结论更接近真实业务价值。特别注意分级标准要写死在评测配置里不能让裁判每次临时定义否则口径漂移会重新找上门。提示技能评测最怕的不是分数不够好看而是分数不可解释。所有避坑手段本质上都是在保住分数的可解释性。8. 把这套分层思路落地的一些体会读这 9 篇论文加上自己在实际项目中反复踩坑我最大的体会是技能评测不是一个做完就交付的东西而是一个需要持续经营的基础设施。一开始可以从最小的闭环搭起——先定能力维度清单再攒 100 个覆盖这些维度的任务配上最基础的仿真环境用一两个结果指标跑通然后逐步补上环境版本管理、轨迹标准化、失败归因和回归机制。每一步都在给后面省时间。还有一个很实际的建议评测系统一定不要让算法同学在项目尾声顺手做它值得一个至少持续投入的人长期维护。我在实际使用中发现评测结果的价值和评测系统的维护频率直接挂钩三个月不维护环境漂移、任务泄漏、口径漂移会把这套系统变成摆设。分层本身不解决所有问题但它让所有问题都可以被单独定位和修复这已经是评测工程里最重要的一步了。
给 Agent 技能打分乍看是个标准的测评话题但我系统性啃完 9 篇和技能评测相关的前沿论文后最大的感触是这件事根本不是出题、考试、给分的线性流程而是一道必须分层拆解的工程题。技能评测要同时处理任务设计、环境搭建、交互数据采集、指标口径和失败归因任何一层没做扎实最后那个分数都会失真。这里我按工程分层把那 9 篇论文重新组织了一遍把每一层在解决什么、有哪些坑、论文里是怎么处理的都串起来讲。适合正在给 Agent 做应用的研发团队、想搭建内部评测平台的同学也包括所有不想被 Benchmark 表面分数带偏的人。1. 为什么给 Agent 技能打分突然成了硬需求1.1 从模型考试到技能评测变的不只是题目形态传统大模型评测的核心是一问一答出题、让模型答、拿参考答案比对。这个范式在文本能力评测上很成熟但用到 Agent 身上立刻露馅。Agent 的典型任务是一个多轮交互过程用户丢一句帮我把这周三个数据源合并成一张报表Agent 要先判断需要哪些工具逐个调用处理中间报错最后产出结果文件。整个过程可能是十几轮对话、几十次工具调用任何一个环节卡住任务都可能功亏一篑。我现在看到越来越多的团队在自建评测集但大多数做法是拿一个 Benchmark 跑一下出一个总分然后就没有然后了。总分高到底高在规划能力还是工具调用熟练度总分低是任务太难还是环境有问题单看一个数什么都回答不了。这就是为什么技能评测这四个字必须从考试题的思维切换成工程系统的思维。1.2 九篇论文的共同主线评测是流水线不是考试我读的这 9 篇论文来源比较杂有学术实验室的工作也有产业研究团队的产出但它们有一条高度一致的主线都把评测当成一条流水线而不是一次考试。流程大致是先构造任务集合和仿真环境再让 Agent 和环境交互并完整记录轨迹然后把轨迹喂给指标层计算得分最后把分数和错误样本一起送进分析模块做归因。有意思的是这 9 篇论文没有一篇是从头到尾覆盖整条流水线的而是各管一段。有的专注任务难度标定有的专注环境仿真度有的专门打磨指标口径有的死磕失败归因。这本身就说明问题技能评测已经大到单篇论文装不下必须分层协作。这个观察直接印证了我后来的判断——用分层工程的方式来组织评测工作是成本最低、最容易迭代的结构。2. 整体拆解把技能评测分成四层工程2.1 四层结构长什么样我把这 9 篇论文按职责归成了四层分别是任务构建层、交互观测层、指标计算层、结果分析层每层回答一个核心问题。层级核心问题对应论文数代表性工作方向任务构建层测什么题目和场景是否合理3任务难度标定、环境仿真度、数据污染检测交互观测层怎么记录 Agent 的一举一动2轨迹格式标准化、观测粒度设计指标计算层怎么给过程与结果打分2过程指标与结果指标、裁判口径一致性结果分析层分数背后的原因是什么2失败归因、能力画像、回归机制这个分层不是拍脑袋分的。我读论文时发现不少评测系统的失败案例都出在相邻层的边界上。比如任务层的题目设计得很好但观测层没记录关键中间状态导致指标层无法判断 Agent 是否走了合理路径又比如指标层定义得很严格但结果分析层没把错误样本按模式聚类迭代时只能瞎猜。四层划分本质上是在给评测系统画清晰的职责边界让每一层可以独立替换、独立优化而不是牵一发而动全身。2.2 分层带来的工程收益分层最直接的好处是可维护性。评测系统不是搭完就完事的Agent 在迭代、环境在升级、任务集合在扩展如果所有逻辑揉在一起改一处崩一片。分层之后换一个任务生成器不影响指标计算升级指标口径不需要重跑整个环境观测协议调整也不会牵动结果分析的代码。第二个收益是可解释性。当两个 Agent 版本对比时如果总分下降我可以逐层定位是任务分布变了、还是观测有缺失、还是 Agent 本身在某个技能维度退化了。我在实际项目中见过一个相关案例某团队某次发版后所有任务成功率掉了十几个点排查了半天最后发现不是模型退化而是仿真环境里一个第三方接口的返回格式变了。如果评测系统没有分层这种事故几乎不可能快速定位。能三分钟定位到环境层问题和折腾三天只能通过回滚代码来试错差别就是分层带来的。3. 第一层任务构建与环境搭建3 篇论文的重点3.1 任务设计的三个原则覆盖度、难度梯度、语义真实性任务构建层是整个评测系统的地基。3 篇论文切入点不同但总结下来都在强调三个原则。第一是覆盖度。Agent 的技能不是单一的至少要覆盖规划、工具选择、参数填充、错误恢复、多步推理这几类。很多评测集在覆盖度上很偏科工具调用占了八成题目规划类任务稀疏结果模型只把工具调用练好了放到真实场景还是经常卡在中间步骤。论文里的做法是把技能清单前置定义好要测的技能再把任务分配到技能网格上保证每个格子都有样本。第二是难度梯度。如果一个评测集里 90% 的任务所有模型都能做对这个评测集对你已经没有区分度了反过来如果 90% 的任务所有模型都做不对评测就成了纯粹的挫败体验也拿不到有效信息。难度梯度要像考试卷一样有基础题、有进阶题、有压轴题这样才能把不同水平的 Agent 拉开让每次迭代的进步或退步都看得见。第三是语义真实性。任务描述必须贴近真实用户的话术。我见过不少评测任务为了让标准答案更容易匹配把用户指令写成了结构化文档格式——这测的根本不是 Agent 的理解能力而是模型对文档模板的检索能力。有篇论文专门做了统计把任务指令从口语化表达改成书面化结构表达后同样的 Agent 指标可以差出一大截。任务表述方式的真实度直接决定了评测结论在真实场景里的参考价值。3.2 环境仿真度做到 80% 还是 100%任务有了还得有让 Agent 跑起来的考场也就是仿真环境。这类场景通常是模拟 API 集合、模拟数据库、模拟网页。这里有个经典问题仿真到底要做到多真有篇论文的结论很有意思环境仿真度和评测有效性的关系不是线性的而是存在一个阈值。低于某个仿真度Agent 在评测里学到的东西和真实场景里需要的策略会脱节高于某个仿真度边际收益急剧下降但搭建和维护成本持续上升。原因也简单真实系统里有大量噪音、延迟、随机报错、边界数据仿真度不够时Agent 在评测里表现完美一上真实环境就原形毕露但仿真度够了之后多模拟一个奇葩报错场景对评测结论的影响其实很小。我个人的建议是把仿真度重点投向三个方面接口返回格式的真实性、错误分支的覆盖率、状态的一致性和可恢复性。接口格式不真实Agent 学的就是一套假的解析逻辑错误分支太少Agent 的兜底能力完全测不出来状态不一致评测结果根本不可复现。至于 UI 像素级还原、网络延迟的精确模拟属于边际收益比较低的投入可以往后放。3.3 数据污染任务层的第一道防线任务构建层还有一个容易被忽视的环节数据污染检测。很多评测任务是拿大模型辅助生成的生成过程本身就可能把已有模型的答题模式带进去如果生成时用了包含答案的上下文评测就失效了。更隐蔽的一种污染是评测任务和训练语料有高度相似的内容模型不是会做而是背过。论文里比较通用的做法是查重加扰动。首先做 n-gram 级别的相似度筛查把和训练语料大面积重合的题目剔除其次对保留的任务做语义扰动比如改写人名、数字、时间线确保任务虽然结构相同但模型不能靠记忆作答。实操里我经常用一个土办法拿一个能力明显不够格的小模型跑一遍整套评测如果它在某类任务上得分异常高就要警惕那类题目是不是存在泄漏。这个方法不是论文教的但实测下来特别能暴露问题。4. 第二层交互观测与数据采集2 篇论文的重点4.1 观测粒度决定你能做什么分析第二层负责记录 Agent 和环境的每一次交互。听起来无非是打日志但论文里反复提醒一个词观测粒度。粒度太粗只有最终结果和对话文本那你能做的分析就非常有限。你没法知道 Agent 是在哪一步开始跑偏的也没法判断工具参数填错和工具选错到底谁更频繁而这些恰恰是迭代模型最重要的输入。粒度太细每一步都记录全部系统状态存储和加工成本爆炸而且大量中间状态根本用不上。合适的粒度我自己的经验是至少记录四类内容用户输入、Agent 的决策输出包括思考过程、工具调用、参数、环境返回的结果、时间戳和成本信息。有篇论文专门对比过加了思考过程的观测之后失败归因的准确率明显提升因为很多错误发生在Agent 想错了而不是执行错了看不到思考过程分析时就只能靠猜。观测层漏掉的信息后面任何一层都没法补救这是把观测设计放在前面位置的根本原因。4.2 轨迹格式与对齐问题两篇论文里都提到了轨迹数据标准化的问题。Agent 评测里一次任务会产生一条轨迹由多轮观测—决策—执行—反馈组成。如果不定义统一格式指标计算层每次都要重新适配而且不同来源的实验结果没法直接对比。我建议团队内部尽早定一个简单的轨迹协议至少包含会话 ID、任务 ID、每一步的角色、内容、时间戳、token 消耗、工具名和参数快照。有了协议无论是做离线指标计算、失败模式聚类还是后续接入自动分析模块都省力得多。实操中最容易踩的坑是时间戳和参数快照缺失等到要分析哪一步最耗时或者参数填错长什么样的时候想补都补不回来。5. 第三层指标计算与口径设计2 篇论文的重点5.1 结果指标成功率之外还有四类大多数团队评测 Agent 只看一个指标任务成功率。这两篇论文都明确指出这在技能评测里是极其单薄的。我见过两个 Agent任务成功率一模一样但一个是大部分任务慢慢磨成功另一个是快速失败但成功率高两者在实际业务里的体验天差地别。结果指标至少应该包含四类任务成功率、完成质量、完成时间、资源成本。完成质量解决的不只是快慢问题比如生成一份报表结果文件里数据算错了但格式齐全算成功吗完成时间衡量效率。资源成本关乎 token 消耗和 API 调用次数Agent 在真实生产里是要算钱的。还有一类安全性指标比如是否访问了越权资源、是否侧漏了敏感信息在涉及真实业务的评测中必须纳入。只拿成功率一个指标做决策等于拿单科成绩给综合素质下结论。5.2 过程指标能看到失败发生的位置结果指标说明成没成过程指标说明怎么走的。论文里强调最多的过程指标有三个步骤完整率、工具调用正确率、错误恢复率。步骤完整率衡量 Agent 有没有漏掉关键步骤工具调用正确率可以再细化为工具选对率、参数填对率错误恢复率则衡量 Agent 在遇到异常反馈时能否自动修正而不是直接放弃或死循环。我在实践中体会到这三个过程指标的诊断价值远超结果指标。一个多步骤任务Agent 前两步全对、第三步工具参数填错、后面整体崩盘结果指标只能告诉你失败了过程指标能精确告诉你挂在参数填充上这是两个完全不同的信息层级。有了过程指标评测结果才真正具备可操作性。5.3 定义对指标口径一致性指标口径是最乏味但最致命的环节。什么算任务成功是最终输出和参考答案字符串完全一致还是由 LLM 裁判判定语义一致判定标准是结果正确即可还是路径也要正确不同定义下同一个评测集能得出完全相反的结论。有一篇论文专门研究 LLM 裁判的口径漂移问题同一个裁判模型在不同提示词、不同温度、不同时间点下对同一批答案的打分稳定性并不高。应对方法包括多次采样取多数票、给裁判明确的评分 rubrics、定期校准裁判的输出分布。这些操作不性感但评测系统一旦上线口径漂移就是持续存在且必须管理的风险。我自己的经验是把评分 rubrics 写成可运行的正则式规则和关键字约束先把客观部分卡死再让 LLM 裁判只处理语义层面的主观判断漂移会小很多。6. 第四层结果分析与迭代闭环2 篇论文的重点6.1 失败归因把错误样本聚类成能力短板评测的终点不是出分而是回答接下来改什么。这两篇论文的核心方法是一致的先对失败样本做错误类型标注再做聚类最后映射回能力维度。错误类型至少可以分为工具选择错误、参数生成错误、规划顺序错误、信息检索不全、错误恢复失败、指令理解偏差。标注完几百个失败样本后你会看到明显的长尾集中可能 60% 的失败集中在参数生成错误上。这个结论会直接改变团队的迭代优先级——参数填错是提示词问题、是模型能力问题、还是工具本身的参数定义不清楚每一步都对应不同的解法。我记得一个很典型的案例某团队在评测某 Agent 的一个内部工具调用时发现参数错误率高达 40%所有人都以为是模型能力不行结果把参数 schema 拿出来一看有两个参数名极度相似且含义有重叠模型怎么调都容易混淆。改了 schema 之后参数错误率直接降了一半。没有失败模式聚类这类问题靠猜不知道要猜多久。6.2 能力画像从单点分数到结构化结果结果分析层的另一个关键产物是能力画像。论文里的做法是不把技能评测结果压缩成一个总分而是按照技能维度输出结构化画像规划能力、工具调用能力、错误恢复能力、多轮保持能力、指令遵循能力每个维度配一个得分和一个置信区间。能力画像的工程价值在于它能指导回归测试的重点。如果某个版本的目标是提升规划能力评测回归就应该增加规划类任务的权重同时要防止工具调用类、恢复类得分明显下滑。这个能力维度—任务样本—评测指标三层映射关系是评测系统能够精准服务模型迭代的关键。我强烈建议团队在搭建评测系统的第一天就同步维护这份映射关系表后面所有分析工作都会建在这张表上。6.3 回归机制评测要跟着模型一起迭代还有一篇论文的内容偏工程实践把评测系统接到开发流程里做成持续的回归机制。做法是每次模型发版前自动跑一遍精选评测集输出各能力维度的偏移报告如果某个维度得分下降超过阈值就阻断发布。这里面最讲究的是精选评测集的维护。全部任务都跑成本太高只跑固定的抽样子集又会漏掉回归问题。论文推荐的做法是把评测任务按能力维度分层抽样每个维度保留一定基数的必测任务再加上随机采样的覆盖任务既控制成本又保证覆盖面。我在工程落地时也采用了类似策略实测下来发布前回归从全量跑 6 小时压缩到 40 分钟漏召回率完全在可接受范围内。7. 实操中的典型问题与避坑实录7.1 难度标定翻车现场我见过最典型的翻车是评测集刚搭好用一个强模型试跑全对拿一个弱模型试跑全错拿目标模型试跑得分在 70% 上下波动。你以为这是理想的有区分度其实可能是任务难度分布过于两极分化中间梯度缺失。解法是引入多基线校准至少用强、中、弱三个参考模型跑通全量任务用它们的得分分布把任务分成若干个难度桶再检查每个桶里是否有足够样本。没有合理难度梯度的情况下任何两个模型之间的差异分析都会被噪音淹没。7.2 环境漂移导致结果不可复现这是持续运维中最磨人的问题。仿真环境依赖的外部模拟服务一旦有人改了返回格式或者加了随机延迟评测结果就可能产生系统性偏移。我踩过的坑是一次评测回归中某个能力维度得分集体下降排查了两天才发现是模拟支付接口的返回码从 3 位变成了 4 位模型的解析逻辑没跟上。规避方法是给仿真环境做版本管理每一个评测任务固定绑定一个环境版本环境变更必须走评审流程并同步重跑基线。听起来很重但评测系统的信任一旦崩了所有人都会不再看评测结果那才是真正的大浪费。7.3 部分完成的任务怎么打分Agent 任务经常是完成了 80%但最后一步交互失败。给满分显然不合理给零分则丢失了中间有效信息。我见过比较务实的做法是引入分级打分任务完成度在 A 级要求全部步骤正确且结果质量达标B 级允许次要步骤缺失或结果有小瑕疵C 级则是主要目标未实现。分级打分配合过程指标能让评测结论更接近真实业务价值。特别注意分级标准要写死在评测配置里不能让裁判每次临时定义否则口径漂移会重新找上门。提示技能评测最怕的不是分数不够好看而是分数不可解释。所有避坑手段本质上都是在保住分数的可解释性。8. 把这套分层思路落地的一些体会读这 9 篇论文加上自己在实际项目中反复踩坑我最大的体会是技能评测不是一个做完就交付的东西而是一个需要持续经营的基础设施。一开始可以从最小的闭环搭起——先定能力维度清单再攒 100 个覆盖这些维度的任务配上最基础的仿真环境用一两个结果指标跑通然后逐步补上环境版本管理、轨迹标准化、失败归因和回归机制。每一步都在给后面省时间。还有一个很实际的建议评测系统一定不要让算法同学在项目尾声顺手做它值得一个至少持续投入的人长期维护。我在实际使用中发现评测结果的价值和评测系统的维护频率直接挂钩三个月不维护环境漂移、任务泄漏、口径漂移会把这套系统变成摆设。分层本身不解决所有问题但它让所有问题都可以被单独定位和修复这已经是评测工程里最重要的一步了。
