Anthropic：如何评测 Agent？

AI训练营7期，1月下旬开班，欢迎咨询

我们在做AI项目过程中，有个关键词是一定绕不过去的可观测性，这个可观测背后其实对应着这个AI项目是否可评估，对应着会出现RAG评估系统、AI专业性评估策略等等衍生品。

比如前些日子，OpenAI汇集60个国家/地区的262位医生合力打造的5000个真实医疗对话场景，最终推出的HealthBench就是一套评估策略，只不过这个更偏整体的了。

今天我们来看大模型厂商Anthropic一篇关于Agent的评估论文，借此再深入理解下如何做AI项目的评估这件事：

https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents

首先，什么是评测？

什么是评测

评测是对系统进行系统化测试的方法，输入设定好的任务，检查 Agent 的输出或行为是否满足预期。

Anthropic 将评测流程分解为若干结构模块：

1. 任务 (Task) 表示一次独立测试的输入和成功标准；
2. 单词试验 (Trial) 是任务的一次运行，由于模型随机性，通常会多次试次以求稳定；
3. 评分器 (Grader) 是用于评估 Agent 某个方面表现的判定逻辑，一个任务可以包含多个评分器及检查点；
4. 记录 (Transcript) 记录整个试次过程的细节，包括所有的输入、输出、工具调用、推理和中间结果；
5. 结果 (Outcome) 则指单次试验结束时环境中的最终状态，比如一个订票 Agent 的输出可能显示“机票已订好”，但真正的评测结果要通过检查数据库中是否存在预订记录来判断；

通常，评测框架（evaluation harness）会提供任务和工具并发运行、记录全过程并自动评分；

Agent 框架的有效评测体系需要覆盖从输入到行为的完整闭环，以确保 Agent 在多轮交互和工具调用中的表现都被量化评估。

评估的价值前面也说过了，Anthropic的表述有点绕口，其实就是通过明确成功标准，使团队在投产前就发现问题，而不是等到用户投诉后才被动修复。

Anthropic 指出，没有评测的团队往往陷入被动修复循环，每修复一个问题又可能引入新的问题，而无法区分是真正的回归还是模型输出的随机波动。

这里其实需要补一句，就算是建立了评估体系，也一样会出现改了一个地方，另一个地方出问题的可能，Agent或者AI项目就是这么烦；

但无论如何，采用评测的团队对项目本身的认识一定更深，相应着他们会更专业，会用失败的用例“升级”系统，最终飞轮系统成功了，几乎预示着他们项目就成功了。

能力评测 → 任务评测

Anthropic将评测分为两类：能力评估 (Capability/Quality Eval) 和回归评估 (Regression Eval) 。

能力评估是最基础的项目可观测性所在，着眼于“Agent 能做什么”，通常从通过率较低、Agent 较易失败的任务开始，目标是衡量并推动模型新能力的提升；

而回归评估则关注“Agent 是否仍然能完成之前能做的任务”，其通过率应接近 100%，用于防止更新迭代引入性能倒退。这里最好使用之前的错误数据集，每次发布都应该去过一次。

实际项目中，我们也观察到了这种趋势。以 Descript 的视频编辑 Agent 为例，他们围绕“不破坏已有内容、按要求执行、执行质量”三个维度设计评测。

这一套评测从人工评分逐步演进到由产品团队定义标准的 LLM 自动评分，并配合周期性人工校准，现在常态化运行两套测试：一套用于质量基准评测、一套用于回归测试。

而 Bolt AI 团队则是在 Agent 已被广泛使用后才开始搭建评测系统，3 个月内构建了一套完整的自动化评测流程，包括自动运行 Agent 并对输出进行静态代码分析、浏览器应用测试，以及使用 LLM 作为评判者检测行为表现。

结合我之前大型AI项目生产实践，评测体系一定是提高迭代效率、保障质量的关键工具。

有了可评测的指标和方法，我们才不会在AI项目上抓瞎，也不会说出模型能力就这样了的蠢话。

如何评测

Anthropic 总结了三种评测方式：代码型评分器、模型型评分器和人工评分器。

模型评分

模型型评分器（Model-based）是使用另一个大模型来打分或判断，如基于评分量表的打分、自然语言断言、参考答案对比等。

它们灵活，能够捕捉主观和开放式任务的细微差别，但缺点是结果不确定，需要更多计算资源，并需要通过人工标注来校准准确度。

