LangChain 分享如何构建 Agent 评测环境与任务的两步流水线

TLDR:  这是一份关于我们如何创建合成智能体环境和任务的实用指南。到最后，我们会得到一个两步式流水线。第一步接收轨迹、代码和/或人工输入，构建一份详细的规格说明。第二步接收该规格说明，为任务创建评估任务和环境。为此，我们创建了一份“世界规格”来捕获共享知识、脚本和重要定义。这个过程非常迭代。我们将流程打包进了一个更新后的评估工程技能，让每个团队都能自己掌控这套流程。

术语表：

Agent（智能体）：使用 LLM 来决定应用程序控制流的系统

Environment（环境）：智能体运行的地方

Rubric（评分标准）：用于评判智能体运行输出的一组标准

Task（任务）：一个输入、一个环境和一个测试脚本。智能体在环境中运行这些指令以产生输出，输出由测试脚本评分

Dataset（数据集）：任务的集合，也称为基准测试

Evaluation（评估）：在数据集上运行智能体以获得分数

Harbor：用于定义任务和数据集并运行评估的框架。

Traces（轨迹）：关于智能体输入和运行路径的详细运行信息

Task Spec（任务规格）：关于任务（输入、环境、测试脚本）的详细自然语言描述，可用于创建任务

World Spec（世界规格）：项目特定的信息、脚本、辅助函数或其他工件，可用于帮助创建规格或将规格转化为任务

创建基准测试

要可靠地改进智能体，你需要一个良好的基准测试来运行你的智能体。这有助于识别回归、发现改进领域，并总体上确保你能在真实指标的支撑下迭代你的智能体。

构建一个好的基准测试很难。基准测试中的每个任务都需要有代表性的输入、与现实世界高度一致的环境，以及用于给结果评分的对齐评分标准。创建一个任务就需要大量时间、精力和人工对齐，更不用说整个数据集了。

我们在如何创建更好的评估上投入了大量思考，而能够更可靠、更高效地创建有代表性的基准测试是其中的关键部分。在过去几个月里，我们一直在迭代一套流程来帮助实现这一点。

理想的最终状态是什么？

我们努力追求的最终状态是一个由高质量、经过审核的任务组成的数据集。 这些任务随后可用于评估、爬坡优化或后训练我们的智能体。

我们在 LangChain 内部创建的任务示例包括：

• 用于 GTM 工程的任务，测试公司研究以及在客户表中数据缺失和条目不全的情况下寻找个人等能力
• 用于提示优化的任务，其中对智能体进行评估
• 使用真实已合并 PR 的数据进行代码审查的任务
• 用于轨迹挖掘的任务，其中海量轨迹数据语料中存在少量问题

创建任务的流水线

为了生成大量此类任务，我们发现构建一条流水线来产出这些任务是最有效的。我们发现创建这条流水线的核心概念是“规格”。

规格是一个 markdown 文件，用自然语言描述任务（输入、环境、评分器）的样子。根据你试图构建的数据集，它可能有不同的章节或所需信息。

拥有 spec 这个概念的好处在于它把以下两件事分开了：

1. 弄清楚每个任务应该长什么样
2. 构建一个任务

第一步——“弄清楚任务应该长什么样”——可以通过多种方式完成，并且通常需要人工反复迭代，以对齐团队和用户真正关心的事情。第二步——“构建任务”——理想情况下可以更多地由 agent 自动化完成。这种分离让你可以创建许多不同的 spec，把人工审核流程集中在那里，然后并行地构建它们。

Spec 是进行人机协作与编辑的良好媒介。 对人类来说，审阅一份 markdown spec 要比审阅任务的原始代码和数据容易得多。 编辑可以像代码一样进行版本管理和追踪，并在团队之间共享。

总体而言，理想的最终状态是一条由两个步骤组成的流水线：

• 一个 spec 生成步骤
• 一个 Spec2Task 创建步骤

汇集世界知识

