这篇解决的问题是：Agent 评测从想法到落地的每一步该做什么、按什么顺序做。

最值得拿走的是它的结构：六个阶段对应六组检查项，而贯穿其中的原则是「先用最简评测拿到信号」。三个容易踩的坑被点名得很准——只测正例会优化出一个乱调工具的 Agent；把护栏与评估器混为一谈会让内联拦截和异步评估互相拖累；用现成的「有用性」指标制造虚假信心，真正管用的评估器只能从自己的错误分析里长出来。

中文读者要读这篇，因为国内 Agent 项目大多已有跑分意识，但普遍缺这套「评测工程化」的完整方法：分层、打标、校准、修剪、门禁、回流，每一步都有可复制的操作细节，而不是停在概念层。国内语境要叠加的是数据合规与成本约束——生产轨迹回流时先做脱敏与授权管理，多次试验与在线评测的成本要按 token 价格折算，这对预算敏感的团队不是小事。

读完建议做一件事：今天就通读 20 条真实轨迹，写下你自己的故障分类学初稿。

—— FDEChina编辑部 · 架构师视角

本文作者 Victor Moreira 是 LangChain 的前置部署工程师（Deployed Engineer）。这份清单是《Agent 可观测性驱动 Agent 评测》的实操 companion——那篇文章讲清了 Agent 评测与传统软件测试的差异，介绍了核心可观测性原语（运行 run、轨迹 trace、会话线程 thread），并解释了它们如何映射到评测层级。如果你刚接触 Agent 评测，建议先读那篇。

本文聚焦「怎么做」：一份用于构建、运行和上线 Agent 评测的分步清单。核心原则只有一句：从能给你信号的最简评测开始。几条端到端评测——只测你的 Agent 能否完成核心任务——就能立刻建立基线，哪怕架构还在频繁变动。只有当你有证据表明更简单的方案正在漏掉真实故障时，才增加复杂度。

在构建评测之前

这一步的目标是先建立人工判断的基线，再谈自动化。用 LangSmith 从轨迹（trace）走到标注队列（annotation queue），再走到数据集与实验，是推荐的工作路径。本节检查项：

  • 在构建任何评测基础设施之前，先人工审读 20-50 条真实 Agent 轨迹
  • 为单一任务定义无歧义的成功标准
  • 把能力评测与回归评测分开
  • 确保你能识别并说清每个故障为何发生
  • 把评测的所有权交给一位领域专家
  • 先排除基础设施与数据管线问题，再怪罪 Agent

先人工审读 20-50 条真实 Agent 轨迹

在搭建任何基础设施之前，先花 30 分钟通读真实 Agent 轨迹。你从中学到的故障模式，会比任何自动化系统告诉你的都多。LangSmith 的轨迹视图与标注队列非常适合做这件事。

为单一任务定义无歧义的成功标准

如果两位专家无法就通过/不通过达成一致，说明任务本身需要打磨。模糊的成功标准：「把这份文档总结好。」清晰的成功标准：「从这份会议记录中提取 3 条主要行动项，每条不超过 20 个字，如果提到了负责人则必须包含。」

把能力评测与回归评测分开

两种你都需要，因为它们服务不同目的。能力评测（capability evals）通过测量困难任务上的进展推动 Agent 前进；回归评测（regression evals）保护已经可用的部分。不分开的后果是二选一：要么只守着既有行为而停止进步，要么只追新能力而不断把回归带上生产。

  • 能力评测回答「它能做到什么？」——起点是通过率很低，给你一座可以攀登的坡。
  • 回归评测回答「它还依然可用吗？」——通过率应接近 100%，用来捕捉倒退。

确保你能说清每个故障为何发生

