该文章由anthropic在1月9日发布，应该是anthropic第一篇系统讲agent评估的。原文链接可以翻到最底下。

智能体之所以有用，也正是因为它们具备某些功能，而这些功能也使得评估它们变得困难。适用于各种部署环境的策略会结合多种技术，以匹配它们所评估系统的复杂性。

介绍

有效的评估有助于团队更有信心地发布人工智能代理。如果没有评估，很容易陷入被动循环——只能在生产环境中发现问题，而修复一个故障又会引发其他故障。评估能够在问题和行为变化影响用户之前将其显现出来，其价值会在agent的整个生命周期中不断累积。

正如我们在[《构建高效智能体》]{.underline}一文中所述，智能体需要经过多个回合才能完成操作：调用工具、修改状态，并根据中间结果进行调整。正是这些使人工智能智能体发挥作用的能力——自主性、智能性和灵活性——也使得评估它们变得更加困难。

通过内部研发以及与处于agent开发前沿的客户合作，我们学会了如何设计更严谨、更有效的代理评估方法。以下是在各种代理架构和实际部署用例中行之有效的方法。

评估的结构

评估（简称”评估”）是对人工智能系统的一种测试：给人工智能系统输入数据，然后应用评分逻辑对其输出进行评估，以衡量其成功程度。本文重点介绍无需真实用户参与即可在开发过程中运行的自动化评估。

单轮评估简单明了：一个提示、一个回答和评分逻辑。对于早期的学习者学习模型（LLM）而言，单轮、非智能体评估是主要的评估方法。随着人工智能能力的提升，多轮评估变得越来越普遍。

核心区别

LLM Node 评估（单次交互）

- 定义：简单的"一问一答"场景，通过单一提示让 LLM 直接生成响应
- 流程：输入 → LLM 生成 → 直接判断
- 示例：问"猫有多少只脚？"，LLM 回答"18"，通过硬编码逻辑验证 response == 18
- 评估指标：
- 准确性（回答是否正确）
- 简洁性（是否冗余）
- 相关性（是否切题）

Agent 评估（智能体）

- 定义：复杂的"工具调用+环境交互"场景，智能体需要使用多种工具完成任务
- 流程：任务 → 工具调用 → 环境交互 → 结果验证
- 示例：编写 MCP 服务器，需要读取文件、搜索文档、编辑代码、运行测试等多个步骤
- 评估指标：
- 任务完成度
- 工具使用能力（是否正确调用工具）
- 环境交互能力（是否适应环境限制）
- 鲁棒性（遇到错误是否能调整）

智能体评估更为复杂。智能体会在多个回合中使用工具，不断修改环境状态并进行调整——这意味着错误可能会传播并累积。前沿模型还能找到超越静态评估局限性的创新解决方案。例如，Opus 4.5通过[发现]{.underline}策略中的一个漏洞，解决了关于预订航班的[𝜏2-bench]{.underline}问题。虽然它按照既定的评估方法”失败”了，但实际上却为用户提供了一个更优的解决方案。

在构建代理评估模型时，我们使用以下定义：

任务（又称问题或测试用例）是指具有明确输入和成功标准的单个测试。

每次尝试完成任务都称为一次试验。由于模型输出在不同运行中会有所变化，因此我们会进行多次试验以获得更一致的结果。

评分器是一种逻辑，用于对智能体性能的某些方面进行评分。一项任务可以有多个评分器，每个评分器包含多个断言（有时称为检查）。

记录（也称为轨迹或跟踪）是试验的完整记录，包括输出、工具调用、推理过程、中间结果以及任何其他交互。对于 Anthropic API，它是评估运行结束时的完整消息数组，其中包含评估期间对 API 的所有调用以及所有返回的响应。

结果是指试验结束时环境中的最终状态。例如，航班预订代理可能会在记录的最后说”您的航班已预订成功”，但结果取决于环境中的 SQL 数据库中是否存在相应的预订记录。

评估框架是运行端到端评估的基础架构。它提供指令和工具，并发运行任务，记录所有步骤，对输出进行评分，并汇总结果。

