一文搞懂 Agents 评测丨Anthropic 最新万字长文

让 Agents 更可用的部分模块，也恰恰是它们更难评测的部分。

传统模型评测方法无法胜任 Agent 系统的复杂行为，而有效的评测能够帮助团队在产品发布前发现深层问题，而不是等到用户反馈后再去盲目修正。

Agent 并不是一次性输出的系统。它们运行在多轮交互之中：调用工具、修改内部状态、根据中间结果不断调整策略。

也正是这些让 Agent 变得有用的能力 ——自主性、智能性与灵活性 —— 同时也让它们变得更难以评估。

Anthropic 在与内部团队的实践，以及与一线 Agent 开发者和客户的合作中，逐渐摸索出一套更严谨、也更具实际价值的 Agent 评测设计方法。

下面分享的，是这些方法在不同 Agent 架构、不同真实应用场景中反复验证后，总结出的有效经验。

评测的结构

评测（evaluation，简称 eval），本质上是对一个 AI 系统进行测试：

向 AI 提供输入，再通过一套评分或判定逻辑，对其输出进行衡量，以判断是否达成预期目标。

在这篇文章中，我们关注的是可在开发阶段运行、无需真实用户参与的自动化评测。

单轮评测的结构相对简单：一个提示、一段回复，以及对应的评分逻辑。在早期的大模型阶段，单轮、非 Agent 化的评测，几乎是主流乃至唯一的评估方式。

但随着 AI 能力不断提升，系统开始具备规划、多步推理与工具调用能力，多轮交互、具备 Agent 特征的评测，逐渐成为新的常态。

在简单的评测中，Agent 接收一个提示并生成输出，评分器只需判断结果是否符合预期。而在更复杂的多轮评测里，一个编程 Agent 会被提供工具、任务（例如构建一个 MCP 服务器）以及运行环境，在此基础上执行完整的 Agent 循环（包括推理与工具调用），并将实现结果写入环境。最终，评测通过运行单元测试来验证该 MCP 服务器是否真正可用。

Agent 会在多轮交互中使用工具、不断修改环境状态并动态调整行为，这意味着一次失误可能被持续放大、层层叠加。与此同时，前沿的新模型有时还能通过“非常规路径”解决问题，超出静态评测的设计边界。

例如，Opus 4.5 在一个关于订机票的 𝜏2-bench 任务中，通过发现策略漏洞给出了更优解——虽然按照原评测规则判定为“失败”，但对用户而言反而是更好的结果。

在构建 Agent 评测时，我们采用如下定义：

• 任务（Task）：一次独立测试，包含明确的输入与成功标准。
• 试次（Trial）：任务的一次运行。由于模型输出存在随机性，通常会进行多次试次以获得稳定结果。
• 评分器（Grader）：用于评估 Agent 表现某一方面的判定逻辑。一个任务可以包含多个评分器，每个评分器内部可包含多个断言（check）。
• 记录（Transcript / Trace / Trajectory）：一次试次的完整过程记录，包括输出、工具调用、推理、中间结果及所有交互。在 Anthropic API 中，对应的是一次评测结束后完整的 messages 数组。
• 结果（Outcome）：试次结束时环境中的最终状态。比如订票 Agent 最后可能输出“机票已预订”，但真正的结果是数据库中是否存在有效的预订记录。
• 评测框架（Evaluation Harness）：用于端到端运行评测的基础设施，负责提供指令与工具、并发执行任务、记录过程、评分并汇总结果。
• Agent 框架（Agent Harness / Scaffold）：使模型能够作为 Agent 运作的系统，负责处理输入、调度工具调用并返回结果。评测“一个 Agent”时，实际上是在同时评测模型与其 Agent 框架。
• 评测套件（Evaluation Suite）：围绕特定能力或行为设计的一组任务集合，通常共享一个总体目标，例如客服场景下的退款、取消与升级处理等。

Agent 评估的组成部分

为什么要做评测？

