夜雨聆风先说边界：
这篇只讲授权环境、内部靶场、安全评估、蓝队验证里的部署和使用。不要拿它扫公网，不要碰没有授权的目标。
AI 自主渗透测试这件事，已经从“让模型帮我写命令”进入到“模型编排工具、收集证据、生成报告”的阶段。
今天这个项目叫：Zen-AI-Pentest。
仓库地址：
https://github.com/SHAdd0WTAka/Zen-Ai-Pentest
截至我核实时，仓库信息大概是：
Star：429+ Fork：75+ License：MIT 主语言：Python 项目版本： 3.0.0Python 要求：项目元数据写的是 >=3.9，README badge 写 Python 3.10+定位：AI-Powered Penetration Testing Framework 官方描述：自动化漏洞扫描、多 Agent 系统、合规报告
它不是单个扫描器，而是把 LLM、ReAct Agent、FastAPI、Docker、报告系统和一堆安全工具串成一套框架。
官方 README 里写得很猛：
72+ integrated security tools 11 specialized personas 8 MCP servers 95 skills ReAct Pattern：Reason → Act → Observe → Reflect 4-Level Safety：Read-Only → Full exploitation 报告格式：PDF / HTML / DOCX / JSON 合规映射：ISO 27001 / PCI DSS / NIST
听起来像“AI 红队操作系统”。但实际使用时，别被宣传词带跑，真正值得关注的是三件事：
它的架构是不是能落地 它的安全护栏够不够硬 它能不能把一次测试变成可复盘证据和报告
它到底是什么：不是“神器”，而是 AI 编排层
很多人看到“AI Pentest”就以为它会自动变黑客。
实际更准确的理解是：
Zen-AI-Pentest 是一个 AI 编排框架，把已有安全工具、任务队列、风险控制、证据收集和报告生成组织起来。
传统渗透测试流程大概是：
资产发现 端口服务识别 Web 指纹和目录枚举 漏洞扫描 人工验证 风险评级 写报告 复测
Zen-AI-Pentest 想做的是，把这条链路里的大量重复动作交给 agent 编排：
Recon Agent 做信息收集 Exploit Agent 做授权验证 Report Agent 做报告输出 Audit / Cloud / AD / OSINT 等 Persona 做专项分析 Guardrails 控制目标边界和风险等级 Evidence 模块留存证据 Risk Engine 做 CVSS/EPSS/业务影响评分
核心不是“AI 代替安全工程师”，而是：
AI 把工具调用、上下文整理、证据归档、报告初稿这些脏活累活串起来。
这对红队、蓝队、甲方安全运营都有价值。
项目结构与关键组件
从 README 和仓库元数据看，它的主架构可以拆成几层。
1）入口层
React Dashboard Python CLI REST API WebSocket Web Terminal WhatsApp Bot
这意味着它既能当命令行工具，也能当 Web 平台，还能通过 API 集成到别的流程里。
2）API 层
FastAPI JWT / RBAC Auth WebSocket Manager
这部分负责认证、任务提交、实时状态推送。
3）AI 编排层
Agent Manager Guardrails Task Queue Risk Levels 0-3 ReAct State Machine
README 里状态机写得很清楚：
IDLE → PLANNING → EXECUTING → OBSERVING → REFLECTING → COMPLETED
这套设计很像现在主流 agent 框架：先规划，再执行，再观察结果，再反思修正。
4）工具层
官方列出的工具很多，包括：
网络扫描：nmap、masscan、scapy、tshark、tcpdump Web 安全：SQLMap、Gobuster、OWASP ZAP、FFuF、Nikto、WAFW00F、WhatWeb、Nuclei 利用验证：Metasploit、SearchSploit 爆破类：Hydra、Hashcat、John、Ncrack 侦察类：Amass、Subfinder、HTTPX、TheHarvester、Sherlock AD：BloodHound、NetExec、Responder、ldapsearch、enum4linux 代码分析：Semgrep、TruffleHog、Gitleaks、Bandit 容器：Trivy、Docker、Kubectl
注意：工具列得多，不代表你应该全部启用。企业内部落地时，默认应该只开 Recon / Scan / Report，Exploit 类动作必须人工确认。
5）数据层
PostgreSQL：持久化状态 Redis：缓存和队列 File Storage：报告和证据
这部分很关键。因为专业安全评估不是“扫一下看看”，而是要能回答：
谁在什么时间执行了什么动作？ 目标范围是否符合授权？ 漏洞证据是什么？ 风险评级依据是什么？ 报告是否能复现？
部署方式一：Docker Full Stack
如果只是试用，Docker 是最省事的路线。
官方 README 给的流程是：
git clone https://github.com/SHAdd0WTAka/zen-ai-pentest.git
cd zen-ai-pentest
cp .env.example .env
# 编辑 .env，设置 OPENCODE_API_KEY=oc_xxx
docker compose up -d
但注意，GitHub 仓库真实地址大小写是：
git clone https://github.com/SHAdd0WTAka/Zen-Ai-Pentest.git
cd Zen-Ai-Pentest
.env.example 里核心配置包括：
OPENCODE_API_KEY=oc_xxx
WA_ALLOWED_USERS=+1234567890,+9876543210
AI_MODEL=oc/deepseek-v4-flash-free
OMNIROUTE_PROXY=
VPN_SSH_JUMP=
KS_CHECK_INTERVAL=15
KS_VPN_PROVIDER=wireguard
MSF_HOST=localhost
MSF_PORT=55553
MSF_TOKEN=password
Docker Compose 暴露的关键服务：
Web Terminal： :8080OmniRoute AI： :20128Hermes Agent： :9090WhatsApp Bot：内部服务，QR 数据挂载在 volume VPN Proxy / WireGuard Proxy：用于代理和连接切换
这里要提醒一句：
Compose 文件里有 Docker socket 只读挂载，以及 SYS_PTRACE / SYS_ADMIN 等 capability。
这类权限在安全工具平台里很常见，但也意味着它不适合直接跑在办公网生产机器上。
我的建议：
单独虚拟机 单独 Docker 网络 单独靶场 VPC 不和办公终端、域控、生产库混在一起 .env不进 GitAPI Key 用最小权限
部署方式二：本地 Python 安装
如果不想跑全套 Docker，也可以本地安装核心依赖。
官方 README 给的是：
pip install -r requirements.txt
python database/models.py
python api/main.py
requirements.txt 里比较关键的依赖包括：
requests aiohttp python-dotenv pydantic fastapi uvicorn dnspython sqlalchemy pyjwt psutil docker celery langchain-core langgraph cryptography
本地跑适合做二次开发和研究框架逻辑，但真要跑工具链，Docker 更容易把环境隔离好。
建议 Python 环境：
python -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt
如果你只是看代码，不建议一上来把所有外部工具都装满。先跑 API、看 agent 逻辑、看报告模块，比盲目堆工具更有价值。
安全使用前，先把靶场搭好
这类工具最容易犯的错，是部署完直接拿公网域名试。
正确做法应该是：
DVWA OWASP WebGoat Juice Shop VulnHub Hack The Box 自有靶机 内部授权测试环境 公司安全评估白名单资产
测试前至少写清楚：
目标范围：IP、域名、端口、系统 测试窗口：什么时候可以跑 风险级别：是否允许验证漏洞 流量限制：是否限制并发和速率 数据边界：是否允许截图、抓包、保存证据 应急联系人：如果误触发告警找谁
没有这些，自动化工具越强，风险越大。
基础使用：从 Recon 和报告开始
官方 README 里给了一组 CLI 示例：
deep-recon --target example.com
deep-exploit --target example.com --force
deep-audit --target example.com --phases recon,scan,exploit,report
deep-report --scan-id wf-abc123 --format pdf
我不建议新手一上来跑 exploit，更不建议 --force。
更稳的路线是：
第一步：只做信息收集
目标换成你自己的靶场或授权域名，例如：
deep-recon --target lab.example.local
你要观察的不是“扫出多少漏洞”，而是：
任务是否进入队列 Agent 是否生成合理计划 工具调用是否符合预期 输出是否能归档 有没有越界目标
第二步：只做扫描，不做利用
如果项目支持 phase 控制，建议先控制在：
deep-audit --target lab.example.local --phases recon,scan,report
重点看：
Web 指纹识别 端口服务识别 常规漏洞模板命中 误报比例 报告是否能解释风险
第三步：人工确认后再做验证
真正涉及 Exploit Validation 的动作，必须满足：
靶场或书面授权 风险等级明确 有人工确认 有回滚预案 有日志留存
企业里可以把风险级别做成策略：
| 风险级别 | 允许动作 |
|---|---|
| Level 0 | 只读信息收集 |
| Level 1 | 轻量扫描、版本识别 |
| Level 2 | 非破坏性漏洞验证 |
| Level 3 | 高风险验证，必须人工审批 |
这和 README 里提到的 4-Level Safety 思路一致。
REST API：适合集成到内部流程
README 给了 REST API 的使用方式。
登录接口示例：
curl -X POST http://localhost:8000/auth/login \
-H "Content-Type: application/json" \
-d '{"username":"admin","password":"admin"}'
创建扫描任务示例：
curl -X POST http://localhost:8000/scans \
-H "Authorization: Bearer $TOKEN" \
-H "Content-Type: application/json" \
-d '{"name":"Lab Scan","target":"lab.example.local","scan_type":"network"}'
生成报告示例：
curl -X POST http://localhost:8000/reports \
-H "Authorization: Bearer $TOKEN" \
-d '{"scan_id":1,"format":"pdf","template":"default"}'
这里我建议做两件改造：
不要用默认账号密码 在 API 层加目标白名单校验
比如只允许扫描：
10.10.10.0/24*.lab.local内部授权资产清单里的域名
任何不在白名单的目标，直接拒绝。
这比事后解释“误扫了”靠谱多了。
WebSocket：适合做实时扫描看板
README 里还有 WebSocket 示例：
const ws = new WebSocket("ws://localhost:8000/ws/scans/1");
ws.onmessage = (event) => {
const data = JSON.parse(event.data);
console.log("Scan update:", data);
};
这个功能很适合接 SOC 或安全运营平台：
实时任务进度 工具调用状态 发现数量变化 风险等级变化 证据采集状态
如果做成内部平台，建议加：
操作审计 用户权限隔离 任务审批流 任务暂停/终止按钮 速率限制 目标范围可视化
MCP Server 和 Skills：看起来很野，但价值在“工具标准化”
项目 README 里提到 8 个 MCP servers：
omni-ai：AI chat / vision / web extractqterminal：Shell / Docker orchestrationzen-agents：11-agent orchestrationmetasploit：Metasploit RPC connectorvpn-killswitch：连接失败切换obscura：加密 secret vaultip-tracker：IP tracking
还提到 95 个 skills，覆盖框架、平台、工具、模块。
这部分最有意思。
因为安全自动化最大的问题不是“没有工具”，而是：
工具参数不统一 输出格式不统一 证据结构不统一 任务状态不统一 报告模板不统一
MCP + Skills 的价值，就是把一堆命令行工具包装成可被 agent 理解和调度的标准能力。
但也要注意：
能调度 Shell / Docker / Metasploit 的系统，本身就是高危系统。
必须限制：
哪些工具可用 哪些参数可用 哪些目标可用 哪些动作需要人工确认 哪些输出不能离开本地环境
它适合谁？
适合
安全研究员研究 AI Pentest 框架 红队在授权靶场里做流程编排 蓝队验证检测规则覆盖率 安全运营团队生成初步评估报告 企业内部做资产暴露面巡检 教学环境演示 AI + 工具编排
不适合
没有授权就扫公网 完全不懂安全的人当“一键黑客工具” 直接部署在生产办公网 把 API Key、扫描结果、凭证随便传外部模型 对高风险验证动作完全放权给 agent
和传统工具比，Zen-AI-Pentest 强在哪里？
传统工具解决的是单点问题：
nmap 负责端口 nuclei 负责模板扫描 sqlmap 负责 SQL 注入验证 trivy 负责容器漏洞 semgrep 负责代码规则 ZAP 负责 Web 动态扫描
Zen-AI-Pentest 想解决的是流程问题：
谁先跑？ 跑完怎么看？ 结果怎么去重？ 哪些风险优先？ 证据怎么保存？ 报告怎么生成？ 下一步该做什么？
这就是 AI 编排层的价值。
但它也有天然风险：
Agent 可能误判目标边界 LLM 可能幻觉工具结果 自动化可能放大误操作 扫描结果可能有大量误报 高权限容器和 Docker socket 需要特别保护 第三方 API 和模型调用涉及数据出域
所以我的建议是：
把它当“安全工程师副驾驶”，不要当“无人驾驶攻击机”。
企业落地怎么做
第 1 步：只部署在隔离靶场
先用 DVWA / WebGoat / Juice Shop 跑通。
目标是验证：
部署能否成功 Web / API / CLI 是否能用 报告是否生成 日志是否完整 agent 是否会越界
第 2 步：接入内部授权资产清单
不要让用户自由输入目标。
目标来源应该是：
CMDB BAS 平台 漏扫平台资产表 手工审批白名单
第 3 步：禁用高风险动作
默认只开：
Recon Scan Report Evidence
Exploit、Brute Force、Metasploit 类能力默认关闭，需要审批打开。
第 4 步：把输出接入整改流程
报告不是终点，整改才是。
建议输出字段至少包括：
资产 漏洞名称 风险等级 证据截图/请求响应 复现条件 影响范围 修复建议 责任人 复测状态
第 5 步：用它反向验证蓝队
这类框架不只适合红队，也适合蓝队：
触发一次授权扫描 看 EDR 有没有告警 看 SIEM 有没有关联 看 DNS/Proxy 日志是否完整 看 SOC 是否能识别自动化扫描行为 看告警处置流程是否跑通
这就是从“渗透测试工具”升级成“检测工程验证工具”。
安全注意事项
再强调一次：这类框架一定要加护栏。
最少做这些：
目标白名单 扫描速率限制 高风险动作人工确认 API 认证和 RBAC Docker / 容器权限隔离 .env和密钥单独管理证据目录加权限控制 所有任务完整审计 外部模型调用前做数据脱敏 生产环境只读优先
尤其是 Docker Compose 里涉及 SYS_ADMIN、SYS_PTRACE、Docker socket 只读挂载，这些都不是“小权限”。部署时必须按高危平台对待。
我的判断
Zen-AI-Pentest 这类项目代表一个趋势：
渗透测试正在从“工具驱动”走向“Agent 编排驱动”。
过去安全工程师像指挥一堆散兵游勇：nmap 一下、nuclei 一下、sqlmap 一下、截图、复制、写报告。
现在 AI 框架开始把这些动作变成流水线：
规划 执行 观察 反思 证据 风险 报告
它不一定马上取代专业红队，但一定会改变初级安全评估、靶场训练、漏洞复测和检测验证的效率。
真正值得关注的不是“它能不能一键打穿”，而是：
它能不能把安全测试变成可控、可审计、可复盘、可集成的工程流程。
如果答案是能，那它就是未来安全平台的一块拼图。
如果没有护栏，那它也可能是事故发生器。
最后一句：
AI 渗透测试框架最重要的能力，不是自动攻击，而是自动化地守住边界。
推荐阅读：
自动化渗透测试 vs BAS：企业安全防护的双剑合璧 AI渗透测试避坑指南 Shadowrend斩影1.0——集成AI大模型的渗透测试框架 骂骂咧咧教你用MCP开发扫描小程序AI工具 IDA逆向分析不再重复劳动：MCP × LLM的自动化实践 什么是威胁狩猎?
交个朋友 加我进群 交流前沿AI和网络安全技术