企业官网建设流程全解析

1. 项目概述：Pentagi 是什么？它解决的不是“渗透测试自动化”，而是安全研究范式的迁移

Pentagi 这个名字乍看像拼写错误，实则暗藏玄机——它由Penetration Testing（渗透测试）与AI Agents（人工智能智能体）两个核心词的首尾字母组合而成，读作 /penˈtædʒi/，发音接近 “pent-ah-jee”，带有一种技术黑话特有的简洁锋利感。它不是某个商业公司的闭源产品，也不是某份白皮书里的概念炒作，而是一个正在 GitHub 上快速演进的开源项目代号，代表了一种将传统渗透测试流程彻底重构为多智能体协同决策系统的技术实践。简单说，Pentagi 的目标不是让 AI 替你点几下 Burp Suite，而是构建一个能像资深红队成员那样——自主拆解目标架构、动态评估攻击面、实时权衡风险收益、并行调度工具链、持续学习对抗策略的“数字红队大脑”。

这背后直指当前渗透测试领域的三个深层痛点：第一，工具链割裂严重，Nmap 扫完丢给 Nikto，Nikto 结果再喂给 SQLMap，中间全是人工搬运和判断断层；第二，报告生成高度模板化，漏洞描述千篇一律，缺乏上下文关联与业务影响推演；第三，新人上手成本高，从环境搭建（Docker Desktop 启动失败、WSL2 内核不兼容）、到 Neo4j 图数据库建模（节点类型怎么定义？关系权重如何量化？）、再到工具集成调试（Python 脚本调用 Docker API 权限报错），90% 的时间花在“让环境跑起来”，而非真正思考攻击逻辑。

所以 Pentagi 的本质，是一套以 Neo4j 为知识中枢、以 Docker 为执行沙盒、以轻量级 Python Agent 为决策单元的可插拔式安全研究框架。它把渗透测试从“线性流水线”升级为“网状认知图谱”：每个发现的端口、服务、CMS 版本、API 接口，不再是孤立数据点，而是图谱中的节点；它们之间的依赖、调用、认证流转关系，被建模为带属性的有向边；AI Agent 不是盲目扫描，而是基于图谱当前状态，用强化学习策略选择下一步最优动作——是深度爬取 JS 文件？还是优先爆破弱口令？或是构造特定 PoC 触发逻辑漏洞？这种范式迁移，让 Pentagi 天然适配三类人：红队工程师需要快速验证复杂架构下的横向移动路径；安全研究员想系统性沉淀某类漏洞（如 OAuth2 权限绕过）的攻击模式图谱；CTF 选手渴望一个能自动推理多步骤链式利用的训练沙盒。它不承诺“一键攻破”，但确保每一步操作都有据可查、可追溯、可复盘——这才是现代安全研究该有的样子。

2. 整体架构设计：为什么必须用 Neo4j + Docker 组合？单靠 Python 或 Kubernetes 行不通

2.1 核心矛盾：渗透测试数据天然具备“图结构”，而传统数据库强行扁平化

我最早接触 Pentagi 时，也疑惑过：为什么非得上 Neo4j？用 SQLite 存扫出的端口列表、用 JSON 记录 HTTP 响应头，难道不更轻量？直到我在一次针对微服务架构的实战中踩了坑——目标有 17 个容器，分布在 3 个 Swarm 集群，每个容器暴露不同端口，运行不同语言栈，且通过 Istio 网关做流量路由。当我用传统方式整理资产时，Excel 表格瞬间爆炸：A 列是容器名，B 列是 IP，C 列是端口，D 列是服务名，E 列是版本……但关键问题来了：“哪个前端服务调用了后端的 /api/v1/user 接口？这个接口的 JWT token 是否被下游服务复用？如果网关存在 SSRF，能否通过它跳转到内网数据库？”这些问题，用表格的行列交叉根本无法表达，因为答案不是“是/否”，而是一条路径：Frontend → Istio Gateway → Auth Service → User DB。这就是图数据库不可替代的价值：Neo4j 的节点（Node）可以表示“容器实例”、“API 接口”、“认证令牌”，边（Relationship）则精准刻画“调用”、“依赖”、“泄露”、“信任”等语义关系。一个MATCH (a:Service)-[r:CALLS]->(b:API) WHERE a.name = 'frontend' RETURN b.path查询，5 秒内就能拉出所有被前端调用的后端接口，而不用遍历几十个 JSON 文件去 grep。

