揭秘 AI 智能体评估：从任务、轨迹到生产级 Eval 体系

一、为什么 Agent 越强，评估越难

Anthropic Engineering 在 Demystifying evals for AI agents 中提出了一个很重要的判断：AI Agent 的价值来自自治性、工具使用和多步规划，但这些能力也让评估从“判断一句回答”升级为“判断一个系统是否真正完成任务”。

传统 LLM eval 多数围绕 prompt → response → grader 展开：给模型一个输入，看输出是否匹配参考答案。但现代 Agent 往往会：

• 在多轮对话中不断澄清、计划和修正；
• 调用搜索、代码执行、浏览器、数据库、工单系统等工具；
• 修改外部环境状态，例如文件、UI、数据库、配置、订单或工单；
• 在执行过程中根据中间结果调整策略；
• 给出评估者没有预料到、但对用户更有价值的解决路径。

这意味着，Agent 的最终回复不等于最终结果。一个代码 Agent 可能回复“已修复”，但仓库测试没有通过；一个客服 Agent 可能语气很好，但退款状态没有更新；一个研究 Agent 可能写出漂亮报告，但关键结论没有来源支撑。

因此，Agent eval 的核心问题不是“模型说得对不对”，而是：

在给定任务、工具和环境约束下，Agent 是否以可接受的过程，把真实世界状态推进到了期望状态？

这篇文章尝试把 Anthropic 的方法论转写成面向工程团队的实践指南：如何定义评估对象，如何选择评分器，如何处理不确定性与主观质量，以及如何从 20–50 个真实失败案例起步，构建一套可长期维护的 Agent 评估基础设施。

二、Agent eval 到底在评估什么

Anthropic 特别强调：评估 Agent 时，评估的不是单独模型，而是“模型 + Agent harness + 工具 + 环境”的完整系统。 这点非常关键，因为 Agent 的表现往往取决于多个组件的交互：

对于单轮问答，response 往往就是主要评估对象；对于 Agent，response 只是 transcript 的一部分。更可靠的方式是同时检查三类证据：

1. 结果证据：最终环境状态是否正确，例如测试通过、订单完成、文件生成、页面状态符合预期；
2. 过程证据：工具调用是否合理，是否绕过流程，是否出现危险行为，是否消耗异常多的轮次和 token；
3. 体验证据：语言是否清楚，是否解释了风险，是否对用户友好，是否符合产品 tone 和合规要求。

如果只看最终文本，Agent 可能“说对了但没做成”；如果只看工具调用路径，又可能误伤那些没有走预设路径但真实解决了问题的创造性解法。一个成熟的 eval 体系必须把 outcome 和 transcript 放在同等重要的位置。

三、为什么 eval 是 Agent 工程化的基础设施

早期做 Agent 原型时，团队通常依赖手工测试：开发者跑几个 demo，产品同学试一试，用户反馈坏例子后再修。这个阶段手工验证是必要的，因为团队还在摸索什么叫“成功”。

但一旦 Agent 进入生产环境，只靠手工测试会迅速失效：

Anthropic 在原文中提到多个案例：Claude Code 后来加入了关于简洁性、文件编辑和避免过度工程化的 eval；Descript 为视频编辑 Agent 将成功拆成“不要破坏内容、完成用户要求、完成得好”；Bolt 在 Agent 已经被大量使用后补建 eval 系统，结合静态分析、浏览器 Agent 和 LLM judge 来评估应用行为。

这些案例说明：eval 不是学术 benchmark 的同义词，而是 Agent 产品快速迭代的质量控制面。 它既服务于研发期的能力爬坡，也服务于上线后的回归保护、模型升级决策和生产监控。

四、三类评分器：确定性、语义判断与人工校准

Agent eval 最容易踩的坑之一，是试图用一种 grader 解决所有问题。实际上，评分器应该按任务性质分层组合。

4.1 Code-based grader：能确定就不要猜

代码型评分器适合有客观成功标准的任务，例如：

• 字符串、正则、JSON schema 或 fuzzy match；
• 单元测试、集成测试、端到端测试；
• 静态分析、类型检查、安全扫描；
• 文件系统、数据库、页面 URL、工单状态检查；
• transcript 统计，例如工具调用次数、turn 数、token 用量、延迟。

