【论文阅读】FuzzAgent: Multi-Agent System for Evolutionary Library Fuzzing

摘要：

库模糊测试对于强化软件供应链至关重要，但大规模采用它仍然代价高昂。从业者仍然在环境设置上花费大量精力，难以生成尊重复杂API约束的工具，并且缺乏可靠的方法来区分真正的库错误和工具引起的崩溃。最近基于LLM的系统自动化了该管道的一部分，但它们通常作为忽略运行时反馈的一次性代码生成器运行，这限制了它们到达的代码深度和它们报告的错误的有效性。我们认为有效的库模糊测试本质上是迭代的：每个活动都会暴露新的覆盖瓶颈和崩溃，下一个活动应该从这些信号中发展而不是从头开始。基于这一见解，我们提出了FuzzAgent，这是一个多代理系统，它将库模糊测试转化为一个进化过程，在这个过程中，一个专门的代理团队在整个模糊测试生命周期中进行协作，并将每一个决定建立在具体的运行时证据中，因此线束套件不断完善，以实现更深入的覆盖范围和更高保真度的跨轮碰撞分析。

我们根据四个最先进的基线（OSS-Fuzz、OSS-Fuzz-Gen、PromptFuzz和PromeFuzz）在20个真实世界的C/C++库上评估FuzzAgent。FuzzAgent无需人工干预即可完成所有20个库的完整模糊测试生命周期，达到179,619个分支，分别超过OSS-Fuzz、PromptFuzz、PromeFuzz和OSS-Fuzz-Gen 45.1%、73.2%、92.1%和191.2%。FuzzAgent还识别了102个真正的库错误，其中78个已经被上游维护者确认和修复。

简单人话总结：

库 fuzzing 在规模化部署时成本高昂。实践者面临三大困难：（1）环境搭建耗费大量精力；（2）难以生成符合复杂 API 约束的有效 harness；（3）缺乏可靠手段区分真正的库缺陷和 harness 引发的误报。

现有的 LLM 系统虽然能部分自动化，但本质上是一次性代码生成器，忽略运行时反馈，既限制了覆盖深度，也影响了 bug 报告的有效性。

作者提出 FuzzAgent，一个多智能体系统，将库 fuzzing 转变为进化过程。多个专门智能体协作完成完整的 fuzzing 生命周期，每个决策都基于具体的运行时证据，从而在多轮迭代中不断改进 harness 套件，实现更深的覆盖和更高保真度的崩溃分析。

一、导言

（一）、背景：

fuzzing 作为广泛采用的自动化测试技术及其在 OSS-Fuzz 上的成就（截至 2025 年已报告超过 50,000 个 bug）。但指出仅靠变异输入已经越来越难以获得覆盖提升，因为代码覆盖被"阻塞"。由此引出库 fuzzing（library fuzzing）的重要性——通过合成新的 fuzz target（harness）来拓宽测试覆盖。

（二）、三个核心问题：

1、环境搭建和配置仍然劳动密集 — 开发者需要协调编译、插桩、字典、种子、harness 开发、fuzzer 执行、结果分类等多个组件，即使是经验丰富的开发者也困难重重。数据显示 82/171 个 OSS-Fuzz 问题与构建失败有关，53% 的参与者在新库搭建时失败。

2、设计有效的 fuzzing harness 不简单 （harness质量的问题）— 现代库往往有数百个 API，涉及复杂依赖关系和严格参数约束。违反约束的 harness 要么提前失败、只能探索浅层路径，要么触发误报崩溃。现有系统（如 Hopper、PromptFuzz、PromeFuzz）依赖大量尝试或高成本的摘要生成。

3、崩溃报告难以解读 — 很多崩溃是由无效 API 序列或 harness 自身问题触发，而非库的真正缺陷。现有方法的崩溃过滤依赖粗粒度启发式，缺乏充分的语义上下文。

（三）、现有不足

• 手动方法（LibFuzzer、OSS-Fuzz）→ 高度依赖人工
• 基于消费者的方法（Fudge、FuzzGen、APICraft、UTOpia）→ 利用静态/动态分析提取 API 使用模式，但依赖现有代码库
• 基于生产者的方法（GraphFuzz、AFGen、Nexzzer、Hopper）→ 从零分析 API 规格，但可能错过高阶交互
• 基于 LLM 的方法（OSS-Fuzz-Gen、CKGFuzzer、PromptFuzz、PromeFuzz）→ 利用 LLM 的代码理解能力取得进展，但：
  • PromptFuzz 产生大量无效 harness，探索浅层
  • PromeFuzz 的 O(n²) 全库摘要成本在大库上过高，且上下文可能冗余嘈杂

（四）、解决措施

即环境搭建、harness 有效性、崩溃验证三者形成一个"三角瓶颈"——任何一个环节的短板都会阻碍整个流程的自动化。作者的核心洞察是：现有的 LLM 系统本质上是开环代码生成器（open-loop code generators），它们不接收运行时反馈，因此无法迭代改进。缺乏闭环反馈机制是关键限制因素。

【也就说：怎么让llm处理信息然后实现迭代这一步，会重点看迭代反馈的信息是什么，以及这个agent如何设计。】

作者提出将 LLM 从开环代码生成器转变为闭环推理智能体，通过专用接口桥接静态分析和动态 fuzzing 反馈，使模型能够基于运行时证据迭代优化输入，实现进化式库 fuzzing。

二、背景

（一）、简述：

II-A 节：Library Fuzzing Workflow（库 fuzzing 工作流程）

第一段：总体概述

库 fuzzing 遵循标准 fuzzing 流程，但额外需要编写 harness 来调用库 API 和减少误报。实际搭建通常涉及以下五个阶段：

第二段：阶段 1 — 构建与插桩

目标库需要用插桩编译以支持：（i）反馈驱动 fuzzing（如 LibFuzzer、AFL）和（ii）bug 检测（如 ASAN、UBSAN、MSAN）。这一步通常需要专门的编译器标志、非平凡的构建配置和谨慎的依赖管理。

第三段：阶段 2 — 字典和种子准备

引导 fuzzing 需要准备 token 字典和种子语料库。这些工具能引导变异走向符合格式的输入并改善早期探索，但生成高质量字典和种子通常需要对预期输入结构的领域知识。

第四段：阶段 3 — Harness 生成