agent框架（或脚手架）是一个使模型能够作为代理运行的系统：它处理输入、协调工具调用并返回结果。当我们评估”agent”时，我们实际上是在评估框架和模型协同工作的情况。例如，[Claude Code是一个灵活的代理框架，我们通过其代理 SDK]{.underline}使用了其核心组件来构建我们[长期运行的代理框架]{.underline}。

评估套件是一系列旨在衡量特定能力或行为的任务集合。套件中的任务通常具有共同的总体目标。例如，客户支持评估套件可能测试退款、取消订单和升级处理流程。

这张图说明agent评估的结构：有一个 Evaluation harness 包含多个任务组成的 Evaluation suite，每个任务定义输入、成功标准、评委（如deterministic_tests、llm_rubric、state_check、tool_calls）和跟踪的指标（如 n_turns、n_toolcalls、tokens、latency），通过多次 Trial 采集完整轨迹（消息、工具调用、推理等）。任务执行由 Agent harness 运行，产生最终环境状态的 Outcome，随后各个 Grader 基于轨迹和结果打分，形成agent的评估成绩。

为什么要构建评估体系？

团队在开发智能体之初，往往凭借手动测试、[内部测试]{.underline}和直觉就能取得令人惊讶的进展。更严格的评估甚至可能被视为一种额外的开销，会拖慢产品发布速度。但是，在早期原型阶段之后，一旦智能体投入生产并开始扩展，不进行评估的开发方式就会失效。

问题往往出现在用户反馈代理在更改后体验更差时，而团队却只能”盲目摸索”，除了猜测和反复检查之外别无他法。缺乏评估机制，调试只能被动进行：等待用户反馈，手动复现问题，修复错误，然后祈祷没有其他回归问题。团队无法区分真正的回归问题和无关信息，无法在发布前针对数百种场景自动测试更改，也无法衡量改进效果。

我们已经多次见证了这种发展进程。例如，Claude Code 最初是基于 Anthropic 员工和外部用户的反馈进行快速迭代开发的。之后，我们增加了评估环节——最初针对简洁性和文件编辑等具体方面，后来扩展到过度设计等更复杂的行为。这些评估有助于发现问题、指导改进，并聚焦研发与产品之间的合作。结合生产监控、A/B 测试、用户研究等手段，评估结果能够为 Claude Code 的持续改进提供信号，助力其规模化发展。

在代理生命周期的任何阶段，编写评估报告都非常有用。早期阶段，评估报告能促使产品团队明确agent的成功标准；后期阶段，评估报告则有助于维持一致的质量标准。

[Descript]{.underline}的智能体帮助用户编辑视频，因此他们围绕成功的编辑工作流程的三个维度构建了评估体系：不破坏功能、执行指令、高质量地完成任务。他们从人工评分发展到使用 LLM 评分器，评分标准由产品团队定义，并定期进行人工校准。现在，他们定期运行两套独立的测试套件，分别用于质量基准测试和回归测试。Bolt [AI]{.underline}团队在拥有一个广泛使用的智能体之后才开始构建评估体系。他们仅用了 3 个月就构建了一个评估系统，该系统运行他们的智能体并使用静态分析对输出进行评分，使用浏览器智能体测试应用程序，并采用 LLM 评判器来评估诸如指令执行等行为。

有些团队在开发初期就创建评估用例；而另一些团队则会在规模化开发过程中，当评估用例成为改进智能体的瓶颈时才添加。评估用例在智能体开发的初期尤为重要，它可以明确地编码预期行为。两位工程师阅读同一份初始规范后，可能会对人工智能如何处理极端情况产生不同的理解。评估用例套件可以消除这种歧义。无论何时创建，评估用例都能帮助加速开发。

评估结果还会影响你采用新模型的速度。当更强大的模型出现时，没有评估结果的团队需要花费数周时间进行测试，而拥有评估结果的竞争对手则可以迅速确定模型的优势，调整提示信息，并在几天内完成升级。

一旦评估系统建立起来，您就能免费获得基准测试和回归测试：延迟、令牌使用量、单项任务成本和错误率都可以在一个静态任务库中进行跟踪。评估系统还可以成为产品团队和研究团队之间带宽最高的沟通渠道，定义研究人员可以据此进行优化的指标。显然，评估系统的好处远不止于跟踪回归和改进。由于成本是前期可见的，而收益是后期积累的，因此评估系统的累积价值很容易被忽视。

