关于 Agent 评估的常见问题解答：LangChain 实战指南

LangChain 2026-10-15 2026-10-19

原文来源：LangChain Blog

核心要点

评估（Evals）会为 Agent 的每次运行打分，让你能够确认它是否按预期行事。 上手时，先选定一种行为，用真实轨迹构建一个小型数据集，然后跑出一个基线。在发布变更前使用离线评估，在生产环境中使用在线评估，并把新出现的失败案例转化为数据集样本。
能用代码评估器的地方就用代码评估器，代码无法评估的地方用 LLM Judge，再用人工评审来校验这两者。 对于需要执行多步的 Agent，要评估完整的对话线程、执行轨迹以及最终状态。
像 Terminal-Bench 这样的基准测试属于离线评估，任务更长，并且自带运行环境。 Harbor 会运行这些基准测试，并把结果记录到 LangSmith 实验中。

在构建和发布 Agent 的过程中，你需要一种方法来确认它是否按预期行事——无论是在开发阶段，还是在真实用户开始依赖它之后。

在传统软件中，相同的输入会产生相同的输出，因此单元测试可以检查精确的结果。而 Agent 更难测试，原因有以下几点：

每次运行的输出都会变化，即使请求完全相同也是如此
正确答案可能不止一个，因此检查精确匹配并不够用
Agent 会自行决定执行步骤，所以即便输出正确，也可能来自一条“错误”的路径。例如，Agent 可能调用了一个它并不需要的工具，或者在未经用户许可的情况下采取了某项操作。

Agent 评估正是解决之道。它通过能够应对这些变化的检查项，为 Agent 的运行结果打分。与被评估的 Agent 一样，这些测试并非放之四海而皆准；最佳的评估套件取决于团队、产品，以及团队想要优化的目标。

过去几年，在打造 LangSmith——LangChain 的 Agent 工程平台——的过程中，我们的团队遇到了大量关于评估的不同问题。本文梳理了其中一些最常见的问题，涵盖如何开始做 Agent 评估，以及在工作流中可以使用哪些不同类型的评估。

应该从哪里开始？

每一项评估都始于理解你的 Agent 实际在做什么。轨迹（trace）是 Agent 一次运行的记录，包含它的输入、输出，以及其间每一次模型调用和工具调用。阅读一批轨迹样本，了解它如何处理请求、在哪些地方出错。你的发现会告诉你应该先测试什么。从小的范围开始。

选定一种你关心的行为。 例如，对于旅行助手来说，一种行为可以是它是否按照用户要求的日期和价格区间完成预订。
用轨迹构建一个小型数据集。 数据集（dataset）是一组样本的集合，每个样本都是一个测试用例，包含输入，通常还包含预期输出。针对一种行为，10 到 20 个样本就足以起步；在 LangSmith 中，你可以直接从轨迹视图把轨迹添加到数据集。如果你的 Agent 尚未上线，可以让团队或一小批值得信赖的设计合作伙伴先试用（内部试用，dogfooding），并基于这些轨迹来开展工作。
跑一个基线。 让当前版本的 Agent 在数据集上运行，并把结果保存为一次实验（experiment）。实验包含某个版本的 Agent 在数据集上运行的结果，以及评估器给出的分数。之后你可以用这次实验来对比未来各版本 Agent 的表现。
发现新失败就补充进去。 你在生产环境或测试中看到的每一个失败，都会成为一个新的样本。

价格是准确的，但 Agent 搜索了错误的日期。这条轨迹将成为我们数据集中的一个新样本。

持续把失败案例加入数据集，你就拥有了一个改进闭环：发现失败、加入数据集、改进 Agent、重新运行。随着你识别出更多需要评估的 Agent 行为，你可以按照上面同样的模式扩展评估套件。

离线评估和在线评估有什么区别？

评估可以——也应该——在发布变更之前以及 Agent 上线之后都运行。发布前，评估能告诉你某项变更让 Agent 变好了还是变差了。发布后，评估能告诉你 Agent 在真实用户面前的表现如何。

离线评估（Offline evals） 在发布变更之前，让 Agent 在数据集上运行。样本输入由你选择，你还可以附带预期输出（也称为参考输出）。借助数据集，你可以比较不同 Agent 版本的实验结果。它们最适合用来测试新的提示词、模型或工具，并在问题到达用户之前发现回归。

像 Terminal-Bench 这样的基准测试也属于离线评估，它构建在一组固定任务之上，便于你比较不同的 Agent、模型或版本。Harbor 负责运行这些基准测试，并把结果记录到 LangSmith 实验中，我们会在下文详细介绍。

