参考文献：https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents

AI Agent 凭借自主性、多轮交互、工具调用与环境状态修改能力，成为大模型落地的核心形态，但这些优势也让其评估远复杂于传统单轮 LLM。Anthropic 在《Demystifying evals for AI agents》中，结合内部工程与客户实践，给出一套可规模化、可复现的评估体系，帮助团队从被动救火转向主动可控的迭代模式。

一、为什么 Agent 评估非做不可

Agent 的核心能力恰恰是评估的难点：多轮工具调用会让错误逐级放大，自主决策可能跳出预设规则给出 “超预期正确解”，静态用例难以覆盖真实场景的灵活路径。

没有系统化评估，团队极易陷入生产端被动循环：用户投诉后复现、修复、再引发新问题，无法区分真实退化与噪声，模型升级也只能靠人工盲测，耗时数周。

而完善的 Evals（评估体系）能带来四重价值：

1. 前置发现问题：上线前暴露行为缺陷，避免影响用户
2. 量化迭代方向：把 “感觉变差” 转化为可度量指标
3. 加速模型接入：新模型发布后，几天内完成基准测试与适配
4. 统一协作语言：成为产品与研发间最高效的沟通载体，明确优化目标

二、Agent 评估核心概念与结构

Evals 是面向 AI 系统的标准化测试：给定输入、执行任务、用评分逻辑判定结果。面向 Agent 的评估需明确以下核心组件：

表格

组件	定义	作用
任务（Task）	带明确输入与成功标准的测试用例	评估的最小执行单元
试验（Trial）	单次任务执行	多次试验消除非确定性影响
评分器（Grader）	判定性能的逻辑规则	分代码 / 模型 / 人工三类
交互记录（Transcript）	完整执行轨迹：输出、工具调用、推理	定位失败根因
最终状态（Outcome）	环境真实结果，而非口头提示	衡量真实达成效果
评估框架（Harness）	端到端运行、调度、记录的基础设施	保障评估稳定可复现

---

三、三类评分器：组合使用才高效

Agent 评估不依赖单一评分器，而是代码 + 模型 + 人工分层搭配，兼顾速度、成本与准确性。

1. 代码型评分器（确定性）

• 方法：字符串 / 正则匹配、单元测试、静态分析、工具调用校验、状态检查
• 优势：极速、低成本、客观可复现、易调试
• 局限：对合理变体脆弱，缺乏主观评判能力
• 适用：结果明确的任务（代码可运行、订单生成、权限阻断）

2. 模型型评分器（LLM-as-Judge）

• 方法： rubric 评分、自然语言断言、成对比较、多法官共识
• 优势：灵活、可处理开放任务、捕捉细微差别
• 局限：非确定性、成本更高、需人工校准
• 适用：对话质量、信息完整性、代码风格等主观场景

3. 人工评分器（黄金标准）

• 方法：专家评审、众测、抽样检查、A/B 测试
• 优势：匹配真实用户判断，校准模型评分器
• 局限：昂贵、缓慢、难以规模化
• 适用：关键场景校准、高风险任务终审

---

四、两大评估类型：能力与回归双轮驱动

1. 能力评估（Capability Evals）

• 定位：测 “上限”，聚焦 Agent 尚未掌握的复杂任务
• 特点：初始通过率低，是团队持续攻克的目标
• 示例：复杂代码工程、跨工具多步推理、长文本深度合成

2. 回归评估（Regression Evals）

• 定位：保 “底线”，验证已有能力不退化
• 特点：通过率接近 100%，任何下降都需立即修复
• 机制：高通过率的能力用例可 “毕业” 转为回归用例

---

五、四类主流 Agent 的评估实战

1. 编码 Agent

• 核心：代码可运行、测试通过、符合规范
• 评分：单元测试 + 静态检查 + 代码质量 rubric
• 基准：SWE-bench Verified、Terminal-Bench
• 要点：既看最终结果，也看工具调用效率与交互轨迹

2. 对话 Agent（客服 / 销售）

