从 DVWA 真实靶场验证到项目收口：Qwen Commander 多智能体渗透测试系统完成闭环

一、这篇文章要说明什么

上一篇记录结束时，项目已经从 PenGym / NASim 仿真智能体，推进到了真实 Web 靶场方向的多智能体系统骨架阶段。

当时已经完成的是：

  • PenGym 仿真线已经稳定；
  • tiny / small / medium family 的 expert 和 router 已经形成完整闭环；
  • 本地 toy target 上完成了 nmap service_scan -> XML -> RealObservationEvent；
  • Qwen 的角色被重新定位为 Commander，而不是 step-level action override；
  • 零信任语义通信和 Web Agent Team 的基础架构已经搭起来。

但是当时还不能说系统已经真正具备 Web 靶场渗透测试能力。因为那时只完成了 nginx toy target 的安全探测，还没有完成：

  • DVWA 登录；
  • Web 页面爬取；
  • 表单解析；
  • SQLi / XSS 候选识别；
  • 受控漏洞验证；
  • 证据加固；
  • Qwen Commander 真实动态调度；
  • 最终报告与 Dashboard。

本阶段的核心，就是把这一条线补完整。

这篇记录要说明的就是：

项目已经从“真实 Web 靶场多智能体系统骨架”，推进到“本地授权 DVWA 靶场上的多模块渗透测试闭环”，并完成 Qwen Commander 真实参与、零信任校验、证据复核和 HTML Dashboard 展示。至此，本项目可以作为一个阶段性完整成果收口。

本阶段最终完成的事情可以概括为八点：

  1. 已将 DVWA 作为本地授权 Web 靶场接入系统；
  2. 已完成 DVWA 登录、会话保持和 security level 设置；
  3. 已实现 crawl -> form parse -> candidate classification -> controlled validation 的 Web 渗透测试链路；
  4. 已覆盖 SQLi、Blind SQLi、Reflected XSS、Stored XSS、CSRF 结构分析、File Upload 表单分析六类模块；
  5. 已完成 EvidenceAgent 与 CriticAgent 加固，使 findings 不再只是“看起来像”，而是有结构化证据和复核结论；
  6. 已确认 Qwen Commander 在配置好百炼 API Key 后真实参与调度，不再 fallback 到 template；
  7. 已生成 JSON、Markdown 和本地 HTML Dashboard；
  8. 已清理源码包、生成设计文档包，项目进入最终交付状态。

二、本阶段与上一篇的关系

上一篇的核心结论是：

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

但上一篇还明确说明：

当前只是 Recon 骨架，不是完整 Web 漏洞验证系统。

本阶段解决的正是这个缺口。

系统从：

1
2
3
nginx toy target
  -> service scan
  -> report

推进为：

1
2
3
4
5
6
7
8
9
10
DVWA local target
  -> login
  -> session
  -> crawl
  -> form parse
  -> vuln classify
  -> controlled SQLi / XSS validation
  -> evidence
  -> critic review
  -> JSON / Markdown / HTML report

也就是说，本阶段不再只是“能探测一个 Web 服务”，而是开始具备“对一个本地授权 Web 靶场做完整渗透测试流程”的能力。

三、当前项目最终形成的两条主线

到本阶段结束，项目已经不能再简单理解成一个 PenGym 训练项目。它已经形成两条主线。

1. PenGym / NASim 仿真智能体线

这一条线是整个项目的原始基础。

当前最终状态是：

1
2
3
4
5
6
scenario
  -> fingerprint router
  -> selected expert
  -> PPO / BC expert action selection
  -> manager-worker trace analysis
  -> 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

这说明仿真侧已经具备稳定 benchmark 能力。

需要强调的是：

当前没有继续训练 PPO / BC / D3QN；训练线已经暂停，已有 expert 被作为稳定资产使用。

2. 真实 Web 靶场多智能体线

这一条线是本阶段的重点。

最终结构是：

1
2
3
4
5
6
7
8
9
Qwen / Template Commander
  -> zero-trust semantic message
  -> SafetyGuard
  -> Agent Team
  -> controlled tools / HTTP session
  -> EvidenceAgent
  -> CriticAgent
  -> ReporterAgent
  -> Dashboard

目标不再是直接输出 NASim action id，而是围绕真实 Web 靶场执行：

1
2
3
4
5
6
7
8
Auth
Crawl
Form parse
Vulnerability classification
Controlled validation
Evidence collection
Critic review
Report generation

