Cursor 里多个 Agent 同时跑：Agents Window、side chats 与多代理各解决什么

2026-08-18

「同时跑好几个 agent」听起来是一件事，在 Cursor 的官方文档里其实是五六个各自独立的机制，落在不同的页面上，隔离的层次也不一样。有的只把上下文分开，文件还是同一份；有的连 Git 检出都换了一份。选错形态会怎样，官方文档没有逐条列举，但它给 worktree 写的适用场景是「想在同一个仓库上启动好几个 agent 而不产生冲突」——这句话反过来读，就是选型时真正的分界线。

这篇不排名，只把官方文档写明的几种并行形态，按「你现在处于什么处境」串成一条决策路径，每一步标出文档写死的边界。文档没写的，我会直说没写。

先把「隔离」这个词拆开

Cursor 官方文档《Subagents》页写明，每个 subagent 有自己的 context window，长时间的检索与探索不占主对话空间——这是上下文层。《Worktrees》页写的是另一层：worktree 让 Agent 在隔离的 Git 检出里工作，每个任务拿到自己的文件、依赖与改动，主检出保持不动——这是工作区层。

两句话摆在一起，关键差别就出来了：subagent 文档描述的隔离止于 context window，这一页并没有说明 subagent 会拿到独立的文件检出。所以「几个 subagent 并行改代码会不会互相踩」这个问题，答案不能从 subagent 页里推出来。要文件层隔离就得显式走 worktree，别指望上下文隔离顺带把文件也隔了。

处境一：主线正跑着，你临时想问个旁支问题

这时候对应的形态是 side chat。Cursor 官方文档《Side chats》页写明，它是挂在父 agent 上的持久子对话，把父线程的历史作为参考上下文喂给模型，但这段历史不出现在 side chat 的可见记录里，那里只显示你的提问与追问。

打开方式文档给了三种：输入 /side 开一个空的 side chat（也可以在命令后直接跟上问题一次发出）；选中聊天里的文本或 diff 后选 Ask in Side Chat；或用快捷键把当前选中内容带进 side chat——文档写明的键位是 Mac：Shift+Cmd+S，Windows/Linux：Shift+Ctrl+S。反向把结论带回主线，文档写的是在主线里 @ 提及那个 side chat。

这里有三条边界，都是文档白纸黑字写的，也是最容易咬到人的地方：

默认偏向读。文档写明 side chat 默认聚焦在 reading、searching、answering，好让主 agent 不被打断。所以别指望它默认替你改文件。
不能嵌套。「Nesting is not supported」，side chat 里不能再开 side chat，只能回到父对话再开一个。
目前仅限本地。文档写明 side chats 是 local-only for now，当前不支持 Cloud Agents，并注明这项支持 coming soon。也就是说，你在云端跑的那条长任务上，暂时用不了这个口子。

文档还专门澄清了一点：side chat 不等于 fork。fork 会完整复制父对话（含所有消息与 subagent），side chat 只把父历史当隐藏上下文喂给模型。

处境二：一个任务能拆成互不相干的几块，你只想省主上下文

这时候对应 subagent。《Subagents》页写明 subagent 可以在编辑器、CLI 和 Cloud Agents 里使用，各自独立上下文，起步时上下文是干净的，父 agent 需要把必要信息写进 prompt——因为 subagent 拿不到之前的对话历史。

自定义 subagent 是一个带 YAML frontmatter 的 markdown 文件，文档列出的配置字段里，和并行直接相关的是这两个：

字段	类型	文档写明的默认值	作用
`readonly`	boolean	`false`	置为 `true` 时以受限写权限运行：不改文件，不执行会改变状态的 shell 命令
`is_background`	boolean	`false`	置为 `true` 时在后台运行，不阻塞父 agent

以上是文档写明的默认值，随版本可能变动。is_background 对应文档里 Foreground 与 Background 两档运行模式：前者阻塞直到 subagent 完成并立刻返回结果，后者立即返回、subagent 自己跑。

