LangChain 讲解评估驱动开发如何改进 AI Agent

LangChain：Blog·2026-11-10 03:00· 52 分钟前AI 评分65

什么是评估驱动开发？如何改进 AI Agent

AI 导读

LangChain 在博客中介绍评估驱动开发（EDD），借鉴定驱动开发（TDD），用一致指标衡量 Agent 表现并指导迭代，可拆为三步：定义何为好、构建前先写 eval、修改后对比实验。

正文 · 原文

大多数 Agent 的开发都始于同样的方式。你写一个提示词，手动试几个问题，调整一下，再试一次。这在初期很有效，那时 Agent 的错误很明显，改进也容易看到。但随着时间推移，越来越难判断你最近的改动是让 Agent 变好了还是变差了。

评估驱动开发（EDD）通过提供一套一致的指标来衡量 Agent 的表现并指导你的决策，从而解决这个问题。在 LangChain，我们在构建最先进的 Agent 时使用了 EDD（查看我们关于 IssueBench 的博客），并将其归纳为三步流程：

定义你的 Agent 什么样才算好。
在构建之前先写 eval。
做出改动并进行对比。

在这篇博客中，我们将逐步讲解这一流程，以便你的团队能将其应用到自己的 Agent 开发过程中。

什么是评估驱动开发？

评估驱动开发的名称和概念借鉴了测试驱动开发（TDD），即先写一个失败的测试，再写能通过它的代码。Agent 与传统代码不同，因为它们是非确定性的：

输出会变化。 同一个问题每次运行可能得到不同的答案。
不止一个答案可能是正确的。 两个自然语言结果即使措辞不同，也可能都被认为是正确的。
Agent 自己选择步骤。 它可能调用了一个不需要的工具，或跳过一个本应使用的工具，却仍然得出正确答案。

因此，Agent 需要一种不同类型的测试。eval 通过在一组示例上对 Agent 的运行进行评分来处理这一点。Eval 比传统测试更灵活。你可以对 Agent 运行的任何方面进行评分，也可以使用其他 LLM 来评分（LLM-as-a-judge）。

在 EDD 中，与 TDD 类似，这些 eval 成为你对成功的定义，你朝着它们构建你的 Agent。

第 1 步：定义你的 Agent 什么样才算好

EDD 的第一步是定义你的 Agent 应该做什么。然后，列出它为实现这一目标需要处理的行为。这些可以是诸如回答知识库中的问题、代表用户执行操作，或知道何时提出后续问题等任务。写下每种行为的需求。这些共同构成了你的 Agent 的产品需求文档（PRD）。

EDD 一次只处理一种行为。这为你提供了一个狭窄的目标去逐步攀登，而不会让一项改动混淆另一项改动的效果。你选择的行为通常来自你即将构建的功能，或你在 Agent 过往运行中发现的失败。在写代码之前，定义一个简短的规范会很有帮助，涵盖：

该行为应在何时发生
Agent 应该做什么
Agent 不应该做什么
你的 PRD 中哪些行为必须继续正常工作

该规范应足够明确，以便评分为通过或失败。

假设我们有一个内部文档 Agent，员工用它查询公司信息。它有两个工具：search_docs 用于内部文档，web_search 用于其他所有内容。我们计划添加一个 create_ticket 工具，以便它可以提交 IT 工单。我们的规范如下：

何时：用户报告某功能故障，例如“我的笔记本电脑连不上 VPN。”
应做：致电 create_ticket。
不应做：为“如何连接 VPN？”这类操作问题提交工单。
保持不变：search_docs 和 web_search 仍处理它们目前处理的问题

我们将依据这些准则进行评估，尽管该 agent 目前还不具备相应能力。

Docs agent tool routing: search_docs, web_search, and the planned create_ticket tool, each with an example input — 当前的文档 agent 示例实现，以及我们计划添加的工单工具。每个工具都有一个可调用它的示例输入。

第 2 步：在构建之前先编写评估

构建数据集。 数据集是一组测试用例（称为“示例”），包含输入以及可选的参考“黄金”输出。输入的最佳来源之一是真实的 agent 运行记录。用户会以你意想不到的方式表述，他们的请求还包含你可能想不到要自己编写的边缘情况。如果你的示例看起来像真实流量，那么评估取得好成绩就更可能意味着生产环境中的良好表现。在 LangSmith 中，你可以直接将真实的 agent 运行记录添加到数据集中。如果你还没有任何运行记录，常见的替代方案是从头构建示例。

