揭秘 AI 代理的评估 - 多种Agent的评估方法

前言：

在上一篇《Agent的评估》中，概述都是宏观方向的评估概念，没有具体的使用例子，本篇文章具体到几种类型的Agent评估方法是什么、评估的角度是什么

分析参考来源：

文章链接：https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents
https://arxiv.org/abs/2406.12045
https://arxiv.org/abs/2506.07982
https://arxiv.org/abs/2504.12516
《Agent评估》：文章链接

一、评估编码 Agent 的方法

编码 Agent 的主要任务：编写、测试和调试代码，像人类开发者一样在代码库中检索浏览，所以编码 Agent 是依赖于明确指定的任务，根据这一点，我们可以知道：确定性评分器非常适合编码 Agent

🌴 第一方面的评估要点是：代码能否运行、测试是否通过

这里介绍两种编程基准

SWE-bench Verified
Terminal-Bench

1、Terminal-Bench 这个的理解就是：其不是修复单一的编译错误，而是完成整个编译过程，这个就是端到端的测试，从开始到结束，例如：部署 Web 应用、从零搭建 Mysql 数据库 2、SWE-bench Verified 是一种“单元测试”，常规的使用方法：
给 Agent 一个真实的问题
Agent 开始编写修复代码
运行测试套件，保证 Agent 编写的修复代码可以通过测试

🌴 第二方面的评估要点是：Agent 的工作过程是否合理高效

当你有了测试案例集｜测试函数来验证编码 Agent 执行的任务的结果的时候，评估编码 Agent 的工作过程也是很有用的，不仅要单一的评估测试结果是否通过，也要观察评估完成任务的过程是否合理以及优雅

这个时候有两种额外的评估方法

基于启发式规则的代码质量评估：也就是用代码规则来检查代码质量，而不是只看测试结果
- 代码的复杂度
- 代码的重复率
- 命名的规范
- 安全漏洞
- 性能问题
- 代码的可读性
基于模型的行为评估：用大模型去评估 Agent 的执行任务的中间过程，也就是行为

例如：任务 A - 查询数据库中的用户信息

AgentA 的做法：直接查询所有用户的信息，在内存中进行过滤 AgentB 的做法：用 where 语句条件查询用户信息，最后返回需要的数据

在这种情况下，虽然 A 与 B 都完成啦任务，但是 AgentB 其实是做得更好的，更符合规范的

🌟 结论：编码 Agent 的评估，要评估两个主要方向，编码 Agent 的执行结果和执行过程

案例：这是一个完整的案例，实际使用的时候可以动态调整，不必全部都有

yaml

task:
  id: "fix-auth-bypass_1" # 任务ID：修复认证绕过漏洞_1

  desc: "修复当密码字段为空时的认证绕过漏洞..."

  graders:  # 评分器
    - type: deterministic_tests  # 确定性测试
      required:
        - test_empty_pw_rejected.js    # 拒绝空密码的测试
        - test_null_pw_rejected.js     # 拒绝null密码的测试

    - type: llm_rubric  # LLM评分标准
      rubric: prompts/code_quality.md  # 代码质量评分提示词文件

    - type: static_analysis  # 静态代码分析
      commands:
        - eslint      # 代码风格检查
        - tsc         # TypeScript类型检查

    - type: state_check  # 状态检查
      expect:
        security_logs:
          event_type: "auth_blocked"  # 期望安全日志中有认证阻止事件

    - type: tool_calls  # 工具调用检查
      required:
        - tool: read_file
          params:
            path: "src/auth/*"  # 读取认证代码
        - tool: edit_file       # 编辑文件
        - tool: run_tests       # 运行测试

  tracked_metrics:  # 追踪指标
    - type: transcript  # 对话记录指标
      metrics:
        - n_turns          # 对话轮数
        - n_toolcalls      # 工具调用次数
        - n_total_tokens   # 总token消耗

    - type: latency  # 延迟指标
      metrics:
        - time_to_first_token     # 首token时间
        - output_tokens_per_sec   # 输出速度（tokens/秒）
        - time_to_last_token      # 总完成时间

二、评估对话 Agent 的方法

****

**可验证的最终状态结果和能够捕捉任务完成与互动质量**

🌴 第一方面的评估要点：可验证的最终状态，也就是对话 Agent 最终要完成的任务，例如：客服退款、修改收货地址、生成报价单等

🌴 第二方面的评估要点：相比其他类型 Agent 的独特的挑战：互动本身的质量也是你评估的一部分

例如：场景 - 客服退款

Agent A：

用户："我要退款"

Agent："订单号？"

用户："12345"

Agent："已退款"

任务完成但态度生硬

Agent B：

用户："我要退款"

Agent："很抱歉给您带来不便。请问是哪个订单呢？"

用户："12345"

Agent："我查到了您的订单，符合退款条件。我现在为您处理，预计3-5个工作日到账。还有其他需要帮助的吗？"

任务完成交互体验好

结论：所以对话 Agent 的评估标准是：最终状态验证 + 交互质量的评估

一个对话 Agent 是否有效的标准可以是多维度的：

用户的问题和诉求是否解决（状态检查）、
是否在 10 轮对话中完成（文本上下文的约束）、
语气是否恰当（LLM 来评估）

有两个多维度的测试基准，其模拟了零售支持和航空预订等领域的多轮交互，其中使用了一个 LLM 扮演用户角色，这两个测试基准：𝜏-Bench 及其后续版本τ2-Bench

