Agent 评估评测实战指南

评估 Agent 不是给模型打分，而是诊断一个系统的运行状况。

与传统软件测试不同，Agent 的行为具有非确定性——同一个输入可能产生不同的推理路径、工具调用序列和最终输出。这使得评估从"断言结果是否符合预期"升级为"定位系统在哪个环节失败了"。

本文综合多家来源的实践经验，系统梳理 Agent 评估的核心方法论。

---

一、核心认知：错误分析优先于指标

Hamel Husain（独立 AI 顾问，前 GitHub/Airbnb）的观点非常明确：错误分析（Error Analysis）是最重要的评估活动，建议将 60-80% 的评估开发时间花在错误分析上。

为什么不是先写指标？

常见的误区是一上来就设计复杂的评分体系。但指标本身不能告诉你问题出在哪里——只有逐条阅读失败案例才能做到。

错误分析的方法借鉴了定性研究：

1. Open Coding（开放编码）：逐条阅读失败样本，为每条打上自由标签（"幻觉"、"格式错误"、"遗漏步骤"等）
2. Axial Coding（轴向编码）：将标签归类为更高层的失败模式（"检索失败"、"推理断裂"、"输出格式"）
3. Iterative Refinement（迭代精炼）：用新样本验证分类是否完备，不断调整

评估指标的黄金法则

基于多来源的共识：

• Binary（通过/失败）优于 Likert 量表：二元判断比 1-5 分评分更可靠、更容易对齐
• 不使用通用指标：每个评估都应该是任务特定的（task-specific），通用指标（如 BLEU、ROUGE）对 Agent 场景几乎没有价值
• 数量胜过质量：100 个覆盖真实失败模式的粗糙测试用例比 10 个精心设计的更有统计价值
• 评估应该自动化：手动评估无法规模化，必须设计自动化评分流程

---

二、评估的两个维度：Guardrails 与 Evaluators

向量数据库公司 Weaviate 的框架将 Agent 的质量控制分为两个正交维度：

Guardrails（护栏）

Guardrails 是内联的、同步的安全检查，嵌入在 Agent 的执行流程中：

用户输入
    → [Pre-model Guardrail] 输入验证
    → 模型调用
    → [Post-model Guardrail] 输出验证
    → 返回结果

Pre-model Guardrails（调用模型前）：

• 输入过滤：检测注入攻击、敏感信息
• 主题分类：判断请求是否在 Agent 能力范围内
• 速率限制：防止滥用

Post-model Guardrails（模型返回后）：

• 输出格式校验：JSON 结构是否正确
• 内容安全检查：是否包含有害内容
• 幻觉检测：关键事实是否有依据

Evaluators（评估器）

Evaluators 是异步的、事后的质量评估，不影响执行流程：

特征	Guardrails	Evaluators
时机	同步，执行中	异步，执行后
作用	阻断或修正行为	度量和诊断质量
影响	直接影响用户体验	间接指导系统改进
示例	输入过滤、输出校验	端到端质量评分、回归测试通过率

关键洞察：Guardrails 防止灾难性失败，Evaluators 驱动持续改进。两者缺一不可。

---

三、Agent 评估的五种模式

LangChain 总结了评估 Agent 的五种模式，从简单到复杂递进：

模式 1：定制化测试逻辑（Bespoke Test Logic）

为每个测试数据点编写特定的断言逻辑：

# 每个数据点有自己的判断标准
test_cases = [
    {
        "input": "北京的天气如何？",
        "assert": lambda output: "北京" in output and any(
            w in output for w in ["晴", "阴", "雨", "雪"]
        )
    },
    {
        "input": "计算 15 * 23",
        "assert": lambda output: "345" in output
    }
]

适用场景：快速起步，数据点较少（< 50）时最有效。

模式 2：单步评估（Single-step Evaluation）

不评估整个 Agent 运行，而是评估单个中间步骤的质量：

• 某一步的工具选择是否正确？
• 检索到的上下文是否相关？
• 中间推理是否合理？

价值：将复杂的 Agent 行为分解为可独立评估的原子操作。

模式 3：完整回合评估（Full Turn Evaluation）

评估 Agent 一次完整运行的最终输出：

输入 → [Agent 完整执行] → 最终输出 → 评估

评估维度：

• 最终回答质量：是否正确解决了用户问题
• 轨迹正确性（Trajectory）：Agent 走的路径是否合理
• 效率：是否用了最少必要的步骤

模式 4：多轮对话模拟（Multi-turn Simulation）

用模拟用户测试多轮交互场景：

