Cursor Projects 多人协作指南（2026 Beta）

2026 年 11 月 10 日，Cursor 将 Projects 从单人编排工具升级为多人团队工作区。现在，协调器 Agent 可以与队友的协调器互发消息、标记代码修改冲突，还能交接尚未完成的 Pull Request。要让这套流程稳定运行，团队需要使用 Teams 账户，并运行 Cursor 3.26.13 或更高版本；同时还必须明确共享上下文文件的管理规则，避免某个 Agent 未经确认的假设覆盖整个仓库的协作计划。

从单协调器到团队协作：11 月 10 日到底变了什么

Cursor Multiplayer Projects 将原本于 2026 年 9 月 10 日推出的单用户 Projects beta，升级成了多人工作区。每位成员都拥有独立的 1 对 1 协调器聊天，同时共享一块 Task Board 和一个 Project Agent Store（/cursor/stores/self）。根据Cursor 官方 Projects 文档，11 月 10 日的更新在以下八个核心维度上，将个人执行空间与团队共享状态分离开来：

使用资格、邀请机制与两阶段工作区设置

根据Cursor Projects 文档，共享多人 Project 需要 Cursor Teams 或 Enterprise 账户、3.26.13 或更高版本的客户端，以及每位受邀成员对目标仓库的独立访问权限。Free、Plus 和 Legacy Hobby 方案不支持多人共享。如果启用了 Privacy Mode (Legacy)、Project 运行在自托管机器上，或 Project 已归档，也无法邀请队友。

第一阶段：创建基础 Project（4 步）

邀请协作者前，Project 所有者需要先在 Cursor 的 Agents Window 中初始化工作区：

1. 从左侧导航打开 Projects：打开 Agents Window，在侧边栏找到 Projects，然后选择 New Project。
2. 命名 Project：选择图标并填写一个范围清晰、面向具体结果的名称；如果留空，默认名称为 New Project。不要为整个仓库只建一个庞大的 Project，最好按交付目标拆分，例如分别为数据库结构迁移、多 PR 功能和持续性 CI 维护创建 Project。
3. 选择工作区和协调器模型：在 Workspace 下选择目标 GitHub 仓库；如果尚未连接 GitHub，请点击 Connect GitHub。然后在 Model 下选择负责协调工作的模型。
4. 点击 Create Project：Cursor 会为 Project 配置云电脑，并打开与协调器 Agent 的 1 对 1 线程。

如果你已经在符合条件的顶层 Cloud Agent 聊天中完成了初步工作范围定义，可以将该聊天从侧边栏拖到 Project 条目上，或者打开聊天菜单并选择 Add to Project，让协调器读取此前的对话记录。如果对本地聊天使用该选项，Cursor 会先将其转换为 Remote Control，再添加到 Project。

第二阶段：分 3 步邀请队友

Project 启动并连接仓库后，所有者或现有成员都可以按以下三个步骤邀请队友：

1. 打开邀请菜单：在 Project 顶部选择 Invite。完成第一次邀请后，这个控件会变成一排头像。
2. 邀请队友或复制共享链接：在 Invite teammates to this project 下按姓名或邮箱搜索队友并发送邀请；也可以选择 Copy link，再把 Project URL 分享到 Slack 或 Linear。
3. 队友接受邀请并获得专属聊天：受邀者在 Project 邀请卡片上点击 Accept Invite 后，会获得自己的 Project 聊天、专属协调器 Agent，以及共享 Project 上下文的读写权限。

成员与链接权限控制

访问边界同时由 Cursor 团队权限和 Git 仓库权限共同控制：

• 必须属于同一团队并拥有仓库权限：个人账户用户以及来自其他 Cursor 团队的开发者无法加入。受邀队友还必须独立拥有该 Project 仓库的访问权限。
• 撤销泄露的邀请链接：只有现有 Project 成员可以复制邀请链接。如果链接被过度传播，Project 所有者可以打开邀请菜单并选择 Reset Share Link，使之前生成的所有链接失效。
• 退出或移除成员：任何参与者都可以从侧边栏菜单选择 Leave Project（之后可通过有效邀请或链接重新加入）；Project 所有者则可以在邀请菜单中选择 Remove 移除成员。

共享上下文（/cursor/stores/self）与个人存储区（/cursor/stores/user）

