Let It Flow: Agentic Crafting on Rock and Roll Building the ROME Model within an Open Agentic Learning Ecosystem

发表时间: 2025-12 · arXiv:2512.24873 (Alibaba iFlow et al.)

文章标题：Let It Flow: Agentic Crafting on Rock and Roll Building the ROME Model within an Open Agentic Learning Ecosystem
作者/机构：ROCK & ROLL & IFLOW & DT 联合团队

A1 主要贡献

近年来，大型语言模型（LLM）推动了软件工程领域的变革。早期的研究主要将LLM视为一次性生成器，但这种模式缺乏迭代推理和环境反馈，不适用于复杂的端到端工作流。因此，研究前沿正转向“智能体制作”（agentic crafting）范式，即LLM通过与环境（如软件仓库、终端）的多轮交互来规划、执行和自我修正。然而，由于缺乏一个可扩展的端到端智能体生态系统，智能体制作的广泛应用仍未实现。现有工作或依赖于有限的人类演示进行监督微调（SFT），或采用难以处理长程任务和稀疏奖励的强化学习（RL）方法。

本文认为，一个有原则的智能体生态系统必须打通数据生成、智能体执行和策略优化的闭环，以适应生产环境中不断变化的分布和日益增长的复杂性。为填补这一空白，本文提出了智能体学习生态系统（Agentic Learning Ecosystem, ALE），一个统一了智能体智能的数据、训练和部署的全栈基础设施。ALE包含三个协同工作的系统组件：

  1. ROLL (Reinforcement Learning Optimization for Large-Scale Learning)：一个可扩展的RL训练框架，支持多环境部署、基于语义块的信用分配和针对长程智能体任务的稳定策略更新。
  2. ROCK (Reinforcement Open Construction Kit)：一个安全的沙箱化智能体执行平台，提供可执行的、与工具绑定的环境，支持交互轨迹的合成、执行和验证。
  3. iFlow CLI：一个智能体框架，用于编排与环境交互的结构化提示套件，并为真实世界工作流打包智能体。

基于ALE，本文孵化了ROME (ROME is Obviously an Agentic ModEl)，一个基于Qwen3-MoE的开源智能体模型。ROME的开发遵循两个步骤：首先，建立了一个精心策划的数据组合工作流，用于合成多源、多语言、工具绑定的轨迹，并通过ROCK的沙箱进行严格的安全、有效性验证。其次，利用数百万条高质量轨迹，迭代优化了一个从持续预训练、SFT到RL的高效、分阶段的训练流水线。为了稳定RL训练，本文提出了交互感知智能体策略优化（Interaction-Perceptive Agentic Policy Optimization, IPA）算法，该算法在语义交互块（semantic interaction chunks）而非单个token上进行信用分配，从而提高了长程任务的训练稳定性。

实证评估表明，ROME在主流智能体基准测试中取得了优异成绩，包括在Terminal-Bench 2.0上达到24.72%，在SWE-bench Verified上达到57.40%的准确率，超越了同等规模的模型，并与超过100B参数的模型相媲美。为了进行更严格的评估，本文引入了Terminal Bench Pro，一个在规模、领域覆盖和污染控制方面得到改进的基准。ROME在该基准上仍然表现出竞争力，并已成功部署于生产环境，证明了ALE的实际有效性。

总而言之，本技术报告提出了一个可靠、经济、安全且用户友好的训练生态系统。本文呼吁社区重新审视优先事项，强调在复杂智能体场景中，核心挑战是训练基础设施、可执行环境和评估协议的协同设计。


图 1: 智能体学习生态系统（ALE）概览及ROME性能。


图 2: (a) 智能体RL生态系统和 (b) 其训练流水线的概览。

A2 方法细节

2. 智能体学习生态系统：罗马非一日建成

2.1 系统概述