如果你说不清某次失败的原因，就需要先做更多错误分析，再建自动化评测。这里应当花掉你 60-80% 的评测精力。流程如下：

  • 收集轨迹：从生产或测试环境收集有代表性的失败案例
  • 开放编码：与领域专家一起审读轨迹，不做预分类地记下你看到的每个问题（或用标注队列让领域专家自行审读）
  • 归类：把问题归组为故障分类学（taxonomy）——提示词问题、工具设计问题、模型局限、工具故障、数据缺口等
  • 迭代：持续审读，直到不再出现新的故障类别

归类之后，修复方案取决于根因：

  • 提示词问题：Agent 理解偏了，因为你的指令不清晰——改提示词
  • 工具设计问题：工具接口让 Agent 太容易犯错——重新设计参数、增加示例、明确边界
  • 模型局限：指令清晰但 LLM 无法泛化到边缘情况——增加示例、换一种架构，或换模型
  • 尚不清楚：你还没看够多的失败、看不出模式——先做更多错误分析

把评测的所有权交给一位领域专家

必须有人对评测流程负全责：维护数据集、重新校准评分器（judge）、分诊新的故障模式、决定「足够好」的标准。理想状态是由一位领域专家充当模糊情形下的质量仲裁人，而不是靠委员会做设计。

先排除基础设施与数据管线问题，再怪罪 Agent

Witan Labs 团队发现，一个单独的抽取（extraction）bug 就把他们的基准从 50% 拉到了 73%。基础设施问题（超时、API 响应格式错误、过期缓存）经常伪装成推理失败。先查数据管线。

选择你的评测层级

不是所有评测测的东西都一样，要把评测匹配到正确的 Agent 行为层级。本节检查项：

  • 理解三个评测层级：单步（run）、整轮（trace）、多轮（thread）
  • 从轨迹层（整轮）评测起步，再按需叠加运行层与会话层

单步评测（single-step）

回答的是：「Agent 选对工具了吗？」「它生成的 API 调用有效吗？」这类评测最容易自动化，但要求 Agent 架构稳定；如果你还在频繁改工具定义，运行层评测会经常失效。

整轮评测（full-turn）

这是大多数团队应该起步的地方。对一条完整轨迹从三个维度打分：

  • 最终回复：输出是否正确且有用？
  • 轨迹（trajectory）：Agent 走的路径是否合理？（不一定是完全符合预期的路径，只要是有效路径即可）
  • 状态变更：Agent 是否创建了正确的产物？（写入了文件、更新了数据库、排定了会议等）

状态变更评测最常被忽视，但对「做事」而不只是「说话」的 Agent 至关重要。比如你的 Agent 负责排会议，不要只检查它说了「会议已安排！」——要核实日历事件确实存在，且时间、与会人、描述都正确。它写代码，就运行代码；它更新数据库，就查询那些行。最终回复可以说「搞定！」，而实际状态是错的。

多轮评测（multi-turn）

这是最难实现的层级，应在轨迹层评测稳固之后再叠加。

实用技巧：使用 N-1 测试。从生产环境取真实对话前缀（前 N-1 轮），只让 Agent 生成最后一轮。这可以避免完全合成的多轮模拟中误差不断累积的问题。

先轨迹层，再按需叠加

轨迹层评测的单条信息量最高。运行层适合调试具体步骤。当你的 Agent 会有多轮对话时，会话层才开始重要。

数据集构建

本节检查项：

  • 确保每个任务无歧义，并配有能证明其可解的参考解（reference solution）
  • 同时测试正例（行为应当发生）与反例（行为不应发生）
  • 确保数据集结构与你选定的评测层级匹配
  • 按 Agent 类型定制数据集（编码、对话、研究）
  • 缺少生产数据时先生成种子样本
  • 从内部试用（dogfooding）错误、改编的外部基准和手写行为测试中取材
  • 搭建「轨迹到数据集」的飞轮，持续改进

每个任务都要无歧义且可解

歧义任务：「帮我找去纽约的好机票。」无歧义任务：「找 SFO 到 JFK 的往返机票，12 月 15-17 日出发，12 月 22 日返程，价格低于 400 美元，经济舱。」