在最初开发 Agent 时，团队往往靠手动测试、内部试用和直觉，就能推进很远。此时，严格的评测甚至可能被认为是拖慢交付的额外负担。

但一旦 Agent 上线、开始扩展规模，缺乏评测的问题就会显现。典型场景是：用户反馈改动后体验下降，而团队陷入迷茫，唯一手段只能是猜测与尝试。

没有评测，调试只能被动进行：等投诉、手动复现、修复，再祈祷没有引入新问题。团队无法区分真正的调优与噪声，也无法在上线前自动验证数百种场景，甚至无法量化改进效果。

我们多次观察到这样的发展过程。以 Claude Code 为例，最初团队依靠员工和外部用户反馈快速迭代。后来加入了评测——从单一指标（如简洁度、文件修改）到更复杂行为（如过度工程化）——帮助发现问题、指导改进，并强化研发与产品的协作。结合生产监控、A/B 测试和用户研究，评测为 Claude Code 的持续优化提供了关键信号。

在 Agent 生命周期的任何阶段，编写评测都是有价值的。早期，它迫使团队明确“成功标准”；后期，它保证了质量一致性。

例如 Descript 的视频编辑 Agent，他们围绕三条成功指标设计评测：不破坏现有内容、按要求完成、做好每一步。评测从人工评分演进为由产品团队定义标准的 LLM 自动评分，并辅以周期性人工校准，现在常态运行两套套件用于质量基准与回归测试。Bolt AI 则在 Agent 已广泛使用后才搭建评测系统，三个月内实现了自动运行 Agent、静态分析输出、浏览器测试应用、以及 LLM 判断行为的完整流程。

有的团队从开发一开始就做评测，有的则在扩展阶段才添加。评测尤其适合早期阶段，用于明确预期行为，避免两位工程师因初始规格理解不同而产生歧义。一套评测套件，可以统一判断标准，无论何时创建，都能加速开发。

评测还决定了团队采用新模型的速度。没有评测的团队，需要花数周测试新模型，而有评测的团队，可以在几天内快速发现模型优势、调整提示、升级 Agent。

一旦建立评测，就自带基线和回归测试：延迟、Token 使用量、任务成本、错误率等指标都能在固定任务库上追踪。同时，评测还能成为产品与研发之间高效沟通的渠道，定义可优化的指标。显然，评测的价值远不止追踪回归与改进，其复利效应往往被忽略：成本前置、收益延后，但积累下来却极为可观。

如何评测 AI Agent

目前大规模部署的 Agent 主要有几类：编程 Agent、研究 Agent、电脑操作 Agent 和对话 Agent。

虽然它们可能服务于不同行业，但评测方法可以相通。你不必从零设计评测，下面介绍一些已验证的技术，可作为基础，再根据你的应用场景进行拓展。

Agent 的评分器类型

Agent 评测通常结合三类评分器：基于代码的、基于模型的和人工评分。每类评分器用于评估记录（transcript）或最终结果（outcome）的不同部分。

设计有效评测的关键，在于为不同任务选择合适的评分器。

每个任务的评分可以采用加权（各评分器分数加权，达到阈值即通过）、二元制（所有评分器必须通过）或混合方式。

能力评测 vs. 回归评测

能力评测（Capability / Quality Eval）：问“这个 Agent 哪些方面做得好？”通常从较低通过率开始，关注 Agent 易错的任务，为团队设定提升目标。

回归评测（Regression Eval）：问“Agent 是否仍能完成之前能做的任务？”通过率接近 100%，用于防止性能倒退。一旦分数下降，说明出现了问题，需要修复。团队在能力评测上提升的同时，也要持续运行回归评测，确保改动没有引发新问题。

当 Agent 上线并优化成熟后，高通过率的能力评测可以“毕业”成为持续运行的回归套件，用于捕捉性能漂移。原本衡量“能否完成任务”的测试，转而衡量“能否稳定完成任务”。

评测编程 Agent

