揭秘 AI agents 的 evals

好的评估能帮助团队更有信心地发布 AI agent。没有评估，团队很容易陷入被动循环：只有在生产环境中才发现问题，而修复一个失败又会引入其他失败。Evals（评估）能在问题和行为变化影响用户之前使其可见，而且它们的价值会在 agent 的整个生命周期中持续累积。

正如我们在 Building effective agents 中所描述的，agent 会在多个轮次中运行：调用工具、修改状态，并根据中间结果进行调整。让 AI agent 有用的这些能力——自主性、智能和灵活性——也让它们更难评估。

通过我们的内部工作，以及与 agent 开发前沿客户的合作，我们学会了如何为 agent 设计更严格、更有用的 evals。以下是在真实部署中、跨多种 agent 架构和用例被验证有效的方法。

Evaluation（“eval”）是针对 AI 系统的测试：给 AI 一个输入，然后对其输出应用评分逻辑来衡量是否成功。在本文中，我们关注的是可在开发期间运行、且不需要真实用户参与的自动化 evals。

单轮 evaluation 很直接：一个 prompt、一个 response，以及评分逻辑。对于早期 LLM，单轮、非 agentic evals 是主要的评估方法。随着 AI 能力提升，多轮 evaluations 变得越来越常见。

Agent evaluations 更复杂。Agent 会在多个轮次中使用工具，修改环境中的状态，并在过程中不断调整——这意味着错误可能传播并累积。Frontier models 也可能找到超出静态 eval 限制的创造性解法。例如，Opus 4.5 通过发现政策中的漏洞，解决了一个关于预订航班的 𝜏2-bench 问题。按评估文本来看它“失败”了，但实际上为用户提出了更好的解决方案。

在构建 agent evaluations 时，我们使用以下定义：

当团队刚开始构建 agent 时，靠手动测试、dogfooding 和直觉的组合，往往能走得出人意料地远。更严格的 evaluation 甚至可能看起来像是拖慢发布的额外负担。但在早期原型阶段之后，一旦 agent 进入生产环境并开始扩展，没有 evals 的构建方式就会开始失效。

临界点通常出现在用户反馈 agent 在修改后变差，而团队却“盲飞”，除了猜测和试错之外没有验证方法。没有 evals，debugging 就是被动的：等待投诉、手动复现、修复 bug，然后希望没有其他地方回退。团队无法区分真实 regression 和噪声，无法在发布前自动用数百个场景测试变更，也无法衡量改进。

我们多次见过这种过程。例如，Claude Code 一开始依靠 Anthropic 员工和外部用户的反馈快速迭代。后来，我们加入了 evals——先是针对简洁性和文件编辑等狭窄领域，随后扩展到 over-engineering 等更复杂的行为。这些 evals 帮助识别问题、指导改进，并聚焦研究与产品之间的协作。结合生产监控、A/B tests、用户研究等，evals 为 Claude Code 在规模化过程中持续改进提供了信号。

在 agent 生命周期的任何阶段编写 evals 都是有用的。早期，evals 迫使产品团队明确 agent 的成功标准；后期，它们帮助维持一致的质量基准。

Descript 的 agent 帮助用户编辑视频，因此他们围绕成功编辑工作流的三个维度构建 evals：不要破坏内容、完成我的要求、并且做得好。他们从人工评分演进到 LLM graders，由产品团队定义 criteria 并定期进行人工校准；现在，他们会定期运行两套独立 suite，分别用于质量 benchmarking 和 regression testing。Bolt AI 团队开始构建 evals 的时间更晚，当时他们已经有了一个被广泛使用的 agent。3 个月内，他们构建了一个 eval system，可以运行他们的 agent，并用 static analysis 对输出评分，使用 browser agents 测试 apps，还用 LLM judges 评估 instruction following 等行为。

有些团队在开发之初就创建 evals；另一些团队则在规模化之后，当 evals 成为改进 agent 的瓶颈时才添加它们。Evals 在 agent 开发初期尤其有用，因为它们可以显式编码预期行为。两个工程师阅读同一份初始 spec，可能会对 AI 应如何处理 edge cases 得出不同理解。一个 eval suite 可以消除这种歧义。无论何时创建，evals 都有助于加速开发。

