MemoryLake
返回全部文章
Tutorial2026 年 8 月 20 日·10 分钟阅读

如何防止 Devin 在多次运行之间丢失任务上下文 (2026)

Devin 拥有持久化机制,而任务上下文在多次运行之间仍然会消失的原因,在其官方文档中写得清清楚楚:Knowledge(知识库)“是共享代码库级别(而非任务级别)上下文的最佳方式,可以在 Devin 在您的代码库中工作时提供帮助。”

代码库级别,而非任务级别。括号里的这几个字就是全部答案。Knowledge 的设计初衷是让 Devin 熟悉您的仓库——“将其视为为新员工提供相关的组织上下文进行入职培训”——而不是将周二会话中的推理带到周四。因此,当第二次运行重新提出第一次运行已经排除的方法时,并没有发生故障。您是在要求一个代码库级别的存储来保存任务级别的状态。

本文将详细介绍其他四个导致上下文泄漏的地方、如何正确地将应该持久化的部分提升到 Knowledge 中,以及在哪里存放 Knowledge 并非为此设计的任务推理。该症状背后的机制请参阅为什么 Devin 会忘记任务上下文

首先澄清一点,因为文档现在同时涵盖了这两者:本页面介绍的是云端智能体 Devin 及其 Knowledge 系统。以前被称为 Windsurf 的编辑器现在作为 Devin Desktop 进行文档记录,拥有其专属的 Cascade 记忆和规则——这完全是另一种不同的机制

为什么任务上下文无法在 Devin 会话中幸存

Knowledge 的作用域是代码库,而非任务

这值得重申,因为它决定了下游的一切。Knowledge 是“Devin 可以在所有会话中参考的指令和建议的集合”。文档中列出的示例都是持久的、仓库级别的材料:“代码合规实践、部署工作流、PR 命名规范、测试工作流、如何与专有工具交互等”。

这些都不是“我们上周二针对这个 Bug 摸索出的结论”。任务级别的发现不在该存储的作用域内,这意味着它们只有在您刻意提升它们——或者将它们写在其他地方时才会持久化。

未固定的 Knowledge 仅在被触发时使用

第二大原因,也是人们常常忽略的一个配置细节。“Knowledge 是根据您设置的触发器(Trigger)进行检索的。触发器越具体(例如该 Knowledge 适用于哪个文件、仓库或任务类型),检索效果就越好。”

来自最佳实践列表:“如果您希望 Devin 在处理任何会话时都能检索到该 Knowledge 笔记,请务必将其固定(pin)到所有仓库。否则,如果该信息仅在特定上下文中相关,您可以将其固定到特定仓库。如果 Knowledge 未被固定,它将仅在被触发时使用,因此请确保您的触发器描述(Trigger Description)清晰明了。

因此,您编写了但从未固定的 Knowledge 笔记只能静静地躺在触发器描述后面。如果该描述很模糊,它可能根本不会被触发。笔记确实存在,但它无法触达会话。这与为什么智能体会忽略您编写的指令文件中描述的失败属于同一种类型。

这里有一个真正有用的功能,但未被充分利用:“Devin 会在会话中告诉您它使用了哪些 Knowledge;您可以在会话聊天的 'Accessed Knowledge'(已访问的知识)下看到这一点。”这是对“它真的读了我的笔记吗?”的直接回答——在做任何假设之前,先检查一下这里。

自动生成的 Knowledge 是起点,而非记录

Devin 会为您进行引导初始化:“Devin 将根据已连接仓库的现有 README、文件结构和内容自动生成仓库知识。”

这很有帮助,这意味着您的 Knowledge 库在开始时描述的是 README 中的内容——而在大多数仓库中,README 的部分内容已经过时。文档中列出的第一条最佳实践正是:“审查任何自动生成的 Knowledge,并验证其(a)完整性和(b)准确性。”

跳过这一步会给您留下自信、可检索但略微错误的上下文。这比空的存储更糟糕,因为它会被实际使用。

Devin 会读取专用文件并跳过普通的 .md

一条精确且容易被忽略的规则:“Devin 将根据您代码库中的专用文件自动拉取和更新 Knowledge,包括 .rules.mdc.cursorrules.windsurfCLAUDE.mdAGENTS.md请注意,Devin 不会自动拉取更通用的文件类型,例如 .md

这会带来两个后果。首先,如果您的规范存在于 docs/engineering-standards.md 中,Devin 不会自动拉取它们。官方文档建议修复此问题:“如果您的代码库中没有集中的专用文档文件,我们强烈建议您使用专用的文件扩展名设置一个。”

其次——这是一个令人惊喜的发现——如果您的仓库中已经有了来自其他工具的 CLAUDE.mdAGENTS.md.cursorrules,Devin 会直接读取它们。您为其他智能体编写的指令文件在这里已经开始发挥作用了。

没有仓库访问权限意味着没有 Knowledge