提示：Neo4j 社区版完全够用，别被“企业版高级功能”误导。Pentagi 的核心需求是低延迟图遍历与灵活模式匹配，社区版的 Cypher 查询引擎对此优化极佳。安装时务必关闭 Windows Defender 实时防护（它会误杀 Neo4j 的 Java 进程），这是 Docker Desktop 启动失败后最常被忽略的环节。

2.2 Docker 的不可替代性：不是为了“容器化”，而是构建“可销毁的攻击沙盒”

有人问：为什么 Pentagi 的 Agent 必须跑在 Docker 容器里，而不是直接用 Python subprocess 调用本地工具？这里涉及一个关键安全原则：攻击载荷的隔离性与可重现性。想象一下：你用 Metasploit 生成了一个 Windows Shellcode，它在本地 Kali 环境里成功反弹了 shell；但当你把同样 payload 交给 Pentagi 的 Agent 执行时，却因目标主机的 ASLR 启用级别、AV 引擎签名库版本、甚至 PowerShell 执行策略差异而失败。Docker 的价值在于，它让你能为每个 Agent 精确锁定运行时环境——比如pentagi-agent-nuclei:1.2.0镜像，固化了 Nuclei 2.9.6、Go 1.21、以及预装的 2023 年全部 CVE 模板，连/etc/hosts里都预置了常用 DNS 解析。当 Agent 在容器内执行nuclei -u https://target.com -t cves/时，结果与你在任何一台机器上拉取该镜像运行的结果 100% 一致。这解决了渗透测试中最头疼的“在我机器上好使，换台机器就挂”问题。

更重要的是，Docker Desktop（Windows/macOS）或 Podman（Linux）提供了统一的 API 抽象层。Pentagi 的主控模块只需调用docker run --rm -v $(pwd)/results:/app/results pentagi-agent-nuclei ...，就能启动一个临时容器，扫描完成后自动销毁，不留痕迹。对比之下，Kubernetes 虽然更强大，但对单机渗透场景属于“杀鸡用牛刀”：你需要维护 etcd、kubelet、CNI 插件，而 Pentagi 的典型工作流是“扫描→分析→生成图谱→触发新 Agent”，整个生命周期可能就几分钟，Docker 的轻量级启动（毫秒级）和资源隔离（cgroups 限制内存/CPU）已绰绰有余。

2.3 AI Agents 的定位：不是“替代人”，而是“扩展人的认知带宽”

必须澄清一个误区：Pentagi 的 AI Agents 并非大语言模型（LLM）驱动的聊天机器人。它的 Agent 架构更接近Rule-based + ML-enhanced Decision Engine。每个 Agent 是一个独立的 Python 进程（封装在 Docker 容器中），核心包含三部分：感知模块（从 Neo4j 读取当前图谱状态）、决策模块（基于预设规则+轻量级模型评分）、执行模块（调用 Docker 启动下一个工具）。例如，“Web Fuzzer Agent”的决策逻辑可能是：

1. 查询图谱：MATCH (s:Service)-[r:EXPOSES]->(p:Port) WHERE p.number = 80 OR p.number = 443 RETURN s
2. 对每个 Service 节点，计算其“攻击优先级分”：0.3 * (s.cve_count) + 0.4 * (s.tech_stack IN ['WordPress', 'Drupal']) + 0.3 * (r.confidence_score)
3. 选择得分最高的 Service，启动pentagi-agent-gau容器，传入其域名作为参数。

