GitHub 的 agent 式自动修漏洞转正了：免费“一键修”被取代，开始按 AI Credits 收费

先划一条界：本站 cycle52 发过《Chainguard Harness：AI 漏洞狩猎，首战挖出 vLLM 真漏洞》（chainguard-harness-ai-vulnerability-hunting-october-2026），讲的是第三方 AI 产品"发现"漏洞——找到真实存在的漏洞。本篇讲的是另一半：GitHub 自家平台把"修复"漏洞做成标准流程，而且开始收费了。一个是"发现"侧，一个是"修复"侧，两篇连起来，agent 才算走完了"指问题 → 交 PR"的闭环。

2026 年 10 月 15 日，GitHub 在官方 changelog 发布条目《Agentic autofix for code scanning alerts general availability》（页内 Additional Details 显示 Published: 2026-10-15T06:49:20-07:00，北京时间 10 月 15 日晚上）。一句话：GitHub 的 agent 式自动修漏洞转正了——安全告警可以直接指派给 Copilot，它会跨代码库探索、生成修复、重跑 CodeQL 验证，最后开一个 draft PR；同时，免费的"一键修"（Generate Fix）按钮被取代，开始按 AI Credits 收费。

这条新闻的真正分量不在"修漏洞"本身——Copilot 帮修代码已经不是新概念了。分量在两件事：第一，agent 修漏洞从"实验功能"变成了"标准流程"（GA）；第二，安全 agent 正式成为 SKU 级收费项，企业账单上会出现新的一行。"AI 替人审代码"这件事，第一次从演示走进了计费系统。

流程：从"指派告警"到"开 draft PR"的完整闭环

changelog 描述的流程有六步，是一个完整的 agent 工作流，值得一步步拆开：

• 1. 指派告警给 Copilot。在安全告警列表里，把告警 assign 给 Copilot（以前是点免费的 "Generate Fix" 按钮，现在这个按钮被 "Assign to Copilot" 取代）。
• 2. 跨代码库探索相关文件。Copilot 不是只看告警所在的那几行，而是去代码库里找相关文件、理解调用链——"探索"这一步是 agent 式和模板式的根本区别。
• 3. 生成修复。根据探索结果生成代码修复。
• 4. 重跑 CodeQL 验证告警关闭。这是整个流程里最关键的一步：修完之后，用 CodeQL 重新扫描，确认告警真的关掉了才继续。验证不是"看起来修好了"，是"扫描器确认关掉了"。
• 5. 迭代。如果告警没关，继续改、继续验证，直到通过。
• 6. 开 draft PR。PR 里带三样东西：修复摘要、"为什么这个修法能关掉告警"的解释、验证步骤。PR 就绪后，还可以在评论里或 Agents tab 继续追改。

第 4 步和第 6 步是这个设计的灵魂。第 4 步（重跑验证）把"修"和"验"绑在了一起：agent 不能只管生成不管对错，交付标准是"扫描器点头"。第 6 步（PR 带解释和验证步骤）把 human-in-the-loop 留在了正确的位置：人不需要盯着 agent 的每一步，人只需要在"审 PR"这个环节做判断——而 PR 里已经把"为什么这样修"和"怎么验证的"写好了，reviewer 审的是"修得对不对"，不是"agent 有没有偷懒"。

多说一步"探索"：agent 式和模板式的根本区别

第 2 步"跨代码库探索相关文件"值得单独展开，因为它是"agentic"这个词的含金量所在。传统的自动修复（比如 IDE 的 quick fix）是模板式的：告警说"这里有个 SQL 注入"，模板就往那个位置套一个参数化查询的写法。它不管这个函数的调用链、不管参数从哪来、不管修完会不会 break 别的东西。

agent 式的修法是反过来的：先探索，再动手。Copilot 会去代码库里找这个漏洞相关文件的调用关系，理解数据从哪进、从哪出，修完之后还要重跑扫描确认。这意味着修复的质量下限变了：模板式修复的质量下限是"模板写得对不对"，agent 式修复的质量下限是"探索得全不全"。探索越全，修得越准——这也是为什么 changelog 强调"跨代码库探索"，而不是"在告警位置生成补丁"。

对 vibe 开发者：以后你让 agent 改代码，第一句应该问的不是"怎么改"，而是"你先去把相关的文件都找出来"。探索前置，是 agent 改代码不出大乱子的第一道保险。GitHub 的官方流程把探索写成第 2 步（在生成修复之前），这个顺序就是答案。

