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

如何在个人和组织许可证之间管理 GitHub Copilot 记忆(2026年指南)

GitHub Copilot 记忆(GitHub Copilot Memory)旨在让 Copilot 随着使用时间的增加而变得更好。GitHub 将其描述为一种让 Copilot “通过记住有关您的仓库和个人编码偏好的事实,随着时间的推移变得更加高效”的方式。Copilot 云端智能体、代码审查、Copilot CLI 以及智能体自动修复(agentic autofix)都依赖于它,GitHub 指出:“由一个 Copilot 功能捕获的事实和偏好可以被另一个功能使用。”云端智能体了解到的关于您仓库的信息,可以为随后的代码审查提供参考。

然而,一些平常的事情发生了。您在晚上使用个人版的 Copilot,而在白天通过雇主使用它。或者您换了工作。或者您的团队将许可证从一个组织迁移到了另一个组织。突然之间,Copilot 似乎对您的偏好一无所知了。

这并不是系统故障。这直接源于 GitHub 分配记忆所有权的方式,官方文档中对此有明确说明。以下是它的工作原理、人们首先会尝试的方法,以及如何进行设置以将许可证变更带来的损失降到最低。

为什么当您的许可证变更时,您的 Copilot 记忆似乎消失了

Copilot 记忆存储两种类型的信息。仓库级事实(Repository-level facts)涵盖“编码规范、架构决策、构建命令和特定于项目的规则”。用户级偏好(User-level preferences)是“关于用户希望如何与 Copilot 交互的隐含或陈述的个人偏好”。

这两者的作用域不同。

仓库级事实属于仓库。GitHub 解释说,“这些事实只能在同一个仓库的操作中使用”,并且它们只有在“启用了 Copilot 记忆且对仓库拥有写入权限的用户执行操作时”才会创建。任何在该仓库中拥有 Copilot 记忆访问权限的人都能从中受益。它们在被使用前还会经过验证:“仓库级事实在存储时带有指向支持它们的代码的引用”,当某个事实看起来相关时,Copilot 会对照当前分支检查这些引用。“只有通过验证的事实才会被使用。”

用户级偏好会跟随您,但绑定了所有者。这是关键的一段:“偏好归属于计费实体(billing entity),即向用户授予许可证的组织或企业。”当创建偏好时,“它会针对用户当前使用的活跃计费实体进行存储。”而当 Copilot 为会话构建上下文时,“它会再次查看用户当前活跃的计费实体,并且仅检索归该计费实体所有的记忆。”

因此,当您的许可证来自雇主时,Copilot 学到的偏好归您雇主的组织或企业所有。当您在不同的许可证下工作时,Copilot 则会检索归该许可证所有的偏好。

如果您有多个访问来源,还有一个额外要求:“如果您通过多个企业或组织获得 Copilot 访问权限,您必须选择一个默认计费实体,以便通过 Copilot 记忆生成用户级偏好。”该默认设置决定了哪个账户可以管理和删除为您生成的偏好。

所有权对管理员也有实际影响。在 Business 和 Enterprise 计划中,用户级偏好“可以由组织或企业管理员查看和删除”。GitHub 的管理员指南补充道,管理员“可以导出或删除所有以您的组织作为活跃计费实体生成的用户级偏好”,格式为 JSONL。这些操作会被记录:“当管理员导出或删除记忆,以及当用户选择退出 Copilot 记忆时,事件会出现在您的组织或企业的审计日志中。”

还有两条规则决定了您能保留什么。可用性取决于计划:对于个人计划,Copilot 记忆默认开启,而“对于企业和组织管理的 Copilot 订阅,Copilot 记忆默认关闭,必须在企业或组织设置中启用。”此外,记忆会过期:“任何未使用的已存储事实或偏好将在 28 天后自动删除。”Copilot 记忆目前也处于公开预览阶段,因此具体细节可能会发生变化。

人们尝试的其他方法(以及误区)

误以为 Copilot 记忆是每人一份的。 实际上,它是每个计费实体一套偏好。个人计划和公司许可证各自拥有独立的记忆。

从未选择默认计费实体。 当从多个渠道获得访问权限时,GitHub 要求您先设置一个默认实体,然后才会为您生成用户级偏好。如果您的“记忆”页面完全没有显示任何偏好,这是首先需要检查的地方。

期望偏好能出现在代码审查中。 GitHub 指出,“Copilot 代码审查仅使用仓库级事实。在代码审查期间不应用用户级偏好。”而 CLI 则不同:“Copilot CLI 会应用仓库级事实以及发起操作的用户的用户级偏好。”

