Cognition 实际发布了什么
产品公告将 Memory 描述为一种“在不同会话之间携带有关您喜欢的工作方式的有用学习成果：您的偏好、您做出的修正以及关于您的项目和工作流的经验教训”的方式。在 X 上，Cognition 简短地表示：“在不同会话之间，Devin 会构建一个关于您喜欢如何工作的记忆图谱。”
文档描述了存储方式。“您的记忆保存在一个记忆驱动器中：一个由 Markdown 笔记组成的持久 Git 仓库。”一个简短的 MEMORY.md 文件保存了通用偏好和索引，其他笔记则按项目或主题存放在文件夹中。
它还描述了一个由三部分组成的循环。在第一部分中，“每个会话都会获得该驱动器的专属检出（checkout），并接收 MEMORY.md 作为上下文。”Devin 仅在任务需要时才会搜索和读取其他笔记。在第二部分中，当您纠正 Devin 或它琢磨出一些可复用的东西时，它会编辑一条笔记，每个条目都是一个单行列表项，链接回学到该内容的会话。在第三部分中，Devin 会提交、合并来自其他会话的更改并保存。并行会话可以写入同一个驱动器，博客中写道：“冲突的编辑会被呈现出来以供解决，而不是被静默覆盖。”
有一个时间细节很容易被忽略：“新的记忆适用于未来的会话，而不是写入它们的当前会话。”
然后是开放标准。文档指出，Devin 的记忆“构建在 Agent Memory Repo 之上，这是一个将智能体记忆视为具有 MEMORY.md 入口点的 Git 仓库的开放规范”，并补充道：“您可以在自己的智能体中使用相同的格式。”
这改变了什么，没改变什么
Devin 在规定的限制内决定保存什么。 文档中包含一个表格。已保存：偏好、修正、带有您所提供理由的决策，以及关于您仓库的注意事项。未保存：“会话摘要”、“任务状态（如 PR 编号或状态）”、“任何重新发现成本很低的内容”以及“机密和凭据”。博客用另一种方式表达了同样的想法：“记忆不是会话的摘要。”
Dreaming 会添加、合并和删除。 “Dreaming 是一个后台会话，在您使用 Devin 时大约每天运行一次。”它会合并重叠的笔记，添加未捕获的经验教训，并重新整理索引。它还会“删除任何会话都未使用的瞬态细节和陈旧笔记”。博客将这同一步骤列为删除“任何会话都未使用的陈旧记忆记录”。Cognition 指出，“源链接和明确的偏好会被保留。”
记忆是私人的。 这是对团队来说最重要的一点。“在每个组织中，记忆对您个人而言是私有的。它不会与您的团队成员或您的组织共享。”博客将其框定为一种设计选择：“它是属于您个人的，而不是成为您组织的共享指令。”
自动化运行不包含在内。 “由自动化启动的会话不会读取或写入您的记忆。”Devin 根据日程安排、Slack 触发器或 Webhook 启动的工作在运行时不会包含您的个人笔记。
您通过 Devin 管理它。 您可以在 Customize（自定义）下的 Memory（记忆）中浏览记忆文件，并查看每个 dreaming 会话更改了什么。但是“记忆文件在应用中是只读的”。要更改某些内容，您需要在会话中要求 Devin，例如让它忘记某个偏好或记住某个规则。
关闭它会保留笔记。 记忆功能默认开启。如果您关闭个人记忆，“Devin 将停止读取和写入记忆；如果您重新开启，您现有的笔记将被保留。”当管理员为组织关闭该功能时，“Dreaming 将不会运行，且 Memory 标签页会被隐藏。现有的笔记不会被删除。”
团队指南有其专属位置，且正在迁移。 对于共享指令，Devin 指向了 skills。“Skills 是您刻意编写的规程，”skills 页面写道，而插件中的 skills “可以安装在个人、组织或企业范围”。Devin 较旧的 Knowledge 功能现在带有一个横幅：“Knowledge 已弃用，将在未来的更新中删除。”现有的 Knowledge 正在自动迁移到 skills。如果您按照我们关于 Devin Knowledge 的指南中描述的方式设置了触发器，它们预计将作为 skills 导入。
这也与 Devin Desktop（Cognition 的本地智能体）不同，其 Cascade 时代的记忆在将 Devin 仅限 Cascade 的记忆迁移到 skills 中有详细介绍。这里描述的记忆驱动器属于 devin.ai 上的 Devin。
人们会从中得出什么结论，以及他们不应该得出什么结论
误以为 Devin 现在记住了您团队做出的决定。 它记住的是它在与您合作时学到的东西。您团队成员的 Devin 有它自己的驱动器。您上周向 Devin 解释的一个决定存在于您的记忆中，而不是他们的记忆中。
将开放规范中的团队用例误读为对 Devin 记忆的描述。 该规范确实将团队记忆列为一个用例：“共享关于客户、流程和工具的知识，特别是对于没有代码仓库的团队。”这描述的是该格式可以支持的功能。即使在那种情况下，共享也是选择性加入的：在规范中两个人在同一个会话中的示例中，“只有在 Bob 选择与会话共享时，他的记忆才会被克隆”，并且每个仓库都保留“其自己的所有权、权限和历史记录”。Devin 的产品文档将其自身的记忆描述为个人记忆，而团队指南则通过 skills 进行。
误以为如果 Devin 学过一次，下个月它还会记得。 Dreaming 会删除任何会话都未使用的笔记。这使记忆保持专注，但也意味着极少用到的重要决定（例如为什么放弃某次迁移，或者合规审查的要求是什么）可能会在两次需要之间被修剪掉。
期望定时运行能够从 Devin 在您的会话中学到的内容中受益。 自动化运行不会读取或写入个人记忆。
误以为 Git 格式意味着您的记忆会随您移动。 规范本身的试用说明指出，“云端会话或其他机器需要私有远程仓库或其他持久存储才能在不同会话之间携带记忆”，并且独立版本中“不包含自动启动和定时 Dreaming”。格式是可移植的，但围绕它的行为取决于实现它的每个智能体。
这些都不是批评。对于与单个开发者并肩工作的智能体来说，一个私人的、自我修剪的记忆是一个合理的设计。关键是要知道它保存的是哪种上下文，以便您可以将其他内容放在别处。
解决方案：让 Devin 学习个人事物，并将团队事物放在团队可以阅读的地方
步骤 1：将 Devin 应该了解的关于您的内容与团队的需求区分开来
列出您发现自己经常告诉 Devin 的内容。然后将其拆分。
个人上下文属于 Devin 的记忆：您喜欢如何编写更新、您偏好哪些工具、反映您个人风格的修正。让 Devin 在您工作时吸收这些内容，并在它出错时在会话中纠正它。
团队上下文需要一个不同的归宿：每个人都使用的构建和测试命令、架构边界、发布规则以及它们背后的原因。如果它应该适用于团队成员的会话或自动化运行，那么个人记忆就不是存放它的正确地方。
一个有用的测试方法是问自己：如果同事明天在同一个仓库上启动会话，他们会需要这个吗？如果是，它就是团队上下文。
步骤 2：将规程放在 skills 和仓库文件中，并保留其原因
Devin 官方的指导是，skill “提供规程，而记忆则提供将其应用于您工作的上下文”。因此，将可重复的规程编写为 skill，放在仓库的 .agents/skills/ 中，或者通过插件放在组织范围内。将仓库规范保留在 Devin 读取的文件中，例如 AGENTS.md。
当您编写规程时，请包含其原因。一个告诉 Devin 在合并前运行集成测试套件的 skill 会被执行。而一个同时说明了原因以及上次跳过时出了什么问题的 skill，则能在下一次重构中幸存下来。Skills 和记忆服务于不同的目的，这一区别在为什么智能体 skills 不是记忆中有详细介绍。
然后检查您正在迁移的旧 Knowledge 条目。确保每一个都落在了您预期的范围内，并且没有重要内容仅仅存在于一个不再触发的触发器中。
步骤 3：写下极少出现但绝不能丢失的决定
有些上下文太重要了，不能依赖于最近的使用情况。例如为什么拆分某个服务、拒绝了哪个供应商以及原因、客户合同的要求是什么。这些情况一年只出现几次，而这恰恰是修剪运行旨在清理的模式。
将它们保存在您刻意维护的记录中，并为每条记录注明日期和来源。Devin 的条目已经链接回它们来源的会话，记忆溯源更深入地解释了这一好习惯。将同样的习惯应用到您自己保留的决定中。
当一个极少使用的决定变得相关时，显式地将其引入会话中。然后 Devin 就可以使用它，如果它对您个人很重要，可以再次将其保存到记忆中。
在 MemoryLake 中进行设置
步骤 3 描述了一层团队和长期存在的上下文，它不应该依赖于个人的智能体。MemoryLake 就是为此而构建的：您只需编写一次长期记忆，即可在需要它的团队成员和智能体之间共享。
You write the entries yourself, in your own words. Nothing is read out of, written to, or deleted from Devin's memory drive, your skills, or any vendor's store.
步骤 1：创建 API 密钥
登录并从控制面板生成一个密钥。该密钥属于您的 MemoryLake 工作区，独立于任何 Devin 组织。
步骤 2：上传您的第一批记忆
从步骤 3 中的决定开始：那些罕见但重要的决定，每个都带有日期和原因。添加步骤 1 中无法自然融入 skill 的团队上下文。
步骤 3：连接您的 AI 和智能体
连接 Devin 和您团队使用的其他智能体。这样，每个团队成员和每个工具都可以使用相同的决定，包括在没有个人记忆的情况下启动的运行。
这在实践中改变了什么
第一个区别是 Devin 的记忆可以发挥其所长。个人偏好和修正会在无需任何人维护的情况下累积，而 Dreaming 会保持它们的整洁。
第二个区别是团队上下文不再依赖于谁运行了会话。规程存在于 skills 中，规范存在于仓库中，而长期存在的决定则保存在共享记录中。团队成员的会话和自动化运行都从相同的基础开始。关于更广泛的设置，请参阅为您的团队设置共享 AI 记忆。
第三个区别是修剪不再是一个风险。当极少用到的重要决定被记录在别处时，Dreaming 删除未使用的笔记只是日常整理，而不是损失。
第四个区别是关于什么在移动的清晰度。记忆格式是开放的，但您团队的知识不应该随着某个人的智能体而移动。正如多智能体系统的共享记忆所讨论的，并行运行多个智能体的团队在更大规模上面临着同样的问题。
Devin 记忆的最佳实践
让 Devin 学习您的个人偏好。 这正是记忆的用途。
在会话中纠正记忆。 应用中显示的记忆文件是只读的；请要求 Devin 忘记或记住。
将团队规程放在 skills 中。 记忆是私人的；skills 可以在组织范围内设置。
检查迁移后的 Knowledge。 确认每个条目都作为 skill 落在了正确的范围内。
显式地向自动化运行提供简要说明。 定时和触发的运行不使用个人记忆。
将罕见的决定保存在持久的地方。 Dreaming 会删除任何会话都未使用的笔记。
在做假设之前先对比设计。 正如 Claude 的 dreaming 记忆存储所示，其他助手现在也在后台合并记忆，并且每个助手划定的界限都不同。
结论
Devin 的新记忆功能针对其设计初衷进行了良好的设计。它将偏好、修正和经验教训作为简短的笔记保存在 Git 仓库中，将每一条链接回其来源，并运行每日 Dreaming 过程来进行合并、添加和删除。Cognition 已经开放了该格式，以便其他智能体也可以使用它。
文档对范围的界定非常清晰。记忆“在每个组织中对您个人而言是私有的”，自动化运行不会读取或写入它，而 Dreaming 会删除任何会话都未使用的笔记。团队指南属于 skills，Devin 较旧的 Knowledge 功能正在向其迁移。
因此，让 Devin 了解您，将团队规程放在 skills 和仓库文件中，并将极少出现但绝不能丢失的决定保存在您整个团队都能访问的记录中。