如果 Agent 根本不可能成功（信息缺失、约束不可能满足），那是任务坏了，不是 Agent 坏了。为每个任务附上参考解，既能证明它可解，也给你一个可以对照打分的基线。

正例与反例都要测

如果你只测「该搜索的时候搜索了吗」，你最终会优化出一个什么都搜索的 Agent。反例也要测。数据集里要包含专门用来证伪你假设的样本，而不是只确认预期行为。

数据集结构匹配评测层级

  • 运行层（单步）评测需要参考工具调用或决策
  • 轨迹层（整轮）评测需要预期的最终输出和/或状态变更
  • 会话层（多轮）评测需要带预期上下文保持的多轮对话序列

按 Agent 类型定制

  • 编码 Agent：除了质量评分标准（rubric），还要配确定性的测试套件（可通过/不可通过的单测）
  • 对话 Agent：配多维标准——任务完成度与交互质量（同理心、清晰度）
  • 研究 Agent：配依据性检查（claims 是否有来源支撑）与覆盖度检查（关键事实是否齐全）

缺生产数据时生成种子样本

先定义任务的关键变化维度（查询复杂度、主题、边缘情况类型），手工创建约 20 个覆盖这些维度的示例输入，用现有 Agent 跑一遍，审读并修改后存为可靠的真实标准（ground truth）。

实用技巧：20-50 个你确信无疑、经过人工审读的样本，胜过几百个未经校验的合成样本。这里质量碾压数量。

三个持续取材来源

过了冷启动阶段后，你需要一条持续发现新评测的管线。三种策略配合使用效果最好：

  • 每天内部试用你的 Agent，把每个错误变成一条评测。这与生产监控不同——这是团队有意识地跨真实工作流对 Agent 做压力测试。
  • 从 Terminal Bench、BFCL 等外部基准中抽取并改编任务。不要整体跑完整基准；挑出测试你在意能力的任务，为你的 Agent 做适配。
  • 为特定行为手写针对性测试，比如「Agent 会并行调用工具吗？」「面对模糊请求它会追问澄清吗？」

《我们如何为 Deep Agents 构建评测》给出了这套方法的具体示例。

轨迹到数据集的飞轮

生产中出现的成功与失败都应回流到你的数据集、错误分析与评测改进中。这个飞轮才是让 Agent 随时间越变越好的机制。

评分器设计

本节检查项：

  • 按评测维度选择专门的评分器：客观检查默认用代码判定，主观评估用 LLM 充当评审（LLM-as-judge），模糊情形交给人，版本对比用成对（pairwise）评测
  • 区分护栏（guardrails，内联、运行时）与评估器（evaluator，异步、质量评估）
  • 优先用二元的通过/不通过，而非数值量表
  • 把 LLM-as-judge 评分器校准到人类偏好
  • 评结果，不评精确路径，并为渐进进展设计部分得分
  • 使用从你自己的错误分析中推导出的自定义评估器，而不是通用的现成指标

按维度选择专门的评分器

当存在客观正确答案时，默认用基于代码的评估器。用 LLM-as-judge 给客观任务打分可能不可靠——不一致的判定会掩盖真实的回归。换成确定性比较往往能消除不一致、给出更好的信号。LLM-as-judge 应保留给真正主观的评估。

实用技巧：与其造一个「正确性评估器」，不如把评测分解为按维度的专门评分器，而不是一个大而全的评分器。例如 Witan Labs 团队构建了 5 个专门评估器（内容准确性、结构、视觉格式、公式场景、文本质量），各自配维度适用的阈值。这能让你更清楚地知道到底什么在失败。

护栏与评估器的区别：

