近半年我一直在折腾 Agent 的技能评测翻了不少资料也拿自己的几个项目试过水。这活儿比想象中难得多——不能像传统模型那样丢一组选择题跑个准确率Agent 的输出是开放式、多步骤、还要和环境实时交互的每一步可能对也可能错错了还可能自己纠正回来。所以当看到一篇把「Agent 技能评测」拆成分层工程问题的综述时我挺有共鸣评测不是跑分评测是一套从能力定义到数据构建、再到评分设计的系统工程。这篇文章想和你聊聊我读完 9 篇相关论文后的核心收获以及我实际操作中踩过的坑。我尽量不堆术语把「为什么技能评测要先分层」「每层到底测什么」「评分怎么设计才不冤枉 Agent」这几件事拆开讲清楚。不管你是正在做 Agent 应用开发、还是想给自己的智能体搭一套评测基准这篇文章应该都能给你一些能直接上手的参考。1. 为什么技能评测要先分层先回答「测什么」再谈「怎么打分」先说我踩过的最大一个坑。早先我给一个客服 Agent 搭评测直接把所有任务混在一起意图识别、多轮对话、工具调用、最终答案对不对全算成一个总分。结果发现一个严重问题某个 Agent 版本在总分上提高了 5%但细看全是意图识别变好拉上来的它调用查询工具时参数传错的老毛病根本没修只是被其他项的提升掩盖了。这就是不分层的代价——你根本不知道分数变化背后是哪项能力在变。所以现在圈内越来越多的人主张Agent 评测要先按技能层级拆解再逐层打分。1.1 Agent 技能评测的三个层级综合多篇论文的思路目前比较共识的做法是把 Agent 技能拆成三层第一层单步能力层。这是最基础的原子能力包括指令理解、意图分类、上下文中的实体抽取、单次工具调用的参数正确性等。特点是输入输出边界清晰可以像传统模型评测那样做自动判分。比如给定一句「帮我查一下上周三的销售报表」Agent 是否准确识别出「查询」意图、是否提取出「上周三」这个时间实体、生成工具调用时时间参数格式是否正确。第二层任务执行层。多个单步能力串起来的完整任务比如「调研某行业过去一年的融资情况整理成报告」。它考察的是规划能力——能不能把大任务拆成子步骤、按正确顺序执行中途遇到工具报错能不能换一条路最终能不能收敛到答案。这一层的评测最难自动化因为「过程对不对」和「结果对不对」需要分开看。第三层系统行为层。再往上是 Agent 作为系统长期运行时的表现多轮对话中的记忆利用是否准确、长时间任务中的状态一致性、遇到歧义时是否敢于追问澄清、从错误中反思和自我纠正的能力以及多个 Agent 协作时任务分配的效率。这一层更多是行为学和工程学的交叉评测周期长、环境依赖重。1.2 「分层」能解决什么问题分层至少带来三个直接收益。第一回归分析变得可解释。你改了一个 Prompt 或换了一个底层模型分数变化能精确落到某一层、某一类技能上而不是笼统一句「效果变好了/变差了」。第二诊断效率翻倍。当 Agent 在线上表现不佳时你可以先在单步能力层跑一遍——如果基础能力都没问题问题大概率出在执行策略或系统设计上如果单步能力本身就差那换模型比调 Prompt 更实际。第三数据构建更高效。每一层需要的数据特征差异很大单步能力层需要大量覆盖边界的短样本任务执行层需要带轨迹标注的长样本系统行为层需要接近真实环境的多轮会话数据。分层建数据每一类的采集标准都能定得更清楚。我现在的评测体系就是一个三层金字塔最底层每两周全量跑一次自动化单测中间层每天跑一组代表性长任务最顶层每月做一次模拟真实用户的多轮会话采样评测三层分数分开汇报不再合并成一个总分。2. 9 篇论文的分层拆解每个层级对应哪些评测方法接下来是我从 9 篇论文里提炼的方法论我按前面说的三层框架重新组织了它们。这 9 篇论文分别对应单步能力、任务执行和系统行为三个层级每层的评测对象、数据形式、评分策略都有非常不一样的设计。2.1 单步能力层用大规模原子任务测试打底这一层对应的是 3 篇论文。核心思路是把 Agent 的复杂行为拆到不能再拆的原子操作然后用大规模、可自动判分的数据去做回归测试。第一篇论文的核心贡献是构建了一套「指令理解与实体抽取」基准测试集。它的样本不是人工从头写的而是用半自动方式从真实对话日志里扒出来经过清洗和难度标注后整理成的。每条样本只测一件事给定用户一句话Agent 是否正确理解意图并抽取关键实体。值得注意的是它设计了「对抗性样本」在一组正常查询里混入了带歧义、带否定、带省略指代的变体。比如「把这个也发了」这种缺少明确指代的指令Agent 是否知道自己信息不足、是否会在必要时追问。这一设计让基准测试不只是考「做对了多少」还能考「知不知道自己做不了什么」。第二篇论文聚焦「单次工具调用的参数正确性」。它的想法非常工程化与其笼统看 Agent 会不会用工具不如逐个工具、逐个参数地测。数据集里把一个工具的函数签名、参数类型、枚举取值范围全部结构化然后自动生成海量调用请求检查 Agent 每次调用时参数类型对不对、必填参数有没有漏、枚举值有没有越界。这套方法做回归测试极其好用——每次改完模型跑一遍全量工具调用测试哪些工具的参数准确率掉了一眼就能定位。第三篇论文是这一层里我读得最仔细的因为它讨论了「上下文记忆检索」的评测。它不测 Agent 能不能记住多轮对话里说过什么而是测「该用哪一段记忆」。同样一句「上个月那个方案」在对话早期、中期、后期分别指代不同内容Agent 能否基于当前上下文选择正确的记忆片段。这个任务的评测数据构建很难因为需要人工标注每个代词、每个省略表达对应的正确记忆项。论文的做法是把标注成本拆成两步先让大模型初标再由人工抽检修正成本大概比纯人工标注低了一半左右。2.2 任务执行层轨迹质量比结果对错更值得关注这一层的 3 篇论文共同关心的问题是一个需要多步推理和多次工具调用的任务Agent 的解题过程到底好不好。第一篇论文提出了一个「规划质量」评估框架亮点是设计了四维度的规划评分量规完整性是否覆盖任务所有要求、顺序合理性子步骤是否按照依赖关系排序、可执行性每一步是否对应可用的工具或资源、效率是否存在明显多余的步骤。这篇论文最实际的贡献是把规划质量的评分从「二元对错」变成了「量规打分」因为现实里 Agent 的规划很少全对或全错多数是部分合理。第二篇论文处理的是长任务可靠性问题。它把超过 20 步的长任务单独拎出来测发现一个现象Agent 在 5 步之内的任务上表现很好但超过 20 步后成功率会断崖式下降。论文把这归因于错误累积每一步都有一个小概率出错正确率乘起来就指数级衰减。针对这个现象论文提出了「阶段性检查点」评测方法——不只在任务结束打一个分而是在每 5 步设置一个检查点看 Agent 有没有跑偏、有没有在检查点主动核对中间结果这个设计对我自己搭长任务评测的启发很大。第三篇论文关注「从错误中恢复」的能力。它构建了专门的评测集每个任务都在中途埋入一个环境报错比如工具返回异常、文件路径不存在、权限不足看 Agent 能否识别异常并修正。评分维度是两个能否正确诊断错误原因以及能否在不放弃任务的前提下调整策略。这篇论文最值得学习的是它的「错误注入」方法——它不是靠随机改参数制造错误而是根据真实使用场景梳理出高频错误类型参数错误、权限错误、依赖缺失、数据格式不符做成一个可插拔的错误注入组件能灵活控制评测难度。2.3 系统行为层从孤立任务评估走向行为模式评估最后 3 篇论文把视角拉到了更宏观的层面Agent 不再是一个「回答问题的程序」而是一个长期运行、可能和其他 Agent 协同的系统。第一篇论文研究「多 Agent 协作」的评测。它设计了一套协作任务集多个 Agent 需要在信息不对称的情况下交换信息、分配任务、汇总结果。这篇论文给出的评测维度很细——除了任务成功率还统计了通信轮次效率、任务分配均衡度、冲突消解成功率。这几个指标比单纯看结果更能反映协作质量因为有的 Agent 虽然最终把任务做完了但过程中反复和队友确认同样信息通信效率极低这种「协作内耗」在原来的评测体系里完全看不出来。第二篇论文做的是「自动化裁判」方法研究即用一个大模型当考官去评价另一个 Agent 的表现。论文系统性测试了不同打分提示词对评测结果的影响发现几个关键结论让裁判模型先写评语再打分比直接打分更稳定要求裁判给出「打分依据」能显著减少分数漂移用多维度拆分打分正确性、完整性、可读性、鲁棒性比单一总分更接近人工判断。论文还提出了「裁判校准」流程先用一批人工评过分的数据校准裁判模型的评分尺度和措辞偏好让自动评分和人工评分的偏差尽可能小。第三篇论文讨论了评测偏差问题是这 9 篇里最「劝退」但也最涨见识的一篇。它指出评测集本身可能存在系统性偏差——比如某个数据集的题目全部来自技术问答社区那么在这个数据集上表现好的 Agent 未必在处理日常对话时同样出色。论文提出了一套「偏差审计」方法计算评测样本在不同维度上的分布话题领域、句式复杂度、目标实体类型等再把 Agent 的各子项得分和这些分布做交叉分析。如果发现「当句式复杂时所有 Agent 的得分都显著下降」这就是数据集的偏倚信号说明评测集在复杂度维度上的覆盖不均衡。3. 落地一套 Agent 技能评测方案从基准搭建到打分配置读完论文之后我照着「分层评测」的思路给自己的两个 Agent 项目搭了一套评测方案。这里分享下实际操作过程踩过不少坑也总结出了一些能直接复用的具体做法。3.1 构建评测数据难度分级与控制变量我的第一步是给每个技能层级分别建设评测数据。单步能力层我用的是「模板泛化 人工抽检」的方式先写 50 条种子样本再通过替换实体、变换句式、增加干扰项等方式泛化出 2000 条左右最后人工抽检约 200 条确认质量。这样做的成本比纯人工写低得多同时通过刚才说的「句式复杂度」「实体类型分布」检查避免了生成的样本扎堆在某一类模式里。任务执行层我选了 30 个有代表性的长任务作为「黄金测试集」每个任务都要求至少 8 步工具调用并且覆盖至少 2 种可能出错的环境异常。系统行为层因为是长期行为考察我采用的是「每周滚动采样」——每周从真实交互日志里随机抽取 50 轮多轮会话作为评测样本并标注每轮的关键行为指标。难度分级是我特别想强调的一点。如果你把评测数据按难度分成 P0常规任务、P1带干扰项任务、P2极端输入或资源受限任务三档那么评测结果就不只是一个总分还能看出「Agent 的能力边界在哪一档」。比如我有一个 Agent 在 P0 档做到 92% 正确率但 P2 档直接掉到 47%这说明它只是「常规环境下的好学生」抗压能力还差得远。这个信息比你算一个综合平均分有价值得多。3.2 评分量规设计从「对错二分」到「多维加权」这是我最想让你避坑的地方。早期我做评测时用的评分方式是「Agent 的最终答案和标准答案对不对」但很快发现两个问题一是开放式任务根本没有唯一标准答案比如让 Agent 写一份竞品分析报告「写得好不好」远不是对错能衡量的二是过程错误和结果错误常常混在一起——Agent 可能最终答案是对的但中间用了一个不合适的工具也可能中途就完全执行错了。所以我参照论文里的量规思想设计了一套三级评分体系。每一级都设了 2 到 4 个考察维度也就是评分量规每个维度按 0 到 3 分打分最后加权汇总。我用一个实际长任务评测案例来说明任务是「调研某公司近一年的产品发布动态并整理成一份简报」。拆解成的评分维度如下——维度一考察信息完整性即报告是否覆盖了全年主要发布事件维度二考察信息准确性即关键数据、时间点是否与查询结果一致维度三考察结构合理性即简报是否有清晰的逻辑层次、核心结论是否突出维度四考察过程效率即是否能用尽可能少的工具调用完成检索。这个方案当然有个缺点维度一和维度二还可以设计自动化判分规则但维度三目前我只能用「裁判模型 人工抽检」的方式评。不过说实话这类开放任务的维度即便有自动化方案我仍坚持人工抽检每条结果原因放在后面「常见问题排查」一节具体说。3.3 自动化评测的工程配置如果只靠每一条都人工打分评测根本跑不完。所以我把自动化部分搭成了三个模块。第一个模块是「规则判分器」适用于单步能力层的大多数情况。比如工具调用的参数类型对不对、必填项有没有漏、意图分类标签是否正确这些都可以用确定性脚本判分。好处是零成本、完全可复现一个晚上能跑几千条测试。第二个模块是「工具结果校验」适用于任务执行层的部分自动判分。如果 Agent 的任务是调用一个查询工具并整理结果我可以写一个脚本去核对答案里的关键数字是否和工具返回的结果一致。第三个模块是「裁判模型打分」主要承接前面说的开放维度比如结构合理性、逻辑清晰度。而裁判模型本身也得先校准我拿 100 条人工评过分的数据做了一次「先评后分 依据引用」的校准实验校准后裁判模型评分和人工评分的相关系数从 0.62 提高到了 0.78虽然还谈不上完美一致但已经可以作为初筛信号使用了。4. 实测三个月后这几类评测问题你八成也会遇到从把这套评测体系真正跑起来到现在已经三个月了中间确实遇到了不少问题。挑几个含金量比较高的按「问题 - 排查思路 - 解决方案」的方式整理出来供你参考。常见问题现象排查思路最终解法环境随机性导致分数波动同一版本 Agent 同一批测试数据两次跑分相差 8%检查采样温度、非确定性排序、外部 API 超时重试是否引入变量固定随机种子失败重试策略改为确定性等待评测环境容器化裁判模型打分偏移自动评分长期显著高于人工评分或对某类答案明显偏好细分各评分维度对比人工与自动分的分布定位具体偏差维度优化提示词要求引用评判依据并定期用校验集校准裁判模型数据污染与过拟合Agent 在评测集上接近满分但线上真实场景表现一般对比评测集与真实日志的句子分布、实体分布每月从真实日志滚动采样新评测样本淘汰被团队反复调优过的旧样本指标与线上表现脱节评测总分稳定提升但用户反馈和线上核心指标没有同步变好检查评测样本与线上任务类型重合度评测指标是否过度聚焦于易优化项引入任务级行为指标追问率、工具重试率、会话轮次和用户满意度做相关性分析4.1 评测结果波动先怀疑环境再怀疑模型我刚开始跑回归测试时连续两次跑同一批数据分数差得离谱。第一反应是模型效果变差了但仔细排查后发现问题出在环境上——Prompt 里带了当前时间戳时间不同生成结果就不同工具调用的 API 偶发超时重试重试后的结果和首次结果不一样还有两个测试用例顺序不同导致上下文状态互相影响。把随机种子固定、把时间相关变量 Mock 掉、把重试策略改成确定性逻辑之后同版本同数据的分数波动降到了 1% 以内。这里特别提醒如果你用语言模型当评测依据务必固定模型版本和采样参数别让「模型当天抽风」影响你的评测结论。4.2 裁判模型会「犯错」校准比换模型更优先有一段时间我注意到裁判模型给 Agent 的评分普遍高于人工评分。起初我怀疑裁判模型版本太老想换个更强的。后来仔细对比了 50 条人工分和自动分的差异发现裁判模型对「信息完整性」维度特别宽容——Agent 只要把相关事件都列出来了即使其中有两条信息混淆了裁判模型也倾向于给满分而人工评分就会因为「有关键事实错误」扣分。这说明问题不是模型不够强而是打分标准没有被明确传达。我修改了裁判提示词要求每个维度打分前必须输出判断依据并补充一个反问指令——「如果答案中存在与工具结果不一致的信息完整性维度最高得 2 分」。这一改相关系数立刻上去了。之后我保持每月用校验集校准一次发现裁判模型的评分偏好会随模型版本升级发生漂移这个定期校准流程不能省。4.3 数据污染是躲不掉的滚动更新才是解法做评测做久了你会发现一个尴尬的情况你的 Agent 越改越好评测集越跑越「熟」最后评测分数高得没有区分度。这时候你的评测集可能已经被污染了——你反复调整 Prompt 的过程本质上就是在隐式地「记住」评测数据的长相。我一开始以为这是小概率事件直到发现某条测试样本里的实体名出现在了我某个版本的 Prompt 调试记录里。解决思路是让评测数据保持流动性。每月的评测集至少有 20% 样本来自最新真实日志同时把已经跑过 10 轮以上的老样本逐步淘汰。这样才能保证评测测的是「能力」而不是「记忆力」。4.4 别只看总分行为指标才是线上表现的前哨最后一类问题是最隐蔽的。我的一个 Agent 评测总分数在涨但用户反馈却没有变好看线上日志发现它越来越擅长「直接给出答案」但遇到信息不全时追问澄清的次数反而变少了于是经常基于不完整信息给出表面合理的错误答案。后来我构建了一套「行为指标」来辅助评测追问率信息不足时主动提问的比例、工具重试率一次调用失败后重新调整参数再调用的比例、中途修正率在任务执行过程中主动改变策略的频率。这些指标不从「最终答案对不对」里体现但恰恰是决定用户体感和任务真实成功率的关键。引入之后我重新发现了不少评测总分掩盖下的真实问题。最后把评测当产品来长期运营如果你问我这三个月最大的体会是什么那就是Agent 技能评测不是一次性搭个测试集就完事的工具而是一个需要长期运营的质量基础设施。它和你维护的 API 一样需要监控、告警、迭代需要有人为它的稳定性和准确性负责。我目前的运营节奏是每天跑一遍单步能力回归每周跑一遍代表性长任务每月做一次真实场景采样评测和裁判模型校准每季度整体审计一次评测集本身的偏倚与污染情况。这套节奏不轻松但比起「评测分数好看但线上拉胯」它至少能让我每天晚上睡得踏实一点。如果你也想给自己的 Agent 搭评测体系我的建议很直接先从单步能力层开始搭哪怕只有 500 条数据也先把自动化回归跑起来比设计一个宏大的全能力评估框架但迟迟落不了地要强得多。等你把这一层跑顺了再往任务执行层扩展——那才是 Agent 真正区别于传统模型的差异化能力所在。