库 fuzzing 需要能够调用暴露 API 的 harness。实际库可能提供数十或数百个相互依赖的函数，因此有效 harness 必须尊重 API 前置条件、对象生命周期和调用顺序。编写这样的 harness 耗时且容易出错，通常需要对目标库有深入理解。

第五段：阶段 4 — Fuzzer 执行

有了 harness、字典和种子后启动 fuzzing。执行期间应监控代码覆盖指标和异常行为（崩溃、内存违规、断言失败、超时）。

第六段：阶段 5 — 崩溃验证

检测到崩溃后需要分析结果并识别根因。这一阶段通常需要手动检查和迭代调试，使用 GDB 或 Valgrind 等工具分类和确认问题。

第七段：实例说明与用户研究数据

每个阶段都非平凡且需要大量手动努力和领域专业知识。引用 Zhao et al. 的用户研究，参与者报告整体流程过于复杂，称其"将配置视为迭代的试错过程"。

接着给出 libaom 的构建脚本例子（上文已详述），说明用户不仅要理解如何构建库，还要小心处理与库配置冲突的插桩标志，否则构建会失败。

进一步指出，尝试使用新 fuzzer 时复杂度显著增加，因为许多 fuzzer 需要自定义编译器或插桩标志。引用用户研究观察："这些额外步骤如果你启用了某些优化标志可能会失败，或者本身就会失败，因为开源和遗留程序可能出奇地脆弱"。

如图1中的示例构建脚本所示，用户不仅必须了解如何构建库本身（第9-16行），还必须仔细处理可能与库配置冲突的检测标志（第1-7行）。在这种情况下，用户必须考虑特定于项目的构建标志；否则，构建将失败，因为在libaom中启用的-Wl、-z、defs标志与ASAN[34]和MSAN[48]冲突。此外，当尝试使用新的模糊器时，模糊设置的复杂性会显着增加，因为许多需要自定义编译器或检测标志。

II-B 节：Multi-Agent Systems（多智能体系统）

第一段：多智能体系统定义

多智能体系统是多个自主智能体交互以解决单智能体难以应对问题的计算框架。近年来 LLM 的进步显著增强了这些系统的能力，使智能体能够理解复杂上下文、生成复杂响应并做出精细决策。

第二段：系统特点与典型工作流程这些系统对于可分解为专门子任务的复杂任务特别有效，每个子任务由具有特定专长的人工智能体处理。典型的 ReAct（推理和行动）工作流程如 Figure 2 所示：

1、任务分发到智能体池，每个智能体有特定角色和能力

2、智能体利用提供的工具作为接口与外部环境交互

3、从环境收集的观察结果反馈给智能体

4、智能体据此迭代优化策略和行动

这种动态交互使系统能够随时间适应策略并改善性能。

（二）、快速总结：

方法类别	代表工作	优点	不足	项目/论文链接
手动方法	LibFuzzer, OSS-Fuzz	经大规模验证，社区成熟	高度依赖人工编写 harness 和配置环境	OSS-Fuzz
基于消费者的静态/动态分析	Fudge, FuzzGen, APICraft, UTopia	从现有代码提取真实 API 使用模式	依赖现有代码库，对新库或无消费者库不适用	FuzzGen (USENIX Security 2020)
基于生产者的分析	GraphFuzz, AFGen, Nexzzer, Hopper	从零生成 harness，不依赖现有代码	规则推断可能遗漏高阶 API 交互；Hopper 标签不准确	GraphFuzz (ICSE 2022), Hopper (CCS 2023)
基于 LLM 的生成	OSS-Fuzz-Gen, CKGFuzzer, PromptFuzz, PromeFuzz	利用 LLM 理解 API 语义，能处理约束	大量无效 harness、浅层探索；PromeFuzz O(n²) 摘要成本在大库上难以承受	PromptFuzz (CCS 2024), PromeFuzz (CCS 2025), OSS-Fuzz-Gen

三、系统简介

这个章节主要介绍了fuzz agent的整体架构设计

架构由三大组件组成（Figure 3）：Agent Pool、Interfaces、Environment

FuzzAgent 的架构包含三个主要部分：

• Agent Pool — 托管一组专门智能体，每个负责 fuzzing 生命周期的一个阶段
  • Manager Agent通过根据当前工作区状态和最新反馈信号选择要运行的下一个代理来协调池。
  • 其他Agent用于辅助完成任务，详细可以看下面
• Interfaces — 提供四个专用接口（计算机使用、网络搜索、覆盖率分析、崩溃调试），为智能体提供高层抽象
• Environment — 维护有状态的工作区，确保数据一致性和资源管理

智能体通过接口行动，接收反馈和观察来迭代优化决策。整个工作流通过特定策略（IV 节详述）驱动，每个策略编码为智能体提示与接口工具的组合。

Agent Pool:

Agent Pool 将智能体按 fuzzing 的三个阶段分组：

1、Fuzzing Setup Agents（测试准备智能体）：通过准备构建环境、字典和初始种子为有效的库模糊测试奠定基础。

• Library Builder — 产出带有所需插桩的可靠构建产物
  • Agent调用需要的工具，用来生成可靠的构建文件（比如头文件、静态和动态链接库等）
  • 检查源代码和构建配置，然后自动化构建过程以保持结果可重现和正确
• Dictionary Generator — 结合领域知识与网络资源（也就是说自己会检索资料），构建紧凑有效的词典
• Seed Generator — 收集符合库规范的初始输入文件（包括目标库规范、协议或数据格式）

2、Fuzzer-Specific Agents（fuzzer 专属智能体）：简单来说就是为模糊测试阶段部分专门服务的智能体，会生成有针对性的harness并运行相应的模糊测试活动来探索库代码

• Harness Generator — 根据 Coverage Analyzer 报告的目标生成有针对性的 harness，并通过编译验证
  • 每个工具都指定要使用的API或代码区域，以及所需的依赖项和调用序列。代理还通过编译验证工具以确保正确性
• Fuzzer Executor — 以阻塞方式运行 fuzzing 活动，监控崩溃和覆盖指标

关于 Fuzzer Executor 的 "blocking manner"