一个测试评估案例，对话 Agent 处理沮丧用户的退款

yaml

graders: 
  # 1. LLM评分标准
  - type: llm_rubric
    rubric: prompts/support_quality.md  # 客服质量评分提示词文件
    assertions: # 列出来的评分的重点角度
      - "Agent对客户的沮丧表现出同理心"
      - "解决方案被清晰地解释"
      - "Agent的回复基于fetch_policy工具的结果"

  # 2. 状态检查
  - type: state_check
    expect:  # 期望的最终状态
      tickets:
        status: resolved      # 工单状态：已解决
      refunds:
        status: processed     # 退款状态：已处理

  # 3. 工具调用检查
  - type: tool_calls
    required:  # 必须调用的工具
      - tool: verify_identity              # 验证身份

      - tool: process_refund               # 处理退款
        params:
          amount: "<=100"                  # 金额必须 ≤ 100

      - tool: send_confirmation            # 发送确认

  # 4. 对话记录约束
  - type: transcript
    max_turns: 10  # 最大对话轮数：10轮

tracked_metrics:  # 追踪指标
  # 1. 对话记录指标
  - type: transcript
    metrics:
      - n_turns          # 对话轮数
      - n_toolcalls      # 工具调用次数
      - n_total_tokens   # 总token消耗

  # 2. 延迟指标
  - type: latency
    metrics:
      - time_to_first_token     # 首token时间
      - output_tokens_per_sec   # 输出速度（tokens/秒）
      - time_to_last_token      # 总完成时间

三、评估研究 Agent 的方法

研究 Agent 的主要任务是：

全面的搜索和研究
有良好的且正确的来源

并且不同领域的任务，评估的标准也是不一样的，例如：市场研究和技术调研是需要不同的标准

研究 Agent专家可能对综合是否全面存在分歧，真实情况会随着参考内容不断变化，而更长、更开放式的输出会为错误创造更多空间

**BrowseComp******

所以构建研究 Agent 的评估的一般方式是：组合多种评分器类型

基础性检查：检查验证每一个声明都有来源支持吗？
覆盖性检查：来源里面的关键信息都包含了吗？都使用了吗？
来源质量检查：引用的资料是否权威，不能因为在网络搜索排名第一就使用它

我们使用一个例子来说明这三种检查的主要方向：

研究类型的Agent的评估

四、评估计算机使用 Agent 的方法

计算机使用 Agent 通过与人类相同的界面与软件交互

屏幕截图
鼠标点击
键盘输入和滚动

而不是通过 API 或代码执行和软件交互，计算机 Agent 可以使用任何带有图像用户界面的程序

那么评估这种类型的 Agent，不仅仅是评估界面是否出现，还要评估软件后面的逻辑是否正确执行，例如：

WebArena 测试基于浏览器的任务，使用 URL 和页面状态检查来验证代理是否正确导航，同时对修改数据的任务进行后端状态验证（确认订单确实已下单，而不仅仅是确认页面出现了）
OSWorld 将此扩展到完整的操作系统控制，评估脚本在任务完成后检查各种产物：文件系统状态、应用程序配置、数据库内容和 UI 元素属性

🌟这一个设计思路非常重要，引用官方原文：

浏览器使用代理需要在 token 效率和延迟之间取得平衡。基于 DOM 的交互执行速度快但消耗大量 token，而基于屏幕截图的交互速度较慢但 token 效率更高。例如，当要求 Claude 总结维基百科时，从 DOM 中提取文本更高效。当在亚马逊上寻找新笔记本电脑保护套时，截图更高效（因为提取整个 DOM会消耗大量 token）。在我们的 Claude for Chrome 产品中，我们开发了评估方法来检查代理是否为每个场景选择了正确的工具。这使我们能够更快、更准确地完成基于浏览器的任务

如果要开发一个浏览器的 Agent，那么在执行的行为中可以考虑这个方向：操作 DOM 还是网页截图

如果网页的文本较多，那么直接读取 DOM 元素回更加的高校，并且信息密度很大，无用的网页标签会大大减少
如果网页的 DOM 很多，文本信息非常的分散，典型的就是电商网站，商品推荐任务，可以考虑截图，截图会更高效和清晰

五、总结

有两个指标有助于捕获这种细微的差异：

1、pass@k 衡量代理在 k 次尝试中至少获得一个正确解决方案的可能性。

🌟

pass@k案例

总共有 5 个任务，在 3 次机会里面至少成功一次的有 3 个任务，所以 pass@3 = 60%，可以注意到在任务三中，Agent 在第四次机会执行成功了，但是不作为 pass@3 的判断标准里面了，所以无效

2、pass^k 衡量所有 k 次试验成功的概率。

🌟

随着试验次数的增加，pass@k 和 pass^k 出现分化。在 k=1 时，它们是相同的（都等于每次试验的成功率）。到 k=10 时，它们呈现出截然相反的情况：pass@k 接近 100%，而 pass^k 降至 0%。

两种指标都很有用，使用哪种取决于产品需求：对于工具，一个成功就很重要，使用 pass@k；对于代理，一致性是关键，使用 pass^k。

揭秘 AI 代理的评估 - 多种Agent的评估方法 ​

前言： ​

一、评估编码 Agent 的方法 ​

二、评估对话 Agent 的方法 ​

三、评估研究 Agent 的方法 ​

四、评估计算机使用 Agent 的方法 ​

五、总结 ​