在线评估（Online evals） 会在真实的生产轨迹产生时对其进行评分。通常没有可供对比的参考输出，因此它们依赖代码检查和能够独立评判单次运行的 LLM Judge。它们最适合用来监控质量，并发现数据集未曾覆盖的问题。

两者都需要，而且它们会相互反哺。在线评估标记出的失败，会成为离线数据集中的新样本。

旅行助手的离线评估与在线评估示例。

在 LangSmith 中，有几种方式可以为离线评估构建数据集。你可以从零编写样本，把现有轨迹中的运行结果添加进来，把你团队在标注队列中审核过的运行结果发送过来，上传 CSV 或 JSONL 文件，或者基于已有的一些样本生成合成样本。

随着评估套件不断增长，你需要决定是把样本加入现有数据集，还是新建一个数据集。一个经验法则是：

当样本测试的是同一种行为、使用相同的评估器时，就把它们放在同一个数据集中，这样实验在长期内仍可比较。
当输入看起来不同（例如单次请求与完整对话）、需要不同的评估器，或者数据集服务于不同目的（例如在每次拉取请求时运行的小数据集，与发布前运行的较大数据集）时，就新建一个数据集。

在同一个数据集内，你还可以使用数据集划分（splits）来只运行其中的一部分样本。

Agent 评估器有哪些不同类型？

评估器（evaluator）是给一次运行打分的逻辑。常见的类型有四种。大多数团队会从一两种开始，再逐步增加。

代码评估器（Code evaluators） 以确定性的方式检查某些事情，例如预订价格是否在用户预算之内。它们快速、廉价且一致，但由于需要确定性的输入和输出，其适用范围受到限制。
LLM-as-a-judge（LLM 作为裁判） 使用模型来评判代码无法判断的内容，例如助手的回复是否清晰地确认了航班详情。
人工评审（Human review） 由你的团队或领域专家直接为运行结果打分。它速度较慢，但对于主观质量以及校验其他评估器而言，能提供最佳信号。通常会在较小的样本上使用，再用其结果来指导 LLM 评估器的判断。
成对评估器（Pairwise evaluators） 将两个输出并排比较并选出更好的一个，在你需要从两个提示词或两个模型之间做选择时非常有用。

根据评估器类型的不同，你可能会提出的问题

上述任何一种评估器，都可以针对 Agent 运行过程中的不同部分进行评估。一项评估可以针对：

单个步骤。 例如，search_flights 是否以正确的日期被调用。
最终回复。 例如，回复是否确认了 Agent 实际预订的航班。
完整对话。 例如，最终预订是否反映了用户在多个轮次中提出的每一项变更。
环境的最终状态。 例如，Agent 在独立容器中运行后，模拟预订系统中的预订记录。基准测试经常采用这种设置，你有时会听到它们被称为容器化评估（containerized evals）。

可以信任 LLM Judge 吗？

LLM Judge 使用模型来评判那些难以用代码检查的输出，例如答案是否有检索到的文档作为支撑。Judge 很灵活，但也可能不稳定，并与你团队的判断产生偏差。养成以下几个习惯可以让它们更可靠：

将 Judge 与人工评分进行对比。 让团队中某个人为一批运行结果打分，再检查 Judge 在哪些地方与人工判断不一致。调整 Judge 的提示词或示例，直到两者趋于一致。LangSmith 中的标注队列让这件事变得很简单。我们的 LLM-as-a-judge 文档会带你完成这一过程。
提出范围狭窄的问题。 在我们的旅行助手示例中，“回复是否提到了每一段经停？”比“这是一个好回复吗？”更容易评判。
定义精确的评分量表。 二元的通过/不通过，或者一小组带标签的类别，远比 1–10 分的评分更可复现。Judge 可能很难区分 6 分和 7 分。

1–10 分评分制（缺乏描述性且容易产生高方差）的评估器与一组二元评估器的对比。

评估和基准测试是一回事吗？

基准测试（benchmark）是一类由一组任务构成的离线评估。任务是基准测试中的单个测试用例，包含指令、容器中的运行环境，以及为结果打分的测试脚本。随着 Agent 能力不断增强，单纯的 LLM Judge 或基于代码的评估往往已经不够用了。如今的 Agent 可以执行代码、编辑文件，并与各种服务交互。为了对这种多步行为建模，基准测试会在容器中搭建隔离的基础设施。这样一来，开发者就能在离线环境中，以与生产环境相同的方式测试 Agent 的行为。

基准测试与更简单的 LLM Judge 和基于代码的评估有以下几点不同：

