4月27日消息，Cursor 更新三个功能：新增 /multitask 命令配套异步子代理（async subagents）能力，把多个请求拆给多个 worker 同时跑；把 Git Worktrees 直接集成进 Agents Window，支持在不同分支上后台并行做隔离任务、一键把任意分支拉回本地前台测试；引入多根工作区（Multi-root Workspaces），让单个 agent 会话能同时操作多个文件夹或仓库，覆盖前后端跨仓库改动这种场景。
整套更新延续了 Cursor 3 在桌面端围绕 Agents Window 重塑工作流的方向，把"Agent 数量"作为新的工作单元。
/multitask：把队列里的消息拆给一群 worker 并行跑
之前在 Cursor 里给 Agent 连续下指令，多条指令是按队列顺序串行执行的——前一条不跑完，后一条不会启动。3.2 引入的 /multitask 命令直接打破这个模型。在 Agents Window 里输入 /multitask 或点对应按钮，Cursor 会启动一组异步子代理（官方称为 workers）在后台并行处理请求；如果用户在对话框里已经堆了若干条排队的指令，可以让 Cursor 直接把已排队的消息切到 multitask 模式跑，不需要等当前任务结束。
/multitask 还会自动把单条较大的任务拆成多个小块分发给一队 worker 同时处理，处理过程中 Agents Window 提供实时计数器（live counter）显示哪些任务在跑、哪些还在队列、哪些正在被发出去，用户问"现在状态怎么样"也能拿到带进度的回答。这套设计的实际意义是把 Agent 从"一对一对话"模式改造成"一对多调度"模式——以前用户只能给一个 Agent 下任务等结果，现在可以同时摆出"重构 X 模块、写 Y 模块单测、修 Z 模块的 bug、补 README"这一串需求，让一组 worker 同时上手，自己继续做别的事。
Worktrees 集成进 Agents Window：分支隔离 + 一键切前台
Git Worktrees 的概念早就存在，但过去在 Cursor 里使用要么靠手动命令要么走 Cursor 3.0 引入的 /worktree 斜杠命令。3.2 直接把 Worktrees 嵌进 Agents Window 的核心交互里。
具体表现是用户可以在不同 Git 分支上分别启动 Agent 任务，每个任务在自己的 worktree 里跑，互不污染主工作目录；任务跑完后想看效果，从 Agents Window 选中任意一个 worktree 对应的分支，一键切到本地前台就能直接编辑、调试、运行测试。这种交互逻辑解决的痛点是"AI 一边帮你改代码、你一边在主分支上想做别的事会冲突"——以前的解法是开多个 Cursor 窗口或者手动 git worktree add 一堆目录，3.2 把这一切收进了一个统一面板。
Cursor 把这套机制和 /multitask 配合使用，就形成了"多个 worker 各自跑在独立 worktree 上，互不干扰，挑想看的拉到前台"的工作流，在状态栏底部还能看到当前的工作目录、worktree 与分支信息。
Multi-root Workspaces：单 Agent 会话同时操作多个仓库
Multi-root Workspaces 解决的是另一类长期痛点——一个改动横跨多个仓库时，需要在 Agent 之间反复切换上下文。Cursor 3.2 让单个 Agent 会话可以指向一个由多个文件夹组成的可复用工作区，覆盖前端、后端、共享库等跨仓库结构。
官方演示里给了一个具体例子：在一个项目里加一个 "Paused" 状态，Agent 自动在前端仓库做 TypeScript 类型与 UI 改动、在后端仓库改 API、补两边的测试和 README，最后给出一个汇总——"我改了什么、哪些地方明确选择不动"。
这套能力对维护 microservices 架构、monorepo 跨服务模块或同一项目跨多仓库分布的团队最有用，本质是让 Agent 不再受"一次会话只看一个 root"的约束。底层实现层面，扩展事件（文件变更、诊断更新等）在多根工作区里也按工作区作 scope 隔离，避免跨项目相互干扰；hooks 也已经修复为从所有工作区文件夹读取，不再只读第一个。
Cursor 与 Claude Code 这次几乎是在同一时间窗口里给出了"如何让 AI 编程支持并行工作"的两套不同答案。Claude Code 选择"多个独立会话各占一个 worktree、靠 sidebar 切换"的范式，每个会话仍是单线程，并行靠开多会话实现；Cursor 选择"单个会话内部就能拆出 async subagents 并行"的范式，再加上跨仓库工作区让一个会话本身能覆盖多个 root。 哲学差异在于 Claude Code 走的是 IDE 工作区路线、Cursor 走的是 IDE 改造路线（VS Code fork）。GitHub Copilot Workspace 仍以 issue 为最小单元，没有 session 级别的 worktree 隔离；OpenAI Codex 是云端优先但没有 sidebar session 管理；都没有 /multitask 这种"一条命令把一组请求并行化"的内建机制。从工程师的实际选择角度看，原本就用 Cursor 当主力 IDE 的人这次能直接拿到并行能力，几乎零迁移成本；偏好 Cursor + Claude Code CLI 混合工作流的人现在两边都拿到了并行原语，可以根据任务粒度自由分配。 局限与开放问题
并行带来的好处明确，但代价同样实在，几个问题官方没有完整回答。
其一，多个 worker 同时编辑同一个文件时怎么处理冲突——是采取乐观锁、版本合并、还是简单按时间序覆盖，目前没有公开的合并语义说明；
其二，任务之间的依赖关系如何被识别——比如 task B 必须等 task A 跑完才能启动（典型场景：先生成接口契约，再让另一个 worker 写客户端），3.2 没有给出显式的依赖描述语法，用户得靠把指令拆好或者人工排队；
其三，worktrees 分叉后的合并 story 仍是手工的——把多个分支拉回前台测试容易，但最终怎么整合回主分支、冲突怎么解决，要回到常规 git 工作流；
其四，/multitask 自动拆解大任务的颗粒度由 Cursor 自己判断，拆错了的回滚机制和成本目前不透明；
其五，并行 worker 数量上限、每个 worker 占用的额度计费规则、模型调度策略（不同 worker 是否会用不同模型、是否能强制指定）这些细节文档目前比较薄；
其六，对于体量较大、依赖复杂的 monorepo，多根工作区的索引与上下文检索性能会不会被拖慢，社区还需要时间反馈；
其七，Cursor 3.2 的工作流默认推用户用 Agents Window，老用户在传统 IDE 视图下能调用的并行能力相对受限，习惯切换需要时间；
其八，/multitask 把"对话历史"概念稀释了——一组 worker 各自有自己的执行轨迹，最后给用户的合并报告由 Cursor 决定怎么呈现，用户对每个子代理的细节追溯成本会更高。
整体看，Cursor 3.2 把"并行 Agent"从"靠用户开多个会话/窗口手动模拟"提升为"系统原语"。/multitask 把队列模型直接打散，Worktrees 让并行不再以"代码冲突"为代价，多根工作区让单个会话能跨越仓库边界——三件事合在一起改变的是 AI 编程的基本工作单元：从"一个 prompt 对应一次 Agent 跑"变成"一个目标对应一组 Agent 协同跑"。
下一步真正决定这套范式价值的是冲突解决、依赖管理、多 worker 报告的可追溯性这些看起来不性感但工程上更难的部分。
AI 速览