要把上述任一步骤做好，都需要收集关于你试图创建的一般数据集的特定信息。我们把这部分信息称为“世界知识”****，它存在于“世界 spec”中。

这些信息并非针对单个任务——如果是的话，它就会存在于任务 spec 中。相反，它是数据集中所有潜在任务（即“世界”）的通用知识。

这些知识可以有不同格式（例如 markdown 与 python 脚本），并以不同方式使用。 例如：

• During world spec creation
  • 关于哪些信息值得存储的指导，例如数据的大小/形状，以及
  • 用于解析 trace（或其他数据）以提取信息的脚本
• During spec to task creation
  • 关于如何为该任务创建良好评分标准的知识（例如：程序化评分 vs LLM-as-a-judge）
  • 用于生成特定数据以填充环境的脚本

以下是我们内部基准测试中世界知识的一些示例：

• Prompt optimization benchmark:
  • 哪些信息需要提前收集并放入 spec（领域、输入形状、输出类别）
  • 用于生成优质数据集的流程和脚本
  • 适用于所有用例的标准评分函数
• GTM agent benchmark:
  • 需要 mock 的特定后端服务（Salesforce、Notion）的 API 和 schema
  • 从现有 agent trace 中挖掘出的用户常问问题

为什么生成世界 spec 是一个迭代过程

为了生成 spec 或将 spec 转化为任务，你需要一个“世界 spec”。你如何获得这个 spec 并让它有用？

我们发现，获得这个 spec 的最佳方式是和一个编码 agent 携手生成第一个任务，然后让它把在此过程中学到的东西写成一份通用的世界 spec，以供将来使用。事实上，你甚至可能想对前两三个任务都这样做，以确保世界 spec 真正完整。

为了帮助做到这一点，我们创建了一个技能（eval-engineering），它既能帮你创建第一个任务，也能把这一过程泛化为一份世界 spec。

在使用 eval-engineering 技能创建第一个任务并进而构建世界 spec 时，编码 agent 实际上在做什么？

• 用子 agent 扫描代码仓库，找出 agent 所交互的确切 prompt、工具、技能等。
• 对 trace 进行分组，以发现用户要求 agent 做什么的真实世界模式。 这些分组有助于头脑风暴潜在的任务类型
• 梳理运行一个 agent 需要哪些凭证。 该 agent 是否会通过 API 调用任何实时工具，例如网络搜索？ 我们应该模拟这种行为，还是在任务期间实时调用它？
• 编目智能体交互的所有服务及其数据模式。 诸如 SalesForce 或 Gong 之类的系统，包括智能体所交互的表和模式。
• 在数据中寻找关系/层级结构，并根据输入数据的类型规划如何进行合成数据生成的良好方法。

这些知识中有很多是特定于智能体或用户试图为其创建任务的领域的。 创建世界规格的核心部分是迭代地收集用户反馈，这就是为什么在生成第一个任务的同时创建这个世界规格如此有用。

任务规格包含什么

生成单个任务的过程需要写下该任务特有的所有实现细节，但要以整体世界知识为依据。 我们创建的规格通常应涵盖三个部分：

• 智能体环境是什么样的
• 输入应该是什么
• 输出应该如何评分

其中一些可能是可选的，如果它们对所有任务都相同并且可以由“世界规格”涵盖。例如：

• 对于通用问答聊天机器人，环境可能始终相同（只是输入/输出会变化）。在这种情况下，环境信息可以合并到“世界规格”中并在任务之间共享。
• 对于 GTM 研究任务，输入可能保持固定（并在“世界规格”中指定），但环境以及因此用于评分的评分标准将是任务规格的一部分

Spec2Task

Spec-to-task 是接收规格并以 Harbor 格式生成任务的流水线。使用编码智能体最容易做到这一点。你可以向它传递任务规格，将“世界规格”作为包含你关于任务创建的特定知识的技能提供给它，以及 eval-engineering 技能（包含一些关于如何以 Harbor 格式创建任务的指导）。

我们在良好的 Spec2Task 创建中发现的一些经验：

