Agent 评测的基本概念与经典方法

背景

现如今想要搭建一个 Agent，其实并不是很复杂，已经有非常多成熟的框架和架构选型。但是，很多人会遇到同一个问题：Agent 构建好之后，到底应该怎么评测？

Agent 的评测的确是一个比较复杂的事情，可以算比较大的一个 “痛点” 了。今天重点聊聊 Agent 评测这件事。因为在做 Agent 的开发和落地的过程中，评测环节实打实会有很多坑。

一、为什么传统测试方法在 Agent 上失效了？

首先我们来讨论一个核心话题：传统的软件测试方法，在 Agent 时代很多都失效了。

虽然我们现在也有一些模块化的评测逻辑，比如端到端地去评测整个 Agent，或者去拆解里面的一些细节逻辑，这些思路本身都是可行的。但是，传统测试在 Debug 时有一个前提，那就是确定性：在输入不变的情况下，输出是不会变的。

所以，传统做法我们会准备很多测试用例，输入一个 Input，然后对比 Output 是否符合预期。这是一个非常直观且正确的做法。但是在 Agent 里面，这件事变得很难。

第一个原因，是因为 Agent 本身有一个很大的特性：你输入同一个问题 10 次，Agent 给出的结果可能每次都不一样。

为什么会这样呢？这主要受以下四个因素的影响：

1. 模型随机性：受模型本身的随机性影响，以及 Temperature 参数带来的随机性。
2. 上下文变化：对话的上下文可能会发生细微变化。
3. 工具返回结果变化：调用的工具返回结果可能会变。比如调用探测状态的工具，状态本身就在变；或者订机票、酒店，这些工具每时每刻返回的结果可能都不一样。
4. 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-based：不用拉齐标准，代码和规则定出来是什么样就是什么样。
• Model-based：如果用同一个模型、同一段 Prompt，标准基本统一，只是受模型随机性影响有点波动。
• Human-based：最难的就是人与人之间的标准平衡和对齐。

四、业界经典评测方法及 Benchmark

Agent 分为三大类：操作型 Agent、对话型 Agent、编程类 Agent

操作型 Agent（Action-oriented Agents）

Agent 的本质就是 “代理”，核心目的是帮用户完成任务。而操作类 Agent 一般是最复杂的，比如 Computer Use（电脑操作）、Browser Use（浏览器操作）等这类 Agent。它们需要基于视觉去访问网站获取内容，或者操作你电脑上的软件、甚至整个操作系统来拿到结果。

针对这种复杂场景，介绍几个业界比较有代表性的 Benchmark。

1. AgentBench

AgentBench 是由清华大学提出的一个 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 主要考察两个方面：

1. 最终结果检查（State-based Verification）

   这和前面的类似，看最终的 Outcome 对不对。比如 Response 是否正确；或者最终的环境状态是否发生了预期变化，比如苹果是否进了冰箱，票是否订成功。

2. 过程率检查（Progress Rate / Trajectory Check）

   这是 AgentBoard 的特色。它会为每个任务设定一组有序的 Subgoal（子目标 / 中间状态）。在评测时，它会拿着 Agent 运行的 Trajectory（轨迹）去和这些中间状态逐一比对。

案例：任务是：“买一个橙色、256G 的 iPhone 17。”AgentBoard 会拆解成以下步骤进行打分：

• 是否搜索了 “iPhone 17” 关键词？
• 是否 Click 了正确的产品页？
• 在选项里，是否选择了 “Orange” 颜色？
• 是否选择了 “256G” 内存？
• 最终是否点击了 “Buy” 按钮？

评判：如果你每一步都做对了，得满分；如果你跳过了中间步骤直接出结果，或者某一步选错了颜色但最后误打误撞买对了，分数就会受影响。这就好比数学题，你可能答案对了，但过程全错，那也拿不到高分；或者过程对了一半，答案错了，也能拿部分步骤分。

总结

