正是那些让智能体（Agent）变得有用的能力，同时也让它们难以被评测。在各种部署中行之有效的策略，往往结合了多种技术，以匹配其所测系统的复杂性。

1. 引言
   =====

优秀的评测（Evaluations，简称 Evals）能帮助团队更自信地发布 AI 智能体。如果没有评测，团队很容易陷入被动的循环，只有在生产环境中才能发现问题，而修复一个故障往往又引发其他故障。评测能让问题和行为变化在影响用户之前显现出来，其价值会在智能体的整个生命周期中产生复利效应。

正如我们在《构建高效智能体》一文中所述，智能体通过多轮交互进行操作：调用工具、修改状态以及根据中间结果进行调整。正是这些让 AI 智能体变得有用的能力，自主性、智能性和灵活性，同时也让它们更难被评估。

通过我们的内部工作以及与处于智能体开发前沿的客户合作，我们学会了如何为智能体设计更严谨、更实用的评测。以下是在真实世界的各种智能体架构和用例中行之有效的方法。

2. 评测的结构
   ========

一项评测（Evaluation/Eval）是对 AI 系统的一种测试：给 AI 一个输入，然后对其输出应用评分逻辑来衡量成功与否。在本文中，我们重点关注自动化评测，即可以在开发过程中运行而无需真实用户的评测。

单轮评测很简单：一个提示词（Prompt）、一个响应和评分逻辑。对于早期的 LLM，单轮、非智能体的评测是主要的评估方法。随着 AI 能力的进步，多轮评测变得越来越普遍。

在简单的评测中，智能体处理一个提示词，评分器检查输出是否符合预期。而在更复杂的多轮评测中，一个编程智能体接收工具、任务（例如构建一个 MCP 服务器）和环境，执行“智能体循环”（工具调用和推理），并用实现代码更新环境。然后，评分利用单元测试来验证 MCP 服务器是否工作正常。

智能体评测更为复杂。智能体在多轮交互中使用工具，修改环境中的状态并随之调整，这意味着错误会传播和累积。前沿大模型还能找到超越静态评测限制的创造性解决方案。例如，Opus 4.5 在解决一个关于预订航班的 τ2-bench 问题时，发现了一个策略漏洞。虽然它在书面评测上“失败”了，但实际上为用户提供了一个更好的解决方案。

在构建智能体评测时，我们使用以下定义：

任务（Task）（也称为问题或测试用例）：具有定义的输入和成功标准的单个测试。

每次执行任务的尝试称为一次试验（Trial）。由于模型输出在不同运行间存在差异，我们会运行多次试验以产生更一致的结果。

评分器（Grader）：对智能体表现的某些方面进行评分的逻辑。一个任务可以有多个评分器，每个评分器包含多个断言（有时称为检查）。

记录（Transcript）（也称为轨迹 (Trace)或路径 (Trajectory)）：试验的完整记录，包括输出、工具调用、推理、中间结果以及任何其他交互。对于 Anthropic API，这是评测结束时完整的消息数组，包含评测期间对 API 的所有调用和所有返回的响应。

结果（Outcome）：试验结束时环境的最终状态。一个订票智能体可能会在记录末尾说“您的航班已预订”，但“结果”是指环境的 SQL 数据库中是否存在该预订记录。

评测框架（Evaluation Harness）：端到端运行评测的基础设施。它提供指令和工具，并发运行任务，记录所有步骤，对输出评分并汇总结果。

智能体框架（Agent Harness）（或脚手架 (Scaffold)）：使模型能够充当智能体的系统：它处理输入，编排工具调用并返回结果。当我们评估“一个智能体”时，我们评估的是框架和模型的协同工作。例如，Claude Code 是一个灵活的智能体框架，我们通过 Agent SDK 使用其核心原语构建了我们的长期运行智能体框架。

评测套件（Evaluation Suite）：旨在衡量特定能力或行为的任务集合。套件中的任务通常共享一个广泛的目标。例如，客户支持评测套件可能会测试退款、取消和升级处理。

3. 为什么要构建评测？
   ============

在智能体团队的初创阶段，通过手动测试、内部试用（Dogfooding）与经验判断三者结合，往往能实现快速突破。此时，严谨的评测体系看似会拖累迭代节奏，甚至被视作产品发布的阻碍。但跨过早期原型验证阶段，当智能体正式投入生产并启动规模化扩张后，缺乏评测的开发模式将迅速陷入困境。

