Agent评测实战：从基准到流水线的完整指南

很多团队跑完十几个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 主流基准速查对比

参考这些基准时，我建议你先回答一个问题：我的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-judge

Agent评测的判定方案是我花了最多时间研究的部分。目前主流的做法分两派，各有适用场景。

确定性校验，适合有明确结果的场景。比如代码类任务用单元测试、数据类任务用字段比对、操作类任务用环境状态断言。它的好处是客观、可复现、不受主观偏倚影响。我强烈建议能用确定性校验的任务就不要用模型打分。

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的质量曲线自然会往上走。