Agentic autofix重新运行CodeQL并关闭目标告警，是一条有价值的修复证据，但不能直接替代功能回归和人工审查。一次补丁能让告警消失，也可能改变业务行为；一次扫描没有返回目标告警，还需要确认它完成了、覆盖范围没变，而且对应当前提交。

GitHub在2026年10月15日宣布agentic autofix正式可用。这里聚焦“AI修复PR怎么验收”，把告警变化、提交版本和功能契约放在一起核对，而不是把“代理已经跑过检查”当成合并结论。Read in English。

新工作流交付的是待审查补丁

10月15日公告描述的流程是探索代码、生成修改、重跑CodeQL，必要时迭代，再打开草稿PR供审查。当时公告列出的范围是Enterprise Cloud的Code Security或Advanced Security客户；支持默认分支告警，一次可将最多25个告警交给一个PR处理，消耗AI Credits及Actions分钟。

这使得修复不再只停留在单处代码建议，而能进入一个查找、修改、验证的循环。工程上的增量是交付过程更完整，不是审查职责消失。草稿PR给人的是可检查的候选改动；是否保持原有接口、错误处理与部署行为，仍需要项目自己的标准。

本文以原公告日期说明事件，不把它包装成今天刚发布的消息。下面的证据模型是原创验收设计，不是GitHub内置合并规则，也没有调用真实代码扫描或修改任何仓库。

先对齐告警身份，不只比较总数

设基线扫描的告警集合为B，补丁后的集合为C，目标集合为T。目标已消失可写成T∩C为空，但还应观察新增集合C−B，以及消失集合B−C。这些集合只有在身份与扫描条件可比时才有意义。总数从2降到1，不能单独说明哪一个问题解决了；总数仍为2，也可能同时关闭了旧问题并引入了新问题。

例如基线B={A,B}，目标T={A}。补丁后C={B,C}，总数不变，但A已消失、C新出现。若看板只显示“两个告警”，会掩盖这两项相反变化。这里的字母是虚构的稳定身份，不是现实中仅凭规则ID就足以唯一标识一个告警。

接入实际工具时，需要选择适合该工具的告警身份与匹配规则，并控制仓库、分支、分析类别和规则配置。文件重命名、位置移动或工具规则更新都可能影响匹配；无法确认是同一问题时，应保留待核对状态，而不是把身份变化计作修复。

告警没出现，先排除证据缺失

空结果至少有两种解释：扫描完成且没有发现问题，或者没有得到可用结果。构建、提取、分析和结果上传是不同环节，任何一个缺失都不能自动改写为“目标已关闭”。因此判断目标是否消失之前，先验证结果是否完整、范围是否与基线可比。

这与此前AI Scan覆盖范围分析关注的“没有发现不等于已经检查”相接，但这次对象是修复PR的前后对照。验收既要确认目标问题的变化，也要确认功能没有因修复而退化。

若代理为让扫描通过而缩小查询范围、排除文件或调整构建路径，结果变化可能来自测量条件变化。范围调整可以有合理原因，但应单独审查，并对相关代码重新建立证据，不能把两个不可比集合直接相减后声称安全改善。

把检查结果绑定到当前提交

设PR先在提交H1上通过回归，随后又产生H2修改。H1的通过记录说明H1的状态，不能自动转移到H2。即使H2只修改几行，也应明确哪些原证据仍适用、哪些需要重跑；默认把旧绿勾当作新提交的结论，会留下检查与代码错配。

本文的模型要求扫描和回归都指向当前head，并且扫描范围与测试契约符合预期。真实系统可能通过提交标识、工作树摘要、构建输入和环境版本表达这种绑定。它们不是同一种强度的证据，选择时要与项目风险和可复现要求匹配。

一个写着“完成”的字符串也不会自己证明范围完整。下面程序中的complete和scope是假设经过可信流程填好的输入。它检验证据组合逻辑，不承担证明这些输入真实可信的职责；伪造或误填的记录仍会使任何上层判断失效。

九项离线检查，输出仍然只是准备审查

模型先要求目标确实来自基线，再核对提交、扫描范围、完成状态和回归结果，最后判断目标是否仍在、新问题是否出现。成功结果刻意叫作ready for human review，而不是自动合并或安全认证。

# Fictional evidence contract, not a GitHub merge rule or a CodeQL runner.
from copy import deepcopy

