Cursor 云端 Agent 现可在您管理的机器上运行 —— Agent 的上下文究竟存在哪里 (2026)

定义这种拆分的一句话

源自公告：

“通过自托管机器（Self-Hosted Machines），只有执行环境发生了转移，而 Agent 循环、推理和规划仍保留在 Cursor 云端。工具输出会流回 Cursor 进行推理，并可能包含代码，且 Agent 的对话记录（transcripts）可能会由 Cursor 处理和存储。”

一句话里包含了三个声明：执行转移了；工具输出流回且可能包含代码；对话记录可能会被处理和存储。

官方文档从另一个角度说明了同样的事情，这两者都值得一读，因为文档列举了哪些数据会传输：

“完整的检出（checkout）、构建缓存和机器本地凭据都保留在您的机器上。在运行期间，worker 会向 Cursor 发送 Agent 所需的内容，例如文件内容、终端输出、diff、屏幕截图、本地 MCP 结果和路由元数据。”

文件内容（File contents）就在该列表中。这并不是因为 Cursor 在遮遮掩掩 —— 他们写得很明白 —— 而是因为推理需要模型正在推理的字节。模型在其他地方运行的架构是无法避免这一点的。

两个部分有不同的保留规则

Cursor 的云端 Agent 安全页面将 Agent 数据分为几类，并为每类数据制定了各自的保留规则。其中有两项至关重要。

运行时工作区（runtime workspace）保存着“检出的仓库、构建产物以及单次运行的工具执行上下文”。它的保留规则是：“在运行变为空闲后自动回收；当您发送后续提示词时，定时器会刷新。”

会话状态（conversation state）保存着“构成对话记录的提示词、模型响应、工具调用、diff 上下文和演示产物”。它存在于“Cursor 后端，使用每个 Agent 的专属密钥进行加密”，其保留规则是：“默认情况下无限期保留，以便您可以重新访问并恢复运行；可按需删除。”

因此，Agent 所思考内容的持久记录是不会移动的那一半。自托管机器（Self-Hosted Machines）迁移的是临时（ephemeral）的那一半。

决定后续对话是否能记住的默认设置

这里是带有具体数字的部分。在资源池配置中：

“一旦 worker 与请求匹配，Cursor 就会将所有 Agent 工具调用直接转发给该机器。该连接的空闲超时时间默认为 1 小时。”

当该定时器触发时：

“一旦 worker 超时，Cursor 会将其标记为已释放。机器可以重置并重新进入资源池。如果用户重新启动已与机器断开连接的聊天，该聊天将重新连接到资源池中的一台新机器。除非资源池使用休眠（hibernation），否则原始机器的工作区状态不会保留。”

把最后一个小句读两遍。您的会话得以幸存 —— 它存在于后端，被无限期保留。但您的工作区没有。文档直接指出了代价：“在机器释放后到达的后续请求会重新从资源池中获取：Agent 会降落在一台全新的机器上，并可能需要花费最初的几分钟来重建它已经拥有过的工作区。”

休眠（Hibernation）是文档中给出的解决方案：在机器变为空闲时对其进行快照，如果后续请求在重新连接窗口期内到达，则恢复它，在“窗口期失效前启动具有相同 ID 的 worker”。如果快照消失了，您就释放该声明，然后“可以由替代机器来声明它”。

资源池不与仓库绑定

还有一个会影响上下文的设计细节：“资源池不与单个仓库绑定。请求只需识别资源池，任何可用的 worker 都可以声明它。这使得一个资源池可以服务于多个仓库。”

这很高效。但这也意味着，默认情况下，服务于您下一个请求的机器并不是对您的项目有任何历史记录的那台机器。

它确实转移了执行，而这正是关键所在。 根据 Cursor 的说法，团队通常在以下情况下使用它：“Agent 工具执行需要在其网络内部进行，并能直接访问版本控制、内部服务和代码仓库”；当 Agent 需要“定制硬件，例如用于 iOS 开发的 GPU 或 Mac”时；或者当构建流水线“难以打包为云端 Agent 构建”时。这些都是现实存在的限制，而这确实解决了这些问题。

它并没有转移推理层，这是设计使然。 Cursor 运行着“Agent 循环、推理和规划”。您的 worker 则“执行文件编辑和终端命令。它还运行电脑使用工具和本地 MCP 服务器”。