指望用记忆来保存团队所需的规则。 仓库级事实虽然有用,但它们是由 Copilot 推断出来的,并且在未使用时会过期。团队规则应该写在指令文件中,正如Copilot 如何解析其指令文件中所解释的那样。

混淆 Copilot 记忆与 VS Code 的本地记忆工具。 它们是具有不同存储和生命周期的独立功能,具体在在 VS Code 中设置 Copilot 记忆中进行了介绍。

解决方案:明确每条记忆的所有者,然后将您需要的内容保存在可以跟随您的地方

步骤 1:检查目前哪个计费实体拥有您的偏好

在 GitHub 上打开您的 Copilot 设置并转到“Memory”(记忆)。GitHub 指出:“用户可以在其个人设置中查看所有已存储的偏好及相应的物主。”仔细阅读它们并记录下每一个的所有者。GitHub 还补充道,“无论使用何种 Copilot 计划,用户都可以查看和删除自己的用户级偏好”,因此在查看时顺便删除任何过时的内容。

如果您从多个渠道获取 Copilot,请转到您的 Copilot 功能设置并选择一个默认计费实体。选择您在大部分工作中所使用的那个。GitHub 将此选择作为当您的访问权限来自多个渠道时生成用户级偏好的先决条件。

在此期间,检查 Copilot 记忆是否已启用。在组织管理的计划中,管理员必须先启用该策略;之后,用户默认加入,但可以单独选择退出。GitHub 将该功能描述为在组织或企业开启之前,对组织管理的订阅默认关闭,因此如果您的工作会话没有显示任何记忆,请与您的管理员联系。

最后,列出对您而言重要的偏好:您希望任何 Copilot 在任何许可证下都能了解的编码风格选择、审查习惯和工作流细节。

步骤 2:将团队知识放入仓库,并用自己的话记录个人偏好

将这两种上下文分开,并为每种上下文提供一个与其所有者相匹配的归宿。

团队知识属于仓库。规范、架构决策、构建命令和项目规则应该保存在 .github/copilot-instructions.md、特定路径的指令文件或 AGENTS.md 中。Copilot 记忆的仓库级事实可以作为这些文件的补充,但书面指令在闲置 28 天后不会过期,也不依赖于 Copilot 的正确推断。如果 Copilot 存储的仓库级事实很有用,可以将其作为编写规则的提示。在 Copilot 经常丢失代码库结构的地方,为什么 GitHub Copilot 会遗忘代码库上下文介绍了更广泛的修复方法。

个人偏好由您自己来重新阐述。用您自己的话写一个简短的列表:您喜欢如何组织代码结构、命名习惯、测试偏好、您希望如何获得解释。这是您对自己的描述,而不是存储在雇主计费实体下的任何内容的副本。您可以在任何许可证下告诉 Copilot 这些内容,它会重新记住它们。

注意这两者之间的界限。在雇主许可证下生成的偏好归您的雇主所有,管理员可以导出或删除它们。请将它们视为公司数据。如果您需要其中的某些内容,请向您的管理员申请;不要尝试自己复制它们。

步骤 3:在许可证变更发生前做好准备

许可证变更是可以预见的:新工作、团队迁移到企业账户、您添加或取消个人计划。为此做好规划。

在您离开组织之前,确保您贡献的团队上下文保存在仓库指令文件中,而不仅仅是在记忆中。仓库级事实会保留在仓库中,但它们可能会过期,而书面指令可以让后来者继续使用这些知识。这种交接的更广泛版本在在员工离职时保留 AI 上下文中进行了介绍。

当您在新的许可证下开始工作时,尽早向 Copilot 提供您的个人列表。在最初的几次会话中就告诉它您的偏好,而不是等待它去推断,并在一个星期后检查“Memory”设置页面,看看它保存了什么以及所有者是谁。

如果您同时使用个人计划 and 公司许可证,请刻意区分哪项工作使用哪个账号。GitHub 会针对创建偏好时处于活跃状态的计费实体来存储每个偏好,因此在 Copilot 学习您关心的内容时,请注意您正在使用的是哪个许可证。

在 MemoryLake 中进行设置

该解决方案将团队规则保留在仓库中,并将个人偏好用您自己的话记录下来。有些上下文介于两者之间,并且比任何许可证都更长久:您在多个项目中做出的决策、规范背后的原因,以及适用于您接触的每个代码库的经验教训。MemoryLake 就是保留这一层的地方,它独立于谁为您的 Copilot 席位付费。

您可以用自己的话亲自编写这些条目。不会从 Copilot 记忆、您的仓库或任何供应商的存储中读取、写入或删除任何内容。在添加任何关于雇主代码或决策的内容之前,请检查您组织的政策。

步骤 1:创建 API 密钥