base={'A','B'}
target={'A'}
head='head-b'
scan={'head':head,'scope':'suite-v1','complete':True,'findings':{'B'}}
tests={'head':head,'contract':'regression-v1','complete':True,'passed':True}

def review_state(base,target,head,scan,tests):
    if not target or not target <= base:
        return 'hold: target baseline'
    if scan['head'] != head or tests['head'] != head:
        return 'hold: stale revision'
    if scan['scope'] != 'suite-v1' or not scan['complete']:
        return 'hold: scan evidence'
    if tests['contract'] != 'regression-v1' or not tests['complete'] or not tests['passed']:
        return 'hold: regression evidence'
    if target & scan['findings']:
        return 'hold: target remains'
    if scan['findings'] - base:
        return 'hold: new finding'
    return 'ready for human review'

assert review_state(base,target,head,scan,tests)=='ready for human review'
s=deepcopy(scan);s['head']='head-a'
assert review_state(base,target,head,s,tests)=='hold: stale revision'
s=deepcopy(scan);s['complete']=False;s['findings']=set()
assert review_state(base,target,head,s,tests)=='hold: scan evidence'
s=deepcopy(scan);s['scope']='reduced-suite'
assert review_state(base,target,head,s,tests)=='hold: scan evidence'
s=deepcopy(scan);s['findings']={'A','B'}
assert review_state(base,target,head,s,tests)=='hold: target remains'
s=deepcopy(scan);s['findings']={'B','C'}
assert len(s['findings'])==len(base) and review_state(base,target,head,s,tests)=='hold: new finding'
t=deepcopy(tests);t['passed']=False
assert review_state(base,target,head,scan,t)=='hold: regression evidence'
t=deepcopy(tests);t['complete']=False
assert review_state(base,target,head,scan,t)=='hold: regression evidence'
assert review_state(base,{'Z'},head,scan,tests)=='hold: target baseline'
print('9 evidence-contract checks passed; no scan or merge executed')

九项检查已执行，覆盖旧提交结果、未完成的空扫描、缩小范围、目标仍在、同数量下新增问题、回归失败、回归未完成及错误基线。告警和提交名都是教学数据，没有运行CodeQL、触发代理会话或合并PR。

程序采用“任何新增告警都先停下”的简化规则；现实项目可区分严重程度、已知基线与接受风险，但必须保留理由。测试通过也只说明所运行的测试通过，不能单凭这个状态推断所有功能路径都被覆盖。

功能契约应围绕修复可能改变的行为

人工审查可先问三个具体问题：原调用者还能否按同一接口调用，正常输入的结果是否保持，需要拒绝的输入是否按预期失败。再结合变更内容补上错误类型、资源释放、幂等性或并发行为等项目要求。并不是每个补丁都要跑同一套庞大测试，但选择依据应与修改有关。

特别要注意“消除路径”与“修复路径”的区别。删除原功能、吞掉所有异常或把结果固定为空，都可能改变扫描器观察到的路径，却不自然满足业务契约。这里不提供漏洞利用样例；要点是审查功能是否仍然存在，而不是只看警告是否减少。

多个告警放进同一PR时，还要判断修改之间是否耦合。一个跨模块重构与数个互不相关的小改动，回归成本和回滚方式不同。批量上限是产品能力范围，不是建议每次把任务凑满；先让一个补丁的证据容易解释，再考虑扩大批次。

把修复结论写成可追溯记录

交付记录可包含目标告警身份、基线和当前提交、扫描配置、消失与新增集合、执行过的回归，以及人工尚未确认的行为。它应允许下一位审查者复查结论，而不是只有一段“AI已修复”的自然语言说明。

若证据不足，保留明确缺口比重复触发代理更有用：缺的是能完成的构建、某项功能断言，还是对新增告警的判断？先补这个缺口，避免把一次新的尝试误计为一次新的成功。若一批目标里仅部分拿到了有效复验，分母仍应保留原任务范围；不能只挑通过的目标计算所谓修复率。本文不提供未经测量的修复率、节省时间或安全收益数字。

如果集合对照和证据契约帮你把AI修复PR变成可审查的工程结果，欢迎通过文末支持区自愿支持。可复用的成果是明确知道哪些证据支持了修复、哪些仍需要人判断。

来源与文章日期

October15 announcement

通过Google News条目发现并打开原始公告；来源时间早于原计划时段。示例与图形为原创教学内容，不是产品测评或真实账户操作。计划文章日期为2026年10月20日11:30北京时间；实际排期或公开状态另行核验，补发不表示此前已经公开。