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

如何在 VS Code 中设置 Copilot 记忆(2026年指南)

Copilot 现在拥有了一个记忆层。如果你一直把它当成一个在对话之间会遗忘你代码库的工具,那么这个假设已经过时了。VS Code 的文档(更新于 2026 年 8 月 26 日)是这样引入这个主题的:"Visual Studio Code 中的智能体使用记忆来跨对话保留上下文。智能体无需在每次会话中从头开始,而是能够召回您的偏好,应用先前任务中的经验教训,并随着时间的推移逐步积累关于您代码库的知识。"

这里有两个需要注意的地方,在您依赖这些功能之前,这两点都非常值得了解。

第一点是,这里有两个记忆系统,而不是一个,且文档明确指出它们是独立的功能:"Copilot Memory 处于预览阶段,与上述本地记忆工具是分开的。" 它们在存储位置、作用域、写入主体、是否默认开启以及如何结束方面都有所不同。

第二点是,其中一个系统会根据定时器结束。埋在列表中的一个事实改变了您应该如何使用它:"自动过期:记忆会在 28 天后被删除,以避免过时的信息。"

本指南将介绍每个系统保存的内容、如何开启您需要的部分,以及哪些内容应该存放在不会过期的地方。

首先划定一个界限。这一问题的症状表现——即 Copilot 不断重新学习您的项目时是什么样子——已在 why GitHub Copilot forgets codebase context 中进行了讨论。该页面早于此处描述的记忆功能,因此您可以阅读它以了解症状,并阅读本文以了解当前的机制。

为什么仓库知识仍然会丢失

这是两个系统,且不可互换

记忆工具(The memory tool)是本地的,内置于 VS Code 中。文档将其描述为"一个内置的智能体工具,允许智能体在工作时保存和召回笔记。您也可以明确要求智能体记住某些内容。" 它目前处于预览阶段,由 chat.tools.memory.enabled 设置控制,并具有三个作用域:

  • User 位于 /memories/ —— 跨会话跨工作区持久化。用于"偏好、模式、常用命令"。
  • Repository 位于 /memories/repo/ —— 跨会话持久化,作用域限于工作区。用于"代码库规范、项目结构、构建命令"。
  • Session 位于 /memories/session/ —— "否(聊天结束时清除)"。用于"特定任务的上下文、进行中的计划"。

Copilot Memory 是另一个系统:"一个由 GitHub 托管的记忆系统,允许 Copilot 在工作时学习并保留特定于仓库的洞察," 并"在多个 GitHub Copilot 界面中共享,包括 Copilot 云端智能体、Copilot 代码审查和 Copilot CLI。" 它仅限于仓库作用域,由智能体自动写入,且默认关闭。

混淆这两者是人们认为记忆功能不起作用的最常见原因。本地工具默认开启,而托管工具则不然。

跨界面的系统需要双重确认开启

Copilot Memory "默认关闭,必须在您的 GitHub 设置中启用" —— 对于 Copilot Pro 或 Pro+ 用户,在个人 Copilot 设置中启用;对于团队,通过组织或企业策略设置启用。

如果您希望您的仓库记忆由其支持,VS Code 端还有第二个关卡:一个默认禁用的实验性设置,以及"必须在您的 GitHub 设置中为该仓库启用 Copilot Memory"的要求。而且失败是无声的:"如果未满足任一条件,仓库记忆将回退到本地文件存储。" 没有任何错误提示。您的仓库记忆只是留在您的笔记本电脑上,而您以为已经开启的跨界面行为从未发生。

仓库记忆在 28 天后过期

这是设计方案时需要围绕的核心事实。Copilot Memory 会在 28 天后删除记忆,其给出的理由很充分——"以避免过时的信息。" 与之配合的是一个真正不寻常且值得称赞的安全保障:记忆在"使用前会进行验证",这意味着"智能体在应用记忆之前会根据当前代码库对其进行验证,从而防止陈旧或错误的信息影响结果。" 极少有记忆系统会在采取行动前针对现实进行自我检查。

