GitHub 在 2026 年 5 月 26 日更新 Copilot Memory，重点是把 AI 记忆从「方便功能」推向「需要被管理的企业能力」。Copilot Memory 仍属 public preview，并向所有付费 Copilot plan 开放，但今次新增的控制项已经很接近企业落地时真正会遇到的问题。
第一个改动是删除指引更清楚。当用户要求 Copilot 忘记某些内容时，系统会指向正确位置让用户移除该项 memory，并在可投票的位置下调相关 memory。这看似细节，但对 AI 用户信任很重要：如果系统会记住偏好或 repo 事实，用户必须知道如何查看和移除。
第二个改动是 repository-level off switch。repository admins 现在可以在既有 Copilot feature controls 中关闭某个 repo 的 Copilot Memory。关闭后，repo-level facts 不会再被储存或读取；不过 GitHub 亦说明，既有 facts 不会因此自动删除，而 user-level preferences 亦不受影响。
第三个改动是 Copilot CLI 加入 /memory 指令。用户可以透过 /memory on 启用、/memory off 关闭，或 /memory show 查看目前状态，而且选择会跨 session 保留。这对开发者工作流很实际，因为 AI agent 越来越常在 terminal 和 IDE 之间切换。
第四个值得留意的地方，是 capture time 的 scope 提示更明确。store_memory permission prompt 会说明即将储存的是 user-level preference，还是 repository-level fact。前者只对个人跨 repo session 可见，后者则可被同一 repository 的 contributors 使用。这个边界很关键，因为个人习惯和团队事实的治理方式不应混在一起。
AI agent 要真正进入团队工作，记忆能力几乎不可避免。没有记忆，agent 每次都要重新理解 repo 习惯、架构、风格和流程；但有记忆，就会带来资料保留、权限、错误记忆、跨人共享和删除责任。GitHub 今次的更新，正是在补这条治理链。
对企业采用 AI 编码工具来说，这条新闻的讯号很清楚：未来要管理的不只是 prompt、模型和工具权限，还包括 AI 记住了什么、由谁批准、在哪个范围可见、何时可以关闭，以及如何删除。AI 记忆会由使用体验功能，逐步变成合规与营运管理的一部分。