ALE系统构成。图2a展示了支持智能体制作的智能体学习生态系统（ALE），它包括训练框架ROLL、环境执行引擎ROCK和智能体框架iFlow CLI。下面简要介绍这三个系统。
- ROLL【Wang et al., 2025c; Lu et al., 2025】是智能体RL训练框架，支持可扩展且高效的RL后训练，具备多环境、多轮采样和策略优化功能。
- ROCK是环境执行引擎，为智能体交互提供安全的沙箱化环境。它支持环境驱动的轨迹生成和验证，用于数据合成和训练期间的闭环执行。
- iFlow CLI是智能体框架，负责管理与环境交互的上下文，并为完成给定工作流提供端到端的智能体制作体验。

三大系统协同工作。这三个系统协同工作以高效支持智能体RL训练：ROLL发出多个环境调用，ROCK在其相应的沙箱内管理和执行这些环境，iFlow CLI则编排LLM响应和环境输出之间的上下文。它们共同构成了一个高效、容错且可扩展的智能体制作基础设施。

2.2 智能体RL训练框架：ROLL

智能体训练流程。图2b描绘了一个智能体RL训练工作流，包含三个关键阶段：rollout（部署）、reward（奖励）和training（训练）。在rollout阶段，智能体LLM通过生成代表动作的token与环境交互。每次动作后，环境返回一个观察。这种交互持续多轮，直到一个回合结束，产生一个交错的动作和观察轨迹。接着，reward阶段为每个轨迹评分并输出一个标量奖励。最后，training阶段使用收集到的轨迹和奖励来更新智能体的权重。更新后的模型会定期同步回rollout阶段，用于下一次训练迭代。

ROLL的架构设计。ROLL将智能体RL后训练分解为专门的工作者角色，包括LLM推理、环境交互、奖励计算和参数更新。这种分离允许每个阶段独立扩展，并实现了分布式执行中各角色间的高效通信。与先前的框架【Sheng et al., 2024; Hu et al., 2024】类似，ROLL【Wang et al., 2025c; Lu et al., 2025】提供了一个Cluster抽象，并采用单一控制器编程模型。控制器协调异构工作者，并处理相应的部署和生命周期管理，这极大地降低了RL研究者的开发复杂性。


图 3: ROLL架构。(a) ROLL在轨迹级别上将LLM生成、环境交互和奖励阶段流水线化。训练也通过一个使用异步比率管理陈旧度的样本缓冲区解耦。(b) ROLL通过在训练突发时收缩rollout资源，并在需求高峰时将其扩展回来，从而复用动态GPU池。

Rollout开销是主要瓶颈。先前工作的实证结果表明，rollout是RL后训练中的主要成本，通常约占端到端开销的70%【He et al., 2025; Gao et al., 2025b】。这个问题在智能体训练中更为突出，其中rollout阶段可能持续数百秒【Lu et al., 2025】。甚至环境交互也可能成为主要瓶颈，据报道消耗超过15%的总训练时间【Gao et al.】。这些观察驱动了对环境执行和LLM生成的专门优化。本节首先解释ROLL如何实现细粒度rollout，使LLM生成能与环境交互在rollout阶段内并发进行。然后描述ROLL的异步训练流水线，它将rollout与训练重叠以减少训练时间同时保持模型精度。最后，讨论训练-rollout复用如何减少资源气泡并提高异步训练中的rollout吞吐量。

细粒度Rollout。ROLL在rollout期间支持异步奖励计算，从而通过将rollout阶段分解为三个阶段：LLM生成、环境交互和奖励计算，来实现细粒度rollout。它不是以一个完整的批次来执行这些阶段，而是在样本级别应用并行性。这种设计允许用户控制每个样本的生命周期，决定每个阶段在何时何地执行。因此，ROLL支持在样本级别粒度上对LLM生成、环境交互和奖励计算进行流水线化执行。

