Cursor 想运行你的智能体，还想托管它们写出的代码

Cursor 的发布说明通常读起来像功能清单。这一次，读起来像是对地盘的宣示。在今天发布的公告中，该公司推出了 Projects, , 一个由协调者智能体规划工作并分派给子智能体的层级, , 同时推出 Origin, , 其自有的代码托管服务，具备仓库、拉取请求以及与 GitHub 的双向同步功能。

两者都以测试版而非成品形式推出，而它们留下的未解问题比功能清单更重要。

Cursor 今天究竟发布了什么

Projects 负责处理更大的活儿：一个功能、一次迁移，乃至一整个应用。它的协调者智能体本身不写代码。它规划工作，把工作分派给负责实现的智能体，然后交回完成的产出以供审核，并按任务需要并行运行任意数量的智能体。一个项目运行在云端的专属机器上，因此合上笔记本电脑也不会让它停下来；当某个测试必须在本地运行时，协调者会启动一个本地智能体在那里执行。

Origin 覆盖托管，起步阶段包括仓库、拉取请求、代码导航和 GitHub 同步，智能体原生功能则承诺稍后推出。云端智能体不再需要 GitHub 或第三方 SCM 连接即可启动，自托管工作节点现在也支持在 Linux 和 Mac 上的计算机操作（computer use）。

Projects 处于测试阶段，从今天起逐步向所有用户开放。Origin 今天在付费计划中进入早期测试，不包括管理员选择退出的企业组织。

Origin 对 GitHub：唯一可信来源的问题

Cursor 并未把 Origin 宣传为 GitHub 的替代品，其机制也印证了这一点。对于托管在 Origin 上的仓库，Origin 是唯一可信来源，推送永远不会到达 GitHub。对于从 GitHub 导入的仓库，GitHub 仍是唯一可信来源，推送继续发往 GitHub，Origin 则镜像其结果。同步仓库上的拉取请求是双向流动的：在 Cursor 中留下的评论会发布到 GitHub，而 GitHub 上的回复会在数秒内出现在 Cursor 中。

分量落在另一种情形上：仓库在 Origin 中创建，由智能体在其中工作，在 Cursor 内完成审核与合并，全程不碰 GitHub。仓库带有一个代码库名称，它成为其 URL 的一部分，例如 cursor.com/codebase/acme-corp。Cursor 同时还在接入一个应用生态：Vercel、Depot 和 Buildkite 的集成现已可用，Vercel 会为每个拉取请求提供预览部署。

协调者与子智能体的说法，对照措辞来检验

需要单独拎出来看的说法是：协调者不写代码。它负责规划、分派，并交回工作以供验证，按工作需要并行运行任意数量的智能体。Cursor 表示，Projects 会把任务分派给数千个子智能体。子智能体现在可以运行在自己的虚拟机上，每台都有一份隔离的项目副本，并在各自的云环境中拥有干净的上下文，这就消除了并行补丁在同一批文件中相互冲突的风险。

对于一个真实存在的问题来说，这是个合理的答案。但公告没有提供的是衡量标准。没有成功率，没有一个协调者在质量下降之前能管理多少个智能体的上限，也没有公布任何项目能按 Cursor 所描述的那样持续运行数月上下文的实例。一个 Project 会维护一套共享文件集，在其云端和本地机器之间保持同步，智能体则不断补充调研、产物以及它们对代码库的认识。这套机制说得通，但尚未经过检验。

自托管能力：测试版背后的企业级管道

Cursor 的企业级方案建立在三个彼此独立的选项之上。

资源池并不绑定到某一个仓库：给资源池命名，任何可用的 worker 都可以接手请求。云端智能体也可以在买家已经在运营的基础设施上运行，包括 AWS Lambda、Coder、Cloudflare、Daytona、Modal、Namespace、Vercel 和 E2B。这份名单指向的是这样一些团队：它们不会把构建产物或密钥交给供应商的云，而它们的安全审查恰恰卡在这一点上。

值得关注之处：定价、可靠性，以及退出条款

有三处空白格外突出。Cursor 没有公布 Projects、Origin、自托管资源池或其点名的任何基础设施合作伙伴的价格。Origin 的推出不含管理员选择不参与的企业组织，这暗示该公司预期会遭到它花了整整一节去争取的那些买家的抵制。此外，那些自主性说法, , 智能体跟踪某个 Slack 频道或某个拉取请求，并就其发现采取行动, , 依赖的是只有持续部署才能检验的循环。这些循环到第三周还能不能撑住，不是一篇发布帖能回答的问题。