GitHub Copilot 的内存架构

每个带有内存的编程代理都会报告基准测试分数。GitHub Copilot 报告了一个更罕见的东西：生产环境中的实际效果。

启用内存后，Copilot 编程代理的拉取请求合并率从 83% 提升到了 90%，这是通过对真实开发者的 A/B 测试得出的，p<0.00001。

不过，Copilot 的内存之所以值得研究，并不是因为那个数字。而是其底层的设计决策：内存锚定在代码上，并在使用时进行验证。

本文详解其工作原理：每个内存的结构化对象、存储和提供内存的架构、它如何针对不断变化的代码进行自我修复，以及外部层在哪些地方可以弥补其无法触及的部分。

内存是结构化对象，而非笔记

大多数代理内存都是自由文本：一个 markdown 文件、向量存储中的一条嵌入句子、一行日志。而 Copilot 的内存是带有四个字段的结构化对象：

• 主题 (Subject)：话题，例如“API 版本同步“

• 事实 (Fact)：知识本身，例如“客户端 SDK、服务器路由和文档中的 API 版本必须匹配“

• 引用 (Citations)：具体的代码位置，文件路径加行号（src/client/sdk/constants.ts:12, server/routes/api.go:8, docs/api-reference.md:37）

• 原因 (Reason)：为什么重要，例如“如果版本不一致，集成会失败或出现细微错误“

引用是关键所在。Copilot 的内存不是“API 版本需要匹配“。而是将这个声明与证实它的具体代码行绑定在一起。正是这个选择使得其他一切成为可能。

架构：一个工具、一个 API 和一个存储

底层来看，Copilot 内存由三个组件通过两条路径连接而成。在写入路径上，正在处理任务的代理如果认为某件事值得保留，就会调用 store_memory 工具。这会生成一个内存对象（上述的四字段格式），该对象发送给内存 API，并由其持久化到内存数据库中。创建过程是内联且由代理驱动的；没有单独的批处理进程在监控会话。

在读取路径上，当新任务开始时，系统请求内存 API 获取该仓库的近期内存。API 从内存数据库中拉取这些内存，并返回一个 memory_list，该列表在被注入到代理的提示词中后，下一个代理才真正开始工作。因此，一个代理学到的东西通过共享的数据库传递给下一个代理，而不是通过上一个会话结束时的任何对话状态。

图表中明确的一个细节是：检索的是“仓库的近期内存“，基于时间范围，而非相关性排序。GitHub 将专门的搜索工具和加权优先级标记为未来的工作。因此，当前系统在保持记忆正确性方面很强，但在选择展示哪些记忆方面相对直接。

在读取时对抗过时

代理内存的难题在于存储的知识会腐化。代码变了，你上个月保存的事实现在错了，而一个自信地提供过时事实的内存系统比完全没有内存更糟。

大多数系统要么忽略这个问题，要么尝试离线整理，定期重新扫描和修剪。Copilot 两者都不做。它采用即时验证：在代理使用存储的内存之前，它会针对当前分支重新读取引用。如果引用的代码行仍然支持内存中的声明，就使用它。如果它们已发生变化并与内存矛盾，则不使用，并存储一个反映新证据的修正版本。

这将过时从无声的失败转化为明确的修正步骤，而且成本低廉，因为验证主要是读取文件。内存基础在使用过程中自我修复。（这种验证是由 LLM 提示驱动的行为，而不是硬编码的保证。）GitHub 通过植入对抗性记忆（与代码矛盾的事实、引用不相关或不存在的行）对系统进行了压力测试，并报告说代理始终能捕捉到矛盾并重写错误的条目。

验证与滑动过期时间配对。存储的事实或偏好如果在 28 天内未被使用就会被删除，每当 Copilot 验证并重用该条目时，计时器会重置。因此，保持准确并被持续使用的记忆会持久存在；不再被触及的记忆会因闲置而过期。新鲜度来自两种力量：在读取时检查，空闲时修剪。

作用域与共享