这种困境的爆发点，通常是用户反馈功能迭代后体验下滑，而团队却陷入 “盲飞” 状态，除了主观猜测与零散排查，没有任何手段验证问题根源。缺少评测体系的支撑，调试工作只能被动响应：等待用户投诉、手动复现故障、针对性修复问题，最后只能寄望于改动不会引发新的连锁问题。团队既无法区分真实的性能退化与偶发的噪声干扰，也无法在发布前对数百种场景开展自动化变更验证，更无从量化迭代带来的实际改进。

这样的困境在行业内并非个例。以 Claude Code 的迭代历程为例，其早期完全依靠 Anthropic 内部员工与外部用户的反馈进行快速优化；随着产品成熟，团队才逐步引入评测体系，先聚焦简洁性、文件编辑等细分场景建立评估标准，随后将覆盖范围拓展至过度工程化等复杂行为的校验。这套评测体系不仅帮助团队精准定位问题、指引优化方向，更有效打通了研究与产品团队的协作链路。结合生产监控、A/B 测试、用户研究等手段，评测体系为 Claude Code 的规模化扩张提供了持续迭代的核心依据。

事实上，评测体系在智能体的全生命周期中都能发挥关键作用。在产品早期，它能倒逼团队清晰定义智能体的成功标准；进入成熟阶段后，又能成为维持产品质量稳定性的核心抓手。

不同团队的实践路径也印证了评测的价值。例如，Descript 旗下的智能体主打视频编辑功能，团队围绕编辑工作流的核心诉求，从 “不破坏原有内容”“精准执行用户指令”“输出高质量结果” 三个维度构建评测体系。其评估方式也从最初的人工评分，演进为 “产品团队定义标准 + 定期人工校准” 的大模型评分机制，目前已实现质量基准测试与回归测试两大套件的常态化运行。而 Bolt AI 团队的实践则呈现另一种路径，他们在智能体实现广泛应用后才启动评测体系建设，仅用 3 个月就搭建起一套完整的评估系统：通过运行智能体并对输出结果做静态分析、基于浏览器智能体开展应用测试、借助大模型评审器评估指令遵循度等核心能力。

行业实践中，有的团队选择在开发初期就搭建评测体系，也有团队在规模化扩张后、因缺乏评估手段导致迭代瓶颈时才着手建设。值得强调的是，早期构建评测体系的价值尤为突出，它能将团队对智能体的预期行为进行显性化、标准化定义，有效解决工程师因对初始规范理解差异而产生的边缘场景处理分歧。无论选择何时启动建设，评测体系最终都能成为加速智能体迭代的核心驱动力。

评测体系的价值还体现在模型升级的效率上。当性能更优的新模型问世时，缺乏评测体系的团队往往需要投入数周时间开展兼容性测试；而拥有成熟评测体系的团队，仅需几天就能完成新模型的优势分析、提示词调优与版本升级。

一旦评测体系落地，团队还能免费获得两大核心能力：一是基准线监测，可在静态任务库中持续跟踪延迟、Token 消耗量、单任务成本与错误率等关键指标；二是自动化回归测试，保障每次迭代的安全性。此外，评测体系还能成为产品与研究团队之间的高效沟通桥梁，为研究人员明确需要优化的量化指标。

显然，评测体系的价值远不止于跟踪性能退化与优化效果。尽管搭建评测体系的成本是即时可见的，但其收益会随着产品迭代持续累积，这种复利式的价值往往容易被团队忽视。

这份完整版的大模型 AI 学习和面试资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】

4. 如何评测 AI 智能体
   ==============

我们看到目前大规模部署了几种常见类型的智能体，包括编程智能体、研究智能体、计算机操作智能体和对话智能体。每种类型都可以部署在各行各业，但可以使用类似的技术进行评估。你不需要从头发明评测方法。以下部分描述了几种智能体类型的成熟技术。使用这些方法作为基础，然后扩展到你的领域。

4.1 智能体评分器的类型

智能体评测通常结合三种类型的评分器：基于代码的、基于模型的和人工的。每个评分器评估记录（Transcript）或结果（Outcome）的某些部分。有效评测设计的一个重要组成部分是为工作选择合适的评分器。

基于代码的评分器 (Code-based graders)

