深入解析Anthropic的AI Agent评估方法论：从评测体系构建到生产落地实践

April 5, 2026

在推进AI项目的进程中，“可观测性” 是一个无法回避的核心议题。可观测性本质上关联着项目的可评估性，由此衍生出诸如RAG评估系统、AI专业能力评估策略等一系列重要课题。

例如，OpenAI此前联合来自60个国家/地区的262位医生，基于5000个真实医疗对话场景构建的 HealthBench，便是一套综合性评估策略的典范，尽管其侧重点更偏向于整体性能评估。

本文将聚焦于大模型厂商Anthropic发布的一篇关于Agent评估的技术论文，借此深入探讨AI项目评估的系统化方法与工程实践：

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

什么是评测？

评测是对系统进行系统性检验的方法。通过输入预设的任务，检查Agent的输出或行为是否符合预期目标。

Anthropic将完整的评测流程拆解为以下几个结构化模块：

任务：代表一次独立测试的输入指令及其对应的成功标准。
单次试验：指任务的一次具体执行过程。由于模型输出存在随机性，通常需要多次运行同一任务以获得稳定的评估结果。
评分器：用于评估Agent在某个特定维度上表现的判定逻辑。一个任务可以包含多个评分器及检查点。
记录：完整记录单次试验过程中的所有细节，包括输入、输出、工具调用、中间推理步骤及结果。
结果：指单次试验结束时环境的最终状态。例如，一个订票Agent可能输出“机票已订好”，但真正的评测结果需要通过检查数据库是否存在有效的预订记录来确认。

通常，一个评测框架会提供并发运行任务和工具、记录全过程并自动评分的功能。

一个有效的Agent评测体系必须覆盖从输入到最终行为的完整闭环，确保Agent在多轮交互和复杂工具调用中的表现都能被有效量化和评估。

评估的价值前文已有提及，Anthropic的表述虽然略显抽象，但其核心理念可以概括为：通过明确界定成功标准，使开发团队能在产品上线前主动发现问题，而非在用户投诉后才被动进行修复。

Anthropic指出，缺乏系统评测的团队往往陷入“被动修复”的循环，每解决一个已知问题都可能无意中引入新的问题，且难以区分性能波动是真正的回归还是模型输出的随机性所致。

需要补充的是，即便建立了评估体系，也可能出现修复一处而另一处出现问题的情况，这是Agent乃至所有AI项目固有的复杂性所带来的挑战。

然而，毋庸置疑的是，采用系统化评测的团队对项目本身的理解必然更为深刻。相应的，他们的工作方式也会更加专业，能够利用失败的测试用例持续“训练”和优化系统。最终，当这个自我强化的“飞轮”成功运转时，几乎就意味着整个项目走向了成功。

从能力评测到任务评测

Anthropic将评测主要分为两大类：能力评估与回归评估。

能力评估是项目可观测性的基石，它聚焦于“Agent能做什么”，通常从通过率较低、Agent容易失败的任务开始，目标是量化和推动模型新能力的提升。

而回归评估则关注“Agent是否仍然能完成之前可以胜任的任务”，其预期通过率应接近100%，主要用于防止在版本更新和迭代过程中引入性能倒退。实践中，最佳方式是复用历史错误数据集，确保每次发布前都执行一遍回归测试。

在实际项目开发中，我们也能观察到这种分类趋势。以Descript的视频编辑Agent为例，其评测体系围绕“不破坏已有内容、按要求准确执行、执行质量”三个核心维度设计。

这套评测体系经历了从人工评分，逐步演进到由产品团队定义标准、LLM自动执行评分，并辅以周期性人工校准的过程。目前，他们常态化运行两套测试：一套用于质量基准评测，另一套用于回归测试。

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

结合我们过往在大型AI项目中的生产实践经验，系统化的评测体系无疑是提升迭代效率、保障产品质量的关键工具。

只有建立了可量化评估的指标与方法，我们在面对AI项目时才不会盲目摸索，也不会轻易得出“模型能力仅止于此”的片面结论。

如何进行评测

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

模型评分

模型型评分器是指使用另一个大语言模型来进行打分或判断，例如基于评分量表的打分、自然语言断言、与参考答案对比等。

这类评分器的优势在于灵活性高，能够捕捉主观性强和开放式任务的细微差别。但其缺点在于结果存在不确定性，需要消耗更多计算资源，并且必须通过人工标注来进行校准以确保其准确度。

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

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

从广义上讲，前文提到的HealthBench就可以采用模型评分器来实施。

人工评分

这种方式大家最为熟悉，它是最原始、理论上也最“可靠”的评分方式。人工评分器适用于需要专家判断或难以用简单规则量化的复杂场景。

人工标注能够提供“金标准”质量，精准匹配专业用户的主观评判，通常用于校准模型评分器或进行最终的质量验收。然而，其代价是昂贵且耗时的。

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

代码评分

代码型评分器涵盖了字符串匹配、断言检查、静态分析、环境状态校验等方法，通过确定性的逻辑来快速判断结果是否符合预期。

其优点是高效、客观且易于复现，特别适用于结构化输出和确定性任务，例如对编程Agent的代码输出进行评估。

