Agent 评估最常见的问题解答

来源：https://www.langchain.com/blog/common-questions-about-agent-evals

当你构建并部署一个 Agent 时，你需要一种方式来验证它是否按预期运行，无论是在开发阶段还是在真实用户开始使用之后。

在传统软件中，相同的输入会产生相同的输出，因此单元测试可以验证精确的结果。Agent 之所以更难测试，有几个原因：

• 同一请求的输出每次运行都可能不同
• 正确的答案不止一种，因此精确匹配检查不够用
• Agent 自己选择执行步骤，所以一个正确的输出也可能来自“错误“的路径。例如，Agent 可能调用了不需要的工具，或者在未经用户许可的情况下执行了操作。

Agent 评估就是解决方案。它通过考虑这些变体的检查来为 Agent 的运行打分。与被评估的 Agent 类似，这些测试并不是放之四海而皆准的，最好的评估套件取决于团队、他们的产品以及他们想要优化的方向。

在 LangSmith（https://smith.langchain.com/）——LangChain 的 Agent 工程平台——过去几年的工作中，我们的团队遇到了非常多不同的评估问题。本博客将介绍如何开始进行 Agent 评估以及在工作流中可以使用的不同评估类型中最常见的一些问题。

我们应该从哪里开始？

每个评估都始于理解你的 Agent 实际做了什么。**Trace（追踪记录）**是 Agent 一次运行的记录，包括其输入、输出以及中间所有的模型和工具调用。阅读一些 Trace 样本，看看它是如何处理请求的，以及在哪些地方出了问题。你的发现会告诉你应该先测试什么。从小处开始。

1. **选择一个你关心的行为。**例如，对于一个旅行助手，一个行为可以是它是否预订了用户要求的日期和价格范围。
2. **从 Trace 构建一个小数据集。**数据集是示例的集合，每个示例是一个包含输入和通常的预期输出的测试用例。十到二十个关于某个行为的示例就足够开始了，在 LangSmith 中你可以直接从追踪视图将 Trace 添加到数据集。如果你的 Agent 还没有上线，让你的团队或一小群受信任的设计伙伴试用它（内部测试），然后根据这些 Trace 来工作。
3. **运行基线。**用你当前的 Agent 在数据集上运行，并将结果保存为实验。实验包含你的一个 Agent 版本在数据集上的运行结果，以及评估器给出的分数。你将用这个实验来对比未来 Agent 版本的表现。
4. **发现新的失败案例后将其添加到数据集中。**你在生产环境或测试过程中看到的每一个失败都成为新的示例。

价格是准确的，但 Agent 搜索了错误的日期。这条 Trace 将成为我们数据集中的新示例。

持续向数据集中添加失败案例，你就有了一个改进循环。找到失败案例，添加到数据集，改进 Agent，然后重新运行。随着你识别出更多需要评估的 Agent 行为，你将按照相同的模式扩展你的评估套件。

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

评估可以而且应该在你发布变更之前和 Agent 上线之后运行。发布前，评估可以告诉你变更是否让 Agent 变好或变差。发布后，评估可以告诉你 Agent 在真实用户中的表现如何。

离线评估在你发布变更之前用数据集运行 Agent。你选择示例输入，也可以包含预期输出（也称为参考输出）。使用你的数据集，你可以跨 Agent 版本对比实验结果。它们最适合用来测试新的提示词、模型或工具，以及在影响用户之前发现回归问题。

像 Terminal-Bench（https://www.tbench.ai/）这样的基准测试也是离线评估，建立在一组固定的任务上，方便你对比不同的 Agent、模型或版本。Harbor 运行这些测试并将结果记录到 LangSmith 实验中，我们稍后会更详细地介绍。

在线评估对实时进入的生产 Trace 实时打分。通常没有参考输出可以对比，所以它们依赖代码检查和 LLM 评判器来独立评估一次运行。它们最适合用来监控质量和发现数据集遗漏的问题。

你两种都需要，它们互相补充。在线评估标记的失败案例会成为你离线数据集中的新示例。

旅行 Agent 的离线评估和在线评估示例。

在 LangSmith 中，有几种方式可以为离线评估构建数据集。你可以从零编写示例、从现有 Trace 中添加运行、发送团队在标注队列中审核过的运行、上传 CSV 或 JSONL 文件，或者从已有示例中生成合成示例。

随着评估套件的增长，你需要决定是将示例添加到现有数据集还是创建新的数据集。经验法则：

• 当测试相同的行为且使用相同的评估器时，将示例保存在同一个数据集中，这样实验结果可以随时间保持可比。
• 当输入形式不同（如单次请求 vs 完整对话）、需要不同的评估器、或数据集有不同用途时（如在每个 Pull Request 上运行的小型数据集 vs 发布前运行的较大型数据集），创建新的数据集。

在单个数据集中，你也可以使用 split 来运行子集。

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

评估器是对运行结果打分的逻辑。有四种常见类型。大多数团队从一两种开始，然后随着时间推移逐步增加。

• 代码评估器进行确定性检查，例如预订的价格是否在用户的预算之内。它们快速、廉价且一致，但对确定性输入和输出的要求限制了它们的适用范围。
• LLM 作为评判器使用模型来评估代码无法检查的内容，例如助手的回复是否清晰确认了航班信息。
• 人工审核让你的团队或领域专家直接对运行结果打分。虽然较慢，但它是主观质量和验证其他评估器的最佳信号。通常用于较小的样本来为 LLM 评估器的判断提供校准。
• 成对评估器将两个输出并排比较并选出更好的一个，这在你需要在两个提示词或模型之间做选择时很有用。