编程 Agent 会像人类开发者一样编写、测试、调试代码，并操作代码库和运行命令。现代编程 Agent 的有效评测通常依赖：明确的任务规范、稳定的测试环境、以及全面的代码测试。

确定性评分器非常适合编程 Agent，因为软件行为相对可量化：代码能否运行？测试是否通过？

两个常用基准：

• SWE-bench Verified：给 Agent 提供 GitHub 上 Python 项目的 issues，通过运行测试套件评分；仅在修复失败测试且不破坏原有功能时算通过。LLM 在一年内成绩从 40% 提升到 >80%。
• Terminal-Bench：面向端到端技术任务，例如从源码构建 Linux 内核或训练机器学习模型。

除了对关键结果的通过/失败测试外，评估记录（transcript）也很有用。例如：

• 可用启发式规则评估代码质量
• 可用模型评分器按明确标准评估 Agent 的行为，例如工具调用方式、用户交互情况

示例：编程 Agent 的理论评测

假设任务是修复一个认证绕过漏洞。通过 YAML 文件定义，可以同时使用多种评分器和指标，对 Agent 进行评估。

task:

  id: "fix-auth-bypass_1"

  desc: "Fix authentication bypass when password field is empty and ..."

  graders:

    - type: deterministic_tests

      required: [test_empty_pw_rejected.py, test_null_pw_rejected.py]

    - type: llm_rubric

      rubric: prompts/code_quality.md

    - type: static_analysis

      commands: [ruff, mypy, bandit]

    - 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

    - type: latency

      metrics:

        - time_to_first_token

        - output_tokens_per_sec

        - time_to_last_token

需要注意的是，上述示例展示了可用评分器的全套范围，仅用于说明。实际上，编程 Agent 的评测通常只依赖单元测试验证正确性，以及LLM 评分标准评估整体代码质量，其他评分器和指标仅在必要时添加。

评测对话 Agent

对话 Agent 在客服、销售、辅导等场景中与用户交互。与传统聊天机器人不同，它们保持状态、使用工具、并可在对话中采取行动。虽然编程或研究 Agent 也可能有多轮用户交互，但对话 Agent 的独特挑战在于：交互本身的质量也是评测的一部分。

有效的对话 Agent 评测通常依赖：

• 可验证的最终状态（end-state outcome）
• 能反映任务完成度和交互质量的评分标准（rubric）

与大多数评测不同，这类评测往往需要第二个 LLM 来模拟用户。我们在对齐审计 Agent 中也采用此方法，通过长轮次、对抗式对话对模型进行压力测试。

对话 Agent 的成功通常是多维度的，例如：

• 问题是否解决（状态检查）
• 是否在 < 10 轮内完成（记录约束）
• 语气是否合适（LLM 评分标准）

两个体现多维度评测的基准是 𝜏-Bench 及其后续 τ2-Bench，它们模拟零售客服、机票预订等多轮场景，一方模拟用户角色，Agent 在真实情境中操作。

示例：对话 Agent 的理论评测

假设任务是：Agent 需要处理一位情绪激动的客户的退款请求。

graders:

  - type: llm_rubric

    rubric: prompts/support_quality.md

    assertions:

      - "Agent showed empathy for customer's frustration"

      - "Resolution was clearly explained"

      - "Agent's response grounded in fetch_policy tool results"

  - type: state_check

    expect:

      tickets: {status: resolved}

      refunds: {status: processed}

  - type: tool_calls

    required:

      - {tool: verify_identity}

      - {tool: process_refund, params: {amount: "<=100"}}

      - {tool: send_confirmation}

  - type: transcript

    max_turns: 10

tracked_metrics:

  - type: transcript

    metrics:

      - n_turns

      - n_toolcalls

      - n_total_tokens

  - type: latency

    metrics:

      - time_to_first_token

      - output_tokens_per_sec

      - time_to_last_token

