Devin Desktop 实际发布了什么
这里有三个官方声明至关重要，它们来自三个不同的页面。
更新日志确定了移除的日期，并指明了对话的替代路径。它指向的迁移提示词是 Continue in Devin Local，而它带走的仅仅是对话。
Devin Local 的文档对于什么没有被带走则说得更加直接。在“局限性”（Limitations）一栏下：
"记忆 —— Devin Local 智能体不会在会话之间持久化记忆。请使用 Devin: Open Cascade Migration Wizard 命令将你的关键记忆迁移到技能（skills）中。"
"工作流 —— Devin Local 智能体不提供工作流功能。"
而“记忆”（Memories）页面解释了这些记忆原本存放在哪里：
"Cascade 自动生成的记忆与创建它们的工作区相关联，并本地存储在 ~/.codeium/windsurf/memories/ 中。Cascade 会在认为相关时检索它们。在一个工作区中生成的记忆在另一个工作区中不可用，并且它们不会被提交到你的仓库中。"把这三点结合起来看，问题的轮廓就很清晰了。这些记忆本地存在于单台机器上，仅限于单个工作区，并且没有纳入版本控制。这一切并没有被隐瞒——文档里写得清清楚楚——但这意味着积累的知识只有唯一的一份副本，存放在一个没人会想到的目录里。
还有一个值得注意的脱节，因为它会影响你本周应该做的事情。更新日志的迁移说明针对的是对话。而无论是“记忆”页面还是 Devin Local 的局限性说明中，记忆的迁移路径都是一个名为 Devin: Open Cascade Migration Wizard 的独立命令——该命令是以更新日志中声称已被移除的智能体命名的。截至本文撰写时，“记忆”页面仍在使用现在时态描述 Cascade。两条路径针对两个不同的事物，而文档还没有赶上发布的步伐。如果你有在乎的记忆，在假设迁移向导依然存在之前，先看看它们所在的机器。
这次移除也并非毫无征兆，信号就藏在那些条件从句中。7 月 29 日，标记为仅限 Devin Local 的模型开始在 Cascade 的模型选择器中显示为禁用。8 月 10 日，发布说明中描述了“当你的团队禁用 Cascade 时”隐藏“Cascade 特定的配置和自定义选项”。8 月 21 日，“解释并修复问题”（Explain and Fix Problem）开始在“Cascade 被禁用时”将问题发送给 Devin Local。在最终发布彻底关闭 Cascade 之前，更新日志已经连续六周在描述一个 Cascade 被关闭的世界中的行为。
这改变了什么，又没有改变什么
我们很容易对这件事过度解读，所以让我们准确地看看 Devin Local 到底承载了什么，又没有承载什么。
Devin Local 并非一个没有持久化能力的工具。它的文档恰恰相反：
"Devin Local 智能体确实支持规则（rules）和 AGENTS.md 文件，以及用于提供持久上下文和可重用工作流的技能（skills）。"
它还会将规划产物写入一个固定的位置：
"规划会被写入到 ~/.devin/plans/plan-<session>.md 的持久化 Markdown 文件中，因此你可以编辑它、稍后返回，或者将其交给一个全新的会话。"因此，客观的总结很简短：Devin Local 的持久化是基于文件的。规则、AGENTS.md 和技能得以保留，是因为它们是文件，而且其中大多数是你仓库中的文件。规划也作为文件保留了下来，尽管默认情况下它们保存在你的用户主目录中，而不是项目目录中。无法保留的，是那个由智能体（而不是你）来决定什么值得保留的机制。
规则文件夹本身在过渡中完好无损地保留了下来，包括它们的优先级顺序——优先使用 .devin/rules，以 .windsurf/rules 作为备用，且传统的根文件依然会被读取。如果你还没有理清在你的仓库中哪一个规则文件真正起作用，合并你的 Windsurf 和 Devin 规则文件夹 详细介绍了如何合并它们，这项工作现在比一周前更有价值，因为规则现在承担了更多的职责。
同样没有改变的，还有厂商自己的建议，这个建议一直写在“记忆”页面上：
"对于你希望 Cascade 可靠地重复使用的知识，请将其写为规则（Rule）或添加到仓库中的 AGENTS.md 中，而不是依赖自动生成的记忆（Memories）。规则是版本控制的、可与团队共享的，并且能让你对激活进行显式控制。"这个建议最初是针对检索的可靠性而写的，而不是为了在产品决策中存活下来。事实证明，它对这两者都是正确的建议。
人们会从中得出什么结论，以及为什么不应该这样想
目前普遍的反应是，Cascade 用户需要赶快迁移到 Devin Local，而教训是要紧跟编辑器的发布说明。这两点都没错，但都不是最有趣的部分。
首先要避免的是将此仅仅看作是一家厂商停用了一个功能。这是近几个月来第三次出现同样的模式，而另外两次来自与这家厂商毫无关系的竞争对手。
Kilo Code 的文档中包含以下通知：
"Kilo Code 的记忆库（memory bank）功能已被弃用，取而代之的是 AGENTS.md。"
它的迁移说明是将记忆库内容移动到项目的 AGENTS.md 中，而它对该文件的描述解释了原因：
"AGENTS.md 是在软件项目中配置 AI 智能体行为的开放标准……该标准受到多种 AI 编程工具的支持。"
OpenHands 走向了另一个方向，但最终到达了同一个终点。它的持久化记忆功能确实存在，但文档将其描述为“选择性加入且默认关闭”，并指出在没有它的情况下，“智能体保留现有的基于 AGENTS.md 的引导，且提示词保持不变”。仓库文件是默认设置；智能体维护的记忆才是你需要手动开启的东西。
三个独立的团队，三个产品，一个共同的趋势：项目知识的持久容器是仓库中的一个文件，而不断积累的智能体端存储则是被弃用、变为可选或被移除的层。这并不是对它们中任何一个的批评。自动生成的存储确实非常有用——它捕捉到了你永远不会费心写下来的东西——但它与特定的智能体实现绑定在一起，而这恰恰是产品团队最容易改变的东西。
第二件要避免的事是得出“技能（skills）就是答案”的结论，因为那是迁移向导所指向的地方。技能是模型在认为相关时调用的程序——对于“我们如何运行发布”来说是一个好归宿，但对于“我们在三月份因为重新投递语义而拒绝了另一个队列库”来说却是一个糟糕的归宿。为什么智能体技能不是记忆 探讨了这种区别，当迁移路径促使你将前者扁平化合并到后者中时，这一点尤为重要。
第三是将其定性为“锁定”（lock-in）的故事。这在一定程度上确实是——AI 记忆是一项功能还是锁定机制 是向任何厂商提出的一句合理质问。但锁定通常意味着你无法导出数据。而在这种情况下，这些文件在你的磁盘上、在有文档记录的路径中，始终是可读的。问题不在于访问权限，而在于工作流中没有任何环节将它们移动到第二台机器或第二个团队成员可以看到的地方。
解决方案：将决策写入仓库可以承载的地方
这一切的实际操作其实是一个分类整理的过程。做一次，下一次产品退役时就会风平浪静。
步骤 1：查看退役的存储中实际保存了什么
在决定东西往哪里放之前，先阅读一下积累了什么。Cascade 的记忆存放在生成它们的机器上一个有文档记录的目录中，每个工作区一套。打开它们，并将每个条目分类到三个桶中：常规指令（“使用 bun，而不是 npm”）、带有原因的决策（“因为迁移问题，我们放弃了该 ORM”），或者关于几个月前已完成任务的临时笔记。
自动生成存储积累的大部分内容都是第三个桶，这就是为什么这些功能弃用带来的痛感比人们预期的要小。但第二个桶才是代价高昂的，而且目前没有仓库文件保存它，因为没有人会把“为什么”写进规则文件里。
步骤 2：将常规指令发送到规则层
第一个桶里的内容应该去往厂商说它该去的地方：.devin/rules/ 中的规则，或者你仓库中的 AGENTS.md。这两者都会被 Devin Local 读取，都纳入了版本控制，并且都会被遵循相同约定的其他工具读取。将每个条目保持在一两句话以内，放在激活模式与它应该应用的频率相匹配的文件中。
一个关于命名的注意事项（做对很容易，做错却不会有任何报错提示）：Devin Desktop 的文档说 AGENTS.md 和 agents.md 都可以被识别，但读取相同约定的其他工具要求文件名必须大写。在共享仓库中，请使用 AGENTS.md。
步骤 3：给原因一个不属于任何单一产品界面的归宿
第二个桶无处可去。规则文件是错误的容器——规则在每次会话中都会加载，因此用历史记录填满它们代价高昂，而且规则的重点在于简短和命令式。技能也是错误的，原因如上所述。
这些内容需要一个可查询的地方，独立于任何单一编辑器，且使用不同工具的团队成员也可以访问。这正是这些弃用事件不断指向的层，也是这三家厂商都没有提供的一样东西。
在 MemoryLake 中进行配置
MemoryLake 是保存这些原因的地方。它位于你的编辑器之外，通过 MCP 或 API 为任何发出请求的智能体提供服务，因此你今天记录的决策在下一个智能体界面退役后依然可以被解答。你的规则和 AGENTS.md 依然保留在仓库中，完全符合 Devin Local 文档的描述；而共享层则保存了那些文件本不该承载的部分。
步骤 1：创建 API 密钥
生成一个密钥，并在大约 30 秒内发出你的第一次请求。在开始分类整理之前完成这一步，这样在你阅读旧记忆时，就有地方可以存放每一个原因。
步骤 2：上传你的第一批记忆
逐条处理第二个桶中的条目。对于每个决策，写下选择了什么、拒绝了什么以及原因。支持性文档——架构说明、事件记录、厂商对比——也放在同一个地方。
步骤 3：连接你的 AI 和智能体
让 Devin Local、Claude、Codex 以及你的其他智能体通过 MCP 或 API 进行访问。当有人询问为什么存在某种约定（convention）时，返回的答案将附带其推理过程，而不是一条干巴巴的重述规则。
这在实践中改变了什么
第一个改变是，产品退役不再是一场紧急事件。当厂商移除一个智能体界面时，你检查仓库和共享层，发现它们都还在。
第二个改变是，分类整理只需要进行一次。你从 Cascade 记忆中提取的所有内容现在都以一种新工具在第一天就能读取的格式存在，这就是“迁移”与“重新接纳”之间的区别。
第三个改变是，新机器和新团队成员可以从与你相同的起点开始。Cascade 的记忆是工作区范围且本地化的，因此第二次检出（checkout）时内容是空的。仓库文件加上可查询的共享层则没有这种不对称性——这正是 Devin 在会话之间丢失任务上下文 这一问题最终归结到的原因。
第四个改变是，你的规则文件变得更短而不是更长。一旦推理过程有了归宿，规则就可以是简短的一行命令，而这正是激活模式系统设计的初衷。
在智能体界面退役后存活下来的最佳实践
阅读发布说明中的条件从句。 在“Cascade 已被移除”之前，已经出现了六周的“当 Cascade 被禁用时”。关于某项功能被关闭的表述通常是一个时间表，而不是一种假设。
将任何未纳入版本控制的内容视为唯一副本。 自己磁盘上有文档记录的路径既不是备份，也不是交接。如果它很重要且没有被提交，那么它就只存在一份。
不要让迁移向导决定你的信息架构。 引导式流程会将内容移动到目标端拥有的任何容器中。这很方便，但并不等同于该容器是正确的选择。
将命令保留在文件中，将原因排除在外。 常规指令属于规则层，在每次会话中加载。历史记录则属于可以按需检索的地方。
检查跨工具的文件名大小写。 一个厂商的大小写不敏感匹配可能是另一个厂商的静默遗漏。大写的 AGENTS.md 在所有读取该约定的地方都能被识别。
假设自动生成层是最容易发生变化的那一层。 今年在三家厂商中，它分别被弃用、变为可选和被移除。
结论
Devin Desktop 的更新日志将 Cascade 的移除归于 2026 年 9 月 8 日的发布，并且文档明确指出，替代它的智能体不会在会话之间持久化记忆，同时完全支持规则、AGENTS.md、技能和持久化规划文件。所有这些都是有文档记录且合理的。它所暴露出来的问题是，大多数团队从未决定他们的项目推理过程应该存放在哪里——他们任由智能体将其积累在本地目录中，并将结果视为一项功能。
解决方案虽然朴实无华，但却是一劳永逸的。常规指令放入仓库中，这也是厂商几个月来一直告诉你要放的地方。它们背后的原因则放入一个可查询的地方，不属于任何单一的产品界面。做到这一点，下一次看到某个功能退役的发布说明时，它就只是你带着淡淡兴趣阅读的一个段落，而不是让你在周一花上一整天去重建决策。