这条线目前已经在本地 DVWA 上跑通。

四、DVWA 靶场为什么是关键一步

之前使用 nginx toy target，只能验证：

  • HTTP 服务能访问；
  • nmap 能识别服务；
  • XML 能解析成结构化 observation；
  • Commander 能调度 ReconAgent；
  • SafetyGuard 能限制目标范围。

但 nginx 本身没有漏洞模块，无法验证真正的 Web 渗透测试流程。

DVWA 的价值在于它提供了标准的 Web 漏洞训练模块，例如：

  • SQL Injection；
  • SQL Injection Blind；
  • Reflected XSS；
  • Stored XSS；
  • CSRF；
  • File Upload。

因此，接入 DVWA 后，系统才真正能验证：

1
2
3
4
5
6
7
智能体是否能登录靶场
智能体是否能爬取页面
智能体是否能解析表单
智能体是否能识别漏洞候选
智能体是否能执行受控验证
智能体是否能保存证据
智能体是否能生成报告

本阶段使用的目标严格限制为：

1
http://127.0.0.1:18081

并且仅用于本地授权测试。

五、Stage 23：DVWA 基础渗透验证

Stage 23 的目标是让 MAS 系统第一次真正跑 DVWA。

完成内容包括：

  1. 启动本地 DVWA Docker 靶场；
  2. 访问 http://127.0.0.1:18081；
  3. 使用 admin / password 登录；
  4. 处理 CSRF token；
  5. 保持 requests.Session；
  6. 设置并验证 security level；
  7. 爬取 DVWA 页面；
  8. 解析表单；
  9. 识别 SQLi / XSS 候选；
  10. 执行受控 SQLi / XSS 验证；
  11. 生成 JSON report。

Stage 23 的结果为：

1
2
3
4
5
6
7
8
9
10
11
DVWA running               yes
Login successful           yes
Security level             low
Crawled pages              21
Forms found                15
SQLi candidate             yes
XSS candidate              yes
SQLi controlled validation confirmed
XSS controlled validation  likely
Findings                   2
Commander                  qwen

这一步说明：

系统不再只是结构骨架，而是已经能在真实本地 DVWA 靶场上完成第一轮 Web 漏洞验证。

六、Stage 24：DVWA 多模块扩展验证

Stage 24 的目标是扩展覆盖范围，不再只看 SQLi 和 Reflected XSS。

新增或强化的 Agent 包括：

1
2
3
4
sqli_blind_agent.py
stored_xss_agent.py
csrf_agent.py
upload_agent.py

同时修改了：

1
2
3
4
5
6
config.py
safety_guard.py
vuln_classifier.py
dvwa_orchestrator.py
reporter_agent.py
izumi_cli.py

Stage 24 覆盖的 DVWA 模块为：

模块 结果 说明
SQLi confirmed 受控验证成立
Blind SQLi confirmed true / false 差异成立
Reflected XSS likely marker 被反射
Stored XSS likely marker 存储并再次出现
CSRF likely 只做结构分析，不改状态
File Upload possible 只检测上传表单，不上传文件

这一步的重要意义是：

系统从“能验证两个漏洞”扩展为“能覆盖 DVWA 多个常见 Web 漏洞模块”。

但这一阶段仍然有一个问题：

  • likely 和 possible 的证据强度还不够；
  • XSS / CSRF / Upload 的证据需要进一步细化；
  • 报告需要更像真实渗透测试报告。

这就进入了 Stage 25。

七、Stage 25：证据加固与报告质量升级

Stage 25 的目标不是新增漏洞，而是提高证据质量。

本阶段强化了：

1
2
3
4
5
6
7
EvidenceAgent
CriticAgent
XSSAgent
StoredXSSAgent
CSRFAgent
UploadAgent
ReporterAgent

核心改动包括：

  1. EvidenceRecord 增加完整字段；
  2. 对 cookie、session、token、password、API key 做脱敏；
  3. 每个 finding 都必须有 evidence record；
  4. Reflected XSS 必须看到 harmless marker 原样反射；
  5. Stored XSS 必须二次 GET 后仍能看到 marker；
  6. CSRF 不再写成 confirmed，而是做结构性 candidate；
  7. File Upload 不执行上传，只保留表单 evidence；
  8. Reporter 同时生成 JSON 和 Markdown 报告。

Stage 25 后的结果变化为：

