终端Agent训练数据构造的难题，被人大高瓴开源的新框架解决了！

智猩猩AI整理

论文作者投稿

Agent 训练正遭遇新的数据瓶颈。

近年来，研究者们通过搭建自动化数据 pipeline，大规模构造 Agent 训练任务。以终端智能体为例，许多工作通过持续扩展数据规模，推动模型在 Terminal-Bench 2.0 等 Benchmark 上取得更好的表现。

然而，当任务数量从数百条扩展到上万甚至更大规模，有问题接踵而至：

Scaling 更多任务，就一定能带来更强的 Agent 吗？

一个自动生成的任务，该如何判断它是否真的具有训练价值？

自动化合成的任务中至少存在两类典型的低价值模式：

1、过于简单的任务：对当前 Agent 或蒸馏对象几乎没有挑战，难以提供新的学习信号；

2、过于困难或存在缺陷的任务：即使是能力较强的 Agent 也难以探索出有效解法，甚至由于任务本身存在问题而根本不可解。

这意味着，Agent 数据构造面临的核心问题正在从“如何生成更多任务”，进一步转向“如何发现真正处于模型学习边界上的任务”。

要判断一个任务是否真正具有训练价值，仅靠生成阶段预设的规则是不够的。一个更直接的思路是：让模型真正去做题，再用它的求解表现反向指导数据构造。

这种“通过竞争与反馈寻找能力边界”的思想并不陌生。早期的 GAN 通过生成器与判别器间的竞争不断改进生成结果，对抗训练则利用模型容易失败的样本提升鲁棒性。它们虽然形式不同，但都体现了一个共同思想：利用模型反馈暴露当前系统的能力边界，并围绕这一边界持续优化。

随着 Agent 的发展，这种思想也开始融入训练数据构造。近期的一些自动化数据工作，如AutoData，开始让 Agent 自己参与数据的发现、筛选和优化。相比提前用固定规则定义“什么是好数据”，模型在真实任务中的表现，可以提供一种更加直接的判断依据。

对于终端任务而言，中国人民大学高瓴人工智能学院的研究者们进一步提出问题：

能否让 Solver Agent 不再只在任务生成结束后负责“做题”，而是让它直接参与任务构造，用真实求解反馈帮助不断调整任务？

针对该问题，研究者们提出了CalibForge，一个面向终端智能体训练任务校准的框架。CalibForge 的核心思想是：将 Solver 从任务完成后的评估者，转变为任务构造过程中的反馈来源，利用 Solver 的真实求解表现持续校准任务，使其逐渐进入更具有训练价值的可学习区间。

实验结果表明，这种校准能够带来显著收益。在 Terminal-Bench 2.0 上，研究团队训练得到的两个模型分别达到 32.58% 和 47.57%，相比最强 baseline 分别提升 6.36 和 6.75 个百分点；迁移到软件工程任务后，在 SWE-bench Pro 和 Doc2Repo 上最高分别提升 27.68 和 30.04 个百分点。更重要的是，在对抗式校准过程中，初始生成的任务中仅有 19% 达到预设目标，而经过 Solver 反馈驱动的修改与重新探测后，最终 96% 的候选任务达到目标状态。

01

CalibForge：从任务验证

到任务校准

传统的终端任务构造通常采用“生成—验证”流程：先生成任务描述、执行环境和测试，再检查任务能否正常运行、答案能否被验证。只要通过这些检查，任务就可以进入训练数据。

但“任务能用”并不等于“任务值得学”。一个任务即使完全正确，也可能对当前 Agent 太简单，几乎学不到新东西；也可能过于困难，让 Agent 根本无法找到有效解法。

CalibForge 因此在传统验证流程外，引入了Solver 的真实求解反馈：让 Solver 真正进入环境完成任务，再根据它的成功或失败、求解过程和交互轨迹，判断任务是否合适，并进一步修改任务。

整个过程由两个角色配合完成：

Authoring Agent：负责生成和修改任务，将初始线索扩展为完整的终端任务，包括任务指令、执行环境和验证测试。

Solver Agent：负责实际求解任务，并返回成功/失败结果、执行过程和完整轨迹，为后续任务修改提供依据。

于是，原本一次性的题目合成流程

生成任务 → 验证任务

变成了一个闭环：

生成任务 → Solver 求解 → 分析反馈 → 修改任务 → 再次求解

通过这样的反复校准，CalibForge 不只是筛选“能够运行”的任务，而是让任务逐渐进入相对于当前 Solver 既有挑战、又有机会学会的可学习区间。

02

候选任务合成：从线索

到可执行任务

Authoring Agent 从一个初始 clue 出发，逐步探索出一个真实、完整的工程问题。

首先，Authoring Agent 会利用搜索工具查找相关技术资料，并围绕线索探索不同的任务方向。例如，一个与数据处理有关的线索，可能进一步发展成文件恢复、数据库修复或格式解析等任务。

面对多个候选方向，Authoring Agent 会重点判断三个问题：这个问题是否真实、是否足够独特，以及能否真正落地为一个终端任务。

确定方向后，Authoring Agent 会进入隔离的 sandbox 环境进行实际检查，例如确认依赖能否安装、工具能否运行、所需资源能否访问，以及初始环境是否符合预期。只有工程上真正可行的方向，才会被进一步构造成完整任务。

任务生成完成后，CalibForge 还会进行两阶段验证：

第一阶段：结构验证。检查 Docker 环境能否正常构建、必要文件和依赖是否完整，以及测试和验证逻辑是否正确。