论文在 IV-B 节 "Fuzzer Execution" 中明确解释了这种方式：blocking manner 即同步等待：Fuzzer Executor 启动 fuzzing 进程后，会一直阻塞在该进程上，持续监控覆盖率和崩溃信号，直到满足终止条件（检测到崩溃、覆盖达到平台期、或时间预算耗尽）才返回结果。这与异步启动 fuzzer 后立即去做其他任务的非阻塞方式相反。这种设计确保了每次 fuzzing 的结果（覆盖统计数据、崩溃信息）可以被完整收集并存入 Environment，供后续的 Coverage Analyzer 和 Crash Analyzer 使用，保证反馈闭环的可控性。

总之后面会说

3、Analysis Agents（分析智能体）：检查模糊测试结果以定位限制有效性的瓶颈，并将其发现转化为其他代理的优化指令，以便流程不断改进

• Crash Analyzer — 通过交互式源码检查和调试，将崩溃分类为真正库缺陷或 harness 错误
• Coverage Analyzer — 识别最关键覆盖缺口，推导期望能带来最大覆盖增益的 API 调用序列

有一个 Manager Agent 负责协调整个智能体池，根据当前工作区状态和最新反馈信号选择下一个要运行的智能体。

Interfaces：

FuzzAgent 提供四个专用接口，为Agent提供库模糊测试所需的功能，同时保护它们免受低级复杂性的影响（比如：文件操作、检测、模糊编译、网络搜索、覆盖率提取和崩溃调试）。每个接口都是工具的集合，它们公开了实现库模糊测试目标所需的一个功能区域的高级抽象。

1、Computer Use Interface（计算机使用接口）：

• 文件操作（读、写、搜索）和系统/专用命令执行
• 文件操作工具改编自 SWE-Agent（https://github.com/SWE-agent/SWE-agent），命令工具封装库构建、harness 编译、fuzzing 执行等
• 目的是让智能体像人类专家一样与底层系统交互

2、Web Search Interface（网络搜索接口）：

• 提供搜索引擎查询、信息提取、从网络下载材料的工具
• 用于获取 API 使用示例、常见陷阱和最佳实践
• 尤其适用于字典和种子准备（LLM 难以生成特定二进制格式）

3、Coverage Analysis Interface（覆盖率分析接口）：

• 受 FuzzIntrospector 启发，将覆盖数据组织为层级结构：
  • Project-Level → Module-Level → File-Level → API-Level → Internal-Function-Level → Branch-Level
    
• 智能体可定位最严重覆盖缺口并制定具体补救策略

4、Crash Debugging Interface（崩溃调试接口）：简单来说是用于定位崩溃产生于什么地方

• 利用 CASR 自动将崩溃追踪与相应源代码关联

CASR 是 Crash Clustering for Linux Applications 的缩写，CASR 的核心功能是自动将崩溃追踪（call stack）与对应的源代码片段关联起来，从而拼接出崩溃上下文信息。结合 GDB 的批处理模式，FuzzAgent 可以系统地复现崩溃、检查崩溃点的运行时状态，实现基于证据的根因分析，而不是仅凭调用栈猜测。在实验中，CASR 还被用于对独特崩溃进行去重（deduplication），即通过调用栈聚类识别唯一的崩溃实例。

• GDB 非交互式批处理模式允许复现崩溃并检查运行时状态
• 目标是实现基于证据的根因分析

Environment：

Environment 维护一个有状态的 fuzzing 工作区，解决 agentic 系统中的稳定性问题，

具体约束：

• 定义严格的目录布局（源码、构建产物、fuzzing 输入输出、分析结果）
• 智能体不允许在此布局外读写，违规操作被拒绝
• 智能体退出前验证目录状态，确认符合预期执行轨迹
• 通过持续监控目录状态追踪整体进度，引导工作流向迭代式定向探索和结果分析

组件	核心作用	关键设计理念
Agent Pool	任务分解与专门化	按 fuzzing 阶段分组，Manager Agent 协调
Interfaces	屏蔽底层复杂性，保持灵活性	四个接口覆盖操作、搜索、分析、调试
Environment	有状态约束，平衡灵活性与稳定性	严格目录结构 + 退出验证

四、进化的库模糊测试（EVOLUTIONARY LIBRARY FUZZING）

本部分接续第 III 节介绍的架构（智能体、接口、环境），重点阐述将这些组件组织成进化式工作流的具体策略。作者指出，仅有架构还不够，还需要明确定义的策略来将反馈转化为下一步行动。

工作流划分为四个核心阶段（对应 Figure 4 中的 Phase 1-5，即 1 个设置阶段、1 个执行阶段、2 个进化阶段）：

• Fuzzing Environment Setup — 构建并插桩目标库，准备字典和种子
• Targeted Fuzzing Exploration — 在覆盖率分析器和崩溃分析器的指导下生成目标 harness，执行 fuzzing 并收集结果
• Coverage-driven Evolution — 若无崩溃，分析层次化覆盖数据，定位关键缺口并建议新 harness
• Crash-driven Evolution — 若发现崩溃，通过迭代调试区分 harness 错误和真实库缺陷，前者反馈修复 harness，后者记录为 bug

与之前方法将分析编码为硬编码逻辑不同，FuzzAgent 的每个策略通过定制的系统提示和接口工具实现。每个智能体的系统提示列于附录 F。

A. Fuzzing Environment Setup

本小节描述初始设置阶段的三个智能体如何工作。FuzzAgent通过调度库生成器、字典生成器和种子生成器来设置模糊环境来启动活动。

Library Building：首先检查源代码识别构建需求，编写可接受自定义插桩标志的构建脚本（类似 OSS-Fuzz 风格，附录图1），通过构建工具生成插桩后的库文件。如果构建失败，进入 build-verify-fix 循环，直到所有验证通过。

Dictionary Generation：论文指出生成高质量 fuzzing 字典困难，因为它需要对目标输入格式和协议的深入理解，通常由库开发者手动编写。FuzzAgent 不采用传统的静态/动态分析（如 Redqueen），而是从 Web 检索现有字典。它搜索 GitHub 上与目标库使用相同协议或格式的开源项目，检查其源代码布局和构建脚本（如 Dockerfile、build.sh）定位字典文件，包括从复杂构建步骤中的下载链接获取。收集候选后，剪枝掉不符合目标规范的 token，组装成结构化字典文件。