对于我们的文档 agent，少量示例就足以起步。在数据集中，我们将包含工单请求，以及仍应交给 search_docs 和 web_search 处理的问题，以便将现有行为纳入考量。

Docs agent dataset: example input questions paired with the tool the agent should call — 每个示例将输入问题与参考输出配对，参考输出即 agent 应调用的工具。

你还可以扩展数据集以覆盖尚未包含的情况。假设我们没有多少沮丧用户的示例。我们可以将现有示例交给 LLM，让它将其改写为更愤怒的消息，并检查 agent 是否仍调用正确的工具。

编写评估器。 有了数据集后，你可以将 PRD 中对“良好”的定义转化为测试或评估，为 agent 在你的示例上的表现打分。编写评估器时，选择最适合你的测试的评分方法类型。当检查是确定性的时，使用代码评估；当不是时，使用 LLM 作为评判者。你想查看 agent 的最终答案、它为达到目标所采取的操作，还是完全不同的其他内容？对于我们的文档 agent，我们希望查看它调用的工具，以验证它在每种情况下都使用了正确的工具。工具选择很容易在代码中检查，因此我们可以使用代码评估来检查每个示例是否调用了其参考输出中列出的工具。

Code evaluator that passes an example when the agent calls the tool in its reference output — 如果 agent 调用了其参考输出中的工具，则该示例通过。

我们的文档 agent 是一个具有几个特定功能的简单聊天机器人。随着你的 agent 变得越来越复杂，你的评估套件可能需要有所不同。如果你的 agent 在环境中进行更改，例如沙盒中的编码 agent，仅检查几个工具调用和最终响应并不能告诉你足够的信息。你需要检查 agent 在系统中留下的状态，并且每次运行都需要一个干净的环境，以免一次运行影响下一次。 Harbor 是一个用于在此类任务上运行 agent 的开源框架，它也是 Terminal-Bench 等行业基准背后的测试框架。每个任务都在自己的沙盒中运行，并附带一个测试脚本，用于对最终状态进行评分。

针对 Terminal-Bench 这类基准进行优化，遵循与 EDD 相同的循环。你先编写任务和测试，运行基线，然后在修改 agent 时对比实验。在构建 LangSmith Engine 时，我们用真实和合成的 agent 运行记录构建了自己的基准，并将其作为 Harbor 评估运行。我们还使用 Harbor 来对 Deep Agents 进行基准测试。它能告诉我们，是否可以在不让 agent 变差的情况下削减 harness 的某些部分，比如待办事项列表中间件或系统提示词的部分内容。

运行基线。无论你选择如何构建数据集或评估器，都可以让 agent 在每个示例上运行，并将结果作为实验记录在 LangSmith 中。实验是 agent 在数据集上的一次运行，其中每个示例的输入、输出和评估器分数都保存在同一条记录中。拥有一个集中式系统，可以让你将不同 agent 版本的结果相互比较。在对 agent 做任何更改之前，运行一个基线实验作为对比指标非常重要。

在我们的文档 agent 中，数据集里的工单示例会得到失败分数，因为该工具尚不存在。其他示例记录了已经正常工作的内容，这样你之后就能判断添加新工具是否会破坏其他功能。

第 3 步：做出更改并对比

现在，我们构建 create_ticket 工具并运行相同的评估。

请记住，EDD 涉及朝着评估目标“爬山”。爬山意味着重复改进 agent 的过程（评估、对比和调整），从而建立一个具有客观改进证据的明确循环。对 agent 的每一次后续更改都会有自己的实验，每个实验都会与上一个实验进行对比以验证进展。在 LangSmith 中，你可以通过选择两个实验来打开对比视图。它会并排显示每个示例的分数，这样你就能看到哪些改进了、哪些退步了。

在对比实验时，重要的是不仅要关注平均分数的变化，还要注意任何回归或对正常行为的覆盖。在我们的文档 agent 中，工单示例现在通过了。但“如何连接 VPN？”现在会提交工单，而不是搜索文档。平均分数上升了，但有一个用例坏了。

Experiment comparison: the ticketing tool raises the average score while the VPN how-to question regresses — 添加工单工具提高了平均分数，但“如何连接 VPN？”现在失败了。

