DeepAudit AI多智能体代码审计项目学习与解读（四）
本篇主要探讨DeepAudit中的工具
工具基类（base.py）
工具位于app/services/agent/tools下，所有工具继承自 AgentTool 基类（app/services/agent/tools/base.py），在前面的文章中已经知道，agent会使用app/services/agent/agents/base.py中的execute_tool去调用工具：
Agent如何调用工具
对于recon agent，其输入是step的的action和action_input字段
- action：要调用的工具名
- action_input：要调用工具的入参
由LLM结合_parse_llm_response结构化输出的结果就是step：
值得注意的是，Step这样的类在各个agent中尤其是调用工具的agent中并没什么不同
数据类
前面已经知道了各个Agent中的Step会提供工具的输入，而工具的结构化输出由基类中的ToolResult决定:
必须实现的方法
基于AgentTool工具基类实现自定义工具必须实现以下方法：
-
name:
-
description
-
_execute
工具加载（LLM加载工具描述）
前面知道工具的调用会基于step去做，但是LLm还需要知道有哪些工具以及这些工具可以做什么才知道应该调用什么工具，在DeepAudit中是通过Agent初始化对话历史时加入所有工具描述实现的：
工具
工具数量很多，随便看看就行
-
基础文件操作工具
-
FileReadTool: 读取项目中的文件内容，支持读取特定行范围，避免输出过长
-
FileSearchTool: 在项目代码中搜索关键字或模式，支持正则表达式和文件名模式
-
ListFilesTool: 列出目录中的文件，支持递归和文件名模式匹配
-
-
代码分析与扫描工具
-
CodeAnalysisTool: 代码分析工具
-
DataFlowAnalysisTool: 数据流分析工具
-
SmartScanTool: 智能扫描工具
-
QuickAuditTool: 快速审计工具
-
PatternMatchTool: 模式匹配工具
-
RAGQueryTool: RAG知识库查询工具
-
SecurityCodeSearchTool: 安全代码搜索工具
-
FunctionContextTool: 函数上下文分析工具
-
-
专业安全扫描工具
-
SemgrepTool: 多语言静态分析工具，支持30+种编程语言
-
BanditTool: Python专用安全扫描工具
-
GitleaksTool: 密钥泄露检测工具，检测硬编码密钥、密码等
-
SafetyTool: Python依赖漏洞扫描工具
-
NpmAuditTool: Node.js项目依赖漏洞扫描工具
-
TruffleHogTool: 密钥和凭证检测工具
-
OSVScannerTool: 开源漏洞扫描工具
-
KunlunMTool: PHP和JavaScript语义分析工具
-
-
漏洞验证与测试工具
-
SandboxTool: Docker沙箱工具，提供隔离环境执行代码
-
SandboxHttpTool: 沙箱HTTP测试工具
-
VulnerabilityVerifyTool: 漏洞验证工具
-
CommandInjectionTestTool: 命令注入漏洞测试工具
-
SqlInjectionTestTool: SQL注入漏洞测试工具
-
XssTestTool: XSS漏洞测试工具
-
PathTraversalTestTool: 路径遍历漏洞测试工具
-
SstiTestTool: 模板注入漏洞测试工具
-
DeserializationTestTool: 反序列化漏洞测试工具
-
UniversalVulnTestTool: 通用漏洞测试工具
-
-
多语言代码测试工具
-
PhpTestTool: PHP代码测试工具
-
PythonTestTool: Python代码测试工具
-
JavaScriptTestTool: JavaScript代码测试工具
-
JavaTestTool: Java代码测试工具
-
GoTestTool: Go代码测试工具
-
RubyTestTool: Ruby代码测试工具
-
ShellTestTool: Shell脚本测试工具
-
UniversalCodeTestTool: 通用代码测试工具
-
-
Agent协作与流程控制工具
-
CreateSubAgentTool: 创建子Agent工具
-
SendMessageTool: 发送消息工具
-
ViewAgentGraphTool: 查看Agent图工具
-
WaitForMessageTool: 等待消息工具
-
AgentFinishTool: Agent完成工具
-
RunSubAgentsTool: 运行子Agent工具
-
CollectSubAgentResultsTool: 收集子Agent结果工具
-
ThinkTool: 思考工具，允许Agent进行内部思考
-
ReflectTool: 反思工具，用于自我评估
-
-
代码执行与功能提取工具
-
RunCodeTool: 通用代码执行工具
-
ExtractFunctionTool: 函数提取工具
-
-
报告与输出工具
-
CreateVulnerabilityReportTool: 创建漏洞报告工具
-
FinishScanTool: 扫描完成工具
- 漏洞验证工具(沙箱)
- VulnerabilityValidationTool: 漏洞验证工具
-
代码审计的工具调用分析
接下来探讨DeepAudit代码审计过程中的工具调用是否存在问题。
-
Recon调用了list_files、semgrep_scan、gitleaks_scan、npm_audit、 osv_scan、rag_query、search_code、think，Recon工具：
由于扫的是java+nodejs项目，明确用于python的工具没有使用，而Gitleaks和trufflehog_scan这两种工具只调用了前者，尽管trufflehog_scan的工具描述建议与Gitleaks搭配使用：
-
Analysis调用了read_file、semgrep_scan、gitleaks_scan、smart_scan、pattern_match、dataflow_analysis、 security_search、search_code、think、reflect，有三种没调用
可以发现dataflow_analysis调用出现了错误，但是缺少重试，或调整超时时间：
-
Verification调用了read_file、run_code，其他工具均未调用，而Verification的工具超过20个，有意思的是我发现在使用run_code验证java 路径穿越漏洞时失败了，但是它使用python去模拟了这个路径穿越的过程，函数使用的也是python的函数，乐：
-
Orchestrator未调用任何工具，think、reflect均未被调用
总结
-
涉及到工具调用的Agent会在初始化LLM对话历史时将所有的工具描述加载，Recon拥有12种工具，analysis拥有13种工具，verification更是拥有超过20种工具，如此多的工具描述会增加token消耗，同时，Agent可能无法正确推理出应该调用哪些工具，所以重点是要实现工具的按需加载，Skill或许是一个不错的选择
-
如果无法按需加载，尽量保证一个Agent只拥有3-5个工具，拥有过多工具的Agent最好拆分为多Agent
-
缺少要求工具必须执行和执行失败进行一定次数重试或尝试修改超时时间的机制，直接集成到CI/CD会出现问题，比如思考和反思对应的工具缺少必须执行的机制，像thinkTool仅在Recon和Analysis中使用了，Orchestrator每次迭代时都进行思考和反思会不会更好
DeepAudit的系列文章到此为止，项目整体可圈可点，最后感谢开源：https://github.com/lintsinghua/DeepAudit