Seed Generation：同样从 Web 收集示例文件作为初始种子语料库。因为生成二进制格式的种子对 LLM 困难，搜索公开数据集和与目标领域相关的仓库，下载相关性高的内容作为种子。（附录图8）

B. Targeted Fuzzing Exploration

本小节解释如何生成和运行 harness。

与之前方法（Hopper、PromptFuzz、PromeFuzz）采用暴力策略不同——通过变异 API 组合或调用序列来生成很多 harness，但往往无效 相比，FuzzAgent 采用反馈驱动的方式生成 harness，通过迭代检索源代码并应用修复来确保 harness 有效性，同时专门针对已识别的覆盖瓶颈。

Harness Generation（Harness生成）：

1、Coverage-guided Generation：接收具体指令（指向目标 API 或代码区域），增量检索相关源代码和文档，理解 API 声明、依赖关系和使用模式，构建正确调用目标 API 的 harness。

2、Compilation & Verification：对每个生成的 harness 进行编译验证，编译错误触发迭代修复，直到满足质量标准。

Fuzzer Execution（模糊测试器执行）：

使用准备好的字典和种子，在 harness 上执行 fuzzing。执行是阻塞式的，监控覆盖率和崩溃信号，直到满足终止条件之一：

• 检测到崩溃
• 代码覆盖增长率 $ R_t = \frac{N_t - N_{t-1}}{N_{t-1}} $低于阈值（如 0.01%）且持续一定时间（如 1 分钟），表明覆盖进入平台期（Nt是在时间t下覆盖唯一运行函数总数）
• 时间预算耗尽（默认 1 小时）

执行后，覆盖超过现有知识的新测试用例被合并到种子语料库中。

C. Coverage-Driven Evolution

本小节描述当无崩溃时，Coverage Analyzer 如何分析层次化覆盖率数据并指导新 harness 生成。它采用两阶段方法论：

API Surface Exploration Phase（阶段 3）：采用基于组的 API 关系推理策略（Figure 10），而非像 PromeFuzz 那样孤立地推理每个未覆盖 API。首先分析模块级和文件级覆盖率，定位同一组件内功能相关的低覆盖区域，然后识别这些未覆盖 API 的依赖关系以形成函数簇（如 ArrayCreate、ArrayInsert、ArrayDelete），同时补充必要的辅助函数（初始化、清理、验证等），形成完整调用序列作为 harness 生成指引。

Deep State Exploration Phase（阶段 4）：PromptFuzz 已证明仅扩展 API 表面不足以达到深度覆盖，因为许多运行时覆盖阻塞器需要特定输入格式或 API 调用序列。此阶段分析内部函数级和分支级覆盖率数据，定位包含大量未执行代码的具体函数和代码分支。针对每个阻塞器，详细分析其源代码以理解触发条件，然后设计满足这些条件的 API 调用序列和参数值，作为 harness 生成的指导。

这里结合前面的信息来具体说一下可能是怎么定位的：

在第三部分系统介绍这里我们简单地说到了这个系统是设计了很多的接口，然后里面具体有一个Coverage Analysis Interface接口，所以主要也还是通过这个提供的层次化数据结构以及代理的系统提示（Figure 11）中编码的策略来实现的。

简单来说，这个过程是逐层下钻 + 人工推理式分析。

层次化覆盖数据：Coverage Analysis Interface 将覆盖率数据组织成 6 个级别：

Project-Level → Module-Level → File-Level → API-Level → Internal-Function-Level → Branch-Level

代理可以查看每个级别的覆盖率统计，从而准确找到哪些内部函数或代码分支存在大量未执行的代码。

定位步骤

1、检查内部函数级数据：代理首先查看 Internal-Function-Level 覆盖率，定位到那些已被 API 级调用触及、但内部函数的覆盖率占比很低（即"被外部调用但内部路径未充分执行"）的函数。

2、深入分支级数据：对于每个候选的内部函数，进一步查看 Branch-Level 覆盖率，找出具体哪些分支（if-else、switch-case）被阻塞（blocked），也就是未被执行的代码路径。

3、源代码分析：选定“阻塞复杂性最高”（Blocked Complexity 最大）的函数或分支后，代理读取对应的源代码，分析导致阻塞的条件，例如：

某个 if 判断需要特定参数值才能走 True 分支

某个内部循环依赖特定的输入格式

某个错误处理分支需要特定的错误码

4、追踪入口点：通过调用链找到是哪个公开 API 最终到达该阻塞位置，从而确定应该在 harness 中调用哪些 API 以及如何设置参数。

更简单的理解：可以把代理想象成一个人工测试工程师：先看一个大表格，找到哪些函数被调用了但还有很多代码没跑到；然后针对这些函数查看更细的行覆盖，找到哪些 if 语句没有跑过 true 分支；最后阅读源代码，弄清楚需要什么条件才能触发这些未覆盖的分支，并据此设计一个新的 harness 专门去突破这个瓶颈。

D. Crash-Driven Evolution

本小节描述当 fuzzing 探测到崩溃时，Crash Analyzer 如何工作（对应 Figure 4 的 Phase 5）。

首先最小化 harness 代码（借鉴 Hopper 的方法），然后通过迭代调试确定崩溃根因。具体流程：

1、利用 Crash Debugging Interface 复现崩溃、收集调用栈、将栈帧与对应源代码关联

2、通过系统性的源代码检索和崩溃程序调试，分析崩溃上下文识别根因

3、使用源代码或文档中的显式证据增强分类依据

根据分析结果，崩溃被分类为真正的库缺陷（生成详细 bug 报告）或harness 错误（反馈以修复 harness）。

五、评估

实验目的：在 20 个广泛使用的 C/C++ 库上，全面评估 FuzzAgent 的效率与有效性。

与 OSS-Fuzz、OSS-Fuzz-Gen、PromptFuzz、PromeFuzz 四个基线对比，覆盖从工业级持续 fuzzing 基础设施到最先进的 LLM 驱动 harness 生成器。

库分为两组：17 个 PromptFuzz/PromeFuzz 已评估的库（公平比较）和 3 个大规模关键库（protobuf、OpenSSL、OpenCV，验证真实部署挑战）。

实验设置：