方法：字符串匹配检查（精确、正则、模糊等）、二元测试（失败转通过、通过转通过）、静态分析（lint、类型、安全）、结果验证、工具调用验证（使用的工具、参数）、记录分析（轮次、Token 使用量）。

优点：快速、便宜、客观、可复现、易于调试、验证特定条件。

缺点：对不完全匹配预期模式的有效变体脆弱、缺乏细微差别、限制了对某些更主观任务的评估。

基于模型的评分器 (Model-based graders)

方法：基于量表的评分、自然语言断言、成对比较、基于参考的评估、多法官共识。

优点：灵活、可扩展、捕捉细微差别、处理开放式任务、处理自由形式输出。

缺点：非确定性、比代码更昂贵、需要与人工评分器校准以保证准确性。

人工评分器 (Human graders)

方法：领域专家（SME）审查、众包判断、抽样检查、A/B 测试、标注者一致性。

优点：黄金标准质量、匹配专家用户判断、用于校准基于模型的评分器。

缺点：昂贵、缓慢、往往需要大规模接触人类专家。

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

4.2 能力评测 vs. 回归评测

能力（Capability）或“质量”评测问的是“这个智能体能做好什么？”，它们应该从较低的通过率开始，针对智能体难以处理的任务，给团队一个攀登的目标。

回归（Regression）评测问的是“智能体还能处理它过去能处理的所有任务吗？”，并且应该有接近 100% 的通过率。它们防止倒退，因为分数的下降表明某些东西坏了需要改进。当团队在能力评测上攀登时，运行回归评测以确保变更不会导致其他地方出现问题也很重要。

在智能体发布并优化后，具有高通过率的能力评测可以“毕业”成为回归套件，持续运行以捕捉任何漂移。曾经衡量“我们要不要做这件事？”的任务，随后变成了衡量“我们还能可靠地做这件事吗？”。

4.3 评测编程智能体

编程智能体编写、测试和调试代码，浏览代码库，并像人类开发人员一样运行命令。现代编程智能体的有效评测通常依赖于明确指定的任务、稳定的测试环境以及对生成代码的全面测试。

确定性评分器对于编程智能体来说是很自然的，因为软件通常很容易评估：代码能运行吗？测试能通过吗？两个广泛使用的编程智能体基准测试，SWE-bench Verified和Terminal-Bench，都遵循这种方法。SWE-bench Verified 给智能体提供流行 Python 仓库中的 GitHub issue，并通过运行测试套件来对解决方案评分；只有当解决方案修复了失败的测试且不破坏现有测试时，才算通过。LLM 在这个评测上的得分在短短一年内从 40% 提高到了 >80%。Terminal-Bench 采取了不同的路径：它测试端到端的技术任务，例如从源代码构建 Linux 内核或训练 ML 模型。

一旦你有了一组用于验证编程任务关键结果的通过或失败测试，通常对记录（Transcript）进行评分也很有用。例如，基于启发式的代码质量规则可以根据不仅仅是通过测试来评估生成的代码，而具有清晰量表的基于模型的评分器可以评估诸如智能体如何调用工具或与用户交互等行为。

示例：编程智能体的理论评测考虑一个编程任务，智能体必须修复一个身份验证绕过漏洞。如下面的说明性 YAML 文件所示，人们可以使用评分器和指标来评估该智能体。

task:
id: "fix-auth-bypass_1"
desc: "修复当密码字段为空时的身份验证绕过..."
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

4.4 评测对话智能体

对话智能体在支持、销售或辅导等领域与用户互动。与传统的聊天机器人不同，它们保持状态、使用工具并在对话中途采取行动。虽然编程和研究智能体也涉及与用户的多轮交互，但对话智能体提出了独特的挑战：交互本身的质量就是你正在评估的一部分。对话智能体的有效评测通常依赖于可验证的最终状态结果和捕捉任务完成度及交互质量的量表。与大多数其他评测不同，它们通常需要第二个 LLM 来模拟用户。我们在对齐审计智能体（alignment auditing agents）中使用这种方法，通过扩展的对抗性对话对模型进行压力测试。

对话智能体的成功可以是多维的：工单是否解决（状态检查），是否在 10 轮内完成（记录约束），以及语气是否恰当（LLM 量表）？包含多维性的两个基准是𝜏-Bench及其继任者𝜏2-Bench。它们模拟了零售支持和机票预订等领域的跨领域多轮交互，其中一个模型扮演用户角色，而智能体则处理现实场景。