Evals 也会影响你采用新模型的速度。当更强大的模型发布时，没有 evals 的团队可能面临数周测试；而有 evals 的竞争者则能快速确定模型优势、调优 prompts，并在数天内完成升级。

一旦有了 evals，你就自然获得了 baselines 和 regression tests：latency、token usage、每项任务成本和 error rates 都可以在一组静态任务上跟踪。Evals 也可以成为产品和研究团队之间带宽最高的沟通渠道，定义研究人员可以优化的 metrics。显然，evals 的好处远不止跟踪 regressions 和 improvements。由于成本一开始就很明显，而收益是在之后累积的，因此它们的复利价值很容易被低估。

今天，我们看到几类常见 agent 已经规模化部署，包括 coding agents、research agents、computer use agents 和 conversational agents。每一类 agent 都可能部署在多种行业中，但可以用相似技术进行评估。你不需要从零发明 evaluation。下面几节描述了几类 agent 的成熟技术。可以将这些方法作为基础，再扩展到你的领域。

Agent evaluations 通常结合三类 graders：code-based、model-based 和 human。每个 grader 会评估 transcript 或 outcome 的某一部分。有效 evaluation 设计的关键组成部分，是为任务选择合适的 graders。

对于每项任务，评分可以是加权的（组合后的 grader 分数必须达到阈值）、二元的（所有 graders 都必须通过），或二者的混合。

Capability 或“quality” evals 会问：“这个 agent 能做好什么？”它们的初始通过率应该较低，目标是 agent 目前困难的任务，让团队有一座可以攀登的山。

Regression evals 会问：“这个 agent 是否仍能处理过去能处理的所有任务？”通过率应接近 100%。它们防止退步，因为分数下降意味着某处出了问题，需要改进。当团队在 capability evals 上爬坡时，也要运行 regression evals，确保变更不会在其他地方引入问题。

Agent 发布并优化后，通过率较高的 capability evals 可以“毕业”为 regression suite，并持续运行以捕捉任何漂移。过去用于衡量“我们到底能不能做到？”的任务，之后会衡量“我们是否仍能可靠做到？”

Coding agents 会编写、测试和 debug code，像人类开发者一样浏览 codebases 并运行 commands。现代 coding agents 的有效 evals 通常依赖定义清晰的任务、稳定的测试环境，以及对生成代码的全面测试。

Deterministic graders 很适合 coding agents，因为软件通常比较容易评估：代码能否运行，tests 是否通过？两个广泛使用的 coding agent benchmarks，SWE-bench Verified 和 Terminal-Bench，都采用这种方法。SWE-bench Verified 向 agents 提供热门 Python repositories 中的 GitHub issues，并通过运行 test suite 来评分；只有在修复失败 tests 且不破坏现有 tests 的情况下，solution 才算通过。LLMs 在这个 eval 上仅一年就从 40% 提升到 >80%。Terminal-Bench 走的是另一条路线：它测试端到端技术任务，例如从源码构建 Linux kernel，或训练一个 ML model。

一旦你有了一组用于验证 coding task 关键 outcome 的 pass-or-fail tests，通常也值得对 transcript 进行评分。例如，基于 heuristics 的代码质量规则可以在通过 tests 之外评估生成代码，而带有清晰 rubrics 的 model-based graders 可以评估 agent 如何调用工具或与用户交互等行为。

示例：coding agent 的理论 evaluation

考虑一个 coding task，其中 agent 必须修复一个 authentication bypass vulnerability。如下方用于说明的 YAML 文件所示，可以同时使用 graders 和 metrics 来评估该 agent。

请注意，这个示例是为了说明而展示了全部可用 grader 类型。实践中，coding evaluations 通常依赖 unit tests 进行 correctness verification，并使用 LLM rubric 评估整体代码质量，只有在需要时才添加额外 graders 和 metrics。

