一个 AI 智能体告诉你：“机票已经订好了。”这能证明任务完成了吗？
Anthropic 在《AI 智能体评测揭秘》（Demystifying evals for AI agents）中给出的判断很具体：需要检查系统数据库里，是否真的存在这笔预订记录。
这篇文章结合 Anthropic 内部实践和客户经验，讨论了怎样为智能体建立可信的评测。它的主线可以概括为：提前定义成功，用真实任务验证表现，再把失败持续转化为改进依据。
理解智能体评测，可以从几个问题入手：评测什么、怎样评分、如何理解成功率，以及怎样从零建立并长期维护一套评测体系。
一、为什么智能体评测比普通问答更复杂？
评测，也就是 evaluation，简称 eval，基本做法是给 AI 一个输入，再用评分逻辑判断输出是否符合要求。这里重点讨论开发过程中可以运行、无须真实用户参与的自动化评测。
单轮问答的过程比较直接：输入问题、得到回答、检查答案。但智能体会连续调用工具、修改环境，并根据中间结果调整下一步。错误可能在多轮操作中传播和累积，只检查最后一句回答，很难完整判断任务是否成功。
另一项挑战是，智能体可能找到设计者没有预料到的方法。Anthropic 举过一个案例：Opus 4.5 在 τ2-bench 的订票任务中发现了政策漏洞，按照既定规则没有通过评测，但作者认为它实际上为用户找到了更好的解决方案。这个例子提醒团队，也要检查评分规则是否拒绝了有效解法。
二、评测的是一个系统，先把几个概念分清楚
首先需要区分以下概念。
任务是一个有明确输入和成功标准的测试，例如处理退款、修复代码问题。试验是对任务的一次尝试；同一个任务可以重复运行，因为模型每次的表现可能不同。
评分器是对表现某个方面进行评分的逻辑。一个任务可以配置多个评分器，每个评分器也可以包含多个检查项。评测套件则是围绕特定能力或目标组织起来的一组任务。耗时、token 使用量和工具调用次数等，还可以作为单独跟踪的指标，帮助比较效率与成本。
尤其重要的是区分执行记录与最终结果。执行记录包括输出、工具调用和中间结果；最终结果指试验结束后环境的实际状态。“机票订好了”属于记录，数据库里存在预订才是结果的证据。
还有两种容易混淆的运行框架。智能体运行框架负责处理输入、编排工具调用和返回结果；评测运行框架负责提供指令和工具、并发运行测试任务、记录过程、评分和汇总。
因此，评测一个智能体，实际评测的是模型与智能体运行框架共同工作的表现。工具、指令、执行约束和环境，都可能影响成绩。
三、为什么要尽早做评测？它让开发有据可依
开发初期，靠手动测试、内部试用和直觉，也能取得不错的进展。但产品上线并扩大规模后，用户一句“更新后感觉变差了”，就可能让团队陷入猜测：哪里变差了？是真正退步，还是结果本来就有波动？
没有评测，团队容易被动地等待投诉、手动复现、修复问题，然后希望没有引发其他退步。评测能够帮助团队在同一批任务上比较不同版本，更有依据地判断变化，并持续跟踪耗时、token 使用量、成本和错误率。
它还促使团队尽早说清楚“怎样才算成功”。视频编辑产品 Descript 的评测围绕三个维度展开：不要破坏已有内容、完成用户要求、把事情做好。团队从人工评分逐步转向大模型评分，由产品团队制定标准，并定期进行人工校准；同时分别运行质量评测与回归测试两套任务。
Claude Code 也经历了从反馈驱动迭代，到逐渐加入简洁性、文件编辑和过度工程化等评测的过程。Bolt 则在产品广泛使用后，用三个月建立了结合静态分析、浏览器测试和大模型评委的评测系统。
评测也能帮助团队判断新模型是否适合自己的产品，并让产品与研究团队围绕明确的任务和指标沟通。它的投入在开始时就能看见，而收益会在后续开发中不断累积。
四、三类评分方式，应该怎样组合？
代码评分：验证明确条件
代码评分可以检查答案是否匹配、测试是否通过、代码规范、类型与安全问题，以及最终状态和工具调用是否符合要求。程序也可以分析执行轮次和 token 使用量；是否将这些指标设为通过条件，要由具体任务要求决定。
它快速、便宜、判断依据明确，也易于复现和调试。但它只能检查事先定义好的条件，对主观质量和细微差别的判断有限；规则过于僵硬时，也可能拒绝合理的结果变化。
大模型评分：判断开放式质量
大模型可以按照评分细则评价输出，也可以把两个候选结果放在一起比较、对照参考答案，或由多个评委综合判断。它更灵活，适合开放式任务和自由表达，但评分具有波动性，成本通常高于代码评分，并且需要与人工判断校准。
使用大模型评分时，需要清楚、结构化的标准。必要时，让独立评委分别评价任务的不同维度；信息不足时，允许返回“Unknown”，避免强行下结论。
人工评分：提供专业判断与校准
专家审查、抽样检查等人工方法，能够提供专业判断，也可以校准模型评分。人工评审同样需要关注不同评审者的判断是否一致，而且成本高、速度慢，难以频繁覆盖大量任务。
实际设计时，能够用明确规则验证的部分优先使用确定性评分器，需要灵活判断时再使用模型，并合理安排人工验证。不必给每个任务都堆上全部评分方式，应按需要选择。
评分结果可以加权汇总，也可以要求全部检查通过，或采用混合方式。多环节任务还可以设置部分得分：识别问题、核实身份后才在退款时失败，与一开始就失败，反映的是不同程度的表现。
五、能力评测和回归评测，回答不同问题
能力评测关注智能体还能把什么做好。它可以从较低通过率开始，针对当前难以完成的任务，为团队提供改进目标。
回归评测关注以前能够处理的任务，现在是否依然可靠。它以接近 100% 的通过率为目标；一旦下降，就提示某些已有能力可能退步，需要排查。
提升困难任务的表现时，也需要检查已有能力。当某项能力逐渐成熟，原本用于探索能力边界的任务，就可以转入回归套件，持续守住质量。
六、不同智能体，需要什么成功证据？
编程智能体：重点检查代码是否运行、目标问题是否修复、原有功能有没有被破坏。SWE-bench Verified 使用 GitHub 上的真实问题和测试套件评价解法；Terminal-Bench 测试构建系统、训练模型等端到端技术任务。常见做法是用单元测试验证正确性，再用大模型评分细则评价整体代码质量；工具使用、用户交互等其他检查按需增加。
对话智能体：需要同时检查任务完成情况和交互质量。例如，客服工单是否解决、处理轮次是否符合要求、语气是否恰当。有些评测会让另一个大模型模拟用户，开展多轮交互。τ-Bench 和 τ2-Bench 等基准就采用了这类方法。由于回答问题等任务可能有多个正确解法，模型评分也常用于判断目标完成情况，而不只是评价语气。
研究智能体：需要检查论断是否得到来源支持、关键事实是否覆盖、来源是否权威，以及综合分析是否连贯完整。市场研究、收购尽职调查和科学报告，对“全面”的要求并不相同；专家可能有分歧，参考资料也会变化，较长的开放式输出还会增加出错空间。
具有客观答案的问题可以精确匹配，例如查询某家公司某季度的营收；开放式研究则需要贴合具体任务的标准，并经常与专家判断校准。BrowseComp 这类基准还会用“容易验证、难以找到答案”的问题，测试智能体在开放网络上查找信息的能力。
电脑操作智能体：需要在真实或测试环境中操作软件，再检查文件、应用配置、数据库和界面状态。WebArena、OSWorld 都体现了这种思路。订单确认页面出现，不代表后台一定生成了订单。
浏览器智能体还涉及工具选择与效率。读取页面结构与使用截图，在不同任务中的成本和速度有所不同。Anthropic 为 Claude for Chrome 建立了相关评测，检查智能体是否针对具体场景选择合适的工具，从而改进完成任务的速度和准确性。
这些方法的共同起点，是从任务目标出发，寻找能够验证完成情况的证据。
七、偶尔成功和稳定成功，要用不同指标理解
同一智能体重复执行同一任务，可能这次成功，下次失败。因此，单次运行不足以全面说明可靠性。
两个指标可以帮助理解这种差别：pass@k 是同一任务尝试 k 次至少成功一次的概率；pass^k 是 k 次全部成功的概率。当 k=1 时，两者都是单次成功率，编程任务中常关注的 pass@1 就是第一次尝试的表现。
增加尝试次数，会提高“至少成功一次”的机会；要求更多次全部成功，则提高了一致性的门槛。这是两个不同问题。
以单次成功率 75% 为例，三次全成功的概率约为 42%。这里按每次成功率相同、试验相互独立计算，0.75³≈42.19%。为便于对比，配图按同一前提计算了“三次至少成功一次”的概率：1−(1−0.75)³≈98.44%。这是演示计算，并非额外的实测成绩。
哪个指标更重要，取决于产品需求。有些工具允许提出多个方案，只要其中一个有效就有价值；直接服务用户的智能体，则往往更需要关注每次执行的一致性。
不同任务的成功率也可能不同，不能只看一次运行或一个汇总分数。重复试验的同时，仍需要检查任务、环境和评分是否合理。
八、从零到一建立评测：三个阶段、九个步骤
Anthropic 将建立评测的路线分为三个阶段、九个步骤（Step 0—8），涵盖任务收集、运行框架与评分器设计，以及长期维护。
第一阶段：收集初始任务集
步骤 0：尽早开始。
不必等到有数百个任务再启动。按照 Anthropic 的建议，初期从真实失败中整理 20—50 个简单任务，就是很好的起点。因为开发早期改动的影响通常较大，小样本也能提供信号；系统成熟后，可能需要更多、更难的任务来识别细微变化。
越早开始，产品需求越容易自然转化为测试。等得太久，就需要从已经运行的系统中反向推导成功标准。
步骤 1：从已有的手动测试开始。
整理开发时经常检查的行为、发布前必测项目和用户常见任务。产品上线后，再从故障记录和客服反馈中收集案例，并根据对用户的影响确定优先级。
步骤 2：编写无歧义的任务，并提供参考解法。
好的任务，应让两位领域专家独立判断时，得到一致的通过或失败结论。他们自己也应能够按照要求完成任务，否则就需要进一步完善说明。评分检查的要求，应在任务描述中清楚体现。
对 Terminal-Bench 的审查曾发现，某些任务要求编写脚本，却没有指定保存路径，测试程序却只认某个位置。智能体可能完成了要求，却因没猜中隐藏条件而失败。
准备一个已知能通过所有评分器的参考解法，可以确认任务可解、评分配置正确。Anthropic 还提醒，对前沿模型而言，如果大量尝试后通过率仍为零，应重新检查任务和评分器；这并非证明模型无能力的充分依据。
步骤 3：构建平衡的题集。
既测试某种行为应该发生的情况，也测试它不应该发生的情况。例如，搜索评测可以同时包含需要搜索的天气查询，以及应根据已有知识回答的“谁创立了苹果公司”。这样才能同时发现“应该搜索却没搜”和“不该搜索却搜索”的问题。只测一个方向，可能导致优化失衡。
第二阶段：设计运行框架与评分器
步骤 4：建立稳健的运行框架和稳定环境。
评测中的智能体，其运行方式应与实际产品大体一致。每次试验应尽量从干净环境开始，避免残留文件、缓存和资源不足干扰成绩。
Anthropic 曾发现 Claude 通过查看前几次试验留下的 Git 历史获得额外优势。环境因素既可能抬高成绩，也可能导致多次试验一起失败，破坏结果的独立性。
步骤 5：审慎设计评分器。
选择适合任务的评分方式，设置清晰标准，并校准模型评分。多环节任务可以保留部分得分；信息不足时允许模型表示无法判断。
评分通常应更关注产出，避免强制规定唯一的工具调用路径。但同时要防止绕过规则，确保通过测试真正需要解决问题。
CORE-Bench 的一个案例说明了评分和运行条件的重要性。Opus 4.5 最初得分为 42%，Anthropic 研究人员排查发现，存在数值匹配过严、要求含糊和随机任务无法精确复现等问题。例如，预期答案是“96.124991……”时，“96.12”也可能被判错。修复问题，并采用约束更少的运行框架后，分数提高到 95%。
这涉及评测和运行框架变化，不能解读为模型自身能力突然从 42% 提升到了 95%。METR 也发现过任务要求达到阈值、评分却要求超过阈值的配置错误，导致遵循指令的模型受到惩罚。
第三阶段：长期维护与使用
步骤 6：检查执行记录。
需要阅读多次试验的记录和评分，确认失败来自智能体错误，还是评分拒绝了有效解法。失败应当让人觉得合理：能够指出哪里做错了，以及为什么。
当分数不再提高，也要确认瓶颈来自智能体，而不是评测。阅读记录是验证评测是否衡量了重要问题的方法，也是智能体开发的一项关键技能。
步骤 7：监测能力评测是否饱和。
任务几乎全部通过时，评测仍能发现退步，却难以衡量进一步提升。剩下的任务越来越难，也可能让较大的能力改进只体现为小幅分数变化。
代码审查公司 Qodo 最初使用的单次作答编程评测，没有捕捉到 Opus 4.5 在更长、更复杂任务上的进步，因此开发了新的智能体评测框架。
需要随着能力变化调整任务，不能仅凭表面分数判断进步。
步骤 8：通过贡献与维护，保持评测套件长期健康。
评测需要持续更新和明确的责任归属。Anthropic 的实践是，由专门团队维护核心基础设施，让领域专家和产品团队贡献大部分任务并运行评测。
最了解产品要求和用户的人，也最有条件定义成功。因此，也应创造条件，让产品经理、负责客户使用与落地的客户成功团队，以及销售等角色参与贡献任务。
这九步共同构成了“评测驱动开发”：先用任务和标准定义预期能力，再持续迭代，直到智能体能够做好。这也能检验需求是否足够具体，避免开发很久后才发现团队对成功标准的理解不同。新模型出现时，再用同一套任务检查哪些预期已经实现。
九、自动评测之外，还要看真实使用
自动评测可以不影响真实用户地运行大量任务，但它不是理解智能体表现的全部。如果测试与实际使用脱节，也可能产生错误信心。
几种方法各有价值，也各有局限：
自动评测适合开发与发布前检查，能够频繁、规模化运行，但需要建设和维护，也可能遗漏真实使用模式。
生产环境监控能够观察实际行为、发现未预料到的问题，但通常较被动，问题可能已经影响用户；信号有噪声，而且真实交互未必有可直接判断对错的标准答案。
A/B 测试把不同版本交给不同组用户使用，比较留存、任务完成等实际结果。它需要足够流量和时间，而且只验证已部署的变化。要理解指标变化原因，仍需要查看执行细节。
用户反馈带来真实案例和意料之外的问题，但反馈较稀疏，主动反馈的人并不代表全部用户，内容也更偏向严重问题。用户通常不会详细解释失败原因，不能主要依靠他们发现故障。
人工执行记录审阅有助于理解细微问题和建立判断，但耗时、难以规模化，覆盖范围和评审一致性也有限，通常提供定性判断。
系统性人工评估能够为主观质量和模型评分提供校准依据，但成本更高、周期更长，复杂领域还需要专家。
在开发流程中，可以在发布前及每次改动、升级时运行自动评测；上线后用监控发现实际变化；有足够流量时用 A/B 测试验证重要改动。同时持续处理反馈、每周抽样阅读执行记录，并按需开展人工研究。
十、工具可以帮助起步，任务质量仍然关键
可借助的评测工具有不同侧重：
Harbor 侧重在容器化环境中运行智能体，支持大规模试验，以及标准化的任务和评分器定义。
Braintrust 结合离线评测、线上运行情况观察和实验跟踪；LangSmith 提供执行追踪、评测和数据集管理，并与 LangChain 生态紧密集成。
Langfuse 提供类似能力，是可自行托管的开源方案；Arize 提供开源的 Phoenix，以及扩展规模化、优化和监控能力的 AX。
以上工具定位以该文发表于 2026 年 1 月时的介绍为准。选择取决于任务类型、现有技术栈，以及是否同时需要离线评测和线上观察。
也可以组合工具、构建自己的框架，或者从简单脚本开始。框架的效果取决于测试任务和评分标准的质量。选定适合工作流程的工具后，更应把精力投入测试用例和评分器的持续改进。
结语：把失败变成能够积累的改进依据
《AI 智能体评测揭秘》提出的，是一套持续开发的方法：尽早定义成功，从真实失败中收集任务，组合合适的评分方式，检查执行记录，并随着能力和使用场景变化持续维护。
这样，用户一句“感觉变差了”，才能进一步变成可定位、可验证的问题；一次失败，也能成为以后防止同类问题的测试。
评测的价值会不断累积，前提是把它当作智能体开发的核心组成部分，并持续用真实使用中的证据检验和调整。
这个领域也仍在快速发展。随着智能体承担更长的任务、开展多智能体协作，以及处理更主观的工作，评测方法也需要继续演进。
——
本文参考：Anthropic《AI 智能体评测揭秘》（Demystifying evals for AI agents）
