机器之心发布

Andrej Karpathy 大神力荐的 Vibe Coding，正在成为开发者的新宠。这种「只需聊一聊，AI 可以把功能写出来」的体验，极大提升了简单任务的开放效率。

然而，当我们目光转向实际的系统，特别是 AI Infra 这种复杂系统时，Vibe Coding 就会常常会陷入「水土不服」的困境。

总结下来，主要有这三个方面的问题。

首先是上下文丢失问题：对话历史被压缩，关键设计决策在多轮交互中逐渐遗忘，导致后续生成的代码与前期讨论脱节。其次是决策偏离困境：AI 在面对复杂系统时需要做出大量技术决策（如架构选择、接口设计、错误处理策略等），自主决策容易偏离开发者意图，生成的代码难以符合预期。最后是质量不稳定挑战：即使提供了完整的需求描述，生成代码的质量仍然波动很大，同样的需求在不同时间可能得到截然不同的实现方案。

而这些问题背后的根源在于：AI Infra 到底还是个复杂系统，动辄数万行代码、成百上千个相互关联的决策点，而当前的对话式编程缺乏持久化、结构化的决策管理机制。

换句话说，Vibe 本身是模糊且不稳定的，无法支撑严肃复杂的 Infra。

不过 Vibe Coding 的发展不可逆，其广泛应用的潜力不应就此止步。要让 Vibe Coding 真正适用于 AI Infra 开发，我们实践了文本驱动的 Vibe Coding方法：通过设计文档将所有关键决策体系化、持久化。

将复杂系统的关键决策前置到设计阶段，通过结构化文档让开发变得有章可循，大幅降低复杂度门槛。

程序员只需要专注于高层设计决策，AI 负责代码实现细节，真正实现「几乎不写一行代码，就可以完成复杂功能」。

整个过程通过详细的设计规范和代码逻辑来约束 AI 生成，确保实现复合预期，同时提升系统健壮性。

而要验证这一新范式的有效性，我们需要一个兼具高复杂度、强工程约束和真实业务价值的典型场景。

AI Infra 中的资源调度系统，尤其是面向 Agentic RL，正是这样一个理想试验场。该系统是数万行代码的分布式训练系统，面临 GPU 利用率优化的复杂挑战，涉及核心调度逻辑改动。

新开发范式是如何在这一场景实操的？阿里巴巴未来生活实验室与智能引擎团队带你进一步来看。

第一部分：Agentic RL 中的 GPU 利用率挑战

在 Agentic RL 的采样过程中，系统需要支持越来越高的交互轮数，让智能体有足够的环境交互来处理复杂任务。然而，这一趋势带来了显著的资源调度挑战。

在实际采样中，智能体执行任务的时间分布呈现典型的长尾特征：绝大多数样本能够在较少轮数内快速完成采样并得出结果，而只有少数复杂样本需要执行到最大轮数限制才能终止。这种极不均匀的执行分布成为 GPU 资源利用的核心瓶颈。

问题的本质在于分布式计算中经典的 "落后者效应"（Straggler Effect）：无论有多少样本已经完成，系统都必须等待最慢的那个样本执行完毕，才能进入下一阶段。等待过程成为整个训练流程的性能瓶颈，更造成 GPU 资源浪费。

1.2 方案对比与技术优势

业界针对 Agentic RL 训练存在两种主流解决方案，但都存在根本性缺陷：

共置方案采用严格的串行执行策略：所有 GPU 首先统一投入 rollout 阶段，等待全部样本采样完成后再切换至 training 模式。这种方案存在双重效率问题。首先是阶段内的资源闲置：在 rollout 阶段，由于落后者效应的存在，大量 GPU 在短样本完成后进入闲置等待状态，无法有效利用。其次是阶段间的严格串行限制：rollout 和 training 完全无法并行执行，training 阶段必须等待 rollout 完全结束才能开始，导致整体迭代时间被显著拉长。

异步分离方案通过静态分配专用的 rollout GPU 和 training GPU 实现流水线并行。虽然理论上能够缩短单轮迭代时间，但引入了严重的 "双边空泡" 问题。在 rollout 侧，短样本快速完成后，rollout GPU 进入闲置状态等待长尾样本执行完毕；在 training 侧，训练任务完成后需要等待新一轮 rollout 数据，training GPU 同样处于闲置状态。使得理论上的并行优势在实际运行中大打折扣。

我们提出的时分复用方案通过 GPU 池动态分配机制解决上述问题。其核心创新基于一个关键洞察：异步训练过程中，rollout 对 GPU 资源的需求呈现动态波动特征。在 training 触发前，大量样本已进入完成阶段，系统处于样本数目的低谷期，此时对 GPU 资源的需求自然下降。相反，在训练结束后，新一轮大量样本涌入系统，对 GPU 资源的需求急剧激增，形成明显的高峰期。基于这一波动规律，我们设计了智能资源调度机制，在采样需求低谷期分配部分 GPU 资源用于执行训练任务，从而实现需求波动与资源调度的有效匹配。

