Agent上线后才发现变差？Anthropic提醒：没有eval就是盲飞

摘要

很多 Agent 团队都会经历同一个阶段：原型阶段靠手测、dogfood 和直觉推进很快；上线后用户开始反馈“它好像变差了”“它乱用工具”“它改动太多”“它没有完成真实任务”。这时团队才发现，自己没有可靠办法判断到底是模型退化、prompt 改坏、工具环境变化，还是用户场景分布漂移。

Anthropic Engineering 在《Demystifying evals for AI agents》中把这个问题说得很直接：没有 eval，Agent 团队很容易陷入 reactive loop，只能等生产问题出现后再猜测和修补。对技术研发团队来说，Agent eval 不是锦上添花，而是让 Agent 从 demo 走向生产的核心工程基础设施。

背景：Agent 比普通 LLM 更难评测

传统单轮 LLM 评测相对简单：给一个 prompt，看 response 是否符合预期。但 Agent 不同。Agent 会多轮调用工具、修改外部状态、根据中间结果调整策略，错误也会沿着执行轨迹传播和放大。

Anthropic 在文章中强调，评测 Agent 时不仅要看最终文本，还要看完整 transcript、工具调用、推理过程、中间结果和最终环境状态。一个订票 Agent 最后说“机票已预订”没有意义，真正的 outcome 是数据库里是否存在正确预订记录。一个编码 Agent 说“我修好了”也不够，真正 outcome 是代码是否通过测试、是否修复失败用例、是否没有破坏已有行为。

这也是很多 Agent 项目上线后质量失控的根源：团队评的是回复，用户要的是结果。

技术要点一：先分清 task、trial、grader 和 outcome

Anthropic 给出了一组非常实用的定义。task 是一个带输入和成功标准的测试用例；trial 是一次对 task 的尝试，因为模型输出有随机性，同一 task 往往要跑多次；grader 是评分逻辑，可以有多个断言；transcript 是完整轨迹，包括输出、工具调用和中间结果；outcome 是试验结束后的最终环境状态；eval harness 则负责端到端运行、记录、评分和聚合。

这些定义看似基础，但能避免很多混乱。比如很多团队说“我们的 Agent eval 通过率 80%”，但没有说明是单次 trial 还是多次 trial，评分看的是 transcript 还是 outcome，grader 是代码检查、人类判断还是 LLM judge。这样的数字很难指导研发决策。

对研发团队来说，建立 Agent eval 的第一步不是上复杂平台，而是统一语言：到底测什么、一次尝试如何定义、什么叫成功、谁来打分、结果存在什么环境里。

技术要点二：grader 要组合使用，不能迷信 LLM judge

Anthropic 将 Agent grader 分成三类：code-based、model-based 和 human。代码类 grader 包括字符串匹配、测试用例、静态分析、状态检查等；模型类 grader 适合评估语义、风格、覆盖度和 groundedness；人类 grader 则用于专家判断和校准模型评分。

关键点是组合使用。编码 Agent 最适合确定性 grader：单元测试、类型检查、lint、安全扫描、回归测试。研究 Agent 则需要 groundedness 检查、覆盖度检查和来源质量检查。对话 Agent 除了任务是否完成，还要评估轮数、语气和状态变化。

如果所有评分都交给 LLM judge，系统很容易产生虚假信心。LLM 可以帮助发现遗漏和主观质量问题，但它也会受提示词、上下文和自身偏差影响。更稳的做法是：能用代码验证的尽量用代码；主观项用 LLM rubric；关键任务定期用人类专家校准。

技术要点三：能力 eval 和回归 eval 不能混在一起

Anthropic 区分 capability eval 和 regression eval。能力 eval 问的是“这个 Agent 能做到什么”，应该有一定难度，初始通过率可以不高，给团队留下爬坡空间。回归 eval 问的是“它是否还能稳定做到过去能做的事”，通过率应接近 100%，一旦下降就说明有东西坏了。

很多团队的问题是把二者混在一起：用太简单的任务评估能力，导致分数早早饱和；或者用太难的探索任务做上线门禁，导致每次发布都噪声很大。

