AI Agent 评测指南（下）：从指标设计到准出标准

四、开源评测框架与方法论

不要从零造轮子。业界已有成熟的评测框架和 Benchmark，根据你的 Agent 场景选型即可。

4.1 Agent 通用评测框架

框架	定位	适合场景	核心能力
LangSmith	LLM 应用全生命周期平台	强	Trace 追踪、数据集管理、在线评测、人工标注、A/B 对比
Braintrust	AI 产品评测平台	强	数据集管理、自定义 Judge、实验对比、集成 CI/CD
DeepEval	开源 LLM 评测框架	中	丰富的内置指标（Faithfulness/Relevancy/Toxicity等）、批量评测、CI 集成
Promptfoo	Prompt 测试与红队	中	Prompt 对比测评、安全红队测试、多模型对比、断言式验证
Ragas	RAG 系统评测	Agent RAG 环节	RAG 专属指标（Context Precision/Recall、Faithfulness）、合成测试数据生成
Arize Phoenix	LLM 可观测性+评测	强	Trace 可视化、检索增强评测、线上监控告警

4.2 Agent 专属 Benchmark

SWE-bench（软件工程 Agent 评测）：

• 任务：从 GitHub issue 出发，Agent 自动修 bug / 加功能
• 评测方式：运行测试用例，看 Agent 生成的 patch 是否通过
• 指标：resolve rate（问题解决率）
• 难度：高（需要理解代码库 + 生成正确补丁）
• 代表模型得分：Devin 13.86%, SWE-Agent 12.47%

ToolBench（工具使用能力评测）：

• 任务：涵盖 16K+ 真实 API 的工具调用场景
• 评测方式：检查工具选择 + 参数正确性
• 指标：工具选择准确率、参数准确率、端到端成功率
• 亮点：覆盖单工具、多工具、工具链组合等难度分层

AgentBench（通用 Agent 评测）：

• 任务：8 个交互环境（操作系统、数据库、知识图谱、Web等）
• 评测方式：Agent 在模拟环境中自主操作并完成任务
• 指标：任务完成率
• 特点：端到端、多环境、强调自主性

WebArena（Web Agent 评测）：

• 任务：在真实 Web 环境中完成操作（购物、协作、内容管理）
• 评测方式：Agent 操作浏览器，评测结果是否符合预期
• 指标：任务成功率
• 适用：有 Web 操作需求的 Agent

τ-bench（工具使用 + 推理）：

• 任务：需要推理 + 工具调用的组合任务
• 评测方式：检查 Agent 是否通过正确的推理链完成任务
• 指标：推理链正确率、工具调用准确率

GAIA（通用 AI 助手评测）：

• 任务：需要推理、多模态、工具使用的复杂问题
• 评测方式：答案精确匹配（避免 LLM-Judge 的主观性）
• 特点：Agent 必须"答对"而非"答得好"

4.3 主流评测方法论

方法论 1：LLM-as-Judge（LMSYS 范式）

• 来源：LMSYS 团队（Chatbot Arena 背后团队）
• 核心思想：用 GPT-4 等强模型作为裁判，评估其他模型的输出
• 关键实践：
• 位置偏差修正（交换 AB 位置各评一次）
• 多 Judge 一致性（至少 2 个 Judge 交叉验证）
• Judge 和人工评测的校准（定期抽检，确保 Judge 质量不退化）
• 资源：MT-Bench、Chatbot Arena 数据集公开可用

方法论 2：Arena 式众包评测

• 来源：Chatbot Arena
• 核心思想：让真实用户在盲测中选择"哪个回答更好"，用 Elo 评分排名
• 优点：真实用户偏好、大规模、持续更新
• 局限：只反映"偏好"不反映"能力"、受用户画像影响
• 适用：需要"用户喜欢哪个"而非"哪个能力更强"的场景

方法论 3：G-Eval（Chain-of-Thought 评测）

• 来源：G-Eval: NLG Evaluation using GPT-4 with Better Human Alignment
• 核心思想：让 LLM Judge 先写出评测步骤（CoT），再打分
• 优点：和人工评测的相关性显著提升（超过直接打分 10-15%）
• 示例：
• Judge 先分析 → "这个回答需要检查：1. 事实准确性 2. 完整性 3. 格式"
• 然后再给出 1-5 分，每分有明确锚点
• 适用：需要高分辨力的评测场景

方法论 4：Eval-as-Service

• 来源：各大 AI 平台（OpenAI Evals、Anthropic Eval Tool）
• 核心思想：将评测作为 CI/CD 流程的一部分
• 实践方式：
• 每个 PR 自动跑评测
• 评测结果作为 merge 的 blocking check
• 长期追踪指标趋势
• 工具：LangSmith CI、DeepEval CI、Promptfoo CI

方法论 5：分层阶梯式评测（Google/DeepMind 实践）