如何评估人工智能代理

如今我们看到几种常见的agent类型被大规模部署，包括coding智能体、research智能体、computer use智能体和chat智能体。

虽然agent类型可以应用于各种行业，但它们可以使用类似的评估技术。您无需从零开始创建评估方法。以下章节介绍了几种代理类型的成熟评估技术。您可以以此为基础，将其扩展到您的领域。

经纪人的评分类型

agent评估通常结合三种类型的评分者：基于代码的评分者、基于模型的评分者和人工评分者。每种评分者都会评估成绩单或结果的某个部分。有效评估设计的关键在于选择合适的评分者。

基于代码的评分器

点击图片可查看完整电子表格

基于模型的评分器

点击图片可查看完整电子表格

人工评分员

点击图片可查看完整电子表格

对于每项任务，评分可以是加权的（综合评分员得分必须达到阈值）、二元的（所有评分员都必须通过）或混合的。

能力评估与回归评估

能力或”质量”评估会问”这个智能体擅长做什么？”评估应该从较低的通过率开始，针对智能体难以完成的任务，给团队设置一个挑战。

回归评估旨在检验”代理是否仍然能够处理之前的所有任务？”，其通过率应接近 100%。回归评估能够防止系统退步，因为分数下降表明某些环节出现问题，需要改进。团队在进行能力评估时，同时运行回归评估至关重要，以确保变更不会在其他地方引发问题。

agent程序启动并优化后，通过率高的能力评估可以”升级”为回归测试套件，持续运行以检测任何偏差。以前衡量”我们能否完成这项任务？”的任务，现在可以衡量”我们是否仍然能够可靠地完成这项任务？”

评估coding agent

编码代理能够编写、测试和调试代码，浏览代码库并执行命令，其工作方式与人类开发人员非常相似。对现代编码代理进行有效评估通常依赖于明确的任务定义、稳定的测试环境以及对生成代码的全面测试。

对于编码代理来说，确定性评分器是天然的选择，因为软件的评估通常比较直接：代码能否运行，测试能否通过？两个广泛使用的编码代理基准测试工具[SWE-bench Verified]{.underline}和[Terminal-Bench]{.underline}都采用了这种方法。SWE-bench Verified 会向代理提供来自热门 Python 代码库的 GitHub 问题，并通过运行测试套件来评估解决方案；只有当解决方案修复了失败的测试且不破坏现有测试时，该解决方案才能通过。LLM（逻辑学习模型）在该评估中的得分在短短一年内就从 40% 提升到了 80% 以上。Terminal-Bench 则采用了不同的方法：它测试端到端的技术任务，例如从源代码构建 Linux 内核或训练机器学习模型。

一旦你拥有了一套用于验证编码任务关键结果的合格/不合格测试，通常也需要对代码进行评分。例如，基于启发式的代码质量规则可以基于除通过测试之外的其他因素来评估生成的代码，而带有清晰评分标准的基于模型的评分器可以评估诸如智能体如何调用工具或如何与用户交互等行为。

示例：编码代理的理论评估

考虑这样一项编码任务：智能体必须修复一个身份验证绕过漏洞。如下面的示例 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 rubric 看代码质量；静
态分析跑 ruff/mypy/bandit；状态检查确认安全日志里有拦截事件；tool_calls 要求代理确实读/改文件并跑测试。还跟踪过程指标：对话轮数、工具调用次数、总
token 数，以及延迟（首 token 时间、生成速度、结束时间）。这样既考最终结果，也看过程是否合理高效。

请注意，此示例仅展示了所有可用的评分工具，仅供参考。在实际应用中，代码评估通常依赖于单元测试进行正确性验证，并使用 LLM 评分标准评估代码整体质量，其他评分工具和指标仅在必要时添加。

评估chat agent

对话式智能体在支持、销售或辅导等领域与用户互动。与传统聊天机器人不同，它们会在对话过程中维护状态、使用工具并采取行动。虽然编码和研究型智能体也可能涉及与用户的多次交互，但对话式智能体面临着一个独特的挑战：交互本身的质量也是评估内容的一部分。对对话式智能体进行有效评估通常依赖于可验证的最终状态结果和评估标准，这些标准既能反映任务完成情况，又能反映交互质量。与其他大多数评估方法不同，对话式智能体通常需要第二个逻辑逻辑模型（LLM）来模拟用户。我们在[对齐审计智能体]{.underline}中使用了这种方法，通过扩展的对抗性对话来对模型进行压力测试。