Conversational agents 在 support、sales 或 coaching 等领域与用户交互。不同于传统 chatbots，它们会维护状态、使用工具，并在对话中途采取行动。虽然 coding 和 research agents 也可能涉及多轮与用户交互，但 conversational agents 提出了一个独特挑战：交互本身的质量就是你要评估的内容之一。Conversational agents 的有效 evals 通常依赖可验证的 end-state outcomes，以及能够捕捉任务完成情况和交互质量的 rubrics。不同于大多数其他 evals，它们通常需要第二个 LLM 来模拟用户。我们在 alignment auditing agents 中使用这种方法，通过长时间、对抗性对话对模型进行 stress-test。

Conversational agents 的成功可能是多维的：ticket 是否已解决（state check）、是否在 <10 turns 内完成（transcript constraint）、语气是否合适（LLM rubric）？两个体现多维性的 benchmarks 是 𝜏-Bench 及其后继者 τ2-Bench。它们模拟 retail support 和 airline booking 等领域中的多轮交互，其中一个模型扮演 user persona，而 agent 则在真实感场景中完成任务。

示例：conversational agent 的理论 evaluation

考虑一个 support task，其中 agent 必须为一位沮丧的客户处理退款。

与我们的 coding agent 示例一样，这项任务展示了多种 grader 类型用于说明。实践中，conversational agent evaluations 通常使用 model-based graders 来评估沟通质量和目标完成情况，因为许多任务——例如回答问题——可能有多个“正确”解法。

Research agents 收集、综合和分析信息，然后生成答案或报告等输出。不同于 coding agents 中 unit tests 提供二元 pass/fail 信号，research quality 只能相对于任务来判断。什么算“全面”、“来源充分”，甚至“正确”，都取决于上下文：市场扫描、收购尽调和科学报告各自需要不同标准。

Research evals 面临独特挑战：专家可能不同意某个 synthesis 是否全面，ground truth 会随着参考内容持续变化而改变，较长且更开放的输出也为错误留下更多空间。例如，BrowseComp 这样的 benchmark 会测试 AI agents 是否能在开放 web 中大海捞针——问题被设计成容易验证但难以解决。

构建 research agent evals 的一种策略是结合多种 grader 类型。Groundedness checks 验证 claims 是否由检索到的 sources 支持，coverage checks 定义优秀答案必须包含的关键 facts，source quality checks 确认咨询的 sources 具有权威性，而不只是最先检索到的来源。对于有客观正确答案的任务（“Company X 的 Q3 revenue 是多少？”），exact match 可行。LLM 可以标记 unsupported claims 和 coverage gaps，也可以验证开放式 synthesis 的 coherence 和 completeness。

鉴于 research quality 的主观性，要有效给这些 agents 评分，基于 LLM 的 rubrics 应频繁根据专家人工判断进行校准。

Computer use agents 通过与人类相同的界面与软件交互——screenshots、mouse clicks、keyboard inputs 和 scrolling——而不是通过 APIs 或 code execution。它们可以使用任何带有 graphical user interface（GUI）的 application，从设计工具到 legacy enterprise software。Evaluation 需要在真实或 sandboxed environment 中运行 agent，使其能够使用软件应用，并检查它是否达成预期 outcome。例如，WebArena 测试 browser-based tasks，使用 URL 和 page state checks 验证 agent 是否正确导航，并对会修改数据的任务进行 backend state verification（确认订单确实已下单，而不只是出现了确认页面）。OSWorld 将其扩展到完整 operating system control，使用 evaluation scripts 在任务完成后检查多种 artifacts：file system state、application configs、database contents 和 UI element properties。

Browser use agents 需要在 token efficiency 和 latency 之间取得平衡。基于 DOM 的交互执行很快，但消耗许多 tokens；基于 screenshot 的交互更慢，但更节省 tokens。例如，当要求 Claude 总结 Wikipedia 时，从 DOM 提取文本更高效。当在 Amazon 上寻找新的 laptop case 时，截取 screenshots 更高效（因为提取整个 DOM 会消耗大量 tokens）。在我们的 Claude for Chrome 产品中，我们开发了 evals 来检查 agent 是否为每个上下文选择了正确工具。这使我们能更快、更准确地完成 browser-based tasks。