它的优势是快、便宜、客观、可复现，适合作为 eval 的第一道防线。例如代码 Agent 的任务可以通过测试套件判断是否修复问题；浏览器 Agent 的任务可以检查最终 URL、页面 DOM、后端状态；客服 Agent 的任务可以检查退款状态是否从 pending 变成 processed。

但它也有明显局限：过度刚性的 grader 会惩罚合理变体。 原文提到 CORE-Bench 的例子：模型初始得分很低，但后来发现部分评分逻辑过于严格，例如期望一个高精度浮点值，却拒绝了合理四舍五入的答案；修正任务和 grader 后，分数大幅提升。

4.2 Model-based grader：评估开放式质量

模型型评分器使用 LLM 作为 judge，适合主观或开放式任务：

• 回答是否完整、清晰、连贯；
• 是否遵循产品语气和交互规范；
• 研究报告是否覆盖关键事实；
• 代码是否可维护、是否过度工程化；
• 多个候选答案之间哪个更好。

工程上应尽量避免让 LLM judge “自由发挥”，而要给它结构化 rubric。例如：

rubric:
  task_completion:
    description: "是否完成用户的核心请求"
    score: "0-3"
  groundedness:
    description: "关键结论是否被来源或环境状态支持"
    score: "0-3"
  safety_and_policy:
    description: "是否遵守工具、权限和业务流程约束"
    score: "0-3"
  communication:
    description: "是否清楚解释结果、限制与下一步"
    score: "0-3"
allow_unknown: true
require_evidence: true

这里有两个实践要点：

1. 给 judge Unknown 选项：如果证据不足，允许模型说不知道，减少它为了打分而编造理由；
2. 要求引用证据：让 judge 指出依据来自哪段 transcript、哪个 outcome 或哪个工具结果。

4.3 Human grader：用于高风险和校准

人工评分最慢、最贵，但在高价值、高风险或高度主观的场景仍然不可替代。典型用法不是让人类评审所有样本，而是：

• 对 LLM judge 的样本进行抽样校准；
• 对模型和 grader 分歧的 case 做仲裁；
• 为新任务、新 rubric 和边界样本提供专家标注；
• 检查用户体验、业务价值、合规风险等复杂维度。

成熟团队通常会把三者组合起来：确定性 grader 承担可客观验证的部分，LLM judge 覆盖语义和体验，人类专家负责校准与仲裁。

五、能力评估与回归评估：一个负责爬坡，一个负责守门

Anthropic 将 eval 区分为两类：

5.1 Capability eval：回答“现在能做好什么”

能力评估用于探索 Agent 的能力边界。它通常不会一开始就有很高通过率，因为它的目标正是暴露 Agent 还做不好的地方。

适合放入 capability suite 的任务包括：

• 用户真实失败案例；
• 团队希望新版本具备的复杂能力；
• 长链路、多工具、多轮交互任务；
• 当前模型和 harness 容易不稳定的边界场景。

这类 eval 的价值不是“分数好看”，而是告诉团队下一步应该优化哪里。

5.2 Regression eval：回答“以前会的是否还会”

回归评估用于防止倒退。它的通过率应该接近 100%，并且适合接入 CI/CD、发布门禁和模型升级流程。

一个常见演进路径是：

1. 某类任务先进入 capability suite；
2. 团队持续修复失败模式；
3. 当通过率稳定提升并接近饱和；
4. 将其“毕业”为 regression suite；
5. 再构建更难的新 capability suite。

这类似软件工程中的单元测试演进：新 bug 先被复现为测试，修复后测试长期留在回归集中。

六、不同类型 Agent 的评估策略

Agent 的任务形态不同，评估证据也不同。不要拿代码 Agent 的测试通过率去评估客服 Agent，也不要只用客服对话体验去评估研究 Agent。

6.1 Coding Agent：最终仓库状态优先

代码 Agent 的任务通常包括读代码、修改文件、运行测试、修 bug、实现功能。评估时应优先看：

• 单元测试、集成测试和端到端测试是否通过；
• 修改是否限定在合理范围内；
• 静态分析、类型检查、安全扫描是否通过；
• 是否引入不必要抽象或过度工程化；
• transcript 中是否合理读取文件、编辑代码、运行验证命令。

SWE-bench Verified、Terminal-Bench 等 benchmark 都体现了这个思路：让 Agent 在相对真实的工程环境中完成任务，并用最终状态而非口头解释判断成败。