这并非 Cursor 独有的特性。 相同的模式也出现在 Anthropic 为托管 Agent 提供的自托管沙箱中，其文档中的描述几乎如出一辙：自托管“将编排保留在 Anthropic 侧，但将工具执行转移到您控制的基础设施中”。具体到记忆层：“Agent 的技能以及与会话关联的任何记忆库的内容都由 Anthropic 存储，并在会话期间复制到您的沙箱中；Agent 对记忆文件所做的更改会同步回存储库。” Anthropic 甚至记录了一个硬性限制 —— “在 AWS 上的 Claude 平台的自托管环境中，无法将会话与记忆库关联。” 两个厂商，相同的架构结论：自托管迁移的是沙箱，而不是记忆。这些托管存储的机制本身就值得去理解，这正是Claude 的 Agent 记忆库所涵盖的内容。

就其本身而言，它并不会让您的隐私状况变差。 云端 Agent “在隐私模式（Privacy Mode）下运行”，开启该模式后，“Cursor 绝不会对云端 Agent 访问的代码或其运行生成的提示词和响应进行训练”。有一个删除 Agent API 可以“按需删除 Agent 的会话记录和产物”，企业团队“还可以通过保留政策来限制会话保留时间”。运行时机密（Runtime Secrets）会“从对话记录、工具输出和提交中剥离，绝不会到达模型”。这些都是非常有意义的控制措施，并且都已记录在文档中。

“现在什么都不会离开网络了。” 这是最常见的解读，也是 Cursor 官方那句话所纠正的：工具输出会流回进行推理，并且可能包含代码。保留在原处的是检出、构建缓存和机器本地凭据。这与“什么都不会离开”相比，是一个截然不同且更为狭窄的声明。

“所以 Agent 记住的更多了，因为机器是我们的。” 对于池化设置来说，事实恰恰相反。拥有机器并不能扩展 Agent 的记忆；它引入了一个现在由您管理的释放定时器。在没有休眠的情况下，空闲释放的机器意味着下一次后续对话将在全新的硬件上开始。

“休眠已开启。” 这是一个需要您去实现的模式，而不是为您一键开启的开关：缩短空闲释放超时时间、在空闲时进行快照、监听已声明但离线的队列条目、在窗口期失效前进行恢复。这是一个需要您编写和运行的控制器。

“对话记录现在也在我们这边了。” 并没有。会话状态保存在 Cursor 后端，默认情况下无限期保留。可按需删除，可通过政策限制 —— 但并没有被自托管机器（Self-Hosted Machines）迁移。

“一个资源池，一个项目。” 资源池服务于任何仓库。如果您指望通过机器亲和性（machine affinity）来为特定仓库保持一个热启动的工作区，这资源池并不能保证。

步骤 1：写下您的设置中每种状态存在的位置

花 15 分钟，为您的部署制作一个四行的表格。Cursor 的文档为您提供了其中三行；第四行由您决定。

检出、构建缓存、机器本地凭据 —— 您的机器，在 worker 重置时消失。运行时工作区 —— 您的机器，在空闲后回收。会话记录 —— Cursor 后端，默认无限期保留。持久项目知识 —— 这是大多数团队无法填写的行，因为答案是“在恰好包含它的那个对话记录中”。

第四行正是问题的关键所在。它之上的所有内容要么在设计上是临时的，要么由您的供应商持有。

步骤 2：刻意设置定时器，然后验证一次释放

两个旋钮，它们的相互作用才是关键。有针对性地配置 worker 连接的空闲超时时间，而不是继承一小时的默认值，并明确决定资源池是否使用休眠。

然后测试您真正关心的场景。启动一个 Agent，让它构建真实的工作区状态，等待超过空闲超时时间，然后发送后续请求。观察 Agent 是恢复运行，还是花费最初的几分钟进行重建。做一次这样的测试，您就会知道您的资源池具有哪种行为，这比从文档中推导要有用得多。

在此期间，检查您的控制器是否处理了离线路径。Cursor 将针对离线机器的后续请求宣传为带有 claimedWorkerId 和 wakeTimeoutMs 的“已声明但离线”的队列条目，并发出匹配的事件。如果您的基础设施中没有任何东西在监听该事件，那么休眠实际上并没有配置成功。

步骤 3：将必须保留的知识放在每台机器和每个对话记录之外