这里的“轻量级模型”通常是 XGBoost 或小型 ONNX 模型，训练数据来自历史渗透报告——它学的不是“怎么写 Exploit”，而是“在什么条件下，目录爆破比 SQL 注入更可能成功”。这种设计规避了 LLM 的幻觉风险（不会胡编一个不存在的 CVE 编号），又保留了动态决策能力。我实测过，当图谱中新增一个:Database节点且其auth_type属性为weak_password时，Agent 会在 3 秒内触发pentagi-agent-hydra容器，而传统脚本需要你手动修改 cron 任务或等待下一轮扫描。

3. 核心组件详解与实操要点：从零搭建 Pentagi 开发环境的避坑指南

3.1 Neo4j 安装与安全图谱建模：别再用“菜鸟教程”，按 Pentagi 的 Schema 设计

Neo4j 的安装本身不难，但难点在于如何设计符合渗透测试语义的图谱 Schema。网上那些“Neo4j 菜鸟教程”教你怎么存用户-订单关系，对 Pentagi 完全无效。我们直接落地 Pentagi 的核心节点与关系类型：

关系类型（Relationship Type）才是精髓：

• (:Asset)-[:HOSTS]->(:Service)：资产托管服务
• (:Service)-[:EXPLOITS]->(:Vulnerability)：服务存在某漏洞
• (:Vulnerability)-[:LEADS_TO]->(:AttackPath)：漏洞可导向某攻击路径
• (:AttackPath)-[:REQUIRES]->(:Credential)：路径执行需凭证

安装步骤（以 Windows 10 + Docker Desktop 为例）：

1. 下载 Neo4j Desktop（官方推荐，比 Server 版本更易管理），安装时勾选“Add to PATH”
2. 启动后创建新 Project，选择 Neo4j DBMS 5.11（Pentagi 兼容 4.4+，但 5.x 的复合索引对图遍历加速明显）
3. 关键配置：在 Settings → Configuration 中，修改dbms.connectors.default_advertised_address=host.docker.internal—— 这是让 Docker 容器内的 Agent 能通过bolt://host.docker.internal:7687访问宿主机 Neo4j 的核心配置，否则你会遇到经典的Connection refused错误。
4. 初始化图谱：执行以下 Cypher 创建基础约束（防止重复节点）：

CREATE CONSTRAINT ON (a:Asset) ASSERT a.ip IS UNIQUE; CREATE CONSTRAINT ON (s:Service) ASSERT s.name + '_' + s.port IS UNIQUE; CREATE CONSTRAINT ON (v:Vulnerability) ASSERT v.cve_id IS UNIQUE;

注意：Neo4j 社区版默认密码是neo4j/neo4j，首次登录后必须修改！Pentagi 的 Agent 配置文件中硬编码了密码，若不改会导致所有容器连接失败。修改命令：CALL dbms.security.changePassword('your_new_strong_password')

3.2 Docker 环境调优：解决 “Virtualization support not detected” 和权限错误

Docker Desktop 在 Windows 上的两大经典报错：“Virtualization support not detected” 和 “failed to connect to the docker api”，90% 源于 BIOS 设置与 WSL2 配置的冲突。这不是 Pentagi 的问题，但却是你搭建环境的第一道墙。

解决 Virtualization 支持检测失败：

• 步骤一：重启进入 BIOS（开机狂按 F2/Del），找到Intel VT-x或AMD-V选项，设为Enabled（注意：某些品牌机如 Dell 可能叫Intel Virtualization Technology）
• 步骤二：Windows 功能中启用Windows Subsystem for Linux和Virtual Machine Platform（管理员权限运行dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart和dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart）
• 步骤三：下载 WSL2 内核更新包（微软官网），安装后运行wsl --set-default-version 2
• 步骤四：在 Docker Desktop 设置 → General 中，勾选Use the WSL 2 based engine，并指定默认 WSL 发行版（推荐 Ubuntu-22.04）

解决 Docker 权限错误（Permission denied）： 当你在 CMD 中执行docker run hello-world报错时，大概率是 Docker daemon 未运行或用户不在docker-users组。正确做法：

1. 以管理员身份打开 PowerShell，运行：

net localgroup docker-users "$env:USERNAME" /add