6.2 Conversational Agent：任务完成 + 交互质量

客服、销售、教练、内部助手等对话 Agent 的难点在于：它们既要完成业务任务，也要让用户感到过程可信、清楚、友好。

评估维度通常包括：

• 业务状态是否完成，例如工单 resolved、退款 processed；
• 是否调用了必要工具，例如身份验证、政策查询、退款处理；
• 是否在合理轮数内完成；
• 是否表达共情、解释清楚、避免误导；
• 是否遵守合规和产品流程。

这类任务往往需要 transcript 级别的评估。最终状态正确但对话体验糟糕，或者语气很好但业务没完成，都不应算作高质量成功。

6.3 Research Agent：groundedness、coverage 与 source quality

研究 Agent 没有单一标准答案，评估更像审稿：

• 结论是否被可靠来源支持；
• 是否覆盖了任务要求中的关键维度；
• 是否遗漏重要反例或限制条件；
• 引用是否真实、准确、可追溯；
• 来源是否权威、时效性是否足够；
• 长报告是否结构清楚、没有幻觉。

这类 eval 通常需要 LLM judge 与人工专家结合。确定性检查可以验证引用是否存在、链接是否可访问、结构是否完整；LLM judge 可评估覆盖率和连贯性；专家抽样用于校准事实性与专业判断。

6.4 Computer Use Agent：检查真实或沙盒环境

Computer Use Agent 会操作浏览器、桌面软件或远程系统。它的输出不是一段文字，而是一系列 GUI 行为和最终环境状态。

评估重点包括：

• 最终页面 URL、DOM、截图或应用状态；
• 文件是否被创建、移动、修改；
• 配置、数据库、后端状态是否正确；
• 是否选择了合适工具，例如 DOM 文本提取还是截图理解；
• 点击、输入、滚动轨迹是否合理；
• 是否在预算内完成。

原文提到浏览器 Agent 在 DOM 与截图之间存在 token、延迟和可靠性权衡：总结 Wikipedia 页面时提取 DOM 文本更高效，而在电商网站找特定商品时，截图可能更接近人类视觉判断。eval 不仅要看任务是否完成，还要帮助团队判断 Agent 是否学会了正确的工具选择策略。

七、Agent eval 的五个核心难题

7.1 非确定性：一次成功不代表稳定

Agent 每次运行都可能因为采样、工具返回、环境状态或中间决策不同而产生差异。因此，单次 trial 的 pass/fail 往往不足以代表真实性能。

Anthropic 文章中特别区分了两个指标：

• pass@k：运行 k 次，至少成功一次的概率；
• pass^k：运行 k 次，每次都成功的概率。

如果单次成功率是 (p)，直观上可以理解为：

[ pass@k = 1 - (1 - p)^k ]

[ pass^k = p^k ]

当 (p = 0.75) 时，pass@3 已经接近 98%，看起来 Agent 很有潜力；但 pass^3 只有约 42%，说明它还远没有达到“每次都可靠”的生产标准。

这两个指标服务于不同问题：

7.2 创造性解法：静态标准可能误伤强模型

越强的 Agent 越可能找到评估者没有预料到的路径。原文提到 Opus 4.5 在一个订机票任务中发现了政策漏洞，为用户提供了更好的解决方案，却因为偏离静态 eval 的预设路径而被判失败。

这类 case 的启示是：不要因为 Agent 没有走设计者想象中的路径就惩罚它；应优先评估它是否真正解决了用户问题，并且是否符合约束。

因此 grader 设计要尽量评估 outcome，而不是强制 path。只有在路径本身代表安全、合规或成本约束时，才应将路径纳入硬性判断。

7.3 Grader 脆弱：低分不一定说明 Agent 差

Agent 得分低可能来自三类问题：

1. Agent 真的失败了；
2. task 描述有歧义，成功标准没有写清；
3. grader 或 harness 有 bug，拒绝了合理答案。

因此团队必须阅读失败 case 的 transcript，而不是只看聚合分数。一个好的诊断流程通常是：

失败样本 → 读 transcript → 检查 outcome → 判断失败归因
        → Agent 问题：修 prompt / tool / harness / model
        → Task 问题：重写任务和成功标准
        → Grader 问题：修评分逻辑并回放历史样本

7.4 环境污染：共享状态会让分数失真