想让多个 subagent 同时开工，文档给的做法是在提示里直接表达并行意图（示例是「Review the API changes and update the documentation in parallel」），Agent 会在一条消息里发出多个 Task 工具调用。另一个更直接的入口写在《What is multi-agent coding?》页里：输入 /multitask，Cursor 会并行跑异步 subagent 而不是把请求排队；从一份计划出发，点击 Build in Parallel，Cursor 同时跑互相独立的步骤，有依赖关系的步骤仍按序执行。

边界也要一起记住。文档写明自 Cursor 2.5 起 subagent 可以再启动子 subagent，形成一棵树，但存在嵌套上限：主 agent 和它的直接 subagent 可以再启动 subagent，而被另一个 subagent 启动出来的 subagent 不能再往下启动；嵌套还需要当前模式下有 Task 工具权限，hooks 或工具策略可以阻止这类启动。代价文档也自己写了：并行执行意味着更高的 token 用量，subagent 带来的是上下文隔离而不是速度，简单任务交给它反而可能更慢，因为它要从零收集上下文。

处境三：几个 agent 要动同一个仓库的文件

到这一步才轮到 worktree。《Worktrees》页写明的适用场景就是：想在同一个仓库上启动好几个 agent 而不产生冲突。

先看一条容易踩的前置条件：文档写明该页描述的 UI-native worktree 功能仅在 Agents Window 可用，在 IDE 里要用的是本页后面那组 Worktree Skills 命令。同一个能力在两种形态里入口不同，在 IDE 里照着 Agents Window 那段找是找不到的。

IDE 侧文档给出的命令是 /worktree（这一段对话都在独立检出里进行）、/apply-worktree（把改动带回主检出）、/delete-worktree（用完清理）。文档给的示例原样如下：

/worktree fix the failing auth tests and update the login copy

想看当前仓库有哪些 worktree，文档给的是原生 Git 命令：

git worktree list

命令行侧，《Using the CLI》页写明传 -w 或 --worktree [name] 可以让 agent 在一个新的 Git worktree 里运行而不是直接改当前检出，这些检出创建在 ~/.cursor/worktrees/<reponame>/<name>，与编辑器创建的 worktree 放在一起；省略 name 时 Cursor 自己生成一个。需要显式指定仓库根目录时配合 --workspace <path>，否则用当前工作目录。文档原样给出的示例是：

# Create a temporary worktree from the current repository with a generated name
agent --worktree "upgrade the test runner and fix any broken snapshots"

# Create a named worktree from another repository
agent --workspace ~/src/my-app --worktree auth-fix "fix the flaky auth test and open a PR"

以上两条为官方文档原样给出的示例，我们未做实测；参数语义与实际行为以官方文档与 --help 的实际输出为准。

Windows 侧不要照抄 Unix 那一段

新检出里往往要重装依赖、拷环境变量文件，这部分靠 .cursor/worktrees.json 配置。文档写明 Cursor 在 Agents Window、IDE 和 Cursor CLI 创建 worktree 时都会读这个文件，查找顺序是先 worktree 路径、再项目根路径。该文件支持三个 setup 键（这是文档列出的全部三个）：

setup-worktree-unix：macOS 与 Linux 用，在 Unix 系统上优先于 setup-worktree
setup-worktree-windows：Windows 用，在 Windows 上优先于 setup-worktree
setup-worktree：所有操作系统的通用兜底

每个键既可以是一个按顺序执行的 shell 命令数组，也可以是一个相对于 .cursor/worktrees.json 的脚本文件路径。文档给出的分平台示例原样如下：

{
  "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"
  ]
}

环境变量的写法两侧不同：Unix 侧是 $ROOT_WORKTREE_PATH，Windows 命令数组里是 %ROOT_WORKTREE_PATH%，文档给的 PowerShell 脚本示例里则是 $env:ROOT_WORKTREE_PATH。只写通用的 setup-worktree、内容却是 Unix 语法，Windows 上这行就跑不通。脚本文件放在 .cursor/ 目录里与 worktrees.json 并列，文件名如 setup-worktree-windows.ps1。文档另外写明不推荐把依赖软链进 worktree，建议改用 bun、pnpm、uv 这类较快的包管理器；setup 出问题时的调试入口是编辑器 Output 面板里的 Worktrees Setup。