示例：对话智能体的理论评测考虑一个支持任务，智能体必须为沮丧的客户处理退款。

graders:
- type: llm_rubric
rubric: prompts/support_quality.md
assertions:
- "智能体对客户的沮丧表示同情"
- "解决方案解释清楚"
- "智能体的回应基于 fetch_policy 工具的结果"
- 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:
# ... (与编程智能体的指标类似)

4.5 评测研究智能体

研究智能体收集、综合和分析信息，然后生成答案或报告等输出。与单元测试提供二元通过/失败信号的编程智能体不同，研究质量只能相对于任务进行判断。什么算作“全面”、“来源可靠”甚至“正确”，取决于上下文：市场扫描、收购尽职调查和科学报告各自需要不同的标准。

研究评测面临独特的挑战：专家可能对综合报告是否全面存在分歧，随着参考内容的不断变化，基本事实（Ground Truth）也会发生变化，而且更长、更开放的输出为错误创造了更多空间。例如，像 BrowseComp 这样的基准测试测试 AI 智能体是否可以在开放网络的大海捞针，这些问题旨在易于验证但难以解决。

构建研究智能体评测的一种策略是结合多种评分器类型。确证性检查（Groundedness checks）证主张是否有检索到的来源支持，覆盖率检查（Coverage checks）定义好答案必须包含的关键事实，来源质量检查确认参考的来源是权威的，而不仅仅是检索到的第一个。对于有客观正确答案的任务（“X 公司第三季度的收入是多少？”），精确匹配是有效的。LLM 可以标记不支持的主张和覆盖率差距，同时也验证开放式综合报告的连贯性和完整性。

鉴于研究质量的主观性质，基于 LLM 的量表应经常与专家的人类判断进行校准，以有效评测这些智能体。

4.6 计算机操作智能体

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

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

4.7 如何思考智能体评测中的非确定性

无论智能体类型如何，智能体的行为在不同运行之间都会有所不同，这使得评测结果比初看时更难解释。每个任务都有自己的成功率，可能在一个任务上是 90%，在另一个上是 50%，并且在一个评测运行中通过的任务可能会在下一次运行中失败。有时，我们要衡量的是智能体完成任务的频率（试验的比例）。

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

pass@k衡量智能体在k次尝试中获得至少一个正确解决方案的可能性。随着 k 的增加，pass@k 分数上升，更多的“射门”意味着至少一次成功的几率更高。pass@1 的分数为 50% 意味着模型在第一次尝试时成功完成了评测中的一半任务。在编程中，我们通常最感兴趣的是智能体在第一次尝试就找到解决方案，pass@1。在其他情况下，只要有一个方案有效，提出多种方案也是有效的。

pass^k 衡量所有 k 次试验都成功的概率。随着k的增加，pass^k 下降，因为要求在更多试验中保持一致是一个更难清除的障碍。如果你的智能体每次试验的成功率为 75%，并且你运行 3 次试验，那么全部通过这三次的概率是 (0.75)3≈42%。这个指标对于面向客户的智能体尤其重要，因为用户期望每次都有可靠的行为。

随着试验次数的增加，pass@k 和 pass^k 会出现分歧。在 k=1 时，它们是相同的（都等于单次试验成功率）。到了 k=10，它们讲述了相反的故事：pass@k 接近 100%，而 pass^k 降至 0%。

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

5. 从零到一：智能体优质评测路线图
   ==================

本节列出了我们将评测从无到有并建立信任的实用的、经过实战检验的建议。将其视为评测驱动的智能体开发路线图：尽早定义成功，清晰衡量，并持续迭代。

5.1 收集初始评测数据集的任务

步骤 0：尽早开始我们看到团队推迟构建评测，因为他们认为需要数百个任务。实际上，从真实失败中提取的20-50 个简单任务就是一个很好的开始。毕竟，在早期智能体开发中，系统的每个变更通常都有清晰、显著的影响，这种巨大的效应意味着小样本量就足够了。更成熟的智能体可能需要更大、更难的评测来检测较小的效应，但最好在开始时采用 80/20 法则。等待越久，评测就越难建立。在早期，产品需求自然转化为测试用例。等太久，你就得从实时系统中逆向工程成功标准。