这是一个显而易见的警告:“请注意,如果您不授予 Devin 访问仓库的权限,它将不会生成任何关联的 Knowledge。”如果某个特定的仓库对 Devin 来说像是一张白纸,请在检查其他任何内容之前先检查访问权限。”

人们尝试过的方法

在每次会话开始时重新向 Devin 简报。 有效,但这意味着每次都要重新支付解决该问题的全部成本——陷入了如何停止向 AI 重复解释上下文中所描述的循环。

将每个任务的发现都写入 Knowledge。 可以理解,但这会让代码库级别的存储充斥着任务级别的噪音,从而降低对真正属于那里的材料的检索效果。

将所有内容固定到所有仓库。 保证了检索,但也会在每个会话中引入无关的上下文。这是一种粗暴的做法,其实有更精细的设置方式。

对自动生成的 Knowledge 不予审查。 这是最常见的捷径,它会将过时的 README 转化为看似权威的指导意见。

在仓库中保留一个名为 notes.md 的决策记录文档。 合理的直觉,但扩展名错了——Devin 不会自动拉取通用的 .md 文件。

假设编码偏好会自动跨运行传递。 只有当它们存在于 Knowledge 中且可触达时才会传递。这就是为什么 Devin 会忘记编码风格背后的情况。

解决方案:提升需要持久化的内容,然后保持任务推理可查询

两项工作:让 Knowledge 针对代码库级别的材料正常工作,并为任务级别的推理提供一个非会话的归宿。

今天就审查自动生成的 Knowledge。 按照文档指示,检查其完整性和准确性。删除任何描述已废弃系统的内容。过时的条目会以与正确条目相同的置信度被检索出来。

为每条笔记决定是固定还是触发。 应该始终适用?将其固定到所有仓库。仅在某个仓库中相关?固定到该仓库。确实视情况而定?保持触发状态——然后编写一个足够具体的触发器描述以使其生效,指明它适用的文件、仓库或任务类型。

如果您还没有专用文档文件,请创建一个。 AGENTS.md 是一个不错的默认选择:Devin 会自动拉取它,其他智能体也会读取它。如果您已经维护了 CLAUDE.md.cursorrules,那么您就已经搞定了——它们都在支持列表中。

将 "Accessed Knowledge" 用作您的反馈循环。 会话结束后,查看 Devin 实际使用了什么。如果您期望的笔记没有列出,问题出在触发器或固定设置上,而不是编写的内容。

对任何感觉像白纸的内容检查仓库访问权限。 没有访问权限,就没有生成的 Knowledge。

这使得代码库级别的上下文变得可靠。但仍然留下了文档明确置于 Knowledge 之外的类别——任务级别的推理。您在上次运行中尝试了什么以及为什么失败;您在进行到一半时发现的限制;您评估并拒绝的方法。将所有这些都提升到 Knowledge 中是错误的做法:它不是代码库级别的,而且会稀释对真正属于那里的内容的检索。

这正是 MemoryLake 所保存的内容:将任务和项目推理保存在一个供您的智能体查询的层中,与仓库级别的存储分开。设置只需三个步骤。

步骤 1:创建 API 密钥

登录 MemoryLake 并创建 API 密钥。在您连接的各种工具中通用这一个凭据。

创建 MemoryLake API 密钥以在运行之间保留 Devin 任务上下文
创建 MemoryLake API 密钥以在运行之间保留 Devin 任务上下文

步骤 2:上传您的第一批记忆

简短的条目,每条记录一个断言。对于自主智能体来说,以下类别能最快带来回报:

将拒绝的方法和任务中途的发现写入 MemoryLake
将拒绝的方法和任务中途的发现写入 MemoryLake

尝试过并被拒绝的方法,以及原因。 当智能体无人值守工作时,这是价值最高的一类条目。如果没有它,第三次运行会重新推导第一次运行已经证伪的内容——并为此耗费宝贵的时间。

单次运行中得出的、生命周期超出该运行的发现。 “预发布环境的种子数据在 2024 年之后没有行,因此日期范围测试在本地通过,但在那里失败。”这既不是代码库级别的建议,也不是一次性的临时发现。

仅在任务中途才显现出来的限制。 速率限制、行为与文档描述不同的依赖项、没人写下来的顺序要求。

决策及其背后的限制。 规范可以放入 Knowledge。而支持该规范的论据则属于可以被检索和推理的地方。

步骤 3:连接您的 AI 和智能体

连接您使用的工具。MemoryLake 可以通过 MCP 和 API 访问,因此原生支持 MCP 的智能体(包括 Claude Code、Codex 和 OpenClaw)可以通过指向 MCP 服务器进行连接,而其他助手则通过 API 读取相同的记忆。

将 Devin 和原生支持 MCP 的智能体连接到便携式记忆层
将 Devin 和原生支持 MCP 的智能体连接到便携式记忆层

三个坦诚的局限性。MemoryLake 不会写入 Devin 的 Knowledge,也不是它的替代品——Knowledge 是存放代码库级别上下文的正确地方,您应该正确配置它。它只保存您或您的智能体写入其中的内容,因此步骤 2 是实实在在的工作。而且它不保证合规性:可检索的上下文并不是强制执行的配置。