系统采用两阶段执行流程来实现这一设计理念。在全力采样阶段，所有 GPU 协同处理大多数样本，快速推进系统至需求低谷状态。当采样完成度达到训练要求时，系统执行缩容操作，释放固定的 rollout GPU 资源转入训练模式。随后进入并行执行阶段，被释放的 GPU 专门执行训练任务（充分利用低谷期的闲置资源），而长尾样本被迁移至剩余 GPU 继续处理。训练任务完成后，系统立即执行扩容操作，回收所有 GPU 资源恢复全力采样状态，为应对下轮需求高峰做好准备。

这种基于工作负载特征的智能时分复用策略，不是简单的资源分割，而是将训练的快速执行特性与 rollout 需求波动在时间维度巧妙匹配提升了整体的 GPU 资源利用效率。

以 4GPU 系统为例，我们比较各个方案的任务执行时间线。

时分复用方案的核心挑战在于系统复杂度的显著提升。为了追求高性能，需要精细复杂的控制机制，在分布式高并发的系统中实现尤其困难。相比串行执行和静态资源分配，动态调度引入了诸多技术难点：分布式环境下的精确同步控制，以及扩缩容操作的原子性保证，并发场景下样本状态的无缝迁移。

各个方案的优缺点

在一个包含数万行代码的分布式 RL 系统中，手工编码不仅周期长，更易引入隐蔽的状态不一致 bug。传统的开发方式已难以应对这种「高价值、高复杂度」的功能迭代需求。

正是在这一背景下，我们创新性地采用了文档驱动的 Vibe Coding 方法论，通过系统化的设计文档驱动开发流程，显著提升了复杂系统的实现效率和代码质量。

第二部分：文档驱动的 Vibe Coding 方法论

前文提到的氛围编程三大痛点，上下文丢失、决策偏离、质量不稳定，其根源都指向同一个问题：缺乏持久化、结构化的决策管理机制。

要理解设计文档如何解决这一问题，我们需要先认识到代码实现的本质：它是由成百上千个相互关联的决策点构成的。从顶层的架构选择、接口设计，到底层的变量命名、错误处理，每个决策都影响着最终的代码质量。在理想情况下，如果 AI 已经掌握了完整的代码改动（如代码迁移任务），它可以直接复制执行这些修改。但现实中，我们要解决的往往是全新的问题，比如本文的 "训练 - 推理时分复用优化" 功能此前从未实现过。

既然没有现成的代码可以参考，那么退而求其次，如果我们能够系统化地枚举出所有决策点，AI 就可以按照这些明确的决策逐步生成代码。

设计文档正是实现这一目标的关键工具：它通过结构化的方式，将高层的设计思路逐步细化为具体的代码改动，完整记录每一个决策点。

经过程序员审阅的设计文档，意味着人与 AI 在关键决策上达成一致。这直接解决了氛围编程的三大痛点：持久化文档消除上下文丢失，明确决策避免 AI 偏离意图，规范和代码逻辑确保代码质量稳定。这带来工作方式的根本转变：程序员从编码、调试、测试等执行层面，转向与 AI 讨论设计，通过文档明确决策点直到完全对齐，然后 AI 负责实现。设计文档同时记录实施进度，确保可追溯性。更重要的是，设计文档本身由 AI 管理，大大降低了编写门槛。

设计文档驱动的氛围编程和传统的 vibe coding 的工作流对比

这三种开发方式的优缺点

2.1 核心方法论：设计文档驱动开发

在明确了设计文档的必要性后，我们需要建立一套系统化的方法论来指导实际操作。设计文档驱动开发不仅仅是编写文档，更是一种全新的开发范式：通过结构化的文档组织决策过程，通过迭代审阅确保决策质量，通过分步实施降低实现风险。

这一方法论的核心在于将复杂的系统开发问题分解为三个可管理的环节：内容组织（如何构建决策体系）、审阅修改（如何确保决策质量）、分步实施（如何将决策转化为代码）。每个环节都有明确的操作流程和质量标准，确保整个开发过程的可控性和可预测性。

2.1.1 流程概览

设计文档的审阅是一个迭代优化的过程，需要人和 AI 协作来确保文档质量。我们建立了系统化的审阅流程，通过多轮迭代逐步完善设计文档，直到达到实施标准。

总体审阅流程

2.1.2 如何组织内容：开发者与 AI 共同完成