步骤 1：从你已经手动测试的内容开始从你在开发过程中运行的手动检查开始，你在每次发布前验证的行为以及最终用户尝试的常见任务。如果你已经在生产环境中，请查看你的错误跟踪器和支持队列。将用户报告的故障转换为测试用例，确你的套件反映了实际使用情况；按用户影响排优先级有助于你将精力投入到最重要的地方。

步骤 2：编写带有参考解决方案的明确任务确任务质量比看起来更难。一个好任务是两个领域专家能独立得出相同通过/失败结论的任务。他们自己能通过这个任务吗？如果不能，任务需要细化。任务规范中的模糊性会变成指标中的噪声。这也适用于基于模型的评分器的标准：模糊的量表会产生不一致的判断。

每个任务都应该能被正确遵循指令的智能体通过。这可能很微妙。例如，审计 Terminal-Bench 发现，如果任务要求智能体编写脚本但未指定文件路径，而测试假设脚本位于特定路径，智能体可能会非因自身过错而失败。评分器检查的所有内容都应该从任务描述中清晰可见；智能体不应因规格模糊而失败。对于前沿模型，如果在多次试验中通过率为 0%（即 0% pass@100），这通常是任务损坏的信号，而不是智能体无能，这也是需要仔细检查任务规范和评分器的标志。对于每个任务，创建一个参考解决方案（通过所有评分器的已知工作输出）是很有用的。这证明了任务是可解的，并验证了评分器已正确配置。

步骤 3：构建平衡的问题集既要测试行为应该发生的情况，也要测试不应该发生的情况。片面的评测会导致片面的优化。例如，如果你只测试智能体是否在应该搜索时进行了搜索，你最终可能会得到一个对几乎所有事情都进行搜索的智能体。尽量避免类别不平衡的评测。我们在为 Claude.ai 构建网络搜索评测时亲身体会到了这一点。挑战在于防止模型在不应该搜索时进行搜索，同时保留其在适当时进行广泛研究的能力。团队构建了涵盖两个方向的评测：模型应该搜索的查询（如查找天气）和应该根据现有知识回答的查询（如“谁创立了苹果？”）。在触发不足（undertriggering）和过度触发（overtriggering）之间取得适当的平衡是困难的，并且需要多轮改进提示词和评测。随着更多示例问题的出现，我们将继续添加到评测中以提高覆盖率。

5.2 设计评测框架和评分器

步骤 4：构建具有稳定环境的健壮评测框架至关重要的是，评测中的智能体功能与生产中使用的智能体大致相同，并且环境本身不会引入进一步的噪声。每次试验都应通过从干净的环境开始来“隔离”。运行之间不必要的共享状态（残留文件、缓存数据、资源耗尽）可能导致由基础设施不稳定而非智能体性能引起的相关故障。共享状态也可能人为地提高性能。例如，在一些内部评测中，我们观察到 Claude 通过检查先前试验的 git 历史记录，在某些任务上获得了不公平的优势。如果多个不同的试验因为环境中的相同限制（如受限的 CPU 内存）而失败，这些试验就不是独立的，因为它们受到相同因素的影响，评测结果在衡量智能体性能方面就变得不可靠。

步骤 5：深思熟虑地设计评分器如上所述，优秀的评测设计包括为智能体和任务选择最佳的评分器。我们建议尽可能选择确定性评分器，在必要时或为了额外的灵活性选择 LLM 评分器，并谨慎使用人工评分器进行额外验证。 有一种常见的本能是检查智能体是否遵循了非常具体的步骤，例如按正确顺序进行的一系列工具调用。我们发现这种方法过于僵化，导致测试过于脆弱，因为智能体经常找到评测设计者未预料到的有效方法。为了不必要地惩罚创造力，通常最好是对智能体产生的结果进行评分，而不是它采取的路径。

对于具有多个组件的任务，建立部分学分（partial credit）。一个能正确识别问题并验证客户身份但未能处理退款的支持智能体，比立即失败的智能体要好得多。在结果中体现这种成功的连续性很重要。

模型评分通常需要仔细迭代以验证准确性。LLM 作为法官（LLM-as-judge）的评分器应与人类专家密切校准，以确信人工评分和模型评分之间的分歧很小。为了避免幻觉，给 LLM 一条出路，比如提供一条指令，当它没有足够信息时返回“未知”。创建清晰、结构化的量表来对任务的每个维度进行评分，然后用独立的 LLM 作为法官对每个维度进行评分，而不是用一个法官对所有维度进行评分，也会有所帮助。一旦系统稳健，偶尔使用人工审查就足够了。