正如我们在编程 Agent 示例中所示，这个任务展示了多种评分器类型，仅用于说明。在实际操作中，对话 Agent 的评测通常使用基于模型的评分器来同时评估交互质量和目标完成情况，因为许多任务——例如回答问题——可能存在多种“正确”解法。

评测研究 Agent

研究 Agent 的工作是收集、综合并分析信息，然后生成输出，例如答案或报告。与编程 Agent 不同，研究任务无法通过单元测试提供简单的二元对错信号，研究质量必须根据任务情境来判断。什么算“全面”、“来源可靠”或“正确”，依赖具体场景：市场调研、并购尽调、科学报告，各自的标准都不同。

研究评测面临一些独特挑战：专家可能对综合内容是否全面存在分歧；参考内容持续变化导致“标准答案”不断漂移；长篇、开放式输出给错误留下更多空间。例如基准测试 BrowseComp 就考察 AI Agent 能否在开放网络中找到“干草堆中的针”——问题设计易于验证，但解决难度高。

构建研究 Agent 的评测策略之一是结合多种评分器类型：

• 事实性检查（Groundedness checks）：验证输出内容是否有检索到的来源支撑
• 覆盖率检查（Coverage checks）：定义一个良好答案必须包含的关键事实
• 来源质量检查（Source quality checks）：确认引用的来源权威可靠，而不仅仅是检索到的第一个

对于具有客观正确答案的任务（例如“X 公司第三季度营收是多少？”），可以使用精确匹配。LLM 评分器不仅可以标记 unsupported claims 和信息覆盖缺口，还可以评估开放式综合输出的连贯性和完整性。

由于研究质量具有主观性，基于 LLM 的评分器应定期与专家判断进行校准，以确保对研究 Agent 的评测有效。

电脑操作 Agent 的评测

电脑操作 Agent 通过人类界面操作软件——如截图、鼠标点击、键盘输入和滚动——而非通过 API 或代码执行，能够使用任何图形界面应用程序（GUI），从设计工具到遗留企业软件均可。评测要求在真实或沙盒环境中运行 Agent，观察其是否达成预期目标。

• 例如 WebArena：测试基于浏览器的任务，通过 URL 和页面状态检查验证 Agent 是否正确导航，同时通过后台状态检查确认任务是否实际完成（例如订单是否真正生成，而不仅仅是确认页显示）。
• OSWorld：将评测扩展到整个操作系统，评测脚本在任务完成后检查多种产物：文件系统状态、应用配置、数据库内容以及 UI 元素属性。

浏览器 Agent 的评测需要在 Token 使用效率与延迟之间找到平衡：

• 基于 DOM 的操作执行快，但消耗大量 Token
• 基于截图的操作慢，但更节省 Token

例如，让 Claude 总结 Wikipedia 内容时，从 DOM 提取文本效率更高；在 Amazon 找笔记本保护壳时，截图操作更省 Token（因为完整提取 DOM 代价太高）。在 Claude for Chrome 产品中，我们开发了评测来检查 Agent 是否在每种场景中选择了正确工具，从而实现更快、更准确的浏览器任务完成。

如何看待 Agent 评测中的非确定性

无论 Agent 类型如何，其行为在不同运行中可能会有所不同，这使得评测结果比表面看起来更难解读。每个任务都有自身的成功率：一个任务可能在 90% 的尝试中成功，另一个任务可能仅有 50%；一次评测中通过的任务，下次可能失败。有时我们关注的，是 Agent 在多次尝试中成功的频率（试次比例）。

两个指标常用于量化这种非确定性：

• pass@k：表示 Agent 在 k 次尝试中至少一次成功的概率。随着 k 增加，pass@k 分数上升——尝试次数越多，至少一次成功的概率越高。举例来说，如果 pass@1 = 50%，意味着模型在评测中第一次尝试成功了一半任务。在编程场景，我们通常最关心第一次尝试能否成功（pass@1）。在其他场景，提出多种解决方案也是有效的，只要其中至少有一个成功。
• pass^k：表示 k 次尝试全部成功的概率。随着 k 增加，这个指标下降，因为要求在更多试次中保持一致更难。例如，如果 Agent 单次试次成功率为 75%，运行 3 次试次，那么三次全成功的概率为 0.75³ ≈ 42%。这一指标对面向用户的 Agent 尤为重要，因为用户期望每次都能可靠完成任务。