异步训练。如图3a所示，我们在不同设备上解耦了rollout和训练阶段。rollout阶段作为生产者，训练阶段作为消费者。ROLL维护一个样本缓冲区来存储完成的轨迹，并引入异步率（asynchronous ratio）来配置异步训练期间每个样本的陈旧度。异步率是针对每个样本定义的，表示当前策略与生成该样本的初始策略版本之间允许的最大策略版本号差距。

异步训练流程。异步训练流水线迭代重复以下步骤。首先，训练阶段完成上一迭代的梯度计算，然后以阻塞方式从样本缓冲区中获取一个目标批次的轨迹。违反异步率约束的样本将被丢弃以保持模型准确性。其次，rollout阶段被暂停，模型权重从训练工作者同步到rollout工作者。第三，rollout阶段恢复并使用更新后的模型权重生成新轨迹，而训练阶段则在获取的样本上并行执行梯度计算，以最大化资源利用率。我们之前的工作ROLL-Flash【Lu et al., 2025, Part ii: Roll flash – accelerating rlvr and agentic training with asynchrony】进行了广泛的实证研究，表明ROLL的异步训练可以有效地平衡训练准确性和吞吐量。感兴趣的读者可以参考该工作了解详情。

训练-Rollout复用。尽管异步训练架构可以通过流水线重叠训练和rollout，但由于阶段不平衡，气泡是不可避免的。rollout阶段通常比训练耗时更长，训练器可能会因为等待样本缓冲区中收集到足够多的轨迹而停顿。与具有固定资源分配的经典流水线不同，GPU可以根据当前的关​​键路径在阶段之间动态重新分配。当rollout成为瓶颈时，为rollout分配更多GPU可以加速轨迹收集。相反，当训练是瓶颈时，资源应优先用于训练。

气泡问题与长尾延迟。图3说明了当rollout阶段主导端到端迭代时间时的气泡问题。Rollout通常表现出明显的长尾延迟分布：陈旧度界限限制了在途轨迹的数量，虽然大多数轨迹很快完成，但一小部分拖后腿的轨迹会运行到最大上下文长度，导致许多rollout GPU利用率不足。与此同时，训练阶段相对较短，但必须等到rollout产生足够多的有效样本。在rollout和训练之间静态划分GPU的情况下，这种不匹配会产生资源气泡。

动态GPU分区解决气泡问题。我们的关键洞察是，rollout需求是高度时变的：它在权重同步后立即达到峰值，此时会启动许多新轨迹，然后下降到一个低需求谷底，只剩下一小部分拖后腿的轨迹。相比之下，训练阶段以短暂、爆发性的方式消耗资源。基于这一观察，我们引入了时分复用与动态GPU分区，用于rollout和训练之间。如图3b所示，系统首先将所有GPU分配给rollout以快速生成一批样本。一旦样本缓冲区为下一步训练积累了足够的数据，系统会触发一个shrink操作，临时将一个固定的GPU子集重新分配给训练，同时将剩余未完成的轨迹整合到剩余的rollout GPU上。训练完成后，一个expand操作将这些GPU归还给rollout，以应对下一个需求高峰。该策略将训练爆发期与rollout需求低谷期对齐，与静态解耦的异步设计相比，减少了气泡并提高了整体GPU利用率。

2.3 环境执行引擎：ROCK

ROCK系统定义。ROCK是一个可扩展且用户友好的系统，用于管理沙箱环境以完成各种智能体制作应用（例如，旅行计划、GUI助手）。它被设计为框架无关的，提供灵活的API，允许任何RL训练框架以编程方式构建、管理和调度这些环境。

ROCK系统架构与工作流。图4展示了ROCK的架构。ROCK系统围绕客户端-服务器架构设计，以支持多级隔离，保证操作稳定性。从客户端的角度来看，通过一小组原语如reset、step和close，与远程环境交互就像使用本地RL环境一样方便。在底层，ROCK将环境执行与编排解耦，使得大规模并发rollout保持稳定、可调试且资源高效。