成熟做法是让 eval suite 生命周期化。一个能力 eval 在模型和系统优化后通过率变高，可以毕业为回归 suite；新的难任务继续作为能力 eval。这样既能推动能力提升，也能防止已经修好的行为重新退化。

技术要点四：eval harness 必须接近生产，但环境要隔离

Agent eval 的难点不只在题目，还在 harness。Anthropic 提醒，评测时 Agent 的运行方式要尽量接近生产，否则测出来的是另一个系统。但每次 trial 又必须从干净环境开始，避免共享状态污染结果。

这一点对编码 Agent 尤其重要。若不同 trial 共用同一目录、缓存、Git 历史或临时文件，Agent 可能无意中利用前一次实验留下的信息，导致成绩虚高。反过来，如果环境资源不足、依赖不稳定、CPU 内存限制导致多次失败，这些失败也不是 Agent 能力问题，而是 eval 基础设施问题。

因此，Agent eval harness 应该像 CI 系统一样严肃：固定依赖、隔离环境、记录版本、保存 transcript、可重复运行，并能把失败归因到 Agent、grader 还是环境。

研发视角：读 transcript 是 Agent 开发的基本功

Anthropic 反复强调，不要只看分数，要读 transcripts。因为分数下降可能是真退化，也可能是任务写得模糊、grader 过严、环境坏了，或者 Agent 找到了更好的解法但被静态规则误判。

这对研发负责人很有现实意义。Agent eval 不是黑盒排行榜，而是研发反馈系统。每次失败都应该能回答：Agent 是否理解任务？是否选错工具？是否被无关上下文干扰？是否中途遗忘约束？是否最终 outcome 正确但表达不符合 grader？

只有读过足够多 transcript，团队才知道自己的 eval 是否真的测到了重要行为。否则 eval 分数会变成新的玄学。

实践建议：从 20 个真实任务开始

Anthropic 的路线图很务实：不要等到有几百个任务才开始。早期 20 到 50 个来自真实失败或核心需求的简单任务就有价值。早期 Agent 变更通常影响较大，小样本也能暴露方向问题。

研发团队可以按以下顺序落地：

1. 从线上反馈、手测失败和核心用户路径中收集 20 个任务。
2. 每个任务写清输入、允许工具、成功标准和不应发生的行为。
3. 为每个任务准备 reference solution，证明任务可解、grader 可用。
4. 对编码任务优先使用单元测试、静态分析和状态检查。
5. 对研究任务增加来源质量、覆盖度和 groundedness 检查。
6. 每个任务跑多次 trial，记录通过率、成本、延迟和失败类型。
7. 每周抽样读 transcript，把不公平 grader 和模糊任务修掉。

这套流程不需要一开始很重，但必须持续维护。eval suite 和单元测试一样，是活的工程资产。

风险与限制

Agent eval 也会制造误导。任务太窄会导致过拟合，grader 太弱会放过坏结果，LLM judge 没校准会给出虚假高分，静态 benchmark 饱和后会掩盖真实能力提升。Anthropic 也提醒，完整理解 Agent 质量不能只靠自动 eval，还需要生产监控、A/B 测试、用户反馈、人工 transcript review 和系统性 human eval。

因此，eval 不是替代所有质量方法，而是第一层防线。它让团队在上线前发现一部分问题，在模型升级和 prompt 变更时快速回归，在生产反馈出现后能把新问题沉淀成可重复测试。

结语

Agent 产品最大的风险之一，是团队以为自己在迭代，其实是在盲飞。模型换了、prompt 改了、工具多了、上下文压缩策略变了，用户才告诉你“它变差了”。这时再排查，成本通常已经很高。

Anthropic 这篇文章的核心提醒很明确：Agent eval 不是研究团队的装饰品，而是产品研发的基础设施。没有 eval，Agent 的每一次优化都可能是一次未知风险；有了 eval，团队才有资格快速迭代。

参考来源

• Anthropic Engineering: Demystifying evals for AI agents
  https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents