为什么即使环境是热的，云端 agents 也会冷启动
Builds 准备的是机器，而不是模型
看看 build 实际包含什么。文档将开发环境描述为“类似于您笔记本电脑上的设置：克隆的仓库、安装的依赖项、机密信息、启动命令和网络访问”，通过 .cursor/environment.json 进行配置，支持 agent 引导设置、保存的快照或 Dockerfile。Builds 提前准备该环境，以便 agents “在启动时仓库和依赖项就已就绪”，并且 agents 始终从最新成功的 build 启动 —— 如果依赖项更新破坏了环境，失败的 build 绝不会被激活。
该列表中的每一项都是基础设施。没有一项是知识。安装命令在创建 build 期间运行一次，而启动命令在每个会话中重新执行，这对于服务和容器来说是完全正确的设计 —— 但这与 agent 是否知道您的计费模块在本次迭代中不能接受破坏性变更完全无关。
Cursor 坦言环境有多重要：“Agents 的能力取决于它们运行的环境”，以及“环境设置是提高云端 agents 有效性最重要的一步”。这确实没错，而且 builds 让这一切变得很廉价。它只是回答了一个与人们在第三次云端运行重复犯错后所提出的不同的问题。
触发器就是全部的简报
本地会话有对话过程。而云端 agents 通常没有。文档中记录的入口点包括 Cursor Desktop、位于 cursor.com/agents 的 Cursor Web、iOS 应用或 Android PWA、通过 @cursor 命令的 Slack、在 GitHub 或 Bitbucket 拉取请求或 issue 上提及 @cursor 的评论、Linear 以及 API。
看看这些方式的共同点：agent 是由某人写下的一条消息启动的，通常此人并没有坐在编辑器前，有时甚至是由没有写过代码的队友启动的。这条消息就是完整的简报。除了您的仓库内容之外，agent 所能知道的一切都来自这句话以及它自己读取的任何文件 —— 与您在本地与 agent 交流了二十分钟的本地会话相比，在手机上根据 Linear 工单写下的一句话是非常单薄的简报。
这也是为什么这种失败感觉不同于本地的遗忘。在本地，您会注意到 agent 偏离了主题，然后您会重新解释。但在云端运行中，房间里没有人能注意到，因此误解最终会直接变成一个拉取请求。
规则是唯一的知识通道 —— 且其中一种形式会静默失效
由于触发器很单薄，仓库就成了所有持久知识必须存放的地方。Cursor 的规则文档明确指出：“大型语言模型在完成生成之间不会保留记忆。规则在提示词级别提供持久、可复用的上下文。” 规则有四种文档记录的形式 —— 作为版本控制下 .cursor/rules 中 .mdc 文件的项目规则、全局适用于您 Cursor 环境的用户规则、在 Team 和 Enterprise 计划中从仪表板管理的团队规则，以及项目根目录下的 AGENTS.md（支持嵌套文件，且更具体的文件具有更高优先级）。
这里有一个陷阱，引用自同一份文档：“.cursor/rules 中的普通 .md 文件会被规则系统忽略，因为它没有 frontmatter 来指定 description、globs 和 alwaysApply。”
没有警告，没有错误，日志中也没有记录。一个看起来像规则、放在规则目录下、读起来也像在起作用的文件。这对于那些从其他工具（其规则是普通 markdown）迁移过来的团队来说打击最大，而且它恰恰在您最无法承受的地方隐形了：在云端运行中，没有人盯着会话去注意到规范文件从未加载。这值得与四种应用模式结合来看，因为它们决定了何时加载有效的规则 —— alwaysApply: true、用于智能应用的 description、用于特定文件的 globs，或者什么都没有（这需要显式的 @ 提及）。设置为手动应用的规则永远不会在云端 agent 的运行中自动加载。
对于云端工作，还有两个限制需要注意。文档建议将规则保持在 500 行以内，并将大型规则拆分为可组合的碎片，这意味着始终加载的通道被刻意收窄了。而且，由 globs 限定范围的规则只有在匹配的文件参与其中时才会进入上下文 —— 这很合理，但这意味着特定领域的知识在 agent 决定触碰哪些文件之前是不可见的。
文档列出了持久化的内容，而记忆并不在列
这是我想谨慎对待的部分。Cursor 的云端 agent 文档涵盖了环境、快照、builds、来自 .cursor/hooks.json 的钩子、多仓库工作区（其中“agent 可以检查整个工作区，进行协同更改”）、模型选择（其中“Cloud Agents 使用精选的模型系列”并可选择上下文窗口大小），以及显示 agent 使用了哪个环境和 build 以及版本历史记录的仪表板。
但它并没有描述在不同的 agent 运行之间持久化的上下文、状态或记忆。同样，规则文档中也没有关于记忆（memories）功能的说明，在撰写本文时，cursor.com/docs/agent/memories 返回 404。因此，准确的说法不是“Cursor 没有记忆” —— 而是跨运行传递知识的文档化机制是规则文件，并且文档中没有任何内容承诺 agent 的第二次运行会从第一次运行中继承除仓库内容之外的任何东西。
请围绕文档中记录的内容进行规划。如果您的团队依赖于一个未记录的假设，即云端 agent 记得上周的事情，那么这个假设在文档中是得不到支持的，其症状将表现为运行之间的不一致 —— 这正是本地问题在云端的对应体现，具体描述请参见为什么 Cursor 会遗忘之前的会话。
人们尝试过的方法
编写更长的规则文件。 自然的选择，但这与 500 行的指南相冲突。超过一定大小后，始终加载的文件就会变成一堵文字墙，与实际任务竞争模型的注意力 —— 而且其中的每一项内容在每次运行中都需要付费，无论是否相关。
将上下文放在触发评论中。 对单次运行有效。这意味着提交工单的人必须了解所有的项目约束并记得重新陈述它们，这违背了委托给 agent 的初衷，而且它无法延续到下一个工单。
将其添加到环境中。 人们尝试将知识编码为设置：安装脚本 cat 的 README，或者启动命令 echo 的文件。环境是为依赖项和服务准备的。通过它们路由的知识是脆弱的，且在审查中是不可见的。
改为完全在本地运行。 最安全也是最昂贵的答案。您放弃了云端 agents 存在的理由 —— 队友可以从 Slack 或 PR 评论中触发工作，而无需拥有自己的机器。
假设规则已加载。 极其常见，而普通 .md 陷阱让情况变得更糟。团队在文件根本没有进入上下文时去调试模型。在归咎于模型之前，请验证规则是否实际应用 —— 参见为什么 Cursor 会遗忘项目规则中的失败模式。
生成更多 agents。 并行云端 agents 会成倍放大问题，而不是解决问题：每一个都从自己单薄的简报开始，而且没有一个知道其他 agents 得出了什么结论。这就是多 agent 记忆中所涵盖的形态。
解决方案：将项目知识放在云端可以触及的地方
结构性问题在于，云端 agent 只有两个输入 —— 触发器和仓库 —— 且其中一个是单句。规则文件处理的是每次运行都必须在上下文中的一小部分内容。它们无法承载不断增长的项目知识库：决策、被否决的方法、使一段奇怪的代码成为正确选择的约束条件。这些材料对于始终加载的文件来说太大了，而对于已经结束的本地会话来说又太有价值了，不能就此丢弃。
MemoryLake 为这些知识提供了一个 agent 可以查询的归宿，而不是一个它必须时刻携带的文件：一个任何连接的 agent 都可以读取的记忆层，这样由 PR 评论触发的运行就可以查找团队已经做出的决定。设置只需三个步骤。
步骤 1：创建 API 密钥
登录 MemoryLake 并创建 API 密钥。一个凭据由您连接的每个 agent 共享 —— 这在这里很重要，因为云端运行是从多个界面触发的，而您不希望进行针对每个界面的配置。
步骤 2：上传您的第一批记忆
加载您的规则文件无法承受的知识。架构决策及其背后的推理。您尝试过并放弃的方法及原因 —— 这是价值最高的一个类别，因为一个带着单薄简报的新 agent 否则会自信地重新提出这些方法。没有上下文就显得武断的约束。存在于人们脑海中的规范，因为没有人想到要把它们写下来。保持条目简短且每条只有一个想法，以便检索返回 agent 可以执行的操作。
步骤 3：连接您的 AI 和 agents
连接您的 agents。MemoryLake 可以通过 MCP 和 API 访问，因此支持 MCP 的原生 agents —— 包括 Claude Code、Codex 和 OpenClaw —— 可以通过指向 MCP 服务器进行连接，而其他工具则通过 API 读取相同的记忆。规则继续履行其狭窄的职责：每次运行都必须在上下文中的少数几件事。其他一切都变得可检索，因此单薄的触发器不再意味着单薄的简报。如果您是第一次配置 MCP 端，使用 MCP 设置跨 AI 记忆将引导您完成该过程。
诚实的限制。MemoryLake 不会监视您的云端运行，也不会捕获 agent 学到的东西，除非有人将其写下来。它不是一个强制执行层 —— 如果一个规则无论模型如何决定都必须遵守，那它应该属于钩子或 CI 检查，这正是 .cursor/hooks.json 的用途。而且它不能取代规则文件；两者承担不同的工作，而要求其中任何一个同时承担这两项工作都是错误的。
这在实践中改变了什么
单薄的触发器不再产生单薄的工作。 提交工单的人不再需要是记住每个约束条件的人。这是云端 agents 的真正承诺，而且只有在无需他们参与即可触及约束条件时，这一承诺才成立。
云端和本地运行趋于一致。 目前，相同的请求通常会产生不同的工作，这取决于您是在长时间对话后在编辑器中运行它，还是通过 Slack 消息运行它。当两者读取相同的记忆时，界面就不再重要了 —— 这也意味着上下文不再只存在于一台机器上。
规则文件变得更短，因此更好。 将参考知识移出始终加载的通道不仅是为了整洁。它能让您保持在 500 行指南之内，并减少与那些确实必须每次都应用的规则竞争的噪音。
重复的修正不再重复。 最让人沮丧的云端 agent 体验是看着第三次运行犯下您在第一次运行中已经纠正的错误。发生这种情况是因为修正存在于会话中，而会话会结束。一旦写下来，它就可以用于之后的每一次运行。
审查变得更短。 对 agent 编写的拉取请求的大多数审查意见并不是关于代码质量的 —— 而是关于 agent 所缺少的上下文。移动上下文，很大一部分审查就会消失。
云端 agent 上下文的最佳实践
立即审计 `.cursor/rules` 中的普通 `.md` 文件。 其中的任何没有指定 description、globs 和 alwaysApply 的 frontmatter 的文件都会被静默忽略。这是一个只需五分钟的高命中率检查，特别是在从其他工具迁移过来的仓库中 —— 这与将 Windsurf 迁移到 Cursor 中描述的转换陷阱相同。
了解每个规则使用哪种模式。 alwaysApply: true 用于必须始终加载的少数规则；globs 用于特定区域的规则；description 用于智能应用。需要 @ 提及的手动规则永远不会在无人值守的云端运行中自动加载 —— 请将它们视为仅限本地。
编写触发器时，假设 agent 除了仓库之外一无所知。 因为事实确实如此。陈述目标和验收标准；让可检索层提供背景信息。
当运行出错时，使用环境仪表板。 文档描述了它显示 agent 使用了哪个环境和 build，以及版本历史记录。如果某次运行的表现与其前身不同，在假设模型发生变化之前，请检查它是否处于不同的 build 上。
将必须遵守的约束放在钩子中，而不是散文中。 云端 agents 运行来自 .cursor/hooks.json 的基于命令的钩子。任何对每次更改都必须为真的内容都属于那里，在其中它是被强制执行的，而不仅仅是建议。
不要将机密信息存入记忆。 环境机密属于环境配置。记忆层保存的是知识，而不是凭据。
结论
Builds 是一项真正的改进，而且价格无可争议 —— 免费，从 8 月 17 日起默认开启，且 agents 始终从上一次成功的 build 启动，而不是冷启动机器。现在之所以值得讨论剩下的差距，是因为 builds 消除了借口。当云端 agent 需要四分钟才能启动时，慢似乎是主要问题。而在几秒钟内启动并立即提出您上个月否决的设计，这让人们清楚地认识到，速度从来都不是问题所在。
解决方案不是编写更长的规则文件。而是认识到云端 agent 有两个输入，其中一个是单句，而您团队所知道的其他一切都需要能从另一个输入中检索。像 Cursor 现在预热机器一样，预热您的知识。