这在实践中带来了什么改变

第三次运行不再重复第一次运行的工作。 被拒绝的方法已被记录下来,因此无人值守的智能体不会花一整个会话去重新发现它们。

Knowledge 保持干净,检索保持精准。 代码库级别的材料存放在代码库级别的存储中,意味着触发器描述匹配的内容更少、更相关。

"Accessed Knowledge" 变得真正有用。 当存储不再是垃圾堆时,查看使用了什么能为您提供有价值的信息。

指令文件发挥双重作用。 AGENTS.mdCLAUDE.md 会自动填充 Devin 的 Knowledge,同时也能被其他智能体读取,因此一个文件可以服务于多个工具。

任务推理在更换工具后依然存在。 您对自身系统所了解的内容并非 Devin 独有——这就是AI 智能体的情景记忆中所涵盖的形式。

Devin Knowledge 和任务上下文的最佳实践

保持 Knowledge 处于代码库级别。 这是文档中明确的用途。任务发现应该存放在其他地方,否则会降低存储的质量。

固定必须始终适用的内容。 未固定的 Knowledge 仅在被触发时使用——这是文档中记录的行为,而不是需要规避的 Bug。

编写指明具体对象的触发器描述。 文件、仓库或任务类型。具体的触发器检索效果更好;文档中直接指出了这一点。

在信任自动生成的 Knowledge 之前先对其进行审查。 它源自 README、文件结构和仓库内容,而这些内容会过时。验证其完整性和准确性。

使用专用的文件扩展名。 .rules.mdc.cursorrules.windsurfCLAUDE.mdAGENTS.md——不要使用普通的 .md,因为它不会被自动拉取。

在重要会话结束后检查 "Accessed Knowledge"。 这是最廉价的诊断方法,但大多数人从未打开过它。

立即记录被拒绝的方法。 某种方法被排除的那一刻,是其原因在您脑海中最清晰的时刻。

为任何与环境相关的条目注明日期。 预发布环境的奇特行为和速率限制是会发生变化的。未注明日期的条目会变成未来的错误答案——这是AI 记忆是什么以及不是什么中的普遍问题。

结论

Devin 的 Knowledge 系统确实可以在会话之间持久化上下文,其文档对界限的划分非常精确:它适用于代码库级别而非任务级别的上下文;除非您将其固定,否则它将通过您设置的触发器进行检索;它是根据您需要审查的材料自动生成的;并且它从专用文件而非通用的 .md 文件中拉取内容。

正确设置这些内容,仓库级别的这一半问题就不再是问题。然后将任务级别的推理视为一个独立的类别——被拒绝的方法、任务中途的发现、环境限制、每个决策背后的论据——并将其保存在您的智能体可以查询的层中。这就是一个在每次运行开始时都表现得像称职新员工的智能体,与一个在每次运行开始时都像第一天入职的同一个新员工的智能体之间的区别。

常见问题

Devin 会在会话之间记住上下文吗?

是的,通过 Knowledge——“Devin 可以在所有会话中参考的指令和建议的集合”。文档中一个重要的限定条件是,Knowledge 针对的是代码库级别而非任务级别的上下文,因此它并非旨在将一个任务的发现带入下一个任务。

为什么 Devin 没有使用我编写的 Knowledge 笔记?

最有可能的原因是它没有被固定。根据文档,如果 Knowledge 未被固定,它将仅在被触发时使用,因此触发器描述必须清晰。对于应该始终适用的笔记,请固定到所有仓库;如果信息仅在特定仓库中相关,请固定到该特定仓库。您可以在会话聊天的“Accessed Knowledge”下确认使用了哪些内容。

Devin 会自动读取哪些文件?

文档列出了 .rules.mdc.cursorrules.windsurfCLAUDE.mdAGENTS.md,并指出 Devin 不会自动拉取更通用的文件类型(如 .md)。如果您的规范写在普通的 Markdown 文件中,请将它们移至上述文件之一。

我应该把任务发现放入 Knowledge 中吗?

通常不建议这样做。根据文档,Knowledge 是存放代码库级别上下文的地方——如合规实践、部署和测试工作流、PR 规范。用任务级别的细节填充它会稀释对真正属于那里的材料的检索;任务推理需要自己专属的可查询归宿。

为什么 Devin 针对我其中一个仓库的 Knowledge 是空的?

请检查仓库访问权限。文档指出,如果您不授予 Devin 访问仓库的权限,它将不会生成任何关联的 Knowledge。

Devin Desktop 的记忆与 Devin 的 Knowledge 是一样的吗?

不是。Devin Desktop(以前被称为 Windsurf 的编辑器)拥有其专属的 Cascade 记忆和规则,具有不同的作用域和存储方式,并有单独的文档记录。Knowledge 是云端智能体的机制。配置其中一个并不会自动配置另一个。