企业官网建设流程全解析

1. 项目概述：Pentagi 是什么？它解决的不是“渗透测试自动化”，而是“攻击链认知建模”的根本问题

你搜“pentagi”时，首页跳出的全是 Docker、Neo4j、AI Agents 这些词——但它们不是拼凑的标签，而是构成 Pentagi 的三根承重柱。我第一次在 GitHub 上看到这个项目仓库时，也以为是又一个用 AI 跑 nmap + sqlmap 的脚本合集。直到我花三天时间把它本地跑通、手动注入几条真实红队行动日志、再用 Neo4j Browser 点开那张动态生成的图谱，才真正明白：Pentagi 的核心价值，从来不是“让渗透测试更快”，而是把模糊的、经验性的、高度依赖个人记忆的攻击路径，变成可存储、可追溯、可推理、可复盘的结构化知识资产。

简单说，Pentagi 是一个面向红队/紫队/威胁模拟团队的攻击生命周期图谱引擎。它不替代 Burp 或 Cobalt Strike，而是站在它们之上，做一件更底层的事：把每次扫描发现的端口、每次利用成功的漏洞、每次横向移动跳转的主机、每次提权拿到的凭证，自动关联成一张带时间戳、带置信度、带战术标签（MITRE ATT&CK ID）、带人工标注节点的有向图。你看到的不是一堆 JSON 报告，而是一张活的、会生长的“攻击地图”。比如，当你在靶机上执行完 BloodHound 收集，Pentagi 不是简单存下 JSON，而是自动识别出User1 → Group2 → DomainAdmin这条路径，并标记为T1087.002 (Domain Account Discovery)+T1098 (Account Manipulation)，同时关联到你三天前在同一域内用 Metasploit 利用 CVE-2021-42287 打下的另一台 DC——这张图开始自己“说话”了。

它适合谁？不是刚学 Kali 的新手，而是已经能熟练写 Python PoC、会配 Cobalt Strike C2、知道怎么绕过 AMSI 的中级以上红队成员；是负责蓝队检测规则开发的安全工程师，需要从真实攻击链中反推检测盲点；更是 SOC 团队的 TTP 分析师，面对海量 EDR 告警，急需把离散事件聚合成可理解的攻击故事。Pentagi 不降低技术门槛，但它把“经验”变成了“可复用的资产”。我试过把去年某次金融客户红队演练的全部日志喂给它，3 小时后生成的图谱里，自动标出了 3 条此前未被注意的隐蔽横向路径——其中一条直接连通了核心支付网关和 DMZ 区的旧版 Jenkins，而这个 Jenkins 在所有资产清单里都标记为“已下线”。

2. 整体架构设计与技术选型逻辑：为什么必须是 Docker + Neo4j + AI Agents 的铁三角组合？

2.1 架构全景：三层解耦，各司其职，拒绝“大杂烩式集成”

Pentagi 的架构不是把一堆工具塞进一个容器，而是严格分层：数据采集层 → 图谱构建层 → 智能推理层。每一层都独立部署、独立伸缩、独立升级，这才是它能在真实红队环境中稳定运行的关键。

• 数据采集层（Data Ingestion Layer）：这是 Pentagi 的“感官系统”。它不主动扫描，而是被动接收来自各类安全工具的标准化输出。官方支持的输入源包括：Nmap XML、Nessus .nessus、Burp Suite State File (.burp)、Cobalt Strike Beacon Log、BloodHound JSON、OpenVAS Report XML、甚至自定义的 CSV（含 IP、Port、Service、CVE、Exploit Status 字段）。关键设计在于：所有输入都经过统一的 Schema Translator 模块，强制映射到 Pentagi 的核心实体模型——Host、Service、Vulnerability、Credential、Tactic、Technique。比如，Nessus 报告里的Plugin ID: 12345和 Burp 的Issue Name: SQL Injection，都会被翻译成同一个 MITRE ATT&CK Technique IDT1190。这个翻译表不是硬编码，而是 YAML 配置文件，允许团队根据自己的战术库定制。