在问答、摘要、对话等输出形式丰富的任务中，模型型评分器可以用来衡量答案是否符合人类预期、是否优雅有用、是否遵循约定格式等。

例如，在对话 Agent 的评测中，往往需要第二个 LLM 来模拟用户发起问答，并通过提示词设计评价 Agent 的交互质量和目标完成度。

严格来说，我们最前面的HealthBench就可以用模型评分器。

人工评分

这个大家就一定不陌生了，也是最初、也应该是最“靠谱”的评分方式了，人工评分器适用于需要专家判断或无法用规则轻易量化的场景。

人工标注可以提供金标准质量，匹配专业用户的主观评判，通常用于校准模型评分器或最终质量验收，但其代价是昂贵且耗时。

实际中可以采用抽样检查、专家复核或众包评估等方式，对关键指标或异常输出进行人工审查，以确保评测结果的可靠性。

代码评分

代码型评分器（Code-based）包括字符串匹配、断言检查、静态分析、环境状态校验等，通过确定性逻辑快速判断是否符合预期。

其优点是高效、客观、易重现，适用于结构化输出和确定性任务，如编程 Agent 的代码输出。

例如，在编程 Agent 评测中，通常会对生成的代码运行自动化测试，只要代码能通过单元测试就认为通过。

Anthropic 指出，对于此类任务，“代码型评分器是天然选择”：软件任务可以用“代码是否能运行、测试是否通过”来直接评价。

这里人工评分大家一定最熟悉，而模型评分就是我们在建模后让模型替代人力的效率工具，只不过这里的代码评分一下就给很多同学干懵了，这是什么呢？

代码型评分器不是“测试代码生成能力”，而是 利用代码执行这一确定性的手段，来验证Agent复杂任务产出的正确性。

它解决的是Agent评估中最大的痛点之一：对于复杂、开放式任务，如何避免主观、模糊的评价，实现自动化的客观评估？

举个例子：“写一个Python函数，计算斐波那契数列” 这个任务的结果是可执行的。

这个例子背后就对应着论文绕口的翻译：任务的结果必须是可通过某种明确规则或外部系统进行客观验证的。

这个场景就可以用代码评分器：一个会自动导入Agent生成的函数，然后用一系列测试用例（如 fib(10) == 55）去运行它，检查结果是否正确。

“评分器”是一个自动化验证脚本或规则引擎。它的作用是：接收Agent的产出，调用相应的工具或规则，判断产出是否满足预设的成功标准。

再比如很多Tools调用就很适合用代码评分器。一般的AI项目一般不用这个，这个很适合Agent模式，所以很多同学对这个不大熟悉。

然后这里就开始分项目领域了，不同类型的 AI Agent，因其任务目标和交互模式不同，需要采用不同的评估策略：

Coding Agent

编程Agent需要编写、测试和调试代码，其评估通常借鉴软件测试思想。常见做法是给Agent指定明确的编程任务，例如修改代码漏洞、实现功能模块等，并用自动化测试或脚本来验证输出代码是否正确。

例如，SWE-Bench 和 Terminal-Bench 等著名基准测试都是基于这一思路：

1. SWE-Bench 给出 GitHub 问题，Agent修改后使用原有测试套件验证；
2. Terminal-Bench 则要求完成完整的工程任务（如编译 Linux 内核），通过成功执行步骤判断合格；

这些评估的关键在于准备可运行的测试环境和详尽的单元测试，以实现对代码结果的二元判定。

除了最后的结果验证外，还可对Agent的执行过程进行评估。例如，通过静态分析工具检查代码质量、通过 LLM 评分器评估其代码风格和可读性、或者检查Agent调用了哪些工具和命令（确保工具调用序列合理）。

如下示例 YAML 展示了一个复杂的编码任务评估配置，可以包含单元测试、静态分析、状态检查和工具调用检查等多个评分器：

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

真实项目中，常用的做法是以单元测试为主，它们验证功能正确性，再加一个 LLM 评分来判定代码质量即可

对话Agent

AI编程只是少数平台型公司的赛道，现阶段主主流的Agent场景依旧是对话机器人，再根据对话做不同意图识别完成特定功能。

对话型Agent在客服、销售、咨询等场景中与用户交互，需要维持上下文和正确完成目标。评估这类Agent既要验证最终“业务结果”，也要评估交流质量。

