Cursor 实际发布了什么
发布日志对范围进行了具体说明。Cursor 写道，Projects “让您能够承担更大体量的工作，例如一个功能、一次迁移或一个完整的应用程序。它可以在数月的工作中保持上下文，将任务分发给数千个子 Agent，并在无需提示的情况下执行循环性工作。”
协调器刻意不设计为编码器：“项目中的协调 Agent 本身不编写代码；它规划工作，将其分发给执行代码的 Agent，并将完成的工作带回给您检查。”它还在您不在的地方运行——“Project 在云端自己的计算机上运行，因此合上笔记本电脑并不会停止它”——并且它可以自行开始工作，监控 Slack 频道、日程表或一组 Pull Request。
对上下文最关键的部分是 Cursor 在公告中标题为“共享上下文”（Shared context）的章节：
“每个 Project 都维护着一组文件，这些文件会在其 Agent 使用的每个云端和本地机器之间同步。Agent 会添加研究和产物，以及它们对代码库的了解和您偏好的工作方式。”
接下来的例子揭示了其机制：“例如，如果一个 Agent 弄清楚了如何测试某个服务，那么未来的每个 Agent 都可以使用这些指令。共享上下文随着 Project 的进行而增长，使协调器随着时间的推移变得更加高效。”
仔细阅读这个例子。好处是真实的，但也是有条件的。未来的每个 Agent 能够使用这些指令，是因为某个 Agent 将它们写进了一个文件中。知识的传递并不是因为 Agent 之间是相连的，而是因为它们被记录了下来。
Cursor 的子 Agent 文档则直白地道出了另一半事实：
“子 Agent 启动时上下文是干净的。由于子 Agent 无法访问之前的对话历史记录，父 Agent 会在提示词中包含相关信息。”
这就是用两句话概括的整个模型。子 Agent 获得一个提示词和一份检出的代码。它不会获得历史记录。父 Agent 决定包含什么，而 Project 同步的文件集则是父 Agent 消失后唯一留存下来的东西。
这改变了什么，又没有改变什么
它并没有改变单个 Agent 所能容纳的容量。Cursor 隔离子 Agent 的自身原因在于预算：“每个子 Agent 都有自己的上下文窗口。长时间的研究或探索任务不会占用您主对话的空间。”三个内置的子 Agent——用于代码库探索、Shell 命令和浏览器控制——之所以存在，是因为这些操作会产生很多噪音，而 Cursor 阐述的原理是“中间输出保留在子 Agent 中。父 Agent 只看到最终的摘要。”
因此，根据设计，传递到下一步的是摘要。任何看过 Agent 自信地重新推导它在三小时前就已经做出的决定的人，都体会过这种设计带来的后果。我们之前关于编码 Agent 实际阅读了什么的文章从单个 Agent 的角度探讨了相同的边界；而 Projects 则将这一问题乘以了 Worker 的数量。
它也没有让共享文件集成为一个完整的记录。Cursor 在这里也很谨慎。在 8 月 19 日的版本中，一个独立的条目（不属于 Projects 发布的一部分）引入了在各自机器上运行的子 Agent：“子 Agent 现在可以在它们自己的虚拟机上运行。每个子 Agent 都会在自己的云环境中获得一个具有干净上下文的隔离项目副本。”子 Agent 文档还对默认设置提出了警告：“默认情况下，子 Agent 共享父 Agent 的检出。当多个子 Agent 同时编辑文件时，它们可能会覆盖彼此的更改。”
它确实改变的是您项目中持久部分所存放的位置。在 Projects 之前，一个长期运行的任务存在于您保持打开的聊天中，以及您手动维护的一组指令文件中。在 Projects 之后，聊天作为载体不复存在——取而代之的是数百个聊天，每个聊天都从头开始——而文件集被提升为唯一的通道。这是一个更好的架构。但这也意味着，您项目记忆的质量现在完全取决于有人愿意写下什么。
这不仅是 Cursor 的观察，也是整个行业最终走向的趋势。Kiro 的 Crew 文档描述了“在隔离上下文中并行运行”的子 Agent。Factory 将自定义 Droid 定义为子 Agent，“拥有自己的系统提示词、模型和工具策略，Droid 在全新的上下文窗口中将专注的任务委派给它们”。Zencoder 的子 Agent 流水线“生成具有不同模型、上下文和技能的隔离子进程，以进行并行执行和干净的上下文隔离”。Warp 在便携性上采取了相反的策略，并表示其“Rules、Skills、MCP 服务器和 Codebase Context 在应用程序、CLI 和云端中以相同的方式应用”——从另一个方向得出了相同的结论：持久层是声明式的，而不是对话式的。这并不是对它们中任何一个的批评。这是四个团队独立做出的决定：干净的上下文优于继承的上下文，并且这四个团队都让您来提供必须持久保存的部分。
人们会从中得出什么误解，以及为什么不应该这样想
“协调器会记住，所以我不需要写下来。” 协调器维护的是一个文件集。它不维护口述历史。子 Agent 学到并总结掉的任何内容，在子 Agent 运行结束时都会消失，除非它被写入了文件中。
“数千个子 Agent 意味着对我的代码库有数千种视角。” 这意味着数千次干净的启动。宽度来自并行性；连续性来自书面记录层。我们关于为什么长上下文不是记忆的文章在模型层面上做出了相同的区分。
“这与 Claude Code 的子 Agent 是同一个问题。” 接近，但不是同一个对象，值得区分。Claude Code 的子 Agent 不共享记忆是指单个会话的分散和收回。而 Cursor Project 的范围限定在某项工作体中——“一个功能、一次迁移或一个完整的应用程序”——它在您从未见过的机器上运行数月。其波及范围不同，解决方案也不同。同样，Cursor 的云端 Agent 遗忘上下文涵盖的是单次远程运行；而这里讨论的是比每一次运行都更长寿的层。
“Project 是我团队知识应该存放的地方。” 其中一部分是的。但 Project 的范围仅限于该 Project 本身。您团队争论了两周的约定——为什么拒绝了另一个数据库、哪个服务负责迁移、发布的“完成”意味着什么——这些并不是针对单个功能的具体事实。它们的生命周期超出了引出它们的 Project，并且它们需要能够被下一个 Project 以及您身边的人所使用的任何工具读取。
解决方案：将持久的决策放在无需协调器重新发现的地方
我们的目标不是与架构对抗。而是停止要求每个 Project 的文件集去承载跨项目的推理。
步骤 1：将工作产物与项目决策分离
梳理 Project 积累的内容，并根据一个问题对每项内容进行分类：在功能发布后，这是否仍然成立？“如何启动支付服务进行测试”是这项工作的产物，它恰好属于 Cursor 放置它的地方。“在没有负责人的情况下，我们不添加依赖项”是一个决策，在下一个 Project 中、在您的编辑器中以及三个月后的代码审查中，它都同样成立。
产物放入 Project 中。决策放入 Project 读取的层中。
步骤 2：捕获原因，而不仅仅是规则
读取“在此处使用 repository 模式”的协调器会照做，但不会知道原因。而读取“我们在此处使用 repository 模式，是因为遗留适配器在负载下会泄露连接，我们在生产环境中遇到过这种情况”的协调器，则可以判断该规则何时不再适用。这就是指令文件与决策记录之间的区别，也是该记录值得在 Project 之间传递而不是每次都重写的原因。
步骤 3：为记录提供一个每个界面都能访问的地址
Cursor 在“其 Agent 使用的每个云端和本地机器”之间同步其 Project 文件，这解决了 Project 内部的便携性问题。但它并没有解决跨 Project 或团队中其他工具之间的便携性问题。将决策记录放在一个可寻址的地方，让 Project 文件集指向它，您就不用在四个地方维护相同的段落了。我们关于将项目文档转化为 AI 记忆的笔记更详细地介绍了这一分类过程。
在 MemoryLake 中进行设置
共享决策层正是 MemoryLake 的用途所在：一个存放推理的地方，可供协调器、本地 Agent 以及从未接触过这些内容的下一个 Project 读取。
步骤 1：创建 API 密钥
登录并打开您的工作区设置，然后生成一个 API 密钥。这是您的 Agent 和编辑器用于读取同一层的凭据，因此只需创建一次，并使其对您工作的每个界面都可用。
步骤 2：上传您的第一批记忆
从您已经解释过两次以上的决策开始：架构决策及其原因、在审查周期中幸存下来的约定、以及代码中不明显的约束。保持每个条目足够简短，以便协调器无需加载整篇文档即可对其采取行动。
步骤 3：连接您的 AI 和 Agent
连接您实际使用的工具——编辑器、终端 Agent、云端运行——以便相同的推理能够到达每一个工具中。子 Agent 仍然会干净地启动。只不过它在启动时，项目的决策已经呈现在它面前了。
这在实践中改变了什么
第一个区别体现在 Project 结束时。推理已经存在于下一个 Project 可以读取的地方，而产物则留在它们该在的地方，而不是让文件集在关闭的 Project 中慢慢失效。
第二个区别体现在协调器分发任务时。Cursor 的模型由父 Agent 决定在提示词中放入什么。当持久的事实存在于父 Agent 可以引用的层中时，该决策会变得更容易且更一致，您将不再看到子 Agent 对您在五月份就已经解决的问题给出三个不同的答案。
第三个区别体现在您最糟糕的一天。一个在没有提示的情况下针对 Bug 报告频道运行的 Project 最终可能会采取您不会采取的行动。事后有用的问题是它是基于什么工作的——当现有的决策是被记录并进行版本控制的，而不是从摘要中重构时，这个问题就可以得到解答。审计您的 AI 记住了什么是使该问题可解答的实践。
多 Agent 间共享上下文的最佳实践
为没有历史背景的读者编写。 每个子 Agent 都是这样的读者。以“如前所述”开头的条目很容易被误读。
将“永远正确”与“当前正确”分开。 Sprint 状态属于 Project。而现有的决策属于其下方的层。将它们混在一起意味着一旦 Sprint 结束，该层就会失效。
记录被拒绝的选项。 阻止 Agent 重新提出某项建议的最廉价方法，就是将拒绝及其原因记录下来一次。
重新阅读 Agent 写入的关于您代码库的内容。 Cursor 表示 Agent 会添加“它们对代码库的了解以及您偏好的工作方式”。这是一个真正有用的机制，但它也是一种推论。将前几个条目视为草稿并进行纠正，就像您纠正新团队成员的入职笔记一样。
假设交接是有损的，并降低其成本。 您无法拓宽 Agent 之间的通道。但您可以确保通过该通道传递的是结论，而不是过程记录。
结论
Cursor Projects 是一项严肃的工程，其上下文模型非常坦诚：子 Agent 干净地启动，父 Agent 提供它们所需的内容，而 Project 同步的文件则是唯一留存下来的东西。其后果很容易陈述，但也极易被忽视。在每个 Worker 都从零开始的架构中，书面记录层并不是可有可无的。它是今天发生的一切与下个月发生的一切之间整个的带宽。
Projects 目前处于 Beta 阶段，并正在向所有用户推广。如果您即将让协调器处理数月的工作，您能花的最有价值的一小时不是在提示词上，而是写下您原本期望它能记住的决策。