任务涉及更多步骤。 为了完成单个任务，Agent 可能需要安装软件包、编辑文件，并通过数十次工具调用执行命令。
每个任务都自带环境。 Agent 现在可以在沙箱之类包含代码仓库、文件和工具的环境中采取行动。每个任务都会附带自己独立的隔离环境，供 Agent 在其中工作。
评分检查的是 Agent 做了什么。 测试脚本会在运行结束后检查环境的状态，例如测试是否通过、正确的文件是否存在。你仍然可以查看轨迹，但分数来自 Agent 采取的行动以及它留下的状态。

对于我们的旅行助手，一个基准测试任务可能会给 Agent 一个模拟预订系统，以及这样一条请求：“一场风暴取消了旅客飞往丹佛的航班。请为其重新预订，并相应调整酒店。”Agent 完成后，测试脚本会检查数据库中的预订记录。

每个基准测试任务都自带环境。测试脚本会检查 Agent 留下的状态，Harbor 会把各个任务的结果记录到一次 LangSmith 实验中。

Harbor 是一个开源评估框架（eval harness），为这类更长任务的测试提供脚手架。它是驱动 Terminal-Bench 的框架，你也可以用同样的任务格式为自己的 Agent 构建基准测试。借助 LangSmith 集成，每次 Harbor 运行都会作为一次 LangSmith 实验被记录下来。Harbor 会为每个任务构建一个容器，你可以利用 LangSmith 轨迹让每个环境更接近 Agent 在生产中看到的样子。这样，基准测试结果就会与其他评估结果放在一起，你可以打开任意一次运行，在分数旁边查看完整的轨迹。

我们正是用这套设置在 Terminal-Bench 2.0 上改进 Deep Agents：通过审阅轨迹找出失败模式，然后修改 harness。我们也用它构建了 IssueBench——一个面向 LangSmith Engine 的基准测试。IssueBench 的每个任务都会给 Engine 一批轨迹，并评估它是否将正确的轨迹归入了正确的问题聚类。

为自己的 Agent 构建基准测试，遵循的步骤与上面的评估相同，只需做几处调整：

从轨迹中收集任务。 在 LangSmith 轨迹中寻找失败案例，然后把每一个转化为一个带有独立环境的 Harbor 任务，例如一个填入了用户预订信息的模拟预订系统。
定义什么算“好”。 创建 LLM Judge 或基于代码的评估器，按照你的评分标准打分。
围绕分数做爬山优化。 运行 Agent，并利用分数对变更进行 A/B 测试。你可以搭建一个 Agent 循环来自动完成这一过程：它会修改你的 Agent、重新运行基准测试，并保留或回滚每一项变更，这类似于 Andrej Karpathy 几个月前提出的 autoresearch 循环。

如何在不产生高成本的情况下评估生产流量？

离线评估运行在固定数据集上，因此成本可预测。在线评估运行在实时流量上，所以如果让 LLM Judge 为每条轨迹打分，评估成本就会随着每一个新用户而增长。为了把成本控制在可承受范围内：

采样与过滤。 LangSmith 中的在线评估器可以只对一定比例的流量打分，或者只对符合某个过滤条件的轨迹打分，例如收到负面用户反馈的轨迹。
尽可能使用代码检查。 检查预订是否与请求的日期一致，或者检查 Agent 是否在预订前进行了搜索，成本几乎为零。
使用更便宜的 Judge。 在我们的 Jev-as-a-Judge 实验中，来自 TypeSafe AI 的 Jev 在每一次通过/不通过的判定上都与人工标签一致，总成本仅为 $0.34，而 Claude Sonnet 4.6 的成本为 $28.17。

LangSmith 会随时间保存在线评估的成本，因此团队可以监控自己的开销。

按评估器划分的在线评估成本随时间变化

必须自己构建 Agent 评估吗？

不必，尤其是在评估常见的 Agent 问题时。LangSmith 中预置的 LLM 评估器模板是一个很好的起点，可用于幻觉或 PII 泄露等典型检查。把模板添加到数据集或追踪项目，再修改其提示词以适配你的 Agent，例如告诉 Judge：我们的旅行助手绝不能在用户预算之外进行预订。

我们的开源 agentevals 包也为 Agent 的消息和工具调用提供了预置评估器。它们可以将 Agent 调用的工具与参考列表进行比较，或者让 LLM Judge 判断这些步骤是否合理。

你还可以跨数据集复用一个离线评估器，并把它作为在线评估器运行在生产轨迹上（仅当该评估器不需要参考输出时才可行）。

对于针对你自己 Agent 的评估，Eval Engineering Skill 可以在 Claude Code 或 Codex 等编码 Agent 中运行，读取你的代码仓库和轨迹，并与你一起编写可运行的评估。

