Cursor Builds 是什么 云端 Agent 为何能快三倍启动

Cursor Builds 是什么？一句话：Cloud Agent 不再每次从零 clone、装依赖，而是从 Cursor 在后台持续准备好的环境快照启动。官方在 2026-08-13 的 Builds 公告 里写，首 token 时间最多可快约 3 倍；自家内部环境甚至宣称启动快约 10 倍。对天天开自动化 Agent 的团队，这直接砍掉「等机器就绪」那几分钟。

作者：CodePass 技术编辑

以前每次会话都在重复装环境

Cloud Agent 跑在隔离机器上。没有 Builds 时，每次开跑大致要：起机 → clone 仓库 → 跑 install。大仓库、重依赖场景里，Agent 真正开始改代码前就可能耗掉数分钟。Automations、批量 Code Review、无人值守流水线一多，这段固定成本会被乘上次数。

Builds 把 clone 与 install 挪到后台，按计划或配置变更提前做完，并留下一份可启动的磁盘快照。新 Agent 从「已经装好」的状态进场，而不是排队等安装脚本。

Build 生命周期：触发 → 准备 → 快照 → 激活

按 Cloud Agent Builds 文档，一次 Build 大致走四步：

1. 触发：定时 Recurring、保存环境配置、手动 Trigger/Test，或 setup agent 请求。
2. 准备：从 base image 起，clone 环境里每个仓库的默认分支，跑完 install。
3. 快照：把磁盘状态与各仓库的精确 commit SHA 一起存下。
4. 激活：成功则成为 active Build；之后新的 Agent、Automations、Code Review 默认从它启动。

失败的 Build 不会顶掉当前 active。依赖升级翻车、Dockerfile 坏了、私有源鉴权挂了，通知你会来，但已有会话继续用上一份成功快照。公告里 Faire 工程师提到一周两千多次自动化跑，正是靠「坏 Build 不拖垮舰队」才敢放手。

和 snapshot / Dockerfile 不是二选一

Builds 不取代你已有的 snapshot 或 Dockerfile。那些仍定义「机器长什么样」；Builds 是在之上再 clone、再 install，再打一层可启动快照。多仓库环境一次准备齐，每个 repo 记自己的 commit。

命令分工也没变：install 只做写磁盘、可幂等的事；start / terminals 仍在 Agent 启动时拉起 Docker、数据库、dev server。把长驻进程塞进 install，快照会带着半吊子进程状态——这是老坑，Builds 出现后更容易被放大，因为失败 Build 虽不激活，但日志会反复红。JSON 字段怎么写，见已发布的 environment.json 配置。

8 月 17 日默认开启，不加钱

新环境已默认走 Builds。存量环境可在 Dashboard → Environments → 某环境的 Builds 页点 Enable Builds，或先跑 setup agent 让它拆分 install/start 再开。官方写明：Builds 包含在 Cloud Agents 费用里，不另收费；到 2026-08-17，所有新环境和已有环境都会默认用 Builds。

若你关心云端环境配好以后 PR 吞吐怎么变，可对照 Cloud Agent 环境与 PR；本文只回答「Builds 这个产品层到底是什么」。