随着试次增加，pass@k 与 pass^k 会出现明显分化。在 k = 1 时，两者相同，都等于单次试次的成功率。但到 k = 10 时，它们会呈现完全相反的趋势：pass@k 接近 100%，而 pass^k 则降至 0%。

两种指标都有用，具体选用哪一个取决于产品需求：pass@k 适用于只需一次成功即可的工具，pass^k 则适用于对一致性有严格要求的 Agent。

从零到一：打造高质量 Agent 评测的路线图

本节分享在实战中验证过的经验，指导团队从没有评测到建立可靠评测的过程。把它看作以评测驱动的 Agent 开发路线图：早定义成功标准、明确衡量方式、持续迭代。

收集初始评测任务集

Step 0. 及早开始

许多团队拖延建立评测，因为他们认为需要上百个任务。实际上，20–50 个源自真实失败的简单任务就足够起步。早期 Agent 开发中，每次系统改动通常都会产生明显影响，这种大效应意味着小样本也能显现问题。随着 Agent 越成熟，可能需要更大、更难的评测来捕捉微小变化，但初期采用 80/20 法则最合适。评测建立越晚越困难。早期，产品需求自然能转化为测试用例；等太久，就需要从运行中的系统逆向推断成功标准。

Step 1. 从已有的手动测试开始

从开发过程中手动检查的内容入手——每次发布前验证的行为、用户常做的任务。如果 Agent 已上线，可查看 Bug 跟踪系统和客服工单。将用户反馈的失败转化为测试用例，确保评测套件反映真实使用情况；按用户影响优先排序，可让努力投放在最关键的地方。

Step 2. 编写明确无歧义的任务并附参考答案

任务质量比想象中难把控。一个好任务应当让两位领域专家独立评判均得出相同的通过/失败结论。他们自己能完成任务吗？如果不能，任务需要调整。任务说明中的模糊性会成为指标噪声，模型评分器的标准同理：含糊的评分标准会导致判定不一致。

每个任务都应可被严格按照指令操作的 Agent 完成。这往往很微妙。例如，在 Terminal-Bench 审核中发现，如果任务要求 Agent 写脚本，但没有明确指定文件路径，而测试假设了特定路径，Agent 可能因非自身原因失败。评分器检查的一切都应在任务说明中清楚呈现，Agent 不应因任务模糊而失败。对于前沿模型来说，若多轮试次通过率为 0%（即 0% pass@100），通常是任务或评分器配置问题而非 Agent 无能，应检查任务说明与评分器设置。

每个任务最好都提供参考答案：一个已知可通过所有评分器的输出。这不仅证明任务可解，也验证评分器配置正确。

Step 3. 构建平衡的问题集

评测任务既要测试应发生的行为，也要测试不应发生的行为。单向评测会导致单向优化。例如，如果只测试 Agent 应该搜索的情况，可能训练出一个几乎对所有情况都搜索的 Agent。尽量避免类别不平衡的评测。

在 Claude.ai 构建网页搜索评测时亲身经历了这一点。挑战在于：防止模型在不该搜索时搜索，同时保留在适当场景下的广泛研究能力。团队建立了覆盖双向场景的评测：一类查询模型应搜索（如查天气），另一类查询应直接回答（如“谁创立了 Apple？”）。在“不触发搜索”和“过度触发搜索”之间找到平衡非常困难，提示词和评测经过多轮迭代才稳定。随着更多示例任务出现，我们持续扩充评测，提升覆盖率。

设计评测框架和评分器

Step 4：构建稳健的评测框架和环境