护栏（Guardrails） 评估器（Evaluators）
时机 执行期间，用户看到输出之前 生成之后，异步
速度 毫秒级（必须快） 秒到分钟级（可以贵）
目的 拦截危险或格式错误的输出 度量质量、捕捉回归
例子 PII 检测、格式校验、安全过滤 LLM-as-judge 打分、轨迹分析

安全检查和格式校验是护栏，应当内联运行。质量评估和回归测试是评估器，异步运行。别把两者混为一谈。

三类评分器的适用与陷阱

评分器类型 最适用于 当心
基于代码 确定性检查、工具调用验证、输出格式、执行结果 对有效但非预期的格式可能误判为失败
LLM-as-judge 细腻的质量判断、基于评分标准的打分、开放式任务 需要与人类校准（参见 Align Evals）
人类 校准、主观标准、边缘情况 贵、慢、难以规模化

优先二元判定而非数值量表

1-5 分量表会在相邻分数之间引入主观差异，并且需要更大的样本量才能达到统计显著性。二元判定逼你把思路理清楚：Agent 要么成功，要么没成功。复杂任务总是可以拆解成多个二元检查。

注意：近期研究表明，若使用 LLM-as-judge，短量表（0-5）可能带来更强的人类-LLM 对齐；但对人类评审而言，二元判定仍更简单、迭代更快。

把 LLM-as-judge 校准到人类偏好

  • 先用 20 条以上带标注的样本起步（可用 LangSmith 的 Align Evaluator 功能），再朝约 100 条增长，达到生产级置信度
  • 在评审输出中包含推理过程；这能提升准确性，也让你能审计它为什么这样打分（Anthropic 的《Demystifying Evals》同样强调这点）
  • 定期重新校准；评审器会漂移，且没有哪个评审器在所有基准上都一致可靠
  • 用少样本（few-shot）示例提升评估器一致性；在 LangSmith 中纠错记录可以自动填充为少样本示例

评结果，不评路径

Agent 会找到有创意的解法。正如 Anthropic 在《Demystifying Evals》中所说：「不要评 Agent 走了哪条路，要评它产出了什么。」如果你要求「必须按顺序调用工具 A、B、C」，你会错杀那些找到更聪明路线的 Agent。更好的问法是「会议是否被正确排定了？」而不是「它在 create_event 之前是否调用了 check_availability？」

一个正确识别问题、但在最后一步失手的 Agent，好过一开始就失败的 Agent。设计部分得分，让指标反映渐进进展。

自定义评估器胜过现成指标

「有用性」「连贯性」这类现成指标制造虚假信心。真正重要的评估器，是那些能抓住你特定故障模式的评估器——而它们只能来自上文描述的错误分析过程。

运行与迭代

本节检查项：

  • 区分离线、在线与临时（ad-hoc）评测，三者都用起来
  • 每个任务跑多次试验（trial），以应对非确定性
  • 人工审读失败评测的轨迹，验证评分器是否公平
  • 确保每次试验都在干净、隔离、无共享状态的环境中运行
  • 按能力类别给评测打标签、记录每条评测测什么，并在质量之外跟踪效率指标（步数、工具调用数、延迟）
  • 识别通过率进入平台期的信号，并随之演进测试套件
  • 只保留直接测量你在意之生产行为的评测
  • 投资工具接口的设计与测试，而不只是优化提示词
  • 区分任务失败（Agent 做错了）与评测失败（评分器判错了）

离线、在线与临时评测

本清单的大部分篇幅聚焦离线评测，这是有意的。离线评测是你进步的地方：精选数据集、受控实验、上线前迭代。但 Agent 进入生产后，你同样需要在线评测与临时评测。

是什么 何时使用
离线 精选数据集，部署前运行 上线前测试变更
在线 对生产轨迹的持续评测 在真实流量中捕捉失败
临时 对已采集轨迹的探索性分析 发现你没预料到的模式（参见 Insights）

下文的「生产就绪」一节会详细展开如何搭建在线评测、以及如何定期安排临时性的轨迹探索。