ROCK组件。ROCK由三个主要组件构成。首先，服务器层由Admin控制平面管理，作为编排引擎：它配置沙箱环境、执行准入控制，并管理集群范围的资源调度和分配。其次，工作者层由部署在每台机器上的Worker节点组成；它们运行沙箱运行时并管理本地硬件资源。第三，Rocklet是一个轻量级代理，负责协调智能体SDK和沙箱之间的通信，管理出站网络访问，并强制执行出口策略。此外，ROCK提供EnvHub，一个用于环境镜像的集中式注册表，可实现可复现的配置和更快的冷启动。


图 4: ROCK系统架构。

ROCK核心功能。智能体LLM的训练、评估和数据合成提出了多样化的需求，ROCK提供以下功能来满足这些需求。
- 技能1：简化的SDK控制。ROCK提供一个与标准GEM RL环境语义对齐的最小化、一致的控制接口。用户可以通过一小组API创建、重置、步进和关闭环境，简化了与RL训练和评估流水线的集成。我们稍后会详细介绍这些API。
- 技能2：无缝的智能体扩展。ROCK支持多智能体环境，并能根据交互模式提供共享或隔离的沙箱，从而实现多智能体协作和竞争。它还在统一的GEM API后编排了多样的智能体基准测试（例如，SWE-bench【Jimenez et al., 2024】、Terminal Bench Pro【Team, 2025】），因此ROLL可以通过单一接口与异构环境交互，只需最小的配置更改即可实现多任务RL训练。
- 技能3：原生智能体桥接。这弥合了RL框架和智能体框架之间的差距，后者重建并对齐了智能体原生的基于消息的上下文管理。我们稍后会详细解释这种原生智能体模式。
- 技能4：大规模调度。ROCK在沙箱之间执行资源的动态分配和回收。这使得在突发工作负载下实现高利用率，并通过在集群上弹性分配任务来支持大规模并发，可扩展到数万个并发环境。
- 技能5：稳健的故障隔离。每个任务都在其自己的沙箱中运行。如果一个智能体崩溃、卡住或损坏其文件，故障将被限制在该沙箱内，不会干扰同一台机器上的其他任务。ROCK还通过每个沙箱的策略限制其网络访问，限制了行为不当或被攻破的智能体的影响。
- 定制优化。ROCK为不受信任的指令提供权限隔离，高效的大文件和工件传输，集中式日志记录，带有故障恢复的资源防护栏，可选的检查点和重启支持，以及用于调试和CI/CD式环境交付的工具。

API接口。ROCK提供两个主要的API服务用于编程控制，即Sandbox API和GEM API。Sandbox API管理托管GEM环境的沙箱。ROCK提供的GEM API遵循官方的GEM标准化API【Axon-RL】。它是训练框架无关的，并能与一系列RL框架无缝集成，包括veRL【Sheng et al., 2024】、OpenRLHF【Hu et al., 2024】和Tinker【Thinking Machines AI】。为确保广泛的兼容性，ROLL也提供了一个遵循GEM协议【Axon-RL】的GEM API实现。特别是，由ROLL运行时管理的环境工作者使用GEM API来协调智能体与其由ROCK托管的环境之间的交互。所有端点都遵循RESTful设计并使用JSON进行数据交换。我们下面描述这两个API。

Sandbox API功能。Sandbox API管理沙箱实例的完整生命周期。其功能可分为三个主要类别：
- 配置（Provisioning）：创建和启动沙箱，支持自定义镜像、资源配置以及同步和异步模式。
- 监控（Monitoring）：查询任何运行中沙箱的状态、操作健康状况和资源消耗统计信息。
- 持久化（Persistence）：停止一个沙箱实例以释放其资源，或将其当前状态提交到一个新镜像以供将来使用。

GEM API功能。作为RL环境的标准化接口，该协议使API能够支持通用任务的核心智能体交互循环：
- Make：创建一个新的GEM环境实例。
- Reset：将现有环境实例重置为其默认状态。
- Step：向环境发送一个动作以推进一个步骤，并接收下一个状态。
- Close：关闭环境以释放资源。

