AI未开源软件工具

Cursor 的 Projects 变成了多人协作：一群人带着各自的 Agent，共用一块任务板和一份上下文

2026年11月11日2 次阅读
Cursor 的 Projects 变成了多人协作：一群人带着各自的 Agent，共用一块任务板和一份上下文

3分钟看懂

一句话先说结论：Cursor 的 Projects 从「一个人指挥一群 Agent」升级成了「一个团队带着各自的 Agent 一起干活」，共享任务板和共享上下文，即日起向所有 Cursor 用户 beta 推送。

这件事的分量不在功能清单，而在于它承认了一个现实：这些编码 Agent 已经不只是帮某个人补全几行代码，它们在替团队跑迁移、修 CI、盯 on-call。当 Agent 多到一个人管不过来，协作的对象就从「人和人」变成了「人和人，再加人背后那群 Agent」。

为什么这件事值得看一眼

过去一年，几乎所有编码 Agent 的产品形态都是单人的：你开一个窗口，它读你的仓库，改你的文件，跑你的测试。多 Agent 编排听起来很先进，实际服务对象始终是一个人。

问题是团队真正的工作不长这样。一个功能要几个 PR，一次迁移要几个人分头改，一个线上故障要有人交接班。这些事现在有 Agent 参与了，但 Agent 的上下文还锁在每个人的窗口里——新人接手要先花半天把背景喂给它，两个人的 Agent 甚至不知道彼此在改同一个文件。

Cursor 这次改的就是这层。官方博客原话是：「多 Agent 系统到目前为止只服务一个人。Projects 是第一个为整个团队构建的多 Agent 系统。」

具体变了什么

第一块，共享任务板。

一个 Project 里所有人看同一份任务列表和看板：谁在做什么、每个人的 Agent 正在跑哪些任务、每个任务背后对应哪个 PR。人和 Agent 看到的是同一份实时视图，不用再靠群里问「这个归谁」。

第二块，上下文分成两层。

这是我觉得设计上最值得说的地方。以前 Agent 的记忆是跟人走的，人一走全丢。现在拆成两个 store：

  • Project store（路径 /cursor/stores/self）：全员 Agent 都能读写。放需求文档、架构图、技术规格、原型，以及某次对话里定下来的决策。新成员进来时上下文已经是配好的，不用从零搭。
  • 个人 store（路径 /cursor/stores/user）：只有你自己的 Agent 能挂载。放你的偏好和技能，跟着你跨 Project 走，但队友的 Agent 看不到。

官方还留了一个口子：队友加入时，你的协调者可以提议把你个人偏好里「描述这个 Project 该怎么干活」的条目复制进 Project 规则——只复制你点头的那部分。

第三块，Agent 之间可以直接说话了。

你的协调者需要队友那边的东西，可以直接发消息给对方协调者，不用你去传话。规则写得很克制：

  • 消息被标记为「agent 输入」，接收方知道是「某位队友的 Agent」发来的，把它当不可信输入来权衡，而不是当自己主人的指令；涉及对方的个人文件或连接器数据时，要先问。
  • 你的对话不会被打断。对方的消息落在一个从你的对话分叉出去的旁路对话里，名字叫「Chat with 某某的 agent」，它答完把回复送回去，你这边下一轮只会看到一条「发生过这次交流」的提示。
  • 旁路对话只负责回答：你能读、能停、能归档，但不能往里发消息。它不会外传密钥、凭证、token，能读任务板但不能改，也不能反过来问你问题、申请权限、连源码管理、管定时任务。

怎么用

操作路径不复杂，四步：

  1. 在 Agents Window 左侧导航找到 Projects，点 New Project，起个名、选图标。
  2. 选 workspace（就是 Project 要干活的仓库）和协调者用的模型。Project 跑在云上，所以列表里是你云 Agent 能访问到的仓库；没连 GitHub 会提示先连。
  3. 建完之后它是一个和协调者对话的聊天窗口。把你想要的东西说清楚，剩下的拆活派活由它做。
  4. 点 Project 顶部的 Invite，按名字或邮箱搜队友发邀请；也可以复制链接，但只有 Project 里的人能复制，所有者还能点 Reset Share Link 让之前的链接失效。

队友收到邀请卡片，点 Accept Invite，就会在这个 Project 里拿到属于自己的那条对话——自己的协调者、自己的执行 Agent，跑起来按他自己的账号计费。