内存的作用域限定于一个仓库，并且作用域通过权限而非约定强制执行：内存只能由具有写权限的贡献者在该仓库的操作中创建，并且只能在对该仓库有读权限的用户的任务中展示。这防止了一个私有仓库的知识泄露到另一个仓库，并将可见性与现有的访问控制绑定。

在这些限制内，存储包含两种条目：仓库级别的关于代码库的事实，以及用户级别的关于你偏好工作方式的偏好。这些内存在三个 GitHub 托管的界面中共享：云端编程代理、代码审查和 CLI。这些界面以不同方式应用层级。代码审查只使用仓库事实，忽略用户偏好；CLI 只对启动操作的用户应用事实和偏好。（这与本地 VS Code 内存工具是分开的，后者仅限于 VS Code，不进入这个池子。）

数字说明了什么

在真实开发者中进行的 A/B 测试结果，p<0.00001：

• 编程代理：PR 合并率从 83% 提升到 90%（+7 个百分点）
• 代码审查：对评论的正面反馈从 75% 提升到 77%（+2 个百分点）

一项合成代码审查评估显示精度提高 3%，召回率提高 4%。（GitHub 报告了主要数据和 p 值，但没有报告样本量或方法论。）

从发布角度来看，它从 2025 年 12 月的早期访问，到 2026 年 1 月 15 日的公开预览版，默认关闭，付费计划可在编程代理、CLI 和代码审查中选择加入。2026 年 3 月 4 日，它默认对个人 Pro 和 Pro+ 用户开启（现在可选择退出）；企业和组织计划保持关闭状态，直到管理员启用该策略。

其局限性

基于引用的设计既是优点也是牢笼。你可以锚定到文件和行的事实正是模式想要的；而不能锚定的事实——团队约定、工作流程习惯、风格偏好——则缺乏可验证的坚实基础，因此仓库事实层级在代码方面保持精准，而在其他方面则相对沉默。

其余的限制源于设计。检索基于时间范围，因此存储的价值取决于什么恰好是最近的，而不是什么最相关。内存也绑定到它被学习的仓库：它不能跨仓库使用。

外部层的作用位置

Copilot 在一个产品内为一个仓库构建了内存。问题的另一半——跨越你实际使用的工具的内存——正是从那个边界结束的地方开始。这就是 Mem0 要填补的空白。

作为一个专用层而非仓库功能，它带来了两个好处。它按含义而非时间进行检索，通过语义相似性、关键词和实体链接进行多信号搜索，因此浮现的内存是适合任务的。它按身份而非工具范围进行作用域限定：一个内存跟随你跨过 Cursor、终端代理、你的 CLI、每个仓库和机器，并且它包含那些永远无法绑定到一行代码的偏好类事实。

Copilot 在仓库内继续做它最擅长的事；这为它周围的一切提供了一个共享、可移植的内存。

有关每个主要框架如何处理此问题的更多信息，请查看：

mem0@mem0ai · 6 月 2 日 文章
代理框架中的内存现状
代理框架是 AI 软件实际运行的地方。Cursor、Devin、Claude Code、Codex：这些环境处理上下文、编排工具、协调代理，并且越来越多地管理内存。……
27117793199K

《上下文内》第 12 期

本文是 @mem0ai 博客系列《上下文内》的一部分，涵盖 AI 代理内存和上下文工程。

Mem0 是一个智能、开源的内存层，专为 LLM 和 AI 代理设计，提供跨会话的长期、个性化和上下文感知的交互。

• 在这里获取免费 API 密钥：app.mem0.ai
• 或从我们的开源 GitHub 仓库自行托管 mem0

参考资料

• GitHub：为 GitHub Copilot 构建代理内存系统
• GitHub 文档：Copilot 内存
• GitHub 文档：Copilot 代码审查
• GitHub 更新日志：代理内存在公开预览中（2026 年 1 月 15 日）
• GitHub 更新日志：Copilot 内存对 Pro/Pro+ 默认开启（2026 年 3 月 4 日）
• VS Code 文档：内存