多次试验应对非确定性

模型输出在不同运行之间存在波动。成本允许就用多次重复。跑多次试验时，先算置信区间再宣布改进——单次运行的基准充满噪声。对非确定性 Agent，按产品需求选择 pass@k（k 次中至少一次成功）或 pass^k（k 次全部成功）指标。

质量之外还要跟踪运营指标：对话轮数、token 用量、延迟、单任务成本。一个准确率 95% 但慢 10 倍的 Agent，未必是改进。

打标签、写文档、跟踪效率

按评测测什么来分组，而不是按它来自哪里。file_operations、retrieval、tool_use、memory、conversation 这类别，能在单一聚合分数与逐条结果之间给你一个「中间视角」。给每条评测加文档说明它测量哪项 Agent 能力，这能在套件变大时保持意图清晰，也让你可以跑定向子集（比如改了某个工具定义后只跑 tool_use 评测）。

给每个实验附加元数据，方便按重要维度过滤、分组、对比。这让你不用翻日志就能回答「从 GPT-4.1 切到 Claude Sonnet 后准确率提高了吗」「哪个提示词版本在这个数据集上回归了」。LangSmith 在可用时会自动抓取 git 信息，但显式标注模型与提示词元数据，在实验量上来后很快就有回报。

质量确立之后，再在效率维度上比较模型。跟踪诸如实际步数/理想步数、实际工具调用数/理想工具调用数、实际延迟/理想延迟的比值。这与「评结果不评路径」并不冲突：理想轨迹度量的是效率，不是正确性。找到有创意路线的 Agent 照样通过，但你能看出它是否花了更久。《我们如何为 Deep Agents 构建评测》里的指标框架是一个完整示例。

人工审读失败评测

一条「失败」的任务可能其实是评分器没预料到的、有创意的有效解。读轨迹是你判断评分器是否公平的方式。

试验环境必须干净隔离

如果第 2 次试验能看到第 1 次的产物，你的结果就不独立。实践中这意味着：编码 Agent 每次试验用全新容器或虚拟机；调 API 的 Agent 用预发环境或 mock 服务；数据库 Agent 在试验之间做快照与恢复。

识别通过率平台期

当通过率停滞、继续加同类任务不再暴露新的故障模式时，就该演进套件了：加更难的任务、测新能力，或转向其他维度。在一个已饱和的评测集上死磕纯属浪费。

只保留有信号的评测

每条评测都会随时间对系统施加压力。盲目堆几百条测试很诱人，但那制造的是进步的错觉——你最终优化的是一个不反映生产要害的评测套件。评测越多不等于 Agent 越好。构建定向评测，并定期修剪不再给你信号的条目。具体做法参见《我们如何为 Deep Agents 构建评测》。

投资工具接口设计，而不只是提示词

工具设计能整类整类地消灭 Agent 错误。Anthropic 团队提到，构建他们的 SWE-bench Agent 时，花在优化工具上的时间比提示词还多。测试模型实际如何使用你的工具：尝试不同参数格式（diff 对比全文重写、JSON 对比 markdown）、重新设计接口让犯错更难、投入写带示例的清晰文档。目标是让错误在结构上不可能发生，而不只是不太可能发生。比如，强制使用绝对文件路径就消灭了一整类导航错误。

区分任务失败与评测失败

显式跟踪运行状态（完成、错误、超时）。把超时标记为「推理错误」的评分器会污染你的信号。把任务失败与评测失败分开，指标才干净。

生产就绪

本节检查项：

  • 把通过率持续很高的能力评测晋升进回归套件
  • 把回归评测接入 CI/CD 流水线，配自动质量门禁
  • 采集用户反馈
  • 为生产流量搭建在线评测
  • 在自动检查之外，定期人工探索生产轨迹
  • 提示词与工具定义跟随代码一起做版本管理
  • 确保生产故障回流到数据集、错误分析与评测改进