PR 里的三样东西：给 reviewer 的"审题材料"

第 6 步开 draft PR 时带的"修复摘要、关闭原因、验证步骤"，本质上是一份给 reviewer 的"审题材料"。以前的 agent PR 经常被吐槽"不知道它干了什么"——diff 一大片，没有解释，reviewer 只能逐行猜。现在 GitHub 规定 PR 必须自带三样东西：

• 修复摘要：改了什么，一句话版本。
• 关闭原因：为什么这个修法能让告警关闭——这是"论证"，不是"描述"。reviewer 看的是"它的推理对不对"。
• 验证步骤：怎么证明修好了——重跑了哪个扫描、结果是什么。reviewer 可以自己复跑一遍。

这三样东西把 review 的认知负担从"读 diff 猜意图"降到了"检查论证和验证"。agent 时代的 PR 规范，正在从"代码写清楚"进化到"论证写清楚"。vibe 开发者以后让 agent 开 PR，也可以要求它按这个三件套写描述——reviewer（可能是你自己，也可能是同事）会轻松得多。

对 vibe 开发者：这是"agent 工作流长什么样"的标杆设计。探索 → 修 → 验证 → 开 PR → 可追评，五段式。以后你让 agent 干任何"改代码"的活，都可以套这个模板：先让它探索（别急着写），再让它修，然后必须有一个独立的验证步骤（测试、扫描、lint 都行），最后产出保持"人能审"的粒度。

真实产品截图：Copilot Autofix 针对 CodeQL 路径遍历告警给出建议修复

计费切换：免费"一键修"被取代，安全 agent 成为 SKU

这次 GA 最有商业信号的变化是计费：

• 免费的 "Generate Fix" 按钮被 "Assign to Copilot" 取代。以前点一下免费修，现在指派给 Copilot 开始计费。这是一个时代的结束：AI 修代码的"免费尝鲜期"过去了。
• 消耗两样东西：Code Security 预算里的 AI Credits，加上 GitHub Actions 分钟。注意是"两样"：模型推理烧 AI Credits，跑验证（CodeQL 重跑）烧 Actions 分钟——验证也是有成本的。
• 企业账单 "AI usage" 区新增 "Advanced Security" 产品行。安全 agent 第一次在账单上有了自己的名字，不再是藏在某个大类里的"AI 用量"。
• 可设 SKU 级预算。企业可以给 Advanced Security 单独设预算上限，超了就停——账单治理做到 SKU 粒度。

把这四条连起来读：GitHub 在把"安全 agent"从一个功能，变成一个可定价、可预算、可审计的 SKU。这是 agent 商业化的标准动作——先免费培养习惯（Generate Fix 时代），再转正收费（Assign to Copilot 时代），最后给企业全套的预算管控（SKU 级预算）。2026 年的 agent 产品，收费模式的成熟速度正在追上能力的成熟速度。

双成本结构：AI Credits + Actions 分钟

计费细节里最值得琢磨的是"消耗两样东西"：AI Credits（模型推理）和 Actions 分钟（跑验证）。这两样对应流程里的两个环节：第 3 步生成修复烧的是 Credits，第 4 步重跑 CodeQL 烧的是 Actions 分钟。

这个双成本结构揭示了一个真相：agent 工作流的成本，不只是"模型推理"，还有"验证"。而且验证的成本是刚性的——你不能为了省钱跳过第 4 步，跳过了，整个"修→验"闭环就断了。所以以后给 agent 工作流做预算，要按"推理 + 验证"两项分别估。GitHub 把这两项拆开计费，等于在教育市场：验证不是免费的赠品，它是工作流的一等公民。

对 vibe 开发者：你自己的 agent 工作流也一样——跑测试、跑 lint、跑扫描，这些"验证"步骤烧的是 CI 分钟/时间，不是 token。做成本核算时别只算 token，验证的开销经常被低估。GitHub 的账单设计，就是一份现成的"agent 工作流成本结构"教科书。

和本站之前发过的 Simon Willison 硬预算上限论对照看：Willison 讲的是"个人/团队怎么给 agent 花钱设限"，GitHub 这次讲的是"平台怎么把花钱做成标准 SKU"。一个是用户侧的自律，一个是平台侧的供给——两边在 2026 年 10 月同时成熟，不是巧合，是 agent 经济进入"明码标价"阶段的标志。

真实产品截图：Copilot Autofix 针对 CodeQL 路径遍历告警给出建议修复