无论 agent 类型如何，agent 行为在不同运行之间都会变化，这让 evaluation results 比乍看起来更难解释。每项任务都有自己的成功率——可能某个任务是 90%，另一个是 50%——而在一次 eval run 中通过的任务，下一次可能失败。有时，我们想衡量的是 agent 在某项任务中成功的频率（即 trials 的比例）。

两个 metrics 有助于捕捉这种细微差别：

pass@k 衡量 agent 在 k 次尝试中至少得到一个正确 solution 的可能性。随着 k 增大，pass@k score 会升高：更多“射门机会”意味着至少成功 1 次的概率更高。50% pass@1 表示模型在 eval 中一半的任务上第一次尝试就成功。在 coding 中，我们通常最关心 agent 第一次尝试就找到 solution——pass@1。在其他情况下，提出多个 solutions 是可以接受的，只要其中一个有效即可。

pass^k 衡量所有 k 次 trials 都成功的概率。随着 k 增大，pass^k 会下降，因为要求更多 trials 都保持一致成功，是更高的门槛。如果你的 agent 每次 trial 的成功率是 75%，并运行 3 次 trials，那么三次都通过的概率是 (0.75)³ ≈ 42%。这个 metric 对 customer-facing agents 尤其重要，因为用户期望每次都有可靠行为。

这两个 metrics 都有用，使用哪个取决于产品需求：对于只要一次成功即可的工具，用 pass@k；对于一致性至关重要的 agents，用 pass^k。

本节给出我们从没有 evals 到构建可信 evals 的实用、经现场验证的建议。可以把它看作 eval-driven agent development 的路线图：尽早定义成功，清晰衡量，并持续迭代。

Step 0. 尽早开始

我们看到一些团队推迟构建 evals，因为他们认为需要数百项任务。实际上，从真实失败中抽取 20-50 个简单任务就是很好的起点。毕竟，在 agent 开发早期，系统的每个变更通常都有清晰、可观察的影响，而这种较大的 effect size 意味着小样本量已经足够。更成熟的 agents 可能需要更大、更困难的 evals 来检测较小效果，但一开始最好采用 80/20 方法。等待越久，evals 就越难构建。早期，产品需求会自然转化为 test cases。等得太久，你就只能从 live system 反向推导 success criteria。

Step 1. 从你已经手动测试的内容开始

从开发期间执行的手动检查开始——也就是每次发布前验证的 behaviors，以及最终用户常尝试的 common tasks。如果你已经进入生产环境，查看 bug tracker 和 support queue。将用户报告的 failures 转换为 test cases，能确保你的 suite 反映真实使用情况；按用户影响优先级排序，有助于把精力投入到最重要的地方。

Step 2: 编写无歧义任务和 reference solutions

把 task quality 做好比看起来更难。好的任务是两个 domain experts 独立判断时会得到相同 pass/fail verdict 的任务。他们自己能完成这项任务吗？如果不能，任务就需要细化。任务说明中的歧义会成为 metrics 中的噪声。model-based graders 的 criteria 也是如此：模糊的 rubrics 会产生不一致的判断。

每项任务都应该能被一个正确遵循 instructions 的 agent 完成。这一点可能很微妙。例如，对 Terminal-Bench 的审计显示，如果任务要求 agent 编写一个 script，但没有指定 filepath，而 tests 假定该 script 位于某个特定 filepath，那么 agent 可能并非自身错误却失败。Grader 检查的所有内容都应从任务描述中清楚得出；agents 不应因为 spec 模糊而失败。对于 frontier models，如果在许多 trials 中通过率为 0%（即 0% pass@100），最常见的信号不是 agent 无能，而是任务有问题，并提示你重新检查 task specification 和 graders。对于每项任务，创建一个 reference solution 很有用：一个已知可工作、能通过所有 graders 的输出。这证明任务可解，也验证 graders 配置正确。

