模糊测试交给智能体：它做决定，工具管执行

它想替掉的那部分人工

持续模糊测试不是一劳永逸的。接入多年的项目仍然藏着严重缺陷，原因几乎总是同一个：得有人盯着覆盖率，给没人触达的代码写新的测试桩，再把崩溃逐个分类。作者想知道这部分人工有多少可以交给智能体。

三层结构

• 一个脚本把各阶段串起来
• 每个阶段一份任务流描述，本质上是告诉智能体这一步做什么的提示
• 一组通过 MCP 提供的工具，真正去跑 AFL、编译测试桩、保存崩溃、读覆盖率

作者最在意的一条规则是职责分开：智能体负责决定，工具负责执行。智能体决定测什么、测试桩怎么写、下一个去追哪个覆盖缺口；工具只暴露基本操作。智能体从不直接调用 AFL 或编译器。所有状态都在一个 SQLite 数据库里，阶段之间只通过数据库传递。

每个测试桩会编译两次：一份带插桩用于引导模糊测试，一份带覆盖率统计用于事后回放队列、产出人读得懂的行覆盖和分支覆盖。

覆盖率反馈循环

每一轮，智能体让 AFL 跑一段时间，回放得到覆盖率报告，读未覆盖的分支，然后从几种动作里选一种：加一个能触达该分支的种子、改测试桩去调用更多接口、把判断条件里比较的常量补进字典，或者判断这是冷门错误路径而跳过。

时间预算每轮翻倍，从 30 秒到 960 秒，每个目标约 32 分钟。连续两轮的行覆盖率增量都低于 1 个百分点时，循环认为收益递减而停下。

分类与报告

循环结束后，每个崩溃被最小化、在内存检查器下回放取得调用栈、按栈顶去重；已知崩溃会在当前版本上重放，看上游是否已修。然后智能体读测试桩和崩溃函数，从公开接口回溯调用链，写出报告。

报告给出七种结论之一，其中最要紧的区分是：真正可从公开接口触达并利用的漏洞，还是测试桩自己的错误。每份报告附根因分析、可达性论证、修复补丁和回归测试草稿。补丁标着「需要复核」，作者明说：分析受限于模型对代码的理解，它确实会出错，结论应当看作给人准备的起点。

两处值得留意

运行环境：流水线在宿主机上直接运行模糊测试器、编译器和模型选定的任意构建命令，中间没有容器。作者的原话是，被提示注入的智能体原则上能做你这个用户能做的任何事，所以只应在一次性环境里、不带提升权限地运行。

模型选择：默认用 Claude Sonnet 5。理由是一些前沿模型会对输出加安全护栏，而它通过了全部内部测试。

文章没有给出这条流水线到目前为止找到了多少漏洞。