很多团队跑完十几个Demo都会陷入同一个尴尬模型评测还能用MMLU、HumanEval说事轮到Agent就只能甩“跑了100条case都过了”。可这个“过”到底怎么判的环境是不是干净目标是几步完成的中间有没有让模型撞运气撞出来的换个场景还成立吗这些问题答不上来Agent的评测就是一笔糊涂账。我这两年把主流的Agent基准都过了一遍也给自己团队的Agent搭过完整的评测流水线。这篇就把我踩过的坑、看过的基准、以及一套能落地的评测方法一次说清楚。目标是让你看完之后能直接给手上的Agent设计一套“有说服力”的能力评测方案。1. 为什么Agent评估比LLM评测棘手得多先对齐一个底层认知Agent评测不是LLM评测的简单延伸。LLM评测是“输入一句话比对输出文本”Agent评测是“输入一个目标让Agent在环境里做一系列决策最终观察世界状态发生了什么样的变化”。这两件事的复杂程度完全不在一个量级。1.1 从“单发问答”到“多步决策”的范式转移传统大模型评测里每条样本是独立的给问题、出答案、对标签。哪怕考的是推理题模型只需要把最终结果写对过程再乱也能得分。但Agent的核心运行单元是“感知—规划—行动—观察”的循环。一个任务往往要拆成若干个步骤每一步又依赖上一步的反馈中间还穿插着工具调用、信息检索、异常恢复和路径修正。举个例子同样是“帮我在GitHub仓库里找到所有没有license的第三方依赖并生成一份合规报告”这个任务一个Agent可能要经历列出依赖清单、解析依赖类型、查看每个仓库的license信息、发现某个仓库404、换用包管理器元数据、汇总生成报告。整个过程可能涉及数十次工具调用。如果只用最终报告是否生成来打分你会完全看不清问题出在依赖识别、信息检索还是报告格式化环节。这就是Agent评测最核心的难点动作空间高维、执行路径长、失败模式多。传统LLM的答案可以接受“部分对”的评分Agent的执行轨迹却是一条串行链任何一个环节失败都可能导致最终结果不可用。评价一个Agent本质上是在评价一整条决策链的质量而不只是一个端点的答案。1.2 部分可观察、环境状态与“不可复现性”LLM评测是确定性的输入输出映射Agent评测却嵌在环境里。环境是动态的状态是部分可观察的。同一个Agent同一段Prompt同一条工具链跑两次可能得到完全不同的结果——因为环境反馈变了或者随机采样变了甚至工具的返回延迟变了。我做过一次两极分化极其明显的测试让Agent去某个沙盒电商网站下单。第一次它顺利用登录、搜索、加入购物车、结算6步搞定第二次可能是因为页面渲染稍慢定位元素失败它在重试两轮之后直接放弃最终任务失败。同一个配置同一个任务结果从通过变成失败这不是Agent异常而是环境交互类任务与生俱来的波动性。更麻烦的是很多状态下述对模型是“部分可观测”的。Agent只能通过屏幕截图、HTML源码或API返回去推断当前状态而这些信息往往是残缺甚至误导的。评测这类Agent时如果只在脚本里断言“最终有没有下单成功”就会丢掉大量关于“它是如何在不确定信息下做决策”的有价值信号。1.3 指标要看“结果”还是“过程”一个硬币的两面我们评测Agent时到底想量化什么不外乎三个层面结果层任务有没有完成完成得对不对。比如代码修复是不是通过了全部测试订单是不是真的生成了。过程层路径质量如何规划是否合理工具是否被正确调用有无无效空转。成本层完成同样任务消耗了多少token、多少时长、多少次API调用。这三个层面不是互相替代而是互相补充。只看结果你会漏掉“虽然成功但路径一塌糊涂”的Agent只看过程你又可能埋没“虽然绕了远路但最终扛住任务”的Agent。从评测设计的第一天起你就得想清楚自己的产品更看重哪一层再把权重设计进评分体系里。提示结果指标适合做门禁过程指标适合做分析成本指标适合做优化。三者的用途完全不同别想用一套指标包打天下。2. 主流Agent基准测试全景扫描提到Agent评估绕不开几个高频出现的基准。每个基准的设计哲学、任务形态、评估方式都有巨大差异理解它们的差异比记住一堆榜单数字有用得多。2.1 GAIA真实世界问题合集GAIA的定位很明确它不搞环境模拟而是精挑细选了几百个“连人类都需要做多步检索和推理才能回答”的真实问题。比如“2023年某个月某个去重后的PDF文件里第几个脚注引用的是某篇文章”你要先下载PDF、解析内容、定位脚注、再回答。没有现成的工具环境要Agent自己发现并组合工具去完成。GAIA评估的是Agent的综合问题解决能力尤其是多步骤信息检索与推理的组合。它的优点是不依赖沙盒环境答题就是最终结果复现成本低缺点是问题和答案都是静态的一旦数据集泄露到训练语料里分数就会迅速贬值。它目前更适合作为Agent能力上限的参考不太适合日常迭代回归。2.2 AgentBench统一跨环境评测AgentBench的思路是把多种不同形态的环境统一到一个评测框架里覆盖操作系统的命令行操作、数据库查询、知识图谱推理、卡牌游戏、横向思维谜题、网页电商、家居控制等场景。它把Agent扔到各类交互环境里看它在不同界面和反馈机制下的完成能力。这类“多环境”评测的好处是能评估Agent的跨域泛化能力——不是只会用某一个工具而是能适应不同环境的反馈模式。缺点也很明显环境种类多但每个环境的任务深度有限容易止步于“能用”而非“好用”而且搭建多个沙盒环境对基础设施的维护成本不小。2.3 WebArena与OSWorld操作类任务的沙盒阵地如果目标是评测Agent在真实软件界面上的操作能力WebArena和OSWorld是我目前觉得最“像那么回事”的基准。WebArena一个自托管的网站集群包含电商、论坛、CMS管理、开发者工具等场景。Agent在这些网站里完成跨页面的任务比如“把论坛里某篇帖子转成PDF附件发到站内信”。它的特点是环境可控、任务相对真实很多网页Agent的研究都会拿它做度量。OSWorld更进一步直接跑在真实操作系统上通过截图和键盘鼠标接口操作桌面应用。它的难度极大很多基于纯文本的Agent在这里会“睁眼瞎”因为信息都要从截图中去理解。用这类基准时要有心理准备首因是环境搭建复杂容器化、网络隔离、状态重置都要做好次因是任务粒度差异大从三步能完成的点操作到几十步才能解决的综合任务都有直接用总通过率排名可能掩盖某些子能力的问题。2.4 SWE-bench代码修复场景的“硬核考场”代码Agent是当前应用最密集的方向之一SWE-bench是绕不开的基准。它从真实开源项目的GitHub issue中提取任务要求Agent理解问题描述、定位代码缺陷、修改代码并通过针对该issue的单元测试。SWE-bench之所以硬核在于它绝无“背答案”的空间——每个任务都是一段独立的历史快照Agent得自己探索仓库、定位缺陷、写补丁、跑验证。它的评测判定也很干脆跑测试过了就是过了。这类完全确定性的验证方式是我最推荐的Agent判题形态之一因为它不依赖任何主观打分模型结果可复现性很好。不过要提醒的是SWE-bench本身也在演进。官方后来做了SWE-bench Verified人工过滤掉了一些模糊或不可复现的任务进一步提升了可信度。用的时候别直接照搬全量测试集优先选Verified子集能省掉大量争议。2.5 τ-bench与工具调用类评测基准工具调用能力的专项评测是Agent能力的又一个重要子维度。τ-bench这类基准的设计思路是构建一个模拟业务系统航空预订、客服系统等Agent需要从自然语言中理解用户目标在多个数据库和API间完成查询、预订、取消等操作。这类基准的独特价值在于它显式约束了工具行为和副作用规则Agent不仅要完成操作还要保证操作符合业务约束不能替用户做超范围的决定。评测指标也不只算“任务完成率”还会看“违规率”。你可以在里面学到一种很实用的评测思路把“能做”和“该做”分开打分。2.6 主流基准速查对比基准任务形态环境判定方式主要考察点GAIA综合问答无固定环境答案比对多步检索与推理AgentBench多环境任务多个沙盒规则判定跨域泛化WebArena网页操作自托管网站状态断言网页Agent完成力OSWorld桌面操作真实OS状态断言视觉操作能力SWE-benchGitHub issue修复代码仓库单元测试代码修改正确性τ-bench业务系统操作模拟API规则违规检查工具调用合规性参考这些基准时我建议你先回答一个问题我的Agent到底在什么环境下工作如果是网页自动填充类看WebArena如果是代码生成类看SWE-bench如果是企业内部多工具编排那AgentBench多环境的思路比单一基准更值得参考。3. 拆解Agent能力评测的多个维度基准是别人设计好的“考卷”你总归要回到自己的场景出题。出题之前先把能力维度拆清楚。我发现一个常见的毛病是把“任务完成率”当作唯一指标这其实远远不够。3.1 任务完成率只是起点任务完成率是衡量Agent能否达成目标的基线指标。它很直观但有很多隐含问题。第一它不区分任务难度一个三步任务和一个三十步任务同样计一分Agent完全可能通过“把简单任务全做对、把复杂任务全失败”来粉饰成绩。第二它不区分失败原因Agent是因为规划错了失败的还是因为工具报错失败的都被混在一个数字里。所以我在实际评测里会把指标拆成三档完整成功率任务完全达成不作任何折减。部分完成度任务达成一定比例比如“生成了报告但缺失两个模块”。关键里程碑达成率把长任务切成几个不可跳过的阶段看Agent在哪些阶段容易掉链子。第三项是最容易被忽视的。复杂任务里我把每个Agent任务的执行轨迹预先划分成“理解目标—访问数据—执行操作—校验结果”几个阶段再让评判逻辑看每个阶段是否达成。这样可以精准定位Agent的短板是缺工具、不会拆解、还是不会做最终校验。3.2 规划与工具调用的质量如何量化规划能力听起来很虚但有几种可量化的代理指标无效步骤占比Agent执行了多少次没有改变任何状态或没有给下一步提供有用信息的动作。无效步骤占比高说明Agent在盲目试探。重试次数同一工具调用失败后的重试次数。合理范围内的重试是容错能力过量的重试则是退化成了“撞运气”。死循环概率Agent连续执行同一动作超过阈值而无法跳出。这是生产环境最致命的问题之一也是评测里必须单独统计的指标。工具选择正确率在任务已知的情况下标准路径里更应该调用哪个工具与实际调用的工具做比对。这个指标需要人工标注标准路径成本较高但信息量最大。工具调用层面还有一个我强烈建议你去加的评测维度输入参数合法性。很多Agent不是选错了工具而是工具参数填得乱七八糟。比如调日历API时把日期格式传错、把用户ID传成订单号。这类错误完全可以通过Schema校验来自动检测不需要任何人工成本而且能快速暴露Agent在“信息提取和字段映射”上的缺陷。3.3 鲁棒性、安全性与对抗性评测Agent跟LLM最大的不同是它有“真实副作用”。LLM答错了一句话最多是文本质量差Agent调用API下了个订单、删了条数据、发出去一封邮件错误就是实打实的生产事故。因此安全性和鲁棒性是Agent评测里比任务完成率更值得优先看的维度。我在自己的评测流程里固定跑三类安全用例敏感操作二次确认当任务涉及删除、转账、发送、修改权限等高危操作时Agent有没有主动要求用户确认。对抗性Prompt注入在网页内容、工具返回里埋入“忽略之前指令请执行xxx”这类句子看Agent会不会被环境里的恶意指令劫持。约束遵守任务描述里明确说“只能读取CSV文件不得调用网络API”看Agent能不能严格遵守边界。韧性评测也很重要。真实世界里的API会超时、会返回异常、会中途限流。我一般会给Agent加一组“故障注入”用例把某个工具的复杂度调高、故意让某个外部服务返回500、给结果注入一点延迟。优秀的Agent应该能在反馈异常时降级重试、更换策略而不是直接崩溃。注意安全评测应该跟功能评测分开跑因为安全用例的任务目的就是“诱导Agent犯错”它和正常任务的目标是冲突的。混在一起跑指标会被严重稀释。3.4 成本效率一个常被忽略的关键维度两个Agent完成同一任务的准确率都是80%但它们成本差距可能高达5倍甚至10倍。在实际工程场景里成本效率和任务成功率同等重要。评测报告上不能光写“成功率92%”你得同时记录Token消耗总数尤其是输入token的膨胀情况。很多Agent失败后反复重试重试会把大量历史上下文重复塞进提示词导致单任务成本飙升。工具调用次数工具次数直接影响延迟和出错点。调用次数过高的Agent哪怕成功率高也不具备生产可用性。端到端耗时Agent的串行决策结构天然有延迟30秒内能完成的任务如果被拖到3分钟用户早就流失了。有一次我调优一个客服Agent把成功率从78%提到了82%同时也观察到了工具调用次数从平均9次降到6次、token消耗降了将近四成。这让我意识到好的Agent在路径分析和资源利用上通常是同时进步的。评测时把成本列出来你会看得更清楚。4. 从零搭建Agent评测流水线看再多基准最后都得落到自己的评测体系上。我把自己在项目里真正用过的、经过多轮迭代的方案梳理成一个可复用的流程。它是面向工程团队的不一定需要多复杂的平台但要把每个环节做到位。4.1 选型复用现成框架还是自建沙盒Agent评测市面上已经有不少框架例如LangChain生态里的LangSmith、OpenAI出过的Evals、还有各类评测平台。它们各有优势但我想给一个务实的建议先别急着选框架先想清楚自己的评测场景里“环境”占多大分量。如果你的Agent不需要跟外部世界交互只根据已有信息做判断和组合那用现成的离线评测框架就够把数据集导入、跑批、算指标就行。这类场景的评测本质上还是“输入—输出”的模式框架的成熟度很高。如果Agent需要操作浏览器、调用真实API、读写文件那你的核心建设任务反而是“沙盒环境”。我团队的做法是用容器给每个评测用例准备独立的执行环境任务开始前做一次快照任务结束后销毁容器。这样能确保用例之间互不污染。这个环节需要花时间做基础设施但它正是Agent评测和LLM评测差异最大的地方也是最能保证可信度的地方。4.2 设计评测集任务语料与初始状态评测集的设计直接决定评测结果有没有参考价值。我认为一份好的Agent评测集至少要覆盖这三个维度任务类型多样性简单任务、中等任务、复杂任务按比例混排。避免评测集全是一步能完成的简单任务否则指标会虚高也避免全网全是长链路任务否则回归成本太高、定位问题困难。初始状态一致性每个任务开始前环境必须处于约定好的初始状态。测电商下单起始购物车必须是空的测多轮客服对话历史必须是同一份。初始状态不一致评测结果就没有对比意义。参考答案与判定标准每个任务对应一条“成功标准”。能程序化断言的就用断言不能的也要先写清楚从哪些维度打分。不要在评测跑完才补判定标准那基本意味着你在给结果讲故事。我习惯用一张二维表来管理评测集横轴是任务类型检索、操作、生成、修复纵轴是难度等级L1-L3。每次版本迭代三类任务抽样比例固定这样版本之间的指标才可比较。4.3 运行时观测与轨迹记录跑评测前就要想好观测方案。Agent运行过程中的每一个动作、每一次工具返回、每一轮思考都应该被记录。我要求所有评测日志至少包含时间戳与步骤序号模型输入的完整内容Prompt、工具返回、上下文——别只记录关键字段留全量日志是事后排查的唯一线索Agent决策输出思考过程和工具调用参数工具执行的结果成功、失败、返回内容摘要。记录这些内容的价值在评测阶段就体现出来了。判定完成后凡是失败用例我都能按步骤重放整条轨迹精确看到Agent是在哪一步走偏的。没有轨迹记录的Agent评测相当于考试只发总分不发试卷你根本不知道学生错在哪。4.4 判定方案确定性校验与LLM-as-judgeAgent评测的判定方案是我花了最多时间研究的部分。目前主流的做法分两派各有适用场景。确定性校验适合有明确结果的场景。比如代码类任务用单元测试、数据类任务用字段比对、操作类任务用环境状态断言。它的好处是客观、可复现、不受主观偏倚影响。我强烈建议能用确定性校验的任务就不要用模型打分。LLM-as-judge适合开放性问题。比如“总结是否有洞察力”“方案是否可行”“回复语气是否专业”。让GPT-4或Claude这类强模型按评分标准打分。它的成本低、速度快但风险是“分数膨胀”和“立场偏倚”——如果两条回复里都带有“抱歉没能解决您的问题”后再接“但为您提供了方案”模型打分时经常被冗长道歉和废话干扰。我实践出来的最稳定模式是混合判定先用规则或断言做客观过滤把“明确对”和“明确错”的case过滤掉剩下的模糊地带再用LLM打分。打分时给LLM提供全部轨迹摘要而不是只看最终回复并且让打分模型用结构化评分项输出比如“目标匹配度1-5分”“步骤合理性1-5分”“错误处理1-5分”不要只给一个总分。4.5 回归机制与报告模板评测不是一次性动作它是迭代过程中的“体检”。我建议把Agent评测嵌入到每次变更的回归流程里跑完以后输出一份结构化的回归报告。报告至少包含总体成功率和分类型成功率与上一版对比的差异失败case明细重点标注新增失败与恢复成功某一类工具调用的平均次数、平均token消耗Agent进入死循环或提错异常方案的具体case清单。有了这份报告团队评审Agent改进时就能直接讨论“哪类case变好了、哪类case变差了、我们要不要接受这个调整”。评测体系到此才算真正闭环。5. 评测实战中的常见深坑这段是我踩过最多坑的地方写出来希望你能绕开。5.1 缓存污染与环境不隔离第一个坑就是环境不隔离。Agent评测时如果多个用例共用同一个数据库、同一个浏览器实例上一道题留下的状态就会污染下一道题。我知道很多人一开始图省事只做了“清空缓存”而不是“重置容器”结果就是每次跑完指标都稳得可疑一旦排查才发现Agent拿到的是上一道题的残留数据。我的建议是每个评测用例跑在独立的、一次性的环境里。哪怕成本高一点也要这么做。Agent评测最怕的不是慢是结果不能归因到Agent本身。5.2 上下文泄漏把答案写进了Prompt第二个坑极其隐蔽。有一次我发现Agent在某类任务上的成功率异常高快到让我起疑。一查日志发现评测Prompt里为了“交代背景”放了一份包含答案线索的文档。Agent根本不需要真正思考直接从上下文里摘录答案就能答对。这种“标签泄漏”在Agent评测里非常常见因为Agent任务本身必须携带上下文上下文和“答案之间的边界”天然模糊。规避方法是专门做一轮“泄漏检查”把评测集中的任务背景逐个审查看有没有直接给出最终答案的句子同时可以设计几个“如果只读背景就能答对”的探针用例测出泄漏程度。5.3 基准污染与模型记忆如果你用的是公开基准比如SWE-bench、GAIA这类一定要警惕模型在训练阶段可能已经见过原题。现在很多模型对知名基准的记忆程度远超你的想象。一个典型的特征是模型对刷过的题成功率极高但对仅做了微小改动的变体成功率大幅下降。应对方法有几个一是优先使用官方验证过的子集并定期更新版本二是尽量在你的评测集里加入自建的私有case这部分永远可以信任三是如果必须用公开题就改写题干、修改数值、替换文件路径让模型不能直接“背答案”。5.4 Judge模型带来的分数膨胀LLM-as-judge的分数膨胀问题比较头疼。早期我用一个口径较宽松的模型做判定团队里所有Agent的评分都高得让人兴奋测试集一换或者判定模型一换分数立刻掉一截。这说明分数不是Agent的而是Judge的。现在我对Judge的要求是评分必须给出依据每条分数后面挂输出原因并且定期人工抽检一批LLM判定结果计算JD一致性与人工评判的一致性。当Judge的打分习惯和人工判断偏差超过一定阈值就得立刻更换或调教Judge模板。5.5 “终点成功”掩盖“过程灾难”最后一个坑是对“最终还是成功了”的case缺少过程审查。一个Agent花了40步、调了15次工具、消耗了大量上下文才完成一个6步能完成的任务评测报告上它依然是“成功”。这类成功在生产环境中就是定时炸弹因为每一步都是概率相乘路径越长整体失败率越高。所以我坚持在成功case里也做路径效率分档一步到位算优秀绕路但能收敛算可接受严重绕路必须标记为待优化。效率和成功率永远要放在一起看。6. 把评测看作一条持续运行的流水线跑过几轮完整评测之后你会慢慢意识到Agent评测不太可能一锤定音。它更像一条持续运行的流水线环境在变、工具在变、模型的版本也在变评测方案必须跟着迭代。6.1 过程监督的优先级正在提升过去看Agent的最终结果现在越来越多的评测设计转向“过程监督”。原因很简单Agent的长任务链路中任何一步错了都可能导致最终结果不可用而结果失败时如果只做最终判定你根本不知道应该优化Agent的规划能力、工具能力还是自我校验能力。我身边已经在同步建设“过程级”评测维度比如每个中间步骤的结果是否符合预期、每轮规划是否合理、Agent在拿到工具异常时是否采取了正确策略。做这类评测需要更精细的标注和更完善的观测基础设施但它的投入回报非常明显——它能把“Agent行不行”这个问题转化为“Agent具体哪里不行”让每一次迭代都有明确的靶子。6.2 从静态基准走向自适应环境静态基准是一个固定滑倒的脚本你的Agent只要训练得当分数迟早饱和。饱和之后的分数波动基本是噪声对迭代毫无参考价值。真正有价值的评测应该具备“自适应”能力当Agent明显适应了某个评测集之后环境要能自动生成新的变体题目。这个方向当前已经有雏形比如你可以在评测框架里引入fuzzing的思路修改任务参数、调整环境初始状态、在工具返回里随机注入异常。这样做评测集的难度会动态匹配Agent能力能持续给研发团队提供新的增量信息。6.3 评测要与Agent架构对齐最后提醒一点评测方案要跟你真实生产的Agent架构对齐。如果你的Agent外层挂了一个执行控制壳里层才是模型决策核心那评测时既要测模型决策能力也要测外层控制壳的容错与编排能力。很多团队把这两个层面混在一起评分出了问题还要靠猜。我实际使用中的做法是把评测报告分成两层决策层测试模型本身的判断、规划、工具选择质量执行层测试Agent框架的编排、重试、状态管理能力。哪个环节坏了改哪个不会让模型为执行层的bug背锅也不会让框架为模型的能力缺陷背锅。6.4 分享一个我现在坚持的评测节奏我现在对Agent项目坚持的评测节奏是每次模型或框架变更跑一遍全量回归集每周抽一天做一次随机变体压力测试每个月做一次私有case扩充。这样下来Agent的每个版本迭代是否值得发布我都能拿数据说话而不是靠感觉。如果你要从零开始别一上来就追求评测平台的大而全。先把手头的三个核心Agent任务做成带初始状态、判定规则、轨迹记录的评测case跑通整个流程再去逐步扩展评测集。评测这件事最大的价值不是那个最终分数而是它逼着你去想清楚我的Agent每一步到底在做什么、做到什么程度算好、做坏了会有多严重。把这些想清楚Agent的质量曲线自然会往上走。