第二阶段：自求解验证。Authoring Agent 亲自在隔离环境中尝试解决任务，并通过测试结果确认任务确实存在可行的解决路径。

只有同时通过这两阶段验证的任务，才会进入后续的Adversarial Solver Calibration阶段。

03

对抗式 Solver 校准：

让任务进入可学习区间

经过前面的生成与验证，CalibForge 已经得到了一批环境有效、且存在可行解法的候选任务。但任务“能做”，并不意味着它的难度恰好适合当前 Agent 学习。

因此，我们进一步引入AdversarialSolver Calibration：让不同能力的 Solver 真正进入环境完成任务，用它们的实际求解表现来判断和调整任务难度。

这个想法非常直观：

• 弱 Solver 也能完成：任务可能太简单，难以提供新的学习信号；

• 强 Solver 都无法完成：任务可能太难，或者仍然存在设计问题；

• 强 Solver 能完成、弱 Solver 无法完成：任务恰好落在两者的能力差距之间，更可能具有训练价值。

换句话说，CalibForge 真正希望寻找的，不是单纯“能够被解决”的任务，而是位于当前 Agent 能力边界附近的任务。

基于这一思路，我们设计了两种 Solver Calibration 策略：

Multi-Solver Calibration：让多个 Solver 尝试同一个任务，根据它们之间的成功与失败差异判断任务所处的难度位置，并利用反馈进一步调整任务。

Contrastive Solver Calibration：进一步明确设定“Stronger Solver 成功、Weaker Solver 失败”的目标关系，主动将任务校准到强弱 Solver 之间的能力区间。

在这一过程中，Solver 不再只是任务生成完成后的“考官”，它的成功、失败和完整求解轨迹都会成为 Authoring Agent 修改任务的依据。

最终，CalibForge 要回答的问题也从：

“这道题能不能被解决？”

进一步变成：

“这道题对于当前 Agent 来说，是否恰好值得学习？”

04

校准后的任务，是否更适合训练

Terminal Agent ？

一、实验效果分析

CalibForge 最终构建了5,431 个经过校准的终端训练任务。为公平比较不同训练数据的效果，实验统一使用 DeepSeek-V4-Pro 蒸馏成功轨迹，并采用相同的 Agent scaffold 和监督微调设置。

基于 CalibForge 数据训练得到的：CalibForge-30B-A3B、CalibForge-35B-A3B，在 Terminal-Bench 2.0 上分别达到32.58%和47.57%，相较于对应基座模型，两者分别提升24.71和8.47分。

我们进一步发现，这种收益并不局限于终端任务，在 SWE-bench Pro 和 Doc2Repo 等软件工程任务中，CalibForge 训练出的模型同样取得提升，说明这批合成的数据能够迁移到更广泛的软件工程场景：

CalibForge 的目标不是构造更多任务，而是构造更有训练价值的任务。

二、关键不是增加 Solver，而是利用 Solver 间的关系

在验证 CalibForge 的效果时，一个问题是：效果的提升是否只来自引入的 Solver 反馈？

因此，我们在固定相同任务数量和训练流程下，对比了四种设置：

• No Solver：不使用额外 Solver 反馈；

• Single Solver：利用单个 Solver 的成功/失败结果反馈；

• Multi-Solver Calibration：利用多个 Solver 之间的表现差异；

• Contrastive Solver Calibration：利用 Stronger Solver 与 Weaker Solver 间的目标关系。

消融实验效果如下：

相比普通 Single-Solver Feedback，后两种 calibration 策略带来更明显的提升。我们发现：Solver 的价值并不只是提供更多一次求解结果，而是提供一组相对关系，它回答的核心问题应该从“任务能否被解决？”，进化到“这个任务对于当前 Solver 能力而言，处于什么位置？”。Multi-Solver 和 Contrastive Solver的设置并不是简单增加 Solver 数量，而是利用 Solver 间的相对求解关系，为任务构造提供更加明确的校准目标。

三、校准引导下的持续优化流程

若候选任务没有达到目标关系，CalibForge不会盲目丢弃，而是基于反馈不断修正。在 Contrastive Solver Calibration 中，所有候选任务在进入校准前已经通过结构验证和自求解，但首次 Solver 探测时，仅有19%满足我们设定的目标关系。经过 Solver 反馈驱动的任务修订和重新探测后，最终96%的候选任务达到目标状态。

这说明，Solver 反馈的价值并不只是判断任务是否保留，更重要的是帮助 Authoring Agent 理解任务当前的问题，并指导任务进一步优化。

05

总结：从“任务生成”到

“任务校准”

训练数据已成为限制Agent发展的关键因素。过去，任务构造的重点更多集中于：任务是否能够生成足够多任务、是否能够构造真实环境、是否能够通过自动化测试验证结果。

然而，对 Agent 训练而言，一个任务真正的价值并不只在于它是否能够执行，而在于它是否能够在求解过程中提供有效反馈，并推动模型学习新的能力。我们提出 CalibForge 的初衷，是想将 Solver 从任务完成后的评测工具，转变为任务构造阶段的反馈来源。通过观察 Solver 在任务中的成功、失败以及交互过程，让题目合成系统不断调整候选任务，将“可执行任务”进一步转变为“具有训练价值的任务”。

从“验证任务是否能够运行”，到“校准任务是否值得学习”，我们希望探索一种面向下一代 Agent 训练数据构造的新范式。

关注+星标，获取AI前沿进展与优质开源项目