• 让流水线通过使用真实智能体运行任务并阅读轨迹来改进任务。这有助于它们发现环境设计中的任何缺陷，例如过于具体的指令或泄漏的抽象。例如：一条写得不好的表条目写着“Answer placeholder”
• 任务的难度可以通过让流水线使用不同层级的模型（例如：gpt-5.6- Luna 与 gpt-5.6-Sol）运行每个任务来校准。这提供了关于任务对于某一层级的模型来说是否太简单或太难，或者任务是否因为奖励黑客行为而对更强的模型失效的反馈。
• 智能体不擅长知道该用什么方法来生成不同类型的数据。 因此我们给它们总体指导，例如对自由文本数据使用带评分标准的 LLM，对表格数据使用带 sqlite + 指定模式的脚本。

端到端流程

1. Use eval-engineering to create a first task
   1. 确保 eval-engineering 技能已加载
   2. **示例提示词：“**使用 eval-engineering 技能、来自 {LangSmith project} 的轨迹以及 {current repository} 来帮我为 {agent} 创建一个 eval 任务。”
   3. 这将涉及一些来回沟通，会为世界规格创建一个单独的技能（并向用户展示），在达成一致后将创建一个任务
2. Review the world spec skill and make any adjustments necessary
   1. 示例提示词：查看 {world spec - insert name that was created} 技能，告诉我它所说的核心部分，以便我审查它
3. Use “world spec” and eval-engineering to create a second task
   1. 切换线程，以便你能够正确验证世界规格技能。确保世界规格技能和 eval engineering 技能都已加载
   2. **示例提示词：“**使用 {world spec} 技能创建一个新任务。这个任务应该……”
   3. 这将涉及一些来回沟通，并将更新 {world spec} 技能
4. Repeat step 2
   1. **示例提示：“**这个任务中的客户看起来太相似了。 用更大和更小的客户来扩展客户集，让收入、员工总数、发送的邮件数量等各不相同。”
5. 重复步骤 3-4，直到确信为止
6. Scale this process with a coding agent with “world spec” to look at a bunch of traces and generate specs
   1. **示例提示：“**使用 {world spec} 为我创建 10 个新的、不同的任务规格供我审阅。 使用过去 10 天的轨迹来发现我们当前任务中尚未捕捉到的新模式。”
7. Run each of those specs through a coding agent with “world spec” to create a bunch of tasks
   1. **示例提示：“**使用 {world spec} 和 {task spec X} 来创建一个新任务。”

仍然需要人类判断的地方

eval-engineering 技能为构建智能体环境提供了一个通用框架，但这个过程并非完全自主。智能体仍然需要在两个方面获得人类指导。

首先，完善规格通常需要多轮反馈。智能体需要帮助来判断某个规格是否准确反映了真实世界领域、用户行为和任务要求。

其次，智能体倾向于创建过于简单的任务。这有助于验证环境可以正常工作，但一个有用的基准需要涵盖各种难度级别的任务。校准这种难度通常需要多次运行每个任务、审查轨迹，并要求智能体把任务调得更简单或更难。

构建环境是一个持续改进智能体的过程

我们对一个团队能够持续从生产数据构建环境的未来感到无比兴奋。eval-engineering 技能提供了一个加快这一过程的框架。

环境可用于多种类型的智能体优化，例如提示调优、harness 调优或后训练。这些环境还可以回答如下问题：

• 我能否对一部分任务使用更便宜的模型？ 这样能节省多少？
• 我能否简化提示？
• 如果我移除所有现有的 harness 工具，只用 bash 来做所有事情，会怎样？

生产数据和模型变化迅速，因此这些环境需要持续更新，以匹配用户关心的事情以及最新模型能够做到的事情。这就是为什么构建环境必须是一个持续的过程，而这正是我们的 eval-engineering 技能所设计的用途。

如果你对此感兴趣，请联系我们并试用我们的技能。 我们正在积极研究如何让这一过程更简单，以便每个人都能利用自己的数据来拥有并持续改进自己的智能。

‍