引言：一个真实的困境

你的团队刚完成一个客服 Agent 的开发。在本地评测中，Agent 在标准测试集上达到了 94% 的任务完成率，超越了发布阈值。

上线第一周，客诉率比预期高出三倍。用户反馈的问题集中在：Agent 在复杂对话中"失忆"、在边界情况下输出有害内容、以及对同一问题给出不一致的答案。

Benchmark 高分 ≠ 生产可靠。 这是 2026 年 AI Agent 开发者最需要理解的一句话。

传统 LLM 评测有清晰的输入-输出对，评测的是模型的知识储备和推理能力。但 Agent 的评测要复杂得多：它涉及多轮交互、工具调用、状态管理、环境反馈，是一个动态的、序列决策的过程。评测一个 Agent，本质上是在评测一个运行在不确定环境中的系统，而非一张静态的试卷。

本文系统梳理 2026 年 Agent 评测的完整层次，并给出构建可落地评测流水线的实践建议。

第一层：任务层基准 — 你的 Agent 能做对的事

任务层基准（Task-level Benchmark）是评测 Agent 基础能力的第一道门槛。这些基准定义了一系列结构化的任务，Agent 在其中需要完成特定目标，最终由自动化脚本或人工判断给出 pass/fail 结果。

GAIA：通用助手能力评测

GAIA（General AI Assistants）是目前最被广泛引用的 Agent 基础评测集。它的设计原则是：任务必须要求真实的工具使用和多步推理，而非知识回忆。

GAIA 典型的任务需要 Agent 组合使用浏览器、代码解释器、API 搜索等多种工具。例如：“从维基百科找出 2020 年后获得诺贝尔物理学奖的左撇子科学家，并在你的代码中生成一张柱状图。”

GAIA 的价值在于它的任务贴近真实使用场景，评测的是 Agent 的"真本事"而非"背书能力"。

AgentBench：多环境综合评估

AgentBench（清华大学团队开发）是目前最全面的 Agent 评测框架之一，支持在多种真实环境（操作系统、数据库、卡片游戏、代码调试等）中评测 Agent 的端到端能力。

AgentBench 的特色在于它的环境真实性：Agent 不是在一个沙箱 prompt 里答题，而是真的在操作一个 Linux 环境或真实网站。这让它能捕捉到很多"纸上谈兵"式评测无法发现的问题。

2026 年初，AgentBench 新增了 lite preset，允许开发者用更低的资源快速验证基础任务集，而不必运行全套重型环境。

WebArena 与 TAU-bench：环境模拟评测

WebArena 提供了一组真实可操作的网站（电商、论坛、协作工具），Agent 需要像真人一样点击、填表、导航。早期 GPT-4 版本的 Agent 在 WebArena 上仅能达到 ~14% 的任务完成率，而人类基线约为 78%，这说明 Agent 在真实网页操作上的能力缺口依然显著。

TAU-bench 则专注于 Agent 在结构化对话环境（机票预订、酒店预订场景）中的决策能力，评测 Agent 在多轮交互中能否做出正确且一致的工具调用选择。

BFCL：函数调用专项

BFCL（Berkeley Function Calling Leaderboard）专门评测 Agent 的函数调用能力：给定一个任务描述，Agent 需要从多个候选函数中选择正确的调用组合，并正确填充参数。函数调用是大多数 Tool-augmented Agent 的核心能力，BFCL 提供了一个标准化、可复现的评测方式。

第二层：决策层评测 — 过程比结果更重要

任务层基准告诉你 Agent 能不能完成一个任务，但它无法告诉你 Agent 是如何完成的。在生产环境中，过程质量往往和结果质量一样重要。

pass@k：突破单次评测的局限

传统评测用 pass@1（一次运行是否成功）来衡量 Agent 能力。但这种方法有一个根本缺陷：一个不稳定的 Agent 可能偶尔碰巧做对一次，就在 pass@1 上表现优异。

pass@k（即在 k 次尝试中至少成功一次的概率）是一个更诚实的指标。研究表明，许多在 pass@1 上看起来可靠的 Agent，在 pass@8（8 次运行中至少成功 1 次）上的表现会显著下降。

这对生产环境的启示是：如果你期望 Agent 在关键任务上可靠运行，需要关注它在多次尝试中的成功率，而非单次结果。

LLM-as-Judge：让模型评价模型

对于没有标准答案的开放式任务（如"这条回复是否合适地处理了用户情绪"），传统的自动化评测几乎失效。LLM-as-Judge 使用一个强模型（如 GPT-4o、Claude Sonnet）作为评测者，给目标 Agent 的输出打分。

一个有效的 LLM-as-Judge 评测通常包含：

  • 评判 prompt：清晰地定义评分维度和标准（如"回复是否准确、是否有帮助、是否有害内容"）
  • 评分粒度：建议使用 1-5 分制，而非简单的 binary 判断
  • few-shot 示例：提供 3-5 个有人类标注的参考答案，提升评判一致性

需要警惕的是：LLM-as-Judge 存在偏爱长输出的偏见，以及自身能力的上限问题——它很难评价比自己更强的 Agent。

规则引擎：确定性边界检测