按照Cursor Projects Context and Personal Store 文档的定义，Cursor Multiplayer Projects 通过两个不同的文件系统路径，将个人开发者配置与团队知识分开挂载到每个 Agent 的环境中：/cursor/stores/self 用于共享 Project 上下文，/cursor/stores/user 用于个人用户存储区。根据官方存储区规则，队友加入共享 Project 后，其协调器可能会建议把 /cursor/stores/user 中相关的工作偏好复制到 Project 规则中，但只有用户明确批准的条目才会被复制。

协调器 Agent 如何通过不受信任的侧边聊天互相沟通

当一个协调器需要了解队友的工作时，Cursor Projects 多人协作规范允许它从接收方的普通聊天中分叉出名为 Chat with {name}'s agent 的侧边聊天，并直接向对方的协调器发送消息。Cursor 限制了这种分叉聊天能够执行的操作，因此外部查询不会打断接收方正在进行的主线程，也无法借此泄露机密。

在 Cursor 发布的2026 年 11 月 10 日多人协作公告中，产品经理 Aryaman Khandelwal 介绍了两种主要的跨 Agent 协作场景：

• UI 与功能发生重叠：一名工程师为产品页面添加客户评价，另一名设计师同时重做该页面。双方协调器可以提前发现冲突，将评价组件直接纳入新布局，而不是之后再返工。
• 数据库结构与读取方的时序：一名开发者修改数据库结构，队友同时开发读取该数据库的功能。两个 Agent 可以提前确定执行顺序，避免合并时发生集成冲突。

根据官方 Cursor Projects 文档中“协调器如何互相发送消息”的说明，这类交流遵循四条严格规则：

1. 发起查询：队友 A 的协调器发现依赖队友 B 工作的事项后，直接向队友 B 的协调器发消息。
2. 创建分叉侧边聊天：收到消息后，系统会从队友 B 的普通聊天中创建一个侧边聊天，名称为 Chat with {Teammate A}'s agent。
3. 按不受信任内容处理：收到的协调器消息会被标记为 Agent 输入，接收方会看到消息来自哪位队友的 Agent；接收 Agent 必须把它当作需要评估的不受信任材料，而不是自己用户直接提出的请求。
4. 使用主聊天知识回答，并在下一轮提醒：侧边聊天会根据接收方主聊天可用的知识作答，并将结果返回给发送方协调器。队友 B 的主聊天不会立即被打断，而是在下一轮收到有关此次交流的提示。

Cursor Projects 文档定义了每个 Chat with {name}'s agent 分叉侧边聊天的具体权限边界：

从规划到交付的理想流程，为什么在 Beta 中仍会失控

Cursor 官方示例展示了这样的场景：新加入值班的工程师，其协调器可以接手当前事故、Linear 看板和 Slack 线程。但单人 Projects Beta 的实测报告显示，在项目四个生命周期阶段中仍存在四类运营风险，团队需要额外设置防护规则：

可变 Project Notes 与“共享错误”问题

开发者 Lutz Leonhardt 在Cursor Community Forum发布了一份为期 3 天的 Cursor Projects Beta 实测报告，包含 5 次会话、约 14 小时、20 个 Agent、32 个任务、49 次 Agent 运行，以及 5 个 Pull Request（其中 4 个已合并）。他检查了同步的上下文目录和编排器记录。虽然任务分派和交付最终成功，并修复了 Codex 审查机器人发现的全部 18 个问题，但项目记忆层暴露出两类问题；如果把它们放大到多人共享存储区，风险会更高：

• 重写 111 次，却只明确读取 1 次：在 3 天测试中，协调器通过整文件替换重写 Project Notes 111 次，但明确读取该文件只有一次。第二天开始归档前，里程碑 1 已从记录中消失；而对 Podcast LLM 分析的明确批准在两次重写后被压缩成 "done"，导致协调器第二天再次卡在同一个审批上。
• 把未经批准的默认值写成决策：协调器列出 5 个关键词和 3 个待解决问题后，开发者询问了 API key，并询问能否开始里程碑 2。协调器将未经确认的默认值视为 "accepted for the start"，并启动了一个实现常驻 cron 适配器的 Agent，这与它此前的建议相矛盾。另一次交流中，协调器否认收到一个自己已经执行过的 Worker 交接，并把这段错误历史写入上下文目录，变成了工作流规则。

Leonhardt 测试的是单人 Projects，但多人模式下，每位队友的 Agent 都会读写 /cursor/stores/self。因此，任何被污染的记录或未经验证的 Agent 默认行为，都可能影响之后读取共享存储区的其他队友 Agent。多人协作上线后，开发者 @avisinghdotdev 在 X 上表示：

“说实话，我不喜欢 Agent 和队友的 Agent 对话，尤其是双方有不同的规则和技能时。一次低质量输出就可能拉低整体质量。”——@avisinghdotdev