在编程Agent的评测中，常规做法是对生成的代码运行自动化测试，只要代码能通过预设的单元测试即可认定为通过。

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

人工评分最为人熟知，模型评分则是我们用模型替代人力、提升效率的工具。而“代码评分”这个概念可能让许多同学感到困惑：它究竟指什么？

代码型评分器的核心并非“测试代码生成能力”，而是 利用代码执行这一确定性手段，来验证Agent在完成复杂任务后所产生结果的正确性。

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

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

这个例子背后对应着论文中一个较为拗口的翻译：任务的结果必须能够通过某种明确的规则或外部系统进行客观验证。

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

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

再比如，许多涉及工具调用的任务就很适合采用代码评分器。一般的AI项目可能不常用到此方法，但它非常契合Agent的工作模式，因此许多同学对此不太熟悉。

接下来，我们需要根据不同的项目领域进行区分：不同类型的AI Agent，由于其任务目标和交互模式各异，需要采用针对性的评估策略。

编程型Agent

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

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

SWE-Bench会提供一个GitHub问题，要求Agent修改代码，修改完成后使用项目原有的测试套件进行验证。
Terminal-Bench则要求Agent完成一项完整的工程任务（如编译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最擅长的工作主要包括三类：

生成代码，特别是HTML等前端代码。
生成与加工内容，例如基于现有材料生成PPT、图片或博客文章。
进行深度信息研究与整合。

研究型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评分；仅在必要时才引入人工评估。应避免对Agent的具体执行步骤顺序进行过度约束，而应关注其最终目标是否达成。对于多步骤任务，可以设计部分积分机制。LLM评分器必须经过严格的人工校准，并应设置“当不确定时返回未知”的逃生机制，以减少因模型幻觉导致的误判。

七、深度分析对话记录

定期审查评估失败的完整对话轨迹，仔细区分是Agent真的失败，还是评分器本身存在误判。

通过人工审阅这些记录，能够发现评估设计本身可能存在的问题，从而确保评估结果真实、准确地反映产品需求。

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

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

此时，需要主动设计更具挑战性的任务、更复杂的场景或引入多轮交互测试，以建立新的评估前沿。评估套件应被视为一份“活的文档”，需要像维护单元测试一样持续进行更新和补充。

生产落地实践

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

一、集成到CI/CD流程

自动化评估应与持续集成/持续部署系统无缝衔接。每次模型版本或Agent逻辑发生更改后，都应自动触发评估流程，以便在开发早期快速发现功能回归和潜在问题。

考虑到评估运行需要消耗计算资源，可以根据开发阶段的不同选择执行范围：在开发阶段运行轻量级的快速测试，在正式发布前再执行全套的深度评估。

二、实施实时监控与报警

在评估流程之外，还需要对Agent在生产环境中的实际表现进行实时监控。

例如，持续追踪日常请求中关键评估任务的成功率、监控核心指标的变化趋势等，以便及时发现实际用户流量下可能出现的质量下降。

Galileo、Maxim等平台都强调，必须将生产环境的数据反馈到评估闭环中。例如，可以根据真实的用户交互自动生成难题样本，避免同一个错误模式反复出现而未被检测到。

三、指标化管理

开发团队应为项目设定清晰、可追踪的核心指标，并对其进行长期监控。

例如，对于客服型Agent，可以追踪“工单一次解决率”、“用户满意度评分”等；对于编程助手，则可以追踪“代码构建通过率”、“引入的代码缺陷率”等。

这些业务指标应与自动化评估的结果相互关联。评估报告不应只包含单个任务的通过率，还应关注系统级的性能指标，如平均响应时间、资源消耗情况等。可以利用Elastic APM、Prometheus、集中式日志系统等工具链来捕获这些指标，并将其与评估管线打通，形成统一的综合看板。

四、工具与框架选择

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

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

团队可以根据自身的技术栈和具体需求进行选择或自行研发。关键在于尽快选定一个合适的工具启动，并将主要精力投入到构造高质量的测试用例和评分器上。

五、与其他质量保障方法结合

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

完整的质量监控方案通常还包括生产环境监控、A/B测试、用户反馈收集、日志深度分析等。Anthropic将其比喻为“瑞士奶酪模型”：自动化评估能够捕获绝大部分常见问题；生产监控能够揭示随机分布的错误；而用户反馈和人工复盘则能发现那些细微的、难以自动化量化的问题。

在资源允许的情况下，也可以周期性地进行人工对话审查或开展用户研究，以补充自动化评估无法覆盖的维度。

结语

总体而言，Anthropic的这篇论文提供了有价值的系统性框架，但部分内容仍显宽泛。相比于理论概述，或许结合一个具体案例进行逐步演练，会带来更直观、更深入的理解。当然，这或许也是多数技术论文在可读性上普遍面临的挑战。

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

它将模糊、感性的反馈转化为清晰、可行动的洞察，是支撑数据驱动式迭代的核心基础设施。总而言之，必须对其给予高度重视！

最后，让我们了解一下Anthropic论文中提到的五大挑战，以供参考：

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