本期亮点： v3.7 的 Cloud Environment Setup 和 Cloud Subagents 推出了一套完整的分布式 agent 基础设施——环境快照、云端子 agent 独立 VM、带 /in-cloud 的并行任务分发，以及本地与云端之间的无缝切换。这不只是功能更新，它在重新定义"AI 编程工具"的协作边界。

背景：为什么云端环境是 agent 的下一个瓶颈

过去一年，Cursor 的核心叙事是"让 agent 越来越强"——Composer 2.5、Auto-review、Design Mode，每一步都在扩大 agent 能做的事。但有一条暗线一直没被充分讨论：本地环境的天花板。

当 agent 跑在你自己的笔记本上，它能访问的资源本质上是有限的：内存、CPU、网络条件、GPU——都绑定在那台物理设备。更关键的是，一旦你合上笔记本或者网络断开，agent 就停了。这是一个根本性的约束，限制了 agent 的"任务时间跨度"。

Wayfair 的案例把这个矛盾暴露得很清楚：他们的 ML 研究团队需要跑 20+ 并行 agent，每个实验可能耗时数小时。如果这些 agent 全绑在研究人员的笔记本上，笔记本一没电，整个实验 Sprint 就得重来。Wayfair 的解法是用 Cursor Cloud Agents——让 agent 在云端跑，人不在电脑前也能继续运行。

这引出了一个更本质的问题：当 agent 从"工具"变成"劳动力"，它的工作环境和物理设备的绑定就必须解耦。

Cloud Environment Setup：把开发环境变成可复用资产

v3.7 最务实的新功能是 Cloud Environment Setup——Cursor 能帮助你在 10 分钟内把开发环境配置到云端，并且这个环境会被捕获成一个可复用的快照（snapshot）。

这里有几点值得注意的工程细节：

环境快照的复用价值：一旦快照被 commit 到 .cursor/environment.json，它就成了团队共享资产。新来的 cloud agent 不需要重新跑依赖安装、工具链配置，直接从快照启动。这意味着云端 agent 的冷启动时间从"分钟级配置"压缩到"秒级快照恢复"。

共享终端的监控价值：整个环境搭建过程在共享终端可见，团队成员可以看到 agent 正在安装什么依赖、配置什么环境。这个透明度在团队协作场景里很重要——它让人类的监督变得可能，而不是把环境配置变成一个黑箱。

对并行化实验的直接支撑：结合 Wayfair 的案例来看，这条能力链变得清晰了：环境快照 → 快速并行启动多个 cloud agent → 每个 agent 跑不同的 ML 实验 variant → 全部在云端完成，不需要占用本地资源。这是把 AI 编程工具用到 ML 研究场景的核心基础设施。

Cloud Subagents：/in-cloud 与隔离式并行

这次更新最关键的新能力是 /in-cloud 命令：用户可以在本地 agent session 里，随时 spin up 一个云端子 agent，在独立 VM 上运行你提交的下一个任务。

这个设计解决了三个实际问题：

隔离与并行：子 agent 运行在独立的 VM 和独立的 git branch 上。这意味着它对你的本地工作区没有任何干扰——不会产生 merge 冲突，不会占满你的内存，不会因为改了你正在看的文件导致你丢失上下文。你可以同时开五六个 cloud subagent 跑不同的任务，本地编辑器照常工作。

PR babysitting：你也可以让 cloud subagent 来"看守"一个 PR。点击 quick-action pill 或用 /babysit，cloud agent 就会在远端迭代，直到 PR 准备好被合并。这个能力解决的是一个很具体的痛点：reviewer 时间碎片化，PR 经常因为等一个 review 而卡住。babysit 模式让 agent 可以在 reviewer 空闲之前就主动把 PR 推到可合并状态。

后台运行与 session 解耦：cloud subagent 可以在后台运行，不打断父 agent——父 agent 可以继续在本地或云端跑其他任务。这是一个异步并行的架构模式：不再是"等这个 agent 做完，再做下一个"，而是"所有任务同时推进，最后汇总"。

本地与云端的无缝切换：Handoff 机制

v3.7 的另一个重要能力是本地和云端之间的 session 迁移。你可以：

  • 把本地跑的任务 offload 到云端，让它不受本地电脑状态影响继续运行
  • 随时 pull 下来一个云端 agent 到本地，手动接管检查或修改

这个 handoff 机制表面上是一个"切换"功能，但它背后的架构意义更深远：它意味着 agent session 不再绑定特定的执行环境。你的上下文、任务状态、工作进度，跟运行它的物理机器解耦了。

这对开发者体验的影响是：你可以在地铁里用 iPad 的 Cursor 网页版继续笔记本上没跑完的 agent 任务，回家后再 pull 回本地检查 diff。这个体验已经在向"你的 AI 工作流跟设备无关"这个方向演进了。

Automations v3.8：GitHub 原生工作流的补完

同期 v3.8 的 Automations 更新值得放在一起看，因为它补完了 cloud agent 的外部触发链路。

这次新增的五条 GitHub 触发——issue comment、PR review comment、PR review submitted、review thread updated、workflow run completed——本质上把 Cursor Automations 打造成了 GitHub Workflow 的智能层：原来需要人工判断和操作的事情，现在可以由 cloud agent 自动接手。

举一个具体的自动化场景：PR review comment 触发 → cloud agent 自动分析评论内容 → 在代码里做修改 → 提交新 commit 并回复评论。这个循环不需要人工介入，reviewer 看到的直接是修复结果，而不是"我会改"的承诺。

Slack 的 emoji 反应触发则把 automations 扩展到了团队协作层——任何人在任何频道看到值得自动化处理的事情，只需要加一个 emoji 就能 kick off 一个 automation。这降低了触发自动化的门槛，让 AI 自动化能力渗透到非技术成员。

竞争格局：从功能竞争到架构竞争

把最近几期的更新连起来看，Cursor 的战略方向变得清晰：

第一阶段：补全 agent 基础能力（Composer、agentic 编程、Auto-review）
第二阶段：把 agent 从本地搬到云端，建立分布式执行能力（Cloud agents、environment snapshots）
第三阶段：让 agent 的工作流和团队现有的协作工具链（GitHub、Slack）深度集成，变成团队工作流的智能中枢（Automations v3.8）

这个路径和 GitHub Copilot 的演进方向形成了有趣的对照：Copilot 强在 Microsoft 365 生态的集成、IDE 渗透率高，但 cloud agent 的分布式执行和团队自动化工作流能力，目前 Cursor 走得更快。

JetBrains AI Assistant 的挑战在于它本质上还是一个 IDE 插件，没有建立起云端 agent 执行的基础设施。Cursor 现在做的，是把"AI 编程工具"的定义从 IDE 插件扩展成一个有分布式执行层、有团队协作接口、有外部工具链集成能力的完整平台。

这条路的尽头，是 Cursor 自己在博客里写的那个愿景——"self-driving codebases"。但从这期更新来看，self-driving 不仅仅是"agent 自己写代码"，而是"agent 在完整的开发环境和团队协作上下文里，自主推进复杂任务"。基础设施的搭建，是通往这个终局的必经之路。