多人 Projects 的建议防护措施：不要让协调器把 /cursor/stores/self 中的单个可变 Markdown 文件同时当作临时草稿和决策记录。应在 Project 规则中将状态拆分为两个文件：

1. 可变的 plan.md，用于记录任务状态和当前分支指针。
2. 提交到仓库的 decisions.md，由只追加规则管理；在需要严格执行时，再配合 Git diff 审查或分支保护。每条记录包含 date、decided_by（human:@handle 或 agent:proposed）、status（proposed、accepted、superseded）、applies_to（文件路径 glob）以及一行 rationale。

过期检出、云端 MCP 不一致与本地 Worktree 交接

第二类 Beta 问题源于 Cursor 默认采用云端执行架构。根据Day 7 Cursor Projects receipt中的已验证用户报告和 r/cursor 讨论，团队采用 Projects 时需要注意四个陷阱：

1. 长期 Project 使用过期 Git 检出：长期运行的云端 Project 不会自动从 main 拉取已合并的修改（Day 7 Report R1；Cursor 工作人员确认这是预期行为，并建议要求协调器执行拉取）。多人协作时，务必要求协调器在分派新任务前运行 git pull。
2. 只加载云端 MCP 服务：协调器以 Cloud Agent 形式运行，因此只会读取 Cursor 云端设置中配置的 Model Context Protocol（MCP）服务（Day 7 Report R6）。仅配置在本地桌面编辑器中的 MCP 服务不会加载到 Project 协调器中。
3. “No self-hosted workers available”开关陷阱：如果要从云端 Project 运行本地测试，需要在 Settings > Agents 中启用 Remote Control（本地自托管 Worker），然后在仓库根目录运行 agent login，再运行 agent worker start。不过，启用 Remote Control 也可能同时打开 Self-hosted Machines，并在团队管理后台激活 Require Self-hosted Machines and Personal Machines。这会阻止 Cloud Agent 和 Projects 在 Cursor 云端运行。团队管理员应关闭这个 Require 开关，以保留云端与本地混合执行能力。
4. 云端 Token 消耗：同时运行 10 到 20 个云端子 Agent 会快速消耗方案额度。r/cursor 用户 u/Shirc 在 Reddit 上表示：

“Projects 很有潜力，但现在还有点混乱，而且绝对会快速烧掉 Token。”——r/cursor 的 u/Shirc

在同一个 r/cursor 讨论串中，开发者 u/dryu12 建议将 Composer 设为协调器模型，并明确规定哪些委派任务应交给哪些模型。如果团队还运行 Cursor 内置计费体系之外的外部 CI 审查机器人或自定义 Agent 脚本，可以通过AIReiter转发这些 API 调用，在一个按量付费余额中组合低成本模型DeepSeek V4.1 Flash和审查模型Claude Opus 5.5。

PR 审查冲突：为什么每个 Pull Request 都需要唯一负责人

根据Cursor Projects 订阅文档，只要至少存在 1 项订阅——例如监听 Slack 频道、PR 活动、某个分支上的 CI 运行，或设置 every day at 8:00 AM 这样的计划任务——聊天输入框上方就会出现 Listening 标记。

在 Leonhardt 的 3 天单人测试中，PR 审查处理已经存在归属不清的问题，因为协调器、最初负责实现的 Worker 以及后来创建的修复 Agent 都可能响应审查事件。有一个 PR 中，协调器两次询问作者是否完成修复，但原始 Agent 已经在处理；另一个 PR 中，3 个 Agent同时重写了同一个状态文件，还留下了错误的作者信息。

当多个队友在同一仓库中运行协调器时，如果多个协调器都订阅范围过大的仓库级 PR 事件，就更容易产生重复修复提交和无效的云端运行。开发者 @LabubuNoBB 在 X 上说：

“让 Agent 互相交流从来不是最难的部分。真正难的是，当两个 Agent 都想修改同一个文件时，决定到底谁负责什么。”——@LabubuNoBB

建议的 PR 归属规则：在共享 Task Board 上为每个 PR 指定一名人类负责人和一个指定 Agent，并由他们负责该分支上的全部审查意见。同时，将每位队友协调器的订阅范围限制在自己的 PR 上，不要使用覆盖整个仓库的通配订阅。

团队上线决策表：什么时候共享 Project，什么时候保留独立聊天

在把团队工作流迁移到共享 Cursor Project 之前，应根据 3.26.13+ Beta 中已经验证的限制，对照任务结构选择合适的模式：