还有一条最容易翻车的：文档写明 Cursor 会按间隔自动清理旧 worktree，以限制磁盘占用，保留最新的若干个，上限是机器级的、设备上所有工作区共用同一个额度，对应两个 machine-scoped 设置项 cursor.worktreeCleanupIntervalHours 与 cursor.worktreeMaxCount（具体数值随版本变动，以官方文档为准）。关键在下一句——文档写明每次清理都会重新发现 worktree root，因此在管理器之外创建的 worktree（例如通过 /worktree skills 或 git worktree add 创建的）同样在可删除范围内，这一点值得在往里放长期分支之前先想清楚。文档注明该节描述的清理行为对应 Cursor 3.5 及之后的版本。

处境四：任务长到你想合上电脑

这时候形态换成云端。《What is multi-agent coding?》页给的做法是把长任务交给云端，需要自己动手时再把改动拉回本地。入口在 Agents Window——文档写明这是 Cursor 的 agent-first 工作区，可跨仓库、跨环境（本地、云端、远程 SSH 等）管理 agent，并列出了几项仅在 Agents Window 提供的能力：parallel agents（在云端跑多个并行 agent，并从手机、网页、Slack、GitHub、Linear 上跟进）、本地与云端之间的快速交接、cloud subagents，以及前面说的 worktrees。

cloud subagent 的入口文档写得很具体：输入 /in-cloud，你接下来提交的任务就作为 cloud subagent 运行，它会起自己的 VM 和分支；/babysit 则让 cloud subagent 远程盯着一个 PR，把它推进到可合并状态。文档同时写明，因为跑在云端 VM 上，它的 MCP 服务器来自你团队在 cursor.com/agents 上的配置，而不是你本地会话里的那套——这条对依赖自建 MCP 的团队是硬约束。

打开 Agents Window 的方式，官方文档写明是命令面板 Cmd+Shift+P → Open Agents Window，切回经典编辑器是 Cmd+Shift+P → Open IDE。这一页只给了 Cmd 键位，Windows 侧的对应键位官方文档在这一页没有写明。文档还写明 Agents Window 随 2026 年 4 月 2 日发布的 Cursor 3 正式可用。

处境五：同一个任务，你想让几个模型各写一版再挑

《Worktrees》页写明 /best-of-n 会用多个模型同时跑同一个任务，每一次运行各自拿到一个 worktree，候选之间以及与主检出之间互相隔离。文档给的示例格式是在命令后跟模型名列表再跟任务描述。这里有一条必须记住的边界：文档明说 /best-of-n 只做比较，不会替你把改动合回主检出；挑出胜者之后，要么直接从那个 worktree 提交推送，要么用 /apply-worktree 带回主检出。

一条压缩过的决策路径

把上面几段收成一句话式的对照：

你的处境	文档对应的形态	隔离到哪一层
主线在跑，想问个旁支问题	side chat（`/side`）	会话层：独立可见记录，父历史作隐藏参考
拆成互不相干的子任务，想省主上下文	subagent（含 `/multitask`、Build in Parallel）	上下文层：各自 context window；文件层文档未说明
多个 agent 要改同一个仓的文件	worktree（`/worktree`、CLI `--worktree`）	工作区层：独立 Git 检出、依赖与改动
任务很长，想离开电脑	cloud subagent（`/in-cloud`、`/babysit`）	环境层：独立 VM 与分支
想让多个模型各写一版	`/best-of-n`	工作区层：每次运行各自一个 worktree

真正会咬到你的，几乎都不在「能不能并行」这一栏，而在旁边那些限定语：side chat 不能嵌套、当前不支持 Cloud Agents（文档注明 coming soon）；UI-native 的 worktree 只在 Agents Window，IDE 走的是另一组命令；worktree 会被机器级上限自动清理，且手工 git worktree add 出来的也在清理范围里；subagent 的嵌套只有有限层数，且 hooks 与工具策略能拦；cloud subagent 的 MCP 来自团队配置而非本地。

最后提醒一句：worktrees.json 的 setup 键会在本机执行 shell 命令或脚本，提交进仓库就意味着任何人创建 worktree 时都会执行它们，值得先过一遍。这是通用做法，不是 Cursor 官方文档的内容。

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

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

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