代码实现的结果是由一系列自顶向下的决策决定的，顶层的关键决策包括新功能如何融入已有架构，底层的决策如是否需要增加成员变量。组织设计文档的核心目的是系统性的跟进这些决策点，并逐步完善解决。由于底层的决策，往往依赖于顶层或者上层的决策，设计文档需要层次化的拆解决策，形成决策体系。开发者需要按照章节的先后顺序和目录层次结构审阅文档中的自顶向下的决策过程，当我们指出前面顶层设计的错误时，AI 会自动修改后面章节的中层和下层决策以保持内部逻辑的一致性。因此，我们可以按章节层次和顺序和 AI 逐个对齐自顶向下的决策。同时，在开发者和 AI 共同修正这些决策的过程中文档不断演进，文档需要自包含这个迭代的过程，记录迭代的版本。最后，文档也需要记录代码实施的进度和一些衍生的待办。

具体而言我们的设计文档模板包含如下内容：

2.1.3 如何审阅修改：复用 iFlow CLI 的 prompt 模板

上文描述的逐章节审阅对齐的过程理论上已经完备，但实践中会遇到一系列挑战。为应对这些挑战，我们建立了多层次的文档质量保证机制。

由于这些场景在文档审阅中反复出现，我们利用 iFlow CLI 的 Sub Command 功能，将不同场景的指令逻辑固化成了自定义的 prompt 模板。

审阅挑战与解决方案对照表

2.2 设计文档的实施

2.2.1 如何分步计划和实施

当 Section 5 完成所有 API 和 Implementation 的设计后，我们需要将这些设计转化为可执行的代码。这个转化过程分为两个阶段：首先规划 Section 6 制定实施步骤，然后进入 AI 辅助的增量开发循环。

规划实施步骤： 规划的核心目标是将 Section 5 中的方法拆解为依赖有序的小步骤。我们首先分析每个方法的 deps: 字段，识别底层 helper 方法和高层 orchestration 方法之间的依赖关系，绘制出完整的依赖图。在拆解步骤时，我们遵循 "每步越小越好" 的原则，通常一个 Step 包含 3-5 个相互关联的方法，避免单个 Step 包含超过 10 个方法。步骤的排序遵循依赖关系：Step 1 通常是基础设施（配置、常量、基础类），Step 2 到 Step N 按照从底层到高层的顺序排列，最后一个 Step 负责集成和端到端测试。每个 Step 都定义清晰的验证点和测试用例覆盖，确保可以独立验证和方便回退。

规划完成后，我们得到一个清晰的依赖图，指导后续的增量开发：

增量开发循环： Section 6 规划完成后，我们进入实施阶段。对于每个 Step，AI首先读取 Section 6 中的 purpose 和 dependencies，以及 Section 5 中相关方法的 Signature 和 Implementation，然后按照 docstring 和代码实现具体代码，同时展开 validation placeholders 为实际的验证逻辑。AI 完成编码后，会自动更新 Section 6 中该 Step 的状态，将方法从 NOT_STARTED 改为 DONE。

接下来是人工代码审查环节。我们使用 IDE 的 Local History 功能查看当前 step 的代码改动，重点检查代码是否符合 Section 5 的设计、是否正确实现了 validation 和 assertion、是否存在明显 bug。如果发现问题，小范围修正或进入错误处理流程（见 2.2.3）。审查通过后，我们创建一个 git commit，commit message 遵循 "Step N: [描述]" 的格式，然后继续下一个 Step，重复这个循环直到所有 Steps 完成。

2.2.2 防御性编程：让复杂系统更可靠

在分布式 AI 训练环境中，微小的错误可能触发级联故障，而异步操作和资源调度的复杂性使得问题追溯本就困难。更糟糕的是，AI 编程倾向于主动做错误处理，这种 "善意" 的处理机制往往弄巧成拙，掩盖了真实的错误信息，使得问题定位变得更加复杂。我们真正需要的是防御性编程，让错误主动暴露而不是被掩盖。然而，传统的防御性编程因其开发繁琐性和进度压力常被开发人员选择性忽略，导致系统健壮性完全依赖个人自觉。为此，我们将防御性思维前置到设计阶段：在关键节点设置验证点，构建标准化的错误处理模式库，利用 AI 技术自动生成健壮的防御代码，从而在保证开发效率的同时实现快速问题定位，显著降低维护成本。

统一的验证模式库： 我们维护了一个包含常用验证模式的库，每个模式都有唯一的 ID 和标准化的实现。这些模式遵循单一定义，多处复用原则。当需要在代码内增加某个验证逻辑时，只需在注释中加入模式库中的一处定义，AI 实施时会按 ID 查表展开，确保整个代码库中相同验证逻辑的一致性。