有些评测具有微妙的故障模式，即使智能体表现良好也会导致低分，因为智能体因评分错误、智能体框架约束或模糊性而未能解决任务。即使是成熟的团队也会错过这些问题。例如，Opus 4.5 最初在 CORE-Bench 上得分 42%，直到一位 Anthropic 研究员发现了多个问题：僵化的评分惩罚了“96.12”当期望是“96.124991…”时，模糊的任务规格，以及无法精确复现的随机任务。在修复错误并使用约束较少的脚手架后，Opus 4.5 的分数跃升至 95%。同样，METR 在他们的时间跨度基准测试中发现几个配置错误的任务，要求智能体优化到规定的分数阈值，但评分要求超过该阈值。这惩罚了像 Claude 这样遵循指令的模型，而忽略规定目标的模型则获得了更好的分数。仔细复查任务和评分器可以帮助避免这些问题。

使你的评分器能够抵抗绕过或黑客攻击。智能体不应该能够轻易地“欺骗”评测。任务和评分器的设计应确保通过真正需要解决问题，而不是利用意外的漏洞。

5.3 长期维护和使用评测

步骤 6：检查记录（Transcripts）除非你阅读了许多试验的记录和评分，否则你不会知道你的评分器是否工作良好。在 Anthropic，我们投资了用于查看评测记录的工具，并定期花时间阅读它们。当任务失败时，记录会告诉你智能体是犯了真正的错误，还是你的评分器拒绝了一个有效的解决方案。它通常还会浮现关于智能体和评测行为的关键细节。 失败应该看起来是公平的：很清楚智能体哪里错了以及为什么。当分数没有攀升时，我们需要确信这是由于智能体性能而不是评测本身。阅读记录是你验证评测是否衡量了真正重要内容的方式，也是智能体开发的一项关键技能。

步骤 7：监控能力评测的饱和度100% 的评测可以跟踪回归，但不能提供改进信号。当智能体通过所有可解决的任务，没有改进空间时，就会发生评测饱和（Eval saturation）。例如，SWE-Bench Verified 分数今年从 30% 开始，前沿模型现在已接近饱和，达到 >80%。随着评测接近饱和，进展也会放缓，因为只剩下最困难的任务。这可能会使结果具有欺骗性，因为巨大的能力提升表现为分数的微小增加。例如，代码审查初创公司 Qodo 最初对 Opus 4.5 不以为然，因为他们的单次编程评测没有捕捉到在更长、更复杂任务上的收益。作为回应，他们开发了一个新的智能体评测框架，提供了更清晰的进展图景。 作为规则，在有人深入研究评测细节并阅读一些记录之前，我们不会从表面上看待评测分数。如果评分不公平、任务模糊、有效解决方案受到惩罚或框架限制了模型，则应修订评测。

步骤 8：通过开放贡献和维护保持评测套件的长期健康评测套件是一个活的工件，需要持续关注和明确的所有权才能保持有用。 在 Anthropic，我们尝试了各种评测维护方法。事实证明最有效的方法是建立专门的评测团队来拥有核心基础设施，而领域专家和产品团队贡献大多数评测任务并自己运行评测。 对于 AI 产品团队来说，拥有和迭代评测应该像维护单元测试一样常规。团队可能会在早期的测试中“有效”但在设计良好的评测本可以及早发现的未说明期望上失败的 AI 功能上浪费数周时间。定义评测任务是对产品需求是否具体到可以开始构建的最佳压力测试之一。

我们建议实行评测驱动开发（eval-driven development）：在智能体能够实现计划的功能之前构建评测来定义这些功能，然后迭代直到智能体表现良好。在内部，我们经常构建今天“足够好”的功能，但这是对模型在几个月后能做什么的押注。从低通过率开始的能力评测使这变得可见。当新模型发布时，运行套件会迅速揭示哪些押注得到了回报。 最接近产品需求和用户的人最有资格定义成功。以目前的模型能力，产品经理、客户成功经理或销售人员可以使用 Claude Code 作为 PR 贡献评测任务，让他们做吧！或者更好的是，积极地赋能他们。

6. 评测如何与其他方法配合以全面了解智能体
   ======================

自动化评测可以在不部署到生产环境或影响真实用户的情况下，针对数千个任务运行智能体。但这只是了解智能体性能的众多方法之一。完整的图景包括生产监控、用户反馈、A/B 测试、手动记录审查和系统性人工评估。