Finding Stage 24 Stage 25 变化
SQLi confirmed confirmed 稳定
Blind SQLi confirmed confirmed 稳定
Reflected XSS likely confirmed 证据增强
Stored XSS likely confirmed 证据增强
CSRF likely candidate 更精确
File Upload possible candidate 更精确

Stage 25 的输出包括：

1
2
./prototype/reports/dvwa_stage25_report.json
./prototype/reports/dvwa_stage25_report.md

这一步使系统从“能发现”进一步变成“能解释为什么发现成立”。

八、Stage 26：DVWA medium security validation

Stage 26 的目标是验证系统是否只能打 low，还是能适应 DVWA medium security。

在 medium 下，部分参数和请求方式发生变化，特别是 SQLi / Blind SQLi 模块需要识别表单方法和安全等级差异。

本阶段主要改动包括：

1
2
3
sqli_agent.py
sqli_blind_agent.py
dvwa_orchestrator.py

关键点：

  • SQLi medium 使用 POST；
  • 使用数字型注入 1 OR 1=1；
  • Blind SQLi 使用 1 AND 1=1 / 1 AND 1=2；
  • Evidence 中记录真实 HTTP method；
  • 不使用 sqlmap；
  • 不做时间盲注；
  • 不执行破坏性请求。

Medium 结果为：

Finding Verdict
SQLi likely
Blind SQLi confirmed
Reflected XSS confirmed
Stored XSS confirmed
CSRF candidate
File Upload candidate

这说明：

系统已经不是只对 low security 的固定页面模式生效，而是开始具备一定的安全等级适配能力。

但 medium 下 SQLi 只达到 likely，这也是合理的，因为它基于 differential evidence，而不是 error marker。

九、Stage 27：Commander 对比框架

Stage 27 的目标是验证 Qwen 是否真的作为 Commander 工作，而不是只做报告生成器。

本阶段实现了：

1
2
3
dvwa_commander.py
commander_comparison.py
test_stage27_commander_comparison.py

并修改：

1
2
3
dvwa_orchestrator.py
reporter_agent.py
izumi_cli.py

新增 CLI：

1
./scripts/izumi mas-compare-commanders

对比对象是：

1
2
template Commander
Qwen Commander

对比维度包括：

  • Commander decision count；
  • Agent call order；
  • findings by type；
  • evidence count；
  • refused actions；
  • SafetyGuard decisions；
  • divergence points；
  • Qwen decision reasons。

不过第一次 Stage 27 中发现一个关键问题：

1
Qwen Commander fallback 到 template

原因是当前 shell / Claude Code 环境没有拿到 DASHSCOPE_API_KEY，导致 BailianClient 初始化失败。

因此，Stage 27 只能证明：

1
2
3
Commander comparison 框架可用
template fallback 可用
SafetyGuard 拦截可用

但还不能证明：

1
Qwen 真实参与 Commander 决策

所以必须补 Stage 27.1。

十、Stage 27.1：真实 Qwen Commander rerun

Stage 27.1 解决的是 Qwen 是否真正参与的问题。

修复方法是：

1
2
3
4
5
重新设置 DASHSCOPE_API_KEY
确保 Claude Code 进程继承环境变量
验证 BailianClient init
验证 Qwen ping
重跑 mas-compare-commanders

最终结果为：

1
2
3
4
5
6
7
DASHSCOPE_API_KEY set   yes
BailianClient init      OK
Qwen ping               OK
Qwen Commander real     yes
Fallback to template    no
qwen_run_skipped        false
qwen_fallback_reason    ""

Qwen Commander 产生了 6 个真实决策：

1
2
3
4
5
6
SQLi
SQLi_Blind
XSS_Reflected
XSS_Stored
CSRF
File_Upload

每个 decision 都包含 Qwen decision reason，例如：

1
2
3
4
5
6
candidate classified as SQLi
candidate classified as SQLi_Blind
candidate classified as XSS_Reflected
candidate classified as XSS_Stored
candidate classified as CSRF
candidate classified as File_Upload

最终对比结果为：

1
2
3
4
template success: True
qwen success:     True
findings match:   True
divergence pts:   0

这说明：

Qwen 已经真实参与 Commander 决策，但在当前 DVWA medium 场景下，它的调度顺序与 template Commander 一致。

这不是坏事。它说明当前任务结构已经足够明确，Qwen 与 template 都选择了同样合理的流程。

但也必须客观承认：

Stage 27.1 证明了 Qwen 真实参与和 SafetyGuard 有效，但还没有证明 Qwen 比 template 更优。

