GitHub Security Lab 的 Antonio Morales 开源了一套能自己跑模糊测试的流水线：给它一个仓库地址，它识别入口点、写 harness、拉起 AFL++、读覆盖报告、分诊崩溃。项目叫 Fuzzing Taskflow，基于 Taskflow Agent，代码在 GitHub 上公开。它不做代码补全，也不写漏洞分析报告，只盯住从入口点到崩溃清单这一条链路。C/C++ 维护者可以直接 clone 下来对着自己的项目跑。
一条命令背后的完整链路
输进去的是 URL，吐出来的是 crash
整个流程的输入端干净得不像话：一个仓库 URL，没有配置文件，没有前置脚本。中间也不需要人按播放键——识别入口点、生成 harness、编译、拉起 fuzzer、读覆盖率、归并崩溃，一路串下来。真正值得看的是它的输出清单：harness 源文件、语料与运行参数、崩溃样本、外加一份分诊结论。安全工程师最怕的从来不是工具笨，而是工具甩过来一个复现不了的结论。把中间产物全部落地，这条流水线才算能被信任。
Taskflow Agent 扮演的角色，比“自主”两个字朴素得多
框架本身没有神秘之处：把任务拆成带依赖关系的节点，让模型在节点之间传递上下文和中间产物。听起来平平无奇，可正是这份平无奇决定了流水线能不能用。每一步的产出必须是下一步能解析、能继续操作的结构化东西，而不是一段人类读着舒服的自然语言。Morales 的设计取舍基本都绕着这一点转，所以他做的不是让模型更聪明，是让模型每一步都留下能被程序接手的痕迹。
为什么安全团队最后还是回到 C/C++
内存不安全的代价摆在那里，模糊测试在 C/C++ 上的投入产出比常年排在第一档。麻烦也在这里：每个项目的构建系统都长得不一样，依赖千奇百怪，入口函数藏得深浅不一。过去十年里，大量项目的 fuzzing 覆盖率上不去，原因不是没人愿意跑 AFL++，而是写 harness 这件事需要有人坐下来读几小时代码。把这几个小时交给模型，收益曲线立刻变得清晰。
harness 写不出来，后面全是空谈
入口点识别：先搞清楚该往哪儿喂字节
入口点判断是整条流水线的第一道分水岭。读命令行参数？解析文件头？跑网络协议？还是把某个库函数暴露出去？判断错了，harness 写得再工整也是在空转——fuzzer 一天跑几亿次执行，一次都没摸到真正的逻辑。这个步骤考的是对代码结构的理解，模式匹配在这里帮不上太多忙。
结构感知，省下的是算力也是时间
往 fuzzer 里灌纯随机字节，对文本格式、二进制格式、协议报文基本都是浪费。所谓结构感知，是让模型先读懂解析器期待什么：magic number、长度字段、校验和、嵌套层级，然后把语料构造和变异策略往这些约束上靠。它换不来免死金牌，但能实打实减少那种“卡在第一个校验就返回”的执行。
编译不过，前面的聪明都归零
链接失败、缺头文件、CMake 选项写错、sanitizer 和优化级别打架——这些琐碎问题会吃掉 agent 大半的上下文预算。流水线得能读懂编译器的报错，回到 harness 或构建脚本上动手改，再重试。这一步做不扎实，后面所有环节都无从谈起，再漂亮的分诊逻辑也是空转。
覆盖报告既是眼睛，也是天花板
读懂一份覆盖率报告，没有那么机械
报告里是函数名、边、计数、百分比。哪些新增边说明 fuzzer 真的往前推进了？哪些只是启动路径上的噪声？覆盖率涨不动时，该换变异策略还是该补语料？回答这些问题，需要模型把报告和源码本身对上号。这一步做得好坏，直接决定了后面的循环是在探索还是在原地踱步。
循环什么时候该停
反馈回路如果没有终止条件，烧的就是真金白银。可以设预算：执行次数、墙钟时间、覆盖率增幅阈值。停早了漏掉深层路径，停晚了对维护者没有实际意义。Morales 把选择权交回调用者，而不是替所有人拍一个默认值——这个处理很务实，因为不同项目的“跑够”定义本来就不一样。
分诊才是脏活累活的中心
去重和根因，别指望一次到位
三十个崩溃样本，可能只对应两处根因。不做归并，维护者面对的是一份噪声清单，看完就想关掉。分诊要按调用栈、崩溃类型、触发路径把样本聚起来，再指出真正该修的是哪一处。这件事没有一劳永逸的算法，agent 能给的是排序和理由，不是终审判决。
哪个 crash 值得修
崩溃不等于漏洞。同一处越界读，在 sanitizer 下报得惊天动地，实际可能落在不可控的尾部填充上；而一个看着温和的整数溢出，后面接的也许是可控写。分诊环节的价值就在这里：给出优先级判断，并说明为什么。堆一份按时间排序的崩溃列表，对维护者几乎等于没做。
人没有被请出这个流程
工程师的位置换了，但没有消失。过去的工作是写 harness、跑、翻日志；现在是审查 agent 的判断——入口点选得对不对，harness 有没有把关键输入裁掉，分诊结论站不站得住。工作量下降，不等于责任转移。这一点，任何把 agent 塞进安全流程的人最好先想清楚。
真想用，先摸清楚它的边界
什么样的项目适合先上
解析类、协议类、图像与文档处理类库通常是最合适的起点：入口清晰，格式有边界，历史上还沉淀了大量已知漏洞，正好拿来检验流水线的判断力。反过来，构建系统极度定制、依赖闭源组件、需要特殊硬件的项目，先别急着上，光是把编译打通就够耗掉一整轮。
别把它当漏洞挖掘机
它不会替你决定这个崩溃值不值得修。它能做的是把过去几天的手工准备压缩到几十分钟，把维护者从“写 harness”推向“审结论”。这个价值已经不小。把它想象成一台自动发现零日漏洞的机器，多半会失望；把它当成一个不知疲倦、偶尔判断失误的实习生，预期就刚好对得上。