常用策略是：定义清晰的终态检验，例如工单状态是否更新、退款是否处理成功等；并配合 多维度评价指标如回应轮数、情感语调、礼貌程度等，用 LLM 或人工来评估对话质量。

在许多测试中，还需要使用第二个语言模型模拟用户，通过脚本化的方式与被测Agent展开模拟对话，以形成复杂、多轮的交互场景，如 Claude 的“对抗式审计Agent”就采用过这种长对话测试方式。

这个举个简单的案例，大家就懂了，如果我们做了AI医生，那么要做测试可以同步做一个AI患者...

HealthBench就是标准的对话Agent测试案例，大家可以多了解，这些内容输出核心还不只是要顺畅，并且要有专业性，比如医疗、法律出点问题都是不可容忍的。

研究类Agent

我们之前讨论NotebookLM说过，针对现阶段的通用Agent，他们最擅长的其实是三种工作：

1. 生成代码，尤其是HTML这类前端代码；
2. 生成加工内容，比如基于内容生成PPT、图片、博客；
3. 然后就是深度研究了；

研究型Agent负责收集、整合信息并输出报告式答案，它的评估注重内容的准确性和全面性，但正确答案本身通常是开放式的。

这类任务存在挑战：不同专家可能对“全面”与否有不同看法，参考资料不断更新也会有些影响，长篇输出容易出现错误。

例如，BrowseComp 基准测试要求Agent从互联网检索信息找到“草堆里面的针”，设计成易于验证但难以解决的问题。

普通情趣聊天Agent其实评估很简单，就自己建立评估框架，直接放给AI就好。真正困难的还是之前说的专业性Agent，比如医疗Agent，每一句话的输出都必须有原因，还必须有出处，这就恼火，所以这类Agent评测方式会采用多种方式。

操作型Agent

这类Agent通过模拟人类用户操作图形界面（键盘、鼠标、截图等）与软件交互，适用于自动化操作桌面应用或浏览器任务。评估这类Agent的关键是需要在实际或沙箱环境中运行Agent任务，并检查预期的最终系统状态。

例如，WebArena基准测试在浏览器中运行任务，使用URL检查和页面状态检测来验证Agent是否正确导航，同时对后台系统状态进行核对。

与上述Agent不同，应用操作Agent还要在评估时考虑性能权衡：DOM操作速度快但耗费大量Token，而截图操作更慢但Token花费低。

实际工程经验是根据任务类型选择合适方式，例如让Agent从网页DOM提取文本摘要更高效，而在电商搜索中用截图比解析整个DOM更实用。

实施路线图

构建系统的评估体系是AI Agent产品化的核心工程能力。构建评估体系的八大核心步骤如下：

一、及早开始，小步启动

评估体系建设越早越好。即使只有20-50个从真实失败案例中提取的简单任务，也足以发现系统性的重大问题。

早期改动引起的质量波动显著，小样本也能清晰评估改进效果。早期构建评估能迫使团队明确“成功”的具体含义，避免后期概念模糊。

二、从真实场景切入

将日常手工检查点、已知Bug、用户反馈转化为评估任务。

如果产品已上线，直接从问题跟踪系统和用户投诉中提取典型失败案例，这确保评估内容贴合真实场景，聚焦用户核心痛点。

三、设计明确的任务与参考答案

每个评估任务必须清晰无歧义，确保不同专家对任务描述的理解一致。

应为每个任务准备可执行的参考解，既证明任务可解，也用于验证评分器配置正确。

四、构建平衡的测试集

测试集需覆盖积极与消极场景，防止单方面优化导致模型行为偏差。

例如，在评估搜索代理时，既要包含需要搜索的查询（“今日天气”），也要包含不应搜索的查询（“苹果公司创始人是谁”）。

当模型表现不平衡时，应及时补充相反方向的任务进行约束。

五、搭建稳定的评估环境

确保评估环境与生产环境一致，每次试验从干净状态开始。

避免试验间共享状态（如残留文件、缓存历史）导致结果相互污染。使用容器化等隔离手段保证评估的独立性与可复现性。

六、精心设计自动化评分器

评分器设计遵循“结果优于过程”原则。

优先使用确定性检查（单元测试、状态验证）；需要灵活判断时采用LLM评分；仅在必要时引入人工评估。

