我们开发 Composer 的一个显著特点，是会利用模型的早期版本来改进后续版本的训练过程。

这种自举最明显的应用场景之一，就是环境设置。RL 训练需要可运行的环境；如果环境一开始就是坏的，模型就会把 token 浪费在调试环境上，而不是学习解决问题。在最糟糕的情况下，糟糕的环境甚至会让问题彻底无解，最终白白消耗算力，却得不到任何奖励信号。

为了解决这个问题，我们构建了 Composer autoinstall。这个系统会利用较早版本的 Composer 模型，从未经配置的代码仓库 checkout 结果中自动创建可用的 RL 环境。在训练最新版本的模型 Composer 2 时，我们使用它的前代版本 Composer 1.5 来处理这一流程。我们发现，现代 coding model 不只是会按步骤执行说明，还会尽一切努力完成配置、模拟项目依赖，并测试设置是否成功。

#更好的环境意味着更好的训练信号

和我们模型开发中的许多其他方面一样，autoinstall 也受到 Cursor 生产系统的启发。在 Cursor 的云端智能体中，我们有一项功能，可以为用户自动完成云环境设置，让他们的智能体能够在模拟环境中处理项目。智能体从 git checkout 开始，安装软件包、配置设置并运行基础检查，以确保代码能够正常运行且保持稳定。这样一来，后续请求就可以直接基于正确的环境设置开始。

对于 RL 训练来说，这个问题更加关键，但也更具挑战性。从一个代码仓库开始，autoinstall 的目标是创建一个可运行的、模拟的代码库基础版本，以便解决未来尚未出现的编程问题。这个基础环境至关重要，因为 Composer 是在一整套工具下训练的，其中包括编程语言的 lint 命令、搜索，以及对 shell 的沙箱化使用。如果环境没有被正确设置，训练就会变得低效，甚至可能白白浪费算力，却得不到任何奖励信号。

#一个智能体定义成功标准，另一个则尝试达成它

Autoinstall 分两个阶段进行。在第一个“目标设定”阶段，我们向 Cursor 智能体提供处于固定 checkout 的代码库，并要求它提出 10 条命令，以及在环境正确设置后这些命令应产生的输出的高层描述。

智能体会查看环境中的 README 或 Makefile，也会尝试一些常见的语言特定命令，例如 uv 这样的项目管理工具，或 clippy 这样的 lint 工具。智能体的工作通常包括设置命令、测试 (如果有) 以及可执行文件的启动命令。

在第二阶段，我们向一个独立的 Composer 智能体提供环境的初始状态，以及从前面 10 条提议中选出的 3 条目标命令。随后，该智能体会探索代码库，并通过工具调用将环境设置到可以运行这些命令的状态。之后，我们会测试这 3 条命令是否都能运行，以及输出是否与第一个智能体给出的目标描述一致。如果不一致，我们就重新开始第二阶段。如果这一流程重复五次后，智能体仍无法将环境设置到令人满意的程度，我们就会丢弃该环境。

通过 autoinstall，Composer 的目标是尽可能完整、正确地设置环境。为此，它会模拟缺失的文件、创建占位图片，甚至创建假的数据库表。有些项目需要安装运行测试所需的额外组件，例如 S3 文件夹或缺失的 sidecar 容器。Composer 也经常会模拟这些内容，创建 MinIO 配置或 Docker 容器来让它们正常工作。为支持长时间运行的进程，我们允许 autoinstall 创建启动脚本，以便在 RL 用量开始时启动这些进程。

#真实项目中的 Autoinstall

为了说明 Autoinstall 的流程，我们来看一个真实实验：我们曾使用 Autoinstall 来搭建一个复杂的真实项目。这个项目是 Celo，代码位于 celo-org/celo-monorepo。它是一个大型区块链项目，具有多个重要依赖项。这个项目很适合用来检验 Autoinstall，因为它既需要管理大量安装依赖，还需要为测试模拟一套身份验证流程。

在 Autoinstall 的第一阶段，我们观察到智能体查阅了项目文档和代码，以找出关键的安装命令。不过，该项目自带的文档相对有限，因此它还使用了 Web 命令搜索该项目的文档网站，以获取更多设置命令。识别出的命令大多与安装或测试有关，但其中也包括一个来自文档的基础最小应用，用于实际使用该软件。

在第二阶段，智能体的任务是把这些命令真正跑起来。虽然任务本身很明确，但模型事先并不知道会遇到哪些问题。就这个具体案例而言，它发现还需要安装其他一些依赖项，例如相关 repo Foundry。它使用 Web 搜索来查阅这个必装项目的文档。它还需要在这个环境中运行一个最小应用。在这一阶段的第一次迭代中，它未能成功运行这个测试应用，但在第二次迭代中，它发现可以创建一个模拟用户，从而在本地启动该应用并满足要求。

#为下一代自举。

Autoinstall 是一个很有意思的例子：它展示了如何用上一代模型来自举 RL 流程。尤其值得注意的是，Composer 2 现在在 Terminal-Bench 上的得分明显更高 (61.7%，而 Composer 1.5 为 47.9%)。这项基准测试包含对模型配置开发环境能力的测试。这表明，Composer 2 将为 Autoinstall 提供更好的基础。我们预计，在未来的训练轮次中，先前的 Composer 实例将在训练流程的更多环节发挥重要作用，包括运行管理、数据预处理和架构调优。

深入了解 Composer 2