做了大半年 Agent 评测最常被问的一句话是你手上这套 Agent 到底行不行我一般不会直接甩一张排行榜截图而是反问一句你跑的是什么任务环境复杂度多少单次执行的成本上限是多少。为什么这么问因为同一款模型在单轮问答里的表现和在三十步工具调用里完全可以是两个物种。这个行业正在快速从“谁的分数高”走向“谁的能力画像更匹配我的业务”而 2026 年的基准测试生态恰恰是理解这件事最好的入口。这篇东西不是科普也不是卖课。它是基于我自己搭建评测体系、跑了几千条任务之后沉淀下来的实操总结怎么理解基准测试的全景怎么从分数里读出模型的真实能力画像以及怎么搭一套能复用的轻量级评测流程。适合正在做 Agent 选型的产品负责人、写评测脚本的工程师、以及想搞清楚“模型到底能干到哪一步”的研究者。不同基础的人都能从中找到可以直接抄作业的部分。1. 为什么要给 Agent 做“体检”评测这件事的本质1.1 从模型评测到 Agent 评测到底变了什么传统的模型评测本质是“闭卷考试”。给定一道题、一个标准答案看模型能不能答对。这种评测测的是知识存储、语言流畅度和基础推理能力对象是静态的模型权重。Agent 评测完全不是一回事。Agent 是在一个目标指导下自主完成多步骤任务的系统。它的输入往往不是一个孤立问题而是一个需要拆解的目标它的输出也不只是一段文字而是一系列动作调用工具、读取返回、修正计划、再次尝试。评测 Agent 更像“实习考核”你给实习生下了一个活他在真实或者模拟的环境里折腾一圈最后交上来一个结果。过程里他可能犯错、可能绕路、可能调用错了接口也可能中途彻底卡死。这是关键的转变评测对象从“一个模型”变成了“一个系统”。系统里包含模型、工具接口、环境反馈、记忆机制甚至还有前端界面。任何一个环节出问题最终表现都会崩。我见过一个跑分非常高的大模型进了某个办公自动化环境之后连续五次把“打开表格”理解成“写一段打开表格的说明文字”任务直接失败。单看模型评测你完全看不出这个问题。1.2 评测决定的不只是排名而是预算和风险很多人觉得评测就是搞个排行榜给模型们排个序。但在我实际使用中评测结果影响的往往是更实际的事情第一任务分配。哪些任务可以交给 Agent 全自动跑哪些必须人机协同哪些现阶段根本不该尝试。没有评测数据这些决策全是拍脑袋。第二预算分配。一个 Agent 调用的模型 API 成本、工具运行成本、人工介入成本都需要基于评测结果来测算。第三风险控制。客服场景里一个话术错误可能不算大事财务场景里一次数字读错就是事故。评测本质是在给能力边界画线。所以我常说评测不能只看平均分要看分布。一个模型可能在 80% 的任务上表现完美但在剩下的 20% 里出现严重偏离甚至产生破坏性输出。平均分 90 分看起来很漂亮落地之后每天都在处理那 20% 的异常。能力画像的意义就是把这 20% 的坑提前标出来。2. 2026 年基准测试全景主流的评测维度与代表基准2.1 六个绕不开的评测维度2026 年主流 Agent 基准基本围绕六个维度展开。我梳理一下各自测什么以及为什么它重要。工具调用与 API 使用。Agent 要落地必然要调外部工具。这个维度看的是模型能不能从自然语言目标出发选对工具、填对参数、解析返回值并在失败后换一种方式重试。它是 Agent 能力的底座没有这一层上面全是空中楼阁。长程任务规划与执行。短任务看不出规划能力。真正难的是一件事需要拆成 20 步、50 步模型要维护一个计划、跟着环境反馈动态调整、中途不忘最初目标。这类评测通常看任务完成率、步数效率、重启次数。多轮交互与记忆一致性。Agent 不是一问一答的聊天框它要在一个会话里记住用户偏好、历史决策、上下文细节。评测会故意在中途插入干扰信息看模型会不会把旧结论推翻。世界知识与常识推理。这部分很微妙。Agent 任务是情境化的它需要领域常识来理解目标、判断工具返回结果是否合理。比如一个财务任务里模型如果不知道“借贷必相等”它可能根本看不出来某个工具返回的数据有问题。安全与对齐。包括命令注入、恶意工具调用、越狱攻击、隐私泄漏以及“过度顺从”——用户让模型做违规操作模型是否懂得拒绝。2026 年这个维度已经不是什么加分项而是准入门槛。多模态感知与操作。越来越多的 Agent 要“看”界面截图理解、坐标点击、OCR 读取、页面状态解析。这个维度在 GUI Agent 类基准里是核心。2.2 代表性基准逐个拆解这一年跑过的基准不算少了各有各的脾气。我挑几个有代表性的讲讲它们的数据集构造、任务形态和公认的局限性。“通用任务完成集”主测工具调用和任务完成率。它把一条任务包装成一个目标句配上若干可用工具和一份初始环境状态。判定标准是最终状态是否达到预期。优点是环境可控、测试量大适合横向对比缺点也很明显它的任务颗粒度偏小大部分在 3 到 8 步以内测不出长程规划。“多步办公环境基准”把场景换成表格、文档、邮件等虚拟办公工具任务动辄 30 步以上。它特别关注跨工具的数据流转比如从一个报表里提取数据再填入另一个文档最后生成汇总邮件。这个基准一度很受欢迎因为它非常贴近真实办公场景但环境反馈只给布尔值中间过程缺少细粒度打分模型走了一条奇怪的弯路但最终结果对了算不算合格不同实现版本给出的答案还不统一。“开放式沙箱环境”是我个人比较偏爱的一类。它给模型一个非常宽松的目标比如“把服务器上某个服务的日志里出现频率最高的三个错误提取出来并生成一份归因报告”。环境里有命令行、文件系统、代码执行器模型想怎么折腾都可以评测员只看最终产物质量和过程安全性。这类基准最接近真实部署缺点是可复现性差。模型每次跑的路径都不一样评分也很依赖人审。“GUI 操作类基准”则完全切换成像素级交互。给模型一张桌面截图它要决定点击哪里、输入什么、怎么验证操作结果。这类基准对多模态能力的要求特别高也最容易暴露模型“不会看细节”的问题。很多模型在文字任务里表现出色一到 UI 元素定位就频繁偏移尤其在复杂布局里点错位置。安全对齐类基准在 2026 年数量激增。它的任务分成两类一类是攻击面测试用户或者环境里的某个角色会尝试诱导模型执行危险操作另一类是权限边界测试模型被授予有限权限它需要判断哪些操作不越界、哪些必须拒绝。这类基准最重要的不是什么高分而是看模型的拒答率和拒答理由是否合理。2.3 基准之间的互补与冲突很多人在选基准的时候存在一个误解找一个“最权威”的基准跑一遍就完事。实际经验告诉我没有哪个基准是银弹它们之间的互补和冲突本身就有价值。举一个实际现象某开源 Agent 框架在“通用任务完成集”上的成绩排到前三换到“开放式沙箱环境”直接掉到中游。原因不是模型变笨了而是两个基准考察的规划自由度完全不同。前者任务路径相对固定模型只要按顺序调工具就行后者需要模型自己设计排查步骤、决定什么时候看日志、什么时候写脚本这完全是另一种能力。更麻烦的是基准间的冲突。某个闭源模型在办公环境基准上表现很好却在 GUI 操作基准上连续失误。一开始我以为是多模态能力弱后来发现是它对“确认按钮”这类视觉元素的定位策略过于保守宁可多问也不动手。这算好算坏如果目标是安全场景保守是优点如果目标是效率场景这就是缺陷。基准本身不告诉你答案它只负责把现象暴露出来解释和权衡是人做的。所以我在实际评测方案里从来不会只押一个基准。标准配置是两到三个互补基准交叉验证再加一组私有业务任务垫底。公开基准帮我看模型的通用能力水位私有任务帮我看业务匹配度两者缺一不可。3. 模型真实能力画像怎么从分数看到“真人”3.1 分数之外的关键指标排行榜上的分数只是一个浓缩指标它掩盖了大量细节。我在做能力画像时会同时记录下面这些指标它们比总分更接近真实。稳定性。同一个任务跑五次通过几次一个确定性很强的任务模型却有时成功有时失败这是稳定性差。我曾经遇到过某模型在一个固定任务上五次运行出现四种不同结果排除采样随机性之后发现是它对环境初始状态的微小差异过于敏感。这种模型在生产环境里特别难伺候。延迟分布。Agent 任务里单次工具调用的延迟和完整任务的总时长都很关键。某些模型平均延迟不错但 P95 延迟爆炸意思是偶尔会卡很久。在实时业务里这种长尾延迟比平均延迟更致命。成本消耗。Agent 任务的真实成本不只是单次 token 价格还有任务执行过程中的重复调用、失败重试、上下文膨胀。我见过一个模型在简单表单填写任务里反复调用搜索工具最终成本是其他模型的六倍任务完成率却差不多。如果只看打分你会低估它的真实成本。步数效率。完成任务所需的总步数以及有效步数占比。有些模型会“表演”明明可以直接完成还要先解释一番、再验证一番Step 数翻倍。这种模型在机器人流程自动化场景里会让整体吞吐大幅下降。恢复能力。任务中出错之后模型能不能自己发现错误并恢复这是 Agent 和聊天机器人最本质的区别之一。我统计过优秀模型在任务失败之后重新规划的成功率比平庸模型高出近一倍。恢复能力是很多基准完全不测、但落地时决定生死的一项。3.2 从单一分数到能力画像的绘制方法能力画像怎么做我通常分四步。第一步把评测日志结构化。每条任务至少记录目标、初始状态、模型每一步动作、工具返回值、最终输出、耗时、成本、是否人工干预。这一步是基础很多团队最后分析不了问题就是因为日志散落在各处没有统一格式。第二步按维度聚合。把动作序列里的动作分类工具调用、信息检索、计划更新、错误恢复、用户确认。按类别统计成功率、频率和效率。这个维度得分描述的是“模型在哪些类型的操作上靠谱”。第三步绘制雷达图和分层画像。雷达图的六个轴就是第二节说的六个评测维度。分层画像则是按任务复杂度分档简单任务成功率、中等任务成功率、困难任务成功率、极端任务成功率。通常能看到模型在简单任务上接近满分在困难任务上断崖下跌。第四步录制典型成功和失败轨迹。这一步容易被忽视但价值极高。带着轨迹看分数你才知道一句“任务失败”背后到底是工具选错了还是参数填错了还是模型压根误解了目标。3.3 不同应用场景对能力画像的要求能力画像不是越全面越好它要服务于场景。客服场景看重的是多轮交互一致性、语言风格稳定性和安全边界。规划深度反而不是最要紧的因为大多数客服任务不超过五步。这个时候如果你只盯着长程任务基准的分就会选错模型。代码开发场景恰恰相反。它极度依赖长程规划、工具调用准确率比如读文件、搜代码、执行测试和错误恢复能力。代码 Agent 经常陷入几十步的长任务中途编译失败是常态能不能自己读报错再改代码直接决定可用性。数据分析场景则对世界知识和推理判断要求更高。模型要理解业务指标的含义判断工具返回的数据是否合理还要在数据缺失时提出假设。这类场景里多模态能力也经常被用到比如读取图表截图。办公自动化是个混合体对 GUI 感知、跨工具联动、长时间上下文记忆都有要求同时因为面向终端用户还必须保持低的误操作率。我一个真实项目里统计过用户在意的不是任务完成得快而是“别给我乱改文件”。这本质上就是一个安全对齐问题。所以与其问“这个模型厉害吗”不如问“这个模型的能力画像跟我的场景匹配吗”。匹配度高的模型即使绝对分数不是最高落地效果也往往更好。4. 实操指南搭建自己的 Agent 评测体系4.1 评测集怎么构建从公开基准到私有任务要搭一套可复用的评测体系首先要想清楚评测集从哪来。我的建议是三分之一公开基准、三分之一私有业务任务、三分之一对抗性样本。公开基准解决“通用水位”问题。它可以帮你快速建立模型之间的对标关系知道某个模型在行业里大概是什么水平。但直接照搬有问题公开基准的任务可能被模型训练数据覆盖也就是所谓的“数据污染”分数虚高。私有业务任务才是评测体系的核心。它来自你真实的业务场景把过去三个月用户实际提过的需求、实际跑过的任务脱敏后改写成评测用例。这类任务不追求数量多追求的是代表性和准确性。比如你做一个合同审查 Agent你应该从真实合同样本里抽 50 个关键条款场景而不是随便生成 5000 条模拟数据。对抗性样本用来测试边界和安全性。包括措辞含糊的目标、恶意指令注入、超长上下文、冲突指令。这类任务通常不是从业务里来的而是从“用户最坏能搞出什么事”出发设计出来的。每个评测用例我都建议配一张任务卡固定以下字段任务目标、初始环境状态、可用工具列表、预期产出标准、特殊约束、难度标记、成本上限。有了任务卡评测的可复现性和沟通成本都会大幅改善。4.2 评测执行与数据采集的注意点评测执行的门槛比很多人想象的高。环境不稳定、版本不一致、随机性没有控制都会让结果失去意义。首先是锁定版本。模型版本、框架版本、工具环境版本、评测代码版本全部要固定。尤其要注意模型服务端的“偷偷更新”有些提供方会在没有通知的情况下更新模型推理参数导致几天前后的评测结果对不上。我在流程里会记录每个任务的调用时间和模型版本号一旦发现数据异常先查版本。其次是控制随机性。模型推理采样参数要固定特别是在测成功率的时候。如果采样温度设得太高同一个任务会出现很大的结果波动评测的置信度就低了。我通常会分别记录 greedy 模式和带采样模式下的成绩两者差异本身就是一条重要信息。然后是超时与并发。Agent 任务耗时长必须设置任务级超时和单步超时避免一个卡死的任务耗掉整个评测预算。并发也要控制因为工具环境的限流和状态隔离会影响评测结果。一个稳妥的做法是把每个任务封装成独立沙箱互不干扰。最后是日志规范。我强烈建议从一开始就用结构化日志不要用纯文本输出。每个动作都必须包含时间戳、动作类型、输入摘要、输出摘要、token 消耗、工具返回状态。这些日志不仅是评测数据也是之后排查问题的唯一依据。4.3 结果分析与报告呈现评测报告不能是一堆数字的堆砌。我会按三层结构来组织结论摘要、能力画像、轨迹证据。结论摘要用三到五句话回答决策者真正关心的问题这个模型能不能用、适合什么场景、在什么条件下需要人工介入、成本大概是多少。不要在第一页放雷达图决策者没时间解读。能力画像部分放维度得分、分层成功率、成本分布。这里要特别注意区分“统计显著差异”和“偶然波动”。如果 A 模型在某个维度比 B 模型高五个点但样本只有二十条这个差异可能没有意义。我在报告里会标注置信区间或者用最简单的办法把任务随机分成两组看两次跑分的一致性强不强。轨迹证据部分放典型成功和失败案例的摘要。每个案例附上模型的关键动作序列和最终产出必要时放录屏链接。这个部分很有说服力一张真实的失败轨迹截图比十页分析都管用。报告最后还要留一页“未知项”。哪些任务没覆盖哪些维度测试不足哪些结果因为环境原因被标记为低置信度。敢于写未知项比硬给结论更能建立信任。5. 常见问题与排查技巧实录5.1 问题速查表这一年多踩了不少坑我把最常遇到的问题整理成了一张速查表方便大家按图索骥。现象常见根因排查与解法同一条任务本次通过、下次失败环境初始状态未隔离采样随机性未控制固定环境种子降低采样温度多次运行取分布模型在公开基准上分数虚高训练数据可能覆盖了评测集加私有任务交叉验证换新版本基准模型频繁调用无关工具提示词对工具使用引导不足检查系统提示词限制工具可见范围任务超时后重试还是失败单步超时设置过短模型陷入循环分析轨迹确认循环点加入步数上限机制两个模型分数明明不同却都很好用业务任务覆盖不足增加业务私有任务按难度分层再看真实环境表现跟评测结果不一致评测环境与业务环境差异过大尽量用沙箱模拟真实工具增加人审环节上下文太长导致后半程任务崩坏上下文管理策略缺失加入摘要压缩机制观察上下文增长曲线模型拒绝执行合法任务安全对齐过保守检查拒绝理由在安全审核逻辑里增加放行条件5.2 实操中容易踩的坑速查表之外下面这五个坑是我觉得最具普遍性的值得展开讲。第一个坑是只报最好的一次运行成绩。很多模型在评测中的表现并不是稳定的跑五次取最高分是典型的“幸存者偏差”。真实应用的场景是成千上万次调用必须按分布来评估而不是按最乐观的那一次。我在团队内部定了一个规矩一切结论基于至少三次完整运行的中位数和极差不允许只报 best case。第二个坑是低估数据污染。公开基准满天飞模型训练数据里很可能已经包含了评测样本的同类任务。这不是说所有公开基准都没用而是说你要有“污染怀疑论”的心态。发现一个模型在某个公开基准上成绩异常突出第一反应不是欢呼而是查有没有可能的泄漏。第三个坑是评测环境跟生产环境不一致。我在某办公自动化项目里就吃过亏评测时工具返回速度非常快模型决策节奏很舒服上了生产工具接口延迟变成三秒模型开始频繁超时和重试整体表现断崖下跌。后来把网络延迟和限流都注入到评测环境里才还原了真实表现。第四个坑是只测功能不测成本。功能跑通了就认为模型可以上生产完全没算过 token 消耗、重试开销、人审成本。等到账单出来才傻眼。正确的做法是从评测阶段就把成本字段记录在案并且设置成本上限作为硬指标。第五个坑是忽视长期记忆。很多 Agent 任务需要多会话记忆模型能不能记住昨天的结论、上次的处理偏好这决定了 Agent 是否像一个有连续性的同事而不是每次都要重新介绍自己的陌生人。评测集里应该包含跨会话任务连续跑同一个用户的两三个关联任务看信息能不能正确带过去。还有一个我觉得非常有用的技巧给每次评测任务录屏。Agent 任务运行过程中录屏能捕捉到日志里看不到的细节比如页面闪动、点击错位、加载状态。排查 GUI 类问题时录屏几乎是唯一能还原现场的手段。关于怎么做最简单的方式是加一个定时截图任务按固定频率记录界面状态最后拼接成排序帧。这个改动成本不高但对后续问题定位帮助很大。写在后面评测的真正意义是建立信任最后再说两句我从实际操作里悟出来的东西。做 Agent 评测的时间越久我越觉得评测的价值不在于给模型贴一个分数标签而在于建立一种基于证据的信任感。你知道这个系统在什么条件下可靠在什么条件下会失效失效的时候会以什么方式表现出来。这种信任感是产品落地、业务放量、风险管控的底牌。另一个体会是评测体系要跟着模型能力一起进化。半年多以前觉得很难的任务现在的模型可能已经轻松处理以前觉得稳定的维度换一个底层模型之后又出现了新问题。我的建议是每个季度把评测集重新审视一遍淘汰过时任务补充新风险点保持测试环境的对抗性。如果你现在还没建立自己的评测体系我建议先从一个小切口开始挑十个业务里最典型的任务配上任务卡和结构化日志搭一个最小可用的评测脚本。这个版本不需要什么完美指标跑通之后你自然会感受到它带来的确定性。等你想知道“模型到底行不行”的时候至少有数据可以回答而不是靠直觉和别人的榜单空转。