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 会做多轮决策读任务、拆计划、调用工具、读取工具结果、更新环境状态最后再输出结果。也就是说我们评估的不是一句话而是一条执行轨迹。这张图很关键上半部分是传统单轮 evalprompt 进去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(orchecks) 是打分逻辑是Agent在某一个方面的打分一个任务可以有多个评分者每个评分者包含多个断言可以看结果也可以看轨迹。Transcriptortrajectory/trace是一次Trial的完整执行记录包括工具调用、模型回复、中间状态对于Anthropic API这是评估运行结束时的完整消息数组包含评估期间对API的所有调用以及所有返回的响应。Outcome是最终环境状态注意一般来说都是不是大模型的返回的回答, 在使用大模型时经常遇到的问题是他告诉你任务完成了但实际文件并没有改对、数据库中的订单也没有真的创建所以需要强调的是具体任务实际的完成度。Eval harness是跑完整评测的基础设施它提供沙箱环境和工具并发运行任务记录所有步骤对输出进行评分并汇总结果。Agent harnessorscaffold 是让模型具备 Agent 行为的系统框架, 例如Claude Code是一个灵活的智能体框架我们通过智能体SDK使用其核心原语来构建我们的长期运行的智能体框架。这里最容易忽略的是 transcript, 很多团队只存最终输出不存过程。这样一旦失败就只能靠猜到底是 prompt 没写清楚工具 schema 不好检索结果错了模型没读懂工具返回还是 grader 写得太死如果保存完整 transcript定位会快很多。失败样本不再只是一个红叉而是一条可复盘的执行轨迹。3. 如何评估AI agents文章总结了当前大规模部署的Agent类型基本有4种:Coding AgentsResearch AgentsComputer use AgentsConversational Agents对于这些AgentsAnthropic介绍了几种成熟技术。实际操作时可以将这些方法作为基础然后将其扩展到具体的领域。3.1 Grader 不能只有一种Agent eval 的打分逻辑通常不能靠单一方法完成。Anthropic 总结了三类 grader代码型、模型型、人工型。我的经验是硬指标用代码软质量用模型高风险用人工抽检。不要让 LLM judge 去判断本来可以用代码验证的事情也不要强行用规则去判断明显语义化的问题。实战1: Code Agents的测评Coding Agents 的测评依赖 1定义清晰的任务 2稳定的测试环境 3全面的测试方法所以对于Coding Agents最简单的测试方法就是是否通过测试用例其中有两个公开的测试benchmarkSWE-bentch 和 Terminal-BenchSWE-bench 是给Agents GitHub 上热门python仓库收集的问题并通过运行测试套件对解决方案进行评分只有在修复失败测试且不破坏现有测试的情况下解决方案才算通过。Terminal-bench 要更加综合一点测试的是技术任务本身包含构建linux内核或者训练一个模型等在具体一点文章讲了一个修复authentication bypass vulnerability(安全漏洞) agent的测评方法如下所示task:id:fix-auth-bypass_1desc:Fix authentication bypass when password field is empty and ...graders:-type:deterministic_testsrequired:[test_empty_pw_rejected.py,test_null_pw_rejected.py]-type:llm_rubricrubric:prompts/code_quality.md-type:static_analysiscommands:[ruff,mypy,bandit]-type:state_checkexpect:security_logs:{event_type:auth_blocked}-type:tool_callsrequired:-{tool:read_file,params:{path:src/auth/*}}-{tool:edit_file}-{tool:run_tests}tracked_metrics:-type:transcriptmetrics:-n_turns-n_toolcalls-n_total_tokens-type:latencymetrics:-time_to_first_token-output_tokens_per_sec-time_to_last_token这个示例中graders和metrics都有使用展示了所有可用评分器并不是说都要用只是给大家打个烊。在实践中代码评估一般就是写单测然后并使用大语言模型LLM评分标准来评估整体代码质量仅在必要时添加额外的评分器和指标。实战2: 对话Agents的评估对于对话Agentsinteraction(与客户交互)本身的质量至关重要可以验证最终的任务状态(有没有解决用户的问题系统级别)和用户的评价尤其是用户评价如果用户评价是满意的那么任务执行和对话质量应该都是没有问题的。另外与大多数其他评估不同它们通常需要第二个大语言模型来模拟用户。Anthropic在Building and evaluating alignment auditing agents中采用这种方法通过连续多轮的、故意找茬的对抗性对话来对大模型进行高强度的压力测试。对话式智能体的成功可以是多维度的工单是否得到解决状态检查是否在10轮对话内完成对话记录约束语气是否恰当大语言模型评分标准两个包含多维度考量的基准是-Bench及其后续版本τ2-Bench。它们模拟跨领域的多轮交互如零售支持和机票预订其中一个模型扮演用户角色而智能体则应对现实场景。graders:-type:llm_rubric# 对应对话质量本身rubric:prompts/support_quality.mdassertions:-Agent showed empathy for customers frustration-Resolution was clearly explained-Agents 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:10tracked_metrics:-type:transcriptmetrics:-n_turns-n_toolcalls-n_total_tokens-type:latencymetrics:-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 agentsComputer use agents使用人类惯于使用的图形界面graphical user interface (GUI) 操作电脑评估需要在真实或沙盒环境中运行代理使其能够使用软件应用程序并检查它是否达到了预期结果。评估标准一般要同时考虑token经济性和性能指标DOMDocument Object Model文档对象模型很快但是token消耗多Screen-shot基于截图 要慢一点但是token消耗少不同的任务可能不同的操作方式要好些比如总结知识一般DOM就好些但是要在Amazon上买电脑这种任务基于截图的方式就要好些。在Claude for Chrome产品中Anthropic开发了评估机制以确保智能体在每种情境下都能选择正确的工具。这使我们能够更快、更准确地完成基于浏览器的任务。3.2. 不要只看 passk还要看 pass^kAgent 系统有非确定性。同一个任务跑 10 次可能 7 次成功、3 次失败。这时候只看一次结果很危险。Anthropic 特别强调了两个指标passk和pass^k。passk衡量的是跑 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