多智能体LLM漏洞发现架构：规划、分析与验证Agent的分工协作机制

引言：从单模型到多 Agent 协作的演进

传统基于 LLM 的漏洞发现往往依赖单一模型完成代码分析、漏洞推理与 PoC 生成的全链条任务，这种模式在复杂代码库面前暴露出上下文窗口限制、推理深度不足以及幻觉问题。多智能体架构通过角色专业化与协作机制，将单一任务拆解为由不同 Agent 分工执行的子流程，在 Co-RedTeam 等最新研究中已展现出显著的性能提升。

本文聚焦于三核心 Agent 的分工机制 —— 规划 Agent 负责任务分解与执行路径设计、分析 Agent 执行深度代码审查与漏洞假设生成、验证 Agent 通过沙箱执行确认漏洞可利用性。这一架构设计不仅提升了漏洞发现的准确率，更实现了从静态分析到动态验证的端到端自动化闭环。

核心架构：三 Agent 分工模型

规划 Agent（Planner）：战略层任务编排

规划 Agent 是整个协作流程的战略中枢，其核心职责在于将高层次的漏洞发现目标转化为可执行的步骤序列。与单一 LLM 的端到端生成不同，规划 Agent 维护一个显式的 "利用计划"（Exploit Plan）数据结构，包含步骤目标、当前状态、依赖关系与回滚策略。

在工程实现中，规划 Agent 需要具备以下能力：

• 任务分解策略：将 "发现某类漏洞" 拆解为 "代码扫描→攻击面识别→输入源追踪→Sink 点分析→利用链构建" 的递进式子任务
• 动态重规划：当验证 Agent 反馈执行失败时，规划 Agent 需基于错误类型（如路径不可达、过滤绕过失败）调整后续步骤
• 资源调度：协调分析 Agent 的代码浏览工具调用频率，避免 API 速率限制或上下文溢出

规划 Agent 的 Prompt 设计应包含安全领域知识库引用接口，使其能够检索历史成功案例中的相似漏洞模式，指导当前任务的优先级排序。

分析 Agent（Analyzer）：战术层深度审查

分析 Agent 承担最重的认知负荷，负责执行细粒度的代码分析与漏洞假设生成。其工作模式区别于传统的静态分析工具 —— 分析 Agent 通过代码浏览工具（Code Browser）主动探索代码库，构建 "证据链"（Evidence Chain）来支撑漏洞假设。

证据链的结构化表示包含三个关键要素：

1. 输入源定位：识别用户可控的输入入口（HTTP 参数、文件上传、环境变量等）
2. 传播路径追踪：分析数据流从 Source 到 Sink 的完整传播路径，标记 sanitization 检查点
3. Sink 点脆弱性确认：验证目标 Sink 是否存在足够的安全控制缺失

分析 Agent 的输出并非简单的漏洞存在性判断，而是一个带有置信度评分的结构化草案（Vulnerability Draft）。这一设计为后续的 Critique Agent 审核提供了可审计的决策依据。

验证 Agent（Validator）：执行层确认与反馈

验证 Agent 是连接静态分析与动态测试的关键桥梁，其核心职责是在受控沙箱环境中执行分析 Agent 提出的利用假设，并返回结构化的执行结果。验证 Agent 的设计必须满足安全性与可观测性的双重要求。

验证 Agent 的工作流程包含三个环节：

前置安全审查：在代码执行前，验证 Agent 对 Payload 进行静态扫描，检测是否包含危险系统调用、网络外连或文件系统越界访问。这一环节通过策略规则与 LLM 判断的混合模式实现，既保证覆盖度又降低误报。

沙箱执行监控：利用容器化隔离环境（如 Docker 或 gVisor）运行目标应用，注入分析 Agent 生成的测试输入，捕获应用响应、异常堆栈与系统调用序列。执行超时通常设置为 30-60 秒，防止资源耗尽型攻击影响基础设施。

结果结构化输出：验证 Agent 将执行结果转化为标准化反馈格式，包含 "成功 / 失败 / 不确定" 的状态标记、错误分类（如 WAF 拦截、输入验证、逻辑错误）以及建议的下一步动作（重试、调整 Payload、放弃当前路径）。

协作机制：Orchestrator 的协调作用

三 Agent 的高效协作依赖于中央协调器（Orchestrator）的统一调度。Orchestrator 并非简单的消息转发器，而是具备状态机管理能力的工作流引擎。

Orchestrator 的核心职责包括：

• 阶段路由：根据当前任务状态决定进入 "发现阶段"（Discovery）或 "利用阶段"（Exploitation）。当已有明确的漏洞描述时，直接跳转至利用阶段；否则先执行发现流程
• Agent 生命周期管理：初始化 Agent 实例、注入上下文信息、监控执行超时、处理异常中断
• 消息过滤与转换：在不同 Agent 间传递信息时，执行敏感内容脱敏（如系统 Prompt 隐藏）与格式标准化

在通信协议设计上，建议采用结构化的消息 Schema：

{
  "message_id": "uuid",
  "sender_role": "planner|analyzer|validator",
  "receiver_role": "...",
  "content_type": "task_assignment|analysis_result|execution_feedback",
  "payload": {...},
  "metadata": {
    "timestamp": "...",
    "retry_count": 0,
    "priority": "high|normal|low"
  }
}

长期记忆系统：知识沉淀与复用

多 Agent 架构的优势不仅体现在并行处理能力，更在于通过长期记忆实现跨任务的知识积累。Co-RedTeam 框架采用三层记忆架构：

漏洞模式记忆（Vulnerability Pattern Memory）：存储已验证的漏洞类型特征、代码指纹与利用技术。当分析 Agent 遇到相似代码结构时，可检索历史成功案例指导当前分析。

策略记忆（Strategy Memory）：记录不同场景下有效的任务分解策略与 Agent 协作模式。例如，针对 Web 应用与二进制程序的漏洞发现，最优的 Agent 调用序列存在显著差异。

技术动作记忆（Technical Action Memory）：保存具体的工具调用参数与执行结果映射关系。这有助于验证 Agent 在面对相似执行环境时快速复用经过验证的配置。

记忆的检索与更新通过嵌入向量（Embedding）实现相似度匹配，确保 Agent 在上下文窗口有限的情况下仍能访问相关历史经验。

可落地的工程参数

基于上述架构设计，以下参数可作为实现多智能体漏洞发现系统的工程基准：

在错误处理方面，建议实现分级降级策略：当验证 Agent 连续失败时，首先降低 Payload 复杂度（如从 RCE 降级至信息泄露），其次切换分析 Agent 的代码浏览策略（如从数据流分析切换至控制流分析），最后才触发人工介入流程。

总结

多智能体 LLM 架构通过规划、分析、验证三 Agent 的分工协作，有效解决了单一模型在漏洞发现任务中的能力瓶颈。规划 Agent 提供战略层面的任务编排，分析 Agent 执行战术层面的深度代码审查，验证 Agent 通过沙箱执行完成可利用性确认。Orchestrator 的协调作用与长期记忆系统的知识沉淀，进一步增强了系统的可扩展性与持续学习能力。

对于安全团队而言，这一架构不仅提升了漏洞发现的自动化水平，更重要的是建立了可审计、可复现的分析流程。随着 LLM 能力的持续演进，多智能体协作模式有望成为安全测试领域的主流工程实践。

参考来源

• Co-RedTeam: Orchestrated Security Discovery and Exploitation with LLM Agents (arXiv:2602.02164)
• Red-Teaming LLM Multi-Agent Systems via Communication Attacks (ACL 2025 Findings)

security