• 来源：Gemini、PaLM 团队的评测实践
• 核心思想：评测按难度分层 ——
• Level 1: 基础能力（单轮问答、翻译、摘要）→ 自动化指标
• Level 2: 推理能力（多步推理、代码生成）→ LLM-Judge
• Level 3: Agent 能力（工具使用、规划、自主执行）→ 端到端任务
• Level 4: 安全与对齐（红队测试、偏见检测）→ 专项评测
• 优点：评测成本和风险匹配，最低层可全自动化

4.4 评测工具链搭建示例

推荐的 Agent 评测工具链（最小可用方案）：

• 数据管理：JSON/YAML 文件 → LangSmith 数据集（或自建 Git 仓库）
• 自动化评测：DeepEval（指标库）+ Promptfoo（对比测试）
• LLM-Judge：GPT-4o / Claude Opus（作为裁判模型）
• 人工评测：LangSmith 标注平台（或 Google Sheets + 脚本）
• CI 集成：GitHub Actions 触发评测
• 结果看板：LangSmith Dashboard / Grafana + 自建数据库

一周内可搭建的 MVP：

• Day 1-2：搭建评测数据集（50 个核心 Agent 任务，标注预期结果）
• Day 3：接入 DeepEval + 自定义 Agent 指标
• Day 4：配置 LLM-as-Judge Pipeline（含 G-Eval CoT 打分）
• Day 5：接入 CI（每次 Prompt 变更自动跑评测）
• 后续：逐步补充测试集（目标 500+ 任务），加入人工评测

五、分级准出标准

5.1 按变更风险分级

L1 变更（低风险）：

• 范围：SKILL 内容修改、Prompt 措辞调整、单个工具配置变更
• 必须过：
• 单工具任务集回归（200条+）：成功率不下降
• LLM-as-Judge 结果评判（100条多工具任务）：得分不下降
• 准出：两项均不劣化

L2 变更（中风险）：

• 范围：模型版本升级、新增/移除工具、Agent 系统 Prompt 变更
• 必须过：
• L1 全部评测
• 多工具链任务集（100条+）：成功率 ≥ 基线
• 工具选择准确率 ≥ 85%
• 死循环率 = 0%（零容忍）
• 安全评测：危险操作率 = 0%，幻觉率 ≤ 3%
• 准出：核心指标无劣化 + 安全全通过

L3 变更（高风险）：

• 范围：Agent 框架升级、模型全量切换、SubAgent 策略变更
• 必须过：
• L2 全部评测
• 对抗/边界任务集（50条+）：错误恢复率 ≥ 60%
• 3人以上人工评测（50条多工具链任务，Cohen's Kappa ≥ 0.6）
• 灰度上线（5%→20%→50%→100%），每个阶段观察≥1天
• 线上费用对比：不劣化超30%
• 准出：全部通过 + 至少1个核心维度显著提升

5.2 准出决策流程

1. 确定变更风险等级（L1/L2/L3）
2. 运行对应级别的评测套件
3. 检查所有必须通过项是否达标
4. 如有未通过项 → 修复后重跑
5. 全部通过 → 按风险等级决定是否灰度
6. 灰度期间持续监控线上指标
7. 灰度通过 → 全量发布

六、Agent 评测的持续运营

评测不是一次性工作，而是持续运营：

1. 评测集定期更新（每月）

• 从线上真实 Agent 执行日志中抽样新的任务
• 补充新发现的 badcase
• 淘汰"已过时"的任务（Agent 已经 100% 通过的）

2. 建立"评测墙"（Evaluation Wall）

• 每个 PR / 每次 Prompt 变更 → 自动触发 L1 评测
• 每次模型升级 → 自动触发 L1+L2 评测
• 每个版本发布前 → 触发全量 L3 评测
• 结果可视化（趋势图、劣化告警）

3. 异常监控

• 任务成功率突然下降 > 10% → 告警
• 死循环率 > 0 → 告警
• 工具选择准确率下降 > 5% → 告警
• 幻觉率上升 > 50% → 告警

4. 月度评测报告

• 各项指标趋势
• 新增 top badcase 分析
• 和上月的对比

七、总结

Agent 评测的核心原则：

1. 任务完成度是北极星指标

• 不管 Agent 多聪明、工具用得多好，最终只看"事有没有办成"。

2. 评测集必须覆盖端到端任务链

• 不能只用"回答得好不好"来评测 Agent。
• 需要完整的工具调用链、SubAgent 协作、错误恢复场景。

3. 死循环和幻觉是 Agent 的红线

• 这两项指标不能有任何妥协。
• 死循环率必须为 0%，幻觉率必须持续压低。

4. 按风险投入评测资源

• Prompt 微调不用跑全套，模型升级必须跑全套。
• 评测成本要小于变更风险带来的损失。

5. LLM-as-Judge 是 Agent 评测的最佳方式

• 路径多样性让规则匹配失效，只有 LLM Judge 能理解"不同路径都可能是对的"。