Cursor 云端 Agent 还是本地 Agent：按任务形态选，不按快慢选

2026-08-18

选云端还是本地，很多人第一反应是问”哪个快”。这个问题我们答不了——没有实测依据，官方文档也不承诺运行速度。文档能给的是另一样东西：两种形态各自把边界划在哪。边界这东西不会因为你手速快就消失，它会在某个具体时刻咬你一口，比如你发现挂了半年的密钥扫描脚本在云端根本没跑。

下面这条决策路径，全部依据 cursor.com/docs 与 cursor.com/help 上写明的机制。每一步都是一个能自己回答的问题。

分叉一：这次改动能不能从干净的 git 状态开始

这是第一个也是最容易被忽略的岔口。

Cursor 帮助中心《Cloud Agents》页写得很直白：“Move to Cloud” 不会快照你本地未提交的改动，云端 agent 从远端仓库的干净 git 状态起步；它会带走你的对话历史和上下文，但不带脏文件和未提交的编辑。同一页还给了处置：想让 agent 从你最新的状态开始，就先 commit 或 stash。

本地 agent 没有这个断点，它就在你当前工作区里干活。

所以这条分叉的判据不是任务难度，而是你手上的改动有没有落进 git。已经改了一半、依赖一堆未提交的实验性代码、或者本地有 .env 之类不进版本库的东西——搬到云端就是从零开始，你会得到一个基于旧代码的 PR，还找不到是哪里出的岔子。

分叉二：你要不要在过程中卡审批

这是两种形态差得最远的一处，而且文档把话说死了。

《Run Modes》页最后一节标题直接写着 Cloud Agents do not use Run Modes：Run Modes 只作用于本地 agent，Cloud Agent 跑在自己的专用机器上，不会向你请求批准任何动作。

《Secrets & Network》页把同一件事从风险角度又说了一遍：cloud agent 自动执行所有终端命令，以便它自己迭代测试，这一点与需要逐条批准的 foreground agent 不同；该页并自述自动执行会引入数据外泄风险——攻击者可以通过提示注入诱导 agent 把代码上传到恶意站点。这是文档自己写的话，不是我们的推断。

本地这一侧的对应机制是 Run Modes 三档，官方文档表格里列的就是这三行：

模式	不问就跑的部分	sandbox	分类器
Auto-review	允许清单内的调用立即执行；其余 shell 命令尽可能在 sandbox 里跑；无法用 sandbox 的交给分类器	对 shell 命令启用	有
Allowlist	允许清单里的动作免批准；开启 sandboxing 后受支持的 shell 命令可在 sandbox 内运行	对 shell 命令可选	无
Run Everything	每个工具调用都自动执行	无	无

要注意的是，同一页明确写了 Auto-review 不是安全边界：分类器会犯错，既可能放行你本会拦下的调用，也可能拦下你本会放行的调用。这句照实抄给你，别把它当成”有分类器所以安全”。

想调整审批口径，Auto-review 读的是 permissions.json，官方文档给的示例是这样：

{
  "autoRun": {
    "allow_instructions": [],
    "block_instructions": [
      "Every AWS CLI command should go through approval first.",
      "Every command that modifies Kubernetes resources should go through approval first."
    ]
  }
}

文档写明它读两个位置：~/.cursor/permissions.json 作用于本机所有项目目录，<project-dir>/.cursor/permissions.json 只作用于一个项目目录；两者都存在时会合并。另有一条容易踩：团队在面板里定义了全局 Auto-review 配置时，团队配置优先，用户级与项目级文件会被忽略。

Windows 侧要单独说一句。 Run Modes 页讲 sandbox 的平台实现时，只写了 macOS（Seatbelt，经 sandbox-exec）和 Linux（Landlock 加 seccomp，并列出了内核与 unprivileged user namespaces 的要求），没有 Windows 那一段。我们不去猜 Windows 上 sandbox 是什么行为，官方文档在这一页没有说明这一点。这意味着如果你在 Windows 上把”有 sandbox”当成前提来设计流程，你的前提在文档里找不到出处。

分叉三：你的治理脚本要不要一起生效

如果你已经用 hooks 挂了格式化、审计、密钥扫描，这一条决定它们搬不搬得过去。

《Hooks》页有专门的 Cloud agent support 小节。可核到的边界有这么几条，都写得很具体：