智能体原生模式。智能体原生模式将智能体RL训练与ROCK连接起来。训练框架（ROLL）和部署系统（iFlow CLI）之间上下文管理的不一致性会显著降低智能体在生产环境中的性能【Rush, 2025】。一个简单的解决方案是强制ROLL完美镜像iFlow CLI的上下文处理，包括其多轮交互和提示拼接的特定逻辑。然而，这会造成紧密耦合：智能体逻辑的每一次更新都需要在ROLL中进行相应的重新实现，导致不可持续的维护负担。

ModelProxyService实现原生模式。为了解决这个问题，我们在ROCK环境中实现了一个ModelProxyService。该服务充当代理，拦截所有源自智能体沙箱的LLM请求。关键的是，这些请求已经包含了由iFlow CLI完全编排的完整历史上下文。代理随后将这些请求转发到适当的推理服务——无论是在训练期间的ROLL推理工作者，还是在部署期间的外部API（例如，GPT、Gemini）。原生模式实现了清晰的分离。ROLL简化为生成引擎，而iFlow CLI保留了对上下文管理的完全控制。这不仅消除了训练框架中的实现复杂性，而且保证了训练和部署之间的完美一致性，解决了维护和性能问题。

原生模式的优势。智能体原生模式不仅保证了训练和部署之间的一致性，而且贯穿了整个开发流水线，包括数据合成、训练和评估。一个关键特性是它支持多种智能体框架（iFlow CLI、SWE-Agent【Luo et al., 2025】、OpenHands【Wang et al., 2025d】等），这降低了切换脚手架的开销，并简化了诸如生成更多样化训练数据等任务。


图 5: iFlow CLI架构和执行概览。

2.4 智能体框架：iFlow CLI

iFlow CLI概述。iFlow CLI是一个强大的命令行智能体框架，它提供了一个接口来自动化和执行复杂的多步骤任务，作为我们基础设施层的上下文管理器和用户界面。我们描述了iFlow CLI在智能体RL训练中的作用，提供了其概览，并强调了两个关键特性，即上下文工程和开放配置。

iFlow CLI在RL训练中的角色。iFlow CLI在智能体RL训练中承担两个角色。首先，在智能体原生模式下，一个模型代理服务会拦截来自ROLL的请求，并调用iFlow CLI进行上下文管理，确保训练和部署之间的一致性。其次，iFlow CLI的开放配置使通用LLM能够在训练期间通过上下文管理融入领域特定知识。通过允许可配置的系统提示、工具和工作流，iFlow CLI成为了训练和优化智能体行为的灵活基底，提高了在领域特定智能体任务上的性能。

系统架构与工作流。如图5所示，iFlow CLI采用了一个围绕单一智能体设计原则构建的编排器-工作者架构，遵循了Anthropic关于有效智能体系统的建议【Albert et al., 2024】。该系统向用户提供了包括客户端、IDE插件、Web和SDK在内的多种用户界面。系统由一个主智能体（Main Agent）驱动，该智能体维护全局任务状态并执行一个迭代控制循环。在每一步中，iFlow CLI接收用户命令，加载可用的持久内存和先前的聊天历史，然后执行上下文管理以组装模型输入。基于上下文，主智能体选择下一个动作，这可能是一个直接响应、一个工具调用或对一个专门子智能体的调用。工具套件通过一个统一的聚合层访问，该层包装了异构能力，如MCP集成，并将其结果作为智能体可以消费的观察返回。重要的是，子智能体被实现为具有有界上下文的专门工具，避免了智能体切换，并消除了对显式智能体间通信的需求。

