告别“自嗨”与烧钱:如何为“AI渗透测试”构建可靠的实战闭环
在长时间渗透测试任务中,LLM 的上下文窗口有限,随着对话轮次增加,早期的关键信息(发现的漏洞、失败的策略、目标特征等)会因上下文截断而丢失,导致 Agent 重复尝试已失败的方法或遗忘已发现的攻击面。
告别“自嗨”与烧钱:如何为“AI渗透测试”构建可靠的实战闭环?
开源的AI渗透项目,基本都有一些问题。
1.灾难性遗忘:在长时间的渗透中,随着对话轮次的增加,AI会忘记了自己要干嘛、自己做出来的成果、目标的特征、甚至是失败的路径。然后他就会捏造成果或者是重复失败的渗透路径。
2.命令行沉迷:这个是最有意思的,我们调用nmap去扫描整个网段,扫描会需要很长时间,工具不返回结果,AI就会一直等着,然后超过了一定时间之后,AI会认为工具执行失败,又进行尝试,然后又失败,又尝试,陷入一个死循环,曾经因为这个烧了很多很多的token。
3.逻辑断层:AI调用MCP工具时需要传参,有时候传参报错,他就会直接停止任务,然后说XXX工具报错,但是按照已经规定的参数进行传参,工具是可以正常调用的。也就是说,他缺少自我纠错的能力。
4.token消耗巨大:很多工具都将工具执行的过程注入到上下文中,使得上下文资源和token资源消耗很快。曾经有一个靶场测了几百万token的伟大创举。
5.检索效率瓶颈:知识库和渗透测试经验搜索杂,静态知识库和渗透测试经验重复太多,搜一个会出来很多,很浪费token,也影响效率。
下面是我们针对性的一些解决方案。
一、防止灾难性遗忘(Catastrophic Forgetting Prevention)
1.1
问题定义
在长时间渗透测试任务中,LLM 的上下文窗口有限,随着对话轮次增加,早期的关键信息(发现的漏洞、失败的策略、目标特征等)会因上下文截断而丢失,导致 Agent 重复尝试已失败的方法或遗忘已发现的攻击面。
1.2
多层防遗忘架构
项目通过 4 层机制 协同工作来对抗灾难性遗忘:
1.2.1持久化上下文对象(Persistent Context Objects)
定义了两个关键的持久化上下文对象:
classPlannerContext(BaseModel):
这些对象独立于 LLM 对话历史存在,即使对话被压缩,这些结构化数据仍然保留。
**关键代码:**update_planner_context() 方法持续追加规划历史、被拒策略和反思报告。被拒策略使用 Dict[str, str] 存储,key 为策略名,value 为拒绝原因,确保 Planner 不会重复提出已被否决的方案。
1.2.2**:智能上下文压缩(LLM-based Context Compression)**
实现了三策略触发的压缩机制:
classContextCompressor:
触发判断:
defshould_compress(self, messages, execution_count) -> tuple[bool, str]:
压缩策略:
压缩后的消息列表 = 系统提示词(不变) + LLM 生成的历史摘要 + 最近 10 条消息(不变)
核心是 压缩提示词,要求 LLM 在摘要中保留:
- 所有重要的决策和行动
- 关键的工具调用和结果
- 失败原因和教训
- 时间顺序
这确保了即使历史消息被压缩,关键的决策轨迹和失败教训不会丢失。
1.2.3:双后端知识库(Long-term Memory)
知识存储采用 OpenViking + ChromaDB 双后端架构(详见第五章),按数据性质自动路由:
- OpenViking(静态知识):攻击载荷库(PayloadsAllTheThings, 136 文件)和漏洞挖掘方法论(HowToHunt, 88 文件),支持 L0/L1/L2 渐进加载,避免一次性加载长文档浪费上下文窗口
- ChromaDB(动态经验):Agent 执行渗透测试时积累的 STE 经验(experience)、工具使用记录、任务记忆(task_memory)
知识库在 MCP Server 启动时自动预加载,包括 ChromaDB 数据加载和 OpenViking 后端初始化,确保 Agent 在任何新任务开始时都能检索到历史积累的知识。
**1.2.4:**STE 经验提取(Strategy-Tactics-Example)
reflect_global() 方法在任务结束时执行全局反思,提取可复用的 STE 经验:
STE 结构:
这些 STE 经验存储到ReflectorContext.persistent_insights 中,为后续任务提供可复用的攻击模式。
1.3
信息流转闭环
Executor 执行 → 结果存入 message_history
二、逻辑断层解决方案(Logic Gap Resolution)
2.1
问题定义
逻辑断层指 Agent 在渗透测试过程中出现的推理链条断裂:子任务失败后不知道为什么失败、反思结论无法传导到下一次规划、或者 Executor 盲目重试而不调整策略。
2.2
P-E-R 协作架构
实现了 Planner-Executor-Reflector (P-E-R) 三角协作架构来消除逻辑断层:
┌─────────┐
2.3
分层失败归因
(L0-L5 Failure Attribution)
这是消除逻辑断层的核心机制。定义了严格的 6 层递进归因体系:
printf("helloL0 (Observation) → 工具原始输出(最基础层)
严格的递进原则:
defattribute(self, ...):
这防止了最常见的逻辑断层:Agent 错误地将工具级失败归因为策略失败,从而过早放弃正确的攻击路径。
2.4
Reflector 的 VETO 权力
# Reflector 返回的 rejected_staged_nodes 列表
Reflector 拥有否决 Executor 提交的因果图节点的权力。这防止了 Executor 在执行中产生的错误推理被无条件接受,形成逻辑链条上的"坏节点"。
2.5
动态规划闭环
实现了反思驱动的动态规划:
# 基于 Reflector 的情报摘要触发动态规划
动态规划的提示词明确要求:
- 失败驱动:优先处理失败或阻塞的任务
- 诊断优先:为失败任务设计诊断或替代方案
- 避免重复:不要重复已失败的方法
同时,Planner 通过
get_planner_summary() 获取包含 rejected_strategies 的完整历史,确保新规划不会重蹈覆辙。
2.6
逻辑断层消除的完整链条
Executor 执行失败
三、命令执行防沉迷机制(Anti-Addiction / Loop Prevention)
3.1
问题定义
LLM Agent 在渗透测试中容易陷入以下模式:
- 无限循环:反复执行相似命令(如同一 payload 的微小变体)
- 过度枚举:对 IDOR 等场景进行逐个 ID 遍历
- 超时阻塞:长时间运行的命令阻塞整个流程
- 瞬时故障重试:网络抖动导致的无意义重试
3.2
三大防护机制
机制一:SequenceMatcher 相似度检测
核心参数:
classAntiAddiction:
检测流程:
def_is_similar_to_last_command(self, current_cmd: str) -> bool:
滑动窗口历史:
classCommandHistory(BaseModel):
触发警告:当连续相似命令达到 18 次时,返回一个结构化的反思提示:
⚠️ 检测到可能陷入循环(已连续执行 18 次相似命令)
关键设计:警告触发后,计数器重置为 0,允许 Agent 在反思后继续执行。执行不相似的命令也会重置计数器,即只检测连续相似。
机制二:指数退避重试(Exponential Backoff with Jitter)
使用 tenacity 库创建重试装饰器:
def create_retry_decorator(self, func_name: str = "") -> Callable:
等待序列大约为:0.3s → 0.6s → 1.2s(加上 ±0.5s 随机抖动),最多 3 次。
可重试错误判断:
@staticmethod
机制三:异步超时控制
asyncdefexecute_with_timeout(self, coro, timeout=None, func_name=""):
任何工具调用超过 300 秒将被强制终止,抛出 TimeoutError。
3.3
在 Executor 中的集成
Executor 初始化时创建 AntiAddiction 实例。
在每次 shell 命令执行前进行防沉迷检查:
if tool_name == "execute_shell_command":
3.4
防护层次总结
| 层级 | 机制 | 触发条件 | 行为 |
| L1 | 相似度检测 | 连续 18 次相似度 >= 0.85 | 返回反思提示,重置计数器 |
| L2 | 指数退避重试 | Exception 异常 | 0.3s→0.6s→1.2s+jitter, 最多 3 次 |
| L3 | 超时控制 | 单命令超过 300s | 强制终止,抛出 TimeoutError |
| L4 | 循环迭代上限 | execute_reflect_loop > 100 | 标记任务为 FAILED |
四、Meta-Tooling 层实现
4.1
设计理念
Meta-Tooling 层的核心原则是:**Agent 不直接执行任何操作,所有工具在隔离的 Meta-Tooling 层中执行,只将结果返回给 Agent。**这实现了 Agent 推理与工具执行的解耦。
4.2
架构概览
┌─────────────────────────────────────────────────────┐
4.3
MCP Server 作为中间层
定义了 AIPentestMCPServer 类:
classAIPentestMCPServer:
MCP Server 持有所有工具实例,Agent 通过 MCP 协议(JSON-RPC over stdio)发送工具调用请求,Server 路由到对应的工具实例执行,只返回文本结果。
4.4
五大 Meta-Tooling 组件
4.4.1 PythonExecutor(代码执行沙箱)
`self.python_executor = PythonExecutor(path="scripts")`
在 Executor 中的调用:
if tool_name == "execute_python_code":
Agent 发送 Python 代码字符串 → PythonExecutor 在隔离环境中执行 → 只返回输出文本。
4.4.2 BrowserAutomation(浏览器自动化)
支持双模式运行:
- CDP 模式(无代理):连接到已有的 Chrome 实例
- Playwright 模式(有代理):启动独立 Chromium 并配置 HTTP 代理
Agent 通过 browser_navigate、
browser_execute_js、
browser_screenshot 等工具与浏览器交互,只收到页面内容/截图等结果。
4.4.3 Terminal(终端会话管理)
shell 命令执行:
elif tool_name == "execute_shell_command":
Terminal 封装了 tmux 会话管理,Agent 不直接接触 shell,只通过 send_keys → get_output 的模式交互。
4.4.4 Proxy(HTTP 流量代理)
与 Caido 代理集成
self.proxy = Proxy(
Agent 可以通过 proxy_list_traffic 工具查看经过代理的 HTTP 流量,用于分析请求/响应。
4.4.5 Recon Tools(侦察工具集)
导出的侦察工具:
- CyberspaceMapper # 空间测绘(FOFA/Quake)
这些工具都在 MCP Server 层实例化和执行,Agent 只收到结构化的扫描结果。
4.5
工具执行的隔离保障
Executor 中的工具调用流程:
Agent LLM 输出 tool_call
关键点:
- Agent 永远不直接执行命令,只通过 Meta-Tooling 层间接操作
- 每次工具调用都经过防沉迷检查和重试包装
- 工具输出经过 ToolExecutionResult 标准化后才返回
- 失败会自动进行 L0-L5 归因
- 漏洞相关输出自动保存到笔记系统
4.6
Meta-Tooling 层的安全边界
Agent 层(纯推理)
五、双后端知识架构(OpenViking + ChromaDB)
5.1
问题定义
项目知识库存在两类性质截然不同的数据:
-
静态知识**:**攻击载荷
(PayloadsAllTheThings)和漏洞挖掘方法论(HowToHunt),更新频率低、单条内容长(完整 Markdown 文档)
-
**动态经验:**Agent 执行渗透测试时积累的 STE 经验、工具使用记录、任务记忆,持续增长
此前两者共存于 ChromaDB 平坦向量空间,带来两个问题:
- **检索噪声:**搜索「SQL 注入」时,静态 payload 文档和动态 experience 条目混排,Agent 需要大量 token 才能筛选出目标类型
- **无法渐进加载:**ChromaDB 只支持「全文命中→返回全文」,对于长文档(如 SQL_Injection/README.md 有数千行)会浪费 LLM 上下文窗口
5.2
解决方案:OpenViking 层级知识管理
引入 OpenViking 作为静态知识专用后端,利用其L0/L1/L2 渐进加载 和AGFS 层级目录结构替代 ChromaDB 的平坦搜索。
knowledge_search(query, category?)
L0/L1/L2 渐进加载
OpenViking 的核心优势在于三级内容粒度:
| 层级 | 内容 | Token 量 | 用途 |
| L0 | 自动生成的摘要(abstract) | ~100 tokens | knowledge_search 结果列表中的预览 |
| L1 | 结构化概览(overview) | ~2k tokens | 中等粒度浏览,判断是否需要全文 |
| L2 | 完整原始文档 | 原文长度 | knowledge_get_detail 返回完整内容 |
这使得 Agent 可以先通过 L0 摘要快速筛选,再对感兴趣的条目调用 knowledge_get_detail 获取 L2 全文,避免一次性加载大量无关内容。
5.3
路由策略实现
路由表
| category | 后端 | 说明 |
| payloads / howtohunt | OpenViking(不可用时降级 ChromaDB) | 静态攻击载荷和方法论 |
| experience / task_memory / general | ChromaDB | 动态数据 |
| 不填 | 两者合并,按 similarity 排序取 top N | 跨后端搜索 |
路由核心代码
实现了三分支路由:
asyncdef_knowledge_search(self, arguments):
详情路由
按 ID 前缀路由:
asyncdef_knowledge_get_detail(self, arguments):
5.4
OpenViking 客户端封装
ai_pentest/knowledge/viking.py
封装了 OpenViking SDK,提供两个核心类:
VikingKnowledgeResult(兼容对象)
@dataclass
id使用viking://前缀,
使得 _knowledge_get_detail 可以通过前缀判断路由到 OpenViking 而非 ChromaDB。metadata[“source”] = “openviking” 用于搜索结果中标记 [Viking] 来源标签。
VikingKnowledgeBackend(客户端)
classVikingKnowledgeBackend:
5.5
Embedding 配置
OpenViking 使用豆包(Doubao)多模态向量模型生成语义向量:
~/.openviking/ov.conf 核心配置:
{
-
provider: volcengine — 使用火山引擎API
(/api/v3/embeddings/multimodal)
-
dimension: 2048 维多模态向量
-
auto_generate_l0/l1: 资源入库时自动生成 L0 摘要和 L1 概览
5.6
降级策略
系统设计了四级降级保障,确保 OpenViking 不可用时不影响核心功能:
| 场景 | 行为 | 影响 |
| OPENVIKING_ENABLED=false(默认) | 不导入 openviking,路由全部走 ChromaDB | 零影响 |
| openviking 包未安装 | initialize() 捕获 ImportError,返回 False | 降级到 ChromaDB |
| Viking 搜索异常 | 捕获异常返回空列表,ChromaDB 结果不受影响 | 部分结果缺失 |
| knowledge_get_detail(viking://…) 但 Viking 不可用 | 返回明确错误信息 | 用户可从 ChromaDB 获取替代内容 |
initialize() 方法:
definitialize(self) -> bool:
5.7
MCP Server 集成方式
stdio 模式(单会话)
AIPentestMCPServer.__init__ 接受可选的 shared_viking_backend 参数。_initialize_knowledge_base() 末尾调用 _ensure_viking_backend() 懒初始化。
HTTP 模式(多会话)
在 main() 中预加载共享 Viking 后端,注入到所有会话的 AIPentestMCPServer 实例中,避免每个会话重复初始化 AGFS 服务(AGFS 监听端口 1833,只能启动一个实例)。
#### stdio 模式(单会话)
5.8
数据迁移
迁移通过两个脚本完成:
迁移脚本
tools_scripts/migrate_to_openviking.py
将data/knowledge/payloads/(136 个 Markdown 文件)
和 data/knowledge/howtohunt/(88 个 Markdown 文件)
导入 OpenViking:
client = ov.OpenViking(path=data_path)
清理脚本
tools_scripts/cleanup_chroma_static.py
从 ChromaDB 删除已迁移到 OpenViking 的 447 条静态知识(271 payloads + 176 howtohunt),使 ChromaDB 只保留动态数据(experience:1294 + general:15 + task_memory:6)。
5.9
知识库分工
┌────────────────────────────────────────────────────────────────────┐
学习资源
如果你是也准备转行学习网络安全(黑客)或者正在学习,这里开源一份360智榜样学习中心独家出品《网络攻防知识库》,希望能够帮助到你
知识库由360智榜样学习中心独家打造出品,旨在帮助网络安全从业者或兴趣爱好者零基础快速入门提升实战能力,熟练掌握基础攻防到深度对抗。
读者福利 | CSDN大礼包:《网络安全入门&进阶学习资源包》免费分享 (安全链接,放心点击)

一、知识库价值
深度: 本知识库超越常规工具手册,深入剖析攻击技术的底层原理与高级防御策略,并对业内挑战巨大的APT攻击链分析、隐蔽信道建立等,提供了独到的技术视角和实战验证过的对抗方案。
广度: 面向企业安全建设的核心场景(渗透测试、红蓝对抗、威胁狩猎、应急响应、安全运营),本知识库覆盖了从攻击发起、路径突破、权限维持、横向移动到防御检测、响应处置、溯源反制的全生命周期关键节点,是应对复杂攻防挑战的实用指南。
实战性: 知识库内容源于真实攻防对抗和大型演练实践,通过详尽的攻击复现案例、防御配置实例、自动化脚本代码来传递核心思路与落地方法。
二、 部分核心内容展示
360智榜样学习中心独家《网络攻防知识库》采用由浅入深、攻防结合的讲述方式,既夯实基础技能,更深入高阶对抗技术。

360智榜样学习中心独家《网络攻防知识库》采用由浅入深、攻防结合的讲述方式,既夯实基础技能,更深入高阶对抗技术。
内容组织紧密结合攻防场景,辅以大量真实环境复现案例、自动化工具脚本及配置解析。通过策略讲解、原理剖析、实战演示相结合,是你学习过程中好帮手。
1、网络安全意识

2、Linux操作系统

3、WEB架构基础与HTTP协议

4、Web渗透测试

5、渗透测试案例分享

6、渗透测试实战技巧

7、攻防对战实战

8、CTF之MISC实战讲解

三、适合学习的人群
基础适配人群
- 零基础转型者:适合计算机零基础但愿意系统学习的人群,资料覆盖从网络协议、操作系统到渗透测试的完整知识链;
- 开发/运维人员:具备编程或运维基础者可通过资料快速掌握安全防护与漏洞修复技能,实现职业方向拓展或者转行就业;
- 应届毕业生:计算机相关专业学生可通过资料构建完整的网络安全知识体系,缩短企业用人适应期;
能力提升适配
1、技术爱好者:适合对攻防技术有强烈兴趣,希望掌握漏洞挖掘、渗透测试等实战技能的学习者;
2、安全从业者:帮助初级安全工程师系统化提升Web安全、逆向工程等专项能力;
3、合规需求者:包含等保规范、安全策略制定等内容,适合需要应对合规审计的企业人员;
因篇幅有限,仅展示部分资料,完整版的网络安全学习资料已经上传CSDN,朋友们如果需要可以在下方CSDN官方认证二维码免费领取【保证100%免费】
;
因篇幅有限,仅展示部分资料,完整版的网络安全学习资料已经上传CSDN,朋友们如果需要可以在下方CSDN官方认证二维码免费领取【保证100%免费】

文章来自网上,侵权请联系博主
更多推荐
所有评论(0)