AI修过一次漏洞还会再犯吗？关键不只是“记住”

GitHub 让 Agentic Autofix 开始读取 Copilot Memory，并把成功修复模式留给后续安全告警。它能减少同类漏洞反复解释，却也把风险从“这次补丁对不对”扩大到“被复用的经验是否仍然正确”。对开发团队而言，真正要建设的是可验证的安全规则库，而不是越长越好的记忆。

发生了什么

GitHub 9 月 25 日公告称，启用 Copilot Memory 的客户在使用 Agentic Autofix 时，系统会读取已有记忆辅助解决安全告警；创建修复后，还会保存修复模式，供以后处理相似告警，并可被代码审查、云端 Agent 等功能使用。Agentic Autofix 与 Copilot Memory 目前都处于公开预览。

官方文档把记忆分为两类：仓库级事实包括编码约定、架构决策、构建命令和项目规则；用户级偏好只服务个人交互。安全修复主要依赖仓库级事实。跨功能复用是这次变化的价值，也是影响半径变大的原因。

记忆为什么能提高修复质量

漏洞修复很少只有“把危险函数换掉”这么简单。一个仓库可能要求所有数据库访问经过特定封装、两个配置文件必须同步修改，或某个输入在上游已做规范化。通用模型不知道这些局部事实，容易生成能通过单测、却破坏项目边界的补丁。

记忆把局部约束带进下一次推理，相当于给新来的安全工程师一份经过整理的值班手册。我的核心判断是：记忆的单位应是“规则＋证据＋失效条件”，不能只保存一段自然语言结论。代码、依赖和威胁模型都会变化；没有来源与有效期的旧经验，可能把已修复的模式重新引入。

最小实践：让记忆先过门禁

下面的纯 Python 示例只演示治理逻辑：规则必须带来源提交、测试名和到期日；过期或未被当前测试集覆盖的记忆不会进入提示上下文。

from datetime import date

memories = [
    {"rule": "SQL必须参数化", "source": "a1b2c3d",
     "test": "test_sql_injection", "expires": "2026-12-31"},
    {"rule": "JWT允许HS256", "source": "old777",
     "test": "test_jwt_policy", "expires": "2026-06-30"},
]

passing_tests = {"test_sql_injection", "test_path_traversal"}

def approved_memory(item, today):
    expiry = date.fromisoformat(item["expires"])
    has_evidence = len(item["source"]) >= 7
    test_is_green = item["test"] in passing_tests
    return has_evidence and test_is_green and expiry >= today

usable = [m for m in memories
          if approved_memory(m, date(2026, 9, 27))]

for item in usable:
    print(f"USE: {item['rule']} ({item['source']})")

assert [m["rule"] for m in usable] == ["SQL必须参数化"]

无需第三方依赖，保存后运行 python memory_gate.py。本次在 Python 3.9 实际运行，只有“SQL 必须参数化”通过，断言成功。真实系统还应验证提交签名、规则适用目录、依赖版本和测试结果来源。