ABACI 内核补丁定向测试与缺陷检测智能体
ABACI 内核补丁定向测试与缺陷检测智能体
摘要
AI 辅助编程普及之后，内核这类高风险基础软件的变更速度明显提升，而留给质量保障的时间窗口一直在收窄。传统内核测试为广度探索而设计，一旦测试目标被限定为某一次具体变更，效率问题立刻暴露：绝大部分算力落在与本次变更无关的代码路径上。
本白皮书介绍 ABACI，一套面向内核补丁的定向测试与缺陷检测智能体。它把每一次代码变更当作测试目标，结合大模型的语义理解与运行时反馈，自动构建能够真实抵达变更代码的测试用例，并借助历史缺陷经验对变更做缺陷筛查。该能力已经完成产品化，以服务形式运行在内核代码的持续集成流水线上，变更提交即触发定向测试。
在覆盖多子系统的百量级真实合入变更评测集上，ABACI 的目标函数到达率相较业界主流内核模糊测试工具提升约一个数量级。线上运行至今，它已发现上百个可复现真实缺陷，并向社区上游贡献了多个问题与修复补丁。
一、ABACI 解决什么问题
代码写得越来越快，留给测试的时间越来越少。
AI 编程助手与研发智能体的成熟正在重塑基础软件的研发节奏。内核仓库的合入请求成倍增长，单位时间内进入评审与验证环节的变更规模持续攀升，而质量保障侧的供给却停留在原地。内核变更的评审高度依赖资深工程师的领域积累，这部分产能很难随提交量一同扩容；单次变更可分配的测试时长与算力又受到交付节奏的严格限制。一旦缺陷逃逸到生产环境，可能直接表现为宕机或权限提升类漏洞，修复与召回的代价极高。
真正的症结在测试算力的投向。现有内核动态测试以覆盖率引导的模糊测试为主流范式，通过大规模随机变异不断探索新分支，把整体覆盖面推高。用于发现未知问题时，这一范式的有效性已被反复验证。而当测试目标被明确限定为"本次变更涉及的代码"，效率问题立刻显现。
我们的实测统计给出了一个直观的数字：主流工具累计生成的测试用例里，与指定目标相关的仅占 5% 左右。剩下的算力构成了所谓的用例执行幻象，测试系统在高强度运转，覆盖率曲线也在上升，而与本次变更真正相关的代码路径始终停留在执行范围之外。合入前的报告标记为通过，"通过"这个结论却缺少支撑，缺陷要等到灰度发布甚至生产环境才暴露出来。
结构性矛盾就摆在这里：变更供给端在加速，质量验证端正在成为瓶颈。ABACI 换了一个优化目标，把"目标可达性"放在第一位，让测试算力落到本次变更的代码上。
二、核心挑战
从广度探索转向定向抵达，需要跨越三个层面的挑战。
挑战一：如何造得出语义有效的测试用例
内核测试用例是一段受严格约束的系统调用序列。要让内核真正执行到某段代码，用例必须同时满足调用之间的语义关系与执行前的状态条件，任何一层缺失，用例在进入目标逻辑之前就已经失效。
以历史上的高危内核漏洞为例，触发它需要先建立特定的命名空间环境，再以特定方式完成一次文件系统挂载，其后的一组文件操作还必须严格按序发生。系统调用与参数的组合空间近乎无穷，有效约束又深藏在层层条件分支之中。传统静态分析难以完整刻画这类跨层约束；纯随机变异在集群上跑数日，也很难让全部前置状态同时成立。
大模型的语义理解能力为这个问题带来了转机，它读得懂代码意图，也能串联跨函数的约束关系。但把完整用例的生成整体交给大模型同样走不通：内核用例对精确性的要求极高，而模型幻觉恰恰在细节层面集中爆发。
挑战二：如何引导测试用例收敛到目标位置
调用序列在语义层面正确之后，问题仍然存在。大量数值型参数难以仅凭语义推断确定：一处分发逻辑要求传入值恰好等于某个特定枚举，一处条件守卫要求某个内核对象字段在先前操作中已经建立。这类取值只能在反复执行与观察反馈中逐步逼近。
定向测试因此需要一个运行时的指南针，一个能够持续度量当前执行位置与目标之间距离的指标。传统覆盖率反馈在定向场景下天然错位，它衡量的是代码区域的新鲜程度，而"离目标还有多远"落在它的量程之外。方向性信号一旦缺席，测试过程就退化成巨大空间里的随机游走。
挑战三：如何高效识别真实缺陷
抵达目标只是必要条件，测试的价值最终落在发现真实问题上。
内核缺陷有一个重要的统计特性：绝大多数新缺陷是历史缺陷的变体，其机制与触发模式已经隐含在历史问题报告与修复提交之中。当前基础模型的代码理解能力足以读懂变更逻辑，瓶颈在于缺少可直接复用的具体历史经验作为引导。模型面对每一次变更都从零开始通读代码，推理预算大量花在理解代码在做什么，留给定位问题的部分反而有限。
缺陷判定本身对推理要求极高。模型不仅要指出可疑位置，还要给出可触发的状态前提与具体触发思路；而缺陷往往藏在跨文件的不变式与资源生命周期管理里。
三、技术理念与能力架构
充分发挥大模型语义理解的长板，把幻觉风险约束在可验证的范围内。
ABACI 设计上的第一原则是职责分离。语义理解与全局推理交给大模型，对精确性与确定性有要求的部分交给程序化机制和运行时反馈，两者通过统一的目标定义与反馈通路协同工作。由此形成的能力分为三层，下面依次展开。
3.1 语义驱动的定向用例构建
针对挑战一，ABACI 以变更位置为起点做目标导向的语义推理，识别出真正可能通向目标代码的少数路径及其关键约束，把搜索空间从近乎无穷压缩到可枚举的规模。
参数层面采用关键约束优先的策略：只有被目标语义真正钉住的少数参数由模型决策，其余交给确定性机制与运行时探索。模型的幻觉暴露面因此从全部参数收缩到少数关键取值，语义能力得以保留，不确定性也留在可验证的范围内。
能力表现：面向单次代码变更自动产出可直接执行的目标相关用例，全过程无需人工编写测试代码或补充领域提示。
3.2 目标导向的运行时收敛引导
针对挑战二，测试执行链路中引入了面向目标的方向性反馈机制，取代原本的纯覆盖率反馈。它在执行过程中持续评估当前状态与目标位置的接近程度，并据此调配测试资源：
沿有效方向加大投入。呈现靠近趋势的用例获得优先深挖。
及时收敛无效方向。长期原地踏步的用例被降级或淘汰。
方向性信号优先。只有当方向性判断难以区分优劣时，传统覆盖率才作为辅助判据介入。
用例的演进同时遵循结构保持原则：语义推理已经确认的序列骨架与关键约束在迭代中保持稳定，演进只发生在待探索的自由部分。已经建立的语义有效性由此得到保护，整个过程呈现出稳定的收敛特征。
能力表现：在受限的时长与算力预算内，把测试算力集中投放到目标相关路径上，从"可能覆盖"走到"确定抵达"。
3.3 经验驱动的缺陷模式筛查
针对挑战三，ABACI 构建了一套历史缺陷经验的蒸馏与复用体系：
经验蒸馏。模型读取历史缺陷的修复提交与问题报告，抽取出缺陷机制与触发模式，并记录对应的修复方式。
同类归纳。同机制的缺陷被聚类抽象为可复用的模式，经专家抽查确认后入库，形成全局与子系统两级的缺陷模式知识库。
迭代回灌。库中模式作为先验注入定向测试流水线，流水线的新发现经归纳后回灌入库，知识资产随使用持续生长。
这套设计把模型的推理预算从理解代码重新分配到定位问题，缺陷筛查也从通用的代码审查变成带有方向感的模式匹配与验证。
能力表现：在变更审查阶段给出带有触发条件与状态前提的可疑点判断，再交由定向测试链路做运行时验证，静态判断的误报成本因此显著下降。
四、工程实现与落地成效
从工具到服务：作为质量门禁集成进持续集成流水线。
ABACI 已经完成完整的服务化封装，作为内核质量保障平台的能力模块运行在生产 CI 流水线中。代码变更请求提交后自动触发，全程无需人工介入或额外配置。
4.1 服务链路
服务链路划分为四个自动化阶段：
| 阶段 | 职责 | 输出 |
|---|---|---|
| 一、目标识别 | 解析变更内容，确定本次测试的目标代码范围与优先级 | 结构化测试目标 |
| 二、目标分析与环境准备 | 完成面向目标的语义分析与测试环境构建 | 定向测试作业配置 |
| 三、定向测试执行 | 在隔离虚拟化环境中并行执行定向测试与缺陷筛查 | 执行轨迹、崩溃与可疑点 |
| 四、结果归集与报告 | 汇总可达性数据、缺陷线索与复现材料 | 结构化测试报告 |
4.2 工程特性与交付形态
全自动。以代码变更请求为唯一输入，用例编写与目标标注都由系统完成。
时间可控。端到端在小时级预算内收敛，可以放在合入前的门禁位置，交付节奏照常推进。
结果可复现。报告中的每个缺陷都附带复现材料，直接支撑后续的定责与修复。
弹性并行。基于虚拟化隔离的多实例并行执行，测试吞吐随算力资源线性扩展。
对使用方而言，ABACI 呈现为一项标准的质量门禁能力。结构化报告中给出目标可达性数据与缺陷线索，并直接对接研发协同流程，支撑修复跟踪与合入决策。
4.3 生产环境运行成果
ABACI 在生产 CI 流水线中持续运行，对进入仓库的内核变更做自动化定向测试与缺陷筛查，目前的成果包括：
发现上百个可复现真实缺陷。每个缺陷都附带完整的复现材料，可以直接进入修复流程。
形成社区上游贡献。其中一批问题被确认属于社区上游代码缺陷，团队已向上游提交多个修复补丁，并有补丁获得确认合入。
识别版本间的修复缺失风险。一批因上游修复未及时同步而遗留的风险点被找出，为版本维护策略提供了数据支撑。
这些数字支撑了一个关键判断：测试算力一旦被正确投放到变更代码上，缺陷发现效率会出现结构性提升。相当一部分缺陷长期潜伏的原因很朴素，它们所在的代码始终处于执行范围之外。
五、实践
从一次变更的处理过程，看这套能力如何在流水线里运转。
5.1 一次变更的完整处理过程
下面是一次真实合入请求在流水线里的完整处理过程。
变更提交后，目标识别阶段解析出本次改动落在某个网络子系统的状态管理路径上，改动本身只有一行，调整了一处状态判断条件。这处改动被标记为本轮的测试目标。
分析阶段随即从这个位置往上推理。要让内核执行到这里，需要先经由配置接口建立一个状态对象，再触发它的删除路径，两步操作之间存在依赖。同类目标若从入口侧正向枚举，候选路径会达到成百上千条；反向推理最终输出的有效路径只有个位数条，其中需要模型决策的关键约束仅一项，它要求删除请求携带的标识与此前建立的对象相匹配。
执行阶段的首轮用例走完了建立流程，删除请求却因为标识对不上而提前返回。方向性反馈显示位置持平，用例被保留下来继续演进，序列骨架保持稳定，自由取值逐轮变化。若干轮之后标识命中，删除路径走通，目标位置得到真实执行。同一个变更交给通用模糊测试工具，跑满同等时长之后，目标位置仍然停留在执行范围之外。
报告阶段汇总了本次的可达性数据，并在目标函数附近标出一处资源生命周期可疑点，附上完整的复现材料。工程师确认之后，问题进入修复流程。
这次处理的端到端耗时约为 1 小时，其中定向测试的实际执行约占 30 分钟，其余时间用于分析与环境构建。人工介入只发生在最后的确认环节。
5.2 实验配置与效果对比
把同样的流程铺开到一批真实合入变更上做批量验证，实验配置如下。
变更选择。从 ANCK devel-5.10 与 ANCK devel-6.6 两个版本真实合入的 PR 中按子系统分布采样，每个版本 50 个，合计 100 个。
测试时间。ABACI 端到端 1 小时，其中定向测试执行 30 分钟，编译与分析占用另外的 30 分钟；对照组 Syzkaller 在同一节点上跑满 1 小时，拿到了更充裕的纯测试时长。
| 指标 | ABACI | Google Syzkaller | 提升 |
|---|---|---|---|
| 变更行覆盖率 | 48.4% | 约 0% | ∞ |
| 目标函数覆盖率 | 66.8% | 约 0% | ∞ |
| 目标函数到达率 | 54.1% | 4.5% | 12 倍 |
三个数字值得展开。目标函数到达率 54.1% 意味着超过一半的变更在合入之前拿到了真实执行验证，"测试通过"这句结论第一次对本次变更具备了实质含义。变更行覆盖率 48.4% 说明抵达之后的探索仍在继续，用例在目标附近展开了多条分支。对照组在前两项指标上贴近零值，覆盖率引导范式在定向场景下的错位由此得到印证。
从算力视角看，定向机制把原本消耗在无关路径上的预算重新投放到目标路径。硬件投入持平，单位算力的质量产出大幅提高。
5.3 实践中的经验
目标粒度直接影响测试收益。目标定在变更行上，反馈信号最锐利；定在函数层面，覆盖面更宽而收敛更慢。两种粒度在实践中按变更类型混合使用。
预算分配需要按子系统调整。语义分析与运行时探索之间的比例，在调用链较深的子系统里与其他子系统差异明显。
知识库的冷启动依赖专家投入。缺陷模式入库前的抽查环节必须保留，前期投入换来的是后续每一次筛查的方向感。运行一段时间之后，库的增长主要来自流水线自身的回灌。
报告的可复现性决定闭环成败。附带复现材料的缺陷才推得动修复，只有可疑描述的报告很难走出评审环节。
六、应用价值
面向基础软件研发团队
质量门禁的含义被改写，从"跑过测试"变成"变更代码被真实执行并验证过"，缺陷逃逸率因此在源头下降。可机械化验证的部分由系统承接，资深工程师的注意力回到真正需要领域判断的设计性问题上。测试能力随提交量弹性扩展，质量环节得以跟上研发加速的步伐。
面向企业级操作系统运营
缺陷在合入前的门禁阶段被拦下，故障成本被大幅压缩。潜在安全风险点被主动找出，安全工作从响应漏洞前移到识别风险。缺陷模式知识库随实践持续生长，团队经验由个人能力沉淀为组织资产。
面向开源社区生态
面向上游代码发现的问题与修复补丁持续回馈社区，企业级验证能力与开源质量之间形成正向循环。
七、总结
AI 正在重构软件研发的生产关系。代码生产环节已经完成效率跃升，质量保障环节的范式革新才刚刚开始。ABACI 给出了这个命题在基础软件领域的一个可落地答案。
范式上，测试的优化目标从覆盖面驱动的广度探索转向目标驱动的定向抵达。技术上，大模型的语义能力与运行时的确定性反馈以职责分离的方式融合，模型能力得到发挥，风险也被系统性地约束住。工程上，从方法到服务的闭环已经打通，它作为生产级质量门禁稳定运行，产出可复现的缺陷结论。价值上，硬件投入持平，目标到达率提升了一个数量级，真实缺陷与社区贡献持续产出。
基础软件的复杂度与变更速度还会继续上升，定向且可验证的自动化测试将成为质量保障的基本要求。我们期待与产业界和开源社区一同推动这个方向的演进。
本文档为技术能力介绍材料，文中数据来源于内部评测与生产环境统计。