GitHub Security Lab 介绍了一条名为 Fuzzing Taskflow 的开源流程，旨在利用模糊测试（fuzzing）和语言模型代理，自动完成 C/C++ 项目测试中的大量环节。当该流程指向 GitHub 仓库时，它可以分析构建系统，确定合适的入口点，创建模糊测试工具（fuzz harnesses），运行 AFL++，读取覆盖率报告，改进工具，分类崩溃，并为每个潜在问题准备单独的报告。
该项目构建于 GitHub Security Lab Taskflow Agent 框架之上。该框架将工作流表示为一组由代理端到端执行的流程。文章作者 Antonio Morales 指出，其目标不是取消研究人员的作用，而是将耗时较长的重复性工作交给代理，同时将决策与执行保留在两个相互分离的层中。
流程如何工作？
使用时从项目仓库开始，例如在 Codespace 中运行命令 ./scripts/fuzzing/run_fuzzing.sh PROJECT。该流程负责安装工具、克隆仓库、分析重要函数，然后创建模糊测试目标并对其运行测试活动。其结构由 shell 运行器、描述工作阶段和发送给模型的指令的 YAML 文件，以及执行运行 AFL、编译工具、读取覆盖率和存储崩溃等操作的 MCP 工具组成。
代理不会直接调用 AFL 或 clang；它负责决定应测试什么，以及哪些覆盖率缺口值得跟进，而 MCP 工具则执行底层操作。状态存储在名为 fuzz_context.db 的 SQLite 数据库中，因此可以在不同阶段之间传递结果，而不依赖共享内存。
覆盖率改进循环
每个 harness 会构建两次：一个是用于通过适当的插桩工具引导 AFL 的 .afl 版本，另一个是用于重新运行输入列表并测量行覆盖率和分支覆盖率的 .cov 版本。每轮结束后，代理会检查未覆盖的分支，然后选择一项操作，例如添加新的 seed、修改 harness 源码以调用另一个接口、用代码检查的值丰富 AFL 字典，或忽略不值得投入成本的冷路径。
时间预算会从 30 秒逐步增加到 60、120、240、480 和 960 秒，也就是上述最大值下每个目标约 32 分钟。当检测到收益下降时，流程会停止：如果连续两轮的行覆盖率增幅低于一个百分点，则根据可调整的默认值转向另一个目标。
输入和崩溃处理
该流程支持针对 JSON、XML、正则表达式、PNG 以及带内嵌长度的二进制 TLV 格式的专用机制，还能从 C 和 H 文件中存在的字符串常量和数字常量生成字典。每次覆盖率步骤之后，它还会根据未覆盖行附近的检查条件丰富该字典。此外，每个 harness 都会保留一个固定的 corpus 文件夹，并使用 afl-cmin 限制其大小，同时在各轮和各次测试活动之间保留有用的输入。
测试活动结束后，崩溃会使用 afl-tmin 进行缩减，并在 AddressSanitizer 下重新运行，然后根据最高栈帧的指纹去除重复项。该流程还会重新测试已知崩溃，以验证修复的影响，并将结果分类为：漏洞、库加固、harness 错误、内存耗尽、超时、断言失败或重复项。
为什么这条消息重要？
这里的实际价值在于，该流程试图自动化通常限制持续模糊测试效果的循环：编写 harness、读取覆盖率、选择下一个缺口以及分类崩溃。这可能降低启动此前从未进行模糊测试的项目的测试成本，或帮助扩大现有项目的覆盖率。
但 GitHub Security Lab 提出了一个关键限制：该流程会直接在主机系统上运行 afl-fuzz、clang 以及由模型选择的构建命令，不使用隔离容器。因此，受到提示注入影响的代理可能会执行用户能够执行的操作。项目建议在可销毁的环境中运行它，例如 Codespace 或临时虚拟机，并且不要使用高权限。
此外，漏洞报告和建议的修复并非最终结果。文章强调，模型分析可能出错，建议的补丁也标记为必须经过审查。因此，Fuzzing Taskflow 是为研究人员准备良好的起点，而不是替代人工验证可达性、可利用性和根本原因的方案。