AREX Feed Article
Cursor 宣布 Projects 重建为多人协作版：队友的 agent 可相互协调，beta 向所有用户推出
北京时间 2026 年 11 月 11 日早上 7 时 20 分（UTC 时间 11 月 10 日 23 时 20 分），Cursor 官方账号 ：用户的 agent 现在可以与队友的 agent 相互协调（coordinate），Projects 已为多人协作（multiplayer）重建，每个团队成员及其 agent 可以在同一个统一工作区（unified workspace）中共同工作。3 秒后，同一账号补充了名称与机制：这一能力名为 Team Projects，为每位成员及其 agent 提供共享上下文——agent 开工前共享计划、工作中标记冲突，并在团队内互相解锁任务，今日以 beta 推出。
Cursor 同步上线了官方博客《》，把这次变更称作 Projects 9 月发布以来的一次重大升级，并称「多 agent 系统至今只服务一个人，Projects 是一个为整个团队构建的多 agent 系统」。博客称 beta 自发布当日起向 Cursor 所有用户推出；本文中的产品能力描述均出自 Cursor 的公告与配套文档。
共享任务板：谁在做什么、哪个 agent 在做、对应哪个 PR
博客把升级后的 Projects 描述为一个团队与全部 agent 共处的协作空间：共享任务板显示谁在做什么、每个人的 agent 正在处理什么，以及每项任务背后对应的 PR（拉取请求），人和 agent 看到的是同一份实时视图；工作区同时带有共享的上下文、记忆与文档。Cursor 在博客中称，这是「第一个软件团队与自己的全部 agent 并肩工作」的工作区，并称市面上的协作软件并不缺，缺的是给编码 agent 的。
配套的官方示意图画出了这个结构：工程师、设计师、PM（产品经理）三位成员各拥有一个负责调度和分派工作的 coordinator（协调者），coordinator 之间以双向箭头连接，每个 coordinator 之下各挂一组执行具体编码任务的 worker agent，所有人共用底部的共享上下文层——文件夹、文件、Markdown 笔记、聊天记录、计划与决定、记忆，以及「谁在做什么」。
共享上下文一次建立，全队 agent 读写，个人存储对队友不可见
Cursor 把核心改动归纳为一套「面向整个团队的统一上下文系统」。博客称，目前 agent 的上下文按个人隔离，新成员要先自己搭建上下文才能让 agent 干活；而在多人 Project 里，每个成员仍保留自己与 coordinator 和 worker agent 的一对一聊天，各带本地上下文，其上叠加一层共享上下文，存放需求文档、图表、技术规格、设计稿等材料。一次聊天中做出的决定，Project 里的每个 agent 都能读到；新成员受邀加入时，上下文已预先配置且保持最新，省去重复搭建。
Cursor 用自家场景作例证：公司内部已有多个团队把 on-call（线上值班）轮值放进共享 Project。博客举例说，一位工程师近期从队友手中接管轮值时，其 coordinator 先确认情况再接手，已经掌握哪些工作在途、哪些问题无人跟进、哪些事件与记录需要交接，以及要盯住哪些频道、Linear 看板和线程；在途工作可以直接移交，由新成员的 agent 接手处理。
文档把存储边界写得：Project 的共享上下文是一个所有成员的 agent 都可读写的 Agent Store，路径为 /cursor/stores/self；每个成员另有挂在 /cursor/stores/user 的个人存储，队友的 agent 看不到，其中存放跟随用户跨 Project 的偏好与技能。成员加入时，coordinator 可以提议把个人偏好中描述该项目工作方式的条目复制进 Project 规则，且只复制经用户批准的部分。
Coordinator 直接互发消息：按「agent 输入」处理，走边聊不打断本人
文档说明了 agent 间协调的落地方式：当你的 coordinator 需要队友那边的东西时，它直接向对方的 coordinator 发消息，不需要本人来回传话。每条消息按三条规则处理。接收方会被告知消息来自哪位队友的 agent，并把它当作需要权衡的「agent 输入」，而不是雇主下达的请求，涉及读取对方个人文件或连接器数据前须先询问。队友的消息不会打断你的聊天，而是进入一条从你的聊天分叉出的边聊（side chat），名为「Chat with {name}'s agent」，边聊基于你聊天已知的内容作答，回复送回发送方的聊天，你的聊天在下一轮收到一条交换说明。边聊只能回答：你可以阅读、停止或归档它，但它不共享密钥、凭证或令牌，能读任务板却不能改，也不能向你提问、申请权限、连接代码托管或管理例行任务。
博客给出两个典型场景：工程师在产品页上加评论功能、设计师同时在重设计这个页面时，两个 coordinator 会提早发现重叠并同步，评论功能直接做进新设计，省去日后返工；你的功能要读某个数据库、队友正在改它的表结构时，双方 agent 会事先商定工作顺序，避免最后撞上合并冲突。
从 9 月的单人版 Projects 到 10 月论坛里的多人请求
Projects 于 2026 年 9 月 10 日，当时的定位是让工程师通过一个 coordinator 调度大批 agent 完成大型工作：coordinator 不自己写代码，负责规划并把任务分派给并行运行的子 agent；Project 默认在云端运行、维护跨任务的共享上下文，还能订阅 Slack 频道或按计划自动执行。Cursor 当时给出的数据是：新用户合并的 PR 多了 30%，主要使用 Projects 的用户合并的 PR 是原来的 6 倍；公司内部一个维护设计系统的 Project 有望每天经手 20～100 个 PR。
「多人」正是当时的缺口。10 月 20 日，论坛用户 Elliot_Hesp 在 Cursor 官方论坛说 Projects「非常偏『单人模式』」：他看得到自己的 agent 和自己的任务板，看不到队友的；队友的 agent 卡在哪里、发现了什么问题，他得去问本人，或碰巧在 GitHub issue 里撞见；「共享上下文」只在同一个 Project 内部的 agent 之间共享，跨成员并不互通。他列出的愿望——队友的 agent 能与自己的 agent 交接工作，而不是「坐在两个互相看不见的房间里」——与这次升级公布的任务板、跨成员共享上下文和 agent 间直接协调一一对应。
加入的门槛：团队账户、Cursor 3.26.13 与同队仓库权限
文档把门槛写得更具体：Projects 本身需要包含 Cloud Agent（云端 agent）的套餐，即 Premium 及以上、Teams、Enterprise 和旧版付费计划，Free、Plus 与旧版 Hobby 不可用；企业团队需要 Cursor 3.21.9 或更高版本。开启多人分享还需要团队账户和 Cursor 3.26.13 及以上版本。
加入需要邀请，Project 只在同一个 Cursor 团队内共享，个人账户或来自其他团队的账户无法加入；受邀成员还须拥有该 Project 仓库的访问权限。Privacy Mode（Legacy）、运行在自托管机器上的 Project 和已归档的 Project 均不支持加入。计费方面，文档写明每个加入者的聊天以本人身份运行并计费，公告与文档均未列出 Team Projects 的单独定价。
回复区反复追问并发冲突与权限边界
截至发稿，主帖显示 36,241 次浏览、795 个赞与 73 条回复。回复中，并发冲突与权限边界被反复追问：软件工程师 写道，「多人模式很有趣——直到两个 agent 抢同一个文件」； 问 agent 如何避免认领同一份工作或改掉彼此的成果； 关注权限——能否查看并限制队友的 agent 在自己这块工作上可以碰什么。也有人表达担忧： 写道，不喜欢自己的 agent 与队友的 agent 直接对话，尤其当双方各有规则与技能时，「一份糟糕的输出就能拉低质量」，这条回复获得 8 个赞。也有正面反馈， 称已在用 Projects 组织 agent 工作，并期待这一更新。
对这类并发问题，公告材料只给到部分回答——例如双方 agent 会为避开合并冲突事先商定工作顺序；至于两个 agent 同时编辑同一文件时系统如何裁决，博客与文档都还没有写。