LangChain 如何构建 Agent 环境与评测任务

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

术语表：

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

环境：智能体运行的地方

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

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

数据集：任务的集合，也称为基准

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

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

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

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

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

创建基准

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

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

我们花了很多时间思考如何创建更好的评估，而能够更可靠、更高效地创建有代表性的基准是其中的关键部分。在过去几个月里，我们一直在迭代一个有助于实现这一目标的流程。

理想的最终状态是什么？

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

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

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

创建任务的流水线

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

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

拥有这个 spec 概念的好处在于它分离了：

弄清楚每个任务应该是什么样子
构建任务

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

Spec 是人与 agent 协作和编辑的良好媒介。人类审查 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 + 指定模式的脚本。

端到端流程

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

仍然需要人工判断的地方

评估工程技能为构建智能体环境提供了一个通用框架，但这个过程并非完全自主。智能体仍然需要在两个方面接受人工指导。

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

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

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

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

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

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

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

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

‍