登录并从控制面板生成一个密钥。该密钥属于您的 MemoryLake 工作区,与任何 GitHub 组织或许可证无关。

MemoryLake 控制台显示 API 密钥屏幕,在此处创建并复制新密钥以供智能体使用
MemoryLake 控制台显示 API 密钥屏幕,在此处创建并复制新密钥以供智能体使用

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

从步骤 2 中的个人列表以及您希望在任何会话中使用的跨项目原因开始。每个条目记录一个偏好或决策,并注明日期。

MemoryLake 工作区,已上传第一批文档,列出了每个文件成为可搜索记忆的过程
MemoryLake 工作区,已上传第一批文档,列出了每个文件成为可搜索记忆的过程

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

连接 Copilot 以及您使用的其他编码智能体。无论您在哪个许可证或工具下工作,您的偏好都将可用。

MemoryLake 集成屏幕,列出了可以连接到记忆层的 AI 客户端和智能体框架
MemoryLake 集成屏幕,列出了可以连接到记忆层的 AI 客户端和智能体框架

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

第一个改变是,缺失的偏好不再是一个谜。您知道哪个计费实体拥有哪些记忆,以及为什么在某个许可证下的会话不会显示在另一个许可证下学到的内容。

第二个改变是,团队知识在人员流动中得以保留。规则保存在每个 Copilot 界面都会读取的指令文件中,因此它们比 28 天的有效期以及最初解释它们的人活得更久。关于这些文件如何在终端中加载,请参阅配置 Copilot CLI 指令。

第三个改变是,换新工作并不意味着要从头开始。您自己写下的偏好只需一两个会话就能让新的 Copilot 快速上手。

第四个改变是,公司和个人上下文之间有了清晰的界限。公司所有的偏好留在公司,由其管理员控制,而您的便携式知识则是您自己写下的内容。

跨许可证使用 Copilot 记忆的最佳实践

设置默认计费实体。 当您从多个渠道获得访问权限时,这是必需的。

在“Memory”设置中检查所有者。 每个偏好都会显示其归属。

将团队规则写入指令文件。 记忆是推断出来的,且在未使用时会过期。

用您自己的话重新阐述个人偏好。 保持列表简短且最新。

将雇主所有的记忆视为公司数据。 向管理员申请,而不是直接复制它们。

记住每种记忆适用的场景。 代码审查仅使用仓库级事实;CLI 则两者都使用。

同时使用其他上下文来源。 精心构建的空间可以承载记忆无法承载的项目知识,正如构建保持最新的 Copilot 空间所示,而迁移工具的团队可以在从 Copilot 迁移到 Codex中对比不同的方法。

结论

GitHub Copilot 记忆存储保留在仓库中的仓库级事实,以及归属于为您授予许可证的组织或企业的个人偏好。Copilot 仅检索归您当前活跃计费实体所有的偏好,管理员可以导出或删除其组织所有的偏好,且未使用的记忆会在 28 天后过期。

这种设计对组织来说是合理的,但也意味着您的 Copilot 记忆并不是一个连续的整体。选择一个默认计费实体,检查谁拥有什么,将团队规则放入指令文件中,并用您自己的话记录您的个人偏好。

做好这些,许可证的变更就会变成一次简微的重新熟悉,而不是一切从头开始。

常见问题

谁拥有我的 GitHub Copilot 记忆偏好?

GitHub 指出:“偏好归属于计费实体,即向用户授予许可证的组织或企业。”您可以在个人 Copilot 记忆设置中查看每个偏好及其所有者。

为什么我的 Copilot 偏好没有出现在我的工作许可证下?

当 Copilot 构建上下文时,“它会再次查看用户当前活跃的计费实体,并且仅检索归该计费实体所有的记忆。”在个人计划下创建的偏好与在组织许可证下创建的偏好是分开归属的。

我需要选择默认计费实体吗?

是的,如果您通过多个组织或企业获得 Copilot 访问权限。GitHub 表示,您必须选择一个默认计费实体才能生成用户级偏好。

我的组织可以查看或删除我的 Copilot 偏好吗?

在 Copilot Business 和 Enterprise 计划中,管理员可以导出或删除以其组织或企业作为活跃计费实体生成的用户级偏好。这些操作会显示在审计日志中。

Copilot 代码审查会使用我的个人偏好吗?

不会。GitHub 指出,Copilot 代码审查仅使用仓库级事实,而 Copilot CLI 会应用仓库级事实以及发起操作的用户的偏好。

Copilot 记忆会将信息保留多久?

GitHub 表示,任何未使用的已存储事实或偏好将在 28 天后自动删除,当 Copilot 成功验证并使用某个条目时,计时器可能会重置。