但把这两点结合起来看。一个既针对代码进行验证又在四周内过期的系统,是针对近期的操作洞察进行优化的——比如构建中的奇特问题、不稳定的测试、上周审查中发现的模式。它并不是为了保存您在三月份做出的架构决策而设计的。任何您在六个月后还需要的东西都必须存放在其他地方,文档自带的对比表也通过对比 Copilot Memory 的"自动(28天)"过期与本地工具的"手动管理"说明了这一点。

指令与记忆回答不同的问题

指令(Instructions)是的要求;记忆(Memory)是智能体学到的东西。Copilot 支持许多第一种类型:单个 .github/copilot-instructions.md、一个或多个 AGENTS.md 文件、在 GitHub 组织级别定义的组织级指令,以及——值得注意的是——一个"为了与 Claude Code 和其他基于 Claude 的工具兼容"而从工作区根目录、.claude 文件夹或用户主目录读取的 CLAUDE.md 文件。基于文件的 *.instructions.md 文件通过 applyTo 头部添加 glob 作用域,其文档记录的位置包括 .github/instructions and .claude/rules

该系统的一个属性比其他任何属性都更重要:"如果您的项目中有多个指令文件,VS Code 会将它们合并并添加到聊天上下文中,不保证特定的顺序。" 是合并,而不是通过优先级解决。如果两个文件发生冲突,没有任何机制为您做决定——这有力地证明了应该保持要求精简且明确,而不是将指令文件用作存放您所知道的一切的档案柜。

人们尝试过的方法

开启记忆工具并以为这就是 Copilot Memory。 本地工具默认启用并写入您的机器。跨界面系统是 GitHub 上一个独立的加入项。

将所有内容都放入 .github/copilot-instructions.md 在内容变长之前它一直有效,然后它就会与第二个 AGENTS.md、继承的 CLAUDE.md 以及任何匹配的 .instructions.md 文件竞争上下文——且它们之间没有保证的顺序。

期望记忆来强制执行规则。 它不会。指令是您的要求;记忆是被注意到的内容。任何每次都必须遵守的内容都应该属于会导致构建失败的检查。

在造成后果后才发现 28 天的有效期。 常见版本:第一周记录的决定,在第六周消失,在第七周重新争论。

得出 Copilot 根本没有记忆的结论。 几个月前这还可以理解,今天则是错误的,这会导致人们手动重建两个已有文档记录的系统已经做好的事情。

解决方案:将必须遵守的内容与可以过期的内容分开

设置本身很简短。请按以下顺序进行。

如果记忆工具关闭,请启用它。 它默认开启,但请确认 chat.tools.memory.enabled,然后有意识地使用它:用户记忆用于跨项目偏好,仓库记忆用于代码库事实,会话记忆用于您当前正在执行的计划。一个值得记住的细节——对于用户记忆,"在每次会话开始时,前 200 行会自动加载到智能体的上下文中"。保持该文件顶部的内容值得占用这个空间。

仅在您需要跨界面学习时启用 Copilot Memory。 个人用户在个人 Copilot 设置中启用,组织在策略设置中启用,如果您希望仓库记忆由其支持,还需要进行仓库级启用和 VS Code 实验性设置。然后进行验证而不是凭空假设,因为回退到本地存储是无声的。

让仓库所有者养成审查的习惯。 存储的记忆可以在 Repository Settings > Copilot > Memory 中进行审查和删除,且记忆"只能由具有写入权限的贡献者创建。" 每月查看一次该列表;这是了解您的智能体认为您的代码库是什么样子的最快方法。

将必需的指导保留在指令中,而不是记忆中。 一个始终开启的文件,其余的使用有作用域的 .instructions.md 文件,并且在这两者中都不要放入任何如果被忽略会让你感到沮丧的内容——因为它们之间无法保证顺序。

然后处理带有四周时钟限制的部分。MemoryLake 是一个独立于任何单一工具之外的记忆层,因此必须存活超过 28 天的知识得以保留。设置分为三个步骤。