评测中的 Agent 必须尽量与生产环境中的 Agent 保持一致，同时评测环境本身不应引入额外噪声。每次试次都应从干净环境开始，实现“隔离”。运行间的不必要共享状态（残留文件、缓存数据、资源耗尽等）可能导致失败相关性，因为问题源于基础设施而非 Agent 本身。共享状态还可能人为抬高表现。例如，我们在内部评测中观察到，Claude 通过查看前几轮试次的 git 历史，在某些任务上获得了不公平优势。如果多个不同试次因环境限制（如 CPU 内存不足）而失败，这些试次并非独立，评测结果无法可靠衡量 Agent 性能。

Step 5：设计评分器

正如前文所述，出色的评测设计依赖于为 Agent 和任务选择合适的评分器。我们建议：尽可能使用确定性评分器，在必要或需要灵活性时使用 LLM 评分器，必要时再辅以人工评分进行额外验证。

很多团队本能地想要检查 Agent 是否严格按照步骤操作，例如按顺序调用工具。我们发现这种方式过于僵硬，容易产生脆弱测试，因为 Agent 经常能找到评测设计者未预料到的有效方法。为了不无谓惩罚创造力，更好的做法是评估 Agent 的产出，而非它的路径。

对于多组件任务，应设计部分得分机制。例如，一个客服 Agent 能正确识别问题并核实客户，但未能完成退款，这比直接失败的 Agent 要好得多。结果中应体现这种成功的连续性。

模型评分通常需要仔细迭代以验证准确性。LLM 作为评判的评分器应与人类专家紧密校准，确保模型评分与人工评分差异最小。为避免幻觉，可给 LLM 一个“安全出口”，例如当信息不足时返回“未知”。建立清晰、结构化的评分细则也很有帮助，每个任务维度使用独立的 LLM 评分器，而不是用一个评分器处理所有维度。一旦系统稳健，人工复核只需偶尔进行。

一些评测存在微妙的失败模式，即使 Agent 表现良好，也可能得分低，原因可能是评分器 Bug、Agent 框架限制或任务歧义。即便是经验丰富的团队也可能忽略这些问题。例如，Opus 4.5 在 CORE-Bench 初次评测得分仅 42%，后来 Anthropic 研究员发现多个问题：严格的评分规则导致“96.12”被惩罚（原期望为“96.124991…”）、任务说明模糊、以及随机任务无法精确复现。修复 Bug 并使用限制较少的框架后，Opus 4.5 分数跃升至 95%。同样，METR 在时间范围基准中发现多个任务配置错误，要求 Agent 优化至指定分数阈值，但评分却要求超过该阈值。这惩罚了遵循指令的模型（如 Claude），而忽略目标的模型反而得分更高。仔细检查任务和评分器可以避免此类问题。

评分器还应具备防止规避或作弊的能力。Agent 不应轻易“走捷径”通过评测。任务与评分器应设计成通过任务必须真正解决问题，而非利用漏洞。

长期维护与使用评测

Step 6：检查试次记录

除非阅读大量试次的记录和评分，否则无法判断评分器是否有效。在 Anthropic，我们投入了专门的工具查看评测记录，并定期进行人工阅读。当任务失败时，记录能告诉你 Agent 是否真正出错，或者评分器是否误判了有效解。记录还常常揭示 Agent 和评测行为的关键细节。

失败应显得公平：清楚显示 Agent 出错原因。当分数不提升时，我们需要确认是 Agent 表现问题，而非评测本身。阅读试次记录是验证评测衡量内容是否正确的关键技能，也是 Agent 开发的核心能力。

Step 7：监控能力评测的饱和度