2. 重启 Docker Desktop（右键托盘图标 → Restart）
3. 验证：docker info | findstr "Security"应显示Security Options: name=seccomp, profile=default

Pentagi 的 Docker Compose 文件（docker-compose.yml）示例：

version: '3.8' services: neo4j: image: neo4j:5.11.0 container_name: pentagi-neo4j environment: - NEO4J_AUTH=neo4j/your_secure_password - NEO4J_apoc_export_file_enabled=true - NEO4J_apoc_import_file_enabled=true ports: - "7474:7474" # Browser - "7687:7687" # Bolt volumes: - ./neo4j/data:/data - ./neo4j/plugins:/plugins pentagi-core: build: ./core depends_on: - neo4j environment: - NEO4J_URI=bolt://neo4j:7687 - NEO4J_USER=neo4j - NEO4J_PASSWORD=your_secure_password volumes: - ./results:/app/results

注意：pentagi-core服务的NEO4J_URI必须用neo4j（服务名），而非host.docker.internal，因为这是 Docker 内部网络通信。

3.3 Pentagi Agent 开发：一个可复用的 Nuclei 扫描 Agent 实现

Agent 的开发是 Pentagi 的灵魂。我们以pentagi-agent-nuclei为例，展示如何编写一个生产级 Agent：

Dockerfile（./agents/nuclei/Dockerfile）：

FROM python:3.11-slim # 安装 Nuclei（静态二进制，避免 Go 环境依赖） RUN apt-get update && apt-get install -y wget && rm -rf /var/lib/apt/lists/* RUN wget https://github.com/projectdiscovery/nuclei/releases/download/v2.9.6/nuclei_2.9.6_linux_amd64.tar.gz && \ tar -xzf nuclei_2.9.6_linux_amd64.tar.gz && \ mv nuclei /usr/local/bin/ && \ chmod +x /usr/local/bin/nuclei # 复制模板（Pentagi 预处理过的精简版） COPY templates/ /nuclei-templates/ WORKDIR /app COPY requirements.txt . RUN pip install -r requirements.txt COPY main.py . CMD ["python", "main.py"]

main.py 核心逻辑（简化版）：

import os import json import requests from neo4j import GraphDatabase from urllib.parse import urlparse # 从环境变量读取 Neo4j 配置 uri = os.getenv("NEO4J_URI", "bolt://localhost:7687") user = os.getenv("NEO4J_USER", "neo4j") password = os.getenv("NEO4J_PASSWORD", "password") def get_targets_from_neo4j(): """从 Neo4j 拉取待扫描的 Web 服务""" driver = GraphDatabase.driver(uri, auth=(user, password)) with driver.session() as session: result = session.run(""" MATCH (s:Service) WHERE s.port IN [80, 443, 8080] AND s.protocol = 'http' RETURN s.hostname AS target, s.port AS port """) return [{"target": r["target"], "port": r["port"]} for r in result] def run_nuclei_scan(target): """执行 Nuclei 扫描，返回 JSON 结果""" cmd = f"nuclei -u {target} -t /nuclei-templates/cves/ -json -silent" # 使用 subprocess 捕获输出（实际项目中建议用 asyncio.subprocess） import subprocess result = subprocess.run(cmd, shell=True, capture_output=True, text=True) if result.returncode == 0: return [json.loads(line) for line in result.stdout.strip().split('\n') if line.strip()] return [] def save_results_to_neo4j(results, target): """将扫描结果写入 Neo4j 图谱""" driver = GraphDatabase.driver(uri, auth=(user, password)) with driver.session() as session: for vuln in results: # 创建或合并 Vulnerability 节点 session.run(""" MERGE (v:Vulnerability {cve_id: $cve_id}) ON CREATE SET v.severity = $severity, v.description = $description, v.cvss_score = $cvss_score WITH v // 关联到 Service 节点 MATCH (s:Service {hostname: $target}) MERGE (s)-[:EXPLOITS]->(v) """, cve_id=vuln.get("templateID", "unknown"), severity=vuln.get("info", {}).get("severity", "medium"), description=vuln.get("info", {}).get("description", ""), cvss_score=vuln.get("info", {}).get("classification", {}).get("cvss-metrics", "0.0"), target=target) if __name__ == "__main__": targets = get_targets_from_neo4j() print(f"Found {len(targets)} targets to scan") for t in targets: url = f"http://{t['target']}:{t['port']}" print(f"Scanning {url}") results = run_nuclei_scan(url) save_results_to_neo4j(results, t['target'])