批量作业：一次 25 个告警，合成一个 PR

GA 还带来了一个"把 agent 当批量修理工用"的官方姿势：

• 在安全告警列表或安全 campaign 里，一次最多选 25 个告警，指派给 Copilot，合成一个 draft PR。
• 支持 REST API 脚本化指派：assignees=["copilot-swe-agent[bot]"]，可以写脚本批量派活。

"25 个告警 → 1 个 PR"这个设计很讲究。它不是"25 个告警开 25 个 PR"（reviewer 会疯），也不是"无上限批量"（agent 会飘）。25 是一个"人还能审"的批量上限：一个 PR 里修 25 个同类问题，reviewer 可以按 pattern 审——"这 25 个都是同一种 SQL 注入，修法一致"。agent 的批量能力，和人的 review 能力，在这里找到了平衡点。

REST API 的脚本化指派则意味着：安全团队可以把"修漏洞"编进 pipeline——每周扫一次，每周自动派 25 个给 Copilot，周一早上 review PR。漏洞修复从"人肉排期"变成了"定时任务"。这是 agent 落进企业安全流之后，工作流本身被重塑的样子。

个人开发者能抄的：土制"修→验"闭环

agentic autofix 需要 Enterprise Cloud + 管理员开 policy，个人项目用不上。但它的"五段式"（探索→修→验证→开 PR→可追评）今天就能抄，一个土制版本只需要三样免费东西：

• 1. 让 agent 先探索再动手。用你手头的任何 agent（Copilot、Claude Code 都行），改代码前先让它"找出所有相关文件并说明调用链"。这是第 2 步的平替。
• 2. 验证步骤独立且自动。修完之后，跑一遍你项目的测试/lint/扫描——这是第 4 步的平替。关键是"独立"：验证不能是 agent 自己说"我觉得修好了"，必须是一个它改不了的外部检查。
• 3. PR 描述按三件套写。要求 agent 在 PR 描述里写"改了什么、为什么这样修、怎么验证的"——这是第 6 步的平替。以后你自己回看，也知道当初为什么这样修。

GitHub 的 GA 版本是"平台级"的实现，你的土制版本是"工作流级"的实现，骨架是同一副。等你的项目长大到需要 Enterprise 的那一天，迁移过去是无缝的——因为你早就按这个形状在工作了。

限制：不是谁都能用，也不是什么都能修

GA 不等于"无门槛"，changelog 和交叉解读里列了一串限制：

• 仅 default branch 的告警可指派。PR 上报的、其他分支的告警不行——agent 只修主干，保证修的是"线上的代码"。
• 需要企业管理员先开 "Agentic autofix" policy，并定义 Copilot 的计费方式。个人项目用不上，这是 Enterprise Cloud 的菜。管理员不开 policy，按钮都不会出现。
• 验证有边界（dev.to 独立技术解读转述 changelog/文档细则）：重跑验证的是默认 CodeQL 查询集；自定义查询、security-extended、第三方工具告警的修复，无法被自动确认。翻译一下："绿 PR 只证明告警关了，不证明修得对"——对于非标准查询，验证闭环是断的，reviewer 要更仔细。

最后一条最值得记住。它给所有"agent 自动修"类产品划了一条诚实线：自动验证的效力，取决于验证器本身的覆盖范围。CodeQL 默认查询集能确认的，agent 敢说"修好了"；超出这个范围的，agent 只能说"我改了，你自己看"。vibe 开发者用任何自动修复工具，都应该先问一句：它的"验"是验什么？验的范围，就是它敢打包票的范围。

判断：agent 从"指问题"进化到"交 PR"

以下进入判断区，事实和观点分开标。

判断一："发现 vs 修复"的闭环走通了。本站 cycle52 的 Chainguard Harness 是"发现"侧：第三方 AI 产品首战挖出 vLLM 真漏洞；本篇是"修复"侧：GitHub 平台把修复做成标准流程。两篇拼起来，agent 在安全流里的完整链条是：找漏洞（Harness 这样的 hunter）→ 修漏洞（agentic autofix 这样的 fixer）→ 验证（CodeQL 重跑）→ 人审（PR）。2026 年 10 月之前，这个链条是散的；GA 之后，GitHub 平台内是通的。安全工作的"最后一公里"（修），第一次有了官方解法。