对话代理的成功可以从多个维度来衡量：问题是否已解决（状态检查）、是否在 10 轮以内完成（文本记录限制）以及语气是否恰当（LLM 评价标准）？[𝜏-Bench]{.underline}及其后续版本[τ2-Bench]{.underline}是两个融入多维度考量的基准测试工具。它们模拟了零售支持和机票预订等领域的多轮交互，其中一个模型扮演用户角色，而代理则处理各种真实场景。

示例：对话代理的理论评估

设想这样一种客服任务：客服人员必须处理一位不满客户的退款事宜。

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

- 评分标准：LLM rubric 按同理心、解释清晰度、是否基于查询的政策结果；state_check 看票据已解决、退款已处理；tool_calls 要求确实核实身份、在额度内处理退款、发送确认；transcript 限制最多 10 轮。
- 过程指标：对话轮数、工具调用次数、总 token，用时指标包括首 token 时间、生成速度和完成时间。
- 目的：既看结局（退款办妥、沟通合规），也看过程是否高效、合规、友好。

如同我们之前的编码代理示例，这项任务展示了多种评分器类型以作说明。实际上，对话agent的评估通常使用基于模型的评分器来评估沟通质量和目标完成情况，因为许多任务（例如回答问题）可能存在多个”正确”答案。

评估Research Agent

Research Agent收集、整合和分析信息，然后生成答案或报告等输出。与编码代理的单元测试提供二元通过/失败信号不同，研究质量只能根据具体任务来判断。何为”全面”、”来源可靠”甚至”正确”，取决于具体情况：市场调研、收购尽职调查和科学报告都需要不同的标准。

研究评估面临着独特的挑战：专家们可能对综合分析是否全面存在分歧；随着参考内容的不断变化，真实情况也会随之改变；篇幅更长、更开放的输出结果更容易出错。例如，像[BrowseComp]{.underline}这样的基准测试旨在检验人工智能agent能否在开放的互联网中大海捞针般地找到所需信息——这些问题的设计初衷是易于验证但难以解决。

构建Research Agent评估的一种策略是结合多种评分类型。基础性检查用于验证论断是否得到检索到的资料支持；覆盖面检查用于定义一个好的答案必须包含的关键事实；而来源质量检查则用于确认所参考的资料来源是否权威，而不仅仅是检索到的第一个来源。对于有客观正确答案的任务（例如”X公司第三季度的收入是多少？”），完全匹配即可。LLM（学习逻辑模型）可以标记出缺乏依据的论断和覆盖面上的不足，还可以验证开放式综合分析的连贯性和完整性。

鉴于研究质量的主观性，基于LLM的评分标准应经常与专家的判断进行校准，以便有效地对这些代理人进行评分。

Computer Use Agent

Computer Use Agent通过与人类相同的界面（例如屏幕截图、鼠标点击、键盘输入和滚动）与软件交互，而不是通过 API 或代码执行。它们可以使用任何带有图形用户界面 (GUI) 的应用程序，从设计工具到传统的企业软件。评估需要在真实环境或沙盒环境中运行代理，使其能够使用软件应用程序，并检查其是否达到了预期结果。例如，[WebArena]{.underline}测试基于浏览器的任务，使用 URL 和页面状态检查来验证代理是否正确导航，并对修改数据的任务进行后端状态验证（确认订单是否实际已下达，而不仅仅是确认页面是否出现）。OSWorld[则将]{.underline}评估范围扩展到完整的操作系统控制，其评估脚本会在任务完成后检查各种组件：文件系统状态、应用程序配置、数据库内容和 UI 元素属性。

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

如何思考Agent评估中的非确定性

无论智能体类型如何，智能体的行为在每次运行中都会有所不同，这使得评估结果比乍看之下更难解读。每个任务都有其自身的成功率——例如，某个任务的成功率可能是 90%，而另一个任务的成功率可能是 50%——而且在一次评估运行中通过的任务，在下一次运行中可能就会失败。有时，我们真正想要衡量的是智能体完成某个任务的频率（即在所有试验中取得成功的比例）。

