528 lines
26 KiB
Markdown
528 lines
26 KiB
Markdown
DeepAudit Agent 架构重构升级方案
|
||
一、现状分析
|
||
当前 DeepAudit 架构特点
|
||
DeepAudit 目前采用基于 LangGraph 的固定流程图架构。整个审计流程按照 Recon（信息收集）→ Analysis（漏洞分析）→ Verification（漏洞验证）→ Report（报告生成）的线性顺序执行。每个阶段由一个专门的 Agent 负责，Agent 之间通过 TaskHandoff 机制传递结构化的上下文信息。
|
||
|
||
这种架构的优点是流程清晰、易于理解和调试，但存在几个明显的局限性：
|
||
|
||
第一，流程过于固定。无论面对什么类型的项目或漏洞，都必须走完整个流程，无法根据实际发现动态调整策略。比如发现了一个 SQL 注入线索，无法立即深入分析，必须等待 Analysis 阶段统一处理。
|
||
|
||
第二，Agent 专业化程度不足。Analysis Agent 需要同时处理所有类型的漏洞，从 SQL 注入到 XSS 到 SSRF，这导致系统提示词过于庞大，LLM 难以在每种漏洞类型上都表现出专家级水平。
|
||
|
||
第三，缺乏动态协作能力。Agent 之间只能按照预设的顺序传递信息，无法根据需要动态创建新的 Agent 或在 Agent 之间进行实时通信。
|
||
|
||
Strix 架构的启示
|
||
Strix 是一个开源的 AI 安全测试 Agent 项目，它采用了完全不同的架构理念。通过深入分析 Strix 的设计，我们可以获得以下关键启示：
|
||
|
||
Strix 的核心是动态 Agent 树结构。根 Agent 可以根据任务需要随时创建子 Agent，每个子 Agent 专注于特定的漏洞类型或任务。子 Agent 完成后向父 Agent 汇报结果，父 Agent 可以根据结果决定是否需要创建更多子 Agent 或进行其他操作。
|
||
|
||
Strix 的另一个亮点是模块化的专业知识系统。它为每种漏洞类型都准备了详细的 Jinja2 模板，包含该漏洞的检测方法、利用技术、绕过手段、验证步骤等专业知识。创建 Agent 时可以指定加载哪些知识模块，让 Agent 在特定领域具备专家级能力。
|
||
|
||
此外，Strix 还实现了 Agent 间的消息传递机制、完善的状态管理、工具的沙箱执行、LLM 调用优化等高级特性。
|
||
|
||
二、升级后的整体架构
|
||
核心设计理念
|
||
升级后的 DeepAudit 将采用"动态 Agent 协作 + 专业知识模块 + 智能编排"的三层架构。
|
||
|
||
最底层是专业知识模块层，包含各种漏洞类型、框架、技术栈的专业知识库。这些知识以模板形式存储，可以按需加载到 Agent 的系统提示词中。
|
||
|
||
中间层是 Agent 执行层，包含可动态创建和销毁的 Agent 实例。每个 Agent 都有完整的生命周期管理，可以执行任务、调用工具、与其他 Agent 通信。
|
||
|
||
最上层是智能编排层，负责根据审计目标和实时发现来协调整个审计流程，决定何时创建什么类型的 Agent，如何分配任务，何时结束审计。
|
||
|
||
动态 Agent 树
|
||
与当前固定的四阶段流程不同，升级后的系统将采用动态 Agent 树结构。
|
||
|
||
审计开始时，系统创建一个根 Agent（Root Agent）。根 Agent 首先进行初步的信息收集，了解项目的技术栈、目录结构、入口点等基本信息。然后根据收集到的信息，根 Agent 决定需要创建哪些专业子 Agent。
|
||
|
||
例如，如果发现项目使用了 SQL 数据库，根 Agent 可能会创建一个专门的 SQL 注入检测 Agent；如果发现有用户输入直接渲染到页面的代码，可能会创建一个 XSS 检测 Agent；如果发现有 HTTP 请求的代码，可能会创建一个 SSRF 检测 Agent。
|
||
|
||
每个子 Agent 专注于自己的任务领域。当子 Agent 发现可疑的漏洞线索时，它可以进一步创建验证子 Agent 来确认漏洞是否真实存在。验证通过后，还可以创建报告子 Agent 来生成正式的漏洞报告。
|
||
|
||
这种树状结构的好处是：任务可以无限细分，每个 Agent 都能专注于自己擅长的领域；发现和验证可以并行进行，提高效率；根据实际情况动态调整策略，而不是机械地执行固定流程。
|
||
|
||
Agent 间通信机制
|
||
升级后的系统将实现完善的 Agent 间通信机制。
|
||
|
||
每个 Agent 都有一个消息队列，其他 Agent 可以向这个队列发送消息。消息类型包括：查询消息（请求信息）、指令消息（要求执行某个操作）、信息消息（分享发现或状态）。
|
||
|
||
当 Agent 处于等待状态时，它会检查自己的消息队列。如果有新消息，Agent 会处理消息并可能恢复执行。这种机制使得 Agent 之间可以进行实时协作，而不仅仅是单向的结果传递。
|
||
|
||
例如，SQL 注入检测 Agent 在分析过程中发现某个函数可能存在问题，但需要了解这个函数的调用上下文。它可以向根 Agent 发送查询消息，请求提供相关信息。根 Agent 收到消息后，可以调用代码搜索工具获取信息，然后回复给 SQL 注入检测 Agent。
|
||
|
||
Agent 状态管理
|
||
每个 Agent 都有完整的状态管理，状态信息包括：
|
||
|
||
基本信息：Agent 的唯一标识、名称、父 Agent 标识、创建时间等。
|
||
|
||
任务信息：当前任务描述、任务上下文、从父 Agent 继承的信息等。
|
||
|
||
执行状态：当前迭代次数、最大迭代限制、运行状态（运行中、等待中、已完成、失败、已停止）等。
|
||
|
||
对话历史：与 LLM 的完整对话记录，包括系统提示词、用户消息、助手回复等。
|
||
|
||
执行记录：已执行的动作列表、观察结果列表、错误记录等。
|
||
|
||
发现列表：该 Agent 发现的所有漏洞和可疑点。
|
||
|
||
这种完整的状态管理使得 Agent 可以被暂停和恢复，可以被序列化和持久化，也便于调试和审计。
|
||
|
||
三、专业知识模块系统
|
||
模块化设计
|
||
专业知识模块是升级后架构的核心创新之一。我们将为不同的漏洞类型、框架、技术栈创建专门的知识模块。
|
||
|
||
漏洞类型模块包括：SQL 注入、XSS、SSRF、IDOR、认证绕过、远程代码执行、路径遍历、XXE、CSRF、竞态条件、反序列化、业务逻辑漏洞等。每个模块都包含该漏洞类型的完整知识体系。
|
||
|
||
框架知识模块包括：FastAPI、Django、Flask、Express、Next.js、Spring、Laravel 等主流框架。每个模块包含该框架的安全特性、常见漏洞模式、最佳实践等。
|
||
|
||
技术栈模块包括：Supabase、Firebase、GraphQL、gRPC、WebSocket 等。每个模块包含该技术的安全考量和常见问题。
|
||
|
||
模块内容结构
|
||
以 SQL 注入模块为例，它应该包含以下内容：
|
||
|
||
漏洞概述：SQL 注入的定义、危害、影响范围。
|
||
|
||
检测方法：错误型注入检测、布尔型注入检测、时间型注入检测、带外注入检测的具体技术和判断标准。
|
||
|
||
数据库特定知识：MySQL、PostgreSQL、MSSQL、Oracle 等不同数据库的特有语法、函数、利用技术。
|
||
|
||
绕过技术：WAF 绕过、过滤绕过、编码绕过等高级技术。
|
||
|
||
ORM 和查询构建器：各种 ORM 框架中容易出现 SQL 注入的 API 和模式。
|
||
|
||
验证步骤：如何确认漏洞真实存在，如何构造 PoC，如何评估影响。
|
||
|
||
误报识别：哪些情况容易被误判为 SQL 注入，如何排除误报。
|
||
|
||
修复建议：参数化查询、ORM 正确用法、输入验证等修复方案。
|
||
|
||
模块加载机制
|
||
创建 Agent 时，可以指定该 Agent 需要加载哪些知识模块。系统会将这些模块的内容动态注入到 Agent 的系统提示词中。
|
||
|
||
为了控制提示词长度和保持 Agent 的专注度，每个 Agent 最多加载 5 个知识模块。这个限制迫使我们为每个 Agent 选择最相关的知识，而不是试图让一个 Agent 掌握所有知识。
|
||
|
||
模块之间可以有依赖关系。例如，FastAPI 框架模块可能依赖 Python 安全基础模块；GraphQL 模块可能依赖 API 安全基础模块。加载模块时会自动处理这些依赖。
|
||
|
||
四、工具系统升级
|
||
统一的工具注册机制
|
||
升级后的工具系统将采用装饰器模式进行统一注册。每个工具都需要提供：工具名称、功能描述、参数定义、返回值说明。
|
||
|
||
工具按类别组织，包括：文件操作类（读取文件、搜索文件、列出目录）、代码分析类（模式匹配、数据流分析、AST 分析）、外部扫描类（Semgrep、Bandit、Gitleaks 等）、验证执行类（沙箱命令执行、HTTP 请求）、协作类（创建子 Agent、发送消息、等待消息）、推理类（思考工具）、报告类（创建漏洞报告）。
|
||
|
||
Think 工具
|
||
Think 工具是从 Strix 借鉴的关键创新。这是一个让 Agent 进行深度推理的工具，Agent 可以用它来：
|
||
|
||
分析复杂情况：当面对复杂的代码逻辑或不确定的漏洞线索时，Agent 可以调用 Think 工具进行深入思考。
|
||
|
||
规划下一步行动：在执行具体操作之前，先用 Think 工具规划策略。
|
||
|
||
评估发现的严重性：发现可疑点后，用 Think 工具评估其真实性和影响。
|
||
|
||
决定是否需要创建子 Agent：当任务变得复杂时，用 Think 工具分析是否需要分解任务。
|
||
|
||
Think 工具的输出会被记录到 Agent 的对话历史中，帮助 LLM 保持思路的连贯性。
|
||
|
||
漏洞报告工具
|
||
漏洞报告工具是正式记录漏洞的唯一方式。只有通过这个工具创建的漏洞才会被计入最终报告。这个设计确保了漏洞报告的规范性和完整性。
|
||
|
||
报告工具要求提供完整的漏洞信息：漏洞类型、严重程度、标题、详细描述、文件位置、代码片段、PoC、影响分析、修复建议等。
|
||
|
||
通常只有专门的报告 Agent 才会调用这个工具，确保漏洞在被正式报告之前已经经过了充分的验证。
|
||
|
||
沙箱执行
|
||
涉及代码执行或网络请求的工具都在沙箱环境中运行。沙箱提供资源隔离（CPU、内存、网络限制）、文件系统隔离、超时控制等安全保障。
|
||
|
||
沙箱执行通过 Tool Server 机制实现。Agent 发送工具调用请求到 Tool Server，Tool Server 在沙箱中执行工具并返回结果。这种设计使得即使工具执行出现问题，也不会影响主系统的稳定性。
|
||
|
||
五、LLM 调用优化
|
||
Prompt Caching
|
||
对于支持 Prompt Caching 的 LLM（如 Anthropic Claude），系统会自动为系统提示词和早期对话添加缓存标记。这样在多轮对话中，这些内容只需要处理一次，后续调用可以直接使用缓存，显著降低 Token 消耗和响应延迟。
|
||
|
||
缓存策略会根据对话长度动态调整。对于短对话，只缓存系统提示词；对于长对话，会在关键位置添加多个缓存点。
|
||
|
||
Memory Compression
|
||
当对话历史变得很长时，系统会自动进行压缩。压缩策略包括：
|
||
|
||
移除冗余信息：重复的工具调用结果、过长的代码输出等会被截断或摘要。
|
||
|
||
合并相似消息：连续的同类型消息可能被合并。
|
||
|
||
保留关键信息：重要的发现、决策点、错误信息等会被优先保留。
|
||
|
||
压缩后的对话历史仍然保持语义完整性，LLM 可以理解之前发生了什么，但 Token 消耗大大降低。
|
||
|
||
智能重试
|
||
LLM 调用可能因为各种原因失败：网络问题、速率限制、服务不可用等。系统实现了智能重试机制：
|
||
|
||
对于可重试的错误（如速率限制），会等待适当时间后重试。
|
||
|
||
对于不可重试的错误（如认证失败），会立即报错并提供清晰的错误信息。
|
||
|
||
重试时会使用指数退避策略，避免对 LLM 服务造成过大压力。
|
||
|
||
六、审计流程重构
|
||
启动阶段
|
||
用户发起审计请求后，系统首先创建根 Agent。根 Agent 加载通用的安全审计知识模块和项目相关的框架知识模块。
|
||
|
||
根 Agent 的第一个任务是信息收集：扫描项目目录结构、识别技术栈、找出入口点、分析依赖关系。这个阶段类似于当前的 Recon 阶段，但更加灵活。
|
||
|
||
任务分解阶段
|
||
根据信息收集的结果，根 Agent 决定如何分解审计任务。它会考虑：
|
||
|
||
项目使用了哪些技术？需要创建哪些专业 Agent？
|
||
|
||
有哪些高风险区域？应该优先分析哪些部分？
|
||
|
||
项目规模如何？需要多少并行 Agent？
|
||
|
||
根 Agent 会创建一批初始的子 Agent，每个子 Agent 负责特定的漏洞类型或代码区域。
|
||
|
||
并行分析阶段
|
||
多个子 Agent 并行工作，各自在自己的专业领域进行深入分析。
|
||
|
||
每个子 Agent 都有自己的工作循环：思考当前状态、选择工具执行、观察结果、决定下一步。这个循环会持续进行，直到 Agent 认为任务完成或达到迭代限制。
|
||
|
||
子 Agent 在分析过程中可能会发现需要进一步调查的线索。这时它可以创建更专业的子 Agent 来处理，形成多层的 Agent 树。
|
||
|
||
验证阶段
|
||
当分析 Agent 发现可疑的漏洞时，它会创建验证 Agent 来确认漏洞是否真实存在。
|
||
|
||
验证 Agent 会尝试构造 PoC、进行数据流追踪、在沙箱中测试等。验证通过后，验证 Agent 会创建报告 Agent 来生成正式的漏洞报告。
|
||
|
||
如果验证失败，验证 Agent 会将结果反馈给父 Agent，父 Agent 可以决定是否需要进一步调查或将其标记为误报。
|
||
|
||
汇总阶段
|
||
当所有子 Agent 都完成工作后，根 Agent 会汇总所有发现，生成最终的审计报告。
|
||
|
||
报告包括：发现的所有漏洞（按严重程度排序）、安全评分、技术栈分析、高风险区域标注、修复建议优先级等。
|
||
|
||
七、可观测性和调试
|
||
完整的事件追踪
|
||
系统会记录所有重要事件：Agent 创建和销毁、工具调用和结果、LLM 请求和响应、Agent 间消息、状态变更等。
|
||
|
||
这些事件可以实时推送到前端，让用户看到审计的进展。也可以持久化到数据库，用于后续分析和审计。
|
||
|
||
Agent 树可视化
|
||
前端可以展示当前的 Agent 树结构，显示每个 Agent 的状态、任务、发现数量等信息。用户可以点击任何 Agent 查看其详细信息和对话历史。
|
||
|
||
调试模式
|
||
在调试模式下，系统会记录更详细的信息，包括完整的 LLM 提示词和响应、工具执行的详细日志、状态变更的完整历史等。这些信息对于排查问题和优化系统非常有价值。
|
||
|
||
八、与现有架构的兼容
|
||
渐进式迁移
|
||
升级不需要一次性完成，可以渐进式进行。
|
||
|
||
第一步，保持现有的 LangGraph 流程不变，但将 Agent 的状态管理升级为新的模型。
|
||
|
||
第二步，引入专业知识模块系统，让现有的 Analysis Agent 可以加载不同的知识模块。
|
||
|
||
第三步，在 Analysis 阶段内部引入子 Agent 机制，允许创建专业的漏洞检测子 Agent。
|
||
|
||
第四步，逐步放开流程限制，让 Agent 可以更灵活地决定下一步操作。
|
||
|
||
第五步，完全迁移到动态 Agent 树架构。
|
||
|
||
保留 LangGraph 的优势
|
||
LangGraph 提供了很好的状态管理和检查点机制，这些在新架构中仍然有价值。我们可以将 LangGraph 用于根 Agent 的高层编排，而在子 Agent 层面使用更灵活的动态创建机制。
|
||
|
||
九、预期收益
|
||
更深度的漏洞发现
|
||
专业知识模块让每个 Agent 都具备安全专家级别的知识。专注于单一漏洞类型的 Agent 比通用 Agent 更容易发现深层次的问题。
|
||
|
||
更高的效率
|
||
并行的 Agent 执行比串行流程更快。动态任务分解避免了在无关区域浪费时间。
|
||
|
||
更低的成本
|
||
Prompt Caching 和 Memory Compression 显著降低 Token 消耗。专业化的 Agent 使用更短的提示词就能达到更好的效果。
|
||
|
||
更好的可扩展性
|
||
添加新的漏洞类型只需要创建新的知识模块。支持新的框架只需要添加框架知识模块。整个系统的扩展不需要修改核心架构。
|
||
|
||
更强的可解释性
|
||
完整的事件追踪和 Agent 树可视化让用户清楚地了解系统在做什么。Think 工具的输出展示了 Agent 的推理过程。
|
||
|
||
这个升级方案借鉴了 Strix 的核心设计理念，同时保留了 DeepAudit 的既有优势，通过渐进式迁移降低风险，最终实现一个更强大、更灵活、更专业的安全审计 Agent 系统。
|
||
|
||
|
||
---
|
||
|
||
## 十、实施进度记录
|
||
|
||
### 已完成的工作 (2024-12)
|
||
|
||
#### 1. 核心模块系统 ✅
|
||
- `core/state.py`: 增强的Agent状态管理，支持完整生命周期
|
||
- `core/registry.py`: Agent注册表和动态Agent树管理
|
||
- `core/message.py`: Agent间通信机制（消息总线）
|
||
|
||
#### 2. 专业知识模块系统 ✅ (基于RAG)
|
||
采用模块化文件组织，统一使用RAG进行知识检索：
|
||
|
||
```
|
||
knowledge/
|
||
├── base.py # 基础定义（KnowledgeDocument, KnowledgeCategory）
|
||
├── loader.py # 知识加载器
|
||
├── rag_knowledge.py # RAG检索系统
|
||
├── tools.py # 知识查询工具
|
||
├── vulnerabilities/ # 漏洞类型知识
|
||
│ ├── injection.py # SQL注入、NoSQL注入、命令注入、代码注入
|
||
│ ├── xss.py # 反射型XSS、存储型XSS、DOM型XSS
|
||
│ ├── auth.py # 认证绕过、IDOR、访问控制失效
|
||
│ ├── crypto.py # 弱加密、硬编码凭证
|
||
│ ├── ssrf.py # SSRF
|
||
│ ├── deserialization.py # 不安全的反序列化
|
||
│ ├── path_traversal.py # 路径遍历
|
||
│ ├── xxe.py # XXE
|
||
│ └── race_condition.py # 竞态条件
|
||
└── frameworks/ # 框架安全知识
|
||
├── fastapi.py # FastAPI安全
|
||
├── django.py # Django安全
|
||
├── flask.py # Flask安全
|
||
├── express.py # Express.js安全
|
||
├── react.py # React安全
|
||
└── supabase.py # Supabase安全
|
||
```
|
||
|
||
#### 3. Agent基类增强 ✅
|
||
- 支持动态Agent树（parent_id, 子Agent创建）
|
||
- Agent间消息通信
|
||
- TaskHandoff协作机制
|
||
- 知识模块加载
|
||
- Memory Compression集成
|
||
|
||
#### 4. 工具系统 ✅
|
||
- `thinking_tool.py`: Think和Reflect工具
|
||
- `reporting_tool.py`: 漏洞报告工具
|
||
- `agent_tools.py`: Agent协作工具
|
||
- CreateSubAgentTool: 动态创建子Agent
|
||
- SendMessageTool: Agent间消息发送
|
||
- ViewAgentGraphTool: 查看Agent树
|
||
- WaitForMessageTool: 等待消息
|
||
- AgentFinishTool: 子Agent完成报告
|
||
|
||
#### 5. LLM调用优化 ✅
|
||
- `memory_compressor.py`: 对话历史压缩
|
||
- 自动检测是否需要压缩
|
||
- 保留关键信息（发现、工具使用、决策、错误）
|
||
- 智能摘要生成
|
||
- Agent基类集成自动压缩
|
||
|
||
#### 6. Orchestrator Agent ✅
|
||
- LLM驱动的编排决策
|
||
- 动态调度子Agent
|
||
- ReAct模式执行
|
||
|
||
### 已完成的工作 (2024-12 续)
|
||
|
||
#### 7. Prompt Caching ✅
|
||
- `llm/prompt_cache.py`: Prompt 缓存管理器
|
||
- 支持 Anthropic Claude 的 Prompt Caching
|
||
- 动态缓存策略（SYSTEM_ONLY, SYSTEM_AND_EARLY, MULTI_POINT）
|
||
- 缓存统计和效果追踪
|
||
- Token 估算工具
|
||
- LiteLLM 适配器集成缓存支持
|
||
|
||
#### 8. 动态Agent树执行器 ✅
|
||
- `core/executor.py`: 完整的执行器实现
|
||
- `DynamicAgentExecutor`: 动态Agent树执行器
|
||
- 并行Agent执行（带信号量控制）
|
||
- 任务依赖管理
|
||
- 执行结果汇总
|
||
- 超时和取消处理
|
||
- `SubAgentExecutor`: 子Agent执行器
|
||
- 从父Agent创建和执行子Agent
|
||
- 并行子Agent执行
|
||
- 结果收集和汇总
|
||
- `ExecutionTask`: 执行任务数据结构
|
||
- `ExecutionResult`: 执行结果数据结构
|
||
|
||
#### 9. Agent状态持久化 ✅
|
||
- `core/persistence.py`: 持久化模块
|
||
- `AgentStatePersistence`: 状态持久化管理器
|
||
- 文件系统持久化
|
||
- 数据库持久化（可选）
|
||
- 检查点列表和清理
|
||
- `CheckpointManager`: 检查点管理器
|
||
- 自动检查点（按迭代间隔）
|
||
- 检查点恢复
|
||
- 状态回滚
|
||
|
||
#### 10. 增强的Agent协作工具 ✅
|
||
- `CreateSubAgentTool`: 增强版
|
||
- 支持立即执行模式
|
||
- 集成SubAgentExecutor
|
||
- 上下文传递
|
||
- `RunSubAgentsTool`: 批量执行子Agent
|
||
- 并行/顺序执行
|
||
- 结果汇总
|
||
- `CollectSubAgentResultsTool`: 收集子Agent结果
|
||
|
||
#### 11. 数据库模型扩展 ✅
|
||
- `AgentCheckpoint`: Agent检查点模型
|
||
- 状态数据存储
|
||
- 执行统计
|
||
- 检查点类型（auto/manual/error/final）
|
||
- `AgentTreeNode`: Agent树节点模型
|
||
- 树结构记录
|
||
- 执行状态追踪
|
||
- 结果汇总
|
||
- Alembic迁移脚本: `007_add_agent_checkpoint_tables.py`
|
||
|
||
#### 12. API 端点 ✅
|
||
- `GET /agent-tasks/{task_id}/agent-tree`: Agent树查询API
|
||
- 返回完整的Agent树结构
|
||
- 支持运行时内存查询和数据库查询
|
||
- 包含执行状态和发现统计
|
||
- `GET /agent-tasks/{task_id}/checkpoints`: 检查点列表API
|
||
- 支持按Agent ID过滤
|
||
- 分页支持
|
||
- `GET /agent-tasks/{task_id}/checkpoints/{checkpoint_id}`: 检查点详情API
|
||
- 返回完整的Agent状态数据
|
||
|
||
### 已完成的工作 (2024-12 续2)
|
||
|
||
#### 13. 前端 Agent 审计页面 ✅ (Strix-inspired Terminal UI)
|
||
- `frontend/src/shared/api/agentTasks.ts`: 扩展 API
|
||
- `AgentTreeNode`, `AgentTreeResponse` 类型定义
|
||
- `AgentCheckpoint`, `CheckpointDetail` 类型定义
|
||
- `getAgentTree()`: 获取 Agent 树结构
|
||
- `getAgentCheckpoints()`: 获取检查点列表
|
||
- `getCheckpointDetail()`: 获取检查点详情
|
||
|
||
- `frontend/src/pages/AgentAudit.tsx`: 统一的 Agent 审计页面 (参考 Strix TUI 设计)
|
||
- **布局**: 左侧活动日志 (75%) + 右侧 Agent 树和统计 (25%)
|
||
- **启动画面**: ASCII Art + 动画加载效果
|
||
- **活动日志**:
|
||
- 实时流式显示 Agent 思考过程
|
||
- 工具调用和结果展示
|
||
- 漏洞发现高亮
|
||
- 自动滚动控制
|
||
- 可折叠的日志条目
|
||
- **Agent 树可视化**:
|
||
- 树状结构展示
|
||
- 节点状态图标（运行中/已完成/失败/等待）
|
||
- 发现数量徽章
|
||
- 节点选择交互
|
||
- **实时统计面板**:
|
||
- 进度百分比
|
||
- 文件分析进度
|
||
- Token 使用量
|
||
- 发现数量
|
||
- 严重程度分布
|
||
- **创建任务对话框**: 选择项目后直接跳转到实时流页面
|
||
- **任务控制**: 停止/取消任务
|
||
|
||
- `frontend/src/app/routes.tsx`: 路由配置
|
||
- `/agent-audit`: 启动画面 + 创建任务
|
||
- `/agent-audit/:taskId`: 任务实时流页面
|
||
|
||
- `frontend/src/components/layout/Sidebar.tsx`: 侧边栏导航
|
||
- 新增 Agent 审计入口图标
|
||
|
||
### 已完成的工作 (2024-12 续3)
|
||
|
||
#### 14. 执行架构切换 ✅
|
||
- **移除旧的 LangGraph 固定流程架构**
|
||
- **启用新的动态 Agent 树架构**
|
||
- `backend/app/api/v1/endpoints/agent_tasks.py`:
|
||
- `_execute_agent_task()` 重写为使用 `OrchestratorAgent`
|
||
- OrchestratorAgent 作为大脑，动态调度子 Agent
|
||
- 子 Agent: ReconAgent, AnalysisAgent, VerificationAgent
|
||
- 新增辅助函数: `_get_user_config()`, `_initialize_tools()`, `_collect_project_info()`, `_save_findings()`, `_calculate_security_score()`
|
||
|
||
### 待完成的工作
|
||
|
||
#### 1. 前端增强
|
||
- 知识模块选择 UI（创建任务时）
|
||
- 检查点恢复功能
|
||
- 导出报告功能
|
||
|
||
#### 2. 测试和优化
|
||
- 单元测试
|
||
- 集成测试
|
||
- 性能优化
|
||
- 并发执行压力测试
|
||
|
||
#### 3. 文档
|
||
- API文档更新
|
||
- 架构图更新
|
||
- 使用指南
|
||
|
||
---
|
||
|
||
## 十一、架构升级总结
|
||
|
||
### 已实现的核心功能
|
||
|
||
1. **Prompt Caching** - 为 Claude 等 LLM 提供缓存支持，减少 Token 消耗
|
||
2. **动态 Agent 树执行** - OrchestratorAgent 作为大脑，动态调度子 Agent
|
||
3. **Agent 状态持久化** - 文件系统和数据库双重持久化
|
||
4. **检查点机制** - 自动检查点、状态恢复、执行历史追踪
|
||
5. **增强的协作工具** - 子 Agent 创建、批量执行、结果收集
|
||
6. **完整的 API 支持** - Agent 树查询、检查点管理
|
||
7. **旧架构已移除** - 不再使用 LangGraph 固定流程，完全切换到动态 Agent 树
|
||
|
||
### 文件清单
|
||
|
||
```
|
||
backend/app/services/
|
||
├── llm/
|
||
│ ├── __init__.py # 模块导出
|
||
│ ├── prompt_cache.py # 🆕 Prompt Caching
|
||
│ ├── memory_compressor.py # Memory Compression
|
||
│ └── adapters/
|
||
│ └── litellm_adapter.py # 集成 Prompt Caching
|
||
│
|
||
├── agent/
|
||
│ ├── core/
|
||
│ │ ├── __init__.py # 模块导出
|
||
│ │ ├── state.py # Agent 状态管理
|
||
│ │ ├── registry.py # Agent 注册表
|
||
│ │ ├── message.py # Agent 间通信
|
||
│ │ ├── executor.py # 🆕 动态 Agent 树执行器
|
||
│ │ └── persistence.py # 🆕 状态持久化
|
||
│ │
|
||
│ ├── tools/
|
||
│ │ ├── __init__.py # 模块导出
|
||
│ │ ├── agent_tools.py # 🔄 增强的协作工具
|
||
│ │ ├── thinking_tool.py # Think/Reflect 工具
|
||
│ │ └── reporting_tool.py # 漏洞报告工具
|
||
│ │
|
||
│ ├── knowledge/ # 专业知识模块
|
||
│ │ ├── vulnerabilities/ # 漏洞类型知识
|
||
│ │ └── frameworks/ # 框架安全知识
|
||
│ │
|
||
│ └── agents/
|
||
│ ├── base.py # Agent 基类
|
||
│ ├── orchestrator.py # 编排 Agent
|
||
│ ├── analysis.py # 分析 Agent
|
||
│ └── verification.py # 验证 Agent
|
||
|
||
backend/app/models/
|
||
└── agent_task.py # 🔄 新增 AgentCheckpoint, AgentTreeNode
|
||
|
||
backend/app/api/v1/endpoints/
|
||
└── agent_tasks.py # 🔄 新增 Agent 树和检查点 API
|
||
|
||
backend/alembic/versions/
|
||
└── 007_add_agent_checkpoint_tables.py # 🆕 数据库迁移
|
||
|
||
frontend/src/shared/api/
|
||
└── agentTasks.ts # 🔄 扩展 Agent 树和检查点 API
|
||
|
||
frontend/src/pages/
|
||
└── AgentAudit.tsx # 🆕 统一的 Agent 审计页面 (Strix-inspired)
|
||
|
||
frontend/src/app/
|
||
└── routes.tsx # 🔄 新增 Agent 审计路由
|
||
|
||
frontend/src/components/layout/
|
||
└── Sidebar.tsx # 🔄 新增 Agent 审计导航图标
|
||
```
|
||
|
||
### 下一步计划
|
||
|
||
1. 测试前端页面渲染和流式事件
|
||
2. 知识模块选择 UI
|
||
3. 检查点恢复功能
|