DeepAudit AI多智能体代码审计项目学习与解读（二）

本篇内容主要探讨DeepAudit 中的多智能体架构

多智能体代码审计流程

在/api/v1/agent-tasks/端点创建后台Agent审计任务

审计任务的进行是在_execute_agent_task中进行的

通过指定sub_agents参数去形成agent层次结构

DeepAudit多智能体实现

前面已经知道DeepAudit中的多智能体架构是：

Orchestrator Agent
    ├── Recon Agent
    ├── Analysis Agent
    └── Verification Agent

以上的agent都继承自backend/app/services/agent/agents/base.py中的BaseAgent

base.py

agent枚举：

运行模式枚举：

Agent协作（TaskHandoff）：

BaseAgent基类：

关键函数：

• • _register_to_registry：将 Agent 注册到全局 Agent 注册表并创建消息队列用于 Agent 间通信，这个消息队列存放在全局的消息队列字典中（agent_id-->message）
• • set_parent_id：设置父agent
• • _load_knowledge_modules：加载知识库
• • send_message_to_parent：发送message给父Agent
• • send_message_to_agent：发送message给指定agent
• • receive_handoff：接收前序Agent的执行结果，为TaskHandoff对象
• • get_handoff_context：从前序Agent的执行结果获取Context
• • build_prompt_with_handoff：基于获取的Context构建提示词
• • create_handoff：创建任务交接TaskHandoff对象
• • stream_llm_call：LLM流式调用
• • execute_tool：执行工具的方法
• • get_tools_description：获取工具的描述

生命周期函数：

• • on_start：agent启动时调用
• • on_complete：agent完成任务时调用，保存结果，如果有父agent就还要将结果报告给父agent
• • on_error：出错时调用
• • run：执行具体的agent，任何继承自BaseAgent的Agent都需要实现这个方法
• • cancel：取消agent的执行

核心事件发射方法：诸如emit_thinking、emit_llm_start这些事件用于向前端发送agent的执行过程

在OrchestratorAgent的run中会在一个循环中执行Agent的编排任务：

结果返回：

现在详细看看迭代的处理（第一次迭代是基于）：

调度子agent是基于_dispatch_agent去实现的，不断汇总结果其实就是在每一次迭代时对_all_findings的不断填充。

_dispatch_agent基于step.action_input去选择要调度的agent：

运行子agent：

处理结果，最终的结果会被填充到observation并返回：

recon Agent

与OrchestratorAgent类似，同样在迭代中完成llm的流式调用：

使用_parse_llm_response解析step：

基于step.action调用工具：

工具调用后会处理输出再返回：

在完成迭代后还会进行一次LLM流式调用进行总结：

verification Agent

verification Agent又存在一些不同，首先获取交接信息

收集所有的待验证漏洞：

有意思的是我发现在这里他对待验证的漏洞数量进行了截断：

基于findings_to_verify初始化对话历史：

后续流程与Recon 类似

analysis Agent

流程与verification 类似

Agent的工作流程汇总

每个agent都有以下关键的变量和函数：

• • xxx_SYSTEM_PROMPT：非常长的系统硬编码提示词，_conversation_history初始化时会使用
• • _parse_llm_response()：解析每次迭代时进行的流式llm调用输出，得到Step
• • Step.action：决定当前迭代流式调用后如何进行后续处理
• • Orchestrator：调度agent、输出报告、不断汇总发现的漏洞
• • Recon：根据action去调用工具去做信息收集
• • analysis：根据action去调用工具去做漏洞分析
• • verification：根据action去调用工具去做漏洞验证
• • _conversation_history：存放对话历史，agent运行时都需要初始化后才进行LLM迭代，后续每次迭代动态添加

完整的agent工作流程其实就是首先调用Orchestrator，然后在迭代中根据LLM的输出提取Step以做出后续决策，一旦决策要求调度子agent，就会调度对应的子agent在迭代中完成特定的任务（工具的调用也都发生在子agent中），直到Orchestrator发现审计完成然后输出报告。

总结

• • 项目中存在较多的提示词硬编码和提示词拼接情况，让代码显得比较繁琐
• • 不是每个agent都使用 TaskHandoff 传递结构化上下文，比如Orchestrator和Recon，agent之间的数据传递一部分使用了参数传递，一部分使用了 TaskHandoff ，可能会造成一些冗余

下一篇将探讨DeepAudit中的知识库。