步骤 1 和步骤 2 为您提供了准确的地图和可预测的定时器。但它们并没有回答底层的问题：当一个新的 worker 声明您的后续请求时，Agent 如何知道您的规范？

如今的答案是“从对话记录中获取，如果里面有的话”。这使得持久知识变成了会话历史的副产品 —— 由您的供应商持有，默认无限期保留，并且是按会话而不是按主题组织的。对于在每次运行中都应该适用的事实来说，这是一个糟糕的归档系统，同样的道理也适用于任何无状态执行层，这就是为什么MCP 任务的记忆得出了相同的结论。

一个独立的记忆层将机器完全从问题中剥离出来。无论哪个 worker 声明了请求，在哪个资源池中，在哪个仓库上，Agent 都会读取相同的存储。休眠不再是阻碍后续请求获得称职回答的障碍，而是变成了它本应成为的角色 —— 针对工作区热启动的成本优化。MemoryLake 只需三个步骤即可设置完毕。

步骤 1：创建 API 密钥

登录并在您的仪表板中生成一个 API 密钥。该凭据绑定到您，而不是绑定到 worker、资源池或机器镜像 —— 当回答您下一个提示词的机器是您的控制器在 90 秒前启动的机器时，这一属性就显得至关重要。

步骤 2：上传您的第一批记忆

放入新 worker 无法从检出中重建的内容：架构决策及其背后的原因、部署规范、允许 Agent 接触的内部服务，以及您已经在三个不同会话中输入过的纠错内容。

让临时的东西保持临时。构建缓存和检出应该被回收；这并不是损失。

步骤 3：连接您的 AI 和 Agent

将您的 Agent 指向该存储库。这样，池化请求在到达时就已经掌握了项目知识，重建工作区只会消耗您几分钟的构建时间，而不是重新解释一遍。

第一个改变是，资源池调优变成了一个经济决策，而不是知识决策。目前，为了省钱而缩短空闲超时时间，也会缩短 Agent 所知道的内容。这两者不应该是同一个杠杆。

第二个改变是，跨仓库资源池可以安全地按设计使用了。一个资源池服务于多个仓库之所以高效，正是因为 worker 是可以互换的 —— 而只有当知识存在于 worker 中时，可互换的 worker 才会成为问题。

第三个改变是，您的持久知识不再是保留政策的派生物。限制会话保留时间是良好的治理；它不应该悄悄减少您的 Agent 对代码库的理解。将两者分开，与在工具之间共享同一个记忆而不是按产品划分记忆是相同的原则。

• 引用真实的界限，而不是摘要。 执行转移了；Agent 循环、推理和规划仍保留在 Cursor 云端，工具输出流回进行推理。
• 有针对性地设置空闲超时时间。 连接默认值为一小时。决定这是否符合您团队发送后续请求的方式。
• 将休眠视为您运行的基础设施。 在空闲时进行快照，监听已声明但离线的条目，在窗口期内使用相同的 worker ID 进行恢复。
• 不要依赖机器亲和性。 资源池不与仓库绑定；任何可用的 worker 都可以声明请求。
• 使用现有的保留控制措施。 针对特定对话记录使用删除 Agent API，针对窗口期使用企业保留政策，使用运行时机密（Runtime Secrets）使敏感值完全不进入对话记录和提交。
• 在组织范围内保持隐私模式（Privacy Mode）为标准配置。 云端 Agent 不支持旧版隐私模式，文档建议强制执行标准模式，以便每次运行都能继承其保证。
• 审计一个全新的 worker 知道什么。 如果答案取决于关联了哪个对话记录，那么该知识就还不是持久的。
• 在更改后重新检查。 该功能于 2026 年 9 月 2 日发布，沙箱提供商集成和 Linux 电脑使用功能也随之而来。快速发展的领域瞬息万变。

自托管机器（Self-Hosted Machines）是对现实限制的真实解答，Cursor 对其界限的记录比周围的报道更为仔细。执行转移到了您的网络中。而 Agent 循环、推理和对话记录则没有。

实际结果比标题所写的更窄，但也更有用：在池化部署中，基础设施超时现在有助于决定您的 Agent 在开始后续对话时是掌握了信息还是从零开始。刻意设置该定时器，如果工作区热启动很重要，则实现休眠，并将必须在每次释放中幸存下来的知识保留在任何 worker 都不拥有的层中。