Anthropic Agent最佳实践系列二: Agent系统测试

原文参考：Anthropic Engineering Blog《Demystifying evals for AI agents》。本文不是逐段翻译，而是基于原文框架做一次面向工程实践的中文整理。

Agent 系统最容易被低估的部分，不是 prompt，也不是工具调用，而是 eval 。

很多 Agent 项目一开始都能跑出很漂亮的 demo：用户输入任务，模型调用工具，最后给出结果。问题是，demo 能跑通一次，不代表系统能稳定上线。真实环境里，同一个任务多跑几次结果可能不同；工具顺序可能漂移；模型可能绕远路；一次修改 prompt 解决了 A 问题，又悄悄引入 B 问题。

所以我现在越来越认同一个判断：没有 eval 的 Agent 开发，本质上是在凭感觉调系统。

1. 为什么 Agent eval 比普通 LLM eval 更难？

传统 LLM 应用通常是单轮结构：输入一个 prompt，得到一个 response，然后判断回答是否正确。

Agent 不一样。Agent 会做多轮决策：读任务、拆计划、调用工具、读取工具结果、更新环境状态，最后再输出结果。也就是说，我们评估的不是一句话，而是一条执行轨迹。

这张图很关键，上半部分是传统单轮 eval：prompt 进去，LLM 输出，grader 判断结果；

下半部分是 Agent eval：任务、工具、运行环境一起进入 Agent loop，中间会产生文件修改、命令执行、数据库状态变化，最后 grader 不只看文本输出，还要看环境结果是否真的变了。

这就是 Agent 测试的核心区别：最终回答正确，不代表过程可靠；过程看起来合理，也不代表最终状态正确 ，比如一个客服 Agent 说"退款已完成"，但数据库里没有退款记录；一个 coding agent 说"漏洞已修复"，但测试没通过；一个研究 Agent 给出了漂亮报告，但关键引用来自低质量网页。这些都不是靠看最终文本就能发现的问题。

另外文章还提到模型还能找到超越静态评估极限的创造性解决方案，比如他们的Opus 4.5通过发现政策中的一个漏洞，解决了一个关于预订航班的𝜏2基准问题。虽然按照既定的评估标准是"失败"的，但实际上模型为用户想出了一个更好的解决方案。

2. 一个完整的 Agent eval 应该包含什么？

Anthropic 把 Agent eval 拆成几个核心对象：task、trial、grader、transcript、outcome、evaluation harness、agent harness、evaluation suite。

看起来术语很多，但实际可以理解成一条工程流水线：

Task 是测试题，包含输入和成功标准。
Trial 是Task的一次运行。同一个 task 可以跑多次，因为 Agent 输出有随机性，为了保证结果稳定可靠，所以多跑几次确定结果。
Grader(or checks) 是打分逻辑，是Agent在某一个方面的打分，一个任务可以有多个评分者，每个评分者包含多个断言，可以看结果，也可以看轨迹。
Transcript （or trajectory/trace）是一次Trial的完整执行记录，包括工具调用、模型回复、中间状态，对于Anthropic API，这是评估运行结束时的完整消息数组，包含评估期间对API的所有调用以及所有返回的响应。
Outcome 是最终环境状态，注意一般来说都是不是大模型的返回的回答, 在使用大模型时，经常遇到的问题是他告诉你任务完成了，但实际文件并没有改对、数据库中的订单也没有真的创建，所以需要强调的是具体任务实际的完成度。
Eval harness 是跑完整评测的基础设施，它提供沙箱环境和工具，并发运行任务，记录所有步骤，对输出进行评分，并汇总结果。
Agent harness（or scaffold）是让模型具备 Agent 行为的系统框架, 例如，Claude Code是一个灵活的智能体框架，我们通过智能体SDK使用其核心原语来构建我们的长期运行的智能体框架。

这里最容易忽略的是 transcript, 很多团队只存最终输出，不存过程。这样一旦失败，就只能靠猜：到底是 prompt 没写清楚？工具 schema 不好？检索结果错了？模型没读懂工具返回？还是 grader 写得太死？

如果保存完整 transcript，定位会快很多。失败样本不再只是一个红叉，而是一条可复盘的执行轨迹。

3. 如何评估AI agents

文章总结了当前大规模部署的Agent类型基本有4种:

Coding Agents
Research Agents
Computer use Agents
Conversational Agents

对于这些Agents，Anthropic介绍了几种成熟技术。实际操作时，可以将这些方法作为基础，然后将其扩展到具体的领域。

3.1 Grader 不能只有一种