Step 3: 构建均衡的问题集

既要测试某个 behavior 应该发生的情况，也要测试它不应该发生的情况。单边 evals 会导致单边优化。例如，如果你只测试 agent 在应该搜索时是否搜索，最终可能得到一个几乎什么都搜索的 agent。尽量避免 class-imbalanced evals。我们在为 Claude.ai 中的 web search 构建 evals 时亲身学到了这一点。挑战在于防止模型在不该搜索时搜索，同时保留其在适当情况下进行深入研究的能力。团队构建了覆盖两个方向的 evals：模型应该搜索的 queries（例如查询天气），以及模型应该用已有知识回答的 queries（例如“谁创立了 Apple？”）。在 undertriggering（该搜索时不搜索）和 overtriggering（不该搜索时搜索）之间取得适当平衡很难，需要对 prompts 和 eval 进行多轮 refinement。随着更多示例问题出现，我们会继续加入 evals，以改善覆盖范围。

Step 4: 用稳定环境构建稳健的 eval harness

Eval 中的 agent 必须与生产中使用的 agent 大体相同，且环境本身不应引入额外噪声。每次 trial 都应从干净环境开始，实现“隔离”。运行之间不必要的 shared state（残留文件、缓存数据、资源耗尽）可能因基础设施不稳定而非 agent performance 导致相关失败。Shared state 也可能人为抬高 performance。例如，在一些内部 evals 中，我们观察到 Claude 通过检查之前 trials 的 git history，在某些任务上获得了不公平优势。如果多个不同 trials 因环境中的同一限制（如 CPU memory 有限）而失败，这些 trials 就不是独立的，因为它们受到同一因素影响，eval results 也就无法可靠衡量 agent performance。

Step 5: 认真设计 graders

如上所述，优秀的 eval design 包括为 agent 和 tasks 选择最合适的 graders。我们建议尽可能选择 deterministic graders，在必要时或需要额外灵活性时选择 LLM graders，并审慎使用 human graders 做额外验证。

一种常见直觉是检查 agents 是否按非常具体的步骤执行，例如按正确顺序进行一系列 tool calls。我们发现这种方法过于僵硬，会导致 tests 过于脆弱，因为 agents 经常会找到 eval designers 未预料到的有效方法。为了不不必要地惩罚创造性，通常最好评价 agent 产出了什么，而不是它走了什么路径。

对于包含多个组件的任务，应引入 partial credit。一个 support agent 如果正确识别问题并验证客户，但未能处理退款，仍明显好于一开始就失败的 agent。在结果中呈现这种成功连续体很重要。

Model grading 往往需要仔细迭代以验证准确性。LLM-as-judge graders 应与人类专家密切校准，以确信 human grading 和 model grading 之间几乎没有分歧。为避免 hallucinations，应给 LLM 一个退路，例如指示其在信息不足时返回“Unknown”。创建清晰、结构化的 rubrics 来为任务的每个维度评分也有帮助；随后用隔离的 LLM-as-judge 分别评分每个维度，而不是用一个 LLM 给所有维度评分。一旦系统足够稳健，人工 review 只需偶尔进行即可。

有些 evaluations 存在微妙的 failure modes，即使 agent performance 很好，也会由于 grading bugs、agent harness constraints 或歧义导致低分，因为 agent 未能解决任务。即使成熟团队也可能遗漏这些问题。例如，Opus 4.5 最初在 CORE-Bench 上得分为 42%，直到一位 Anthropic 研究员发现了多个问题：rigid grading 会在期望 “96.124991…” 时惩罚 “96.12”，任务 spec 存在歧义，以及 stochastic tasks 无法精确复现。修复 bugs 并使用限制更少的 scaffold 后，Opus 4.5 的分数跃升到 95%。类似地，METR 在其 time horizon benchmark 中发现了多个配置错误的任务：这些任务要求 agents 优化到一个声明的 score threshold，但 grading 要求超过该 threshold。这惩罚了像 Claude 这样遵循 instructions 的模型，而忽略声明目标的模型反而得分更高。仔细复查 tasks 和 graders 可以帮助避免这些问题。