查看 trace 是理解评估为何失败的最佳方式。trace 是 agent 一次运行的记录，包括每次模型调用和工具调用。使用你选择的任何框架构建的 agent 都可以在 LangSmith 中进行追踪。更多信息请查看我们的追踪快速入门。

当我们打开最新实验中失败的 trace 时，我们看到工具描述说对“VPN 和笔记本电脑问题”使用 create_ticket，因此任何提到 VPN 的问题都会匹配。这覆盖了基线中的良好行为。

Trace of the failing run showing a too-broad create_ticket tool description — trace 向我们显示工具描述过于宽泛，因此 agent 为文档可以回答的问题提交了工单。

解决方案是将工具描述收窄到需要 IT 采取行动的请求。实施此更改后，我们再次运行评估。现在，每个示例都通过了。

Experiments over time: a tighter tool description gets every example passing — 更精确的工具描述让每个示例都通过了。

在小数据集上拿到满分是个好迹象，但 100% 并不总是正确的目标。我们是在查看这些具体示例的同时调整工具描述的。如果你不断调整 agent 直到每个示例都通过，它可能开始对你的数据集过拟合，而不是你真正关心的行为。它能通过你的评估，却仍然会漏掉那些用你的示例未覆盖的方式表述的请求。要检查这一点，请保留一组在迭代过程中不去查看的留出示例。如果你调优所依据的示例分数上升，但留出集上分数持平，那你很可能过拟合了。

多步 agent 可能在任意一步失败，因此 LangSmith 让你可以评估最终答案之外的内容。你可以对单个步骤、完整的工具调用序列，或分组到一个 thread 中的多轮对话进行评分。

在发布过程中持续运行 EDD

自动化你的评估

当你开始更快地部署变更时，很容易跳过运行评估或跟丢较早的示例。通过将自动化评估加入你的工作流，你可以防止未经测试的变更到达用户，并在生产前捕获回归。

创建评估套件的最佳策略取决于你的具体设置。快速的代码检查可以阻止一次糟糕的合并，而使用 LLM 评判的较慢评估可以每晚运行或在发布前运行。使用数据集拆分，在迭代时只运行你正在处理的行为对应的示例，然后在发布前运行完整集合。

LangSmith 与 pytest 和 Vitest 集成，因此你的评估可以放在代码旁边，并在每次拉取请求时运行。每次运行都会记录为一个实验，因此你可以在与其他所有内容相同的地方查看结果。

在生产环境中评估

在部署你的 agent 之前，你的数据集很可能只覆盖了你在开发中想到要测试的用例。在生产环境中，你可以使用以下评估方法标记其余部分：

在线评估器会在实时 trace 传入时对其进行评分。你可以将代码检查和LLM 评判附加到 tracing 项目，并抽样一部分流量以控制成本。
标注队列让你的团队手动审查被标记的运行。它们也是你在依赖 LLM 评判之前，检查其是否与人类一致的方式。
仪表盘可以随时间跟踪评估分数、反馈、成本和延迟，因此你可以看到一次发布是让情况变好还是变差。
Insights将生产 trace 分组为集群，以便你可以在数千次运行中发现新模式。
LangSmith Engine更进一步，将问题集群转化为带有断言的数据集示例，供你审查。

我们还在其仓库中发布了我们用于 Deep Agents 的评估，因此你可以看到一个真实的生产评估套件。

常见错误

对成功的定义过于宽松。提前做好繁重的工作，清晰地定义成功，以便评估可以轻松地评分为通过或失败。“回复有帮助”不是一个定义良好的指标。
在修复之后才编写评估。一旦你看到了新的输出，就很容易编写一个按设计就能通过的评估。先编写它，并确认它在当前有问题的版本上失败。
只检查平均分。平均分的提升可能掩盖了出现回归的示例，或覆盖了良好行为的变更。在决定保留一项变更之前，请审查每个示例。
添加你并不需要的评估。每个评估都会把 agent 推向某个方向。把每个评估与具体的改动绑定，比如你正在修复的失败或即将构建的功能。
信任未经检验的评判器。先把你的 LLM 评判器与人工评分做对比。向它提出范围狭窄的问题，并使用通过或失败，而不是含糊的 1 到 10 分制。

有关构建 agent 评估的更多信息，请查看这场关于 Agent Evals 101 的网络研讨会，以及我们免费的 LangChain Academy 关于 LangSmith 的课程！

延伸阅读：

来源：LangChain：Blog · langchain.com