设计阶段的验证标注： 在 Section 5 的设计文档中，我们不直接编写完整的验证代码，而是用标准化的注释标注验证需求。以 shrinksampler () 函数为例，通过 VALINTRANGE 标注 GPU 列表的合法性验证，通过 ASTPOSTConDITION 标注返回结果的有效性检查。这种标注方式清晰表达了验证意图，同时保持了设计文档的简洁性。

def shrink_sampler (self, target_gpus: List [int]): 将在实施时展开为实际 validation 代码 offload_ranks = self._calculate_offload_ranks (target_gpus) 将在实施时展开为 assert 语句 return offload_ranks

AI 自动展开验证逻辑： 当 AI 根据设计文档生成代码时，会自动将标注中的模式 ID 展开为具体的验证逻辑。参数范围验证会展开为完整的条件检查语句，后置条件会生成带有详细错误信息的 assert 语句。这种自动展开机制避免了人工编码时的遗漏和不一致。

AST: AST_POSTConDITION (len (offload_ranks) > 0) 10-20 行的详细 validation 逻辑

第三部分：在生产级别的大规模集群上验证

3.1 实验配置

我们在生产级别的大规模集群上验证了时分复用方案的实际效果。实验环境采用 160 卡 GPU 集群，选择了具有代表性的 SWE Agentic 工作负载作为测试场景。模型使用 Qwen3-235B-A22B，这是一个具有 235B 参数规模、22B 激活参数的大规模语言模型，能够充分体现真实生产环境的计算压力。

为了模拟真实的智能体长时交互场景，我们将最大交互轮数设置为 100 轮，最大 token 长度为 64K，batch size 为 512。我们设置异步训练的 async ratio 为 1，这样的配置确保了实验的真实性和挑战性。在对比方案设置上，我们将时分复用方案与传统的异步分离方案进行对比：baseline 采用 128 卡用于 training、32 卡用于 rollout 的静态分配策略，而时分复用方案则采用 128 卡 training、160 卡 rollout 的动态调度策略。

3.2 性能对比分析

实验结果显示时分复用的 rollout 吞吐率提升了 3.5 倍。时分复用方案的 rollout 阶段几乎始终比完全分离的 baseline 要快，甚至在某些情况下训练任务无需等待 rollout 即可开始，性能提升明显。

更值得关注的是任务完成率的提升。在 baseline 的完全分离方案中，由于 rollout 资源受限（仅 32 卡），导致采样速度较慢，大量任务触发了环境默认的超时限制，采样轨迹的 timeout 比例居高不下。而时分复用方案通过动态释放更多 GPU 资源用于 rollout，显著加快了采样速度，完全避免了 timeout，提升了整体训练的稳定性和样本利用效率。

3.3 系统开销分析

在评估时分复用方案时，我们也仔细分析了引入的系统开销。参数同步开销方面，由于时分复用方案需要在更多的 GPU 之间进行参数同步（160 卡 vs 32 卡），相比分离方案会产生额外的通信开销，但这一开销在整体训练整体时间中占比极小。

缩容操作的开销主要来自于 rollout 模型参数的 offload 过程。当系统需要将部分 GPU 从 rollout 模式切换到 training 模式时，需要从显存中将 rollout 参数释放，实测耗时在秒级。尽管这一操作引入了额外的同步点，但由于缩容操作开销极低，因此并未成为性能瓶颈。

综合来看，时分复用方案通过智能的资源调度策略，在引入极小系统开销的前提下，显著提升了 GPU 利用率和训练效率，特别是在降低 timeout 率方面表现突出，充分证明了该方案在大规模 Agentic RL 训练中的实用价值。

第四部分：团队介绍

本文是 ROCK & ROLL 团队使用 iFlow CLI 在开源框架实践中的探索成果，后续相关功能将持续迭代并陆续发布。

ROCK & ROLL 由阿里巴巴未来生活实验室与智能引擎团队联合打造，致力于开拓强化学习（RL）的未来，探索面向未来的创新生活方式。ROLL 是灵活高效的 Agentic RL 训练框架，支持从十亿到千亿参数大模型的优化训练；ROCK 是易用、可扩展的沙箱环境管理器，可在分钟级拉起海量环境。我们坚持工程系统与算法协同创新，持续关注 RL 社区发展并分享开源实践，为 RL 在不同场景中的规模化落地提供坚实的基础设施支持。

iFlow CLI 是阿里巴巴未来生活实验室推出的一款终端 AI 智能体，支持通过自然语言进行交互。它能够高效分析代码仓库、完成各类编程任务，并准确理解特定的上下文需求；同时可将从基础文件操作到复杂工作流的流程自动化，显著提升开发者的工作效率。

、Star、试用并贡献代码，一起推动 RL for LLM 走向更广阔的实用化未来。

ROCK： https://github.com/alibaba/ROCKROLL：http://github.com/alibaba/ROLLiFlow CLI： https://cli.iflow.cn/