对于某些维度（如输出是否包含禁止内容、是否调用了不该用的工具、响应时间是否超限），规则引擎比 LLM 评判更可靠。这类评测本质上是运行时行为检查，可以集成到 Agent 执行框架中，实现对每个 step 的自动校验。

一个实用的规则引擎评测层通常包括：

def evaluate_step(step_output: StepResult) -> EvaluationResult:
    violations = []
    if contains_harmful_content(step_output.response):
        violations.append("harmful_content")
    if step_output.tools_used - allowed_tools:
        violations.append("unauthorized_tool_call")
    if step_output.latency_ms > max_latency_ms:
        violations.append("latency_exceeded")
    return EvaluationResult(pass=len(violations)==0, violations=violations)

第三层：生产级持续评测 — 把评测变成 CI/CD 的一部分

超越离线基准测试的生产级评测，是 2026 年 Agent 工程化最关键的进步之一。

DeepEval：LangGraph 原生的多轮评测

DeepEval 是专为多轮 Agent 评测设计的框架，与 LangGraph 的节点/边结构深度整合，支持对每个决策步骤的打分。它提供了 6 种 Agent 专项评测指标（路径正确性、工具使用准确性、幻觉检测等），并且支持在 CI pipeline 中以 DAG 方式组织评测流程。

from deepeval import evaluate
from deepeval.metrics import ToolCallAccuracyMetric, HallucinationMetric

metrics = [ToolCallAccuracyMetric(), HallucinationMetric(threshold=0.3)]
evaluate(agent, test_cases, metrics)

TruLens：可解释的 Agent 追踪评测

TruLens 强调评测的可解释性：每个评测结果不仅有分数，还有 RAG-style 的归因追踪——它能告诉你"这个评分主要受哪几个输入 token 影响"，帮助开发者定位问题的根源。

对于需要向业务方解释 Agent 质量决策的团队，TruLens 的可解释性报告是很有价值的输出物。

Promptfoo：AI 输出的红队测试

Promptfoo 在 2026 年初被 OpenAI 收购后，已成为 AI 输出安全评测的标准工具。它最初主打 prompt 对比和回归测试，现在已扩展为完整的 AI 红队平台，支持：

  • 针对对抗性输入的输出安全检测
  • 敏感信息泄露检测
  • 跨模型（GPT、Claude、 Gemini）的一致性评测
  • CI 集成：每次 PR 触发自动评测，阻止低质量合并

如果你在构建面向用户的 Agent，Promptfoo 的安全评测应该是发布门槛之一。

持续评测的工程实践

把评测从"上线前一次性检查"变成"持续运行的质量 gate"，是 Agent 生产化的必经之路。一个实用的持续评测流水线通常包含以下要素：

触发时机评测内容工具
每次 PR 合并前回归测试（pass@k、一致性）DeepEval, Promptfoo
每日完整 benchmark 重跑AgentBench, GAIA
每周LLM-as-Judge 质量评分GPT-4o / Claude-as-Judge
实时运行时行为规则检查自定义规则引擎

评测层次的关系：金字塔而非替代

三层评测构成了一个完整的能力金字塔：

  • 任务层基准是地基：它定义了"能做对什么事"，是最低准入门槛。
  • 决策层评测是中层：它评估"做对事的过程是否正确"，这决定了 Agent 在边界情况下的表现。
  • 生产级持续评测是顶层：它确保"在真实环境中持续做对"，而非昙花一现。

如果只做任务层基准，Agent 可能高分但在实际使用中频频翻车。如果只做生产监控而没有任务层基准，则无法建立可量化的能力基线。三个层次缺一不可。

实践建议：你的第一个 Agent 评测流水线

从零开始构建评测体系，建议按以下路径推进：

第一步（1-2天）：建立回归基线。 选择 20-50 个覆盖核心场景的测试用例，用 pass@1 和 pass@8 同时衡量。目标不是追求高分，而是建立每次代码变更的回归检测能力。

第二步（1周）：引入 LLM-as-Judge。 为核心质量维度（回答准确性、语气适当性、工具使用合理性）各建立 3-5 个 few-shot 示例的评判 prompt。先在小范围验证评判一致性，再扩大规模。

第三步（2-3周）：接入 CI/CD。 将评测集成到每次 PR 的检查流程中，定义明确的通过门槛（建议：pass@8 ≥ 80%，LLM-as-Judge 平均分 ≥ 4.0/5.0）。

第四步（持续）：建立生产监控。 对线上真实请求进行采样，定期用 LLM-as-Judge 评分，与离线评测结果对比，持续发现离线集无法覆盖的边界场景。

结语

Agent 评测不是一件"做完就结束"的事。它是一个与 Agent 能力演进同步迭代的工程系统。当你的 Agent 从简单问答升级到多工具协作，从单 Agent 扩展到多 Agent 协作，评测的层次和复杂度也需要同步升级。

2026 年的 Agent 工程化，评测是核心基础设施之一。没有可量化的质量标准，Agent 的可靠性就无从保证，迭代方向也无从判断。希望这篇文章能帮助你建立起对 Agent 评测的完整认知框架，并给出可操作的起步路径。