有两个指标可以帮助我们捕捉到这种细微差别：

[pass@k]{.underline}衡量的是智能体在k 次尝试中获得至少一次正确解的概率。随着 k 的增加，pass@k 得分也会提高——“射门次数”越多，至少成功一次的概率就越高。50% 的 pass@1 得分意味着模型在评估任务中首次尝试就成功完成了一半的任务。在编程中，我们通常最关心的是智能体能否在首次尝试就找到解决方案——即 pass@1。但在其他情况下，只要有一个解决方案有效，提出多个解决方案也是有效的。

[pass\^k]{.underline}衡量的是所有 k 次试验都成功的概率。随着k 的增加，pass\^k 会下降，因为要求在更多试验中保持一致性难度更大。如果你的智能体每次试验的成功率为 75%，并且你进行了 3 次试验，那么三次试验全部成功的概率为 (0.75)³ ≈ 42%。对于面向用户的智能体而言，这个指标尤为重要，因为用户期望每次都能获得可靠的服务。

图里对比了两种成功率定义：
- pass@k：k 次尝试里只要有 1 次成功，k 越大成功率越接近 100%；示例里 k=3 时能到 97%。
- pass\^k：k 次尝试必须全部成功，k 越大成功率越低；示例里 k=3 时掉到 39%。
核心：多试一次能提高"至少成功一次"的概率，但会降低"次次都成功"的概率。

随着试验次数的增加，pass@k 和 pass\^k 的值逐渐趋于一致。当 k=1 时，二者完全相同（均代表每次试验的成功率）。但到了 k=10 时，二者的趋势则截然相反：pass@k 接近 100%，而 pass\^k 则降至 0%。

这两个指标都很有用，具体使用哪个取决于产品要求：pass@k 用于一次成功就很重要的工具，pass\^k 用于一致性至关重要的agent。

从零到一：Agent获得优秀评估的路线图

本节阐述了我们经过实践检验的实用建议，帮助您从零开始构建可信赖的评估体系。您可以将其视为评估驱动型智能体开发的路线图：尽早定义成功标准，清晰衡量成功指标，并持续迭代。

收集初始评估数据集的任务

步骤0：尽早开始

我们发现，一些团队因为认为需要数百个任务而推迟构建评估模型。实际上，从真实失败案例中提取 20-50 个简单的任务就是一个很好的开始。毕竟，在智能体开发的早期阶段，对系统的每一次更改通常都会产生清晰可见的影响，而这种较大的影响意味着较小的样本量就足够了。更成熟的智能体可能需要更大、更复杂的评估来检测较小的影响，但在初期最好采用 80/20 法则。评估模型构建的难度会随着等待时间的延长而增加。在早期阶段，产品需求自然而然地转化为测试用例。如果等待时间过长，你就只能从运行中的系统中逆向推导成功标准了。

第一步：从你已经手动测试过的内容开始。

首先从开发过程中运行的手动检查入手——每次发布前都要验证的行为以及最终用户经常尝试的任务。如果产品已经上线，请查看缺陷跟踪系统和支持队列。将用户报告的故障转化为测试用例，可以确保测试套件反映实际使用情况；根据用户影响进行优先级排序，有助于将精力投入到真正重要的地方。

步骤 2：编写明确的任务说明，并附上参考答案。

确保任务质量远比想象中要难。一个好的任务应该能够让两位领域专家独立地得出相同的通过/失败结论。他们自己能通过这项任务吗？如果不能，那么任务就需要改进。任务规范中的模糊之处会成为评估指标中的噪音。同样的道理也适用于基于模型的评分标准：模糊的评分细则会导致判断结果不一致。