了解 AI 智能体性能的方法概览：

方法	优点	缺点
自动化评测 在没有真实用户的情况下通过编程运行测试	• 迭代更快 • 完全可复现 • 无用户影响 • 可在每次提交时运行 • 无需生产部署即可大规模测试场景	• 需要更多的前期投入来构建 • 随着产品和模型的演进需要持续维护以避免漂移 • 如果不匹配实际使用模式，可能会产生错误的信心
生产监控 跟踪实时系统中的指标和错误	• 揭示大规模的真实用户行为 • 捕捉合成评测遗漏的问题 • 提供关于智能体实际表现的基本事实	• 被动，问题在你知道之前就到达了用户 • 信号可能有噪声 • 需要在仪表化方面投入 • 缺乏评分的基本事实
A/B 测试 比较具有真实用户流量的变体	• 衡量实际用户结果（留存率、任务完成率） • 控制混杂因素 • 可扩展和系统化	• 慢，需要数天或数周才能达到显著性，并且需要足够的流量 • 仅测试你部署的变更 • 如果不能彻底审查记录，很难知道指标变化背后的“原因”
用户反馈 显式信号，如点踩或错误报告	• 浮现你未预料到的问题 • 附带来自真实人类用户的真实示例 • 反馈通常与产品目标相关	• 稀疏且自选的 • 倾向于严重问题 • 用户很少解释为什么失败 • 非自动化 • 主要依靠用户发现问题可能会产生负面用户影响
手动记录审查 人类阅读智能体对话	• 建立对故障模式的直觉 • 捕捉自动化检查遗漏的微妙质量问题 • 帮助校准“好”的样子并掌握细节	• 时间密集型 • 无法扩展 • 覆盖范围不一致 • 审查者疲劳或不同的审查者会影响信号质量 • 通常只提供定性信号，而不是清晰的定量评分
系统性人工研究 由受过训练的评分员对智能体输出进行结构化评分	• 来自多个人类评分员的黄金标准质量判断 • 处理主观或模糊的任务 • 为改进基于模型的评分器提供信号	• 相对昂贵且周转慢 • 难以频繁运行 • 评分者之间的分歧需要协调 • 复杂领域（法律、金融、医疗）需要人类专家进行研究

这些方法对应于智能体开发的不同阶段。自动化评测在发布前和 CI/CD 中特别有用，作为抵御质量问题的第一道防线，在每次智能体变更和模型升级时运行。生产监控在发布后启动，以检测分布漂移和未预料到的现实世界故障。一旦你有足够的流量，A/B 测试验证重大变更。用户反馈和记录审查是填补空白的持续实践，不断分类反馈，每周抽样阅读记录，并根据需要深入挖掘。保留系统性人工研究用于校准 LLM 评分器或评估以人类共识为参考标准的主观输出。

就像安全工程中的瑞士奶酪模型（Swiss Cheese Model）一样，没有任何单一的评测层能捕捉到每一个问题。结合多种方法，穿过一层的故障会被另一层捕捉。 最有效的团队结合了这些方法，用于快速迭代的自动化评测，用于基本事实的生产监控，以及用于校准的定期人工审查。

7. 结论
   =====

没有评测的团队会陷入被动的循环，修复一个故障，制造另一个，无法区分真正的退化和噪声。尽早投资的团队发现相反的情况：随着故障变成测试用例，开发加速，测试用例防止退化，指标取代猜测。评测给整个团队一个清晰的攀登目标，将“智能体感觉变差了”转化为可操作的东西。价值会产生复利，但前提是你将评测视为核心组件，而不是事后的想法。

不同智能体类型的模式各不相同，但这里描述的基本原理是不变的。尽早开始，不要等待完美的套件。从你看到的故障中获取现实任务。定义明确、稳健的成功标准。深思熟虑地设计评分器并结合多种类型。确保问题对模型来说足够难。迭代评测以提高信噪比。阅读记录！

AI 智能体评测仍然是一个新兴的、快速发展的领域。随着智能体承担更长的任务，在多智能体系统中协作，并处理日益主观的工作，我们将需要调整我们的技术。随着我们了解更多，我们将继续分享最佳实践。

8. 附录：评测框架
   ==========

几个开源和商业框架可以帮助团队实施智能体评测，而无需从头构建基础设施。正确的选择取决于你的智能体类型、现有技术栈以及你是需要离线评测、生产可观测性还是两者兼有。