Agent eval 比普通模型 eval 更依赖环境。trial 之间如果没有隔离，就可能出现：

• 上一次运行留下的文件影响下一次测试；
• 缓存、数据库或浏览器 session 泄露状态；
• git history、临时目录或环境变量暴露答案；
• 并发任务争用资源导致随机失败；
• Agent 因为残留状态获得不公平优势。

因此 evaluation harness 必须保证：每个 trial 从干净环境开始，关键状态可重置，资源隔离明确，日志完整记录，失败可以复现。

7.5 Eval 饱和：满分不等于继续变强

当某个 eval suite 的通过率接近 100%，它就不再能衡量能力提升，只能说明 Agent 没有在这些已知任务上倒退。此时它应该转为 regression suite，而团队需要构建更难、更长、更接近真实生产的新 capability suite。

这也是为什么 eval 是“活资产”而不是一次性 benchmark。模型、工具、用户场景和产品目标都会变化，eval suite 也必须持续更新。

八、从 0 到 1 构建 Agent eval 的实践路线

Anthropic 的建议可以概括为一条工程化闭环：从真实失败开始，小规模自动化，持续读轨迹，再把稳定能力沉淀为回归集。

Step 0：尽早开始，不必等到“大而全”

不要等到有几百个任务才开始建设 eval。早期 20–50 个来自真实用户、bug tracker、support queue 或手工测试的失败案例，就足以提供很高价值。

Step 1：把手工测试转成自动化任务

每次发布前开发者都会手动验证的行为，通常就是最该自动化的 eval。例如：

• “搜索功能在需要时会调用工具，但常识问题不乱搜”；
• “代码 Agent 修改文件后会运行测试”；
• “客服 Agent 必须先验证身份再处理退款”；
• “研究 Agent 必须给关键结论附来源”。

Step 2：写清晰、无歧义的 task

好任务应满足一个标准：两个领域专家独立判断时，应得出相同的 pass/fail 结论。

一个 task 至少应包含：

id: refund_late_delivery_001
input: "用户表示包裹迟到，要求退款，请根据政策处理。"
initial_state:
  order_status: delivered_late
  refund_status: none
  identity_verified: false
success_criteria:
  - "必须先完成身份验证"
  - "必须查询退款政策"
  - "符合政策时将 refund_status 更新为 processed"
  - "最终向用户解释处理结果"
reference_solution:
  - "verify_identity"
  - "lookup_refund_policy"
  - "process_refund"
  - "send_confirmation"
grading:
  deterministic:
    - "state.refund_status == 'processed'"
    - "tool_calls includes verify_identity before process_refund"
  llm_rubric:
    - "是否表达共情"
    - "解释是否清楚且不夸大"

参考解不是为了限制 Agent 只能走一条路径，而是为了验证任务可解、grader 合理、环境配置正确。

Step 3：构建平衡样本，避免单向优化

如果只测试“应该搜索”的问题，Agent 可能学成“什么都搜索”；如果只测试“应该拒绝”的危险请求，它可能变得过度保守。eval suite 应同时覆盖正反样本：

平衡样本能防止团队把 Agent 优化成单一策略。

Step 4：构建稳定、隔离的 evaluation harness

一个合格的 harness 至少应具备：

• 每个 trial 独立初始化环境；
• 支持并发运行但避免共享状态污染；
• 记录完整 transcript、工具输入输出、环境快照；
• 聚合 pass rate、成本、延迟、token、工具调用等指标；
• 支持回放失败样本；
• 尽量模拟生产 Agent，但保留可控性和可复现性。

对 Agent 来说，harness 的质量直接影响 eval 可信度。一个有缺陷的 harness 可能让强模型被低估，也可能让脆弱 Agent 看起来表现很好。

Step 5：谨慎设计 grader

评分器设计建议遵循以下顺序：

1. 能用确定性检查的部分优先用代码；
2. 开放式质量再用 LLM judge；
3. 高风险和争议样本交给人工；
4. 尽量评估结果，而不是强制路径；
5. 对多组件任务提供部分分；
6. LLM judge 必须使用结构化 rubric；
7. 定期用人类专家校准 LLM judge；
8. 防止 Agent hack eval，例如硬编码测试、读取隐藏答案、绕过工具权限。

Step 6：读 transcript，不要只看分数

Anthropic 原文中特别强调：Read the transcripts!