每个任务都应该能够被正确执行指令的智能体顺利通过。这一点可能比较微妙。例如，对 Terminal-Bench 的审计发现，如果一个任务要求智能体编写脚本，但没有指定文件路径，而测试又假定脚本位于某个特定的文件路径下，那么智能体可能会在并非自身过错的情况下失败。评分器检查的所有内容都应该在任务描述中清晰明确；智能体不应该因为规范含糊不清而失败。对于前沿模型，多次试验的通过率均为 0%（即 0% pass@100）通常表明任务存在缺陷，而非智能体能力不足，这提示您需要仔细检查任务规范和评分器。对于每个任务，创建一个参考解决方案非常有用：一个已知可行且能够通过所有评分器的输出。这可以证明任务是可解决的，并验证评分器的配置是否正确。

步骤 3：构建均衡的习题集

测试行为应该发生和不应该发生的情况。单向评估会导致单向优化。例如，如果您只测试智能体是否在应该搜索的时候进行搜索，最终可能会得到一个几乎搜索所有内容的智能体。尽量避免[类别不平衡的评估。我们在为Claude.ai]{.underline}构建网络搜索评估时就深有体会。挑战在于既要防止模型在不应该搜索的时候进行搜索，又要保证它在适当的时候能够进行广泛的研究。团队构建的评估涵盖了两个方向：模型应该搜索的查询（例如查找天气）和模型应该根据现有知识回答的查询（例如”谁创立了苹果公司？”）。在触发不足（不应该搜索的时候不搜索）和触发过度（不应该搜索的时候搜索）之间找到合适的平衡点非常困难，需要对提示和评估进行多轮改进。随着更多示例问题的出现，我们会不断增加评估内容，以提高覆盖范围。

设计评估装置和评分器

步骤 4：构建一个具有稳定环境的强大评估框架

评估中使用的代理必须与生产环境中使用的代理功能大致相同，且环境本身不应引入额外的干扰因素。每次试验都应从一个干净的环境开始，从而实现”隔离”。运行之间不必要的共享状态（例如残留文件、缓存数据、资源耗尽）会导致基础设施不稳定，而非代理性能本身的问题，从而引发相关的故障。共享状态还会人为地夸大性能。例如，在一些内部评估中，我们观察到 Claude 通过查看先前试验的 Git 历史记录，在某些任务上获得了不公平的优势。如果多个不同的试验由于环境中的同一限制（例如 CPU 内存不足）而失败，则这些试验并非相互独立，因为它们受到同一因素的影响，因此评估结果对于衡量代理性能而言将变得不可靠。

第五步：精心设计评分标准

如上所述，优秀的评估设计包括为智能体和任务选择最佳评分器。我们建议尽可能选择确定性评分器，在必要时或为了增加灵活性而选择LLM评分器，并谨慎地使用人工评分器进行额外验证。

人们通常倾向于检查智能体是否遵循了非常具体的步骤，例如按正确的顺序调用一系列工具。我们发现这种方法过于僵化，导致测试过于脆弱，因为智能体经常会找到评估设计者未预料到的有效方法。为了避免不必要地扼杀创造力，通常更好的做法是评估智能体最终产出的结果，而不是它所采取的路径。

对于包含多个步骤的任务，应采用部分计分制。一位能够正确识别问题并核实客户身份，但未能成功处理退款的客服人员，其表现也明显优于一位立即失败的客服人员。在结果中体现这种成功与失败的连续性至关重要。

模型评分通常需要反复迭代以验证其准确性。LLM（逻辑推理模型）评分器应与人类专家进行密切校准，以确保模型评分与人类评分之间的差异很小。为避免模型出现错误，应为LLM提供退出机制，例如，当信息不足时返回”未知”。此外，还可以创建清晰、结构化的评分标准，分别对任务的每个维度进行评分，然后使用独立的LLM评分器对每个维度进行评分，而不是使用同一个LLM评分器对所有维度进行评分。一旦系统稳定可靠，只需偶尔进行人工审核即可。

有些评估存在一些不易察觉的故障模式，即使智能体表现良好，也会导致得分偏低，因为智能体由于评分错误、智能体框架限制或歧义而无法完成任务。即使是经验丰富的团队也可能忽略这些问题。例如，[Opus 4.5 最初在 CORE-Bench 测试中得分仅为 42%]{.underline}，直到 Anthropic 的一位研究人员发现了多个问题：评分机制过于僵化，预期得分为”96.124991…“时却被扣分；任务规范含糊不清；以及随机任务难以精确复现。修复错误并使用限制较少的框架后，Opus 4.5 的得分跃升至 95%。类似地，[METR]{.underline}在其时间范围基准测试中发现了几个配置错误的任务，这些任务要求智能体优化到预设的分数阈值，但评分却要求超过该阈值。这导致像 Claude 这样遵循指令的模型受到惩罚，而忽略既定目标的模型反而获得了更高的分数。仔细核对作业和评分者可以避免这些问题。