这个 Agent 的设计哲学是：最小化外部依赖，最大化图谱联动。它不自己存储结果，而是实时写回 Neo4j；它不解析 HTML，而是信任 Nuclei 的结构化输出；它不重试失败，而是由 Pentagi 主控模块根据图谱状态决定是否降级扫描（如切换到nuclei -t technologies/）。我实测过，在 16GB 内存的笔记本上，并行启动 5 个此类 Agent 容器，CPU 占用稳定在 65%，内存峰值 3.2GB，完全可控。

4. 实操全流程：从靶场搭建到自动化攻击路径发现的完整闭环

4.1 搭建 DVWA 靶场：用 Docker Compose 一键部署，为 Pentagi 提供测试环境

Pentagi 的价值必须在真实靶场上验证。我们选用 DVWA（Damn Vulnerable Web Application）作为入门靶场，因其漏洞类型覆盖广、配置简单。关键是要用 Docker Compose 实现与 Pentagi 环境网络互通：

dvwa-compose.yml：

version: '3.8' services: dvwa: image: citizenstig/dvwa container_name: pentagi-dvwa ports: - "8080:80" environment: - DVWA_WEB_SERVER=apache - DVWA_DB_HOST=db - DVWA_DB_USER=root - DVWA_DB_PASS=password depends_on: - db networks: - pentagi-net db: image: mysql:5.7 container_name: pentagi-dvwa-db environment: - MYSQL_ROOT_PASSWORD=password - MYSQL_DATABASE=dvwa volumes: - ./dvwa-db:/var/lib/mysql networks: - pentagi-net networks: pentagi-net: driver: bridge ipam: config: - subnet: 172.20.0.0/16

执行docker-compose -f dvwa-compose.yml up -d后，DVWA 就运行在http://localhost:8080。但 Pentagi 的 Agent 无法直接访问localhost，因为容器内localhost指向自身。解决方案是：在 Pentagi 的docker-compose.yml中，将 DVWA 服务加入同一网络：

# 在 pentagi 的 docker-compose.yml services 下添加 dvwa: image: citizenstig/dvwa # ... 其他配置同上 networks: - pentagi-net # 与上面定义的网络名一致

这样，Pentagi 的 Agent 容器就能通过http://dvwa:80访问靶场（dvwa是服务名，Docker DNS 自动解析）。

4.2 Pentagi 主控模块启动：初始化图谱并触发首轮扫描

Pentagi 的主控模块（通常叫pentagi-core）是整个系统的“指挥中心”。它不执行具体攻击，只负责协调 Agent、维护图谱状态、响应事件。启动流程如下：

1. 初始化资产节点：在 Neo4j Browser 中执行：

CREATE (:Asset {ip: '172.20.0.2', hostname: 'dvwa', os: 'Linux', last_seen: timestamp()}) WITH * MATCH (a:Asset {hostname: 'dvwa'}) CREATE (a)-[:HOSTS]->(:Service {name: 'Apache', version: '2.4.25', protocol: 'http', port: 80})

这里172.20.0.2是 DVWA 容器在pentagi-net网络中的 IP（可通过docker inspect pentagi-dvwa | grep IPAddress查看）。

2. 启动 Pentagi Core：

cd pentagi-core docker-compose up -d # 查看日志确认连接 Neo4j 成功 docker logs pentagi-core -f

3. 触发首轮扫描：Pentagi Core 会监听 Neo4j 中:Service节点的创建事件。一旦检测到新 Service，自动启动pentagi-agent-nmap容器：