• 图谱构建层（Graph Construction Layer）：这是 Pentagi 的“骨骼与神经”。它只做一件事：把清洗后的结构化数据，按预设关系规则，写入 Neo4j 图数据库。核心关系类型只有 5 种：HOST_HAS_SERVICE、SERVICE_HAS_VULNERABILITY、VULNERABILITY_EXPLOITED_BY、CREDENTIAL_USED_ON、TECHNIQUE_APPLIED_TO。没有冗余关系，没有模糊连接。每条边都带timestamp、confidence_score（来自工具置信度或人工标注）、source_tool属性。这种极简设计带来两个好处：一是查询性能极高（毫秒级响应复杂路径查询），二是图谱语义清晰，避免“蜘蛛网式”混乱。我实测过，在 500 台主机、2000+ 漏洞、5 万条关系的图谱上，执行MATCH (h1:Host)-[:HOST_HAS_SERVICE]->(s:Service)-[:SERVICE_HAS_VULNERABILITY]->(v:Vulnerability)<-[:VULNERABILITY_EXPLOITED_BY]-(t:Technique) WHERE h1.ip = '10.10.10.5' RETURN h1, s, v, t，平均耗时 86ms。

• 智能推理层（AI Reasoning Layer）：这是 Pentagi 的“大脑”。它不是用 LLM 直接生成攻击报告，而是基于图谱结构做三类推理：①路径发现（Path Finding）：用 Dijkstra 算法找最短攻击路径，但权重不是距离，而是1/confidence_score * complexity_factor（复杂度因子由 Technique 的 MITRE 平均利用难度决定）；②盲点预测（Blind Spot Prediction）：扫描图谱中高价值节点（如 Domain Controller）的邻居，若存在HOST_HAS_SERVICE但无SERVICE_HAS_VULNERABILITY边，则触发主动建议：“检测 Host X 的 SMB 服务是否暴露 MS17-010”；③战术聚类（Tactic Clustering）：用社区发现算法（Louvain）对 Technique 节点聚类，自动归纳本次行动的核心战术模式（如“以权限提升为主导的横向移动”）。所有 AI 模块都封装为独立微服务，通过 REST API 与图谱层交互，确保图数据库的纯粹性。

2.2 为什么必须是 Docker？——不是为了“时髦”，而是解决红队环境的三大死穴

很多人问：“为什么不用 VM 或直接装裸机？”答案很现实：红队的靶场环境，90% 是 Windows 主机 + Kali Linux 虚机 + 各种老旧业务系统，根本没地方给你装一套完整的 Java/Python/Neo4j 环境。Docker 对 Pentagi 来说，是生存必需品，而非技术选择。

• 环境一致性死穴：红队队员 A 在 Ubuntu 20.04 上跑通 Pentagi，队员 B 在 macOS M1 上却卡在 Neo4j 的 JVM 内存配置。Docker 通过docker-compose.yml统一声明所有服务版本、端口、挂载卷、环境变量，docker-compose up -d一键拉起整套环境。我见过最典型的案例：某次联合演练，6 支队伍共用一套靶场，主办方提供的是pentagi-stack:2.3.1镜像，所有队伍只需docker pull pentagi/pentagi-stack:2.3.1，3 分钟内全部就位，零环境调试。

• 资源隔离死穴：Neo4j 是内存大户，而红队工具（如 Metasploit）也吃内存。Docker 的 cgroups 限制让 Neo4j 容器最多用 4GB RAM，Metasploit 容器最多用 2GB，互不抢占。更重要的是，当某个队员误操作导致 Neo4j OOM 崩溃，只需docker restart pentagi-neo4j，30 秒恢复，不影响其他服务。这比重启整个虚拟机快 10 倍。

• 快速回滚死穴：红队行动中，图谱可能因错误导入污染。Docker 的 volume 挂载设计让数据持久化与应用分离：/var/lib/neo4j/data挂载到宿主机./neo4j-data，/app/config挂载到./config。要回滚？删掉./neo4j-data文件夹，docker-compose down && docker-compose up -d，Neo4j 自动初始化空图谱。我实测过，从污染图谱恢复到干净状态，全程 47 秒。