云端只跑 command-based hooks。prompt-based hooks 不支持，文档给的理由是这类 hook 需要在 hook 与 agent loop 之间做认证串联，云端执行环境里没有。
用户级 ~/.cursor/hooks.json 不加载——云端 VM 访问不到你本地 home 目录的配置。项目级 .cursor/hooks.json 会被拾取并运行；Enterprise 方案下还会跑 team hooks 与 enterprise 托管的 hooks。
云端 agent 有时会以只读环境开始早期探索回合，那些回合里 hooks 不运行，要等 agent 拿到可写环境才开始。

支持矩阵里明确标为 Yes 的有 14 个（回源逐行数过：beforeShellExecution、afterShellExecution、beforeReadFile、afterFileEdit、preToolUse、postToolUse、postToolUseFailure、subagentStart、subagentStop、beforeSubmitPrompt、preCompact、afterAgentResponse、afterAgentThought、stop）。

不可用的那张表更值得盯：sessionStart、sessionEnd、beforeMCPExecution / afterMCPExecution、beforeTabFileRead / afterTabFileEdit、workspaceOpen。理由文档都写了——sessionEnd 绑的是 IDE 会话生命周期，云端 agent 没有编辑器寿命这个边界；Tab hooks 和 workspaceOpen 是 IDE 特性；MCP 那两个则是因为只读起步时 hook 加载与时序不确定而被推迟。

这条分叉的实际后果很直接：你的 MCP 调用审计如果挂在 beforeMCPExecution 上，那它在云端是空的。 同一件治理，本地拦得住，云端拦不住。要搬，就得把策略改挂到云端支持的那 14 个之一上——比如把 shell 侧的拦截放在 beforeShellExecution，把工具侧的放在 preToolUse。

分叉四：任务需不需要”跑起来看”

这一条不是本地做不到，而是两边的做法根本不在一个语境里。

《Capabilities》页写明：每个 cloud agent 跑在自己的隔离 VM 里，带完整桌面环境，可以用鼠标键盘操作桌面和浏览器；因此它能起 dev server、在浏览器里打开应用、点过 UI 流程，在推 PR 前验证改动。文档还写明 agent 会产出 artifacts（截图、视频、日志引用）挂到 PR 上，你也可以接管它的远程桌面自己操作，再把控制权交还给它继续干活。

本地这一侧，跑起来看这件事本来就发生在你自己的机器上，不存在”要不要给它一台机器”的问题。所以这个维度严格说不构成对照，它构成的是一个前置条件问题：你的仓库能不能在一台干净 VM 里跑起来。《Best Practices》页把这条写成了明确建议——你的仓库应该能在本地良好运行、不依赖 VM 触及不到的外部服务，并且原话给了判据：如果一个人类开发者都难以在本地测试，agent 同样会难。

artifacts 有一处必须照实标出来。文档写明，把 artifacts 直接嵌进 GitHub PR 描述是 opt-in，需要在 Cloud Agents 面板里开启 Allow posting artifacts to GitHub；开启后，因为 GitHub 的图片代理要求公开 URL，PR 描述里的 artifacts 使用长而不可猜的 URL，无需认证即可查看。这是白纸黑字的机制说明，不是我们的评价，但它显然会影响你要不要在私有仓库上打开这个开关。

分叉五：并行怎么开

云端这一侧，《Cloud Agents》页写明你可以并行跑任意多个 agent，且不要求你的本地机器保持联网。同页还写了多仓环境：一个 agent 可以跨前端、后端、基础设施、共享库多个仓库工作，并在它改动的仓库里各自开 PR——但同一段也标了 long-running 目前还不支持多仓环境。

本地这一侧的并行走的是 worktrees。文档写明 UI 原生的 worktrees 只在 Agents Window 里有；在 IDE 里用 /worktree 与 /best-of-n 这两个命令。/best-of-n 让同一个任务在多个模型上各跑一份，每份有自己的 worktree，文档同时提醒它只做比较，不会替你把改动合回主 checkout。

worktree 的初始化脚本用 .cursor/worktrees.json 配置，它有三个 setup 键，其中一个是专给 Windows 的。官方文档的 OS 分支示例原样如下：

{
  "setup-worktree-unix": [
    "npm ci",
    "cp $ROOT_WORKTREE_PATH/.env .env",
    "chmod +x scripts/*.sh"
  ],
  "setup-worktree-windows": [
    "npm ci",
    "copy %ROOT_WORKTREE_PATH%\\.env .env"
  ]
}