当评测通过率达到 100% 时，只能检测回归，而无法提供改进信号。评测饱和发生在 Agent 完成了所有可解任务，改进空间消失。例如，SWE-Bench Verified 的分数今年起步为 30%，前沿模型现已接近饱和（>80%）。随着评测接近饱和，进步也会放缓，因为只剩下最困难的任务。这可能导致结果误导：能力提升幅度大，却在分数上表现为小幅增长。例如，代码评审创业公司 Qodo 初期对 Opus 4.5 印象平平，因为他们的一次性编码评测未能体现长复杂任务的改进。于是他们开发了新的 Agent 评测框架，更清晰地展现了进步。

通常，我们不会仅凭评测分数下结论，必须有人深入分析评测细节并阅读部分记录。如果评分不公平、任务模糊、有效解受罚，或框架限制模型，评测都应修正。

Step 8：通过开放贡献和维护保持评测套件健康

评测套件是一个活的产物，需要持续关注和明确负责人才能保持有效。

在 Anthropic，我们尝试了多种评测维护方式。最有效的方法是建立专门的评测团队负责核心基础设施，同时由领域专家和产品团队贡献大部分任务并运行评测。

对于 AI 产品团队来说，拥有并迭代评测应与维护单元测试一样常规。团队可能会浪费数周开发“可用”功能，但未满足隐性预期，而精心设计的评测本可早期揭示这些问题。定义评测任务是检验产品需求是否足够具体的最佳方式之一。

我们建议实践评测驱动开发：在 Agent 能完成之前，先用评测定义计划中的能力，然后迭代直到 Agent 表现良好。内部我们经常开发“今日足够好”的功能，但这实际上是对未来几个月模型能力的押注。初始通过率低的能力评测让这种押注可见。当新模型发布时，快速运行套件能立即显示哪些押注奏效。

最接近产品需求和用户的人最适合定义成功标准。利用现有模型能力，产品经理、客户成功经理或销售人员可以通过 Claude Code 提交评测任务（PR 形式）——让他们参与！甚至更好的是，主动赋能他们参与。

评测与其他方法的结合，形成对 Agent 的整体理解

自动化评测可以在数千个任务上运行，而无需部署到生产环境，也不会影响真实用户。但这只是了解 Agent 表现的众多方式之一。完整的认知还包括生产监控、用户反馈、A/B 测试、手动记录审查以及系统化的人工评估。

这些方法适用于 Agent 开发的不同阶段。自动化评测在发布前以及持续集成/持续部署（CI/CD）阶段尤其有用，每次 Agent 改动和模型升级时运行，是防止质量问题的第一道防线。生产监控则在上线后发挥作用，用于检测分布漂移和意料之外的真实世界故障。A/B 测试在流量足够时验证重大改动。用户反馈和记录审查是持续进行的实践——持续处理反馈，每周抽查部分记录，并根据需要深入分析。系统化人工研究则保留用于校准 LLM 评分器，或评估主观性输出，其中人类共识作为参考标准。

最有效的团队会结合多种方法——用自动化评测实现快速迭代，用生产监控获取真实反馈，并定期进行人工审查以校准。

结论

没有评测的团队容易陷入被动循环——修复一个问题又引入另一个，无法区分真实回归与噪声。而那些早期投入评测的团队则正好相反：开发加速，失败变成测试用例，测试用例防止回归，指标取代猜测。评测为整个团队提供了明确的目标，将“Agent 表现变差”转化为可操作的内容。其价值会随着时间累积，但前提是将评测视为核心组成，而非事后附加。

不同类型的 Agent 模式各异，但本文描述的基本原则始终适用。要尽早开始，不必等待完美的评测套件。从实际失败案例中获取真实任务。定义明确、稳健的成功标准。精心设计评分器，并结合多种类型。确保问题对模型足够具有挑战性。不断迭代评测，提高信噪比。仔细阅读交互记录！

AI Agent 评测仍是一个新兴且快速发展的领域。随着 Agent 承担更长的任务、在多智能体系统中协作，并处理越来越多的主观性工作，我们需要不断调整技术方法。我们将继续分享在实践中积累的最佳经验。

文章来自于微信公众号 “特工宇宙”，作者 “特工宇宙”