LangChain 详述评估驱动开发，以构建可靠的 AI 智能体

LangChain 发布了一份关于评估驱动开发（EDD）的详细指南。该方法论旨在解决一个日益严峻的挑战：如何验证对 AI 智能体的修改是否确实提升了性能。核心问题在于，智能体开发往往依赖于手动测试，随着复杂性的增加，这种方式会变得不可靠。EDD 引入了一套一致的指标来指导决策，它借鉴了测试驱动开发（TDD）的理念，但针对大语言模型（LLM）的非确定性特征进行了调整。

发生了什么

根据 LangChain 博客，EDD 遵循三个步骤：定义行为、构建数据集与评估器，以及运行基准实验。第一步涉及为智能体创建产品需求文档（PRD），列出回答问题或采取行动等具体行为。每个行为都需要一个简短的规范，其明确程度应足以被评定为通过或失败。

第二步是构建测试用例（即“样本”）数据集。该博客强调，最佳输入来自于实际的智能体运行，因为用户表达请求的方式往往出人意料。如果无法获取真实数据，团队可以使用 LLM 来合成样本。数据集准备好后，开发者便可以编写评估器。这可以是针对确定性操作的基于代码的检查（例如验证智能体调用了哪个工具），也可以是用于主观输出的“LLM 作为裁判”的方法。对于修改环境的智能体（如编码智能体），博客重点介绍了 Harbor，这是一个在沙盒中运行智能体并对最终状态进行评分的开源框架，类似于 Terminal-Bench 等行业基准。

最后一步是运行基准实验。这一步会将智能体当前的性能结果与数据集进行记录对比。随后对智能体进行的更改将作为新实验运行，并与基准进行并行比较。博客通过一个文档智能体示例说明了这一点：添加新的 create_ticket 工具最初破坏了现有的行为，因为工具描述过于宽泛。通过分析追踪记录，开发者缩小了描述范围，重新运行了评估，并在所有样本中取得了通过的分数。

为什么这对构建生产级智能体的小型团队至关重要

对于将 AI 智能体集成到工作流中的小型公司而言，最大的风险是静默回归。如果没有 EDD，一个修复了某个问题的提示词微调可能会暗中破坏另一个问题，而在客户抱怨之前你根本不会察觉。这种方法论提供了充满信心的发布所需的客观证据。它将重点从“它在这个特定案例中起作用吗？”转移到了“它在这组具有代表性的案例中都能起作用吗？”对于构建者来说，这意味着减少猜测时间，增加利用数据迭代的时间。它还标准化了成功的定义，使新团队成员更容易理解对于你的特定智能体而言“好”的标准是什么。

本周可以做什么

1. 确定你的智能体应该处理的一个具体行为，并写一段简短的规范，确切定义成功执行的外观。
2. 为该行为收集或创建 10-20 个测试样本，确保包含边界情况以及至少几个不应触发新操作的行为样本。
3. 实现一个简单的基于代码的评估器，检查智能体是否针对这些样本调用了正确的工具或产生了期望的输出格式，并运行基准测试以记录当前成功率。

来源

• What Is Eval-Driven Development? How to Improve AI Agents — LangChain Blog