背景现如今想要搭建一个 Agent其实并不是很复杂已经有非常多成熟的框架和架构选型。但是很多人会遇到同一个问题Agent 构建好之后到底应该怎么评测Agent 的评测的确是一个比较复杂的事情可以算比较大的一个 “痛点” 了。今天重点聊聊 Agent 评测这件事。因为在做 Agent 的开发和落地的过程中评测环节实打实会有很多坑。一、为什么传统测试方法在 Agent 上失效了首先我们来讨论一个核心话题传统的软件测试方法在 Agent 时代很多都失效了。虽然我们现在也有一些模块化的评测逻辑比如端到端地去评测整个 Agent或者去拆解里面的一些细节逻辑这些思路本身都是可行的。但是传统测试在 Debug 时有一个前提那就是确定性在输入不变的情况下输出是不会变的。所以传统做法我们会准备很多测试用例输入一个 Input然后对比 Output 是否符合预期。这是一个非常直观且正确的做法。但是在 Agent 里面这件事变得很难。第一个原因是因为 Agent 本身有一个很大的特性你输入同一个问题 10 次Agent 给出的结果可能每次都不一样。为什么会这样呢这主要受以下四个因素的影响模型随机性受模型本身的随机性影响以及 Temperature 参数带来的随机性。上下文变化对话的上下文可能会发生细微变化。工具返回结果变化调用的工具返回结果可能会变。比如调用探测状态的工具状态本身就在变或者订机票、酒店这些工具每时每刻返回的结果可能都不一样。Runtime 因素运行时环境中的一些因素比如时间会发生变化。这些因素叠加最终导致 Agent 的运行结果每次都有区别。所以只测一次很有可能存在 “测人品” 的情况运气好的情况就会得到好的结果运气不好结果就很糟糕。但如果你能够去测 10 次表现都还不错那才可能说 Agent 本身的能力达标了。这也说明了传统的测试方法在 Agent 状态下很难去复刻和复用。第二个原因就是多轮交互带来的 “蝴蝶效应”。举个例子扔一次硬币正面、反面的概率各是 50%那你扔两次都是正面的概率就是 50% × 50%也就是 25%。如果你要扔 10 次都是正面那就是 50% 的 10 次方这个概率会越来越低。同理在 Agent 的多轮对话中如果每一步模型的准确率是 90%那么到了第十步整体正确的概率就是 90% 的 10 次方。你看这就很容易出现错误累积。所以在多轮对话的状态下如果评测机制设计得不好很有可能导致最后根本得不出一个正确、理想的结果。二、Agent 评测核心概念拆解在深入探讨具体的评测方法之前有几个核心概念我们需要先捋清楚。理解这些术语是构建有效评测体系的基础下图是 Anthropic 官方的 Agent 评测所需的组件图。1. Task任务这是 Agent 所要完成的最核心内容。比如用户的问句是 “请帮我订一张机票”那么 Agent 的 Task 就是要去完成 “订机票” 这件事情。而订机票的最终达成状态就是该任务的最终结果。2. Trial试验指单次运行的试验过程。如果只跑一次成功率可能偶发性很强也就是前面说的 “测人品”。但如果我们跑 10 次或 100 次 Trial计算这 10 次或 100 次试验的平均成功率得到的结果会更有说服力也更稳定。3. Grader评分器Grader 是一个用于评估的模块它可能是一个大模型也可能是一套固定的规则代码。它的作用是给某个模块或者端到端的流程打分。有了这个分数我们才能量化 Agent 的效果而不是凭感觉说 “好” 或 “不好”。4. Trajectory轨迹轨迹也有的地方叫 Trace 或者 Transcript。它指的是 Agent 整个运行过程的全部链路记录通常包括模型的思考过程Thought、工具调用的过程、工具返回的结果、模型基于工具返回结果进行的进一步推理和思考、最终输出的 Response 结论。而且查看 Trajectory 能帮我们定位问题出在哪一步是 Debug 的重要依据。5. Outcome结果Outcome 就是 Agent 真正运行完之后的结果。这里需要注意Outcome 包含两个层面响应内容Response比如我问一个问题答案是什么或者模型口头告知是否成功失败这些能从回复中直接看出来。状态变化State Change这才是更本质的结果。比如我要去订票模型可能在 Response 里说 “已完成任务”但这不一定代表真的成功了。我必须去检查我的订单列表里有没有这张票票有没有真正订下来。这种实际环境中的状态才是最终的 Outcome。6. Harness 与 Model我们到底该测谁我们知道 Agent 领域比较火的一个公式Agent Model Harness。很多时候人们在评估一个 Agent 时会认为本质上是在评估大模型LLM。这个观点对也不完全对为什么说 “对”因为在整个过程中只有大模型是真正具备智能的部分也是随机性最强、最不可控的部分。我们评价一个 Agent 效果好不好很大程度上确实是在评估这个大模型的智能性或者说它做决策的准确度。为什么说 “不完全对”因为现在的 Agent 架构越来越复杂除了模型本身Harness也就是包裹模型的那层框架逻辑也变得非常厚重。Harness 不仅仅是简单的调用接口它包含了Context上下文的组装逻辑、Memory记忆的设计与管理、Compact压缩和 Summary总结的过程、工具的裁剪与路由策略等等。这些环节都会极大地影响 Agent 的最终表现。所以Agent 的效果不单单是 Model 本身的问题它是整个 Runtime 环境中各种组件集体的结果。因此当我们对 Agent 进行评测的时候不仅仅是在测 Model更多时候是在评估这个 Harness 的设计质量最终就是 Harness 与 Model 的配合效果。当然有时候我们也会去固定 Harness去测试不同 Model 在同一套 Harness 框架下的表现这也是评测的一个重要维度。但无论如何Harness 和 Model 都是我们需要去重点关注进行评测的对象。三、Agent 评测的尺子聊了解完这些基本的概念之后接下来我们重点聊聊 “Agent 评测的尺子”也就是 Grader评分器或者叫 Judger裁判。在 Agent 的评测体系中Grader 是那个 “判卷老师”。目前主流的 Grader 主要有三种类型它们各有优劣适用场景也完全不同。1. Code-based / Rule-based基于代码或规则这是第一种也是最传统的一种。它通过预先写好的代码逻辑或固定规则来进行评判。这种 Grader 非常适合那些结果确定、有标准答案的任务。比如我有一个文本分类问题要把一段文本分为几类。我可以预先建立一个 Benchmark知道每一个 Query 对应的正确 Label 是什么。当模型返回结果后只需要一段代码判断模型的输出是否和这个 Label 完全匹配。如果匹配得 1 分如果不匹配得 0 分。跑 100 个 Case看总分是多少满分 100 分能拿多少分一目了然。如果是多分类任务也可以设计成 “分对几类得几分”或者按比例算分。这种方案的优点是成本最低、速度最快、结果最确定没有随机性今天测和明天测结果一样但缺点也很明显适用范围很窄。只能用于那些逻辑固定、非黑即白的场景。一旦涉及语义理解或复杂逻辑它就无能为力。2. Model-based / LLM as Judge基于大模型第二种也是目前 Agent 评测中最主流的方式叫做 LLM as Judge。简单来说就是让大模型来当裁判参与评判过程。为什么需要它因为很多 Agent 的任务很难用简单的规则来定义。举个例子我让 Agent 调用一个天气查询工具返回我当地的天气。我要判断 “天气对不对”靠规则很难写因为天气数据是动态的模型的回复是不固定的。我要判断 “模型有没有调工具”、“调用的工具对不对”、“回复是否依据了工具返回的结果”这些都需要语义层面的理解。这时候就可以引入另一个大模型作为 Judger裁判。我们可以设计一套 Prompt让裁判模型去评估工具调用是否正确给分项 A最终回复是否准确反映了工具返回的信息给分项 B通过这种方式它可以给出一个综合分值。这种方案的优点就是适用面广大部分 Agent 的返回结果都是复杂的、非结构化的LLM 能够理解语义判断动作是否完成准确度比纯规则高得多。缺点也很明显成本高、速度慢每次评测都要调用大模型生成 Token。而且存在随机性这是个大坑即使是同一个问题、同样的回答你用同一个裁判模型测两遍它给出的分数可能会有波动。所以Model-based 的结果往往不够稳定可能需要多次取平均。3. Human-based基于人工标注第三种就是找人也就是人工评估。通常我们会找领域专家来进行判断这可以说是一种 “黄金标准”Gold Standard。这种方案的优点是质量最高最符合人类的真实感官和预期。对于那种极其复杂、连 LLM 都判断不准的场景人是最靠谱的。但缺点也非常多比如成本极高请专家是要花钱的速度极慢人工标注的效率远低于机器标准对齐难这也是人工标注最大的痛点不同的人对同一个结果的看法可能不同你需要花费大量精力去拉齐标注标准Calibration确保张三和李四打分的尺度是一致的。三种 Grader 对比维度Code-basedModel-basedHuman-based成本最低中等最高速度最快较慢最慢确定性最高 (无随机性)中等 (有波动)高 (但需对齐)适用范围窄 (固定逻辑)宽 (语义 / 复杂逻辑)最广 (所有场景)主要痛点无法处理模糊语义结果不稳定、成本高标准难统一、效率低Code-based不用拉齐标准代码和规则定出来是什么样就是什么样。Model-based如果用同一个模型、同一段 Prompt标准基本统一只是受模型随机性影响有点波动。Human-based最难的就是人与人之间的标准平衡和对齐。四、业界经典评测方法及 BenchmarkAgent 分为三大类操作型 Agent、对话型 Agent、编程类 Agent操作型 AgentAction-oriented AgentsAgent 的本质就是 “代理”核心目的是帮用户完成任务。而操作类 Agent 一般是最复杂的比如 Computer Use电脑操作、Browser Use浏览器操作等这类 Agent。它们需要基于视觉去访问网站获取内容或者操作你电脑上的软件、甚至整个操作系统来拿到结果。针对这种复杂场景介绍几个业界比较有代表性的 Benchmark。1. AgentBenchAgentBench 是由清华大学提出的一个 Benchmark。它涵盖了大概 8 种数据集包括操作系统、数据库、知识图谱甚至还有一些具身智能相关的场景。因为它偏向于 **“运行态” 的评测 **所以它不看你生成的代码写得漂不漂亮也不评判代码本身的语法对错。它直接运行代码看返回的结果是否符合预期。案例数据库查询任务请查询数据库中所有年龄大于30岁的员工。Select name from staff where age 30评判看跑出来的结果集员工名字、数量等是否和 Benchmark 预设的标准结果完全对上。如果对上了就认为正确。除了数据库这个 Benchmark 还有卡牌游戏、具身智能等。比如在具身智能场景下任务是 “把苹果放进冰箱”。它最后只看环境状态苹果是不是真的在冰箱里如果是就算成功。2. τ-Bench在客服领域有个 Benchmark 叫 τ-Bench。它的场景更贴近真实的客服业务用户会有一个具体问题且带有操作属性。案例“我要订明天的票” 或者 “我要订某个特定航班的票”。评判Outcome 导向模型不仅要看回复说了什么它会去后台数据库里检索看是不是真的生成了这个订单。只要订单真正落库了就认为是正确的。它关注的不是 Response 里的文字游戏而是真实的业务结果。同时它还引入了业务规则合规性检查这是 τ-Bench 的一个亮点。它不仅看结果还看过程是否符合业务逻辑。案例某些机票在特定情况下是不能退票的或者只能改签。评判如果 Agent 在不能退票的情况下执行了退票操作即使操作成功了它在 τ-Bench 里也会被判为失败。因为这违反了业务规则存在合规性问题。所以τ-Bench 不仅测 “能不能做成”还测 “做得对不对合规”。3. AgentBoard另一个值得关注评测 Benchmark 是香港科技大学推出的 AgentBoard。它的思路有点像我们小时候做数学题老师批改作业时不仅最终答案对不对还要看你的解题步骤。AgentBoard 主要考察两个方面最终结果检查State-based Verification这和前面的类似看最终的 Outcome 对不对。比如 Response 是否正确或者最终的环境状态是否发生了预期变化比如苹果是否进了冰箱票是否订成功。过程率检查Progress Rate / Trajectory Check这是 AgentBoard 的特色。它会为每个任务设定一组有序的 Subgoal子目标 / 中间状态。在评测时它会拿着 Agent 运行的 Trajectory轨迹去和这些中间状态逐一比对。案例任务是“买一个橙色、256G 的 iPhone 17。”AgentBoard 会拆解成以下步骤进行打分是否搜索了 “iPhone 17” 关键词是否 Click 了正确的产品页在选项里是否选择了 “Orange” 颜色是否选择了 “256G” 内存最终是否点击了 “Buy” 按钮评判如果你每一步都做对了得满分如果你跳过了中间步骤直接出结果或者某一步选错了颜色但最后误打误撞买对了分数就会受影响。这就好比数学题你可能答案对了但过程全错那也拿不到高分或者过程对了一半答案错了也能拿部分步骤分。总结AgentBench 重在运行结果代码跑通、数据对上就行τ-Bench 重在业务落地 合规不仅要有订单还要符合业务规则AgentBoard 重在过程 结果像改数学卷子一样既看答案也对步骤。这三种方式分别代表了不同维度对操作型 Agent 的考量大家在设计自己的评测体系时可以根据业务需求参考借鉴。对话型 Agent接下来我们看第二类也是非常常见的类型就是对话类 AgentConversational Agents。这类 Agent 的场景主要可以分为两种常见形态AI 助手比如我们常用的豆包、ChatGPT 等。你给它一个问题它可以直接利用模型自身的知识回答也可以通过 RAG 去搜索实时新闻或资料来回答还可以调用各种工具比如让它画张图、查个天气、算个数学题等。这些都是典型的对话驱动的场景。智能客服比如各大公司的智能客服这类场景稍微复杂一点。它同样基于用户提问可能直接调用知识库里面的固定话术回答也可能需要先查询用户的具体状态如订单状态、账户情况进行诊断后再回答甚至需要调用工具去执行操作。虽然逻辑上跟 AI 助手很像但它对准确性和合规性的要求更高。对于这类 Agent最直接的评估方式就是看输出的 Outcome最终结果。既然用户问的是一个问题我们就看这个回答是否真正意义上解答了这个问题。无论是纯模型生成的回答还是调用了工具后的回答都可以用这套逻辑来评估。但是这类的难点在于答案的不唯一性。因此我们可以考虑建立一个 Benchmark缓存很多用户真实的问题和对应的 “标准答案”。但这个标准答案往往也只能是一个参考答案。案例莎士比亚是哪里人Agent 回答A 答案“莎士比亚是英国人。”B 答案“莎士比亚出生于英国中部的沃里克郡斯特拉特福镇。”C 答案“莎士比亚是欧洲人生活在文艺复兴时期。”其实这三个回答其实都是对的只是粒度不同。如果我们的 Benchmark 里只存了一个 “英国”那模型 B 和 C 可能会被误判。解法也有两种多参考答案在 Benchmark 里为同一个问题预设多个可能的正确答案。LLM as Judge让大模型来判断语义一致性。只要模型说的是 “欧洲”、“英国” 或者具体的 “斯特拉特福镇”都算对。这也是一种比较简单直观的评测思路。下面介绍两个典型的 Benchmark。1. GAIA (General AI Assistants Benchmark)GAIA 是由 MetaFacebook联合多家机构推出的一个基准测试。它的理念很有趣专门挑选那些 “人类觉得简单但 AI 觉得难” 的问题。评测方法关键词匹配Keyword MatchingGAIA 的答案通常是一个具体的关键词或数值。它的评判规则比较 “粗暴” 但有效只要你的回答里包含了这个关键词就算对。常识类还是问莎士比亚出生地的问题。只要答案里提到 “英国” 或 “欧洲”就算通过。虽然有点宽泛但它通过放宽匹配规则来保证准确性。工具 / 文件处理类给你一个 Excel 附件问“这三列数据中哪一列的增长率最高负责人的姓名是谁”Benchmark 里预设了正确的数字和负责人的名字。不管你的回答啰嗦什么样只要里面提到了那个正确的数字和负责人的名字它就认为你是对的。这种方法的优点是非常直观、易于自动化适合大规模快速评测。2. τ²-Benchτ²-Bench 可以看作是前面提到的 τ-Bench 的一个进阶版。虽然它也涉及操作但我更倾向于把它归类在对话类因为它更偏向于客服领域的排查与结论。但是它除了对话之外还引入了对工具调用诊断能力的深度评估主要考察三个维度a. 状态一致性State Consistency状态一致性主要是看 Agent 对目前状态的判断准不准。案例用户欠费停机了。评判Agent 调用工具查询后返回的结果必须是 “欠费停机”。如果工具返回是对的但 Agent 理解错了或者 Agent 查出来的状态和实际不符那就扣分。这一步确保 Agent “看清” 了问题。b. 策略遵循性Policy Adherence这个主要是看 Agent 有没有按照合规的流程去回答或操作。案例某些敏感操作需要先验证身份或者某些问题必须先安抚情绪再给方案。如果跳过了必要步骤即使最后解决了问题也可能被判不合格。c. 最小代价原则Minimum Cost Principle这是 τ²-Bench 非常创新并且值得参考的一个点。它不仅要你解决问题还要看你用的方案是不是最优解是不是成本最低。案例用户说“我家网络连不上了。”方案方案 A引导用户重启路由器。成本低耗时短用户可自行操作方案 B直接派工程师上门维修。成本高耗时长评判虽然方案 B 也能解决问题网络确实通了但在 τ²-Bench 看来这属于 “用核武器打蚊子”。方案 B 的成本远高于方案 A因此会被判定为非最优解甚至可能被扣分。总结一致性是判断状态对不对合规性是判断流程走得对不对经济性是不是用了最小代价的最优方案这三个维度对于构建一个高质量、拟人化且具备商业价值的客服 Agent 来说是非常好的参考标准。编程类 AgentCoding Agents除了操作类和对话类还有一类非常硬核的 Agent编程类 Agent比如 Claude Code、Codex以及泛化除的如 OpenClaw、Hammer Agent 这些最新的、能处理复杂长任务的 Agent。这类 Agent 的评测难度更大因为它们的任务链路长、依赖多。虽然我们也可以沿用前面提到的 Outcome结果或 Trajectory轨迹检查但针对这种 “复杂 Agent”业界已经出现了一些新的、更具针对性的 Benchmark。基于公式Agent Model Harness有两种正交的评测手段固定 Harness 测 Model固定 Model 测 Harness1. ClawBench固定 Harness评测不同 Model 的能力核心逻辑固定住 Agent 的框架也就是 Harness比如固定使用 OpenClaw 这套架构然后替换底层的大模型。通过这种方式去判断在同样的框架下哪个大模型完成复杂任务的效果更好。评测场景ClawBench 覆盖了很多真实场景包括日常生活、娱乐爱好、内容创作、评分投票、旅行规划、教育、办公等等。评判标准看 “做” 得对不对而不是 “说” 得对不对。它不关心 Agent 生成的文本漂不漂亮只关心任务是否真正完成Outcome。如何工作a. 沙箱环境它为每个任务提供一个独立的沙箱里面运行着真实的浏览器或操作系统。b. 过程录制它会全程录制 Agent 的运行过程包括对话、鼠标动作、浏览器截图、最终返回结果等。c. 回放评估评测时系统会回放整个过程结合视觉信息和状态变化来打分。具体的评判流程分为两步第一步Schema 匹配检查。判断 Agent 最终发出的请求或产生的数据结构是否符合预设的 Schema。如果连格式都对不上说明中间已经出错直接判定失败。第二步LLM as Judge。如果通过了第一步再引入大模型作为裁判结合截图和上下文判断最终结果是否正确、任务是否达成。此外ClawBench 还会特别关注安全性评估 Agent 在执行过程中是否有违规或危险操作。2. HarnessBench固定 Model评测不同 Harness 的效果当你想要比较接入同样的模型到底是 Claude Code 好还是 OpenClaw 好或者是 Codex 好就需要反过来固定模型评测 Harness这也是 ClawBench 团队研发的另一个 Benchmark。它的核心逻辑是固定住底层的大模型比如都用 Claude Opus 4.8然后替换上层的框架Harness。通过这种方式剥离模型智能的影响纯粹去评估不同框架Harness在上下文管理、工具调用逻辑、记忆压缩等方面的设计优劣。总结对比ClawBench测的是同样的车架Harness换个引擎Model谁跑得快。HarnessBench测的是同样的引擎Model换个车架Harness谁更稳、更高效。这两个 Benchmark 是正交的共同构成了对复杂 Agent 的全面评估体系。它们最终看的都是复杂任务下的最终效果Outcome。五、通用评测工具OpenJudge出自 AgentScope 的 OpenJudge。它本质上是一个高度封装的 Grader评分器。它的特点是开箱即用。OpenJudge 的设计比较全面它不仅仅看结果而是从三个维度对 Agent 进行评估Final Response最终结果这是端到端的评估。主要看 Agent 最后给出的答案是否正确、是否真正回答了用户的问题、有没有产生幻觉Hallucination、以及是否包含有害或不安全的信息。Single Step单步表现这是对中间过程的微观检查。在每一轮交互中它会评估工具选择Agent 选的工具对不对调用成功工具调用是否成功执行Planning规划当前的步骤规划是否合理Skill/Memory技能调用是否准确记忆提取是否相关Reflection反思Agent 的自我反思逻辑是否成立Trajectory整体轨迹这是对全流程的宏观审视。它会判断整个执行链路是否正确Agent 是不是按照最优或预期的路径去完成任务的整个轨迹的逻辑是否通顺、高效对于大多数通用场景OpenJudge 内部已经预设好了一套完善的评分标准和 Prompt。你不需要做任何配置直接把它接入你的评测流程就能跑起来。这对于快速验证 Agent 能力非常方便。但是如果你觉得默认的开放评判标准不够准或者不符合你的业务特性你也可以考虑自定义 Grader。你可以修改评判 Prompt调整评分权重甚至引入特定的业务规则让它更贴合你的具体场景。六、Agent 评测体系的设计及稳定性现有的 Benchmark大多是面向通用场景或者特定公开场景主要用来给公众展示模型或 Agent 的效果。如果你是在自己的业务里落地 Agent 评测可以参考成熟 Benchmark 思路定制自己的评测标准。评估内容分为五大类端到端的 Outcome多轮的对话或者推理最终看结果对不对。Single Turn Outcome单轮交互的效果好不好。Trajectory 里的执行细节执行路径合不合理。中间结果检查拿到一些中间关键步骤的输出进行细查。State 状态最后完成状态是否正确。关键就在于针对你的场景设定一套合适的指标。强烈建议设计一个多维度指标体系。也就是说你既要看端到端的结果也要看单轮的表现还要关注过程细节。这样做的好处是可以一眼看出整体结果是好是坏。如果结果不好可以拆解出来看到底是中间哪个步骤出了问题。反过来如果你对比两套 Harness 或者两个 Model在过程很复杂并且状态经常变的情况下很容易发现端到端的 Outcome 有波动但中间环节有提升这也证明你的效果相比原来是有进步的。如果 Outcome 变好了但某些中间结果变差了你就可以深入去挖掘核心原因发现这里面其实还有很多优化的空间。另外非常建议多次运行 Trial试验。尽量不要只跑一次而是多跑几次取平均值。为什么因为 Agent 本身输出是不稳定的。如果你用了 LLM as Judge模型在评判的时候也是不稳定的。这就导致指标会左右摇摆。通过多次实验取平均可以有效降低噪音污染。甚至我们可以借鉴一些行业专业比赛的做法去掉一个最高分去掉一个最低分剩下的取平均分。去掉极值的目的就是为了降噪排除一些异常情况。跑的轮数越多出来的效果可能就越准越能真实衡量好坏。在 Trial 方面有两个常用指标也是很多论文里会用到Passk宽松指标意思是跑 k 次只要至少 1 次成功就认为通过了。这是一个比较宽松的指标。Pass^k严格指标意思是跑 k 次必须全部成功才算通过。类似于 Pass 的 k 次方。只要有一轮断了、不成功我就认为这次是不成功的。这是一个非常严格的指标。这两个的值往往差异很大。比如你的 Pass10 可能是 90% 多但你的 Pass^10 可能只有个位数。这种情况下可以通过计算 F1 值让两个指标结合起来算出一个平衡后的分数。这样往往比单一指标更客观。当然不得不承认Agent 的评测和构建成本都蛮高的。尤其是现在一些复杂任务评测一把经常要好几个小时才能跑完一轮还要再去算平均成本确实不低。但在 AI 时代这可能是没办法避免的投入。如果是个人场景Agent 的效果从体感上大概就能判断个差不多。但如果是企业级的 Agent拿到一个量化的评测指标必要性还是非常大的。当然如果模型的评测结果始终不稳定我们还有最后的 “杀手锏”让人进来评估。这也是一种策略但前提是拉通评测标准否则人与人的评测结果也很难一致。七、Agent 评测落地完整路径建立 Benchmark找到一些典型的 Case 构建成评测集。构建 Ground Truth预设标准答案如果你不构建 GT那就只能纯靠 LLM Judge 了但最好还是有标准答案否则 Judge 也会漂移。保证分布真实性Benchmark 集合要能反映你真实的业务分布。不然你测的问题都很偏门实际使用时问题却很常规那评测就不客观。构建稳定环境尽可能包含一些工具的 Mock或者把工具的运行结果缓存好让上下文干净一些减少外部干扰。设计 Grader评分器决定是用 Code-based代码规则、Model-based模型打分还是人工标注。执行与优化真正去跑批多做多次 Trial取平均降低偶发概率的影响最终完成一个比较复杂的评测。评测这块可重可轻如果注重了做可以做的非常精细做得轻也可以快速验证。这完全取决于你的场景需求和要求灵活调整即可。八、全文总结Agent 的评测确实是一个既复杂又充满挑战的领域。它不像传统软件测试那样有绝对的非黑即白更多的是在不确定性中寻找确定性的过程。从 Benchmark 的设计、Ground Truth 的构建到多维度指标的拆解再到通过多次 Trial 来对抗模型的不稳定性每一步都需要我们结合具体的业务场景去权衡和取舍。在实际落地中大家可能会遇到各种各样的 “坑”比如成本太高跑不动、LLM Judge 打分飘忽不定、或者中间过程难以量化等等。这些都不是靠一套标准答案就能解决的而是需要我们在实践中不断去摸索、迭代。评测本身不是目的通过评测发现短板、优化 Harness、提升模型决策能力才是我们构建高质量 Agent 的最终目的。
Agent 评测的基本概念与经典方法
背景现如今想要搭建一个 Agent其实并不是很复杂已经有非常多成熟的框架和架构选型。但是很多人会遇到同一个问题Agent 构建好之后到底应该怎么评测Agent 的评测的确是一个比较复杂的事情可以算比较大的一个 “痛点” 了。今天重点聊聊 Agent 评测这件事。因为在做 Agent 的开发和落地的过程中评测环节实打实会有很多坑。一、为什么传统测试方法在 Agent 上失效了首先我们来讨论一个核心话题传统的软件测试方法在 Agent 时代很多都失效了。虽然我们现在也有一些模块化的评测逻辑比如端到端地去评测整个 Agent或者去拆解里面的一些细节逻辑这些思路本身都是可行的。但是传统测试在 Debug 时有一个前提那就是确定性在输入不变的情况下输出是不会变的。所以传统做法我们会准备很多测试用例输入一个 Input然后对比 Output 是否符合预期。这是一个非常直观且正确的做法。但是在 Agent 里面这件事变得很难。第一个原因是因为 Agent 本身有一个很大的特性你输入同一个问题 10 次Agent 给出的结果可能每次都不一样。为什么会这样呢这主要受以下四个因素的影响模型随机性受模型本身的随机性影响以及 Temperature 参数带来的随机性。上下文变化对话的上下文可能会发生细微变化。工具返回结果变化调用的工具返回结果可能会变。比如调用探测状态的工具状态本身就在变或者订机票、酒店这些工具每时每刻返回的结果可能都不一样。Runtime 因素运行时环境中的一些因素比如时间会发生变化。这些因素叠加最终导致 Agent 的运行结果每次都有区别。所以只测一次很有可能存在 “测人品” 的情况运气好的情况就会得到好的结果运气不好结果就很糟糕。但如果你能够去测 10 次表现都还不错那才可能说 Agent 本身的能力达标了。这也说明了传统的测试方法在 Agent 状态下很难去复刻和复用。第二个原因就是多轮交互带来的 “蝴蝶效应”。举个例子扔一次硬币正面、反面的概率各是 50%那你扔两次都是正面的概率就是 50% × 50%也就是 25%。如果你要扔 10 次都是正面那就是 50% 的 10 次方这个概率会越来越低。同理在 Agent 的多轮对话中如果每一步模型的准确率是 90%那么到了第十步整体正确的概率就是 90% 的 10 次方。你看这就很容易出现错误累积。所以在多轮对话的状态下如果评测机制设计得不好很有可能导致最后根本得不出一个正确、理想的结果。二、Agent 评测核心概念拆解在深入探讨具体的评测方法之前有几个核心概念我们需要先捋清楚。理解这些术语是构建有效评测体系的基础下图是 Anthropic 官方的 Agent 评测所需的组件图。1. Task任务这是 Agent 所要完成的最核心内容。比如用户的问句是 “请帮我订一张机票”那么 Agent 的 Task 就是要去完成 “订机票” 这件事情。而订机票的最终达成状态就是该任务的最终结果。2. Trial试验指单次运行的试验过程。如果只跑一次成功率可能偶发性很强也就是前面说的 “测人品”。但如果我们跑 10 次或 100 次 Trial计算这 10 次或 100 次试验的平均成功率得到的结果会更有说服力也更稳定。3. Grader评分器Grader 是一个用于评估的模块它可能是一个大模型也可能是一套固定的规则代码。它的作用是给某个模块或者端到端的流程打分。有了这个分数我们才能量化 Agent 的效果而不是凭感觉说 “好” 或 “不好”。4. Trajectory轨迹轨迹也有的地方叫 Trace 或者 Transcript。它指的是 Agent 整个运行过程的全部链路记录通常包括模型的思考过程Thought、工具调用的过程、工具返回的结果、模型基于工具返回结果进行的进一步推理和思考、最终输出的 Response 结论。而且查看 Trajectory 能帮我们定位问题出在哪一步是 Debug 的重要依据。5. Outcome结果Outcome 就是 Agent 真正运行完之后的结果。这里需要注意Outcome 包含两个层面响应内容Response比如我问一个问题答案是什么或者模型口头告知是否成功失败这些能从回复中直接看出来。状态变化State Change这才是更本质的结果。比如我要去订票模型可能在 Response 里说 “已完成任务”但这不一定代表真的成功了。我必须去检查我的订单列表里有没有这张票票有没有真正订下来。这种实际环境中的状态才是最终的 Outcome。6. Harness 与 Model我们到底该测谁我们知道 Agent 领域比较火的一个公式Agent Model Harness。很多时候人们在评估一个 Agent 时会认为本质上是在评估大模型LLM。这个观点对也不完全对为什么说 “对”因为在整个过程中只有大模型是真正具备智能的部分也是随机性最强、最不可控的部分。我们评价一个 Agent 效果好不好很大程度上确实是在评估这个大模型的智能性或者说它做决策的准确度。为什么说 “不完全对”因为现在的 Agent 架构越来越复杂除了模型本身Harness也就是包裹模型的那层框架逻辑也变得非常厚重。Harness 不仅仅是简单的调用接口它包含了Context上下文的组装逻辑、Memory记忆的设计与管理、Compact压缩和 Summary总结的过程、工具的裁剪与路由策略等等。这些环节都会极大地影响 Agent 的最终表现。所以Agent 的效果不单单是 Model 本身的问题它是整个 Runtime 环境中各种组件集体的结果。因此当我们对 Agent 进行评测的时候不仅仅是在测 Model更多时候是在评估这个 Harness 的设计质量最终就是 Harness 与 Model 的配合效果。当然有时候我们也会去固定 Harness去测试不同 Model 在同一套 Harness 框架下的表现这也是评测的一个重要维度。但无论如何Harness 和 Model 都是我们需要去重点关注进行评测的对象。三、Agent 评测的尺子聊了解完这些基本的概念之后接下来我们重点聊聊 “Agent 评测的尺子”也就是 Grader评分器或者叫 Judger裁判。在 Agent 的评测体系中Grader 是那个 “判卷老师”。目前主流的 Grader 主要有三种类型它们各有优劣适用场景也完全不同。1. Code-based / Rule-based基于代码或规则这是第一种也是最传统的一种。它通过预先写好的代码逻辑或固定规则来进行评判。这种 Grader 非常适合那些结果确定、有标准答案的任务。比如我有一个文本分类问题要把一段文本分为几类。我可以预先建立一个 Benchmark知道每一个 Query 对应的正确 Label 是什么。当模型返回结果后只需要一段代码判断模型的输出是否和这个 Label 完全匹配。如果匹配得 1 分如果不匹配得 0 分。跑 100 个 Case看总分是多少满分 100 分能拿多少分一目了然。如果是多分类任务也可以设计成 “分对几类得几分”或者按比例算分。这种方案的优点是成本最低、速度最快、结果最确定没有随机性今天测和明天测结果一样但缺点也很明显适用范围很窄。只能用于那些逻辑固定、非黑即白的场景。一旦涉及语义理解或复杂逻辑它就无能为力。2. Model-based / LLM as Judge基于大模型第二种也是目前 Agent 评测中最主流的方式叫做 LLM as Judge。简单来说就是让大模型来当裁判参与评判过程。为什么需要它因为很多 Agent 的任务很难用简单的规则来定义。举个例子我让 Agent 调用一个天气查询工具返回我当地的天气。我要判断 “天气对不对”靠规则很难写因为天气数据是动态的模型的回复是不固定的。我要判断 “模型有没有调工具”、“调用的工具对不对”、“回复是否依据了工具返回的结果”这些都需要语义层面的理解。这时候就可以引入另一个大模型作为 Judger裁判。我们可以设计一套 Prompt让裁判模型去评估工具调用是否正确给分项 A最终回复是否准确反映了工具返回的信息给分项 B通过这种方式它可以给出一个综合分值。这种方案的优点就是适用面广大部分 Agent 的返回结果都是复杂的、非结构化的LLM 能够理解语义判断动作是否完成准确度比纯规则高得多。缺点也很明显成本高、速度慢每次评测都要调用大模型生成 Token。而且存在随机性这是个大坑即使是同一个问题、同样的回答你用同一个裁判模型测两遍它给出的分数可能会有波动。所以Model-based 的结果往往不够稳定可能需要多次取平均。3. Human-based基于人工标注第三种就是找人也就是人工评估。通常我们会找领域专家来进行判断这可以说是一种 “黄金标准”Gold Standard。这种方案的优点是质量最高最符合人类的真实感官和预期。对于那种极其复杂、连 LLM 都判断不准的场景人是最靠谱的。但缺点也非常多比如成本极高请专家是要花钱的速度极慢人工标注的效率远低于机器标准对齐难这也是人工标注最大的痛点不同的人对同一个结果的看法可能不同你需要花费大量精力去拉齐标注标准Calibration确保张三和李四打分的尺度是一致的。三种 Grader 对比维度Code-basedModel-basedHuman-based成本最低中等最高速度最快较慢最慢确定性最高 (无随机性)中等 (有波动)高 (但需对齐)适用范围窄 (固定逻辑)宽 (语义 / 复杂逻辑)最广 (所有场景)主要痛点无法处理模糊语义结果不稳定、成本高标准难统一、效率低Code-based不用拉齐标准代码和规则定出来是什么样就是什么样。Model-based如果用同一个模型、同一段 Prompt标准基本统一只是受模型随机性影响有点波动。Human-based最难的就是人与人之间的标准平衡和对齐。四、业界经典评测方法及 BenchmarkAgent 分为三大类操作型 Agent、对话型 Agent、编程类 Agent操作型 AgentAction-oriented AgentsAgent 的本质就是 “代理”核心目的是帮用户完成任务。而操作类 Agent 一般是最复杂的比如 Computer Use电脑操作、Browser Use浏览器操作等这类 Agent。它们需要基于视觉去访问网站获取内容或者操作你电脑上的软件、甚至整个操作系统来拿到结果。针对这种复杂场景介绍几个业界比较有代表性的 Benchmark。1. AgentBenchAgentBench 是由清华大学提出的一个 Benchmark。它涵盖了大概 8 种数据集包括操作系统、数据库、知识图谱甚至还有一些具身智能相关的场景。因为它偏向于 **“运行态” 的评测 **所以它不看你生成的代码写得漂不漂亮也不评判代码本身的语法对错。它直接运行代码看返回的结果是否符合预期。案例数据库查询任务请查询数据库中所有年龄大于30岁的员工。Select name from staff where age 30评判看跑出来的结果集员工名字、数量等是否和 Benchmark 预设的标准结果完全对上。如果对上了就认为正确。除了数据库这个 Benchmark 还有卡牌游戏、具身智能等。比如在具身智能场景下任务是 “把苹果放进冰箱”。它最后只看环境状态苹果是不是真的在冰箱里如果是就算成功。2. τ-Bench在客服领域有个 Benchmark 叫 τ-Bench。它的场景更贴近真实的客服业务用户会有一个具体问题且带有操作属性。案例“我要订明天的票” 或者 “我要订某个特定航班的票”。评判Outcome 导向模型不仅要看回复说了什么它会去后台数据库里检索看是不是真的生成了这个订单。只要订单真正落库了就认为是正确的。它关注的不是 Response 里的文字游戏而是真实的业务结果。同时它还引入了业务规则合规性检查这是 τ-Bench 的一个亮点。它不仅看结果还看过程是否符合业务逻辑。案例某些机票在特定情况下是不能退票的或者只能改签。评判如果 Agent 在不能退票的情况下执行了退票操作即使操作成功了它在 τ-Bench 里也会被判为失败。因为这违反了业务规则存在合规性问题。所以τ-Bench 不仅测 “能不能做成”还测 “做得对不对合规”。3. AgentBoard另一个值得关注评测 Benchmark 是香港科技大学推出的 AgentBoard。它的思路有点像我们小时候做数学题老师批改作业时不仅最终答案对不对还要看你的解题步骤。AgentBoard 主要考察两个方面最终结果检查State-based Verification这和前面的类似看最终的 Outcome 对不对。比如 Response 是否正确或者最终的环境状态是否发生了预期变化比如苹果是否进了冰箱票是否订成功。过程率检查Progress Rate / Trajectory Check这是 AgentBoard 的特色。它会为每个任务设定一组有序的 Subgoal子目标 / 中间状态。在评测时它会拿着 Agent 运行的 Trajectory轨迹去和这些中间状态逐一比对。案例任务是“买一个橙色、256G 的 iPhone 17。”AgentBoard 会拆解成以下步骤进行打分是否搜索了 “iPhone 17” 关键词是否 Click 了正确的产品页在选项里是否选择了 “Orange” 颜色是否选择了 “256G” 内存最终是否点击了 “Buy” 按钮评判如果你每一步都做对了得满分如果你跳过了中间步骤直接出结果或者某一步选错了颜色但最后误打误撞买对了分数就会受影响。这就好比数学题你可能答案对了但过程全错那也拿不到高分或者过程对了一半答案错了也能拿部分步骤分。总结AgentBench 重在运行结果代码跑通、数据对上就行τ-Bench 重在业务落地 合规不仅要有订单还要符合业务规则AgentBoard 重在过程 结果像改数学卷子一样既看答案也对步骤。这三种方式分别代表了不同维度对操作型 Agent 的考量大家在设计自己的评测体系时可以根据业务需求参考借鉴。对话型 Agent接下来我们看第二类也是非常常见的类型就是对话类 AgentConversational Agents。这类 Agent 的场景主要可以分为两种常见形态AI 助手比如我们常用的豆包、ChatGPT 等。你给它一个问题它可以直接利用模型自身的知识回答也可以通过 RAG 去搜索实时新闻或资料来回答还可以调用各种工具比如让它画张图、查个天气、算个数学题等。这些都是典型的对话驱动的场景。智能客服比如各大公司的智能客服这类场景稍微复杂一点。它同样基于用户提问可能直接调用知识库里面的固定话术回答也可能需要先查询用户的具体状态如订单状态、账户情况进行诊断后再回答甚至需要调用工具去执行操作。虽然逻辑上跟 AI 助手很像但它对准确性和合规性的要求更高。对于这类 Agent最直接的评估方式就是看输出的 Outcome最终结果。既然用户问的是一个问题我们就看这个回答是否真正意义上解答了这个问题。无论是纯模型生成的回答还是调用了工具后的回答都可以用这套逻辑来评估。但是这类的难点在于答案的不唯一性。因此我们可以考虑建立一个 Benchmark缓存很多用户真实的问题和对应的 “标准答案”。但这个标准答案往往也只能是一个参考答案。案例莎士比亚是哪里人Agent 回答A 答案“莎士比亚是英国人。”B 答案“莎士比亚出生于英国中部的沃里克郡斯特拉特福镇。”C 答案“莎士比亚是欧洲人生活在文艺复兴时期。”其实这三个回答其实都是对的只是粒度不同。如果我们的 Benchmark 里只存了一个 “英国”那模型 B 和 C 可能会被误判。解法也有两种多参考答案在 Benchmark 里为同一个问题预设多个可能的正确答案。LLM as Judge让大模型来判断语义一致性。只要模型说的是 “欧洲”、“英国” 或者具体的 “斯特拉特福镇”都算对。这也是一种比较简单直观的评测思路。下面介绍两个典型的 Benchmark。1. GAIA (General AI Assistants Benchmark)GAIA 是由 MetaFacebook联合多家机构推出的一个基准测试。它的理念很有趣专门挑选那些 “人类觉得简单但 AI 觉得难” 的问题。评测方法关键词匹配Keyword MatchingGAIA 的答案通常是一个具体的关键词或数值。它的评判规则比较 “粗暴” 但有效只要你的回答里包含了这个关键词就算对。常识类还是问莎士比亚出生地的问题。只要答案里提到 “英国” 或 “欧洲”就算通过。虽然有点宽泛但它通过放宽匹配规则来保证准确性。工具 / 文件处理类给你一个 Excel 附件问“这三列数据中哪一列的增长率最高负责人的姓名是谁”Benchmark 里预设了正确的数字和负责人的名字。不管你的回答啰嗦什么样只要里面提到了那个正确的数字和负责人的名字它就认为你是对的。这种方法的优点是非常直观、易于自动化适合大规模快速评测。2. τ²-Benchτ²-Bench 可以看作是前面提到的 τ-Bench 的一个进阶版。虽然它也涉及操作但我更倾向于把它归类在对话类因为它更偏向于客服领域的排查与结论。但是它除了对话之外还引入了对工具调用诊断能力的深度评估主要考察三个维度a. 状态一致性State Consistency状态一致性主要是看 Agent 对目前状态的判断准不准。案例用户欠费停机了。评判Agent 调用工具查询后返回的结果必须是 “欠费停机”。如果工具返回是对的但 Agent 理解错了或者 Agent 查出来的状态和实际不符那就扣分。这一步确保 Agent “看清” 了问题。b. 策略遵循性Policy Adherence这个主要是看 Agent 有没有按照合规的流程去回答或操作。案例某些敏感操作需要先验证身份或者某些问题必须先安抚情绪再给方案。如果跳过了必要步骤即使最后解决了问题也可能被判不合格。c. 最小代价原则Minimum Cost Principle这是 τ²-Bench 非常创新并且值得参考的一个点。它不仅要你解决问题还要看你用的方案是不是最优解是不是成本最低。案例用户说“我家网络连不上了。”方案方案 A引导用户重启路由器。成本低耗时短用户可自行操作方案 B直接派工程师上门维修。成本高耗时长评判虽然方案 B 也能解决问题网络确实通了但在 τ²-Bench 看来这属于 “用核武器打蚊子”。方案 B 的成本远高于方案 A因此会被判定为非最优解甚至可能被扣分。总结一致性是判断状态对不对合规性是判断流程走得对不对经济性是不是用了最小代价的最优方案这三个维度对于构建一个高质量、拟人化且具备商业价值的客服 Agent 来说是非常好的参考标准。编程类 AgentCoding Agents除了操作类和对话类还有一类非常硬核的 Agent编程类 Agent比如 Claude Code、Codex以及泛化除的如 OpenClaw、Hammer Agent 这些最新的、能处理复杂长任务的 Agent。这类 Agent 的评测难度更大因为它们的任务链路长、依赖多。虽然我们也可以沿用前面提到的 Outcome结果或 Trajectory轨迹检查但针对这种 “复杂 Agent”业界已经出现了一些新的、更具针对性的 Benchmark。基于公式Agent Model Harness有两种正交的评测手段固定 Harness 测 Model固定 Model 测 Harness1. ClawBench固定 Harness评测不同 Model 的能力核心逻辑固定住 Agent 的框架也就是 Harness比如固定使用 OpenClaw 这套架构然后替换底层的大模型。通过这种方式去判断在同样的框架下哪个大模型完成复杂任务的效果更好。评测场景ClawBench 覆盖了很多真实场景包括日常生活、娱乐爱好、内容创作、评分投票、旅行规划、教育、办公等等。评判标准看 “做” 得对不对而不是 “说” 得对不对。它不关心 Agent 生成的文本漂不漂亮只关心任务是否真正完成Outcome。如何工作a. 沙箱环境它为每个任务提供一个独立的沙箱里面运行着真实的浏览器或操作系统。b. 过程录制它会全程录制 Agent 的运行过程包括对话、鼠标动作、浏览器截图、最终返回结果等。c. 回放评估评测时系统会回放整个过程结合视觉信息和状态变化来打分。具体的评判流程分为两步第一步Schema 匹配检查。判断 Agent 最终发出的请求或产生的数据结构是否符合预设的 Schema。如果连格式都对不上说明中间已经出错直接判定失败。第二步LLM as Judge。如果通过了第一步再引入大模型作为裁判结合截图和上下文判断最终结果是否正确、任务是否达成。此外ClawBench 还会特别关注安全性评估 Agent 在执行过程中是否有违规或危险操作。2. HarnessBench固定 Model评测不同 Harness 的效果当你想要比较接入同样的模型到底是 Claude Code 好还是 OpenClaw 好或者是 Codex 好就需要反过来固定模型评测 Harness这也是 ClawBench 团队研发的另一个 Benchmark。它的核心逻辑是固定住底层的大模型比如都用 Claude Opus 4.8然后替换上层的框架Harness。通过这种方式剥离模型智能的影响纯粹去评估不同框架Harness在上下文管理、工具调用逻辑、记忆压缩等方面的设计优劣。总结对比ClawBench测的是同样的车架Harness换个引擎Model谁跑得快。HarnessBench测的是同样的引擎Model换个车架Harness谁更稳、更高效。这两个 Benchmark 是正交的共同构成了对复杂 Agent 的全面评估体系。它们最终看的都是复杂任务下的最终效果Outcome。五、通用评测工具OpenJudge出自 AgentScope 的 OpenJudge。它本质上是一个高度封装的 Grader评分器。它的特点是开箱即用。OpenJudge 的设计比较全面它不仅仅看结果而是从三个维度对 Agent 进行评估Final Response最终结果这是端到端的评估。主要看 Agent 最后给出的答案是否正确、是否真正回答了用户的问题、有没有产生幻觉Hallucination、以及是否包含有害或不安全的信息。Single Step单步表现这是对中间过程的微观检查。在每一轮交互中它会评估工具选择Agent 选的工具对不对调用成功工具调用是否成功执行Planning规划当前的步骤规划是否合理Skill/Memory技能调用是否准确记忆提取是否相关Reflection反思Agent 的自我反思逻辑是否成立Trajectory整体轨迹这是对全流程的宏观审视。它会判断整个执行链路是否正确Agent 是不是按照最优或预期的路径去完成任务的整个轨迹的逻辑是否通顺、高效对于大多数通用场景OpenJudge 内部已经预设好了一套完善的评分标准和 Prompt。你不需要做任何配置直接把它接入你的评测流程就能跑起来。这对于快速验证 Agent 能力非常方便。但是如果你觉得默认的开放评判标准不够准或者不符合你的业务特性你也可以考虑自定义 Grader。你可以修改评判 Prompt调整评分权重甚至引入特定的业务规则让它更贴合你的具体场景。六、Agent 评测体系的设计及稳定性现有的 Benchmark大多是面向通用场景或者特定公开场景主要用来给公众展示模型或 Agent 的效果。如果你是在自己的业务里落地 Agent 评测可以参考成熟 Benchmark 思路定制自己的评测标准。评估内容分为五大类端到端的 Outcome多轮的对话或者推理最终看结果对不对。Single Turn Outcome单轮交互的效果好不好。Trajectory 里的执行细节执行路径合不合理。中间结果检查拿到一些中间关键步骤的输出进行细查。State 状态最后完成状态是否正确。关键就在于针对你的场景设定一套合适的指标。强烈建议设计一个多维度指标体系。也就是说你既要看端到端的结果也要看单轮的表现还要关注过程细节。这样做的好处是可以一眼看出整体结果是好是坏。如果结果不好可以拆解出来看到底是中间哪个步骤出了问题。反过来如果你对比两套 Harness 或者两个 Model在过程很复杂并且状态经常变的情况下很容易发现端到端的 Outcome 有波动但中间环节有提升这也证明你的效果相比原来是有进步的。如果 Outcome 变好了但某些中间结果变差了你就可以深入去挖掘核心原因发现这里面其实还有很多优化的空间。另外非常建议多次运行 Trial试验。尽量不要只跑一次而是多跑几次取平均值。为什么因为 Agent 本身输出是不稳定的。如果你用了 LLM as Judge模型在评判的时候也是不稳定的。这就导致指标会左右摇摆。通过多次实验取平均可以有效降低噪音污染。甚至我们可以借鉴一些行业专业比赛的做法去掉一个最高分去掉一个最低分剩下的取平均分。去掉极值的目的就是为了降噪排除一些异常情况。跑的轮数越多出来的效果可能就越准越能真实衡量好坏。在 Trial 方面有两个常用指标也是很多论文里会用到Passk宽松指标意思是跑 k 次只要至少 1 次成功就认为通过了。这是一个比较宽松的指标。Pass^k严格指标意思是跑 k 次必须全部成功才算通过。类似于 Pass 的 k 次方。只要有一轮断了、不成功我就认为这次是不成功的。这是一个非常严格的指标。这两个的值往往差异很大。比如你的 Pass10 可能是 90% 多但你的 Pass^10 可能只有个位数。这种情况下可以通过计算 F1 值让两个指标结合起来算出一个平衡后的分数。这样往往比单一指标更客观。当然不得不承认Agent 的评测和构建成本都蛮高的。尤其是现在一些复杂任务评测一把经常要好几个小时才能跑完一轮还要再去算平均成本确实不低。但在 AI 时代这可能是没办法避免的投入。如果是个人场景Agent 的效果从体感上大概就能判断个差不多。但如果是企业级的 Agent拿到一个量化的评测指标必要性还是非常大的。当然如果模型的评测结果始终不稳定我们还有最后的 “杀手锏”让人进来评估。这也是一种策略但前提是拉通评测标准否则人与人的评测结果也很难一致。七、Agent 评测落地完整路径建立 Benchmark找到一些典型的 Case 构建成评测集。构建 Ground Truth预设标准答案如果你不构建 GT那就只能纯靠 LLM Judge 了但最好还是有标准答案否则 Judge 也会漂移。保证分布真实性Benchmark 集合要能反映你真实的业务分布。不然你测的问题都很偏门实际使用时问题却很常规那评测就不客观。构建稳定环境尽可能包含一些工具的 Mock或者把工具的运行结果缓存好让上下文干净一些减少外部干扰。设计 Grader评分器决定是用 Code-based代码规则、Model-based模型打分还是人工标注。执行与优化真正去跑批多做多次 Trial取平均降低偶发概率的影响最终完成一个比较复杂的评测。评测这块可重可轻如果注重了做可以做的非常精细做得轻也可以快速验证。这完全取决于你的场景需求和要求灵活调整即可。八、全文总结Agent 的评测确实是一个既复杂又充满挑战的领域。它不像传统软件测试那样有绝对的非黑即白更多的是在不确定性中寻找确定性的过程。从 Benchmark 的设计、Ground Truth 的构建到多维度指标的拆解再到通过多次 Trial 来对抗模型的不稳定性每一步都需要我们结合具体的业务场景去权衡和取舍。在实际落地中大家可能会遇到各种各样的 “坑”比如成本太高跑不动、LLM Judge 打分飘忽不定、或者中间过程难以量化等等。这些都不是靠一套标准答案就能解决的而是需要我们在实践中不断去摸索、迭代。评测本身不是目的通过评测发现短板、优化 Harness、提升模型决策能力才是我们构建高质量 Agent 的最终目的。