十一、Stage 28：HTML Dashboard

Stage 28 的目标是把 JSON / Markdown 报告升级成本地静态 HTML Dashboard。

新增文件：

1
2
prototype/mas/dvwa/html_reporter.py
prototype/mas/dvwa/test_stage28_html_reporter.py

修改文件：

1
prototype/cli/izumi_cli.py

新增 CLI：

1
2
./scripts/izumi mas-dashboard \
  --output ./prototype/reports/dvwa_dashboard.html

Dashboard 读取：

1
2
3
dvwa_stage25_report.json
dvwa_stage25_medium_report.json
dvwa_stage27_qwen_real_comparison.json

展示内容包括：

  1. Target overview；
  2. Executive summary；
  3. Findings table；
  4. Per-finding evidence；
  5. Qwen Commander trace；
  6. Template vs Qwen comparison；
  7. SafetyGuard refused actions；
  8. Low vs Medium summary；
  9. Limitations。

Stage 28 验收结果：

1
2
3
4
5
6
7
8
9
10
11
12
13
Stage 25 JSON read                 yes
Medium JSON read                   yes
Stage 27.1 Qwen comparison JSON    yes
Findings table rendered            yes
Evidence records rendered          yes
Qwen commander trace rendered      yes
SafetyGuard refused actions        yes
Sensitive redaction complete       yes
External CDN used                  no
New scans/attacks executed         no
Public targets accessed            no
Tests                              16/16 passed
Simulation smoke                   1/1 passed

这一步让项目具备了可演示性：

不只是命令行能跑，而且可以用 Dashboard 展示目标、发现、证据、Qwen 调度和 SafetyGuard 拒绝记录。

十二、系统最终架构

项目最终结构可以概括为：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
PenGym / NASim Simulation Branch
  -> PPO / BC experts
  -> family router
  -> manager-worker
  -> simulation CLI

DVWA Web MAS Branch
  -> Qwen / Template Commander
  -> zero-trust semantic messages
  -> SafetyGuard
  -> AuthSessionAgent
  -> CrawlAgent
  -> FormParserAgent
  -> VulnClassifierAgent
  -> SQLiAgent
  -> BlindSQLiAgent
  -> XSSAgent
  -> StoredXSSAgent
  -> CSRFAgent
  -> UploadAgent
  -> EvidenceAgent
  -> CriticAgent
  -> ReporterAgent
  -> HTML Dashboard

其中 Qwen 的位置非常明确：

1
Qwen = Commander

Qwen 不做：

1
2
3
4
5
不直接发 HTTP 请求
不直接构造 payload
不直接调用工具
不绕过 SafetyGuard
不替 PPO expert 做 step-level action

Qwen 做：

1
2
3
4
5
读取结构化状态
选择下一步 Agent
给出调度理由
输出 semantic task
接受 SafetyGuard 校验

这就是本项目中 LLM 的合理位置。

十三、零信任体系最终落地情况

本项目最终不是简单“让 LLM 调工具”，而是加入了零信任语义通信。

核心原则：

任何 Agent 或 Qwen 输出的任务都不能直接执行，必须先通过结构化消息和 SafetyGuard 校验。

SafetyGuard 拒绝项包括：

1
2
3
4
5
6
7
8
9
10
11
公网目标
非 allowlist host / port
hydra
metasploit
sqlmap
webshell
command injection
反连 payload
破坏性请求
logout / setup 等不应访问路径
upload execution

在实际 Stage 27.1 中，SafetyGuard 仍然生效：

1
2
3
4
39 refused actions per run
blocked_path: setup.php
blocked_path: logout.php
file_upload_blocked

这说明：

即使 Qwen 真实参与决策，系统仍然没有放弃安全边界。

十四、最终交付物整理

功能完成后，项目进入交付整理阶段。

最终源代码包清理原则是：

1
2
只保留项目相关代码、训练脚本、配置、场景、模型/数据资产、Docker 靶场配置
删除所有阶段报告、临时总结、Dashboard 产物、运行报告

最终源码包保留的核心目录包括：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
configs/
cyber_range/
database/
figures/
pengym/
prototype/
research_snapshots/
scripts/
tests/
toy_range/
web_range/
run.py
requirements_*.txt
README.md
LICENSE
CHANGES
CONTRIBUTORS

排除内容包括：