文档写明 setup-worktree-windows 在 Windows 上优先于通用的 setup-worktree，键值既可以是一串依次执行的 shell 命令，也可以是一个相对 .cursor/worktrees.json 的脚本文件路径（Windows 侧的示例给的是 .ps1）。另外它明确不建议把依赖用符号链接接进 worktree，理由是会影响主 worktree。

分叉六：网络出口与私有资源

云端的出口控制是三档模式：允许全部外部主机、默认域名加你的允许清单、仅允许清单。文档还写明即使在”仅允许清单”下，仍有一小组域名保持可达以保证 agent 能工作（Cursor 自身服务与源码托管方）。artifacts 上传有固定主机，文档明确要求把确切主机加进允许清单，并直接劝阻用通配符放开整个区域的 S3——理由它自己写了：通配符会给被提示注入的 agent 开出一条外泄路径。

私有资源方面，文档给的是在 Cloud Agent 环境里跑 Tailscale userspace networking、Cloudflare Tunnel 或类似的私网客户端，让服务不必对公网开放入站。

本地 sandbox 的网络也是三档（sandbox.json Only、sandbox.json + Defaults、Allow All），且文档写明两边共用同一份默认域名清单与团队级允许清单——管理员在面板上配一份，同时作用于 Cloud Agent 的网络访问和 sandbox 网络策略。这是少数几处两边真正打通的地方。

还有一条硬门槛：Privacy Mode (Legacy) 不支持 Cloud Agents。文档给的理由是 legacy 模式阻止云端数据存储，而 Cloud Agent 运行期间需要在云端存放代码与环境数据；要用就得先切到 Privacy Mode。

这些维度我们没有依据，不比

快慢。两边文档都没有给运行速度的承诺或口径，我们也没有实测。
生成质量。同上，且模型选择本身是另一回事。
成本。文档写明 Cloud Agent 按所选模型的 API 定价计费，且更大的上下文窗口会增加 token 用量与成本——这是机制，不是数值；具体数字请看官方定价页，本文不写。
稳定性。没有任何一方给出可核的指标。

另外有一处口径差值得单独记：CI 自动修复。文档写明 Cloud Agent 会自动尝试修复它自己创建的 PR 上的 CI 失败，但目前只支持 GitHub Actions，并且目前只在 Teams 方案上可用，非 Teams 账户的支持文档写的是 coming soon。文档同时列了它主动跳过自动跟进的几种情形：你自己往分支推了新 commit（它不会去自动修人类 commit 引起的失败）、你给 agent 发了后续消息、同一个检查在 PR 的 base commit 上本来就是失败的、以及该 PR 的 CI 失败跟进次数已经用完（具体次数以官方文档为准）。单个 PR 上可以用评论 @cursor autofix off 关掉，@cursor autofix on 重新打开。

把路径压成一句话

按顺序走：改动在不在 git 里 → 要不要人卡审批 → 治理 hooks 搬不搬得过去 → 要不要一台能跑起来的机器 → 并行走 worktree 还是走云 → 出口能不能收住。 六个问题里只要有一个的答案把你钉在某一侧，选择就定了，剩下的都是配置问题。

真正会咬人的是第一和第三条：起始 git 状态是静默失效——你不会收到任何提示，只会拿到一个基于旧代码的 PR；hooks 也是静默失效——beforeMCPExecution 在云端不报错，它只是不存在。这两处都值得在切换形态前先回官方文档核一遍。

Cursor 迭代频繁，本文涉及的设置项、hook 名称、配置键与支持矩阵都会随版本变动，请以官方文档最新内容为准。

本文依据 Cursor 官方文档（cursor.com/docs 与 cursor.com/help）于 2026-08-18 的公开内容整理。该产品闭源，本文只复述官方文档写明的机制，不推断其内部实现； 我们没有对文中涉及的功能做过实测，因此不涉及界面外观、操作手感与运行速度的任何描述。该产品迭代频繁，文中涉及的设置项与命令随版本变动，请以官方文档最新内容为准。本文不涉及订阅价格、额度与模型清单，相关信息请以官方定价与模型说明页为准。

本文对照的是同一产品内的两种形态，依据均为上述官方文档，不对两种形态做优劣排名，选型结论只在官方文档写明的能力边界内成立。

安全与合规相关做法请结合自身环境评估，本文不构成安全方案建议。