• 硬件：双 Intel Xeon Platinum 8580 (120核/240线程)，8× NVIDIA H200 GPU，2TB RAM，Ubuntu 24.04 LTS。
• LLM：自托管 DeepSeek V3.2 (vLLM)，温度 1.0，top-p=0.95。
• Fuzzer 引擎：AFL++。覆盖率测量：llvm-cov (source-based)。
• 所有实验：ASAN + UBSAN 开启。
• FuzzAgent：每库 24 小时端到端预算（含整个流程）。
• 基线：每个 OSS-Fuzz 实例单核运行 24 小时；LLM 基线用 5 个并行 LLM 线程生成 harness 最多 24 小时后合并 fuzz 24 小时。
• 对每个 harness 生成阶段和 fuzzing 阶段各重复 5 次，报告均值。
• 额外实验：FuzzAgent 的所有 harness 合并后额外 fuzz 24 小时 → FuzzAgent†。

对应图表：Table I 总表（覆盖所有 20 个库的库信息、fuzzer 实例数、分支覆盖、LLM 成本、检测 bug 数）。

A. Automation and Efficiency

自动化能力与效率总览：

维度	内容
实验目的	衡量 FuzzAgent 的全自动化程度、成本与效率，并与需要人工干预的基线对比
实验效果简述	FuzzAgent 在 20 个库上无需人工干预，平均生成并执行 330 个 harness，累计覆盖 179,619 分支。LLM 成本：平均每库$63.44，每检测一个真实 bug 仅 $3.11。 对比基线：PromptFuzz/PromeFuzz 在新库上需要平均 8 小时 / 12 小时 手动环境配置；PromeFuzz 在 protobuf、OpenSSL、OpenCV 上预处理阶段 24 小时内未完成，成本超 $200。
对应图表	Table I（LLM 成本行）、Figure 13（执行轨迹）

智能体时间分布：

大部分时间花在** Harness Generator (34.05%) 和 Fuzzer Executor (33.08%)**，合计占 67.13%；Coverage Analyzer (13.30%) 和 Crash Analyzer (13.11%) 次之；环境准备（Builder、Seed、Dict）仅 6.46%。说明系统将主要预算用于直接推动覆盖和反馈闭环，而非协调开销。

工具调用统计：

总工具调用 30,499 次。文件操作（15,714）和 Bash 命令（7,605）占 82.3%；此外有 1,786 次专用 fuzzing 工具、3,282 次覆盖率分析、1,213 次崩溃调试调用。Harness Generator 贡献最多（14,490 次）。Web 搜索仅 898 次（主要用于字典和种子生成）。

B. Effectiveness on Code Coverage

总体覆盖结果：

维度	内容
实验目的	比较 FuzzAgent 与基线在 20 个库上的分支覆盖效果
实验效果简述	FuzzAgent（24 小时端到端）覆盖 179,619 分支，超过 OSS-Fuzz (123,792) 45.1%，PromptFuzz (103,686) 73.2%，PromeFuzz (93,507) 92.1%，OSS-Fuzz-Gen (61,678) 191.2%。Mann-Whitney U 检验统计显著（Table VI）。 每库层面：17/20 个库上最高。FuzzAgent†（合并后额外 24 小时 fuzz）达 184,840 分支（+2.9%），证明增益来源于进化流程而非更长 fuzz 时间。
对应图表	Table I（分支覆盖行）、Table VI（p 值）、Figure 5（24 小时覆盖增长曲线）

基线对比分析（为什么 FuzzAgent 更好）：

维度	内容
实验目的	解释 FuzzAgent 为什么在更少的 harness 数下实现更高覆盖
实验效果简述	OSS-Fuzz 在 OpenSSL 上因分配 152 个并行实例而突出，但 FuzzAgent 顺序执行。 PromptFuzz 生成了 11K 个 harness，但 87.42% 因语法/API 错误被淘汰，另 654 个贡献零唯一覆盖；FuzzAgent 仅用 330 个 harness 即胜出。 PromeFuzz 的全库摘要引入冗余噪音，LLM 已预训练于大量开源代码，过多上下文反而有害。FuzzAgent 按需检索知识避免此问题。字典/种子方面：FuzzAgent 平均参考 4.3 个相关项目 收集输入格式知识。
对应图表	Figure 14（项目关系图）、Figure 5

消融实验 — 字典与种子贡献：

维度	内容
实验目的	量化 FuzzAgent 自动生成的字典和种子对覆盖的提升
实验效果简述	空配置（无字典无种子）覆盖 106,772 分支。加入 OSS-Fuzz 字典/种子分别提升 2.0%/7.1%；加入 FuzzAgent 字典/种子分别提升 3.6%/13.1%。 说明 FuzzAgent 收集的字典和种子对覆盖有显著贡献。
对应图表	Table IV（字典/种子消融实验各库覆盖值与总增益百分比）

消融实验 — Coverage Analyzer 贡献：

维度	内容
实验目的	评估覆盖率分析指导（Coverage Analyzer）对覆盖提升的必要性
实验效果简述	去除 Coverage Analyzer 后，分支覆盖降至 146,508，相比标准设置（179,619）下降 18.5%。在 18 个库上，有覆盖率指导的 FuzzAgent 达到最高覆盖且稳定性最好。说明覆盖率反馈是进化流程的关键。
对应图表	Figure 5（有/无覆盖率指导的 24 小时增长曲线对比）

C. Effectiveness on Bug Detection

崩溃分类与人工验证：

维度	内容
实验目的	评估 FuzzAgent 检测真实库缺陷的能力以及崩溃分析准确率
实验效果简述	5 轮实验共上报 1098 个唯一崩溃（CASR 去重），其中 128 个被归类为候选库缺陷，其余为 harness 错误。4 名博士生手工验证每个候选（平均每 bug 约 2 小时），确认 108/128 个候选（84.38%）为真实库缺陷。20 个误报中：12 个源于 DeepSeek V3.2 未检索到相关 API 约束，8 个源于根因推理错误。将底层模型替换为 Claude Sonnet 4.6 后，14/20 个误报被正确重新分类为 harness 错误，说明瓶颈在于模型能力而非智能体设计。所有确认 bug 已提交上游至今 84 个获得维护者回复，78 个已被确认或修复。
对应图表	Table VII（详列 102 个库缺陷及其类型、状态、基线是否检测到）

基线的崩溃检测能力对比：

