为什么你的 AI Agent“越改越差”？Anthropic 总结了 8 步评测方法

你有没有遇到过这种场景？

Agent 上线了，用户开始反馈：“最近感觉它变笨了。”

你改了提示词，修好一个问题，结果另一个功能又坏了。你只能手动试、凭感觉猜，祈祷别再出事。

Anthropic 在工程博客里，把这种状态叫作 “flying blind”（盲飞）。

他们写了一篇长文《Demystifying evals for AI agents》，总结了团队内部和前沿客户踩过的坑。这篇文章，我帮你拆成最实用的部分。

一、先搞懂：Agent 评测到底在测什么？

评测（eval）很简单：给 AI 一个输入，用评分逻辑给输出打分。

但 Agent 不一样。它要跨多轮调用工具、修改环境状态，错误还会层层累积。

所以评测里有几个关键概念，先记住：

• Task（任务）：一个带明确输入和成功标准的测试
• Trial（试验）：对任务的一次尝试。模型输出有随机性，要跑多次
• Grader（评分器）：给表现打分的逻辑
• Transcript（轨迹）：一次试验的完整记录，含工具调用、推理过程
• Outcome（结果）：环境最终的状态

这里有个精彩的例子：订机票的 Agent 最后说“已为您订好”，但真正的结果，是数据库里有没有这条订单。

别信它说了什么，要看它做了什么。

还有个有趣的插曲：Opus 4.5 在 τ2-bench 的订机票题里，发现了政策里的一个漏洞，给用户找到了更好的方案。按原评测它“失败”了，但其实它更聪明。

评测，有时会跟不上模型。

二、为什么一定要做评测？

早期靠手动测试和直觉，确实能走很远。

但 Agent 一旦上线并规模化，问题就来了：

• 只能等用户投诉，再手动复现
• 分不清是真退步还是噪声
• 没法在上线前跑几百个场景
• 新模型发布，别人几天升级，你测试几周

Anthropic 自己的 Claude Code 就是这样走过来的：先快速迭代，后来才为“简洁度”“文件编辑”，再到“过度设计”这类复杂行为补上评测。

Descript 做视频编辑 Agent，把成功拆成三件事：别搞坏东西、按我说的做、做得好。Bolt 则是在拥有大量用户后，用 3 个月搭起评测体系。

文章里有一句话我特别认同：

评测的成本是眼前的，收益是复利的，所以很容易被低估。

三、三类评分器：怎么给 Agent 打分？

评分器主要有三种，各有优劣。

1. 代码评分器：字符串匹配、单元测试、静态分析、工具调用检查。快、便宜、客观，但对“合理的不同写法”很死板。

2. 模型评分器：基于评分细则、成对比较、多评委共识。灵活、能处理开放任务，但有随机性，需要用人工校准。

3. 人工评分器：专家评审、抽检、A/B 测试。是黄金标准，但又慢又贵。

最佳实践是组合使用：能用确定性的就用确定性的，必要时用 LLM，再用人工做校准。

另外，评测还分两类：

• 能力评测：问“它能做好什么？”，通过率应该从低开始，给团队一座可爬的山
• 回归评测：问“以前会的还会吗？”，通过率应接近 100%

能力评测通过率高了，就可以“毕业”，变成回归测试。

四、不同类型的 Agent，怎么测？

编码 Agent：最适合确定性评分。代码能跑吗？测试通过吗？SWE-bench Verified 一年内从 40% 涨到 80% 以上。之后还可以评估代码质量、工具使用方式。

对话 Agent：要看结果状态（工单解决了吗）、过程约束（10 轮内完成了吗）、语气是否得体。常常需要另一个 LLM 来扮演用户。

研究 Agent：没有标准答案，要组合多种检查：结论有没有来源支撑（groundedness）、是否覆盖关键事实、来源是否权威。

电脑操作 Agent：在真实或沙盒环境里跑，检查后端状态。比如“订单是否真的生成”，而不只是“页面显示了确认”。

五、最容易被忽视的坑：非确定性

同一个任务，Agent 这次过了，下次可能就挂了。

Anthropic 推荐两个指标：

• pass@k: k 次尝试里，至少成功一次的概率。适合“一次成功就行”的场景
• pass^k: k 次全部成功的概率。适合要求稳定的面向用户产品

举个例子：单次成功率 75%，连跑 3 次都成功的概率只有 (0.75)³ ≈ 42%。