步骤 1:创建 API 密钥

登录并创建 API 密钥。一个凭证即可跨您连接的工具使用。

在 Copilot 的两个记忆系统旁创建 MemoryLake API 密钥
在 Copilot 的两个记忆系统旁创建 MemoryLake API 密钥

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

简短的条目,每条只包含一个主张。在这里写下 Copilot Memory 明确不适合保存的内容:

将必须存活超过 28 天有效期的知识写入 MemoryLake
将必须存活超过 28 天有效期的知识写入 MemoryLake

决策及其原因。 "API 在路径中进行了版本控制,因为有两个移动端客户端固定在旧版本上。" 仓库记忆会过期;但原因不应该过期。

尝试过但被拒绝的方法。 看起来正确但失败的方法,以及它是如何失败的。Copilot 的两个系统中都没有用于记录否定结果的字段。

所有权和边界。 谁拥有哪个服务、哪些目录被冻结、该询问哪个团队。关于人而不是关于代码的事实,这意味着无论对代码库进行多少次验证都无法恢复它们。

指向外部的指针。 仪表板、事件日志、设计文档——智能体无法通过阅读您的仓库找到的上下文。

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

连接您使用的工具。MemoryLake 可以通过 MCP 和 API 访问,且 VS Code 支持 MCP 服务器,因此在 Copilot 旁也可以使用相同的记忆。Claude Code、Codex、Cursor 和 Cline 也会读取相同的记忆——这在这里很重要,因为 Copilot 的指令加载器已经读取了 CLAUDE.md.claude/rules,所以混合工具团队是常态而非特例。

将 VS Code、Copilot 和其他智能体连接到一个共享记忆层
将 VS Code、Copilot 和其他智能体连接到一个共享记忆层

三个坦诚的限制。MemoryLake 不会读取或写入 /memories/ 或 Copilot Memory —— 这两个存储库都没有 API,这就是为什么上述审查习惯需要手动进行的原因。It does not change instruction ordering;"不保证特定顺序"的行为是 VS Code 的。并且记忆是上下文,而不是强制执行 —— 任何在每次运行时都必须为真的内容都属于 CI。

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

这两个系统不再是一个模糊的功能。 您知道哪一个是本地的,哪一个是托管的,以及您实际启用了哪一个。

过期不再是一个意外。 Copilot Memory 中保留四周的操作洞察;在没有定时器的地方保留持久的推理。

指令文件变得更短。 一旦知识有了归宿,要求就不再需要用背景信息来填充。

跨界面在您开启时确实有效。 因为您验证了它,而不是信任一个会默默回退到本地存储的设置。

Copilot 记忆的最佳实践

确认您启用了哪个系统。 本地记忆工具默认开启;Copilot Memory 默认关闭,需要 GitHub 端启用。

将 28 天的有效期视为设计约束。 将下个季度需要的所有内容放在它之外。

每月阅读一次仓库记忆列表。 Repository Settings > Copilot > Memory。它是您的智能体所相信的内容的镜子。

保持用户记忆的前 200 行具有价值。 这是加载到每个会话中的部分。

将会话作用域用于计划。 /memories/session/ 会在聊天结束时清除,这正是进行中工作所需要的。

不要堆叠指令文件并寄希望于优先级能救你。 无法保证顺序;矛盾的内容只会同时到达。

记住指令不会触及行内建议。 文档指出,它们"在您于编辑器中键入时,不会被纳入行内建议的考虑范围。"

检查 Agent Host 上从何处读取用户级指令。 文档指出,它读取"与 harness 无关的文件夹,如 ~/.copilot/instructions~/.claude/rules,而不是从 VS Code 配置文件的用户数据中读取" —— 通用陷阱在 why agents ignore your instruction files 中有描述。

结论

