给 Agent 做评测，最容易的做法是收集一组提示词，再用模型裁判打分。问题是，真实 Agent 从来不只回答问题：它读取数据库、调用服务、修改文件、跨多步积累状态，最后留下可以被外部系统验证的结果。脱离这些环境，分数很可能测到的是语言表现，而不是完成工作的能力。
LangChain 总结了一套内部使用的任务生成流程。核心不是让模型批量“编题”，而是把任务拆成两个阶段：先用自然语言写清任务世界和验收标准，再把规范编译成可以运行的环境、输入与测试脚本。
#一个评测任务到底包含什么
原文给出的定义很具体：一个任务由输入、环境和测试脚本 组成。Agent 接收输入，在环境中执行，测试脚本根据最终状态评分；一组任务才构成数据集或基准。
这一区分非常重要。让 Agent “找出缺失的客户记录”只是输入；Salesforce、Notion 或内部数据库的表结构、账户权限和初始数据属于环境；哪些记录应该被补齐、是否允许改动其他字段，则要写进可执行的评分规则。
如果只保留输入和参考答案，Agent 可以绕过真实工作流。若评分只看最终文本，它甚至不必真正修改系统。高质量评测必须让正确行为在环境状态中留下证据，也要让错误副作用被检查出来。
#先写规范，再生成任务
LangChain 把生成流程分成两步。
第一步是生成任务规范。规范是一个可审查、可版本控制的 Markdown 文件，说明任务输入、环境结构和评分方法。人可以先在这里判断任务是否代表真实需求，而不必直接阅读大量模拟数据与环境代码。
第二步是 Spec2Task：让 Coding Agent 根据规范创建可执行任务，生成数据、搭建环境并实现测试。规范把“这个任务应该是什么”与“怎样把它运行起来”分离，因此前者保留更多人类判断，后者才适合规模化自动化。
这种分层也缩小了审查面。团队可以先批准任务意图和难度，再让 Agent 并行构建实现；如果实现偏离，问题可以追溯到规范或编译过程，而不是混在一段不可解释的生成脚本里。
#世界规范保存跨任务知识
单个任务规范之外，还需要一份世界规范。它保存整个数据集共享的知识，例如服务 API、数据库 schema、常见用户请求、凭证边界、数据生成脚本以及评分函数。
世界规范不应该包含某道题的答案，而应回答：这个业务世界有哪些对象，它们如何关联，哪些操作真实可用，怎样构造不会泄题的合成数据。
原文建议不要试图一次写完世界规范。更可靠的方法是与 Coding Agent 一起完成最初两三个任务，让它扫描仓库、分析真实轨迹、列出服务与数据依赖，再把反复出现的知识提炼进世界规范。随后用新任务验证它是否足够完整。
这是一种从实例反推基础设施的做法。世界规范的价值不在于文档漂亮，而在于它能否让下一道任务少依赖隐含知识，同时不把第一道题的偶然细节固化成通用规则。
#生产轨迹是题源，不是现成答案
真实轨迹能揭示用户到底在要求什么，也能暴露 Agent 经常失败的模式。但轨迹不能直接复制成评测：其中可能含有隐私、实时依赖、不可复现的外部状态，以及只有当时才成立的偶然条件。
因此，构建管线要先把轨迹聚类，识别稳定的任务类型，再决定哪些服务应该模拟、哪些可以调用真实 API、需要哪些凭证、如何生成有代表性的关系数据。任务必须保留真实难点，同时移除泄题字段和不可控依赖。
环境生成后，还要让真实 Agent 反复运行并阅读轨迹。这样才能发现环境设计中的漏洞，例如表格里出现“答案占位符”、评分器只检查表面字段，或强模型通过奖励捷径拿分。
#难度也需要校准
Agent 往往会生成过于简单的任务，因为简单任务更容易证明环境能运行。可一个全部被轻量模型解决的基准，无法指导模型和 Harness 的迭代。
LangChain 的做法是让不同能力层级的模型执行同一任务。如果弱模型与强模型都失败，任务可能坏了或约束不清；如果全部轻松通过，题目缺少区分度；只有失败轨迹与能力差异符合预期，难度才算经过校准。
这里的校准不是故意把题写得晦涩，而是加入真实世界本就存在的缺失数据、跨表关系、噪声和权限限制，同时保持验收条件明确。
#为什么这是一条持续管线
产品、用户行为和基础模型都在变化。今天代表生产的任务，几个月后可能已经过时；模型能力提升后，原有题集也会饱和。因此环境不能作为一次性项目，而要从新轨迹中持续发现任务类型、更新世界规范、构建任务、回放验证并进入人工审查。
真正可用的评测系统最终像一条数据与软件共同演进的生产线：生产轨迹提供问题分布，规范保存人类意图，Agent 承担环境实现，测试脚本给出可重复证据。只有四者同时存在，评测分数才有资格影响模型、提示词、工具和工作流的决策。