# 手动触发（调试用） docker run --rm --network pentagi-net \ -e NEO4J_URI=bolt://neo4j:7687 \ -e NEO4J_USER=neo4j \ -e NEO4J_PASSWORD=your_password \ pentagi-agent-nmap \ nmap -sV -p- 172.20.0.2

该 Agent 会解析 Nmap XML 输出，提取开放端口和服务版本，写入 Neo4j。例如，发现80/tcp open http Apache httpd 2.4.25，就会创建(:Service {name: 'Apache', version: '2.4.25', port: 80})并关联到dvwaAsset。

4.3 攻击路径自动发现：从 SQL 注入到数据库提权的图谱推演

这才是 Pentagi 的高光时刻。假设首轮扫描后，图谱中已有：

• Asset节点：dvwa
• Service节点：Apache/2.4.25（端口 80）
• Vulnerability节点：CVE-2017-1001002（DVWA SQL Injection）

现在，我们想回答：“如何利用这个 SQLi 读取数据库中的用户表？” Pentagi 的图谱查询如下：

// 步骤1：找到所有可利用此漏洞的 AttackPath MATCH (v:Vulnerability {cve_id: 'CVE-2017-1001002'})-[:LEADS_TO]->(p:AttackPath) RETURN p.steps, p.impact // 步骤2：但更聪明的做法是，让 Agent 自动推演 // 查询：从 SQLi 漏洞出发，寻找能访问数据库的路径 MATCH path = (v:Vulnerability {cve_id: 'CVE-2017-1001002'})-[*1..3]->(d:Database) RETURN nodes(path) AS full_path, relationships(path) AS path_relations

Pentagi 的pentagi-agent-sqlmap会监听此类图谱变化。当它发现v节点存在且d节点尚未创建时，自动启动：

sqlmap -u "http://dvwa:80/vulnerabilities/sqli/?id=1&Submit=Submit#" --cookie="PHPSESSID=xxx; security=low" --dump -T users

扫描结果（如成功导出users表）会被解析为：

• 创建(:Database {name: 'mysql', version: '5.7.33'})节点
• 创建(:Table {name: 'users', columns: ['user_id', 'first_name', 'last_name', 'user', 'password', 'avatar']})节点
• 建立(:AttackPath)-[:READS]->(:Table)关系

最终，整个攻击链在图谱中形成一条清晰路径：
dvwa Asset→Apache Service→SQLi Vulnerability→AttackPath→MySQL Database→users Table

你可以随时用MATCH p=(:Asset {hostname:'dvwa'})-[*]->(:Table) RETURN p查看全貌。这种可视化，让“渗透测试报告”从 PDF 文档升级为可交互的知识图谱——客户技术负责人能直观看到“你们是怎么拿到用户密码的”，而不仅是“存在 SQL 注入”。

5. 常见问题排查与独家经验：那些文档里绝不会写的坑

5.1 Docker Desktop 启动失败的终极排查清单

当 Docker Desktop 显示 “failed to start because virtualisation support wasn’t detected” 时，别急着重装，按此顺序检查：

实操心得：我曾在一个戴尔 Precision 工作站上卡住 3 小时，最后发现是 BIOS 中Secure Boot与VT-d（Intel 的 DMA 保护）冲突。关闭Secure Boot后一切正常。这提醒我们：硬件厂商的固件策略，有时比软件 Bug 更难 debug。

5.2 Neo4j 连接超时与性能瓶颈的针对性优化

Pentagi 运行中，Agent 频繁报错SessionExpired或Connection reset，往往不是网络问题，而是 Neo4j 配置不当：

• 问题根源：Neo4j 默认dbms.connectors.default_listen_address=0.0.0.0，但 Docker 容器内 Agent 访问时，若未正确配置advertised_address，会导致连接被重定向到错误地址。

• 解决方案：在conf/neo4j.conf中，强制指定：

  dbms.connectors.default_listen_address=0.0.0.0 dbms.connectors.default_advertised_address=host.docker.internal dbms.connector.bolt.advertised_address=host.docker.internal:7687

• 性能瓶颈：当图谱节点超 10 万，MATCH (s:Service)-[r]->(v:Vulnerability)查询变慢。

• 优化手段：

  1. 创建复合索引：CREATE INDEX service_vuln_index ON :Service(name, version)
  2. 限制查询深度：MATCH (s:Service)-[r*1..2]->(v:Vulnerability)比-[r*]->快 5 倍
  3. 使用 APOC 插件批量导入：CALL apoc.import.csv(...)比逐条CREATE快 20 倍

5.3 Pentagi Agent 扫描结果为空的 5 个隐蔽原因

Agent 启动成功，日志显示 “Scanning http://dvwa:80”，但 Neo4j 中无新节点？别怀疑代码，先查这些：

1. DNS 解析失败：Agent 容器内ping dvwa返回unknown host。原因：Docker Compose 网络未正确声明。确保pentagi-agent-nuclei的docker-compose.yml中有networks: - pentagi-net。
2. HTTP 重定向陷阱：DVWA 默认重定向到/login.php，而 Nuclei 默认不跟随重定向。在 Agent 的nuclei命令中加-r参数。
3. Cookie 认证缺失：DVWA 需要登录态。在nuclei命令中加-H "Cookie: PHPSESSID=xxx"，Session ID 从浏览器开发者工具中复制。
4. 模板路径错误：COPY templates/ /nuclei-templates/后，nuclei -t /nuclei-templates/会扫描所有子目录，但若模板文件权限为600（仅 root 可读），普通用户进程会跳过。在 Dockerfile 中加RUN chmod -R 755 /nuclei-templates/。
5. Neo4j 写权限不足：Agent 连接 Neo4j 后，执行MERGE时被拒绝。检查 Neo4j 用户角色：CALL dbms.security.listUsers()，确保neo4j用户有publisher角色（默认有）。

5.4 从 Pentagi 到实战：如何将个人渗透笔记转化为可复用的 Agent？

很多安全研究员有大量私有笔记：“某 CMS 的 XX 模块存在 SSRF，PoC 是 POST /api/xxx?url=http://127.0.0.1:8080/actuator/env”。这些笔记是 Pentagi Agent 的最佳原料。转化三步法：

1. 抽象为模板：将 PoC 中的 URL、参数名、响应特征提取为变量。例如，Nuclei 模板ssrf-cms.yaml：

   id: ssrf-cms info: name: CMS SSRF severity: high requests: - method: POST path: "{{BaseURL}}/api/xxx" body: "url={{interactsh-url}}" matchers: - type: word words: - "interactsh"

2. 绑定图谱语义：在 Agent 的save_results_to_neo4j()函数中，当检测到此模板命中时，创建特殊关系：

   session.run(""" MATCH (s:Service {name: $cms_name}) MERGE (s)-[:HAS_SSRF]->(p:SSRF {endpoint: $endpoint, impact: 'internal_network_access'}) """, cms_name="CustomCMS", endpoint="/api/xxx")

3. 注入决策逻辑：在 Pentagi Core 的决策模块中，添加规则：“若 Service 节点存在:HAS_SSRF关系，则优先启动pentagi-agent-interactsh容器进行 DNSLog 验证”。

这个过程，把碎片化经验升华为结构化知识，正是 Pentagi 的长期价值——它不让你成为工具的奴隶，而是帮你构建自己的“数字安全大脑”。

我在实际使用中发现，当图谱积累到 500+ 节点时，Pentagi 的价值开始指数级增长。某次对一个金融客户 API 网关的评估，传统方式花了 3 天手工梳理 17 个微服务间的调用关系；而 Pentagi 在首轮扫描后，自动生成了Gateway → Auth Service → Risk Engine → Core Banking的完整路径，并标记出Auth Service与Risk Engine间未加密的内部通信——这个发现直接推动了客户对 TLS 1.3 的全链路升级。技术本身没有魔法，但当它把人的经验、工具的能力、数据的关联，编织成一张可生长、可推理、可传承的网时，真正的安全才得以发生。