内置技能与增强能力。在控制循环期间，iFlow CLI提供了四种内置技能来加强上下文管理。Compress为有限的提示预算执行上下文压缩。Reminder报告上下文变化，包括环境更新、工具更改和任务完成。Detection识别诸如循环和工具调用失败等问题。Env.Mgmt跟踪环境状态并在用户环境变化时通知智能体。iFlow CLI还提供了三种增强能力。Hooks实现会话级别的工具调用前后检查，如破坏性命令的警告和拦截。Workflow将可重用的技能打包为用于多步骤任务的可配置程序。Memory在用户、项目和全局级别维护分层的持久状态。

智能体制作的上下文工程。我们采用单一智能体控制循环，因为它简单、稳健且易于扩展。遵循“苦涩的教训”【Sutton, 2019, The bitter lesson】，我们避免了脆弱、过度设计的流水线，而是专注于上下文工程：为智能体提供精确、高质量的上下文，使其能够在真实的软件环境中有效地规划、行动和自我纠正。

五种上下文管理技术。在实践中，iFlow CLI实现了五种技术来管理长程任务的上下文：
- 持久化内存（Persistent memory）。iFlow维护一个轻量级的todo文件作为跨会话的外部内存。智能体可以读写它来跟踪计划、未解决的问题和下一步行动。
- 上下文隔离（Context isolation）。对于复杂任务，iFlow可以将子任务委托给一个子智能体。每个子智能体在专用的、隔离的上下文中操作，这可以防止对主智能体工作流的干扰，并确保更专注、高效的执行。
- 上下文检索（Context retrieval）。iFlow通过智能体搜索、语义向量检索和知识库集成（例如，DeepWiki）按需获取相关信息，减少了对已在提示中的内容的依赖。
- 上下文压缩（Context compression）。为了应对有限的上下文窗口，iFlow应用有损和无损压缩来保留关键事实，同时控制提示长度。
- 上下文增强（Context enhancement）。用户可以明确高亮关键信号。这包括强化当前任务目标或高亮环境中的重大变化（例如，创建的新文件、测试结果）以引导LLM的注意力。

规范驱动的工作流。这些能力共同实现了一个针对领域任务的规范驱动工作流：通过向上下文中注入清晰的“规范”（提示、工具和流程），iFlow可以执行专门的工作流（例如，微信小程序开发或iOS应用工程），同时保持核心智能体循环不变。iFlow CLI还提供了开放的配置接口，使得将RL训练与领域特定的提示、工具和工作流对齐变得简单。

开放配置能力。真实的软件工程需要的不仅仅是通用智能。它要求严格遵守领域特定的标准、复杂的操作逻辑和专门的工具链。为了弥合通用模型和专业工程需求之间的差距，iFlow CLI提供了一个高度可定制的配置层：

具体配置项。
- 系统提示（System Prompt, 行为对齐）：为了使模型的认知风格与特定领域约束对齐，系统提示充当了一个灵活的蓝图。用户可以明确定义工作流、工具集、使用场景和角色语调。这种定制化作为一种精确的控制机制，优化模型响应以适应特定项目或领域的独特需求。
- 工作流/规范（Workflow / Spec, 流程标准化）：为了从简单的代码生成扩展到端到端的、由工作流驱动的任务，iFlow CLI引入了工作流（或规范）。此功能让用户将不同的AI能力——智能体、命令和工具——组合成结构化的、自动化的任务链。无论是代码分析、开发周期还是部署流水线，工作流都能确保复杂流程被可靠且自主地执行。
- 工具集（Tool Set, 功能可扩展性）：为了超越LLM的原生能力，iFlow CLI通过模型上下文协议（MCP）支持广泛的集成。用户可以添加自定义工具或子智能体（在单一智能体循环中作为工具被调用），从而实现与外部API、数据库和专有环境的无缝交互。

2.5 总结

基础设施总结。我们的基础设施利用ROLL、ROCK和iFlow CLI，在系统层面为从训练到部署的整个智能体RL流水线提供支持。它特别作为高性能智能体RL的两大支柱：构建有效的训练算法和构造高质量的数据集，我们将在下文讨论。