• 核心：任务完成 + 交互质量 + 状态合规
• 评分：状态校验（工单完结 / 退款成功）+LLM rubric（共情、清晰度）+ 工具调用合规
• 基准：τ-Bench、τ2-Bench
• 要点：用 LLM 模拟用户，做多轮对抗性测试

3. 研究 Agent

• 核心：信息准确、来源可靠、覆盖全面、逻辑自洽
• 评分：事实核查、来源权威性校验、覆盖度检查、连贯性评分
• 挑战：事实随数据源变化，开放输出易出错
• 要点：高频校准 LLM 评分器，避免幻觉

4. 计算机使用 Agent（GUI / 浏览器）

• 核心：真实环境中达成目标，不依赖 API
• 评分：界面状态校验、后端数据验证、操作链路合规
• 基准：WebArena、OSWorld
• 要点：平衡 Token 效率与延迟，选择 DOM 或截图适配场景

---

六、非确定性解决方案：pass@k 与 pass^k

Agent 输出具有随机性，单次结果不可靠，需用多试验指标量化稳定性：

• pass@k：k 次尝试中至少 1 次成功的概率，适合追求 “能做成” 的工具场景
• pass^k：k 次全部成功的概率，适合要求 “次次稳定” 的 C 端服务场景
• 规律：k 增大，pass@k 趋近 100%，pass^k 趋近 0%，按产品需求选择

---

七、从零到一：8 步落地生产级 Evals

1. 尽早启动，小步快跑

初期 20–50 个真实故障转化的用例足够，避免等待 “完美大套件”，越早构建成本越低。

2. 用真实场景做用例

来源：手动测试点、Bug 单、用户反馈；优先按用户影响排序，确保贴近线上行为。

3. 无歧义任务 + 参考解

• 两位专家可给出一致通过 / 失败结论
• 提供可运行参考解，验证任务可解、评分器正常
• 避免路径隐含假设（如文件路径、字段格式）导致误判

4. 构建平衡用例集

同时测 “该做” 和 “不该做”：如搜索 Agent 既要测该搜时触发，也要测不该搜时不触发，防止单边优化。

5. 稳定隔离的评估环境

每次试验从干净环境启动，消除共享状态干扰；确保评估环境与生产一致，结果可信。

6. 评分器设计：重结果、轻路径

优先评 “做成什么”，而非 “怎么做”，包容 Agent 的创新路径；复杂任务设部分分，避免一刀切；LLM 评分器需人工校准，预留 “无法判断” 选项防幻觉。

7. 必做：通读交互记录

只看分数会被误导，轨迹能区分 “Agent 真错” 还是 “评分器误判”，是优化评估与 Agent 的核心环节。

8. 长期维护，持续迭代

• 避免评估饱和：100% 通过率无改进信号，需持续加入高难度用例
• 专职团队维护基础设施，业务团队贡献用例
• 践行评估驱动开发：先定义评估，再开发能力，同步验证模型演进价值

---

八、评估与其他手段的协同

自动化 Evals 不是全部，需与生产监控、A/B 测试、用户反馈、人工评审形成多层防御，如同安全工程的瑞士奶酪模型，互补覆盖缺陷。

表格

方式	价值	局限
自动化 Evals	预发拦截、快速迭代、可复现	搭建与维护成本高
生产监控	真实用户行为、发现未知问题	被动、信号噪声大
A/B 测试	量化真实业务影响	周期长、需流量
人工评审	校准标准、捕捉主观细节	慢、难规模化

---

九、总结

Agent 评估的本质是把模糊的 “好用” 变成可定义、可测试、可度量的标准。Anthropic 的实践证明：评估不是额外开销，而是加速迭代、保障质量、降低线上风险的核心基建。

落地关键：尽早开始、用真实场景、组合评分器、重结果轻路径、持续读轨迹、长期维护。随着 Agent 走向多任务、多智能体协作，评估体系也需同步进化，成为 AI 产品从 Demo 走向规模化落地的基石。