从 PenGym 仿真到真实 Web 靶场:Qwen Commander、零信任语义通信与多智能体渗透测试系统骨架

一、这篇文章要说明什么

这篇记录的核心,不再是继续在 PenGym / NASim 里训练新的 PPO 模型,也不是继续把已有仿真 expert 的成功率往上堆,而是说明项目开始从“仿真自动渗透智能体”转向“面向本地授权 Web 靶场的多智能体渗透测试系统”。

本阶段最重要的变化可以概括为四点:

  1. 训练线已经暂停:当前没有继续训练 PPO、BC、D3QN 或其他 RL 模型,已有模型仍作为仿真 expert 使用。
  2. PenGym 仿真线已经成为稳定基座tiny / small / medium family 的 solved experts、router、manager-worker、CLI 等工程能力已经形成完整闭环。
  3. 真实工具链路已经迈出第一步:本地 Docker toy target 上已经完成 nmap service_scan -> XML -> RealObservationEvent 的受控真实扫描闭环。
  4. 大模型角色被重新定义:Qwen 不再被定位为 step-level action override,也不只是事后解释器,而是未来真实 Web 渗透系统中的最高战略 Commander,负责调度 Agent Team 工作。

因此,本阶段的准确定位是:

从 PenGym/NASim 仿真智能体,过渡到“LLM Commander + 零信任语义通信 + Web Agent Team”的真实 Web 靶场渗透测试系统架构。

需要强调的是:

当前还没有完成完整真实 Web 自动渗透,也没有完成 DVWA / Pikachu / Metasploitable 的真实漏洞利用链。当前完成的是多智能体架构骨架、零信任语义通信协议、Qwen Commander 调度验证,以及对本地 toy Web target 的安全探测闭环。


二、为什么现在看不到训练

前面很多阶段都围绕训练展开,例如:

  • MaskablePPO;
  • BC warm-start;
  • success distillation;
  • actor-freeze PPO;
  • tiny / small / medium solved experts;
  • family router;
  • cross-family router。

但是从当前阶段开始,项目重点已经发生变化。

现在不是:

1
2
3
继续训练一个更大的 PPO
继续微调 tiny/small/medium expert
继续堆 timesteps

而是:

1
2
3
4
5
把已有仿真能力工程化
把真实工具输出接入 observation 系统
把 LLM 放到战略调度层
构建真实 Web 靶场 Agent Team
建立零信任语义通信协议

也就是说,当前不是训练阶段,而是系统架构迁移阶段。

当前仍然保留的训练成果主要是:

1
2
prototype/models/*.zip
prototype/models/*.pt

这些模型在 simulation mode 中仍然负责底层动作选择。


三、当前项目的两条主线

现在整个项目必须拆成两条线理解。

1. PenGym / NASim 仿真线

这一条线已经比较完整:

1
2
3
4
5
6
7
scenario
-> fingerprint router
-> selected PPO/BC expert
-> expert action selection
-> manager-worker analysis
-> Qwen/template high-level explanation
-> CLI report

仿真线当前的代表结果是:

1
2
3
4
5
6
7
8
9
tiny                 20/20
tiny-small 20/20
tiny-hard 20/20
small-honeypot 20/20
small-linear 20/20
medium 20/20
medium-single-site 20/20
medium-multi-site 20/20
TOTAL 160/160

这说明 simulation benchmark 已经形成稳定闭环。

2. 真实 Web 靶场线

这一条线刚刚开始。

当前已经完成的真实工具链路只有:

1
2
3
4
5
Docker toy target
-> nmap -sV -p18080 -oX - 127.0.0.1
-> nmap XML output
-> NmapXMLParser
-> RealObservationEvent

已经识别到:

1
2
3
4
5
host    = 127.0.0.1
port = 18080/tcp
service = http
product = nginx
version = 1.31.0

这一步说明真实工具输出可以被转回结构化 observation event。

但它还不是完整 Web 渗透。

当前尚未实现:

1
2
3
4
5
6
7
8
真实 SQL injection validation
真实 XSS validation
真实 file upload testing
登录 / session 管理
DVWA / Pikachu 接入
Metasploitable 接入
真实 exploit chain
真实 privilege escalation

四、为什么 PenGym 模型不能直接打 Pikachu / DVWA

PenGym / NASim 的动作是抽象动作,例如:

1
2
3
4
5
6
7
8
service_scan
os_scan
subnet_scan
e_ssh
e_http
e_smtp
pe_tomcat
pe_daclsvc

而 Pikachu / DVWA 这样的真实 Web 靶场需要的是 Web request 级动作,例如:

1
2
3
4
5
6
7
8
9
HTTP GET / POST
URL 参数
表单字段
Cookie / Session
CSRF token
SQLi payload
XSS marker
文件上传请求
页面响应解析

这两套动作空间不是同一个层级。

因此,不能把 PPO policy 输出的 e_http 直接解释成“打 Pikachu 的某个 SQLi 页面”。中间必须增加一层 Web adapter:

1
2
3
4
5
PenGym abstract intent
-> Web task plan
-> HTTP request plan
-> response parser
-> WebObservationEvent

这就是后续真实 Web 靶场智能体要解决的核心问题。


五、Qwen 的角色重新定义

前面曾经做过 step-level LLM override 实验,结论是:

让 LLM 在每一步替 PPO 改 action,不稳定,也不适合作为当前底层高频控制方案。

但这并不等于 LLM 只能写报告。

本阶段重新定义 Qwen 的位置:

1
Qwen = Commander / Strategic Planner

它不做:

1
2
3
4
5
不直接发 HTTP payload
不直接调用 nmap
不直接调用 sqlmap / hydra / metasploit
不直接替 PPO 选 action_id
不绕过 SafetyGuard

它应该做:

1
2
3
4
5
6
判断当前测试阶段
决定调用哪个 Agent
读取 Agent 返回的结构化结果
决定下一步是 recon / crawl / classify / validate / stop
做 fallback / retry / stop 决策
生成最终报告

也就是说,Qwen 是最高战略决策层,而不是底层执行器。


六、零信任语义通信是什么

本阶段引入了一个关键思想:Agent 之间不能直接用裸自然语言互相命令,也不能盲信 Qwen。

每一条任务必须被包装为结构化语义消息。

典型 message envelope 应包含:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
{
"message_id": "uuid",
"from_agent": "CommanderAgent",
"to_agent": "ReconAgent",
"task_type": "SAFE_PROBE",
"target": "http://127.0.0.1:18080",
"intent": "Collect basic HTTP service information.",
"allowed_actions": ["GET", "HEAD"],
"forbidden_actions": ["SQLI", "XSS", "BRUTEFORCE", "UPLOAD_SHELL"],
"constraints": {
"max_depth": 1,
"max_pages": 20,
"timeout_seconds": 5
},
"evidence_requirements": ["status_code", "headers", "title"]
}

收到消息的 Agent 必须检查:

1
2
3
4
5
6
7
8
from_agent 是否可信
to_agent 是否是自己
task_type 是否属于自己的权限
target 是否在 allowlist 内
method 是否允许
是否包含 payload
是否请求公网目标
是否越权调用 exploit / privesc / brute force

如果校验失败,Agent 必须返回:

1
REFUSED

而不是执行。

这就是本项目中“零信任语义通信”的含义:

每个 Agent 都把上游消息当作不可信输入,必须先校验,再执行。


七、Stage 22 已完成的内容

本阶段已经建立了 prototype/mas/ 多智能体包,主要包括:

1
2
3
4
5
6
7
8
9
10
11
prototype/mas/schemas.py
prototype/mas/message_bus.py
prototype/mas/base_agent.py
prototype/mas/scope_policy.py
prototype/mas/mission_state.py
prototype/mas/commander_agent.py
prototype/mas/recon_agent.py
prototype/mas/vuln_agent.py
prototype/mas/exploit_agent.py
prototype/mas/report_agent.py
prototype/mas/orchestrator.py

其中:

  • schemas.py 定义多智能体消息与任务结构;
  • message_bus.py 负责 Agent 间语义消息传递;
  • base_agent.py 定义 Agent 的基础行为;
  • scope_policy.py 做目标范围与权限控制;
  • mission_state.py 维护任务状态;
  • commander_agent.py 承载 Qwen/template Commander;
  • recon_agent.py 负责安全探测;
  • vuln_agent.py 做候选漏洞分类;
  • exploit_agent.py 当前仍是 stub,不执行真实 exploit;
  • report_agent.py 输出报告;
  • orchestrator.py 串联整个流程。

同时 CLI 新增了:

1
mas-attack

当前验证结果为:

1
2
Commander -> ReconAgent -> 127.0.0.1:18080
检测到 nginx / 1.31.0

这说明 Qwen Commander 和 Agent Team 的调度链路已经跑通。


八、当前多智能体团队分工

1. CommanderAgent

最高战略决策层。

职责:

1
2
3
4
5
读取目标和当前 mission state
生成下一步 semantic task
决定调用 Recon / Vuln / Exploit / Report 哪个 Agent
读取 Agent 返回结果
决定继续、重试、停止或报告

当前可用两种模式:

1
2
template Commander
Qwen Commander

Qwen 可参与战略决策,但输出仍必须经过零信任校验。

2. ScopePolicy / SafetyGuard

安全边界层。

职责:

1
2
3
4
5
6
拒绝公网目标
拒绝未授权 host / port
拒绝越权 action
拒绝危险 payload
拒绝 hydra / metasploit / shell payload
限制当前阶段只能执行安全探测

这是整个真实 Web agent 的底线。

3. ReconAgent

负责安全探测。

当前能力:

1
2
3
4
5
HTTP GET / HEAD
读取 status code
读取 headers
读取 server banner
识别基础服务信息

当前已验证能识别:

1
nginx/1.31.0

4. VulnAgent

负责候选漏洞分类。

当前定位:

1
根据 URL、参数、表单、页面结构判断潜在 SQLi / XSS / upload candidate

当前还没有完成真实漏洞验证。

5. ExploitAgent

当前仍是 stub。

这点必须明确:

ExploitAgent 现在还不是可执行真实攻击的 Agent。

后续它应该被拆成:

1
2
3
4
SQLiAgent
XSSAgent
UploadAgent
CommandInjectionAgent

并且每个 Agent 都必须有独立安全策略。

6. ReportAgent

负责输出结构化报告。

内容包括:

1
2
3
4
5
6
7
8
目标
阶段
Agent 任务
观测结果
证据
拒绝原因
发现项
下一步建议

九、当前真实 Web 渗透能力边界

当前已经能做:

1
2
3
4
5
6
本地目标 scope check
Qwen/template Commander 调度
安全探测
服务识别
结构化报告
零信任消息验证

当前不能做:

1
2
3
4
5
6
真实 SQLi payload 执行
真实 XSS payload 执行
真实文件上传测试
真实登录态维护
真实越权检测
真实 Web 自动化攻击链

所以目前不能说:

1
已经完成真实 Web 自动渗透智能体

更准确的说法是:

1
已经完成真实 Web 渗透多智能体系统的 Commander / 通信 / 安全 / Recon 骨架。

十、为什么下一步应进入 DVWA / Pikachu

nginx toy target 只能证明:

1
2
3
4
Commander 能调度 ReconAgent
HTTP 服务能被识别
消息总线能跑通
报告能生成

但它没有真实 Web 漏洞模块。

如果要验证真正的 Web pentest agent,就必须进入本地授权靶场,例如:

1
2
3
DVWA
Pikachu
自建 toy vulnerable web app

下一阶段的正确目标不是直接“全自动攻击”,而是:

1
2
3
4
5
6
7
本地 Web 靶场
-> crawl
-> form parse
-> vulnerability classification
-> controlled SQLi/XSS validation
-> evidence
-> report

也就是先做受控验证,不做破坏性攻击。


十一、下一阶段建议:Stage 23

下一阶段建议定义为:

1
Stage 23: Local Web Range Active Validation v1

目标:

1
2
3
4
5
启动本地 DVWA / Pikachu / toy vulnerable web app
让 Commander 调度 Agent Team
完成 recon / crawl / form parse / classify
执行受控 SQLi / XSS 验证
生成 evidence report

严格禁止:

1
2
3
4
5
6
7
公网目标
爆破
hydra
metasploit
webshell
命令执行 payload
真实破坏性请求

最小验收应是:

1
2
3
4
5
6
7
1. 本地 Web 靶场可访问
2. Agent Team 能发现页面和表单
3. VulnAgent 能识别 SQLi/XSS candidate
4. SQLiAgent/XSSAgent 只执行受控验证
5. EvidenceAgent 能保存请求、响应、证据片段和 hash
6. ReporterAgent 能输出 JSON/Markdown 报告
7. Qwen Commander 不绕过 SafetyGuard

十二、本阶段关键结论

1. 当前不是继续训练阶段

现有 PPO/BC expert 已经完成仿真任务,当前主要问题不在 RL 训练,而在真实 Web action adapter 与多智能体调度。

2. Qwen 的正确位置是 Commander

Qwen 不应该每一步替 PPO 改动作,也不应该只做事后总结。它应该负责高层战略调度,并通过零信任语义消息调用 Agent Team。

3. Agent 之间不能盲信

无论任务来自 Qwen 还是其他 Agent,都必须经过 Schema、Scope、Role 和 Safety 校验。

4. 当前真实 Web 能力还很早期

现在完成的是 Recon 骨架,不是 exploit 系统。

5. 下一步必须进入本地授权 Web 靶场

仅靠 nginx toy target 无法验证漏洞检测能力。后续应进入 DVWA / Pikachu / 自建 toy vulnerable app,完成 controlled active validation。


十三、当前阶段总结

本阶段最重要的成果不是“已经能打真实网站”,而是把真实 Web 渗透智能体的核心组织形态搭起来了:

1
2
3
4
5
6
7
Qwen Commander
-> zero-trust semantic message
-> Agent Team
-> scope/safety validation
-> safe recon
-> structured observation
-> report

这使项目从原来的:

1
PenGym 仿真 DRL agent

正式推进到:

1
面向真实 Web 靶场的多智能体渗透测试系统雏形

但最终目标还没有完成。下一步必须用本地授权 Web 靶场验证:

1
crawl / form parse / SQLi candidate / XSS candidate / controlled validation / evidence

只有完成这些,才能真正说系统开始具备“面向真实 Web 靶场的渗透测试能力”。