Cursor Builds 装依赖失败 仍能开 Agent 怎么排

Builds 打开之后，最常见的惊吓是：Builds 页一片红，但 Agent 居然还能开。这不一定是坏消息——官方设计就是「失败 Build 不替换 active」。真正要怕的是：你以为新依赖已经进环境了，Agent 其实还在用上周那份成功快照。

作者：CodePass 技术编辑

先确认：红的是新 Build，还是 active 也没了

打开该环境的 Builds 页，看两列信息：

• 最新一条是否 Failed，触发类型是 Recurring、Configuration change、Manual 还是 Agent-requested。
• 当前 active Build 是否仍指向更早的 Success。

若 Failed 旁边仍有一份 Success 被标为 active，Agent、Automations、Code Review 默认继续从那份启动。文档写得很直：坏依赖、坏 install、坏 Dockerfile 都不会顶掉正在用的环境。你的任务没停，只是「新代码/新依赖」可能还没进快照。

日志里先分三类失败

打开失败 Build 的事件与日志，按症状分支：

私有源 / 鉴权：npm ERR! 401、pip 拉私有 index 失败、Docker pull 私有镜像 403。Build 只能用 team / environment secrets；你塞在「用户级」的密钥不会进 Build。把 registry token 挪到环境或团队密钥，保存配置会再触发一轮 Build。

install 不幂等或挂死：脚本假设「永远干净机」、删目录后再装却路径写死、或在 install 里起了 pnpm dev / 数据库。Builds 只保留磁盘；进程与 shell export 在快照时结束。长驻服务应放 start / terminals。可反复执行的 pnpm install、pip install 才适合 install。

默认分支上的坏提交：Recurring Build 会跟默认分支走。某次依赖 bump 合进 main 后，install 开始红，但 active 仍是旧 Success。这时 Agent「能跑」反而是缓冲；修好 main 或临时改 install，再 Manual Trigger / Test build，等新 Success 激活。

精确复现：从失败 Build 启动 Agent

文档 Debug 段建议：从失败 Build 直接开一个 Agent。机器停在失败现场，你可以读日志、改环境配置、跑 Test build，确认后再决定是否 Enable / 激活。不要只在本地猜；失败现场和本机往往差在密钥作用域、base image、多 repo 同时 checkout。

也可以把排查交给 Cloud Agent，经 Cursor Cloud MCP 说清目标，例如文档示例：检查该环境最近失败 Build → 修配置 → Test build → 验证后再提最终的 install/start。

预防：Skipped 多不等于坏了

Recurring 检查若发现默认分支无新 commit、配置与密钥也没变，会记一条 Skipped：几秒结束、不跑 install、active 不动。安静仓库大多是 Skipped；热闹仓库 Success 更密。别把「全是 Skipped」当成 Builds 坏了。

配置改动或密钥变更一定会跑 Build（不会被 skip）。改完先看这一轮是否 Success，再拿真实任务验证 Agent run 绑定的 Build ID。环境 JSON 怎么拆命令，仍以 environment.json 配置文 为准；本文只处理「红了怎么办」。