聚合指标告诉你“哪里失败多”，transcript 告诉你“为什么失败”。阅读失败轨迹时可以问：

• Agent 是否理解错任务？
• 工具返回是否误导了 Agent？
• task 是否缺少关键约束？
• grader 是否拒绝了合理答案？
• harness 是否限制了模型能力？
• 是否出现新的失败模式，可以沉淀为新 eval？

如果没有 transcript，团队只能对分数做猜测；有了 transcript，eval 才能真正驱动工程迭代。

Step 7：监控饱和并维护 suite

当某个能力集长期高分，应将其转入 regression suite，并构建更难任务。长期维护需要产品、工程、研究、客服、销售、领域专家共同参与：

• 产品定义什么叫用户价值；
• 工程保证 harness 稳定和自动化；
• 研究或算法团队分析模型能力边界；
• 一线团队贡献真实失败案例；
• 专家负责高价值样本和 rubric 校准。

这就是 eval-driven development：先把“怎样算成功”写成可运行任务，再推动 Agent 达成。

九、落地参考：一个生产级 Agent eval 面板应该看什么

除了 pass/fail，生产级 Agent eval 应同时关注质量、稳定性、成本和风险。一个实用面板可以分成四层：

对不同 Agent，面板的重点不同：

• 代码 Agent：测试通过率、静态检查、diff 大小、验证命令运行率；
• 客服 Agent：业务状态完成率、身份验证顺序、对话轮数、人工接管率；
• 研究 Agent：引用覆盖率、来源质量、事实错误率、专家抽样一致性；
• 浏览器 Agent：最终 UI 状态、点击路径长度、截图/DOM 工具选择、超时率。

真正有用的 eval 面板不只是展示分数，而是能帮助团队回答三个问题：

1. 这次改动是否真实提升？
2. 有没有破坏已有能力？
3. 下一批最值得修的失败模式是什么？

十、最佳实践清单

最后给一份可以直接用于团队评审的 checklist：

任务设计

• 任务来自真实用户、真实失败或明确产品目标；
• 任务描述足够清晰，专家能独立判断成败；
• 成功标准能从任务描述中推出；
• 每个任务有参考解或参考状态；
• suite 中包含正样本和反样本；
• 能力评估和回归评估分开管理。

Harness 与环境

• 每个 trial 使用干净环境；
• 工具、权限、网络、文件系统与生产足够接近；
• transcript、outcome、工具输入输出完整记录；
• 失败样本可以回放；
• 并发运行不会污染共享状态；
• 成本、延迟、token 和资源消耗可观测。

Grader 与指标

• 确定性检查覆盖所有可客观判断的条件；
• LLM judge 使用结构化 rubric；
• LLM judge 允许 Unknown，并要求引用证据；
• 人工评审用于高风险样本、仲裁和校准；
• 同时观察 pass@k 与 pass^k；
• 定期抽查低分和高分样本，防止 grader 漂移。

迭代机制

• 每次重要改动前后运行核心 suite；
• 新 bug 修复后沉淀为回归任务；
• 饱和 suite 转为回归集，并构建更难能力集；
• 定期阅读 transcript，而不是只看 dashboard；
• 产品、工程、研究和领域专家共同维护 eval。

十一、总结：好的 eval 是 Agent 的质量控制面

Agent eval 的难点在于，它评估的不是一个静态文本输出，而是一个会调用工具、改变环境、产生多步轨迹的动态系统。要做好这件事，需要把评估对象从 response 扩展到 transcript 和 outcome，把评分器从单一规则扩展到确定性检查、LLM judge 与人工校准的组合，并把 eval suite 当成长期维护的工程资产。

如果用一句话概括 Anthropic 文章带来的启示：

好的 Agent eval 不是为了给模型打一个漂亮分数，而是为了让团队持续知道：Agent 现在能做什么、哪里不稳定、是否发生回归，以及下一步应该如何改进。

当团队真正把 eval 接入日常开发、发布和生产监控，Agent 的迭代方式就会从“凭感觉调 prompt”转向“基于证据改系统”。这也是 AI Agent 从 demo 走向可靠产品必须跨过的一道工程门槛。

× 爱折腾的工程师

真诚赞赏，手留余香

2元 5元 10元 50元 100元 任意金额

2元

使用微信扫描二维码完成支付

• ← Previous Post
• Next Post →