• AgentBench 重在运行结果，代码跑通、数据对上就行；
• τ-Bench 重在业务落地 + 合规，不仅要有订单，还要符合业务规则；
• AgentBoard 重在过程 + 结果，像改数学卷子一样，既看答案也对步骤。

这三种方式，分别代表了不同维度对操作型 Agent 的考量，大家在设计自己的评测体系时，可以根据业务需求参考借鉴。

对话型 Agent

接下来，我们看第二类，也是非常常见的类型，就是对话类 Agent（Conversational 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 是由 Meta（Facebook）联合多家机构推出的一个基准测试。它的理念很有趣：专门挑选那些 “人类觉得简单，但 AI 觉得难” 的问题。

• 评测方法：关键词匹配（Keyword Matching）

  GAIA 的答案通常是一个具体的关键词或数值。它的评判规则比较 “粗暴” 但有效：只要你的回答里包含了这个关键词，就算对。

• 常识类：

  还是问莎士比亚出生地的问题。只要答案里提到 “英国” 或 “欧洲”，就算通过。虽然有点宽泛，但它通过放宽匹配规则来保证准确性。

• 工具 / 文件处理类：

  给你一个 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 来说，是非常好的参考标准。

编程类 Agent（Coding Agents）

除了操作类和对话类，还有一类非常硬核的 Agent：编程类 Agent，比如 Claude Code、Codex，以及泛化除的如 OpenClaw、Hammer Agent 这些最新的、能处理复杂长任务的 Agent。

这类 Agent 的评测难度更大，因为它们的任务链路长、依赖多。虽然我们也可以沿用前面提到的 Outcome（结果）或 Trajectory（轨迹）检查，但针对这种 “复杂 Agent”，业界已经出现了一些新的、更具针对性的 Benchmark。

基于公式：Agent = Model + Harness，有两种正交的评测手段：

1. 固定 Harness 测 Model
2. 固定 Model 测 Harness

1. ClawBench：固定 Harness，评测不同 Model 的能力

核心逻辑：固定住 Agent 的框架，也就是 Harness，比如固定使用 OpenClaw 这套架构，然后替换底层的大模型。通过这种方式，去判断在同样的框架下，哪个大模型完成复杂任务的效果更好。

• 评测场景：ClawBench 覆盖了很多真实场景，包括日常生活、娱乐爱好、内容创作、评分投票、旅行规划、教育、办公等等。

• 评判标准：看 “做” 得对不对，而不是 “说” 得对不对。它不关心 Agent 生成的文本漂不漂亮，只关心任务是否真正完成（Outcome）。

• 如何工作？

  a. 沙箱环境：它为每个任务提供一个独立的沙箱，里面运行着真实的浏览器或操作系统。

  b. 过程录制：它会全程录制 Agent 的运行过程，包括对话、鼠标动作、浏览器截图、最终返回结果等。

  c. 回放评估：评测时，系统会回放整个过程，结合视觉信息和状态变化来打分。

具体的评判流程分为两步：

1. 第一步：Schema 匹配检查。判断 Agent 最终发出的请求或产生的数据结构，是否符合预设的 Schema。如果连格式都对不上，说明中间已经出错，直接判定失败。
2. 第二步：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 思路，定制自己的评测标准。

评估内容分为五大类：

1. 端到端的 Outcome：多轮的对话或者推理，最终看结果对不对。
2. Single Turn Outcome：单轮交互的效果好不好。
3. Trajectory 里的执行细节：执行路径合不合理。
4. 中间结果检查：拿到一些中间关键步骤的输出进行细查。
5. State 状态：最后完成状态是否正确。

关键就在于，针对你的场景，设定一套合适的指标。强烈建议设计一个多维度指标体系。也就是说，你既要看端到端的结果，也要看单轮的表现，还要关注过程细节。这样做的好处是：

• 可以一眼看出整体结果是好是坏。
• 如果结果不好，可以拆解出来看，到底是中间哪个步骤出了问题。
• 反过来，如果你对比两套 Harness 或者两个 Model，在过程很复杂并且状态经常变的情况下，很容易发现端到端的 Outcome 有波动，但中间环节有提升，这也证明你的效果相比原来是有进步的。
• 如果 Outcome 变好了，但某些中间结果变差了，你就可以深入去挖掘核心原因，发现这里面其实还有很多优化的空间。

另外，非常建议多次运行 Trial（试验）。尽量不要只跑一次，而是多跑几次取平均值。为什么？

因为 Agent 本身输出是不稳定的。如果你用了 LLM as Judge，模型在评判的时候也是不稳定的。这就导致指标会左右摇摆。通过多次实验取平均，可以有效降低噪音污染。甚至我们可以借鉴一些行业专业比赛的做法：去掉一个最高分，去掉一个最低分，剩下的取平均分。去掉极值的目的就是为了降噪，排除一些异常情况。跑的轮数越多，出来的效果可能就越准，越能真实衡量好坏。

在 Trial 方面有两个常用指标，也是很多论文里会用到：

1. Pass@k（宽松指标）：意思是跑 k 次，只要至少 1 次成功，就认为通过了。这是一个比较宽松的指标。
2. Pass^k（严格指标）：意思是跑 k 次，必须全部成功，才算通过。类似于 Pass 的 k 次方。只要有一轮断了、不成功，我就认为这次是不成功的。这是一个非常严格的指标。

这两个的值往往差异很大。比如，你的 Pass@10 可能是 90% 多，但你的 Pass^10 可能只有个位数。这种情况下可以通过计算 F1 值，让两个指标结合起来，算出一个平衡后的分数。这样往往比单一指标更客观。

当然，不得不承认，Agent 的评测和构建成本都蛮高的。尤其是现在一些复杂任务，评测一把经常要好几个小时才能跑完一轮，还要再去算平均，成本确实不低。但在 AI 时代，这可能是没办法避免的投入。

如果是个人场景，Agent 的效果从体感上大概就能判断个差不多。但如果是企业级的 Agent，拿到一个量化的评测指标，必要性还是非常大的。当然，如果模型的评测结果始终不稳定，我们还有最后的 “杀手锏”，让人进来评估。这也是一种策略，但前提是拉通评测标准，否则人与人的评测结果也很难一致。

七、Agent 评测落地完整路径

1. 建立 Benchmark：找到一些典型的 Case 构建成评测集。
2. 构建 Ground Truth：预设标准答案；如果你不构建 GT，那就只能纯靠 LLM Judge 了，但最好还是有标准答案，否则 Judge 也会漂移。
3. 保证分布真实性：Benchmark 集合要能反映你真实的业务分布。不然你测的问题都很偏门，实际使用时问题却很常规，那评测就不客观。
4. 构建稳定环境：尽可能包含一些工具的 Mock，或者把工具的运行结果缓存好，让上下文干净一些，减少外部干扰。
5. 设计 Grader（评分器）：决定是用 Code-based（代码规则）、Model-based（模型打分），还是人工标注。
6. 执行与优化：真正去跑批，多做多次 Trial，取平均，降低偶发概率的影响，最终完成一个比较复杂的评测。

评测这块可重可轻，如果注重了做，可以做的非常精细；做得轻，也可以快速验证。这完全取决于你的场景需求和要求，灵活调整即可。

八、全文总结

Agent 的评测确实是一个既复杂又充满挑战的领域。它不像传统软件测试那样有绝对的非黑即白，更多的是在不确定性中寻找确定性的过程。从 Benchmark 的设计、Ground Truth 的构建，到多维度指标的拆解，再到通过多次 Trial 来对抗模型的不稳定性，每一步都需要我们结合具体的业务场景去权衡和取舍。

在实际落地中，大家可能会遇到各种各样的 “坑”，比如成本太高跑不动、LLM Judge 打分飘忽不定、或者中间过程难以量化等等。这些都不是靠一套标准答案就能解决的，而是需要我们在实践中不断去摸索、迭代。

评测本身不是目的，通过评测发现短板、优化 Harness、提升模型决策能力，才是我们构建高质量 Agent 的最终目的。