LangSmith Engine 还可以从生产轨迹中自动提取信息，为你编写评估。当它识别出一个问题聚类时，会把失败的轨迹转化为数据集样本，并把它们的参考输出写成断言，例如“在用户请求的日期预订航班”。

如何评估多轮对话？

许多 Agent 需要跨多个轮次工作。例如，用户可能先向我们的旅行助手询问航班，然后更改日期，再添加酒店。单独看每一轮可能都没问题，但整个对话却可能出问题。

要在 LangSmith 中评估对话，请在轨迹元数据中传入线程 ID，这样每一轮都会被归入同一个线程。线程是来自同一段对话的一系列轨迹。在此基础上，你可以挂载在线评估器，在对话结束后对整个线程打分，问题可以包括“最终预订是否反映了用户要求的每一项变更？”或者“用户是否不得不重复自己的需求？”LangSmith 还会把每个线程展示为一条轨迹视图（trajectory），按顺序列出每一条消息和每一次工具调用。

对于离线评估，你可以把完整对话作为样本存入数据集，或者用 LLM 模拟用户，从而测试 Agent 从头到尾处理一段对话的能力。

单独看每一轮都合理，问题只有在整个线程中才会显现出来。

如何评估最终输出之外的 Agent 表现？

Agent 会执行许多步骤，因此最终答案只能展示所发生事情的一部分。除了最终回复之外，你可能还想检查：

路径，即 Agent 产生的消息和工具调用序列。
最终状态，例如我们的旅行 Agent 创建的预订记录、它写入的文件，或者它对代码仓库所做的更改。

随着你的生产 Agent 变得越来越复杂，你可能需要一个专门的评估框架（eval harness）。尤其是当 Agent 的工作体现为它对环境所做的更改时。假设一个编码 Agent 被要求修复一个 bug。LLM Judge 可以阅读 Agent 的回复，但可靠的检查方式是在 Agent 完成后运行代码仓库的测试。要做到这一点，每次测试运行都需要自己的一份干净仓库副本，以免各次运行相互影响。Harbor 会为你完成这些设置。你可以在 LangSmith Sandboxes 中运行用 Deep Agents 构建的 Agent，并把每次运行及其轨迹记录到一次 LangSmith 实验中。更多信息请参阅 Harbor x LangChain。

如果 Agent 不是用 LangChain、LangGraph 或 Deep Agents 构建的，还能在 LangSmith 中追踪和评估它吗？

可以！LangSmith 与框架无关，因此你可以追踪和评估用任何框架构建的 Agent，甚至完全不用框架的 Agent。发送轨迹有几种方式：

框架集成。 LangSmith 为流行的 Agent 框架提供了集成，例如 OpenAI Agents SDK、Claude Agent SDK 等。
模型提供方封装器。 如果你直接调用模型提供方，可以封装 OpenAI 或 Anthropic 的客户端，这样每次模型调用都会被追踪。
@traceable 装饰器。 将它添加到自己的函数上，例如旅行助手的航班搜索工具，就能追踪 Agent 的任意步骤。

一旦轨迹进入 LangSmith，评估对任何框架都以相同方式工作。你可以把轨迹添加到数据集，通过把 Agent 传给 SDK 的 evaluate() 函数来运行离线实验，还可以为生产流量挂载在线评估器。

如何从现有的评估技术栈迁移过来？

你不必从头开始。你已经构建的大部分内容都可以沿用到 LangSmith：

数据集。 将现有测试用例作为 CSV 或 JSONL 文件上传，或者用 SDK 创建。
代码评估器。 现有的评分函数通常只需少量修改，就能作为 LangSmith 评估器运行。如果你的评估已经以测试形式运行，pytest 和 Vitest 集成可以让你保留原有设置。
LLM Judge。 将现有的 Judge 提示词粘贴到 UI 中的 LLM-as-a-judge 评估器里，或者继续把它保留在代码中。
追踪。 LangSmith 可与任何框架配合使用，因此你可以从当前的 Agent 发送轨迹，而无需重写它。

如何汇报结果？

离线实验显示每次发布是否带来了改进。在线评估仪表盘则展示性能在生产环境中随时间推移的表现。在 LangSmith 中，你可以直接比较实验结果，并针对 Token 成本、延迟和评估器分数等指标创建自定义仪表盘，观察它们随时间的变化。基准测试则提供一个稳定的分数，用于跨发布版本比较模型或 Agent 版本。

下一步

如果你想深入了解，可以阅读我们如何为 Deep Agents 构建评估，尝试 LangSmith 评估快速入门，或者查看我们在 LangChain Academy 上的 LangSmith Essentials 课程。

更喜欢真人讲师？我将在 2026 年 10 月 28 日主持一场关于 Agent 评估的线上研讨会。请在这里注册！

菜单