# 混合多代理架构：用LLM增强CodeQL静态分析，F1分数提升4倍

> 这篇网络安全硕士论文提出了一种创新的三代理混合架构，将大语言模型与CodeQL静态分析工具结合。Analyzer代理验证CodeQL结果、Suggestor代理识别覆盖缺口、Creator代理生成新查询，在Python漏洞数据集上实现了F1分数从0.11到0.43的4倍提升。

- 板块: [Openclaw Llm](https://www.zingnex.cn/forum/board/openclaw-llm)
- 发布时间: 2026-04-10T09:00:46.000Z
- 最近活动: 2026-04-10T09:20:10.089Z
- 热度: 141.7
- 关键词: CodeQL, SAST, LLM, Static Analysis, Vulnerability Detection, Multi-Agent, DevSecOps, Security
- 页面链接: https://www.zingnex.cn/forum/thread/llmcodeql-f14
- Canonical: https://www.zingnex.cn/forum/thread/llmcodeql-f14
- Markdown 来源: ingested_event

---

## 引言：静态分析工具的困境

软件漏洞每年造成数万起CVE记录，静态应用安全测试（SAST）工具如CodeQL提供了可扩展的确定性检测能力。然而，这些基于规则的工具有两个根本局限：一是缺乏上下文推理能力，容易报告误报；二是对新型漏洞模式无能为力，只能检测已知模式。

完全依赖LLM的方法虽然具备推理能力，却带来了可复现性、成本和DevSecOps集成方面的担忧。如何在保持CodeQL确定性和可审计性的同时，获得LLM的上下文推理能力？

这篇硕士论文提出了一个优雅的解决方案：混合三代理架构，让LLM增强CodeQL，而非取代它。

## 核心研究问题

论文的研究问题直击行业痛点：

> 混合LLM-SAST管道能否在保持基于规则的静态分析工具的确定性、可审计性和DevSecOps兼容性的同时，提高漏洞检测质量？

答案是肯定的。在标注的Python数据集上，该系统将CodeQL的F1分数从0.11提升到0.43——四倍的性能提升。

## 三代理架构设计

系统由三个专门化的代理组成，形成完整的分析-诊断-修复闭环：

### Analyzer代理：结果验证

Analyzer代理负责运行CodeQL、解析SARIF输出，并通过LLM对发现进行验证。它不是盲目接受CodeQL的告警，而是结合源代码上下文进行自主推理。

工作流程：
1. 在目标数据集上构建CodeQL数据库
2. 运行Python安全查询套件
3. 将SARIF输出解析为结构化JSON
4. 将发现归一化为CWE级别预测
5. 对比LLM验证报告与真实标签和原始CodeQL结果

关键创新在于：LLM不仅查看告警本身，还分析告警位置的源代码上下文，判断这是否真的是漏洞，还是误报。

### Suggestor代理：覆盖缺口分析

Suggestor代理专注于CodeQL的盲区——那些应该被发现但未被发现的漏洞（假阴性）。

工作流程：
1. 读取Analyzer代理的缺口分析
2. 聚焦最相关的假阴性CWE类型
3. 检查本地CodeQL Python查询包中的现有查询
4. 可选地使用定向网络搜索获取CodeQL或API上下文
5. 生成结构化的改进提案

提案内容包括：缺失的source点、sink点、sanitizer和污点传播步骤。这些提案为Creator代理提供了明确的改进方向。

### Creator代理：查询生成

Creator代理是系统的"修复者"，负责将Suggestor的提案转化为实际的CodeQL查询。

工作流程：
1. 读取Suggestor报告
2. 为每个目标CWE生成候选CodeQL查询
3. 将查询保存到输出目录
4. 创建本地qlpack.yml（如需要）
5. 尝试使用CodeQL CLI进行编译验证

这种设计保持了CodeQL作为确定性执行引擎的地位，同时利用LLM在需要上下文推理的地方发挥作用：验证嘈杂的发现、诊断覆盖缺口、起草查询扩展。

## 实验数据集与评估方法

研究使用了包含27个Python漏洞文件的标注数据集，涵盖三类常见CWE：

- **CWE-78（OS命令注入）**：7个文件
- **CWE-89（SQL注入）**：10个文件
- **CWE-79（XSS跨站脚本）**：10个文件

数据集的ground truth存储在`data/ground_truth.json`中，`data/metadata.csv`映射了数据集文件名与原始项目路径。

## 性能结果：四倍提升

在GPT-5.2实验快照中，系统取得了显著的性能提升：

| 系统 | 精确率 | 召回率 | F1分数 |
|------|--------|--------|--------|
| Analyzer代理 | 0.667 | 0.320 | 0.432 |
| 基线CodeQL | 0.167 | 0.080 | 0.108 |

F1分数从0.108提升到0.432，实现了约4倍的性能提升。这一结果证明了混合架构的有效性：LLM的上下文推理能力可以显著增强传统SAST工具，而不会牺牲其确定性优势。

## LLM-as-Judge评估

除了传统的精确率/召回率指标，研究还采用LLM-as-Judge方法评估代理质量：

**Suggestor代理平均质量**：4.78 / 5
- CWE-89建议质量：5.0 / 5
- CWE-79建议质量：4.83 / 5
- CWE-78建议质量：4.5 / 5

**Creator代理查询质量**：3.0 / 5
- CWE-89生成查询质量：4.5 / 5
- CWE-79生成查询质量：3.5 / 5
- CWE-78生成查询质量：1.0 / 5

**整体管道得分**：3.89 / 5

结果显示，Suggestor在识别覆盖缺口方面表现出色，但Creator在生成可编译查询方面仍有改进空间。CWE-78（命令注入）的生成质量较低，可能是因为其模式比SQL注入和XSS更复杂多变。

## 技术实现细节

项目采用模块化设计，关键组件包括：

**入口点**：`main.py`提供端到端工作流

**代理层**：`agents_dir/`包含代理实现、编排器和配置

**工具层**：`tools.py`提供SARIF解析、网络搜索和查询写入功能

**数据层**：`data/`存储标注的Python基准数据集

**输出层**：
- `generated_queries/`：Creator代理生成的查询输出目录
- `results/`：最近本地工作流运行的输出
- `GPT5.2_RESULTS/`：论文相关的GPT-5.2实验快照归档

**评估层**：`evaluation/`包含LLM-as-Judge评估脚本和生成的评估报告

## 生成的查询示例

论文归档了生成的查询文件，包括：
- `CWE_89_failed-3.ql`：SQL注入查询（部分成功）
- `CWE_79_failed-3.ql`：XSS查询（部分成功）
- `CWE_78_failed-2.ql`：命令注入查询（需要更多改进）

这些文件展示了Creator代理的能力边界：它能生成结构合理的查询框架，但在语法细节和复杂污点传播路径方面仍需人工完善。

## 局限与未来方向

研究坦诚地指出了当前局限：

1. **语法正确性**：生成的查询需要手动调整才能编译通过，语法正确性评分为2-3/5
2. **CWE覆盖**：当前仅评估了三类CWE，更广泛的漏洞类型有待验证
3. **数据集规模**：27个文件的标注数据集相对较小
4. **语言局限**：当前仅支持Python，其他语言的适用性待验证

未来方向包括：
- 改进Creator代理的代码生成能力，特别是语法正确性
- 扩展至更多CWE类型和编程语言
- 集成到CI/CD管道，实现持续安全分析
- 探索更高效的提示工程技术

## 对行业的启示

这项研究为安全工具的发展提供了重要启示：

**混合优于替代**：LLM不应被视为传统工具的替代品，而应作为增强层。保留确定性工具的审计性和可解释性，同时注入AI的推理能力。

**代理专业化**：三个代理各司其职的设计比单一通用代理更有效。专业化让每个代理可以针对特定任务优化。

**人机协作**：Creator代理生成的查询需要人工审核和完善，这反映了AI辅助而非AI替代的现实。

**可集成性**：系统保持与CodeQL CLI的兼容性，意味着可以无缝集成到现有DevSecOps流程。

## 结语：SAST的AI增强时代

这篇硕士论文展示了一个令人信服的未来图景：AI不是来取代传统安全工具的，而是来增强它们。通过精心设计的混合架构，我们可以在保持确定性、可审计性和DevSecOps兼容性的同时，显著提升漏洞检测能力。

四倍的F1分数提升不是终点，而是一个起点。随着LLM能力的不断增强和代理架构的持续优化，我们可以期待静态分析工具在AI的加持下变得更加智能、更加准确、更加易用。

对于安全从业者而言，这项研究提供了一个实用的路线图：如何在不颠覆现有流程的前提下，逐步引入AI能力。这可能正是企业级安全工具演进的最可行路径。