让你的 graders 能抵抗 bypasses 或 hacks。Agent 不应能轻易“作弊”通过 eval。Tasks 和 graders 的设计应确保通过确实需要解决问题，而不是利用意外漏洞。

Step 6: 检查 transcripts

除非你阅读大量 trials 的 transcripts 和 grades，否则你不会知道 graders 是否工作良好。在 Anthropic，我们投入了用于查看 eval transcripts 的工具，并定期花时间阅读它们。当一项任务失败时，transcript 会告诉你 agent 是否确实犯了错误，还是 graders 拒绝了一个有效 solution。它也经常揭示 agent 和 eval behavior 的关键细节。

Failures 应该看起来公平：清楚知道 agent 错在哪里以及为什么错。当分数不上升时，我们需要确信原因是 agent performance，而不是 eval。阅读 transcripts 是验证 eval 是否衡量真正重要内容的方法，也是 agent development 的关键技能。

Step 7: 监控 capability eval saturation

一个达到 100% 的 eval 能跟踪 regressions，但无法提供改进信号。当 agent 通过所有可解任务、没有提升空间时，就发生 eval saturation。例如，SWE-Bench Verified 分数今年从 30% 起步，而 frontier models 现在已接近 >80% 的饱和。随着 evals 接近饱和，progress 也会放缓，因为只剩下最困难的任务。这可能让结果具有误导性，因为大的能力提升在分数上表现为小幅增加。例如，code review startup Qodo 最初对 Opus 4.5 印象不深，因为他们的 one-shot coding evals 没有捕捉到更长、更复杂任务上的收益。作为回应，他们开发了新的 agentic eval framework，从而更清晰地呈现 progress。

一般来说，在有人深入了解 eval 细节并阅读一些 transcripts 之前，我们不会按表面值接受 eval scores。如果 grading 不公平、tasks 有歧义、有效 solutions 被惩罚，或 harness 限制了模型，就应修订 eval。

Step 8: 通过开放贡献和维护，长期保持 evaluation suites 健康

Eval suite 是一个活的 artifact，需要持续关注和明确 ownership，才能保持有用。

在 Anthropic，我们尝试过多种 eval maintenance 方法。事实证明最有效的是建立专门的 evals teams 负责核心基础设施，同时由 domain experts 和 product teams 贡献大多数 eval tasks，并自行运行 evaluations。

对于 AI 产品团队，拥有并迭代 evaluations 应该像维护 unit tests 一样常规。团队可能会在早期测试中“能用”但无法满足隐含预期的 AI features 上浪费数周，而设计良好的 eval 本可以早早暴露这些预期。定义 eval tasks 是 stress-test 产品需求是否足够具体、可以开始构建的最佳方式之一。

我们建议实践 eval-driven development：在 agents 能实现计划能力之前，先构建 evals 来定义这些能力，然后迭代直到 agent 表现良好。在内部，我们经常构建今天“足够好”可用、但实际上押注模型几个月后能力的 features。初始通过率较低的 capability evals 会让这一点可见。当新模型发布时，运行 suite 能快速揭示哪些押注兑现了。

最接近产品需求和用户的人最适合定义成功。以当前模型能力，product managers、customer success managers 或 salespeople 可以使用 Claude Code 以 PR 形式贡献 eval task——让他们这样做！或者更好的是，主动支持他们这样做。

Automated evaluations 可以在数千项任务上针对 agent 运行，而无需部署到生产环境，也不会影响真实用户。但这只是理解 agent performance 的多种方法之一。完整图景包括 production monitoring、user feedback、A/B testing、manual transcript review 和 systematic human evaluation。

这些方法对应 agent development 的不同阶段。Automated evals 在上线前和 CI/CD 中尤其有用，会在每次 agent change 和 model upgrade 时运行，作为防止质量问题的第一道防线。Production monitoring 在上线后发挥作用，用于检测 distribution drift 和未预料到的真实世界 failures。当你有足够流量后，A/B testing 可验证重大变更。User feedback 和 transcript review 是持续实践，用来填补空白：持续 triage feedback，每周抽样阅读 transcripts，并在需要时深入调查。Systematic human studies 应保留给 LLM graders 的校准，或用于评估以人类共识为 reference standard 的主观输出。

