Copilot 开始记住你的修复习惯，安全告警处理变了

安全团队每天要处理 GitHub Advanced Security 的告警，agentic autofix 这类自动修复工具能让其中一部分不再靠人一个个改。以前的自动修复更多是”看到一条告警，理解当前仓库，生成一个补丁”，每次任务相对独立。2026 年 9 月 25 日，GitHub 在 changelog 里确认，agentic autofix 开始接入 Copilot Memory，两个功能都还处于 public preview。这篇 changelog 虽然只有 1 minute read，但信息密度不低：自动修复现在有了跨会话记忆，修完之后会把它学到的东西留给下一次告警。

这次到底改了什么

官方写的是面向 customers who’ve enabled it，也就是说这次变化只对已经启用 Copilot Memory 的客户生效，不是默认全量打开。具体行为有两步：当 agentic autofix 处理安全告警时，它会先 reviews existing memories，寻找能帮助解决当前告警的上下文；当它创建修复后，又会 stores the fix pattern as a memory，把这次的修复模式保存下来供未来使用。官方还提到，这些 memories 不只用于 agentic autofix，还会让其他 GitHub Copilot 功能，比如 Copilot code review 和 Copilot cloud agent，了解你们仓库特有的安全开发模式（来源）。

Copilot Memory 不是新东西

这里有一个容易忽略的点：Copilot Memory 不是这次 changelog 才第一次出现。它在此前已经是 Copilot 产品线里用来提供个性化上下文的机制，这次的意义是让 agentic autofix 也变成一个明确的读写入口。换句话说，过去你可能只在某些 Copilot 体验里感到它记得你的偏好，现在安全修复流程也开始共享同一套记忆。官方文档入口在 GitHub Docs 的 Copilot Memory 页面，里面会讲清管理边界，不过本次 changelog 没有展开所有细节。

单次处理的流程变了什么

要理解”读旧记忆 + 写新记忆”到底改变了什么，可以看下面这个简化流程。它不是 GitHub 官方 API，只是我按照 changelog 的描述转写成的一次处理过程：

# 示意：接 Memory 后的 agentic autofix 单次处理
for alert in new_security_alerts:
    repo_context = collect_repo_context(alert)

    # 生成修复前，先读取仓库已有的 Copilot Memory
    memories = load_copilot_memories(repo=repo, alert=alert)

    fix = agentic_autofix.generate(
        repo_context=repo_context,
        memories=memories
    )

    apply_fix(fix)

    # 修复完成后，把 fix pattern 写回 memory
    fix_pattern = extract_fix_pattern(fix)
    store_as_copilot_memory(pattern=fix_pattern)

关键变化就在这两步：生成前多了一次记忆读取，生成后多了一次记忆写入。以前的 agentic autofix 更像无状态的”告警到补丁”转换器；接入 Memory 之后，它变成了一个跨会话更新的仓库安全偏好系统。

举一个具体例子：如果同一个仓库反复出现 SQL 注入告警，第一次修复采用参数化查询加输入校验的组合，这个模式被写进 memory 后，后续同类告警就更容易生成同样风格的修复，而不必每次从零推理。如果团队本身有统一的修复规范，这能减少风格漂移；但如果某次错误修复被记进去，后续告警也可能被带偏。

影响不只在 autofix 本身

这个读写循环还会影响 agentic autofix 之外的功能。官方明确说这些 memories 可以 teach other GitHub Copilot features 关于仓库特有的安全开发模式，点名的有 Copilot code review 和 Copilot cloud agent。也就是说，autofix 生成的一个修复模式，之后可能在 code review 里被当成参考基线。对工程团队来说，这比代码补全里的 Memory 更敏感，因为它直接影响安全修复的方向和评审建议，而不是补充一个函数名或 import。