能力评测晋升为回归评测

爬上坡之后就要守住它。曾经测试「我们能不能做到？」的任务，变成测试「我们还能不能做到？」。

接入 CI/CD 与质量门禁

典型流程：

  • 代码或提示词变更触发流水线（通过 git push、PromptHub 更新或手动触发）
  • 离线评测运行单测、集成测试，并用便宜、快速的评分器对精选数据集做评测
  • 离线评测通过后，部署预览环境（preview）
  • 在线评测用 LLM-as-judge 评分器对预览环境跑真实数据
  • 所有质量门禁通过才晋升到生产；否则把失败轨迹路由到标注队列并告警团队

CI 中对每次提交使用便宜的代码评分器；昂贵的 LLM-as-judge 评测留给预览/生产评估。LangSmith 的 CI/CD 流水线指南给出了基于 GitHub Actions 的完整实现示例。

为生产流量搭建在线评测

安全检查、格式校验、质量启发式规则都要上。你会在生产里发现从未预料到的故障模式（参见《不到生产你不知道你的 Agent 会干什么》）。

采集用户反馈

Agent 上生产之后，用户反馈成为你最宝贵的信号之一。自动评测只能抓住你已经知道的故障模式，用户会暴露你不知道的那些：数据集漏掉的边缘情况、技术上正确但毫无用处的输出、以你从未想过的方式断裂的工作流。把反馈结构化地采集起来，回流到数据集，用真实世界的预期校准评分器，才能优先改进对用户真正重要的东西。

定期人工探索生产轨迹

不要只依赖自动化的通过/不通过。定期探索生产轨迹，寻找评分器没覆盖的意外模式或故障方式、令人意外的用户行为，以及改进机会。我们的 Insights Agent 是做这件事的好工具。

版本化提示词与工具定义

LangSmith 让提示词版本管理变得简单。没有版本管理，你就无法把评测结果与具体变更关联起来，也无法知道哪次修改导致了回归。

让生产故障回流

生产的成功与失败都应回流到数据集、错误分析与评测改进。这就是让 Agent 随时间越变越好的飞轮。

小结与下一步

这份清单不需要你第一天就全做。选一节匹配你当前阶段的：还没评测的，从人工审读轨迹和无歧义成功标准开始；已在跑评测的，补齐评分器校准与试验隔离；已上生产的，把回归门禁与用户反馈回环建起来。能上线可靠 Agent 的团队，不是评测基础设施最精良的团队，而是尽早开始评测、并且从未停止迭代的团队。

下一步，建议你先花 30 分钟通读 20 条真实轨迹——这是整个清单中投入产出比最高的一个动作。然后把「能力评测 vs 回归评测」的分层复制到自己的项目中。

延伸阅读（原文列表）

  • LangChain：《Agent Observability Powers Agent Evaluation》（本清单的概念篇）、《You don’t know what your agent will do until it’s in production》、《Evaluating skills》、《How we build evals for Deep Agents》
  • Witan Labs：Research Log: Building an LLM-powered spreadsheet agent
  • 外部基准（评测任务来源）：Terminal Bench 2.0、BFCL（Berkeley Function Calling Leaderboard）
  • Anthropic：《Demystifying Evals for AI Agents》《Building Effective Agents》
  • OpenAI：Testing Agent Skills Systematically with Evals
  • Hamel Husain：LLM Evals: Everything You Need to Know
  • arXiv 论文：Agent-as-a-Judge: Evaluate Agents with Agents、A Survey on LLM-as-a-Judge、Judge Reliability Harness

延伸阅读：想系统补齐评测概念，可阅读站内 Agent 专题与评测相关词条（FDE 实践指南中有评测基线的完整方法）；关于评测在交付流程中的位置，参见 FDE 项目生命周期与 FDE 能力模型。

本文由 FDEChina 团队翻译自原文，转载已注明出处；如需引用请以原文为准。