维度	内容
实验目的	对比基线系统的 bug 检测能力，并检查 FuzzAgent 是否漏检了基线能检出的 bug
实验效果简述	OSS-Fuzz 和 OSS-Fuzz-Gen 在 20 个库上未检测到任何真实库缺陷（全部为 harness 误报）。PromptFuzz 和 PromeFuzz 分别报告 26 和 21 个候选，人工验证后仅 5 个和 8 个为真实库缺陷（高误报率）。所有 5+8 个 bug 均已被 FuzzAgent 检测到，说明它们并非基线独有，而是多种 fuzzing 方法都能发现的常见漏洞。
对应图表	Table VII（每个缺陷标注 PromptFuzz/PromeFuzz 是否检测到 ✓/✗）

漏洞实际影响分析（libaom 案例）：

维度	内容
实验目的	评估检测到的漏洞是否具有真实安全影响，而非仅是浅层崩溃
实验效果简述	102 个库缺陷中，整数溢出（31）和缓冲区溢出（25）占主导。深入分析 libaom 的 21 个确认 bug：7 个可直接通过 libaom 自带命令行工具（aomenc/aomdec）用特制输入触发，无需自定义 harness。8 个缓冲区溢出中，1 个为任意写入原语：攻击者控制的索引逃逸出缓冲区边界，可用于写入任意地址。结合另一个信息泄露 bug（用于击败 ASLR），两个原语可组装为远程代码执行链，通过启用 SVC 功能的 AV1 编码路径可达。
对应图表	Table VII（libaom 第 66-86 行）

六、讨论：

统计方差：

维度	内容
实验目的	讨论库 fuzzing 中固有随机性的来源及其对评估的影响
实验效果简述	库 fuzzing 本身具有随机性，LLM 生成 harness 引入了第二个、通常更大的随机性源。 嵌套实验（Table V）量化了两种方差：LLM harness 生成造成的 CV（变异系数）远大于同一 harness 的 fuzzing 重试 CV。因此 PromeFuzz 等仅重复 fuzzing 阶段的协议不足以控制 LLM 随机性。FuzzAgent 对 harness 生成和 fuzzing 阶段各自独立重复 5 次。Mann-Whitney U 检验（Table VI）确认 FuzzAgent 的提升在大多数库-基线对上统计显著。
对应图表	Table V（方差量化）、Table VI（p 值）

误报分析：

维度	内容
实验目的	分析被维护者拒绝的 bug 报告的原因，指导未来改进方向
实验效果简述	108 个候选中有 84 个获得响应，78 个被确认/修复，6 个被拒绝。 原因：3 个属于"期望行为"（如 libvpx OOM 被解释为格式允许超大分辨率，环境内存不足正常）；2 个被承认是真问题但延后处理；1 个是 harness 端 API 误用未发现。分析表明未来应加强对 API 合约在真实条件下行为的理解。
对应图表	无

七、一些有的没的：

不足：

论文主要在 VI. DISCUSSION 和 VIII. CONCLUSION 中隐含提及了不足，并在 Ethical Considerations 中讨论了风险。明确表述的不足有以下几点：

1、 LLM 模型能力限制导致的误报（Section VI-B）

在 108 个候选 bug 中有 6 个被维护者拒绝，原因包括：3 个属于"期望行为"（如大分辨率下 OOM 是正常现象）、2 个被承认是问题但延后处理、1 个是 harness 端 API 误用。

在崩溃分析阶段，20 个误报中有 12 个源于 DeepSeek V3.2 未能检索到相关 API 约束，8 个源于错误的根因推理。替换为 Claude Sonnet 4.6 后能纠正 14/20 个误报，"说明瓶颈在于模型能力而非智能体设计"。

2、 统计方差问题（Section VI-A）

LLM 生成 harness 引入了比 fuzzing 自身更大的随机性（CV 约 10% vs. 1-5%），导致结果在不同运行间可能显著波动。论文为此采用了嵌套重复实验（5×5）来缓解，但无法完全消除。

3、特定场景的误报模式（Section VI-B）

部分被拒绝的报告属于"期望行为"或"范围外"，说明系统对库 API 合约在真实世界条件下的边界理解仍有欠缺。

4、双用途风险（Ethical Considerations）

系统全自动化特性在降低防御者门槛的同时，也降低了恶意攻击者的门槛。因此作者暂不开源（改为部署为受限服务）。

一些思考：

（deepseek分析生成，总之简单记录一下）

1. 提升崩溃分析的领域知识深度

当前 Crash Analyzer 主要依赖源代码检索和 GDB 调试来推断根因。对于"期望行为"误报（如 libvpx 的大分辨率 OOM），系统缺乏对库的设计意图、边界条件隐含合约的理解。

优化方向：引入 API 规范的正式化描述（如从文档注释中提取前置条件/后置条件），或利用已有测试套件中的断言来建立 API 行为的基线。

2. 降低 24 小时端到端的时间预算

论文以 24 小时为每库固定预算。但 Table II 显示，对于小型库（如 cJSON、zlib），Coverage Analyzer 和 Crash Analyzer 的时间占比并不低，部分时间可能用于不需要的深度探索。

优化方向：引入自适应终止机制——当覆盖增长率稳定低于阈值、且无新崩溃产生时，提前结束该库的流程，将算力重分配给其他库或更多轮迭代。

时间预算这里我觉得完全可以动态调整，我的想法是对于一些规模比较小的库比如已经确定代码行完全覆盖了可以提前终止，类似这样的思路动态分配资源，同样对于更值得探索的目标也可以适当增加时长，当然也需要给定一个最小的值

3. 跨库知识迁移

FuzzAgent 当前对每个库独立启动（从零开始）。但 Figure 14 显示库之间存在格式/协议的联系（如 libaom 和 libvpx 同为视频编解码）。

优化方向：构建库知识图谱，让在一个库上学到的 API 关系、harness 模式、字典词条跨库复用，减少重复的 Web 搜索和初始探索成本。

4. 评估指标的单一性

当前仅使用分支覆盖一个代码覆盖指标。对某些安全关键的库（如 OpenSSL 的密码学路径、protobuf 的协议解析器），分支覆盖可能无法充分反映路径覆盖的深度。

优化方向：补充路径覆盖（path coverage）、关键函数覆盖率（如安全检查函数、边界处理函数），或结合 FuzzIntrospector 的“未覆盖复杂度”评分来更细粒度地衡量覆盖质量。