# LangChain 的模拟评估示例
simulator = MultiturnSimulator(
    user_simulator=llm_user,   # 模拟用户的 LLM
    agent=your_agent,           # 被测 Agent
    max_turns=10
)
result = simulator.run(scenario="用户尝试退货但缺少订单号")

适用场景：对话式 Agent、客服机器人等需要多轮交互的系统。

模式 5：环境设置评估（Environment Setup）

为 Agent 提供可控的执行环境来测试工具使用：

• 提供模拟的 API、数据库、文件系统
• 验证 Agent 是否正确调用了工具、处理了异常
• 测试 Agent 在特定环境状态下的行为

适用场景：Coding Agent（如 SWE-bench，见第七节）、数据分析 Agent。

五种模式的选择策略

数据量少 + 快速起步 → 模式 1（定制化逻辑）
需要诊断中间步骤   → 模式 2（单步评估）
关注端到端质量     → 模式 3（完整回合）
多轮交互场景       → 模式 4（多轮模拟）
工具使用是核心     → 模式 5（环境设置）

实际项目中，通常是多种模式组合使用。

---

四、LLM-as-Judge 实践指南

当人工评估不可扩展时，用 LLM 来评估 LLM 的输出是最实用的折中方案。

设计原则

综合 Anthropic 官方文档和 Hamel 的建议：

1. 使用详细的评分标准（Rubric）

# 差的评分标准
"评估回答是否有帮助"  ← 太模糊

# 好的评分标准
"回答是否包含以下要素：
  1. 直接回答了用户的问题（1分）
  2. 提供了具体的数据或证据（1分）
  3. 承认了不确定性（如果存在）（1分）
  4. 没有包含无关信息（1分）"

2. 要求结构化输出

让 LLM 输出结构化的评估结果，而不是自然语言评论：

{
  "score": 0,
  "reasoning": "回答包含了正确的最终答案，但中间步骤有计算错误...",
  "criteria_passed": ["correct_answer", "clear_explanation"],
  "criteria_failed": ["accurate_reasoning"]
}

3. 鼓励推理过程

Anthropic 的建议：在评分前让模型先推理，再给分。这显著提高评估质量：

"先逐步分析回答的每个部分，指出优点和问题，
最后基于分析给出 0 或 1 的评分。"

LLM-as-Judge 的验证

使用 LLM-as-Judge 时，必须验证其与人类判断的对齐度：

1. 建立黄金数据集：人工标注 50-100 个样本
2. 计算对齐度：LLM 评分与人工评分的一致率
3. 分析分歧样本：找出 LLM 判断错误的模式
4. 迭代优化评分标准：针对分歧样本调整 rubric

经验法则：如果 LLM-as-Judge 与人工的对齐度低于 80%，说明评分标准需要重新设计。

OpenAI 的 Grader 类型体系

OpenAI 提供了五种内置的评分器（Grader）类型：

类型	机制	适用场景
String Check	字符串匹配（精确/包含/正则）	格式验证、关键词检查
Text Similarity	文本相似度（余弦、编辑距离）	语义近似匹配
Score Model	LLM 给出连续分数（如 1-5）	需要细粒度区分质量等级的场景
Label Model	LLM 输出分类标签	多维度分类评估
Python Code	执行自定义 Python 逻辑	复杂业务逻辑验证

---

五、诊断利器：Transition Failure Matrix

Hamel 提出的 Transition Failure Matrix 是诊断 Agent 工作流的有效工具。

核心思想

将 Agent 的工作流建模为一系列状态转换（transitions），然后分析每个转换的失败率：

状态 A → 状态 B → 状态 C → 状态 D
  90% ✅    85% ✅    60% ⚠️

构建方法

1. 定义工作流的关键状态（如：意图识别 → 工具选择 → 工具执行 → 结果整合 → 回复生成）
2. 标注每个样本在每个状态的成败
3. 统计每个转换的成功率

分析价值

Transition Failure Matrix 的价值不在于给出一个总分，而在于精确定位瓶颈：

转换	成功率	典型失败原因
意图 → 工具选择	92%	多意图混淆
工具选择 → 工具执行	88%	参数格式错误
工具执行 → 结果整合	65%	上下文过长导致遗漏
结果整合 → 回复生成	78%	格式不符合要求

上表清楚地指出：工具执行 → 结果整合 是瓶颈，优化应该从这里开始。

与错误分析的配合

Transition Failure Matrix 和 Open Coding 是互补的：

• Open Coding 告诉你"有什么类型的失败"
• Transition Matrix 告诉你"失败集中在哪个阶段"
• 两者结合才能形成完整的诊断视图