最有效的团队会结合这些方法：用 automated evals 支持快速迭代，用 production monitoring 获取 ground truth，并通过定期 human review 做校准。

没有 evals 的团队会陷入被动循环——修复一个失败，又制造另一个失败，无法区分真实 regressions 和噪声。早期投入 evals 的团队则会发现相反情况：随着 failures 变成 test cases、test cases 防止 regressions、metrics 取代猜测，开发会加速。Evals 给整个团队一个清晰的攀登目标，把“agent 感觉变差了”转化为可行动的问题。价值会持续累积，但前提是你把 evals 当作核心组件，而不是事后补充。

不同 agent 类型的模式各不相同，但本文描述的基本原则是不变的。尽早开始，不要等待完美 suite。从你看到的 failures 中提取真实任务。定义无歧义、稳健的 success criteria。认真设计 graders，并结合多种类型。确保问题对模型来说足够难。持续迭代 evaluations，提高它们的 signal-to-noise ratio。阅读 transcripts！

AI agent evaluation 仍是一个新兴且快速演进的领域。随着 agents 承担更长任务、在 multi-agent systems 中协作，并处理越来越主观的工作，我们需要调整技术。随着学习加深，我们会继续分享 best practices。

作者：Mikaela Grace、Jeremy Hadfield、Rodrigo Olivares 和 Jiri De Jonghe。我们也感谢 David Hershey、Gian Segato、Mike Merrill、Alex Shaw、Nicholas Carlini、Ethan Dixon、Pedram Navid、Jake Eaton、Alyssa Baum、Lina Tawfik、Karen Zhou、Alexander Bricken、Sam Kennedy、Robert Ying 以及其他人的贡献。特别感谢我们通过 evals 合作而从中学习的客户和合作伙伴，包括 iGent、Cognition、Bolt、Sierra、Vals.ai、Macroscope、PromptLayer、Stripe、Shopify、Terminal Bench 团队等。这项工作反映了多个团队的共同努力，他们帮助在 Anthropic 发展了 evaluations 的实践。

一些 open-source 和 commercial frameworks 可以帮助团队实现 agent evaluations，而无需从零构建基础设施。正确选择取决于你的 agent 类型、现有 stack，以及你是否需要 offline evaluation、production observability，或两者都需要。Harbor 旨在让 agents 在 containerized environments 中运行，提供跨 cloud providers 大规模运行 trials 的基础设施，并提供用于定义 tasks 和 graders 的标准化格式。Terminal-Bench 2.0 等热门 benchmarks 通过 Harbor registry 发布，因此很容易同时运行成熟 benchmarks 和自定义 eval suites。Braintrust 是一个结合 offline evaluation、production observability 和 experiment tracking 的平台——适合既需要在开发期间迭代、又需要在生产中监控质量的团队。其 autoevals library 包含用于 factuality、relevance 和其他常见维度的预构建 scorers。LangSmith 提供 tracing、offline 和 online evaluations，以及 dataset management，并与 LangChain ecosystem 深度集成。Langfuse 提供类似能力，是面向有 data residency requirements 团队的 self-hosted open-source 替代方案。

Arize 提供 Phoenix，这是一个用于 LLM tracing、debugging 以及 offline 或 online evaluations 的 open-source platform；还提供 AX，这是一个 SaaS offering，将 Phoenix 扩展到 scale、optimization 和 monitoring。许多团队会结合多种工具，自建 eval framework，或一开始只使用简单的 evaluation scripts。我们发现，虽然 frameworks 可以有效加速进展并实现标准化，但它们的效果取决于你通过它们运行的 eval tasks。通常最好的做法是快速选择一个适合你 workflow 的 framework，然后把精力投入 evals 本身：不断迭代高质量 test cases 和 graders。