5. 对非内存安全的 bug 检测

ASAN + UBSAN 主要捕获内存安全（越界、UAF、UB）问题，对逻辑错误（如加密跳过验证步骤、状态机非预期状态转移）不敏感。

优化方向：集成符号执行或轻量级行为断言，以检测逻辑层面的缺陷。不过这可能会大幅增加系统复杂度，需要权衡。

6. 结果的可复现性

论文明确表示因双用途风险暂不开源代码（仅发布测试集的 artifact）。从学术可复现的角度，这限制了社区对方法的验证和渐进式改进。

优化方向：在降低风险的前提下（如提供沙箱化容器镜像、限制某些危险 API 的调用），提供更开放的访问渠道。

八、附录信息

提示词：

这个部分主要放一点附录里面我比较感兴趣的信息，这里主要是关于提示词怎么设计的。

FuzzAgent 的核心设计机制——每个智能体由一段系统提示驱动，该提示包含三个部分：任务职责（做什么、成功的标准）、核心策略（调用工具时遵循的方法论）、少量示例。其中核心策略是最关键的设计部分。

Library Builder：

Role Definition

You are a resilient and expert Build Automation Engineer. Your goal is NOT just to write a script, but to guarantee a successful build that produces valid static (‘.a‘) libraries.

Core Responsibility

You are responsible for the entire BuildTest-Fix cycle.

1. Draft: Create the initial ‘build.sh‘.

2. Execute: Run the build using ‘ run_and_check_build_script‘.

3. Debug: If the build fails, YOU MUST ANALYZE THE LOGS, FIX THE SCRIPT, AND RETRY.

4. Deliver: Only exit when ‘$WORK/lib‘ contains the required artifacts.

5. CRITICAL: Do not exit simply because the build failed. A build failure is a demand for a fix, not a reason to quit.

Dictionary Generator：

Role Definition

You are the Dictionary Acquisition & Optimization Specialist. Your goal is to provide a lean, high-impact fuzzing dictionary. You must locate existing resources from the OSS-Fuzz repository--whether they are stored locally or downloaded dynamically---and rigorously prune them.

Discovery & Matching

1. Analyze Target: Determine the ** Protocol/Format** of the target project (e.g ., "It’s a Video Codec").

2. Search: Run ‘search_web list‘.

3. Select Source: - Exact Match: Target=‘libaom‘, OSSFuzz=‘libaom‘. - Protocol Match: Target=‘ my_video_lib‘, OSS-Fuzz=‘ffmpeg‘. - Select Criteria: All exact matched and protocol matched projects. Use tool ‘ track_web_retrieve_progress‘ to record matched projects waiting for retrieval. - Fallback: If no match found, create a minimal dictionary based on standard protocol knowledge.

Seed Generator:

Role Definition

You are the **Seed Corpus Acquisition Agent **. Your sole responsibility is to locate, download, and install high-quality fuzzing seed corpora for the target project.

Discovery & Matching

1. Analyze Target: Determine the ** Protocol/Format** of the target project (e.g ., "It’s a Video Codec").

2. Search: Run ‘search_web list‘.

3. Select Source: - Exact Match: Target=‘libaom‘, OSSFuzz=‘libaom‘. - Protocol Match: Target=‘ my_video_lib‘, OSS-Fuzz=‘ffmpeg‘. - Select Criteria: All exact matched and protocol matched projects. Use tool ‘ track_web_retrieve_progress‘ to record matched projects waiting for retrieval.

Harness Generator:

New Harness Generation Strategy

Coverage-guided Principles

Primary Objective: Generate a harness according CoverageAnalyzerAgent’s guides.

API Selection Strategy (in priority order):

1. Manager-Specified Targets: Always prioritize APIs explicitly mentioned in Manager specifications

2. Dependency Chain Completion: Include necessary helper functions for proper API initialization and cleanup

Coverage-Driven Design Rules:

• Call as many target APIs has dependencies **as possible to maximize coverage **

• Include input validation and error handling paths where possible - Implement necessary state setup for complex API sequences

• Ensure proper resource management ( allocation/deallocation patterns)

Coverage Analyzer: API-Surface Exploration:

Analysis Strategy

PHASE 1: Surface Coverage Exploration ( API Utilizaiton)

Trigger: High-value public APIs are untouched.

**Goal: Identify a group of related, uncovered APIs to guide the generation of a new, high-impact fuzzing harness**.

Workflow:

1. Select Targets: From the Module, File and API-Level coverage data, prioritize the APIs with the highest undiscovered complexity.

2. Group Clusters: Look for other uncovered APIs in the same files or modules that share a logical relationship (e.g., ‘ ArrayCreate‘, ‘ArrayInsert‘, ‘ArrayDelete‘).

3. Reason Relations: Reasoning relationships among identified APIs and thinking how to organize the related ones into an invocation sequence.

4. Analyze Dependencies: Complement the invocation sequence and determine the correct lifecycle:

• Initialization: What must be called first? (e.g., ‘Init‘, ‘New‘, ‘Parse‘)

• Operation: The target invocation sequence.

• Cleanup: What frees the memory? (e.g., ‘Free‘, ‘Destroy‘)

• Helpers: Do you need ‘CreateString‘ to test ‘DictionaryAdd‘?

5. Formulate Recommendation: Formulate these into a single harness request.

Coverage Analyzer: Deep Stated Exploration:

Analysis Strategy

PHASE 2: Deep Coverage (Blocker Resolution)

Condition: **Overall API coverage is high enough (API Coverage >= 90%) or the API coverage growth is stagnant. **

Trigger: Public APIs are hit, but internal functions and code branches are blocked.

Goal: Analyze the blocker cause and suggest a targeted harness to break this.

Workflow:

1. Identify Blocker: Inspect the Function Level and Branch Level coverage, pick the one with the highest "Blocked Complexity".

2. Trace Entry Point: Analyze the call chains on the function containing the blocker. Identify which Public API reaches this code.

3. Analyze Condition: Read the source code with coverage hits around the blocker. What condition is failing? Is this caused by unsatisfied API calls? If not, select the next blocker to analyze.

4. Formulate Recommendation: Instruct the HarnessAgent to create a specific scenario that satisfies this condition.

Crash Analyzer:

Role Definition

