文章总结： 本文拆解了DeepAudit代码审计项目，阐述了让LLM作为决策者的ReAct模式架构。总结了六大设计原则：自主决策、分层Agent协作、RAG与外部工具优先、领域知识注入及防幻觉机制。文章指出多Agent协作与严格验证能提升审计准确性，建议构建LLM安全工具时遵循专业工具优先及验证后报告的原则。 综合评分： 90 文章分类： AI安全,代码审计,安全工具,安全开发
拆解DeepAudit（一）：当LLM学会“思考”
sec0nd安全
2026年2月4日 22:37 北京
以下文章来源于REDLINE Lab ，作者Lab
REDLINE Lab .
吾心光明，本自具足
这周花了些时间读 DeepAudit 的源码，记录下发现的一些设计思路。
为什么看这个项目
最近在琢磨怎么给 LLM 加上”自主决策”的能力，不是那种写死流程让它跑，而是让它自己判断下一步做什么。
翻了几个开源项目，DeepAudit 的设计比较对胃口：
- 它做的是代码安全审计，不是简单的问答，需要 LLM 去”理解”代码
- 用了 Multi-Agent 架构，不是单个 Agent 硬扛
- 有防幻觉机制，这个很实用
跑了下 cloc，后端差不多 3 万行 Python。Agent 系统占了一半左右，2 万多行，说明这是整个项目的核心。
项目结构
先画个简图：
Frontend (React) │ ▼ SSEBackend (FastAPI) ├── Agent System (~2.5万行) ├── RAG System (~3600行) ├── LLM Adapters (~3500行) └── Sandbox (Docker) │ ▼PostgreSQL / ChromaDB / Redis
LLM 适配层支持十几个厂商，OpenAI、Claude、文心、豆包这些都接了。工具目录有 17 个 Agent 工具，从文件读写到沙箱执行都有。
核心设计：让 LLM 自己决定做什么
看源码时注意到一个设计思路：
LLM 不是执行者，是决策者。
传统扫描器的逻辑是写死的：
def scan_project(path): files = find_python_files(path) for file in files: check_sql_injection(file) check_xss(file) return results
步骤固定，没有”思考”。
DeepAudit 用的是 ReAct 模式，核心循环大概是这样：
for iteration in range(max_iterations): # LLM 思考：现在该做什么？ llm_output = await self.stream_llm_call(history) step = self._parse_llm_response(llm_output) if step.is_final: return step.final_answer # 执行 LLM 选的工具 observation = await self.execute_tool(step.action) history.append(observation)
每一步都是 LLM 在决定：用哪个工具、做什么事、什么时候结束。没有硬编码的 if-else。
这样设计的好处是灵活，不同项目、不同技术栈，Agent 可以自己调整策略。代价是不确定性增加，还有幻觉风险。
六个设计原则
翻完源码，总结了六个设计原则：
1. LLM 自主决策
前面说了，核心是 ReAct 循环。实现在 agents/base.py。
2. 层级 Agent 协作
没用一个”超级 Agent”，而是拆成四层：
Orchestrator (调度) ├── Recon (侦察) ├── Analysis (分析) └── Verification (验证)
每个 Agent 只管自己那摊事，通过 TaskHandoff 传递上下文：
@dataclassclass TaskHandoff: from_agent: str to_agent: str context: str findings: List[str] suggestions: List[str]
3. RAG 优先
System Prompt 里明确写了工具优先级：
首选：rag_query / security_search / function_context次选：search_code最后：read_file
原因是安全审计需要语义理解。比如”找处理用户输入的函数”，grep 只能搜关键词，RAG 能理解语义找到 sanitize_data() 这种函数。
4. 外部工具优先
顶层：Semgrep / Bandit / Gitleaks中层：Smart Scan底层：内置分析
Prompt 里写着 “ALWAYS use external security tools BEFORE internal analysis”。让专业工具干专业的事，LLM 负责理解和整合。
5. 领域知识注入
有个 knowledge 目录：
knowledge/├── frameworks/ (django, flask, fastapi...)└── vulnerabilities/ (injection, xss, ssrf...)
这些知识注入到 System Prompt，让 LLM 变成安全专家。
6. 防幻觉机制
这个设计我觉得很值得学。system_prompts.py 里定义了验证规则：
FILE_VALIDATION_RULES = """1. FILE_EXISTS: 先验证文件存在2. CODE_VERIFIED: 代码片段必须来自实际读取3. LINE_ACCURATE: 行号必须准确4. TECH_MATCH: 技术栈要匹配"""
还有禁止行为：
❌ 报告未验证存在的文件❌ 猜测行号❌ 不读代码就假设模式❌ 不调用工具就给结论
简单说就是”验证后再报告”。
设计层次
把这六个原则画成金字塔：
┌──────────────┐ │ LLM 自主决策 │ ← 决策范式 └───────┬──────┘ ┌──────┴──────┐ │ 多Agent协作 │ ← 协作模式 └──────┬──────┘ ┌───────────┴────────────┐ │ RAG优先 / 外部工具优先 │ ← 执行策略 └───────────┬────────────┘ ┌───────────────┴───────────────┐ │ 领域知识注入 + 防幻觉机制 │ ← 质量保障 └───────────────────────────────┘
从上到下，每一层都为上一层提供支撑。
小结
看这个项目主要学到几点：
- 让 LLM 做决策者，不是执行者
- 复杂任务拆成多个 Agent
- 搜索代码优先用 RAG
- 借力专业工具
- 防幻觉是刚需
下一篇准备拆解四层 Agent 的调度机制，看看 Orchestrator 是怎么调度 Recon、Analysis、Verification 的。
项目地址：https://github.com/lintsinghua/DeepAudit
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：sec0nd安全 《拆解DeepAudit（一）：当LLM学会“思考”》
版权声明
本站仅做备份收录，仅供研究与教学参考之用。
读者将信息用于其他用途的，全部法律及连带责任由读者自行承担，本站不承担任何责任。
评论