1
2
3
4
5
6
7
8
9
10
11
.venv/
.git/
.claude/
__pycache__/
prototype/reports/*
deliverables/
docs/
logs/
阶段报告
summary 文档
dashboard 产物

最终还单独生成了设计文档包，包括：

1
2
3
4
5
6
7
8
system_design.md
agent_architecture.md
zero_trust_semantic_communication.md
dvwa_validation_report.md
deployment_guide.md
user_manual.md
source_code_structure.md
final_project_summary.md

这样最终提交材料被拆成：

1
2
3
4
源码包
设计文档包
运行视频
HTML Dashboard 演示文件

而不是把所有内容混在源码目录里。

十五、系统能做什么，不能做什么

1. 当前已经能做

1
2
3
4
5
6
7
8
9
10
在 PenGym / NASim 中完成 160/160 仿真 benchmark
在本地 DVWA 中完成登录和会话保持
在本地 DVWA 中爬取页面和表单
识别 SQLi / Blind SQLi / XSS / Stored XSS / CSRF / Upload candidate
执行受控 SQLi / XSS 验证
保存 evidence record
进行 CriticAgent 复核
生成 JSON / Markdown / HTML 报告
让 Qwen 作为 Commander 真实参与调度
使用 SafetyGuard 拒绝越权任务

2. 当前明确不能做

1
2
3
4
5
6
7
8
9
不能攻击公网网站
不能声称支持任意真实网站
不能使用 hydra / metasploit / sqlmap
不能爆破
不能上传 webshell
不能执行 command injection
不能执行反连 payload
不能做真实提权
不能把 DVWA 结果等同于真实企业站点能力

3. 当前没有继续做的内容

虽然可以继续扩展，但本项目最终选择收口，没有继续做：

1
2
3
4
5
6
7
Pikachu 接入
DVWA high security bypass
更多漏洞类型
Command Injection
Metasploitable
真实公网目标
长期自主攻击链

原因很简单：

当前项目已经形成完整研究闭环，继续堆功能会降低主线清晰度。

十六、这个项目最终的意义

这个项目最终不是一个“无约束自动黑客工具”。

更准确地说，它是一个：

1
2
3
从 DRL 仿真自动渗透智能体
迁移到本地授权 Web 靶场多智能体渗透测试系统
的研究原型

它的核心贡献可以概括为四点。

1. 仿真侧完成 expert-router 闭环

项目不是停在单一 PPO 模型，而是通过：

1
2
3
4
5
unified observation/action
BC warm-start
success distillation
actor-freeze PPO
family router

逐步解决 tiny / small / medium family，并形成 160/160 的 simulation benchmark。

2. LLM 位置被重新定义

项目实际排除了 step-level LLM override 这条路，最终把 Qwen 放在 Commander 层。

这个结论很关键：

1
2
LLM 不适合替代低层高频动作策略
LLM 更适合做高层调度、任务分配、失败解释和报告生成

3. 零信任语义通信被落地

项目不是简单让 Qwen 发命令，而是要求所有任务都经过：

1
2
3
4
schema validation
scope validation
role validation
safety validation

这使系统具有基本安全边界。

4. 真实 Web 靶场完成本地闭环

项目最终不只是 PenGym 仿真，也不是只扫 nginx，而是在 DVWA 上完成了：

1
2
3
4
5
6
7
8
auth
crawl
classify
controlled validation
evidence
critic
report
dashboard

这说明它已经具备本地授权 Web 靶场测试系统的雏形。

十七、最终结论：可以收工

本阶段结束后，项目已经可以收工。

当前最终判断是：

项目已经完成从 PenGym 仿真 DRL 智能体，到 Qwen Commander + 零信任语义通信 + DVWA 多智能体 Web 渗透验证系统的完整阶段性闭环。

最终状态不是“万能渗透智能体”，而是：

1
本地授权 Web 靶场多智能体渗透测试研究原型

它已经具备：

1
2
3
4
5
6
7
8
9
10
可运行代码
可复现实验命令
本地 DVWA 验证
真实 Qwen Commander
零信任安全边界
证据与复核体系
JSON / Markdown / HTML 报告
设计文档
源码包
演示材料

因此，继续增加新靶场或新漏洞类型已经不是当前最优选择。

当前最合理的动作是：

1
2
3
4
5
清理源码
打包项目
整理设计文档
录制演示视频
提交阶段性成果

到这里，这一轮“深度强化学习 + 大模型 + 多智能体渗透测试”的项目主线可以正式收束。