避免对具体步骤顺序过度约束，应关注最终目标是否达成。对于多步骤任务，可设计部分积分机制。LLM评分器需经过严格的人工校准，并设置“不确定时返回未知”的逃生机制，减少幻觉误判。

七、深度分析对话记录

定期审查评估失败的对话轨迹，区分是代理真失败还是评分器误判。

通过人工审阅发现评估本身的设计问题（如任务描述模糊、评分规则过严），确保评估结果真实反映产品需求。

八、持续迭代，防止评估饱和

当评估通过率接近100%时，意味着当前测试集已失去区分度，仅剩回归测试价值。

此时需主动设计更难的任务、更复杂的场景或引入多轮交互测试，建立新的评估前沿。评估套件是“活文档”，需像维护单元测试一样持续更新。

生产落地实践

将评估体系落地到生产环境，需要考虑工具集成、性能指标、以及与现有工程流程的协同：

一、集成到 CI/CD

自动化评估应与持续集成系统衔接，每次模型版本或代理逻辑改动后自动运行评估，这样能在开发早期快速发现回归和问题。

评估运行需要资源，因此可针对不同阶段选择执行范围：开发阶段轻量级测试，正式发布前再跑全套评估。

二、实时监控与报警

评估结束后，还要实时监控代理在生产中的表现。

如记录日常请求通过的评估任务成功率、关键指标变化等，及时发现实际流量下的质量下降。

Galileo和Maxim等平台都强调要将生产数据反馈到评估闭环中，例如根据真实用户交互自动生成难题样本，避免同一个错误反复出现。

三、指标管理

开发团队应设定清晰的指标并长期跟踪。

例如对于客服代理，可跟踪“工单解决率”、“用户满意度”等；对于编程助手，可跟踪“构建通过率”、“代码缺陷率”等。

这些指标应与评估结果关联，评估报告中不仅包含单个任务的通过率，还要关注系统级指标，如响应时间、资源消耗。

工具链如Elastic APM、Prometheus、日志系统，可捕获这些指标，并与评估管线打通，形成统一看板。

四、工具与框架选择

市面上已有多种开源和商业评估框架可加速落地。

例如，Harbor 适合在容器化环境中大规模运行代理评估；Promptfoo 支持基于 YAML 的灵活测试声明；Braintrust 强调线下评估与线上观测一体化；LangSmith/Langfuse 则提供了模型追踪和评估管理工具。

团队可根据需要选择或自研框架，关键是尽快选个工具，并把精力投入到构造高质量的测试用例和评分器上。

五、与其他方法结合

评估体系并非唯一质量保障方式。

完整的质量监控通常包括生产监控、A/B测试、用户反馈、日志分析等。Anthropic 比喻为“瑞士奶酪模型”：自动化评估捕获绝大部分常见问题，生产监控揭示随机分布的错误，用户反馈和人工复盘发现细节问题。

在资源允许的情况下，也可以周期性进行人工对话审查或用户研究，以补充自动评估无法量化的指标。

......

结语

整个论文是有些东西的，但是没有超过之前的认知，他这里有点泛泛而谈，还不如直接找个案例，带着我们做一次，当然貌似所有的论文可读性都不大高...

评估体系是AI Agent工程化的分水岭

它将模糊反馈转化为可行动的洞察，是支撑数据驱动迭代的核心基础设施。总而言之要重视啊！

下面还有五大挑战，大家感受下即可：

• 挑战一：非确定性。LLM的随机性导致单次测试结果不可靠。策略：采用概率性指标（如pass@k），通过多次试验进行统计分析，建立置信区间。
• 挑战二：评分漏洞。设计缺陷会导致系统性误判。策略：建立“元评估”机制，定期人工审核失败案例，校准评分逻辑，确保其真实反映业务意图。
• 挑战三：路径依赖。僵化的评估会惩罚模型的创造性解决方案。策略：坚持结果导向，评估最终目标是否达成，而非预设步骤，鼓励创新。
• 挑战四：评估饱和。当测试通过率接近100%，评估便失去指导意义。策略：建立“动态前沿”，持续引入更复杂、更贴近真实噪声的任务，保持评估的区分度。
• 挑战五：组织协同。评估易沦为技术团队的孤立任务。策略：建立跨职能责任制，由专责团队维护框架，业务方贡献真实用例，将其纳入产品迭代流程。

点击上方卡片关注叶小钗公众号，查看下方二维码，添加我个人微信：