一个潜在的循环是：autofix 生成一种修复并写进 memory，code review 参考同一份 memory 后更认可这种修复，后续 autofix 又更倾向生成它。这种自我强化在高度同质的修复场景里是好事，但在需要人工判断边界的时候，可能让某些模式过快固化。

反方：什么时候不该打开

从适用边界看，并不是所有团队都该马上打开。我的判断是：仓库数量多、安全告警反复出现、团队已经有明确修复规范并希望 Copilot 持续遵循的场景，会比较受益；如果你们的安全策略要求每次修复严格人工评审，或者正在处理高度敏感代码，不希望模型把修复模式自动沉淀到跨会话记忆里，那么 public preview 阶段应该先小范围开启。

开启前建议先确认组织级配置里哪些仓库共享这些记忆、有没有审计日志能追踪记忆的生成与使用。这是工程上的谨慎做法，不是官方要求。官方文档页已经存在，但具体管理入口和关闭方式需要结合你们自己的 GitHub Advanced Security（高级安全）权限模型去核对，尤其是 public preview 功能，行为随后可能还会调整。

风险也值得重复一遍：记忆是一把双刃剑。它能让 Copilot 更快理解你们的仓库，但也会把早期测试阶段不理想的修复固化成”偏好”。而且这些记忆不会因为模型版本更新而自动消失，得靠团队主动清理或关闭。对于安全类工作，错误的记忆可能比没有记忆更麻烦，因为它会把问题藏进”仓库向来如此”的外壳里。如果团队决定试验，我建议至少先在一个或两个告警类型上观察几轮，看看修复是否真的更贴合内部规范，还是只是更快地重复同一个模式。

这件事意味着什么

这次更新本身的 changelog 很短，但它标志着 Copilot 在应用安全领域从”生成一个补丁”走向”维护一套仓库安全偏好”。对正在使用 GitHub Advanced Security 和 Copilot 的团队来说，如果之前觉得 agentic autofix 的修复不够贴合内部规范，Copilot Memory 是个值得试的叠加项；如果对自动记忆比较谨慎，至少应该先搞清楚怎么关闭和清理，再决定是否打开。等到 public preview 结束、功能变成 GA，记忆行为会直接影响更多仓库，那时候再了解就有点被动了。

常见问题

Q：Copilot Memory 默认是开还是关？
公开 changelog 里只说”面向已启用 Copilot Memory 的客户”，并未点明组织级默认状态。建议在打开 agentic autofix 之前，先在仓库或组织设置里确认 Copilot Memory 的开关与共享范围。

Q：怎么审计一个 memory 是怎么生成的？
GitHub Docs 的 Copilot Memory 页面提到了相关的管理边界与关闭方式。本次 changelog 没展开审计入口细节，需要结合你们自己组织的 GitHub Enterprise Cloud 权限模型去查；如果走 audit log，需要确认是否能追踪到 memory 的写入与读取记录。

Q：如果是新仓库、还没有 memory，会发生什么？
按 changelog 描述，”读旧记忆”这一步在没有 memory 时不会报错，只是不会提供历史上下文；”写新记忆”这一步仍然执行，第一次的修复模式会成为这个仓库 memory 的起点。所以新仓库实际上是从第一次告警修复开始建立偏好——这意味着早期修复质量会决定后续方向。

Q：能用一句话判断要不要打开吗？
仓库多、告警反复、有明确修复规范 → 打开并观察；策略要求严格人工评审或处理高度敏感代码 → public preview 阶段先小范围开，或暂不开。

Q：记忆会跨组织共享吗？
按 changelog 的描述，memory 的可见性与 Copilot Memory 自身的范围绑定；public preview 期间具体行为可能调整，开之前以最新官方文档为准。

参考来源

• GitHub Changelog: Agentic autofix now uses Copilot Memory — 本篇主要依据
• GitHub Docs: GitHub Copilot Memory — 官方文档中关于 Copilot Memory 的概念与边界
• GitHub Changelog: Copilot 标签页 — 同期 Copilot 相关 changelog 索引