不是总结 Anthropic 说了什么，而是——

我作为一个真的在折腾 Agent 的人，看完这篇长文之后，哪些地方被戳中了，哪些地方后背一凉，又有哪些是“啊原来坑在这”的瞬间。

说实话，这两天我刷到 Anthropic 这篇长文的时候，第一反应不是“又一篇工程博客”，而是一句大白话：

这帮人终于把「Agent 为什么老翻车」这件事摊开讲明白了。*

而且讲得非常不留情面。

他们聊的不是模型多强，也不是 Claude Code 多牛，而是一个所有做 Agent 的人都会经历、但很少有人愿意正面承认的问题——

你根本不知道你现在这个 Agent，到底行不行。*

为什么我一看到“评估”这两个字就有点紧张

在真正开始系统做 Agent 之前，我对“评估（Evals）”这件事其实是有点轻视的。

总觉得嘛，先把功能跑通，先让 Agent 能干活，等用户多了自然就知道哪里不行。

但 Anthropic 在文章里戳的第一个点，直接把我打清醒了：

没有评估，团队迟早会进入“头痛医头、脚痛医脚”的被动循环。

这句话太真实了。

你永远是在生产环境里等用户告诉你“好像变差了”，然后你再去复现、修 bug、顺便祈祷别引入新的回归问题。

我写到这的时候才意识到，

这玩意不是“工程不够熟练”，而是你在盲飞。

什么叫 Agent 的评估，真的不是跑个测试那么简单

文章里先把“评估”的基本结构拆了一遍，我一开始看还觉得有点教科书，结果越看越不对劲。

对于早期 LLM，你确实可以一问一答、一条 prompt 对一条输出。

但 Agent 不一样，它会：

多轮交互
调工具
改环境状态
根据中间结果修正策略

也就是说，错误不是一次性的，是会传播、会累积的。

而且最阴间的一点在于：

模型有时候“失败了评估”，但实际上给了更好的答案。*

文章里提到 Opus 4.5 订机票那个例子的时候，我是真停了一下。

模型发现了政策漏洞，给用户一个更优方案，但因为不符合原评估规则，被判失败。

我当时脑子里只有一句话：

这要是线上评估直接拦了，用户怕是要骂娘。*

我是怎么把 Anthropic 那套评估概念，翻译成人话的

他们在文中定义了一堆概念，其实非常工程，但如果不转译，很容易当场劝退。

我后来干脆自己拉了个表，给自己理了一遍，不然概念全糊在一起。

Anthropic 说法	我脑子里的版本
Task	一道明确“成功长啥样”的测试题
Trial	同一道题，让 Agent 多考几次
Grader	判卷老师（可以是代码、模型或人）
Transcript	全程录像：说了啥、点了啥、想了啥
Outcome	不是嘴上说成功，而是世界真的变了
Eval harness	考场 + 监控 + 批改系统
Agent harness	Agent 的“身体”，不是大脑本身
Eval suite	一整套专项训练题

这样一看就清楚多了：

评估的不是模型，是“模型 + Agent 框架”这个整体。*

为什么 Agent 一上生产，不做评估一定会炸

Anthropic 这一段写得很克制，但我读的时候是有点后背发凉的。

他们说：

在早期，靠人工测试、内部试用、直觉，确实能走一段路。

但一旦 Agent 开始规模化，这套开发方式会直接崩。

转折点往往只有一句用户反馈：

“怎么感觉更新之后变差了？”*

而你作为开发者，是完全不知道它“具体差在哪”。

Claude Code 就走过这条路。

一开始靠用户反馈快速迭代，后来才逐步补上对简洁性、文件编辑、过度工程化等行为的系统评估。

我看到这里的时候突然意识到一件事：

评估不是为了发现新问题，而是为了防止你自己退步。*

评估这件事，真的有复利

这一段我特别想单独拎出来。

Anthropic 把评估的价值拆成了几个阶段，我对着一条条看，发现几乎全中。

早期：逼你把“成功”说清楚
后期：防止质量慢慢下滑
模型升级：有评估的团队几天搞定，没评估的团队几周起步
白送收益：延迟、token、成本、错误率，全都能顺手监控

我一边看一边在心里骂自己：

早知道当初就不该嫌麻烦。*

三种评分器，其实就是三种“不信任方式”

他们把评分器分成三类：代码、模型、人。

这分类我一开始觉得挺常规，但越想越觉得贴切。

代码评分器：我完全不信你，只信结果
模型评分器：我信你一点，但要规则兜着
人工评分器：我信专家，但我付得起代价吗？

我后来给自己写了个备忘表，提醒什么时候该用哪个，免得又拍脑袋。

场景	最靠谱的评分器
能不能跑	代码评分器
质量、风格	模型评分器
主观体验	人工评分器
校准模型	人工 → 模型

能力评估 vs 衰退评估，这个区分太重要了

这一点我必须单独点名。

能力评估，是问：你能做到什么程度？

衰退评估，是问：你还能不能做到以前的事？

能力评估的通过率，反而不该太高。

那是给团队立一座“还没爬上去的山”。

而当某个能力评估被你刷到接近 100%，

它就该“毕业”，变成衰退评估，天天跑，专门抓退步。

我以前是真的没意识到这两者要分开。

现在回头看，很多混乱，其实就是这俩掺在一起了。

不同 Agent，评估方式真的差很多

Anthropic 后面把几类 Agent 拆开讲，我看的时候一直在对号入座。

编码 Agent：单元测试是王道，质量用 LLM 补
对话 Agent：状态 + 轮数 + 语气，一个都不能少
研究 Agent：覆盖率、来源、groundedness，缺一不可
GUI Agent：环境真实性、延迟、token，全是坑

尤其是 GUI 那一段，我是真的有点共鸣。

你让 Agent 看截图还是抽 DOM，本质上是在拿延迟换理解，这个平衡一旦没想清楚，评估全是噪声。

pass@k 和 pass^k，是我以前完全没算明白的账

这一段我承认，是我以前理解得太糙了。

pass@k：试 k 次，只要有一次成功就算
pass^k：试 k 次，次次都成功才算

一个关注“能不能找到解”，

一个关注“稳不稳定”。

我写到这的时候才突然意识到：

这根本不是指标问题，是产品定位问题。*

从 0 到 1 的评估路线图，反而是全文最实在的部分

最后那套 0→1→长期维护的路线图，说实话没有什么炫技，但非常落地。

尤其是前几步：

不要等规模，20～50 个真实失败案例就够
手动测试过的，全都该变成 eval
写清楚任务，让两个专家能得出同样结论

我看到“阅读失败记录（Transcripts）”那一条的时候，是真的点头了。

不看记录的评估，跟不看日志的线上系统一样危险。*

写到这里，我反而不太想下结论了

如果硬要一句话，那可能是：

Agent 评估不是一套工具，而是一种“不再自欺欺人”的工程习惯。*

Anthropic 这篇文章没有告诉你“该用哪个框架”，

而是在反复提醒你：

别等用户替你做测试。*

剩下的，可能每个团队都会走出不一样的路。

但至少现在，我知道哪些坑是真的不能再假装看不见了。

# AI工程实践 #Agent评估 #Evals
# ClaudeCode #工程复盘
# 模型稳定性 #评估驱动开发