根据评估器选择不同，你可能会问的问题

上述任何评估器都可以指向 Agent 运行的不同部分。一次评估可能针对：

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

你能信任 LLM 评判器吗？

LLM 评判器使用模型来评估难以用代码检查的输出，例如答案是否由检索到的文档支持。评判器很灵活，但它们可能不一致，或者偏离你团队的判断。一些习惯可以让它们更可靠：

• **将评判器与人工评分进行比较。**让团队中的某人对一批运行进行评分，检查评判器在哪些地方有分歧。调整评判器的提示词或示例，直到它们一致。LangSmith 中的标注队列让这件事变得容易。我们的 LLM 作为评判器的文档会指导你完成这个过程。
• **提出具体的问题。**在我们的旅行 Agent 示例中，问“回复是否提到了每个中转站？“比“这是一个好的回复吗？“更容易判断。
• **定义精确的评分标准。**通过/不通过的二元判断，或一组带标签的类别，远比 1-10 的评分更可复现。评判器可能很难区分 6 分和 7 分之间的区别。

对比使用 1-10 评分的评估器（描述不明确且容易产生高变异）和一组二元评估器。

评估等同于基准测试吗？

基准测试是一种离线评估，由一组任务组成。任务是基准测试中的单个测试用例，包括指令、容器中的环境和对结果打分的测试脚本。随着 Agent 能力的增强，简单的 LLM 评判器或基于代码的评估往往不够用。Agent 现在可以执行代码、编辑文件并与其他服务交互。为了模拟这种多步行为，基准测试在容器中设置隔离的基础设施。这让开发者可以离线测试 Agent 的行为，与 Agent 在生产环境中的工作方式相同。

基准测试与更简单的 LLM 评判器和基于代码的评估有几个不同之处：

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

对于我们的旅行助手，一个基准测试任务可能会给 Agent 一个模拟预订系统和一个请求，如“一场风暴取消了旅行者飞往丹佛的航班。重新为他们预订，并同步调整酒店。“Agent 完成后，测试脚本将检查数据库中的预订记录。

每个基准测试任务都附带自己的环境。测试脚本检查 Agent 留下的状态，Harbor 将跨任务的结果记录到 LangSmith 实验中。

Harbor 是一个开源评估框架，为这些较长任务的测试提供脚手架。它是驱动 Terminal-Bench 的框架，你可以使用相同的任务格式为自己的 Agent 构建基准测试。通过 LangSmith 集成，每次 Harbor 运行都被记录为一个 LangSmith 实验。Harbor 为每个任务构建一个容器，你可以使用 LangSmith Trace 让每个环境更接近你的 Agent 在生产环境中看到的情况。基准测试结果与其他评估结果并列，你可以打开任何运行来查看其分数旁边的完整 Trace。

我们使用这套设置来改进 Deep Agents 在 Terminal-Bench 2.0 上的表现，通过审查 Trace 找到失败模式，然后修改 Agent 框架。我们还用它构建了 IssueBench，一个针对 LangSmith Engine 的基准测试。每个 IssueBench 任务给 Engine 一批 Trace，并评估它是否将正确的 Trace 分组到正确的 issue 聚类中。

为自己的 Agent 构建基准测试遵循与上述评估相同的步骤，只是有一些变化：

• **从 Trace 收集任务。**在 LangSmith Trace 中找到失败案例，然后将每个失败转化为一个带有自己环境的 Harbor 任务，例如一个填充了用户预订信息的模拟预订系统。
• **定义“好“的标准。**创建 LLM 评判器或基于代码的评估器，根据你的评分标准打分。
• **在分数上持续爬升。**运行 Agent 并使用分数进行 A/B 测试。你可以设置一个 Agent 循环来自动执行这个过程。它会对你的 Agent 进行修改，重新运行基准测试，然后保留或回滚每项变更，类似于 Andrej Karpathy 几个月前的 autoresearch 循环。

如何在控制成本的前提下评估生产流量？

离线评估在固定的数据集上运行，因此成本是可预测的。在线评估在实时流量上运行，如果 LLM 评判器对每条 Trace 都打分，评估成本会随着每个新用户增长。为了保持可负担：

• **采样和过滤。**LangSmith 中的在线评估器可以对一定比例的流量打分，或者仅对匹配过滤条件的 Trace（如负面用户反馈）进行打分。
• **尽可能使用代码检查。**检查预订是否匹配请求的日期，或者 Agent 是否在预订前进行了搜索，几乎没有成本。
• **使用更便宜的评判器。**在我们的 Jev-as-a-Judge 实验中，TypeSafe AI 的 Jev 在每个通过/不通过的判断上都与人工标注一致，总成本为 $0.34，而 Claude Sonnet 4.6 的成本为 $28.17。

在线评估成本随评估器随时间在 LangSmith 中累积保存，团队可以监控支出。

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

你必须自己构建 Agent 评估吗？

不一定，尤其是当你需要评估常见的 Agent 问题时。一个好的起点是使用我们在 LangSmith 中预构建的 LLM 评估器模板，用于幻觉或 PII 泄露等典型检查。将其中一个添加到数据集或追踪项目中，并编辑其提示词以适配你的 Agent，例如告诉评判器我们的旅行助手绝不能在用户预算之外进行预订。

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

你也可以在不同数据集之间复用离线评估器，并将其作为在线评估器在生产 Trace 上运行（前提是评估器不使用参考输出）。