---

六、从评估到商业价值

评估不只是技术活动，它需要与商业目标建立映射关系。

Business Model Mapping

OpenAI Cookbook 的方法论：将评估指标映射到具体的商业影响。

评估指标                    业务影响（示意）
─────────                  ─────────
回答准确率 95%        →   客户满意度提升
幻觉率 < 2%           →   人工介入成本下降
工具调用成功率 90%    →   任务完成时间缩短

不是所有评估都同等重要

一个实用的优先级排序：

1. P0：影响用户体验的评估 — 回答正确性、幻觉检测
2. P1：影响运营成本的评估 — 工具调用效率、Token 使用量
3. P2：影响长期质量的评估 — 对话连贯性、风格一致性

开发飞轮（Development Flywheel）

    ┌──────────────────────────────────┐
    │                                  │
    ↓                                  │
改进系统 ──→ 运行评估 ──→ 错误分析 ──→ 识别瓶颈
    ↑                                  │
    │                                  │
    └──────────────────────────────────┘

注意：每次改进系统后，评估数据集本身也需要更新——旧数据集可能不再覆盖新的失败模式。

模型改进瀑布（Model Improvement Waterfall）

当评估发现问题时，按以下优先级尝试改进：

1. 模型选择     — 换一个更强的模型能解决吗？（成本最低）
2. Prompt 调优  — 更清晰的指令能解决吗？
3. 示例补充     — Few-shot examples 能覆盖这个 case 吗？
4. 工具改进     — 工具描述更清晰、参数更友好能解决吗？
5. 辅助模型     — 引入路由器或分类器拆分任务？
6. 微调         — 最后才考虑（成本最高、数据需求最大）

重要原则：不要跳级。在尝试低成本的方案之前，不要直接跳到微调。

---

七、行业基准与趋势

主流 Agent 基准

基准	领域	评估方式	代表性得分（截至 2025 年中）
SWE-bench Verified	软件工程	自动化测试	Claude Code ~70%
WebArena	Web 交互	任务完成率	~40-50%
OSWorld	操作系统操作	任务完成率	~20-30%
GAIA	通用推理	准确率	~70%

趋势：基准正在从"单一任务"向"真实环境中的端到端任务"演进。SWE-bench 被主流 Agent 产品广泛采用作为核心评估标准，证明了"用真实世界的测试套件评估 Agent"是可行且有效的路径。

评估方法的演进方向

1. 从静态到动态：从固定测试集到自适应测试生成
2. 从结果到过程：不只看最终答案，还看推理轨迹的质量
3. 从单轮到多轮：评估 Agent 在持续交互中的表现稳定性
4. 从通用到领域特定：每个领域需要自己的评估框架

---

八、实践建议：如何开始

第一步：建立错误分析习惯

回到第一节的方法论：先手动分析 50 个失败案例，用 Open Coding 归类失败模式，再决定评估什么。

第二步：选择合适的评估模式

基于你的 Agent 类型选择：

Agent 类型	推荐评估模式	起步评估指标
问答/聊天	完整回合评估	回答准确性（binary）
工具调用型	单步 + 环境设置	工具选择正确率
多轮对话	多轮模拟	任务完成率
Coding Agent	环境设置 + 测试套件	测试通过率

第三步：实现自动化评分

从最简单的开始：

1. 先用 String Check 和 Python Code 类型的评分器处理可程序化验证的部分
2. 再用 LLM-as-Judge 处理需要语义理解的部分
3. 最后用人工抽检验证自动化评分的准确性

第四步：建立开发飞轮

将评估集成到开发流程中：

• 每次系统变更后自动运行评估套件
• 评估结果作为 PR review 的输入
• 定期更新评估数据集（至少每月一次）

第五步：映射到商业价值

为每个评估指标建立与业务 KPI 的关联，让评估的投资回报可见。

---

参考资源

• LangChain Blog - Evaluating Deep Agents: https://blog.langchain.com/evaluating-deep-agents-our-learnings/
• Hamel Husain - Evals FAQ: https://hamel.dev/blog/posts/evals-faq/
• Anthropic - Develop Tests: https://platform.claude.com/docs/zh-CN/test-and-evaluate/develop-tests
• OpenAI - Evaluation Getting Started: https://platform.openai.com/docs/guides/evaluation-getting-started
• OpenAI Cookbook - Eval-driven System Design: https://cookbook.openai.com/examples/partners/eval_driven_system_design/receipt_inspection
• Weaviate - Evals & Guardrails for Enterprise Workflows: https://weaviate.io/blog/evals-guardrails-enterprise-workflows-1