Copilot 在 VS Code 中的记忆故事在日常对话中是两个同名的功能。本地记忆工具处于预览阶段,默认开启,并分为用户、仓库和会话作用域,其中用户记忆的前 200 行会加载到每个会话中。Copilot Memory 处于预览阶段,默认关闭,由 GitHub 托管,仅限于仓库作用域,由具有写入权限的智能体自动写入,并在云端智能体、代码审查和 CLI 之间共享。它的安全保障是真实的——记忆在使用前会针对当前代码库进行验证,这比大多数系统做得都要多。

而且它们会在 28 天后被删除。这一行字就告诉了您该系统的用途:近期的、可检查的操作洞察,而不是机构知识。有目的地设置这两个系统,验证跨界面路径而不是凭空假设,在知道无法保证顺序的情况下将要求保留在指令文件中,并将决策、被拒绝的方法和所有权事实放入一个没有过期时钟的层中。

这样做,Copilot 就不会每个月都重新学习您的代码库——您可以亲自查看每个层保存的内容,这就是 how to audit what your AI assistants actually remember 中的练习。

常见问题

GitHub Copilot 现在有记忆功能吗?

是的,有两种形式,均在文档中记录为预览版。VS Code 中的本地记忆工具(memory tool)允许智能体"在工作时保存和召回笔记",具有用户、仓库和会话作用域,并且默认通过 chat.tools.memory.enabled 启用。Copilot Memory 是一个独立的、由 GitHub 托管的系统,可自动捕获特定于仓库的洞察,并在 Copilot 云端智能体、Copilot 代码审查和 Copilot CLI 之间共享。它默认关闭。

Copilot Memory 会将记忆保留多久?

28 天。文档将自动过期列为该系统的一个属性:"记忆会在 28 天后被删除,以避免过时的信息。" 本地记忆工具没有自动过期——其对比行显示为"手动管理"——因此,任何您希望持久保留的内容要么存在于本地工具中,要么存在于指令文件中,要么完全存在于 Copilot 之外。

我启用了仓库记忆共享,但没有任何变化。为什么?

最有可能的是两个条件之一未满足。要用 Copilot Memory 支持仓库记忆,需要一个默认禁用的实验性 VS Code 设置,并且在您的 GitHub 设置中为该仓库启用了 Copilot Memory。文档指出,"如果未满足任一条件,仓库记忆将回退到本地文件存储" —— 且没有错误提示。检查这两项,然后确认行为,而不是凭空假设。

谁可以创建和删除 Copilot Memory 条目?

智能体在工作时会自动创建它们,且作用域有限:记忆"与特定仓库绑定,且只能由具有写入权限的贡献者创建。" 在审查方面,"仓库所有者可以在 Repository Settings > Copilot > Memory 中审查和删除存储的记忆。" 出处和审查是值得养成习惯的两件事——通用原则在 memory provenance explained 中有解释。

我应该使用指令文件还是记忆来制定编码规范?

指令文件。记忆是智能体注意到的内容;指令是您的要求。Copilot 支持 .github/copilot-instructions.mdAGENTS.md、组织级指令、兼容性读取的 CLAUDE.md 以及具有 glob 作用域的 *.instructions.md 文件。需要围绕规划的一个警告是:"如果您的项目中有多个指令文件,VS Code 会将它们合并并添加到聊天上下文中,不保证特定的顺序," 因此请保持要求精简且不矛盾。如果您是从 Claude Code 迁移过来的,文件级映射在 how to migrate your CLAUDE.md to Copilot 中有介绍。

Copilot 记忆能替代记忆层吗?

对于任何长期存在的内容都不行。这两个 Copilot 系统在设计上是互补的——文档建议将本地工具"用于 VS Code 中的个人偏好和特定于会话的上下文",将 Copilot Memory"用于惠及所有 Copilot 智能体的仓库知识。" 两者都局限于 Copilot,其中一个在 28 天后过期,且两者都没有地方记录做出决策的原因或您的团队放弃了哪种方法。这就是 what persistent memory is 中描述的层,它是必须比这两个预览版存活更久的部分。