现有 Cloud Agent 环境怎么打开 Cursor Builds

新环境已经默认开 Builds。你若还在用旧的 Cloud Agent environment，要在 2026-08-17 全量默认前自己点一次，否则仍可能按「每次会话现装」的老路径启动。下面按官方文档把开启顺序写死，避免点错成「只测了一次却没真正启用」。

作者：CodePass 技术编辑

入口：Dashboard 里该环境的 Builds 页

1. 打开 Cloud Agents 环境列表。
2. 点进要迁移的环境。
3. 打开 Builds 标签。

这里能看到历史 Build 的类型、状态、时间；也能 Trigger build / Test build。新环境若已默认开启，你会直接看到 Recurring / Success / Skipped 流水。健康状态往往是「Skipped 与 Success 交错」，不是天天全绿重建。

两条开启路径，别混

文档给存量环境两条路，职责不同：

Run setup agent：让 Agent 扫你的环境，试跑一次 Build，并建议哪些命令该进 Build、哪些该留在 Agent 启动。Dashboard 管理的环境会给出可审阅的配置更新；若环境定义在 .cursor/environment.json，它还可能直接开 PR。setup agent 不会替你勾选 Enable Builds，审完配置后仍要点启用。

Enable Builds：用当前配置立刻打开 Builds，并创建第一轮 Build。适合你已经分清 install / start，只想打开预热机制。

想验证配置又不想让所有 Agent 立刻切到 Builds，用 Test build。它跑一轮、出日志，但不把 Builds 设为该环境的默认启动路径。

开启前先改三处配置

公告 Cloud agents start 3x faster with builds 点名三件容易翻车的事：

• 把能提前做的依赖安装、生成、编译都放进 install，并保证幂等（可反复跑）。
• install 若要打私有 registry，用 team / environment secrets。User secrets 只在 Agent 启动时注入，Build 阶段拿不到，也不会进共享快照。
• Docker、数据库、隧道等「会话一开始就要活着」的进程继续放 start 或 terminals，不要塞进 install。

更细的字段分工与示例见 environment.json 怎么配。

第一轮成功前，Agent 仍走旧启动

在第一份成功 Build 出来之前，Agent 继续用原来的环境启动流程。失败 Build 也不会打断现有工作流。所以正确姿势是：开 Builds → 等首轮 Success → 再拿真实任务压一轮 → 确认 Dashboard 里该次 Agent run 绑定的 Build ID 是你刚激活的那份。

若首轮红了，先别急着关功能。打开失败 Build 看事件与日志；需要精确复现时，可以从失败 Build 启动一个 Agent，机器停在失败现场，方便改配置再 Test build。也可用内置 Cursor Cloud MCP 让 Agent 自己查失败 Build、改配置、再测一轮。文档示例提示词就写了这条链路。

8 月 17 日会怎样

官方写明：到 August 17th，所有新环境和已有环境都会默认使用 Builds，且不额外收费。你提前 Enable，等于自己控制迁移窗口；拖到默认日，配置若还把长驻服务塞在 install，第一波 Recurring Build 更容易红。省 token、少空转的另一面讨论见 云端 Agent 怎么省 token；本文只管「怎么点开」。