图 6: 用于训练智能体模型的数据源和组合流水线概览，涵盖以代码为中心的基础数据和智能体数据。

3. 智能体模型：ROME显然是一个智能体模型

本节介绍ROME，这是我们使用ALE基础设施训练的智能体基础模型。ROME擅长处理各种由工作流驱动的任务（例如，GUI辅助、旅行计划）。我们接着概述了其开发背后旨在实现强大智能体制作性能的核心原则和程序，分为三个组成部分：（1）一个严谨且有原则的数据获取和合成工作流；（2）一个集成了智能体持续预训练（CPT）、监督微调（SFT）和交互感知智能体策略优化（IPA）RL算法的端到端训练流水线；以及（3）一个全面的基准测试套件。总的来说，这些组件构成了一个系统化的路径，说明了ROME如何利用所需的基础设施来支持下一代智能体LLM。

3.1 数据组合

3.1.1 作为数据设计蓝图的智能体能力

智能体制作能力分解。智能体制作旨在构建自主的、由工作流驱动的智能体，这些智能体能够通过一个迭代的制定、实施、验证和完善的循环，可靠地将需求转化为可工作的产物。为了刻画这类智能体必须学习什么，以及因此我们的训练数据必须提供什么信号，我们将智能体制作能力分解为三个紧密耦合的维度：任务理解与规划、行动与执行、以及交互与适应：

任务理解与规划。该维度捕捉了智能体解释自然语言或半结构化规范，并将其转化为范围明确、可执行的工程任务及附带可验证开发计划的能力。智能体必须准确提取用户意图，揭示可能导致实施失败的隐含规则和约束，并浮现隐藏的假设。这包括识别核心系统实体，定义精确的输入输出契约，建立边界条件，并阐明通常被忽略但对现实世界可行性至关重要的非功能性需求（如性能、安全性、可扩展性、兼容性）。当信息不完整时，智能体应提出最少的必要澄清问题，并明确表示不确定性，避免在模糊需求下过度承诺，从而减少下游的返工。

行动与执行。该维度关注智能体将计划转化为高质量实现，并利用外部工具链闭合开发循环的能力。智能体必须根据任务特性（例如，代码搜索、构建系统、依赖管理、编译/执行、测试框架、调试器、静态检查器、格式化器、性能分析器、CI/CD流水线）主动选择合适的工具，并以正确的参数和顺序调用它们。关键地，智能体还必须解释工具输出来驱动后续行动，例如，从失败的测试日志中定位缺陷，解决linter报告中的风格和正确性问题，并根据性能分析器证据优化瓶颈。

交互与适应。该维度管理智能体与环境保持动态反馈循环的能力，从而实现跨迭代的持续改进。智能体必须主动整合多种信号（例如，运行时行为、测试结果、用户反馈、代码审查评论和不断变化的系统约束），并相应地调整其计划和实现。例如，当面临API弃用或依赖冲突时，它应进行影响分析并转向替代策略（例如，回滚、重构或替换），而不是僵化地坚持一个过时的计划。

两层数据设计课程。根据上述能力分析，我们的数据设计采用了一个两层课程，将模型从基础熟练度阶段性地培养到闭环的智能体行为。在第一层，基础数据（Basic Data） 提供智能体模型在迈向完整智能体行为过程中所需的目标性基础能力建设。它包括互补的组件，如以代码为中心的语料库，支持持续预训练并加强项目级代码理解和生成能力；以及涵盖推理密集型任务和通用指令的通用推理数据，以强化可迁移的推断和规划技能。在第二层，智能体数据（Agentic Data） 通过在现实环境中产生闭环、可执行的训练单元来针对智能体的特定需求。它分为 i) 实例（instances），将传统查询扩展为包含可执行规范、固定环境和可验证反馈；以及 ii) 轨迹（trajectories），记录智能体在其中迭代规划、行动、观察运行时反馈并修订解决方案的多轮交互。智能体数据可以直接用于后训练，以选择性地增强在真实世界约束下的智能体规划、执行和适应能力。

