GitHub 在 9 月 25 日更新了 agentic autofix：已经开启该能力的客户，autofix 现在会先查阅仓库里已有的 Copilot Memory，找出有助于解决安全告警的上下文，并在产出修复时把这个修复模式本身存成一条新记忆。按官方说明，这些记忆之后能帮助 autofix 处理更多安全告警，也能让 Copilot code review 与 Copilot cloud agent 了解"这个仓库特有的安全开发模式"。
这条更新只有一分钟的阅读量，但它改变的东西不小：安全修复从此有了跨会话的载体。要理解它值不值得开启，需要先弄清 Copilot Memory 本身是怎么工作的——记忆存在哪里、能活多久、谁能删、谁能看。
AI Coding 交流群
如果你也在用 AI 写代码，或者正在研究 Cursor、Claude Code 这些工具，欢迎加入以下交流群。群里平时会聊一些 AI 编程的实际用法、开发工作流，还有各种新工具和新玩法。
发生了什么：autofix 从一次性回答变成读记忆、写记忆
原来的 agentic autofix 是一次性的：接到一条安全告警，读取当前代码，给出修复建议，结束。它不会记得上次在同一个仓库里用过什么修法，也不会把这个修法告诉别的 Copilot 能力。
更新后的流程多出两个动作。向前，它会"reviews existing memories for context that can help resolve security alerts"，也就是把仓库已有的记忆当作本次修复的输入；向后，当它产出一个修复，会把这个修复模式"stores the fix pattern as a memory for future use"。结果是同一份知识可以在能力之间流动：autofix 学到的东西，官方明确点名会用于 Copilot code review 和 Copilot cloud agent。
Copilot Memory 到底是什么：两类记忆、两种作用域
要判断这条更新落地的效果，得先看清记忆的模型。按 GitHub 文档，Copilot Memory 处于 public preview，分为两类：
- 仓库级事实。包括代码约定、架构决策、构建命令和项目规则。创建这类记忆要求用户对该仓库有写权限；它对该仓库里所有能访问 Copilot Memory 的人共享，但只能在同一个仓库的操作中被使用。
- 用户级偏好。关于"希望怎样与 Copilot 交互"的明确或隐含偏好。它跟人走而不是跟仓库走，可以跨仓库使用。
两者都带引用（citation）。仓库级事实的引用指向支撑它的代码，Copilot 会拿引用去核对当前分支，只有校验通过的事实才会被使用；用户级偏好的引用里可能包含用户原话，由 Copilot 自行判断是否仍然适用。一个容易被忽略的细节是：即使 PR 被关闭且没有合并，事实也可能被捕捉下来，靠校验来避免在代码不再支持它时改变行为。
过期规则是这套机制里最值得记住的数字：任何未被使用的记忆会在 28 天后被自动删除，而当 Copilot 成功校验并使用某条记忆时，这个计时可能被重置。换句话说，记忆库的规模由实际使用决定，不是只增不减。
完整工作场景：同一条告警的两次修复
设想一个团队在一个月里处理同类 SQL 注入告警。第一次，autofix 分析代码，发现这个仓库统一通过某个封装好的查询构造函数来拼 SQL，于是给出符合该约定的修复。因为开启了 Copilot Memory，这次修复的模式被存成一条带引用的记忆。
两周后又出现同类告警。这一次 autofix 在动手之前先读到那条记忆，知道这个仓库不接受直接拼字符串的写法，于是直接按既有约定改，不再需要开发者纠正一轮。这个过程也会影响别的能力：Copilot code review 之后审查其他人提交的类似代码时，拿到的是同一批仓库级事实（文档明确 code review 只使用仓库级事实，不套用个人偏好）。
这些记忆在实际运行中各取所需。Copilot CLI 使用仓库级事实，外加"启动这次操作的那个人的偏好"；Copilot code review 只用仓库级事实。对团队来说，这意味着同一份仓库知识在不同入口的表现会有差别——不是所有人都看到同样的建议。
为什么这会改变工作流
安全修复长期受制于一个问题：审核者要反复解释同一个约定。扫描器报出告警，但"这个仓库里应该怎么改"是隐含知识，散在评审意见和历史 PR 里。把修复模式落成带代码引用的记忆，等于把这类约定从评审意见里挪进了一个被校验、会被过期的结构里。
第二步的变化更关键：记忆是可推翻的。引用要对着当前分支校验，代码不再支持它时它就不生效，长期不用的记忆会自动过期。这比写进 wiki 或者 CLAUDE.md 的规则更不容易腐坏——后者一旦写下就默认一直正确，直到有人想起来删。
限制与人接管点
管理模型需要先说清楚，因为它决定了你能不能让这件事发生。Copilot Memory 的启用是按用户而不是按仓库的：打开之后，该用户在任何仓库里使用 Copilot 时都会生效。个人方案默认开启；企业或组织管理的方案需要管理员先启用策略，之后用户可以自行选择退出。
在 Business 与 Enterprise 下，用户级偏好归属于出资实体（billing entity）。记忆按用户创建时的活跃出资实体存储，构建 agent 会话上下文时只会取用当前活跃出资实体拥有的记忆——持有多份许可证的用户，需要先在账户设置里指定默认出资实体，用户级偏好才可能生成。这条限制在跨部门、跨实体使用同一账号的场景里会直接决定功能是否生效。
可见与可删同样有明确边界：仓库所有者可以查看并手动删除本仓库的事实；用户可以查看并删除自己的偏好，且不受方案限制；Business 与 Enterprise 的管理员可以按用户或批量导出、删除用户偏好，组织与企业也可以查看和删除这些偏好。
人的接管点在这里：autofix 写入的是一条"修复模式"，它对不对取决于这次修复本身是否正确。官方描述的是它会把修复模式存为记忆，并没有说这个模式在入库前需要人工批准，所以开启之前应当确认 CodeQL 之类扫描器的告警质量——一条被固化的错误修法，会顺着记忆进入后续的 code review 与 cloud agent。
如何试用
- 先在个人设置里确认 Copilot Memory 的状态；企业或组织管理的方案需要管理员先启用策略。
- 持有多份许可证时，先在账户设置里指定默认出资实体，否则用户级偏好不会生成。
- 处理一条安全告警后，去仓库设置里查看生成的仓库级事实，确认它的引用指向的代码符合预期。
- 间隔一段时间后再次触发同类告警，观察 autofix 是否复用了先前的修复模式。
信息来源
- GitHub Changelog，2026-09-25，Agentic autofix now uses Copilot Memory：github.blog
- GitHub Docs，Copilot Memory（public preview）：docs.github.com
HiFox ：将 Agent 变成真正的队友
另外，我们也在思考，AI 如何从个人提效走进团队协作。
HiFox 是一个让人和 AI Agent 在同一个工作现场协作的平台：你可以像给同事分派任务一样指派 Agent，在任务看板中跟踪进度、查看结果，让 Agent 成为团队里的队友。
👉 立即体验 Hifox：https://hifox.com
AI Coding 交流群
如果你也在用 AI 写代码，或者正在研究 Cursor、Claude Code 这些工具，欢迎加入以下交流群。群里平时会聊一些 AI 编程的实际用法、开发工作流，还有各种新工具和新玩法。