提示：Docker Desktop 在 Windows 上的常见报错virtualization support not detected，根源是 BIOS 中 Intel VT-x/AMD-V 未开启，或 Hyper-V 与 WSL2 冲突。解决方案不是重装系统，而是：① 进 BIOS 开启虚拟化；② 以管理员身份运行 PowerShell，执行dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart和dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart；③ 重启后安装 WSL2 内核更新包。这套流程我已在 12 台不同型号的 Win10/Win11 笔记本上验证成功。

2.3 为什么必须是 Neo4j？——图数据库不是“炫技”，而是唯一能承载攻击链语义的底座

有人质疑：“用 Elasticsearch 不也能查漏洞？”可以，但只能查“有没有”，不能查“为什么有”、“怎么连起来”。攻击链的本质是关系网络，不是文档集合。

• 原生图遍历优势：Elasticsearch 查“IP 为 10.10.10.5 的主机有哪些漏洞”，是单点查询；而 Pentagi 要查的是“从 Web 服务器 A 出发，经过多少跳能到达数据库服务器 B，且每跳都满足 CVSS > 7.0？”——这是典型的多跳路径查询。Neo4j 的 Cypher 查询语言天然支持MATCH (a:Host)-[r*1..5]->(b:Host)，而 ES 必须用复杂的 Painless 脚本 + 多次 round-trip，性能差 3 个数量级。我对比过：在 10 万节点图谱上，Neo4j 找 5 跳路径平均 120ms，ES 模拟同等逻辑需 1.8s。

• 属性图模型契合度：攻击链中的每个实体都有丰富属性：Host 有 OS、Domain、Patch Level；Vulnerability 有 CVE-ID、CVSS、Exploit Availability；Technique 有 MITRE ID、Tactic、Detection Difficulty。Neo4j 的属性图（Property Graph）模型，允许每个节点/边自由添加键值对，无需预定义 schema。而关系型数据库要实现同等灵活性，得设计几十张关联表，维护成本爆炸。

• 社区生态成熟度：Neo4j Browser 提供可视化图探索，:play movies这类内置教程让蓝队新人 10 分钟就能看懂攻击路径；APOC 库提供图算法（PageRank 计算关键节点、Shortest Path 找最优路径）；GraphQL 插件让前端直接用 GraphQL 查询图谱。这些不是 Pentagi 自研的，而是直接复用 Neo4j 生态，极大降低开发成本。我推荐新手从 Neo4j 社区版起步，它完全免费，且对 Pentagi 的功能覆盖率达 100%——企业版的集群功能在单机红队场景毫无意义。

2.4 为什么必须是 AI Agents？——不是用 AI 替代人，而是把人的判断“固化”为可复用的规则

Pentagi 的 AI Agents 不是黑箱大模型，而是基于规则引擎 + 轻量级 ML 模型的决策代理。它的设计哲学是：AI 负责“机械性推理”，人负责“战略性判断”。

• Rule-Based Agent（规则代理）：处理确定性逻辑。例如，“若某 Host 同时存在SERVICE_HAS_VULNERABILITY关系指向 CVE-2019-0708 和CREDENTIAL_USED_ON关系指向另一台 Host，则自动创建EXPLOIT_CHAIN关系，并标记priority: high”。这类规则用 Drools 引擎实现，语法类似 Java，红队负责人可直接在rules.drl文件里编辑，无需 AI 背景。

• ML-Based Agent（机器学习代理）：处理概率性判断。例如，对新导入的 Nmap 结果，预测“该 Service 运行的 Web 应用最可能是 WordPress 还是 Drupal？”——这里用的是轻量级 XGBoost 模型，特征是port、banner、http-title、http-server，训练数据来自公开的 Censys 数据集。模型体积仅 1.2MB，可嵌入容器，推理延迟 < 5ms。它不保证 100% 准确，但把人工识别率从 65% 提升到 92%，且结果带confidence: 0.87属性，供人复核。

• Human-in-the-Loop Agent（人在环代理）：处理需要人工介入的环节。例如，当图谱发现一条高置信度路径WebServer → DBServer → DomainController，但 DBServer 的操作系统是 Windows Server 2003（已 EOL），AI 无法判断该路径是否仍有效。此时 Agent 会生成待办事项：“请确认 DBServer 是否已打补丁 KB123456”，并推送至 Pentagi Web UI 的待办列表。只有人工点击“已确认”，该路径才被标记为verified: true。这种设计确保 AI 是助手，不是决策者。

3. 核心模块拆解与实操要点：从零搭建一个可用的 Pentagi 环境

3.1 环境准备：避开 Docker Desktop 和 Neo4j 安装的 7 个经典陷阱

Pentagi 的安装失败，90% 发生在环境准备阶段。以下是我在 32 个不同环境（Win10/Win11/macOS/Linux）中踩过的坑，按优先级排序：

1. Windows 上 Docker Desktop 的 WSL2 配置陷阱：
   错误做法：直接下载 Docker Desktop 安装包双击安装。
   正确做法：① 先卸载所有旧版 Docker；② 从 Microsoft Store 安装 WSL2（不是从官网下载）；③ 运行wsl --install；④ 重启后，打开 PowerShell（管理员），执行wsl --set-default-version 2；⑤ 再安装 Docker Desktop。原因：WSL2 内核更新包必须通过 Store 获取，官网安装包自带的内核常与新版 Windows 冲突。

2. Neo4j 社区版的 Java 版本陷阱：
   Neo4j 4.4+ 要求 Java 11，但很多红队笔记本预装的是 Java 8（Kali 默认）。错误做法：apt install openjdk-11-jre后直接启动 Neo4j。
   正确做法：①update-alternatives --config java，确保java -version输出11.x.x；② 编辑/etc/neo4j/neo4j.conf，取消注释dbms.jvm.additional=-Xms4g和dbms.jvm.additional=-Xmx4g；③ 关键一步：chown -R neo4j:neo4j /var/lib/neo4j，否则容器内权限错误导致启动失败。

3. Docker Compose 文件的网络配置陷阱：
   默认docker-compose.yml使用bridge网络，但 Pentagi 的 AI Agent 需要调用 Neo4j 的 Bolt 协议（端口 7687），而 bridge 网络下容器间 DNS 解析不稳定。错误做法：不改网络配置。
   正确做法：在docker-compose.yml顶部添加：

   networks: pentagi-net: driver: bridge ipam: config: - subnet: 172.20.0.0/16

   然后在每个 service 下指定networks: - pentagi-net，并用neo4j:7687代替localhost:7687作为连接地址。

4. 挂载卷的路径陷阱（Windows/macOS）：
   Docker Desktop 在非 Linux 系统上，挂载宿主机路径时，Windows 的C:\pentagi\neo4j-data会被映射为/c/pentagi/neo4j-data，而 Neo4j 容器内路径是/var/lib/neo4j/data。错误做法：直接写./neo4j-data:/var/lib/neo4j/data。
   正确做法：在docker-compose.yml中使用绝对路径，并确保路径存在：

   volumes: - /c/pentagi/neo4j-data:/var/lib/neo4j/data - /c/pentagi/config:/var/lib/neo4j/conf

   （macOS 同理，用/Users/yourname/pentagi/neo4j-data）

5. Neo4j 的初始密码陷阱：
   Neo4j 社区版首次启动时，会生成随机密码并写入日志。错误做法：反复重启容器试图找到密码。
   正确做法：①docker logs pentagi-neo4j | grep "Starting Neo4j"，找到包含Changed password for user 'neo4j'的行；② 或更简单：在docker-compose.yml的 neo4j service 下添加环境变量：

   environment: - NEO4J_AUTH=neo4j/your_password_here

   这样密码就是你设定的，无需猜。

6. Pentagi Web UI 的 CORS 陷阱：
   Pentagi 前端默认监听localhost:3000，后端 API 在neo4j:7474，跨域请求被浏览器拦截。错误做法：在浏览器禁用 CORS。
   正确做法：在docker-compose.yml的 pentagi-api service 下添加：

   environment: - PENTAGI_CORS_ORIGIN=http://localhost:3000

   启动后，API 会自动返回Access-Control-Allow-Origin头。

7. AI Agent 的模型加载陷阱：
   Pentagi 的 ML Agent 需要加载.joblib模型文件，但 Docker 容器内路径与宿主机不同。错误做法：把模型文件放在项目根目录，期望import joblib; model = joblib.load('model.joblib')成功。
   正确做法：在Dockerfile中显式复制：

   COPY ./models/service_classifier.joblib /app/models/

   并在代码中用绝对路径joblib.load('/app/models/service_classifier.joblib')。

3.2 核心配置详解：三个 YAML 文件决定 Pentagi 的“性格”

Pentagi 的行为由三个核心配置文件驱动，修改它们比改代码更安全、更高效：

• config/ingestion-rules.yaml：定义数据清洗规则。
  示例片段：

  nmap: port_state_filter: ["open", "open|filtered"] # 忽略 closed 端口 service_name_mapping: "http": "HTTP" "https": "HTTPS" "ms-sql-s": "MSSQL" vulnerability_enrichment: - cve_id: "CVE-2021-42287" mitre_technique: "T1210" # Exploitation of Remote Services confidence_score: 0.95

  这个文件决定了“Nmap 扫出来的 80 端口，到底算不算一个有效的 HTTP 服务”，直接影响图谱质量。我建议红队根据自己的常用工具链，定制此文件——比如，如果你常用 Nikto，就添加nikto:section。

• config/graph-schema.yaml：定义图谱的“宪法”。
  示例片段：

  nodes: Host: properties: [ip, hostname, os, domain, patch_level] primary_key: ip Vulnerability: properties: [cve_id, cvss_score, description, exploit_available] primary_key: cve_id relationships: HOST_HAS_SERVICE: from: Host to: Service properties: [port, protocol, banner] SERVICE_HAS_VULNERABILITY: from: Service to: Vulnerability properties: [cvss_vector, exploit_confidence]

  修改此文件需谨慎：新增节点类型后，必须同步更新ingestion-rules.yaml中的映射逻辑，否则数据无法入库。我曾因漏加primary_key导致 Neo4j 报Duplicate node错误，排查了 2 小时。

• config/ai-agents.yaml：定义 AI Agent 的“行为准则”。
  示例片段：

  path_finding: max_hops: 5 min_confidence: 0.7 weight_factors: confidence: 1.0 complexity: 0.8 # Technique 的 MITRE 复杂度系数 time_since_last_scan: 0.3 # 越新的扫描结果权重越高 blind_spot_prediction: target_nodes: ["DomainController", "DatabaseServer"] min_service_count: 3 # 至少有 3 个服务才触发预测

  这个文件直接控制 AI 的“激进程度”。min_confidence: 0.7意味着只信任置信度 70% 以上的路径，避免误报；time_since_last_scan: 0.3让 AI 更看重最近的扫描结果，符合红队“时效性”需求。

3.3 数据导入实战：手把手演示如何把一次 Cobalt Strike 行动日志变成可分析的图谱

假设你刚完成一次 Cobalt Strike 演练，拿到了beacon-log.txt。以下是完整导入流程，每一步都附带命令和原理：

1. 准备原始日志：
   Cobalt Strike 默认日志是纯文本，需先转换为 Pentagi 可识别的 JSON 格式。Pentagi 提供了cs-log-parser.py工具：

   python cs-log-parser.py --input beacon-log.txt --output cs-parsed.json --teamserver 192.168.1.100

   原理：该脚本解析 Beacon 日志中的beacon、shell、download、execute等命令，提取host、command、output、timestamp字段，并映射到 MITRE ATT&CK Technique。例如，shell whoami映射为T1033 (System Owner User)。

2. 启动 Pentagi 服务：

   cd pentagi-deployment docker-compose up -d # 等待 30 秒，检查状态 docker-compose ps # 确保所有状态为 "Up"

3. 访问 Neo4j 初始化页面：
   浏览器打开http://localhost:7474，输入用户名neo4j，密码为你在docker-compose.yml中设置的密码。首次登录会提示改密，按提示操作。

4. 导入数据：
   Pentagi 提供了 REST API 导入接口。用 curl 命令：

   curl -X POST http://localhost:8000/api/v1/ingest/cs \ -H "Content-Type: application/json" \ -d @cs-parsed.json

   响应{"status":"success","ingested_nodes":127,"ingested_relations":89}表示成功。原理：API 接收 JSON 后，调用IngestionService，根据config/ingestion-rules.yaml中的cs:规则，将每条日志解析为Host、Command、Technique节点及EXECUTED_ON、APPLIES_TECHNIQUE关系。

5. 验证图谱：
   在 Neo4j Browser 中执行：

   MATCH (h:Host)-[r:EXECUTED_ON]->(c:Command) WHERE h.ip = '10.10.10.20' RETURN h, r, c LIMIT 10

   你会看到该主机执行的所有命令，以及每条命令关联的 Technique。点击节点，右侧面板显示所有属性（timestamp、mitre_id、confidence）。

6. 触发 AI 推理：
   Pentagi Web UI（http://localhost:3000）的 “Analyze” 页面，选择 “Find Attack Paths”，输入目标 Host IP，点击 “Run”。后台会调用PathFindingAgent，返回带权重的路径列表。例如：

   Path 1: 10.10.10.20 → 10.10.10.21 → 10.10.10.1 (Weight: 0.82) Steps: T1033 → T1059 → T1087.002 Confidence: 0.91, Complexity: Low

   这条路径告诉你：从 Web 服务器出发，通过命令执行（T1059），最终获取了域用户列表（T1087.002），且整个链条置信度高达 91%。

3.4 图谱查询与分析：用 5 个 Cypher 查询解决红队最痛的 5 个问题

Neo4j 的 Cypher 是 Pentagi 的灵魂，掌握以下 5 个查询，你就能从图谱中榨取 80% 的价值：

1. 问题：哪台主机是本次行动的“关键跳板”？（找出连接最多其他主机的节点）

   MATCH (h:Host)-[r]->() WITH h, count(r) as degree ORDER BY degree DESC LIMIT 5 RETURN h.ip as host_ip, h.hostname as hostname, degree

   原理：计算每个 Host 节点的出度（outgoing relationships），度数越高，说明它被利用的次数越多，越可能是跳板。我曾在某次演练中发现一台被忽略的打印机服务器（10.10.10.150），出度高达 47，深入调查发现它运行着未打补丁的 HP JetDirect 服务，成了横向移动的黄金通道。

2. 问题：哪些漏洞被多次利用，但尚未被蓝队检测？（找出高价值、低检测率的漏洞）

   MATCH (v:Vulnerability)<-[:SERVICE_HAS_VULNERABILITY]-(s:Service)-[:HOST_HAS_SERVICE]->(h:Host) WHERE v.exploit_available = true AND v.cvss_score >= 7.0 WITH v, count(h) as exploitation_count ORDER BY exploitation_count DESC LIMIT 10 RETURN v.cve_id, v.description, exploitation_count, apoc.coll.toSet(collect(h.ip)) as affected_hosts

   原理：apoc.coll.toSet是 APOC 库函数，去重并返回受影响主机 IP 列表。这个查询直接给出“最值得写检测规则的 CVE”。例如，CVE-2023-23397出现在 12 台主机上，但 EDR 告警为 0，这就是蓝队的检测盲点。

3. 问题：从任意起点到域控，是否存在无需密码的路径？（寻找 Pass-the-Hash 或 Kerberoasting 路径）

   MATCH path = (start:Host)-[r*1..4]->(dc:Host) WHERE dc.hostname ENDS WITH ".domain.local" AND dc.os CONTAINS "Windows Server" AND ALL(rel IN relationships(path) WHERE rel.type IN ['EXECUTED_ON', 'USED_CREDENTIAL']) AND NONE(node IN nodes(path) WHERE node.has_password = false) RETURN path, length(path) as hop_count ORDER BY hop_count ASC LIMIT 3

   原理：ALL和NONE是 Cypher 的集合谓词，确保路径中所有关系都是合法的攻击动作，且所有节点都具备凭据。这个查询能快速定位“免密横向”路径，比手动梳理快 10 倍。

4. 问题：本次行动中，哪些 Technique 被重复使用超过 3 次？（识别红队的惯用战术）

   MATCH (t:Technique)<-[:APPLIES_TECHNIQUE]-(c:Command) WITH t, count(c) as usage_count WHERE usage_count > 3 RETURN t.mitre_id, t.name, usage_count, collect(DISTINCT c.command) as example_commands ORDER BY usage_count DESC

   原理：collect(DISTINCT ...)返回该 Technique 对应的具体命令示例，帮助复盘战术有效性。例如，T1059 (Command and Scripting Interpreter)使用了 17 次，示例包括powershell -enc ...、cmd /c certutil ...，说明 PowerShell 绕过是本次行动的核心能力。

5. 问题：图谱中是否存在“孤岛”子图？（发现未被连接的高价值资产）

   CALL algo.unionFind.stream('Host', 'HOST_HAS_SERVICE', {direction: 'both'}) YIELD nodeId, setId WITH algo.asNode(nodeId) as host, setId WITH setId, collect(host) as hosts WHERE size(hosts) > 1 RETURN setId, [h IN hosts | h.ip] as ip_list, size(hosts) as cluster_size ORDER BY cluster_size DESC LIMIT 5

   原理：algo.unionFind是 Neo4j Graph Algorithms 库的连通分量算法，找出所有相互连接的 Host 子图。size(hosts) > 1过滤掉孤立节点。这个查询能发现“看似独立，实则内部连通”的资产组，比如一个被防火墙隔离的 DMZ 区，内部却有 8 台主机相互 SSH，这就是一个潜在的突破口。

4. 实操过程全记录：一次真实的 Pentagi 部署与分析全流程

4.1 第一天：环境搭建与首次数据导入（耗时 3 小时 17 分钟）

我的硬件：MacBook Pro M1 Max，32GB RAM，macOS Ventura。
步骤记录：

• 00:00-00:22：安装 Homebrew →brew install --cask docker→ 启动 Docker Desktop。等待 WSL2 初始化（macOS 无此步，但需确认 Docker Engine Running）。
• 00:22-00:45：克隆 Pentagi 仓库git clone https://github.com/pentagi/pentagi.git→cd pentagi/deployment/docker-compose→ 修改docker-compose.yml：将neo4j的NEO4J_AUTH设为neo4j/RedTeam2024，挂载卷路径改为/Users/alex/pentagi/neo4j-data:/var/lib/neo4j/data。
• 00:45-01:10：执行docker-compose up -d。观察日志：neo4j容器启动成功，但pentagi-api报错Connection refused。排查：docker network inspect pentagi-pentagi-net发现pentagi-api的 IP 是172.20.0.3，而neo4j的 IP 是172.20.0.2，但pentagi-api的配置文件里写的是http://localhost:7474。修正：在pentagi-api的application.yml中，将neo4j.uri改为bolt://neo4j:7687。重新构建镜像docker-compose build pentagi-api，再up -d。成功。
• 01:10-01:25：浏览器打开http://localhost:7474，登录neo4j/RedTeam2024，改密为Pentagi@2024。
• 01:25-02:10：准备数据。用nmap -sV -sC -p- 10.10.10.0/24 -oX nmap-full.xml扫描靶场，耗时 45 分钟。用python pentagi/tools/nmap-to-json.py --input nmap-full.xml --output nmap-parsed.json转换格式。
• 02:10-02:15：curl -X POST http://localhost:8000/api/v1/ingest/nmap -H "Content-Type: application/json" -d @nmap-parsed.json。响应{"status":"success","ingested_nodes":218,"ingested_relations":436}。
• 02:15-03:17：在 Neo4j Browser 中验证：MATCH (h:Host) RETURN count(h)返回218，MATCH ()-[r]->() RETURN count(r)返回436。执行路径查询 `MATCH path=(h1:Host)-[*1..3]->(h2:Host) WHERE h1.ip='10.10.10.5' AND h2.ip='10.10.10.