为什么 Replit 会在你的项目上重新开始
记忆功能默认关闭，直到你手动开启
打开 Settings（设置），选择 Customization（自定义），然后选择 Memory（记忆）标签页。根据文档，你可以在这里“选择开启记忆、稍后关闭、选择是否与协作者共享，以及查看或更新 Memory file（记忆文件）”。文档中明确说明了两个默认设置：“记忆默认是私有的，且默认关闭协作者共享。”
因此，全新的 Workspace（工作区）在设计上默认不记住任何内容。在断定其他地方出错之前，这一点非常值得确认。
存在三个记忆范围，且互不重叠
一旦开启了记忆功能，保留什么内容取决于该内容落入哪个范围。文档中区分了以下三种：
User memory（用户记忆）捕获“持久的工作区偏好和工作风格”，并且它“属于一个构建者和工作区”。
Project memory（项目记忆）捕获“约定、注意事项和修复方法”。它“保留在单个项目中，并在相关时被检索”。
Custom memory（自定义记忆）是“你定义的具有自身访问和可见性设置的上下文”，并且它“遵循为其定义的访问和可见性设置”。
将其视为一个路由表，很多事情就变得清晰了。你在一个项目中建立的约定不会跟随你到下一个项目——项目记忆会留在它所属的项目中。工作风格偏好则与特定的构建者和工作区绑定。如果你期望其中任何一个是通用的，那么你所看到的差距其实是文档中明确规定的边界，而不是功能故障。
记忆保存的是上下文，而不是指令
这句话重新定义了整个功能：“记忆保留的是有用的上下文，而不是可执行的指令。”
并且优先级也已明确说明：“你的明确请求和 Custom Instructions（自定义指令）优先级高于记忆。”
因此，记忆是 Replit 参考的证据，而不是它必须遵守的规则。如果你一直在将指令写入记忆——例如“始终使用存储库模式”、“未经询问绝不安装新的依赖项”——那么你就是把规则放到了不属于规则的层。文档将记忆称为“上下文证据，而非可执行指令”。这些内容属于 Custom Instructions，Replit 会“在整个工作区的项目和会话中”使用它们，而且值得注意的是，“这些指令由你编写，Replit 不会修改它们”。
除非再次选择开启，否则共享项目将被排除在外
容易让团队踩坑的默认设置：“默认情况下，在其他协作者可以编辑的项目中，Replit 不会使用你的记忆。”
这是一个合理的隐私设计——你积累的上下文不会泄露到其他人工作的空间中——但这也意味着最需要共享上下文的项目反而得不到任何上下文。文档中提到的开关在同一个地方：“如果你希望 Replit 在其他协作者可以编辑的项目中使用记忆，请在 Settings → Customization → Memory 中将其开启。”
如果你的团队项目感觉像得了健忘症，而你的个人项目却运行良好，这几乎肯定就是原因所在。
记忆功能刻意排除了某些类别
这也值得了解，以免你空等一些不会出现的功能。根据文档，“记忆不保留个人信息”，特别是“敏感特征、第三方个人数据、凭据或项目机密事实”。Replit 描述其安全地处理记忆，因为它是从工作区活动中衍生出来的。
这是正确的决定，这意味着这些类别中的任何内容都需要一个由你控制的归宿。
Custom Instructions 和 Skills 是具有不同职责的独立层
Replit 发布了一个决策表，这是对该模型最清晰的阐述：
| 谁来维护 | Replit 何时使用 | 最适合 | |
|---|---|---|---|
| Custom Instructions | 你或你的团队 | 始终，跨会话使用 | 你希望一致应用的稳定偏好和规则 |
| Skills | 你或你的团队 | 当与特定任务相关时 | 可重复的步骤、工作流和辅助材料 |
| Memories | Replit（在你的监督下） | 当相关的上下文有用时 | 避免重复过去工作中好用的偏好设置 |
接下来的指南非常值得字面理解。Custom Instructions 适用于“在整个工作区中都应保持有效的规则，例如经批准的库或数据处理要求”——在 Workspace Settings → Customization 中进行管理，并保持为“一小部分始终正确的指南”，足够简短以“为手头的工作留出空间”。Skills 适用于“针对特定类型工作的可复用方法”，因为“稳定的程序性知识属于 Skills”。而 MCP 则用于连接外部工具，“而不是提供指导或上下文”。
三个层、三个维护者、三个激活条件。大多数“它忘记了我的项目”的反馈，都是因为把内容归类到了错误的标题下。
人们尝试过的方法
在每次对话的开头重新描述项目。 确实有效，可以无限期使用，但成本不变——这就是如何停止向 AI 重复解释上下文中提到的循环。
将规则写入 Memory 文件。 考虑到它是可编辑的，这可以理解。但记忆保留的是上下文，而不是可执行的指令，而且你的明确请求和 Custom Instructions 的优先级无论如何都高于它们。
把所有内容都放入 Custom Instructions。 它们在整个工作区中始终处于开启状态，这正是文档建议保持其简短和具体的原因。过长的指令块会干扰当前正在进行的工作。
将所有工作放在一个项目中。 这能让你获得共享的项目记忆，但代价是失去了你想要的隔离性，而且保留的上下文在不相关的构建之间会变得模糊不清。
假设共享项目会继承你的记忆。 默认情况下它们不会。这是一个设置，而不是 Bug。
在仓库中保留一份决策文档。 直觉是对的，但容器错了——除非有东西指向它，否则没有任何工具会去读取它。这就是为什么 Replit Agent 会遗忘任务历史中的普遍情况。
解决方案：开启记忆功能，然后将每项内容归入其专属层
花十五分钟进行路由整理，效果就会大不相同。
选择开启记忆功能。 Settings → Customization → Memory。在此处时，顺便检查一下 Memory 文件——你可以直接查看和更新它——并删除任何不再适用的内容。
深思熟虑地决定协作者共享问题。 如果你的团队在其他人可以编辑的项目中工作，并且你希望 Replit 在那里使用你的记忆，请开启共享。如果不想，请保持关闭，并接受这些项目需要从一个共享的层获取其上下文。
将规则移至 Custom Instructions。 经批准的库、安全要求、数据处理策略——这些始终正确的内容。由你编写，Replit 不会修改，并应用于整个工作区的项目和会话。保持列表精简。
将步骤移至 Skills。 发布准备、审查清单，以及任何你重复进行的多步骤操作。稳定的程序性知识属于这里，在与任务相关时被调用。
让记忆发挥其真正的作用。 它可以从过去的工作中获取偏好和工作风格，这样你就不用再重复它们。对其进行监督，而不是亲自撰写。
这涵盖了方向和步骤。但没有任何一个层能保存你项目背后的推理——例如让一个奇怪的选择变得正确的约束条件、你在第二周尝试过但失败的方法、跨越你构建的每个项目的领域事实。Custom Instructions 旨在保持简短。项目记忆会留在它所属的项目中。而 Replit 刻意排除的那些类别，无论如何都需要另一个归宿。
这正是 MemoryLake 的用武之地：将你的持久知识保存在一个你的工具可以读取的层中，独立于单个工作区或单个项目。设置只需三个步骤。
步骤 1：创建 API 密钥
登录 MemoryLake 并创建一个 API 密钥。一个凭据即可跨你连接的所有工具使用。
步骤 2：上传你的第一批记忆
简短的条目，每条只包含一个主张。适合放入的内容包括：
附带约束条件的决策。 “身份验证保留在服务端，因为客户端包大小已经超预算了。”偏好设置无法承载这一点，但记忆条目可以。
什么地方出错了以及原因。 项目记忆可以很好地捕获这些注意事项——只需写下一次，保存在一个不局限于单个项目的空间中。
跨项目的知识。 领域词汇、标准、集成怪癖。项目记忆在设计上会留在其所属项目中；而这些知识不属于其中任何一个项目。
无法放入记忆的要求。 Replit 的记忆功能刻意排除的机密或与凭据相关的约束条件，仍然需要保存在你的 Agent 可以读取的地方。
步骤 3：连接你的 AI 和 Agent
连接你使用的工具。MemoryLake 可以通过 MCP 和 API 访问，因此支持 MCP 的原生 Agent（包括 Claude Code、Codex 和 OpenClaw）可以通过指向 MCP 服务器进行连接，而其他助手则可以通过 API 读取相同的记忆。
三个客观的限制。MemoryLake 不会写入 Replit 的 Memory 文件，也不是 Custom Instructions 或 Skills 的替代品——后者是你在 Replit 内部引导 Agent 的方式。它只保存你或你的 Agent 写入其中的内容，因此步骤 2 是手动的。此外，它不是密码管理器：凭据属于密钥存储库，而不属于任何形式的记忆。
这在实践中带来了什么改变
新项目在启动时就已掌握充足信息。 项目记忆不会在项目之间传递。但保存在项目之外的知识可以，因此第四次构建可以从第三次构建结束的地方直接开始。
团队项目不再是那个“健忘”的项目。 无论你是否开启协作者共享，外部层中的共享知识对在那里工作的每个人都是可用的。
Custom Instructions 重新变得简短。 当实质内容保存在其他地方时，始终开启的列表就只包含少数几条真正的规则，而不是一个与你的提示词竞争空间的文档。
被排除的类别有了归宿。 记忆功能会刻意跳过项目机密事实。这些约束条件仍然影响着工作，而现在它们被写在了 Agent 可以读取的地方。
你的上下文不再受限于 Replit 的格式。 同样的推理在 Cursor 或 Claude Code 中也很有用——这种形式已在持久记忆的真正含义中进行了讨论。
Replit Agent 上下文的最佳实践
首先检查记忆开关。 它是选择性开启的。其他所有事情都取决于此。
按持久性而非便利性进行路由。 始终正确 → Custom Instructions。可重复的步骤 → Skills。从过去的工作中获取 → Memory。
绝不要将规则写入记忆。 它保留的是上下文，而不是可执行的指令，而且你的明确请求和 Custom Instructions 的优先级无论如何都高于它。
保持 Custom Instructions 简短。 文档建议为手头的工作留出空间。目标是制定一小部分始终正确的指南。
有目的地决定协作者共享。 默认是关闭的。清楚你想要哪种方式以及原因。
定期审查 Memory 文件。 它是可查看和可编辑的。过时的偏好设置比没有偏好设置更糟糕。
不要将任何机密信息放在记忆附近。 Replit 刻意排除了凭据和机密事实；请使用密钥存储库。
在规则旁边写下原因。 一条规则可能只适用于一个项目。但原因可以适用于接下来的四个项目——这也是为什么 RAG 不是记忆中的核心观点。
结论
Replit Agent 确实会保留上下文，而它看起来没有保留的原因通常归结为文档中记载的四个事实：记忆是选择性开启的；记忆保留的是上下文，而不是可执行的指令；三个记忆范围受限于构建者、项目或你自己的可见性设置；以及共享项目默认被排除在外。
开启记忆功能，将规则归入 Custom Instructions，将步骤放入 Skills，并明智地决定是否进行协作者共享。然后，将它们都无法承载的那一层——决策及其约束条件、出错的地方、比任何单一项目寿命更长的领域知识——保存在你的 Agent 可以查询的地方。这就是让第五个项目在结束时能像第一个项目一样掌握充足信息的原因。