You are the Crash Analysis & Triage Specialist. Your sole purpose is to investigate a specific crash artifact, determine the "Blame" (Library Bug vs. Harness Bug), and file a formal report.

Core Mission

You act as a Judge. You have two suspects:

1. The Library: Did it fail to handle valid input safe? (Genuine Bug)

2. The Harness: Did it violate the API contract or manage memory poorly? (Invalid Bug)

Mandatory Workflow

Phase 1: **Forensics (Data Gathering) **

1. Receive the Crash Artifact Path (from user input).

2. Call ‘crash_initial_analysis‘ with the crash artifact path to get call traces.

3. Identify the "Crash Point": The topmost stack frame that belongs to the project (skip standard library frames like ‘libc.so‘ or ‘asan_report‘).

Phase 2: **Debugging (Runtime Information Gathering) **

1. Call ‘crash_context_inspection‘ on the suspect API or function to inspect the runtime context frames of this invocation.

2. Analyze the runtime context frames to identify the point of failure iteratively.

3. Read the file/documentation of the suspect API or function to verify the preconditions and postconditions.

4. Repeat the process until the point of failure is identified.

简单总结一下就是：

智能体	提示词核心策略（Figure 编号）	一句话概括
Library Builder	Figure 6	"构建-测试-修复"循环：写构建脚本 → 执行 → 分析失败日志 → 修复脚本 → 重试，直到产生有效的 .a 静态库。强调"失败不是退出理由，而是修复需求"
Dictionary Generator	Figure 7	Web 检索 + 裁剪：先判断目标库的协议/格式（如"这是一个视频编解码器"），再从 OSS-Fuzz 仓库或其他项目搜索匹配的字典，裁剪不适用的 token，组装为最终字典
Seed Generator	Figure 8	Web 检索 + 下载：同样通过协议/格式匹配，从 OSS-Fuzz 等来源下载种子文件，逻辑与 Dictionary Generator 类似
Harness Generator	Figure 9	覆盖率指导生成：按优先级调用目标 API → 补全依赖链（初始化、清理等）→ 最大化调用目标 API → 验证编译通过
Coverage Analyzer（API 表面探索）	Figure 10	分组关系推理：分析模块级和文件级覆盖数据 → 将未覆盖 API 按功能关系分组 → 推理组内 API 依赖 → 补充生命周期函数 → 形成 harness 建议
Coverage Analyzer（深层状态探索）	Figure 11	阻塞点突破：当 API 覆盖 ≥90% 或增长停滞时 → 定位未覆盖分支 → 跟踪调用链找到入口 API → 分析源代码中阻塞的条件 → 生成满足条件的场景
Crash Analyzer	Figure 12	法医调查流程：获取崩溃轨迹 → 定位属于目标库的顶层栈帧 → 调用 GDB 非交互模式检查运行时上下文 → 迭代调试直到确定根因 → 判断是库缺陷还是 harness 错误

理解这些提示词的关键洞察：

1、策略替代硬编码：以往工作（如 Hopper）将 API 关系推断写成固定规则，而 FuzzAgent 将领域知识编码为文本指令。例如 Coverage Analyzer 的"分组推理"不是用代码实现的聚类算法，而是告诉 LLM "寻找同一个文件中功能相关的未覆盖 API"。

2、角色扮演 + 迭代闭环：每个智能体被赋予一个专业角色（如"构建自动化工程师"、"崩溃分析与分类专家"），并明确告知必须循环工作（Build-Test-Fix），而非一次尝试就退出。这种角色定义利用了 LLM 在结构化任务中的表现优势。

3、接口充当"手脚"：提示词告诉智能体在什么情况下使用什么工具（如 search_web list、crash_context_inspection），但工具的具体实现细节被隐藏在 Interface 层。智能体只需要说"我想检索相关项目"而不需要知道 GitHub API 的调用格式。

4、两阶段覆盖率分析：Coverage Analyzer 的提示词设计体现了分层进化思想——先广度（覆盖尽可能多的 API），再深度（突破具体阻塞分支）。这种策略性区分是 FuzzAgent 在仅用 330 个 harness 就击败 PromptFuzz 11K 个 harness 的关键原因

实用项目：

这里会提及一些项目里直接提及的工作，或许可以直接复用的部分：

有关框架部分：

项目	论文中作用	地址
AFL++	所有实验使用的 fuzzer 引擎	GitHub
OSS-Fuzz	基线系统之一，工业级持续 fuzzing 平台	GitHub
LibFuzzer	论文背景中提及的经典库 fuzzing 工具	LLVM 文档

覆盖率分析工具：

项目	论文中作用	地址
llvm-cov	基于源码的代码覆盖测量工具	LLVM 文档
FuzzIntrospector	覆盖率层级分析的设计灵感来源，用于组织项目→模块→文件→API→分支的覆盖层级	GitHub

崩溃调试与分析工具：

项目	论文中作用	地址
CASR	崩溃去重与上下文分析：自动关联 crash trace 与对应源码片段	GitHub
GDB	非交互式批处理模式用于复现崩溃和检查运行时状态	GDB 文档

编译与插桩工具：

项目	论文中作用	地址
ASAN (AddressSanitizer)	内存安全检测（越界、UAF 等）	LLVM 文档
UBSAN (UndefinedBehaviorSanitizer)	未定义行为检测	LLVM 文档
MSAN (MemorySanitizer)	未初始化内存读取检测	LLVM 文档
wllvm	用于提取 LLVM bitcode 以支持部分插桩需求	GitHub

多智能体与工具框架：

项目	论文中作用	地址
SWE-Agent	FuzzAgent 的计算机使用接口（File 操作工具）直接改编自 SWE-Agent	GitHub
GitHub REST API	Web Search Interface 的底层实现，用于检索 OSS-Fuzz 仓库中的字典和种子	GitHub Docs

论文评估使用的 20 个目标库：

库名	版本（commit）	地址
libaom	16a97	GitHub
OpenSSL	c8b4a	GitHub
OpenCV	01f9b	GitHub
protobuf	b56a4	GitHub
SQLite3	db4d8	SQLite 源码
cJSON	b2890	GitHub
libpng	7c67f	GitHub
libjpeg-turbo	466c3	GitHub
curl	e8415a

实验结果数据：https://github.com/FuzzAnything/FuzzAgent-Artifacts，但是项目没有开源。