确保评分系统能够抵御绕过或破解。测试人员不应能够轻易”作弊”通过评估。任务和评分系统的设计应确保及格需要真正解决问题，而不是利用无意中存在的漏洞。

长期维护和使用评估

第六步：查看成绩单

除非您阅读大量试验的记录和成绩，否则您无法了解评分员的工作是否高效。在 Anthropic，我们投资开发了用于查看评估记录的工具，并且我们定期抽出时间阅读这些记录。当任务失败时，记录会告诉您智能体是犯了真正的错误，还是评分员拒绝了有效的解决方案。记录通常还会揭示智能体和评分员行为的关键细节。

失败结果应该公平合理：清楚地说明智能体错在哪里以及错在哪里。当分数没有提升时，我们需要确信这是智能体表现的问题，而不是评估本身的问题。阅读评估记录是验证评估是否真正衡量了关键指标的方法，也是智能体开发的关键技能。

步骤 7：监测能力评估饱和度

100% 的评估结果会追踪退步，但无法提供任何改进的迹象。当智能体通过所有可解决的任务时，评估就会达到饱和，没有改进的空间。例如，SWE-Bench Verified 的初始分数今年为 30%，而前沿模型的饱和度已接近 80% 以上。随着评估接近饱和，进步速度也会放缓，因为只剩下最困难的任务。这可能会使结果具有欺骗性，因为能力的显著提升可能只体现在分数的微小增长上。例如，代码审查初创公司[Qodo]{.underline}最初对 Opus 4.5 的表现并不满意，因为他们的一次性编码评估无法捕捉到在更长、更复杂的任务中取得的进步。为此，他们开发了一个新的智能体评估框架，从而能够更清晰地展现进步情况。

通常情况下，我们不会轻易相信评估分数，而是会深入研究评估细节并阅读一些评估记录。如果评分不公平、任务含糊不清、有效解决方案受到惩罚，或者评估框架限制了模型，则应修改评估结果。

步骤 8：通过开放贡献和维护，保持评估套件的长期健康运行。

评估套件是一个动态的产物，需要持续的关注和明确的所有权才能保持其有效性。

在 Anthropic，我们尝试了多种评估维护方法。事实证明，最有效的方法是建立专门的评估团队来负责核心基础设施，而领域专家和产品团队则负责大部分评估任务 并自行运行评估。

对于人工智能产品团队而言，评估的制定和迭代应该像维护单元测试一样成为日常工作。团队可能会在早期测试中”运行正常”的人工智能功能上浪费数周时间，但这些功能却无法满足未明确设定的预期，而精心设计的评估本应及早发现这些问题。定义评估任务是检验产品需求是否足够具体，从而启动开发的最佳方法之一。

我们建议采用评估驱动开发：在智能体能够实现预期功能之前，先构建评估模型来定义计划的功能，然后迭代开发，直到智能体性能良好。在内部，我们经常构建一些目前”足够好用”的功能，但这些功能实际上是对模型几个月后性能的押注。从较低的通过率开始的能力评估可以清晰地展现这一点。当新模型发布时，快速运行评估套件即可发现哪些押注最终得到了回报。

最了解产品需求和用户的人最能定义成功。借助当前模型的功能，产品经理、客户成功经理或销售人员可以使用 Claude Code 以 PR 的形式提交评估任务——让他们去做吧！或者更好的是，积极地赋能他们。

这张图给出打造高质量评估的路线图，分三阶段：
- Evaluation suite development：尽早开始，先用人工测试，写清晰不含糊的任务，覆盖正反面案例。
- Harness development：搭建稳健的评估框架，并精心设计评分器。
- Eval maintenance：查看评估轨迹，监控是否"测不出差异"（饱和），并长期维护更新。

如何将评估与其他方法结合起来，以全面理解Agent