对客服这类 Agent 来说，用户要的是“每次都靠谱”，不是“偶尔很厉害”。

六、从 0 到 1: 8 步路线图

这是全文最干的部分，我帮你浓缩一下。

Step 0：尽早开始。 不需要几百个用例，从真实失败中提炼 20-50 个简单任务就是很好的起点。越晚做，越像是在对一个线上系统倒推成功标准。

Step 1：从你已经在手测的东西开始。 上线前手动检查的行为、bug 列表、客服工单，都是现成的用例。

Step 2：写没有歧义的任务，并附参考答案。 好任务的标准：两个领域专家独立判断，会得出相同的结论。

如果任务通过率长期为 0%，更可能是任务坏了，而不是 Agent 不行。

Step 3：正反两面都要测。 只测“该搜索时搜不搜”，会训练出什么都搜的 Agent。要同时测“不该搜索时别搜”。

Step 4：环境要干净稳定。 每次试验独立启动。Anthropic 曾发现 Claude 通过翻看上一次试验的 git 历史“作弊”。

Step 5：认真设计评分器。

• 评产出，而不是路径。别规定必须按某个顺序调用工具，会抹杀创造力
• 多步骤任务要给部分分
• LLM 评委要给它一条退路：信息不足就回答“Unknown”
• 防止 Agent 钻空子

Step 6：读 Transcript. 不读轨迹，你不知道评分器有没有冤枉好人。好的评测，失败应该“看起来公平”。

Step 7：警惕能力评测饱和。 一个 100% 的评测只能防回退，不能指导进步。

Step 8：让评测成为团队日常。 设专门团队维护基础设施，产品、客户成功甚至销售，都可以用 Claude Code 提交评测任务。

最让我震撼的案例：Opus 4.5 在 CORE-Bench 上一开始只有 42%。后来发现评分过于死板（期望 96.124991，答 96.12 就被判错）、任务描述模糊。修复之后，分数跳到了 95%。

分数低，不一定是模型差，可能是考卷出错了。

七、评测不是万能的：瑞士奶酪模型

文章最后有个很好的比喻。

自动化评测快、可复现、无用户影响，但可能与真实使用脱节。生产监控能暴露真实问题，但已经触达了用户。A/B 测试、用户反馈、人工复盘，各有盲区。

就像安全工程里的瑞士奶酪模型：每一层都有洞，多层叠加，才能拦住大部分问题。

最有效的组合是：自动化评测做快速迭代，生产监控提供真实依据，定期人工评审做校准。

八、想上手？这些框架可以参考

Anthropic 在附录里提到了几个工具：

• Harbor：容器化环境运行 Agent，适合大规模试验
• Promptfoo：轻量开源，用 YAML 声明测试
• Braintrust：离线评测 + 线上观测 + 实验跟踪
• LangSmith / Langfuse：追踪与评测，后者可自托管

但文章也提醒：框架只是加速器，真正有价值的是你打磨的测试用例和评分器。

写在最后

把全文压缩成一句话：

把“感觉它变差了”，变成“第 37 号任务从通过变成了失败”。

三个行动建议，今天就能做：

1. 打开你的 bug 列表，挑出 20 个真实失败案例
2. 给每个案例写清楚“怎样算通过”
3. 跑一遍，然后认真读 Transcript

评测不会让你的 Agent 立刻变强，但它会让你知道自己在往哪个方向走。

原文：Anthropic Engineering《Demystifying evals for AI agents》(https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents)。本文为编译与改写，版权归原作者所有。

JOTO 企业落地观察

• 企业部署 AI Agent 时，若缺乏标准化评测体系，将陷入‘盲飞’状态：每次迭代无法量化影响，故障归因依赖人工复现，导致版本回滚成本陡增。Anthropic 提出的 Task/Outcome/Transcript 三层验证结构，为企业构建可审计的智能体交付流水线提供了基础范式。
• RAG 知识工程中，评测重点应从‘答案是否正确’转向‘答案是否源自指定知识源且未幻觉’。Anthropic 强调的 groundedness 检查与多源交叉验证，正是 RAG 系统避免‘自信错误’的关键防线，需嵌入评分器设计而非仅依赖 LLM 自评。
• AI 安全治理需将非确定性指标（如 pass^k）纳入 SLA 合约条款。当客服 Agent 的 pass^3 低于阈值时，系统应自动触发降级策略而非继续服务——这要求评测基础设施与运维告警链路深度集成，而非仅作为研发阶段的质量门禁。