注意边界：共享只能在同一个 Cursor 团队内，个人账号或别的团队的人进不来；被邀请的人还得有那个仓库的权限。

适用场景

  • on-call / 值班交接：这是官方自己举的例子，也最有说服力。几位 Cursor 工程师把值班轮转放在共享 Project 里，交接时新值班的人一接手，协调者已经知道哪些工作在飞、哪些 issue 还没人认领、哪些事故和笔记要移交、要盯哪些频道和 Linear 看板。在飞的工作还能直接过继——新人那边说一句，他的 Agent 就接过去了。
  • 一个功能拆多个 PR：任务板天然对应 PR，谁改哪块、卡在哪一目了然。
  • 跨角色撞车提前对表：工程师给产品页加评论区，设计师同时在改版——两边的协调者会提前发现重叠并同步，评论直接建进新设计里，省掉后面一次重构。另一例子是「你的功能在读某张表，队友正在改 schema」，Agent 会先商定顺序，避免最后撞合并冲突。
  • 长期跑的项目：Project 的定位本来就是「活过一个聊天窗口的工作」，上下文按月累积，别人接手不用重新教。

不适用场景

  • 一个人写小脚本：单人场景用原来的普通对话或 Cloud Agent 就够了，开 Project 反而多一层协调开销。
  • Free / Plus / 旧 Hobby 套餐：Projects 依赖 Cloud Agents，这几个套餐没有，用不了。
  • 还在用 Privacy Mode (Legacy) 的团队：Projects 跑在 Cloud Agents 上，代码在运行期间存在云端，所以这个模式下的 Project 不可用，共享更不可用。
  • Project 跑在自托管机器上、或已归档：这两种情况不能拉人加入。
  • 强合规、代码不许出内网的团队：先别急，这不是本地部署能绕开的限制。

避坑

  • 版本要对：共享 Project 需要团队账号 + Cursor 3.26.13 或以上；企业版跑 Projects 需要 3.21.9 或以上。版本不够会看不到 Invite 入口，别以为是灰度没轮到你。
  • 别把共享上下文当保密区：Project 共享上下文是全员 Agent 都可读写的，写进去的东西等于全组可见；自己的偏好、笔记留在个人 store。
  • 旁路对话不是后门：它不能改任务板、不能要权限、不共享密钥。所以别指望靠队友的 Agent 帮你「顺手把权限开了」。
  • 交接前先确认在飞任务已写回任务板：Agent 之间能对话，但它读的是 Project 里记录的状态。口头说过的、只在某个私人对话里的信息，不会自动变成共享上下文。
  • beta 阶段会有功能缺口：官方写明先从建 Project、拉人、交接、撞车协调这几件事做起，别指望它第一天就覆盖所有协作细节。

成本/时间

  • 计费方式：多人 Project 里，每个人跑自己的对话，按各自账号计费，不是所有者一个人买单。团队要提前说清楚，不然月底账单容易起争议。
  • 没有单独的「多人版」定价：Projects 本身在包含 Cloud Agents 的套餐里（Premium 及以上、Teams、Enterprise、以及旧的付费 Cursor 套餐），这次升级没有公布新的价格档。
  • 上手时间：熟悉 Cursor 的人，建 Project + 拉人基本十分钟内能跑通；真正花时间的是把需求文档、架构图这些喂进共享上下文，这部分取决于你团队原本有没有写清楚。
  • beta 阶段免费试用谈不上：它不是一个独立付费功能，不存在「试用期到期」的问题，但云端 Agent 的用量照常计。

行动建议

  1. 先拿一个真项目试，别拿演示项目：挑一个要跨两个以上 PR 的活，把需求文档丢进共享上下文，看协调者拆出来的任务是否合理。
  2. 把值班交接搬进去：如果团队有 on-call，这是投入产出比最高的用法——一次交接省下的背景重建时间，比任何 prompt 技巧都实在。
  3. 先定规矩再拉人：谁有权往 Project store 写、哪些信息不许进共享层、Agent 之间互发消息要不要人复核。这三条现在定，比出了事故再补便宜得多。

参考来源

本文基于 Cursor 官方发布与官方文档整理；发布节奏、推送范围与 on-call 交接案例部分，基于多家媒体转述整理（Unite.AI、OmniTools、toolnavs 同日报道）。

评论

0 条已公开
登录或注册后可以参与评论。

正在加载评论...