你的 Agent 真的变好了还是「感觉」变好了
最后更新于
好的 Agent 评估能把「这个版本的 Agent 好像变差了」这种模糊感受，变成团队真正可以行动的数字。 Anthropic 工程团队写了一篇相当扎实的 《Demystifying evals for AI agents》，把他们在 Claude Code 等产品里踩过的坑沉淀成了方法论。 在这篇帖子中分享一下自己读完后感触颇深的几个点。
为什么 Agent 评估比想象中难
单轮 LLM 评估很干净：输入 prompt、输出回答、评分器打分。 Agent 把这种简单性彻底打破。它会在多轮里使用工具、修改环境状态、根据中间结果调整策略， 错误会传播，副作用会叠加。哪怕过程看起来很丑，最终结果也可能是对的，反之亦然。
以 Memex 自己的知识库 Agent 为例。当你记录一段内容时，Agent 会调用 LS、Grep、Read、Edit、Write 这类工具，加上更高层的「更新洞察」「跳过组织」等动作，在多个回合里反复折腾文件系统。 其中一些结果是可以客观验证的（文件写对了吗？关联还在吗？）， 另一些则只能主观判断（这个洞察值得吗？拆得粒度对不对？）。
为什么 Agent 评估这么难
以 Memex 知识库 Agent 为例
fact_id 是否关联？结构是否符合 P.A.R.A.？
分类是否合理？
拆分粒度对不对？
Agent 通常配备多样工具，需要在当前环境根据指令多轮调用，修改状态并根据变化调整策略， 最终产出既包含可客观验证的部分，也包含只能主观评价的部分。
评估框架的核心术语
Anthropic 在文章里给出了一组小而精确的术语，理解了它们后续讨论会顺畅很多：
- 任务（Task）：一组明确输入和成功标准的测试样例。
- 试验（Trial）：对一个任务的单次尝试。因为输出不稳定，所以要跑多次。
- 评分器（Grader）：为产出某个维度打分的逻辑，一个任务可以有多个。
- 运行记录（Transcript）：一次试验的完整记录，包含推理与工具调用。
- 最终结果（Outcome）：试验结束时环境的最终状态。
- 评估框架（Eval harness）：驱动整个过程的执行器，编排试验、记录步骤、汇总结果。
- 评估场景（Eval suite）：一组围绕同一能力或行为的任务集合。
Anthropic 的评估框架
harness、suite、task、grader、metric、trial 的层级关系
评估框架提供 Agent 运行环境，定义 Agent，定义评估场景，并行运行任务，追踪每一步， 对输出进行评分，最后汇总结果。
三类 Agent 评分器
实际工作里，Agent 评估通常会同时用上三种评分器，对不同维度选择最合适的工具。
基于代码的评分器
通过字符串匹配、相似度计算、工具调用验证、单元测试通过/不通过等方式给结果打分， 评分器本身就是确定性的代码：快速、便宜、可复现、易于调试。 缺点是对正确结果的变体不友好，对主观维度也无能为力，所以只用在能机械验证的产出上。
基于模型的评分器（LLM-as-judge）
让一个 LLM 充当评委，按自然语言写的评分标准打分。引入参考解或多位评委可以提升置信度。 代价是：你正在用一个不确定的评估器去对一个不确定的 Agent 打分， 所以基于模型的评分器必须和人工评分反复校准才靠得住。
基于人工的评分器
通过领域专家评审、众包打分、A/B 测试、评分员一致性来评估结果，慢但权威。 它的主要工作是校准基于模型的评分器，以及解决主观维度上的争议。
如何评估 Agent？
Agent 评估通常结合三种类型的评分方式
非确定性：pass@k 与 pass^k
Agent 行为在多次运行间会发生波动，今天通过的任务明天可能就失败了。 原文给出了两个互补的指标来刻画这种不确定性。
pass@k：k 次里至少成功一次
pass@k 是在 k 次尝试里至少成功一次的概率。 随着 k 增大，这个值上升：尝试越多，「至少有一次成功」就越容易。 通常我们希望 pass@1 越接近 100% 越好，因为终端用户很少重试。
pass^k：k 次全部成功
pass^k 是 k 次尝试里全部成功的概率。 随着 k 增大，这个值下降：要求越多次都不出错，标准就越苛刻。 面向终端用户、必须「次次都成」的 Agent 格外关心这条曲线。
Agent 评估中的非确定性如何捕捉
Anthropic 给出了两种互补的指标
尝试多少次能至少成功一次。我们希望 pass@1 接近 100%， 即首次尝试就完成的比例越高越好。
连续 k 次能否全部成功。能容忍的 k 越大， 代表 Agent 在生产环境里越稳定。
在 k=1 时两条曲线相同（都等于单次成功率）。 到 k=10 时它们讲的故事完全相反：pass@k 趋近 100%，pass^k 趋近 0%。 到底用哪条，要看你真正需要满足的用户期望。
从零做 Agent 评估的建议
原文最后给出了一份操作手册，下面是我们最常翻看的精华部分。
Anthropic 给出的评估建议
为什么 / 什么时候 / 如何做
有效的评估让团队更有信心地发布 Agent。 无论是改了 prompt、换了运行时还是升级了模型，评估都能回答那个核心问题：「Agent 真的变好了吗？」
在 Agent 开发的任何阶段做评估都有用。 早期能促使你明确成功标准，后期能维持一致的质量。开始得越早，建立成本越低。
灵活组合多种评分器，并明确分数如何合成：加权？必须全过？还是混合？
早期定义 20–50 个简单任务，从真实失败案例中收集，少量样本就能带来巨大收益（80/20 法则）。
任务要明确到两位领域专家会得出相同结论。0% pass@100 通常说明任务有问题，而不是 Agent 不行。
同时覆盖应该和不应该两类情况，避免单边优化。
评估环境要相互隔离，避免共享状态、剩余文件、资源耗尽等带来的关联失败。
把评估集当作活的工件，定期阅读 transcripts， 将稳定下来的能力任务「毕业」到回归任务集，发现异常时回头审视评分器。
把任务集开放给领域专家和产品团队，他们离用户最近，最了解需求边界。
原文还提到了 Harbor、Braintrust、LangSmith、Arize、Langfuse 等评估框架。 等我们在 Memex 的 Agent harness 中用得更多以后，再来分享实际体验。
Agent 评估对 Memex 来说意味着什么
Memex 在你手机上跑着一整套多 Agent 系统：Card Agent、PKM Agent、Comment Agent、Insight Agent， 再加上你自己写的自定义 Agent。每个 Agent 都自治、会调用工具、会修改你的知识库状态。 Anthropic 这套术语正好对应了我们思考质量时的方式： 为每类记录定义任务，混合用客观与主观的评分器， 再用 pass^k 这种「次次都成」的指标来约束用户每天看到的体验。
评估其实是团队和自己关于「更好」的对话。 这场对话开始得越早，Agent 就越不像「老虎机」，越像一个每个版本都在变靠谱的队友。
想看完整原文，请阅读 Anthropic 工程博客。如果对 Memex 的实现感兴趣，源代码已开源，在手机上运行 AI Agent 真正需要什么一文也涵盖了 Agent 架构的更多细节。
FAQ：AI Agent 评估常见问题
什么是 AI Agent 评估？
Agent 评估是给 AI Agent 的程序化测试：给它一个输入任务，让它在自己的工具集里跑完，再用评分器去看它的运行记录和最终状态是否达标。和单轮 LLM 测试不一样，Agent 评估必须能处理多步工具调用、状态变化和部分得分。
pass@k 和 pass^k 有什么区别？
pass@k 是 k 次尝试里至少成功一次的概率，k 越大值越大；pass^k 是 k 次尝试全部成功的概率，k 越大值越小。pass@1 通常用来衡量首次成功率；pass^k 则用来衡量 Agent 是否每次都靠得住，决定终端用户体验。
代码、模型、人工三类评分器应该用哪一种？
三种都用，按维度配。能用代码确定性验证的，用代码评分器；开放式输出和语气这类，用模型评分器（LLM-as-judge）；用来校准模型评分器、解决主观争议的，用人工评分器。Anthropic 的建议是混合搭配，而不是只挑一种。
搭一个 Agent 评估集需要多少个任务？
从真实失败案例里挑 20 到 50 个就够开始了。Anthropic 反复强调 80/20 法则：少量精挑的任务在迭代早期能带来最大收益。后面随着 Agent 成熟再扩，把稳定的任务「毕业」到回归任务集。
为什么 pass@100 = 0% 通常说明任务有问题，而不是模型不行？
如果一个前沿模型 100 次都做不出来，最大概率是任务定义模糊、评分器太严，或者运行环境拦掉了正确解法。Anthropic 建议先去复核任务规格和评分器，再考虑模型本身的能力问题。