正在加载，请稍候
以 GitHub Security Lab 2026 年 9 月开源的 Fuzzing Taskflow 为样本，拆解多智能体编排：五个专职角色的可检查产物、崩溃只被消费一次的状态机、用编译失败率做熔断的成本控制，以及为什么"一个智能体端到端跑"会在崩溃后失控。
把一个 C/C++ 仓库的 owner/repo 路径丢进去，它会自己认入口点、分析构建系统、写测试驱动、跑 AFL++、读覆盖报告、去重异常，再给每个唯一缺陷出一份漏洞报告。这是 GitHub Security Lab 在 2026 年 9 月放出的 Fuzzing Taskflow 的能力边界。真正难的不是让它跑通，而是当某一步崩掉时——谁的上下文没了，从哪一档状态接着跑。
官方仓库 README 把管线列成 11 个阶段，从安装 AFL++ 一路排到写活动报告。但在编排层面，这 11 步可以收敛成五个职责不重叠的角色。拆分的唯一标准：每个角色的输出，下一个人能不能独立检查。做不到这一点，所谓"拆分"只是把同一段上下文切成两半。
如果你当下还在做平台层的技术选型，可以先看这篇AI Agent 平台搭建指南：从 MCP 到多智能体编排的技术选型。
| 角色 | 覆盖的阶段 | 交接物（可检查产物） | 明确不该做的事 |
|---|---|---|---|
| 侦察 | fetch_source_code / identify_fuzz_targets / analyze_build_system | 入口点清单 + 构建配方 | 不写驱动桩 |
| 构造 | write_initial_harnesses / build_harnesses / qualify_harnesses | 可编译的 .afl 与 .cov 双产物 | 不决定跑多久 |
| 执行 | fuzz_iteration 中的 run_afl_for | AFL++ 队列 + 持久语料目录 | 不判断缺陷可利用性 |
| 判定 | 覆盖反馈循环（store_coverage_from_lcov 等） | 覆盖报告行 + coverage_gap 行 + 去重后的异常集合 | 不写补丁 |
| 分诊 | triage_crashes / confirm_fixed_crashes / write_vuln_reports | 每个异常一份带判定的 markdown 报告 | 不重复发起模糊测试 |
侦察负责把仓库变成"值得做模糊测试的函数列表"：抓源码、认候选目标（解析器、解码器、校验函数这类外部输入入口），再分析构建系统产出编译配方。产物应当落到数据库里的 target 行，能被下游直接查询，而不是留在某段对话里等下一个人去猜。构建配方的价值常被低估——同一个函数用不同宏和链接参数编出来行为可能完全不同，配方写错，后面全白做。
这一环的验收标准最干脆。官方 README 要求每个测试驱动编译两次：一次用 afl-clang-lto -fsanitize=address,undefined 出 .afl 二进制，一次用 clang -fprofile-instr-generate -fcoverage-mapping 出 .cov 二进制。原因是 AFL 的 edge 插桩产不出人能读的覆盖报告，于是 .afl 负责跑模糊测试，.cov 负责回放队列、算真实的行/函数/分支覆盖。交接物就是这两个文件加编译命令；编不出来，就没有交接物，不该放行。
执行角色只做一件事：把一个测试驱动跑起来，并管理它的种子与语料。它先通过 get_persistent_corpus_dir 拿到该目标稳定的语料目录，再调 run_afl_for 指定二进制、种子目录、输出目录、时长与 dictionary。交付的是 AFL++ 队列（default/queue）和持久语料目录。一个值得抄的细节：语料在迭代之间、轮次之间是持久化的，靠幂等 upsert 做增量，而不是每次从干净目录重来。
判定角色读 store_coverage_from_lcov 落库的报告和逐条未覆盖项，回答"下一步补哪里"。它可选的动作就几种：加一条带 coverage_feedback 标记的种子去够到未覆盖分支、改驱动源码去调一个此前没碰的 API、调 enrich_dictionary_from_uncovered 自动补上 AFL 满足不变量所需的魔术常量，或者明确跳过（冷错误路径、vendor 代码）。时间预算在这一环逐轮翻倍：30s → 60s → 120s → 240s → 480s → 960s，约 32 分钟一个目标封顶。
分诊把异常变成人能做决策的东西：先按 stack hash 去重，再对每个唯一问题给出可利用性初判、建议补丁和回归测试草稿，输出成机器可读的 markdown 报告。还有一个容易被忽略的阶段——确认旧问题是否仍可复现，它不做重新分诊，只验证修复是否生效。这个区分后面会反复用到。
五个角色跑起来以后，最大的浪费不是模型慢，而是同一个异常被五个智能体反复消费。要堵这个洞，得先给它定义一个显式状态机，而不是让每个角色各自判断"我见没见过它"。
一个够用的状态集：new → deduped → triaged → verdict_known → repro_confirmed → reported → fixed_verified。每次转换对应一次真实的写库动作，谁卡在哪一档、卡了多久，dashboard 上一眼看得到。
三条约束足够。其一，去重键用 stack hash，落库走幂等 upsert——官方 README 里"重跑同一仓库时对 targets/harnesses/runs 做 upsert 而非重复插入"的设计天然支持这个语义。其二，分诊队列只接受 new 状态的异常，已 triaged 的绝不二次排队。其三，confirm_fixed_crashes 只做复现验证，不重新判定可利用性。三条一立，一个崩溃被反复嚼的空间基本没了。
回退分两层。框架层已经内置：任务失败会以递增退避自动重试最多 3 次，仍失败则保存 session，可用 --resume <session-id> 从最后一个成功的 checkpoint 续跑。业务层要自己定线：
把线画在"重跑还是换策略"，是整条链路最省 token 的一个决定。
AFL 吐出的异常里混着大量非安全问题：超时、OOM、断言失败，以及 sanitizer 报出的 benign UB。归因建议三步走：先看 sanitizer 报告类型（ASan 的堆溢出远比 UBSan 的某个移位更像真问题），再看 hash 是否落在已知集合里，最后才看分诊给出的可利用性判定。复核比例上，一个务实做法是：判定为"可利用"与"未知"的 100% 走人工，判定为"不可利用"的按 10–20% 抽样，用来持续校准误报率。这是实践建议，不是某份报告的硬指标。
整条链路里最烧钱的是 C/C++ 的驱动生成。它不是简单的文本补全：模型要读懂头文件、理清链接顺序，写出既能被 clang 接受、又能被 AFL 插桩的 C 代码。一旦开启多候选（HARNESS_CANDIDATES ≥ 3，让不同 focus 各产一份），成本直接乘三。
所以这里最该加熔断器，判据用编译失败率：为每个 target 维护 compile_fail_ratio，当它在若干候选上超过阈值（经验上 60–70%），就停止为该目标继续生成候选，标成 needs_human 并转下一目标。理由很直接——让 LLM 反复写编不过的驱动，等于用昂贵模型换零产出。配套还有两个便宜动作：正式构建前先跑 clang -fsyntax-only 挡掉语法错；在候选多于一个时，只做 60 秒快速覆盖筛选，留最好的那个再进长跑。
并发侧与 CPU 绑死：AFL 实例数不超过可用核数，单目标时长交给翻倍预算与 plateau 提前退出来控制。还有一条省 token 的原则贯穿全程——LLM 只在决策节点花时间，机械执行（跑 AFL、编译、算 lcov）全部交给 MCP 工具里的 subprocess 封装。让模型去轮询模糊器输出，纯属浪费。
最容易走的弯路，是让一个智能体从头跑到尾。顺利时它看着更省事，可一旦在覆盖循环里崩了或超时，整个上下文就报废——前面辛苦侦察出的入口点和构建配方一起被冲掉，只能从源头重来。更隐蔽的是污染：长上下文里塞进几十轮模糊器输出和失败堆栈，模型对"哪些结论还算数"的判断会开始飘。
这套管线的做法值得借鉴：官方设计规则写得明白——每个阶段是一个自包含的任务流 YAML，阶段之间只通过 fuzz_context.db 这个 SQLite 库通信，没有内存内的 hand-off。把"状态"和"推理"分开：推理可以丢，状态不能丢。框架层再叠一个 task 级 checkpoint，失败后从最后成功点 --resume，恢复单位就从"整条链路"缩到了"单个阶段"。
多智能体一旦铺开，协调开销与上下文丢失的实测数据，可以参考Anthropic 多智能体实验的三个工程警示。
这也是 蓝曜炬辉 在给企业团队做 LLM 编排落地时反复看到的一条规律：多智能体系统最大的返工来源，很少是模型能力不够，而是状态没落在数据库里、或落错了地方。
先认清形态：run_fuzzing.sh 是长跑选手，单目标封顶 32 分钟，挂在每次提交上不现实。合理接线分两档：
--lint，能离线解析任务流及其引用的 personalities / toolboxes / model config，检查模型名、模板语法、未知字段，出错时退出码非零，可直接当 CI 门禁，且不产生任何模型调用。覆盖的接线点在库里：coverage_report 与 coverage_gap 两张表就是 CI 可读的信号源，把"覆盖下降"接成回归告警，比只看异常数量更早发现退化。而 confirm_fixed_crashes 天生适合当修复回归验证——修完漏洞，靠它确认旧问题真的不再复现。
是。仓库明确面向 native C/C++ 项目，测试驱动也直接生成 C 代码交给 clang 编译。其他语言目前没有现成链路，需要自补插桩与入口层。
不建议。它是长跑形态，单目标可到 32 分钟。提交触发只跑 --lint 这类离线门，重型模糊测试放夜间批量。
官方默认 Claude Sonnet 5，理由是它通过了内部测试。可在 src/seclab_taskflows_fuzzing/configs/model_config.yaml 更换；底层框架支持 OpenAI Agents SDK、Copilot SDK 与 Anthropic SDK 三种后端。
要格外小心。管线会在宿主机上直接跑 afl-fuzz、clang 和"由 LLM 挑选的任意构建命令"，中间没有容器隔离。文档明确提示：被提示注入影响的智能体，原则上能做你的用户能做的任何事。所以只能放在一次性环境（Codespace 或一次性 VM）里，且不给提权。
正常不会。异常按 stack hash 去重，落库走幂等 upsert，分诊队列只接受新出现的问题。若出现重复，通常是去重键取错了，而不是角色数量太多。