判断二：安全 agent 成为 SKU，意味着"AI 安全支出"正式成为企业预算科目。账单上出现 "Advanced Security" 产品行这件事，比功能本身更重要。企业预算的逻辑是：没有科目就没有预算，没有预算就没有采购。有了 SKU，企业安全团队明年做预算时，可以名正言顺地列一行"AI 漏洞修复"。GitHub 这次 GA，表面是发功能，实际是在帮整个品类"立科目"。所有做 agent 安全产品的公司，都应该给 GitHub 敬一杯——它把路修宽了。

多说一句"立科目"的连锁反应：科目一旦立起来，接下来就是"比价"。今年是 GitHub 的 Advanced Security 明码标价，明年就会有客户问"你们家和竞品的单漏洞修复成本差多少"。agent 安全产品从"讲故事"进入"拼单价"的阶段，计费模型（按漏洞？按 PR？按 Credits？）会成为竞争维度。GitHub 先选了"AI Credits + Actions 分钟"的双轨制，这个定价锚，大概率会被全行业抄——就像云厂商的"按量计费"当年被全行业抄一样。

判断三：免费时代的结束是 agent 成熟的标志，不是坏消息。"Generate Fix 免费按钮被取代"听起来像涨价，实际是产品从"实验"到"正经"的成人礼。免费的东西，企业不敢依赖（随时可能砍）；收费的东西，企业才敢写进流程（有 SLA、有预算、有 owner）。按 AI Credits + Actions 分钟计费，把成本结构摊开了：推理多少钱、验证多少钱，一目了然。这比"免费但不知道哪天没了"健康得多。对 vibe 开发者：别再等免费的 agent 安全工具了，2026 年 10 月之后，这个品类的免费午餐正式结束。

判断四：10 月 15 日是 GitHub 的"agent 双发日"，读法要连起来。早上 06:49 agentic autofix GA（写入面：修漏洞、开 PR、收费、企业门槛）；晚上 19:16 Copilot 多仓库聊天（只读面：Slack/Teams 里跨仓库问答）。本站同批两篇（本篇 + github-copilot-multi-repo-slack-teams-chats-october-2026）建议连读：GitHub 在一天之内，把 Copilot 的"嘴"（问）和"手"（修）各推了一步，而且商业策略是镜像的——嘴铺得宽（协作工具、跨仓库），手收得紧（单仓库单 PR、按 Credits 收费）。读放大、写收敛，收费落在"手"上。

还有什么没说

changelog 没提的：25 个告警合成一个 PR，实际的 AI Credits 消耗是多少（企业最关心的数字没给）；修复的"质量"有没有统计口径（多少 PR 一次合入、多少被打回——GitHub 手里肯定有数据，没公布）；自定义 CodeQL 查询的验证什么时候补（dev.to 指出的边界，官方路线图没说）。

还有一个更大的问号：agentic autofix 目前只认"CodeQL 默认查询集"，那 SAST 工具百花齐放的企业（比如同时用 Semgrep、Snyk 的）怎么办？GitHub 的答案是"先把自家闭环跑通"，但企业安全的现实是"工具异构"。第三方告警的修复验证如果长期补不上，agentic autofix 的天花板就是"GitHub Advanced Security 全家桶用户"。这个边界，决定了它是"平台标配"还是"生态选项"。

最后留一个给 vibe 开发者的思考题：你的项目里，有没有一条"修→验"的闭环？大多数个人项目的现状是：agent 改完代码，人看一眼 diff，觉得顺眼就合了——"验证"这一步是缺失的。GitHub 这次 GA 给出的最大启示，不是"企业级功能"，而是"工作流形状"：任何 agent 的改动，都应该配一个它改不了的外部验证。测试、lint、扫描仪，三选一，总有一个能用。从今天开始，给你的 agent 工作流加一条"验"，成本几乎为零，收益是"睡得着觉"。

相关阅读：Chainguard Harness：AI 漏洞狩猎，首战挖出 vLLM 真漏洞（发现侧：找到漏洞）；本站同批 GitHub Copilot 进 Slack/Teams 跨仓库聊天（10-15 同日双发的另一半：只读面）；Linus 谈 AI 与内核 bug（AI 审代码主题相邻）。

一句话总结：GitHub 的 agent 式自动修漏洞 GA，标志着"AI 替人修代码"从演示走进计费——免费一键修被取代，安全 agent 成为账单上的 SKU；流程上"探索→修→验证→开 PR"的五段式，是所有 agent 改代码工作流的标杆；但记住 dev.to 划的那条线：绿 PR 只证明告警关了，不证明修得对。