Agent eval 的打分逻辑通常不能靠单一方法完成。Anthropic 总结了三类 grader：代码型、模型型、人工型。

我的经验是：硬指标用代码，软质量用模型，高风险用人工抽检。不要让 LLM judge 去判断本来可以用代码验证的事情，也不要强行用规则去判断明显语义化的问题。

实战1: Code Agents的测评

Coding Agents 的测评依赖 1）定义清晰的任务 2）稳定的测试环境 3）全面的测试方法，所以，对于Coding Agents最简单的测试方法就是是否通过测试用例，其中有两个公开的测试benchmark，SWE-bentch 和 Terminal-Bench：

SWE-bench 是给Agents GitHub 上热门python仓库收集的问题，并通过运行测试套件对解决方案进行评分：只有在修复失败测试且不破坏现有测试的情况下，解决方案才算通过。
Terminal-bench 要更加综合一点，测试的是技术任务本身，包含构建linux内核或者训练一个模型等
在具体一点，文章讲了一个修复authentication bypass vulnerability(安全漏洞) 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```

这个示例中，graders和metrics都有使用，展示了所有可用评分器，并不是说都要用，只是给大家打个烊。

在实践中，代码评估一般就是写单测，然后并使用大语言模型（LLM）评分标准来评估整体代码质量，仅在必要时添加额外的评分器和指标。

实战2: 对话Agents的评估

对于对话Agents，interaction(与客户交互)本身的质量至关重要，可以验证最终的任务状态(有没有解决用户的问题，系统级别)和用户的评价，尤其是用户评价，如果用户评价是满意的，那么任务执行和对话质量应该都是没有问题的。

另外与大多数其他评估不同，它们通常需要第二个大语言模型来模拟用户。Anthropic在Building and evaluating alignment auditing agents中采用这种方法，通过连续多轮的、故意找茬的对抗性对话，来对大模型进行高强度的压力测试。

对话式智能体的成功可以是多维度的：

工单是否得到解决（状态检查）
是否在<10轮对话内完成（对话记录约束）
语气是否恰当（大语言模型评分标准）

两个包含多维度考量的基准是𝜏-Bench及其后续版本τ2-Bench。它们模拟跨领域的多轮交互，如零售支持和机票预订，其中一个模型扮演用户角色，而智能体则应对现实场景。

yaml 复制代码

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

实践中，对话式智能体评估通常使用基于模型的评分器来评估沟通质量和目标完成情况，因为许多任务（如回答问题）可能有多种"正确"的解决方案。

实战3: Research Agents的评估

Research Agents更加复杂，结果的好坏与任务本身也有很大的关系，不同领域的任务关注的内容也可能完全不同，评价标准也就不一样。研究评估面临着独特的挑战：

专家们可能在综合分析是否全面上存在分歧
参考内容不断变化，事实依据也会随之改变
更长、更开放式的输出结果会增加出错的可能性

尽管如此，Anthropic还是给出了一定方向：

召回覆盖率：召回信息的覆盖率，收集的信息是否可以能把答案需要的内容覆盖到；
来源质量评估：召回的内容来源是否权威，而不是仅仅是top/先收集到的就OK了；
对于客观事实性问题，可以使用精确匹配验证正确性
大语言模型（LLM）可以标记出无依据的主张和覆盖范围的缺口，还能验证开放式综合内容的连贯性和完整性
基于大语言模型（LLM）的评分标准需要依据人类专家的判断进行校准，以便有效地对智能体进行评分

附属：benchmark BrowseComp 主要用来测试agents能不能在互联网上找到合适的内容，设计的问题易于验证但难以解决。

实战4: Computer use agents

Computer use agents使用人类惯于使用的图形界面graphical user interface (GUI) 操作电脑，评估需要在真实或沙盒环境中运行代理，使其能够使用软件应用程序，并检查它是否达到了预期结果。

评估标准一般要同时考虑token经济性和性能指标

DOM（Document Object Model，文档对象模型）很快但是token消耗多；
Screen-shot（基于截图）要慢一点，但是token消耗少

不同的任务可能不同的操作方式要好些，比如总结知识，一般DOM就好些，但是要在Amazon上买电脑这种任务，基于截图的方式就要好些。在Claude for Chrome产品中，Anthropic开发了评估机制，以确保智能体在每种情境下都能选择正确的工具。这使我们能够更快、更准确地完成基于浏览器的任务。

3.2. 不要只看 pass@k，还要看 pass^k

Agent 系统有非确定性。同一个任务跑 10 次，可能 7 次成功、3 次失败。

这时候只看一次结果很危险。Anthropic 特别强调了两个指标：pass@k 和 pass^k。

pass@k 衡量的是：跑 k 次，只要有一次成功就算成功。这个指标适合"多试几次总能找到答案"的场景，比如代码生成候选方案；

pass^k 衡量的是：跑 k 次，每一次都必须成功。这个指标更适合用户真正关心稳定性的产品场景。

如果一个 Agent 单次成功率是 75%，跑 3 次时，至少一次成功的概率会变高，但连续 3 次都成功的概率只有大约 42%。这就是很多 demo 看起来能用、生产里却不稳定的原因。

对用户来说，"偶尔能成功"通常不够。用户要的是"每次都别出错"。

4. 从 0 到 1 搭建 eval：别等完美再开始

很多团队不做 eval 的理由是：样本不够、标准没定、系统还在变。

但原文里有个很实用的建议：早期不需要几百条复杂样本，20 到 50 条来自真实失败或手工测试路径的任务就很有价值 。

我会把这个路线图拆成三步：

第一步，先把你已经在手工测试的东西固化下来。每次发布前你都会点一遍的流程，就是最早的 eval 样本。

第二步，把任务写清楚。一个好任务应该让两个懂业务的人独立判断时得出相同结论。任务如果含糊，后面的分数一定是噪声。

第三步，覆盖正例和反例。只测"应该搜索时能不能搜索"，会训练出一个什么都搜索的 Agent；也要测"不该搜索时能不能不搜索"。只测成功路径，系统会在边界路径上崩掉。

6. 评测应该看 outcome，而不是死盯固定路径

Agent 经常会找到我们没想到的路径。过度规定工具调用顺序，容易把有效方案误判为失败。

比如 coding agent 修一个认证漏洞，你当然希望它读相关文件、改代码、跑测试。但你不一定应该要求它必须先读 A 文件，再读 B 文件，再执行 C 命令。只要最终测试通过、漏洞关闭、没有引入新问题，路径可以有弹性。

这也是为什么 grader 设计要小心。太松会让 Agent 钻空子；太死会惩罚合理的创造性。

更好的方式是：

对最终状态做硬验证
对关键安全约束做硬验证
对过程质量做软评估
对部分完成给 partial credit

一个客服 Agent 如果识别了问题、验证了身份，但最后退款失败，它和一开始就答非所问不是同一种失败。评测系统应该能表达这种差异。

7. eval 不是一次性项目，而是长期资产

Agent eval 很像单元测试，但维护成本更高。因为模型会变，工具会变，产品需求会变，用户行为也会变。

一套健康的 eval suite 应该持续加入新样本：

线上真实失败案例
用户投诉和 bad case
新功能对应的能力测试
曾经修过的问题回归测试
高风险业务路径

当某个 capability eval 已经接近 100% 通过率，它就应该变成 regression eval。也就是说，它不再用来衡量"能不能做到"，而是用来保证"以后别退化"。

这里有个很重要的工程习惯：不要只看分数，要读 transcript。

如果分数没提升，可能是 Agent 真不行，也可能是任务写错、grader 写死、环境不稳定。只看 aggregate score，很容易做错判断。

8. 自动化 eval 只是质量体系的一层

Anthropic 最后用 Swiss Cheese Model 做了一个很好的类比：没有任何一层质量保障能捕获所有问题。

自动化 eval 很重要，但它不能替代线上监控、用户反馈、A/B 测试、人工 transcript review。

更合理的结构是：

上线前：自动化 eval 做快速迭代和回归保护。
上线后：生产监控发现真实分布漂移。
关键场景：人工抽查 transcript，校准 LLM judge。
重大改动：A/B 测试验证真实用户效果。
Agent 系统的问题往往不是单点 bug，而是复杂系统行为。只靠一层测试，很容易漏。

结语：Agent 工程的核心不是更长的 prompt

很多人做 Agent，第一反应是调 prompt、换模型、加工具。

这些当然重要。但系统要真正进入生产，最核心的问题会变成：你怎么知道这次改动让它变好了？你怎么知道没有引入回归？你怎么知道它不是只在 demo 样本上表现好？

答案就是 eval。

我的判断是，未来 Agent 工程能力的分水岭，不是会不会写一个炫酷的 agent loop，而是能不能建立一套持续运行、可解释、可维护的评测体系。

能被评测，才能被改进。不能被评测，就只能靠感觉。

参考资料：

Anthropic Engineering Blog: Demystifying evals for AI agents