数据与能力的映射。我们的数据将能力维度映射到两层监督中。基础数据通过让模型接触丰富的项目上下文和格式良好的规范，专注于任务理解和规划，教授意图提取、需求范围界定和计划制定。它还构建了编码和通用推理的基础，以便后续能够进行有效的行动、执行和迭代改进，而无需依赖明确的工具使用轨迹。然后，智能体数据提供对行动与执行以及交互与适应的针对性加强。它将需求嵌入固定的、可执行的环境中，通过确定性的构建和测试提供可验证的运行时反馈，并捕获在真实环境中的单轮和多轮轨迹。这种设置既训练了稳健的执行和适应能力，又将任务理解和规划置于现实约束中，将高层计划转化为在真实世界条件下可行的解决方案。

分阶段课程总结。这两个层次的数据共同构成了一个分阶段的课程。基础数据在没有完整环境编排的情况下，建立了核心编码和推理的广度和可靠性，而智能体数据则增加了闭环执行和具体的运行时信号，直接监督在真实世界约束下的规划纪律、执行保真度和自适应迭代。这一进展操作化了能力蓝图，并为从基础技能到完整智能体能力提供了一条连贯的路径。

3.1.2 以代码为中心的基础数据组合

代码数据的重要性。作为智能体LLM能力的一个基石，编码熟练度需要一个由大规模、高质量代码数据构成的坚实基础。构建这样一个语料库不仅需要系统性地获取广泛的代码库，还需要建立专门的环境来合成和处理真实的软件工程数据。因此，我们利用真实的开发生态系统，策划了一个全面的数据集和任务套件，以覆盖包括代码理解、故障定位、错误修复和自动化测试生成等关键维度。

数据采集与预处理。我们根据星标数、分叉统计和贡献者活动等标准，选择了大约一百万个高质量的GitHub仓库。遵循Seed-Coder【Seed et al., 2025, Seed-coder: Let the code model curate data for itself】的方法，我们将同一仓库内的多个源文件连接起来，形成项目级别的代码结构训练样本，以防止模型仅学习孤立的代码片段，并促进对真实世界工程上下文的理解。此外，为了改进代码定位和修复，我们进一步从选定的仓库中爬取了Issues和Pull Requests (PRs)。我们只保留已关闭的Issues和已合并的PRs，以确保明确的问题-解决方案对应关系。然后，我们使用一个LLM来过滤Issues，移除描述模糊、纯粹是问题/讨论帖子、自动生成内容或缺少关键技术细节的低质量案例。在Issue-PR链接过程中，我们只保留那些具有明确的“将关闭”意图并实际解决了相应Issue的PR，排除了那些仅仅引用了Issue而没有实质性修复的PR。

任务构建与形式化。基于收集到的Issue-PR对，我们制定了五大核心类别的软件工程任务：

代码定位。为了建立一个修改目标，我们遵循AGENTLESS【Xia et al., 2024, Agentless: Demystifying llm-based software engineering agents】中的协议，采用黄金补丁中的修改文件列表作为基准真相。形式上，给定一个问题描述I和仓库结构S，任务是识别出一个需要编辑以解决该问题的最小文件子集 $F = \{ f_1, f_2, . . . , f_n\} \subset S$。

代码修复。在定位的文件基础上，我们将修复过程形式化为一个结构化转换。遵循AGENTLESS【Xia et al., 2024, Agentless: Demystifying llm-based software engineering agents】，黄金补丁的差异被转换为搜索和替换块，以提供精确的编辑信号。形式上，给定问题I和相关代码段C，模型M生成一组编辑 $R = M(I, C)$，其中R代表指定所需转换的搜索和替换块。

单元测试生成。为了实现对提议