自动化评估可以在不部署到生产环境或影响真实用户的情况下，对代理进行数千次任务测试。但这只是了解代理性能的众多方法之一。要全面了解Agent性能，还需要进行生产环境监控、用户反馈、A/B 测试、人工转录审核以及系统性的人工评估。

人工智能代理性能理解方法概述

点击图片可查看完整电子表格

这些方法对应于代理开发的不同阶段。自动化评估在上线前和持续集成/持续交付 (CI/CD) 阶段尤为有用，每次Agent变更和模型升级都会运行评估，作为抵御质量问题的第一道防线。上线后，生产监控会启动，以检测分布漂移和意外的实际故障。一旦流量足够，A/B 测试即可验证重大变更。用户反馈和转录文本审查是持续改进的实践——不断筛选反馈，每周阅读样本转录文本，并根据需要进行深入挖掘。系统性的人工研究应保留用于校准 LLM 评分员或评估主观输出，其中人类共识可作为参考标准。

像瑞士奶酪模型，单一评估层有漏洞，多层叠加才能补漏。图中三层分别代表：
自动化评估（基线与回归防护）、
人工对话审阅/早期访问（抓细微和意外问题）、
线上监控/A/B/用户反馈（暴露规模化的罕见场景）。
组合多种方法，降低漏掉问题的概率。

结论

缺乏评估的团队会陷入被动循环——修复一个故障，又制造另一个故障，无法区分真正的回归问题和噪音。而早期投入评估的团队则恰恰相反：随着故障转化为测试用例，测试用例能够预防回归问题，指标取代了猜测，开发速度显著提升。评估为整个团队指明了前进的方向，将”代理感觉更糟”转化为可执行的行动。评估的价值会不断累积，但前提是必须将其视为核心组成部分，而不是事后补救。

不同类型的智能体模式各不相同，但这里描述的基本原则是一致的。尽早开始，不要等待完美的解决方案。从你看到的失败案例中寻找实际的任务。定义明确、可靠的成功标准。精心设计评分器，并结合多种类型。确保问题对模型来说足够困难。不断迭代评估，以提高信噪比。阅读记录！

人工智能代理评估仍是一个新兴且快速发展的领域。随着代理承担更长的任务、在多代理系统中协作以及处理日益主观的工作，我们需要调整我们的评估技术。我们将随着学习的深入，持续分享最佳实践。

附录：评估框架

多个开源和商业框架可以帮助团队实现代理评估，而无需从零开始构建基础设施。合适的框架取决于您的代理类型、现有技术栈，以及您是否需要离线评估、生产环境可观测性或两者兼备。

Harbor 专为在容器化环境中运行代理[而]{.underline}设计，其基础设施支持跨云提供商大规模运行试验，并提供用于定义任务和评分器的标准化格式。诸如 Terminal-Bench 2.0 之类的热门基准测试程序已通过 Harbor 注册表发布，因此可以轻松运行既定的基准测试程序以及自定义评估套件。

Promptfoo[是]{.underline}一个轻量级、灵活且开源的框架，专注于用于提示测试的声明式 YAML 配置，其断言类型涵盖从字符串匹配到 LLM 作为评判标准的各种类型。我们在许多产品评估中使用了 Promptfoo 的一个版本。

Braintrust[是]{.underline}一个将离线评估与生产环境可观测性和实验跟踪相结合的平台，对于需要在开发过程中迭代并监控生产环境质量的团队非常有用。其 `autoevals` 库包含用于评估事实性、相关性和其他常用维度的预构建评分器。

[LangSmith]{.underline}提供追踪、离线和在线评估以及数据集管理功能，并与 LangChain 生态系统紧密集成。

Langfuse提供类似的功能，它是一款可自托管的开源替代方案，适用于有数据驻留要求的团队。

[许多]{.underline}团队会结合使用多种工具，自行构建评估框架，或者仅仅使用简单的评估脚本作为起点。

我们发现，虽然框架可以有效地加速开发进程并实现标准化，但它们的有效性取决于你运行在其中的评估任务的质量。通常情况下，最好的做法是快速选择一个适合你工作流程的框架，然后将精力集中在评估本身，不断迭代编写高质量的测试用例和评分器。

原文链接：https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents