RSIBench-Data: AI Agent会像研究员一样开展数据研究吗？
RSIBench-Data系统评估 LLM Agent 能否胜任 Agentic Post-Training 中最关键、也最依赖人工经验的数据合成工作。我们在六项基准任务上评估了四个前沿 Agent，测试它们是否具备递归自我改进（RSI）所需的、以数据为核心的研究能力。
研究动机
近年来，Agent benchmark 的任务难度、交互长度与环境复杂度持续提升，相关评测体系也逐渐形成两条主要路线。
一条路线，是持续构建难度更高、交互链路更长、更加贴近真实工作的任务，例如复杂软件工程、浏览器操作、终端任务，以及需要数十步乃至上百步交互的环境。这类 benchmark 具有重要价值，但通常也需要投入大量人力。
另一条路线，则不再以人工构建新任务为核心，而是将模型训练本身转化为 Agent 的实验环境。Agent 在获得基础模型与限定资源后，通过生成数据、调整训练策略和运行评测来提升目标模型。这类工作更接近自动研究，也更容易发展为可持续运行的平台。
我们认为，**后一条路线具备更大的平台化潜力。**因为训练、推理和评测都可以服务化，外部的 researcher harness 通过 API 接进来做实验；它可以像 Tinker 一样被持续调用，也可以逐渐扩展到 data、architecture、algorithm，甚至多个方向的联合优化。
然而，在进一步分析现有 automated post-training benchmark 后，我们发现其中仍存在两个值得关注的问题。
第一，**很多本来可以 Everything as a Service 的环节，并没有被服务化。**Agent 需要自己处理训练脚本、部署、推理接口、评测环境和各种工程细节。大量 token、时间与 FLOPs 消耗在 infra 上，也留下了不少可以被 hack 的空间。
第二，当数据、训练、推理、评测和系统实现均可同时修改时，即使最终分数有所提高，也很难准确判断提升的来源。
它是真的发现了更好的训练数据策略？
还是改了学习率？修好了一个部署 bug？换了推理参数？甚至不小心利用了评测漏洞？
最终测量到的可能是“端到端自动后训练系统”的综合工程能力，而非 Agent 作为研究者的独立能力。
基于这一判断，RSIBench-Data 确立了明确的设计原则：固定所有可控变量，服务化所有标准环节，将评测重点集中在数据研究决策本身。
架构设计
RSI 往往被描述为模型持续修改自身代码、训练方法乃至后续版本的完整自我改进过程。
如果将这一宏观目标拆解，其基础环节可以被定义为一组清晰的研究步骤：
- 发现当前模型在哪里失败；
- 对失败原因提出一个假设；
- 设计一批可能解决问题的训练经验；
- 训练并观察 checkpoint 的变化；
- 根据新证据继续修改策略。
这与人类研究者在模型研发中的基本工作流程高度一致。
**其中的核心难点并非调用一次训练 API，而是将模型失败证据稳定地转化为有效改进。**Agent 需要判断问题来自知识、推理、工具调用、数据格式还是行为分布，并设计与目标能力对齐的数据；当实验失败时，它还需要修正假设，而非退化为简单的规则化数据生成；当强 checkpoint 出现后，它也需要具备明确的保留、停止与回滚策略。
RSIBench-Data 测量的，就是 RSI 中这段 data-centric post-training research loop。
它并不声称已经实现完整的递归自我改进，也不要求 researcher agent 和 target model 必须是同一个模型。我们更希望先把 RSI 拆成一个可测量、可复现、可审计的问题：一个 Agent 能否基于反馈，持续进化自己的数据研究策略？
为回答这一问题，RSIBench-Data 对训练、推理、评测与 Agent 决策边界进行了尽可能严格的物理隔离。
对于每一组实验，RSIBench-Data 固定以下要素：
- 基础模型；
- LoRA SFT 训练后端与可用配置；
- checkpoint serving path；
- Agent harness 的运行边界；
- Harbor 与 E2B 组成的沙箱评测；
- 任务子集、评测指标与重跑协议；
- 时间预算和训练预算。
主实验统一使用 Qwen/Qwen3.5-35B-A3B-Base 作为 target model，通过共享的 Tinker SFT 服务训练 LoRA checkpoint。每次运行有 16 小时名义时间预算和 500 美元 Tinker 预算。
Agent 获得公共 seed tasks、工具与环境说明、可用的基础模型诊断，以及明确的预算合同。它可以编写数据生成程序、调用许可范围内的数据源、构造任务和轨迹、进行过滤与验证，并决定难度比例、课程结构和后续实验方向。
但 Agent 无法重写正式评分器、替换 serving stack，或通过修改基础设施改变 benchmark 的原始评测目标。
每轮训练完成后，Agent 会得到 selection evaluation 的结果和轨迹，再决定是继续探索、回滚旧策略，还是选择某个 checkpoint。最终选定的模型，会在新的沙箱环境中独立执行 official evaluation。
在此基础上，当两个 Agent 在同一任务上出现明显差异时，研究者可以更可靠地将差异归因于：它们如何理解失败，以及如何设计训练数据。
实验设计
RSIBench-Data在六项基准任务上评估了四个前沿 Agent。这些基准分别覆盖软件工程、长程终端操作、科学问答和数学推理，也对应完全不同的数据研究问题：代码任务需要仓库级、可执行的监督；终端任务要求长程工具轨迹和 verifier；数学与科学任务则更依赖难度控制、答案验证与推理数据设计。
因此，RSIBench-Data 关注的不仅是最终分数，更是一条条完整的“研究轨迹”——Agent 在实验过程中做了什么：第一轮提出了什么假设？看到失败后改了什么？哪一次出现了真正的提升？它为什么继续搜索？最终 checkpoint 是最后一次实验，还是历史上最好的一次？
实验结果
Agent 已具备初步发现能力，但研究稳定性仍然有限
24 组 Agent–Benchmark 设置中，有 14 组在后续实验中超过了自己的第一次有效尝试，占 58.33%。
这一结果表明，当前前沿 Agent 已经能够读取 checkpoint 反馈、调整数据策略，并在部分任务上获得优于首次尝试的候选模型。
但另一组结果更值得关注。 在 23 条达到过峰值后仍然继续搜索的轨迹中：
- 18 条最终尝试低于历史最好结果；
- 另外 5 条只是重新回到峰值；
- 没有一条在峰值之后持续单调地刷新上限。 也就是说，78.26% 的继续搜索最终以低于历史峰值的候选结束。
这一结果并不意味着 Agent 必然会丢失已经获得的改进。RSIBench-Data 要求保留并选择历史 checkpoint，因此 Agent 仍可通过合理的选择策略保存早期发现。
更深层次的结论是，当前 Agent 可以做出有用的数据研究发现，但还不能稳定地把新反馈转化成下一次提升。
不是多跑几轮，就能更会研究
一旦 Agent 跑通了研究闭环，人们很容易产生一个直觉：只要给它更多时间、更多训练预算，结果总会更好。
但 RSIBench-Data 的实验显示，事情并没有这么简单。
例如在 Terminal-Bench 2.0 上，Claude Code Sonnet-5 使用约 8.87 小时、花费 156.93 美元，最终官方成绩为 5.62%；Codex gpt-5.6-sol 使用约 9.56 小时、花费 69.07 美元，官方成绩达到 20.22%。
但是这并不意味着某一个 Agent 在所有任务上都很突出，在测试中，6 个 benchmark 没有任何一个 researcher agent 全面占优，甚至三个 SWE 类任务的最好结果也分别来自不同 Agent。
Reasoning effort 也并非单纯增加推理时长。论文中的诊断实验显示，提高 effort 会改变第一轮候选、搜索深度、数据规模和预算分配方式，换言之，它改变的是完整的研究策略。
如果未来要构建真正可用的 AutoResearch 系统，成本—性能前沿、停止策略和研究资源分配，会与最终分数同样重要。
三条代表性研究轨迹：从过程理解 Agent 的研究能力
我们进一步挑出了三条具有代表性的研究轨迹。它们不是简单的“成功案例”，而是展示了当前 Agent 已经初步具备的三类研究行为。
AIME 2026：连试八次没有突破，Agent 换了研究路线
Claude Code Sonnet-5 在 AIME 2026 上前 8 次有效尝试始终没有超过 15%。
如果只是看前半段，这几乎是一条失败轨迹：Agent 调整数据难度、数量和配比，但这些局部修改并没有改变模型真正学到的东西。
第 9 次尝试，它切换到了一个 qualitatively different 的策略，selection score 从 7.5% 直接跳到 55%；第 10 次达到 55.83%。
这一案例的关键并非单次分数的大幅提升，而是 Agent 最终识别出：继续对原有 recipe 进行局部调整无法改变有效数据策略，需要重新判断目标模型的能力缺口。
SWE-bench Pro：会写 patch，不等于会交付代码
Codex gpt-5.6-sol 在 SWE-bench Pro 上逐步改进了候选结果。轨迹中一个关键变化，是从较浅的合成修复数据，转向更贴近真实执行与提交行为的轨迹。
对于 coding agent，监督数据不只是“输入一个 issue，输出一段 patch”。模型最终需要浏览仓库、调用工具、修改文件、运行测试并提交结果。数据的粒度、工具消息格式，以及动作是否来自真实成功执行，都会影响训练后的行为。
这一案例表明：数据内容正确，并不意味着监督形式与目标行为已经对齐。
Terminal-Bench 2.0：恢复一次失败实验，只是研究的起点
Codex gpt-5.6-sol 的第一次 Terminal-Bench 训练没有产出可用候选。
Agent 随后恢复失败、缩小监督范围，第二个有效 checkpoint 达到 15.73% selection score，并最终取得 20.22% official score，而基础模型参考成绩只有 1.12%。
但在后续尝试中，Agent 又加入了更偏向“停止行为”的修改，结果回退。 由于 Agent 保留并选择了更早的历史最佳 checkpoint，后续回退并未覆盖此前获得的更优结果。
这条轨迹把三种能力放在了一起：恢复失败训练、通过更聚焦的数据推进性能，以及在后续实验退步时不覆盖已有发现。
综合这些案例，当前表现较强的数据研究轨迹通常包含四个共同点：
- Diagnose：找到真正的能力缺口，而不是不断调整表面参数；
- Validate：把可执行、可判定的验证信号嵌入数据构建；
- Align：让训练监督与模型最终需要完成的行为对齐；
- Preserve：显式保留历史最佳 checkpoint，并知道何时停止或回滚。
早期 RSI 探索实验：让 Kimi K2.6 研究怎么训练 Kimi K2.6
在主实验里，researcher agent 和 target model 是不同模型。
为进一步接近同家族 RSI 设置，研究团队额外开展了一项探索性实验：使用 Kimi K2.6 驱动 Claude Code harness 作为 researcher，目标模型同样为 instruction-tuned moonshotai/Kimi-K2.6。
这一设置可以概括为：让 Kimi 研究如何训练 Kimi。
评测使用固定的 100 个 SWE-bench Pro 样本。Agent 一共进行了 7 次 Tinker LoRA 尝试。
这条轨迹呈现了较为完整的迭代研究过程。
第一次，Agent 转换了 1500 条软件工程轨迹，但训练中途停止，没有完成评测。
第二次，缩短训练后得到 8%，随后发现转换器遗漏了 tool-result 消息，训练数据格式本身就是坏的。
接下来，它修复工具消息配对，改用 300 条 SWE-Gym 轨迹，调整轨迹长度、学习率和 LoRA 配置，候选分数从 10% 提高到 21%。
之后它尝试用少量成功 rollout 做 imitation，结果因为覆盖过窄回落到 16%。为了验证“训练是不是本身就在破坏模型”，它又构造了一个接近 no-op 的 adapter，得到 22%，并把它选为最终 checkpoint。最后一次重新整理标准工具调用格式，结果为 21%。
从研究行为看，Kimi 确实在学习：它发现了数据格式问题，修复了 tool pairing，切换了数据来源，也在根据结果调整训练配置。
但从模型能力看，最好的候选只有 22%，而未训练的 Kimi K2.6 参考成绩是 33%。我们认为这是因为instruct model本身就比较强大（主实验我们是训练的qwen base model），所以一些训练反而容易掉点，另一方面也说明rsi目前还不够强。
因此，这一实验尚不能被视为模型成功实现自我进化。
更准确的结论是：实验已经呈现出由同家族模型驱动的数据研究闭环，但这一闭环尚未产生净自我改进。
这也是 RSI 研究很容易被忽略的一点：闭环跑起来，不等于递归改进已经成立；Agent 会修改自己的训练 pipeline，也不等于它找到了一个优于原模型的数据分布。
下一步：构建完整的 AutoResearch 实验平台
RSIBench-Data 是整个 RSIBench 方向的第一步。Evolvent AI 团队首先从投入产出比较高、也更容易服务化的 data 场景开始，验证受控 AutoResearch 闭环。
下一阶段，团队将搭建完整的 AutoResearch 实验平台，统一提供训练、模型服务、沙箱执行和评测能力。用户接入自己的模型或 researcher harness 后，即可快速实验不同研究环节：
- Data：数据合成、过滤、配比与 curriculum；
- Algorithm：训练目标、优化算法与 post-training 方法；
- Architecture：模型结构与模块设计；
- Agent / Harness：实验规划、工具使用与 checkpoint 选择。
这些环节既可以单独优化，也可以进行联合搜索。RSIBench-Data 对应其中的 Data 模块，后续将逐步扩展为支持 data、algorithm、architecture 等多变量实验的完整 AutoResearch 平台。
Evolvent AI 团队欢迎研究者试用项目、提交 issue 并开展复现实验，也欢迎模型厂商和 Researcher Agent 团队接入自身系统。对于希望系统评估 Agent 数据研究能力，或共同探索 AutoResearch 平台能力的团队，Evolvent AI 可提供定制化合作测试与实验支持。