Harbor 专为在容器化环境中运行智能体而设计，具有跨云提供商大规模运行试验的基础设施，以及用于定义任务和评分器的标准化格式。像 Terminal-Bench 2.0 这样的流行基准通过 Harbor 注册表发布，使得运行已建立的基准以及自定义评测套件变得容易。

Promptfoo 是一个轻量级、灵活且开源的框架，专注于提示词测试的声明性 YAML 配置，断言类型从字符串匹配到 LLM 作为法官的量表。我们在许多产品评测中使用 Promptfoo 的一个版本。

Braintrust 是一个结合了离线评测与生产可观测性和实验跟踪的平台，对于既需要在开发期间迭代又需要在生产中监控质量的团队非常有用。其 autoevals 库包括针对真实性、相关性和其他常见维度的预构建评分器。

LangSmith 提供跟踪、离线和在线评测以及数据集管理，并与 LangChain 生态系统紧密集成。Langfuse 为有数据驻留要求的团队提供类似的作为自托管开源替代方案的能力。

许多团队结合使用多种工具，推出自己的评测框架，或者只是使用简单的评测脚本作为起点。我们发现，虽然框架是加速进展和标准化的宝贵方式，但它们的好坏取决于你通过它们运行的评测任务。通常最好快速选择一个适合你工作流的框架，然后通过迭代高质量的测试用例和评分器，将精力投入到评测本身。

---

说真的，这两年看着身边一个个搞Java、C++、前端、数据、架构的开始卷大模型，挺唏嘘的。大家最开始都是写接口、搞Spring Boot、连数据库、配Redis，稳稳当当过日子。

结果GPT、DeepSeek火了之后，整条线上的人都开始有点慌了，大家都在想：“我是不是要学大模型，不然这饭碗还能保多久？”

我先给出最直接的答案：一定要把现有的技术和大模型结合起来，而不是抛弃你们现有技术！掌握AI能力的Java工程师比纯Java岗要吃香的多。

即使现在裁员、降薪、团队解散的比比皆是……但后续的趋势一定是AI应用落地！大模型方向才是实现职业升级、提升薪资待遇的绝佳机遇！

这绝非空谈。数据说话

2025年的最后一个月，脉脉高聘发布了《2025年度人才迁徙报告》，披露了2025年前10个月的招聘市场现状。

AI领域的人才需求呈现出极为迫切的“井喷”态势

2025年前10个月，新发AI岗位量同比增长543%，9月单月同比增幅超11倍。同时，在薪资方面，AI领域也显著领先。其中，月薪排名前20的高薪岗位平均月薪均超过6万元，而这些席位大部分被AI研发岗占据。

与此相对应，市场为AI人才支付了显著的溢价：算法工程师中，专攻AIGC方向的岗位平均薪资较普通算法工程师高出近18%；产品经理岗位中，AI方向的产品经理薪资也领先约20%。

当你意识到“技术+AI”是个人突围的最佳路径时，整个就业市场的数据也印证了同一个事实：AI大模型正成为高薪机会的最大源头。

最后

我在一线科技企业深耕十二载，见证过太多因技术卡位而跃迁的案例。那些率先拥抱 AI 的同事，早已在效率与薪资上形成代际优势，我意识到有很多经验和知识值得分享给大家，也可以通过我们的能力和经验解答大家在大模型的学习中的很多困惑。

我整理出这套 AI 大模型突围资料包【允许白嫖】：

• ✅从入门到精通的全套视频教程

• ✅AI大模型学习路线图（0基础到项目实战仅需90天）

• ✅大模型书籍与技术文档PDF

• ✅各大厂大模型面试题目详解

• ✅640套AI大模型报告合集

• ✅大模型入门实战训练

这份完整版的大模型 AI 学习和面试资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】

①从入门到精通的全套视频教程

包含提示词工程、RAG、Agent等技术点

② AI大模型学习路线图（0基础到项目实战仅需90天）

全过程AI大模型学习路线

③学习电子书籍和技术文档

市面上的大模型书籍确实太多了，这些是我精选出来的

④各大厂大模型面试题目详解

⑤640套AI大模型报告合集

⑥大模型入门实战训练

👉获取方式：
有需要的小伙伴，可以保存图片到wx扫描二v码免费领取【保证100%免费】🆓