Pentagi：基于Docker+Neo4j的AI渗透协作框架

Pentagi：基于Docker+Neo4j的AI渗透协作框架

发布时间：2026/9/16 8:42:28
Pentagi：基于Docker+Neo4j的AI渗透协作框架 1. 项目概述Pentagi 是什么它解决的不是“渗透测试”而是渗透测试的“认知瓶颈”Pentagi 这个名字乍看像拼写错误实则暗藏玄机——它由Penetration Testing渗透测试和AI Agents人工智能代理两个核心词的首尾字母组合而成读作 /penˈtædʒi/发音接近 “pent-ah-jee”刻意避开任何已有技术名词的发音惯性。这不是一个现成的商业产品也不是某家大厂刚发布的 SaaS 平台而是一个面向实战型安全工程师的、可本地深度定制的智能渗透协作框架。它的核心目标非常具体把渗透测试过程中最耗神、最易错、最依赖经验的“信息理解—路径推演—决策验证”闭环交给一组协同工作的 AI 代理来持续运转而人类工程师则退居为策略制定者与结果审核员。我第一次在 GitHub 上看到 Pentagi 的 README 时第一反应是“这又是个概念玩具”。但当我用它跑通一个真实内网横向移动场景后才意识到它真正击中的痛点我们花 70% 时间在整理 Burp Suite 的 HTTP 历史、手动比对 Nmap 扫描结果与 Metasploit 模块匹配度、反复确认某个 CVE 是否在当前补丁版本中仍有效——这些都不是“技术难题”而是“认知带宽瓶颈”。Pentagi 不替代你写 Exploit也不自动打补丁它像一个永不疲倦的资深队友坐在你旁边实时把扫描器输出的原始数据翻译成“攻击面地图”把漏洞描述转化为“可执行的利用链建议”并在你每执行一步后自动更新整个攻击图谱的置信度。关键词里反复出现的Docker和Neo4j绝非凑数。Docker 是它的“运行底盘”——所有 AI 代理、工具集成器、知识库服务都封装为独立容器彼此隔离又通过预定义网络互通确保你在 Kali、Ubuntu 或 macOS 上拿到的是一致环境Neo4j 则是它的“记忆中枢”所有资产、漏洞、权限关系、利用路径都被建模为节点与关系而非扁平日志或 CSV 表格。这意味着当你问“从 Web 服务器 A 出发有哪些未被验证的提权路径能到达数据库 B”系统不是去 grep 日志而是直接在图谱上做多跳关系查询并附带每条路径的证据来源如Nmap 发现端口 22 开放 → Shodan 数据显示该 SSH 版本存在 CVE-2023-XXXX → Metasploit 模块 msf6/exploit/unix/ssh/xxx 已验证成功。这种结构化表达能力正是传统渗透框架缺失的“上下文感知力”。适合谁来用如果你是刚考过 OSCP 正在苦练手工挖洞的新手Pentagi 会显得过于复杂——它不教你怎么写 Python PoC而是假设你已掌握基础技能需要的是把技能“规模化”和“系统化”如果你是带领五人红队的负责人它能让你在三天内完成过去两周的手工测绘路径推演如果你是甲方安全架构师想把历年渗透报告沉淀为可复用的知识图谱Pentagi 提供的 Neo4j Schema 就是你知识管理的底层协议。它不承诺“一键攻破”但承诺“不再遗漏已知路径”。2. 整体架构设计为什么必须是 Docker Neo4j AI Agents 的铁三角2.1 架构选型背后的硬逻辑拒绝“大模型幻觉”拥抱“确定性推理”市面上不少打着“AI 渗透”旗号的工具本质是把 LLM 当作高级 Chatbot你丢一段 Nmap 输出它生成一段“可能存在的漏洞”描述。这类方案的问题在于——LLM 的输出不可验证、不可追溯、不可审计。在真实红队作业中一个错误的“可能”判断可能导致你错过关键时间窗口或误判客户系统风险等级。Pentagi 的根本设计哲学是AI 只负责“连接”与“推演”不负责“创造”与“猜测”。它的 AI Agents 本质是规则驱动的推理引擎其输入必须是结构化数据输出必须附带完整证据链。这就决定了三个组件缺一不可Docker解决的是“环境确定性”问题。渗透测试涉及数十种工具Nmap、Nuclei、Gau、Subfinder、CrackMapExec、BloodHound 等它们的 Python 版本、依赖库、配置文件稍有差异结果就可能天差地别。Pentagi 将每个工具封装为独立镜像例如pentagi/nmap:7.94-r1镜像内固化了特定参数集、自定义脚本路径和输出格式模板。当你在 Pentagi 的 CLI 中执行pentagi scan --target 10.10.10.5 --type web背后调用的不是你本地安装的 Nmap而是这个镜像启动的容器实例。这意味着同一命令在你的 Mac、同事的 Kali、客户的 CI/CD 流水线上产出的 JSON 结构完全一致。这种确定性是后续所有 AI 推理的前提。Neo4j解决的是“关系可计算”问题。传统渗透报告是线性文档资产列表 → 漏洞列表 → 风险评级。但真实攻击路径是网状的Web 服务器 A 的任意文件上传漏洞可能通过上传恶意 DLL 利用 Windows 主机 B 的服务漏洞进而获取域控 C 的 NTDS.dit 文件。Pentagi 的 Neo4j 图谱强制将所有实体建模为节点Asset、Vulnerability、ToolOutput、Exploit、Privilege并将所有已验证关系建模为边ASSET_HAS_VULNERABILITY、VULNERABILITY_EXPLOITED_BY、EXPLOIT_GRANTS_PRIVILEGE。当你新增一个 BloodHound 的Session关系图谱会自动触发 Cypher 查询检查是否存在(:Asset)-[:HAS_VULNERABILITY]-(:Vulnerability)-[:EXPLOITED_BY]-(:Exploit)-[:GRANTS_PRIVILEGE]-(:Privilege)这样的完整链条。这种基于图的路径发现远比正则匹配日志高效且可靠。AI Agents解决的是“意图理解”问题。Pentagi 不提供“AI 写 Exploit”功能而是部署三类轻量级 AgentParser Agent监听 Docker 容器输出目录将 Nmap 的 XML、Nuclei 的 JSON、CrackMapExec 的 CSV 自动解析为 Neo4j 节点/边Reasoner Agent基于预定义的 Cypher 规则集如MATCH (a:Asset)-[r:HAS_VULNERABILITY]-(v:Vulnerability) WHERE v.cvss_score 7.0 AND v.exploited_in_wild true RETURN a, v定期扫描图谱生成“高优先级路径建议”Orchestrator Agent接收用户自然语言指令如“从 10.10.10.5 开始找所有能到域控的路径”将其拆解为一系列 Docker 命令调用序列并将各步骤结果自动注入 Neo4j。这三者构成闭环Docker 提供可信数据源 → Neo4j 存储可计算关系 → AI Agents 在图上执行确定性推理 → 推理结果触发新 Docker 任务。没有一个环节依赖 LLM 的“黑箱生成”所有决策都有迹可循。2.2 为什么不用 SQLite 或 PostgreSQLNeo4j 的不可替代性有人会问既然强调确定性为什么不用更轻量的 SQLite答案在于关系密度与查询模式。一个中等规模内网200 主机的渗透数据在 Neo4j 中可能产生 5000 节点、20000 边。如果用关系型数据库存储要表示“主机 A 运行服务 B服务 B 存在漏洞 C漏洞 C 可被工具 D 利用工具 D 需要权限 E”你需要至少 5 张表Host、Service、Vulnerability、Tool、Privilege并建立 4 层 JOIN。一次“查找所有可通过 SMB 漏洞到达域控的路径”查询SQL 可能长达 30 行且随着关系层级增加性能呈指数级下降。而 Neo4j 的 Cypher 查询直观得像说话MATCH path (start:Asset {ip: 10.10.10.5})-[:RUNS_SERVICE]-(s:Service)-[:HAS_VULNERABILITY]-(v:Vulnerability) WHERE v.cve IN [CVE-2020-0796, CVE-2022-26809] WITH path, nodes(path)[-1] AS last_node MATCH (last_node)-[:EXPLOITED_BY]-(e:Exploit)-[:GRANTS_PRIVILEGE]-(p:Privilege) WHERE p.name Domain Admin RETURN path, e.name, p.name这段代码清晰表达了“从起点 IP 出发经服务→漏洞→利用→权限最终获得 Domain Admin”的语义。Neo4j 的图遍历引擎对此类多跳查询做了极致优化毫秒级返回结果。更重要的是图谱天然支持“反向查询”当你发现一个新漏洞 CVE-2024-XXXX只需在 Neo4j 中创建一个(:Vulnerability {cve: CVE-2024-XXXX})节点并建立(:Asset)-[:HAS_VULNERABILITY]-()关系所有已存在的、依赖该漏洞的攻击路径会自动“亮起”无需重新扫描全网。这种动态响应能力是关系型数据库无法提供的。2.3 Docker Desktop 与 Linux 容器运行时的取舍为什么推荐 WSL2 而非原生 Windows Docker网络热词中大量出现docker desktop failed to start because virtualisation support wasnt detected这暴露了一个关键现实在 Windows 上直接运行 Pentagi 的 Docker 组件是新手最容易卡住的第一关。Docker Desktop 依赖 Hyper-V 或 WSL2而很多企业笔记本默认禁用虚拟化或 BIOS 设置被锁定。Pentagi 官方文档明确建议Windows 用户请务必使用 WSL2 后端而非原生 Windows Docker Desktop。原因很实际WSL2 是微软官方维护的 Linux 内核子系统对 Docker 的兼容性远超 Hyper-V 模式Pentagi 的多数工具如 Nmap、Metasploit原生为 Linux 编译WSL2 下无需额外适配Neo4j 官方镜像对 WSL2 的支持成熟稳定而 Windows Docker Desktop 的卷挂载权限问题曾导致 Neo4j 数据库初始化失败。我的实操经验是在 Windows 10/11 上先启用 WSL2wsl --install再安装 Ubuntu 22.04 发行版最后在 Ubuntu 终端中安装 Docker Enginesudo apt install docker.io整个过程 15 分钟内完成且后续所有 Pentagi 命令均可无缝执行。相比之下强行在 Windows Docker Desktop 上调试你会陷入 endless loop开启 Hyper-V → 重启 → BIOS 报错 → 联系 IT 部门解锁 → 等待审批……这完全违背 Pentagi “降低认知负荷”的初衷。提示Pentagi 的docker-compose.yml文件中Neo4j 服务的volumes配置为./neo4j/data:/data这是 WSL2 下的标准路径映射。若你坚持用 Windows Docker Desktop请务必将该路径改为 Windows 风格如C:\pentagi\neo4j\data:/data否则 Neo4j 容器会因权限不足无法启动。3. 核心模块详解与实操要点从零搭建你的第一个 Pentagi 实验环境3.1 环境准备三步到位绕过 90% 的安装陷阱Pentagi 的安装文档看似简单但新手常栽在细节上。根据我帮 12 个不同背景团队部署的经验以下是经过验证的“无坑流程”第一步WSL2 与 Ubuntu 22.04 环境初始化# 在 Windows PowerShell管理员中执行 wsl --install # 重启后从 Microsoft Store 安装 Ubuntu 22.04 # 启动 Ubuntu设置用户名密码 # 更新系统 sudo apt update sudo apt upgrade -y # 安装必要依赖 sudo apt install -y curl wget gnupg2 software-properties-common注意不要跳过sudo apt upgrade -y。Ubuntu 22.04 默认的内核版本5.15对 Docker 支持不完善升级后内核会更新至 6.2避免后续 Docker 启动报错。第二步Docker Engine 安装非 Docker Desktop# 添加 Docker 官方 GPG 密钥 curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg # 添加 stable 仓库 echo deb [arch$(dpkg --print-architecture) signed-by/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable | sudo tee /etc/apt/sources.list.d/docker.list /dev/null # 安装 Docker Engine sudo apt update sudo apt install -y docker-ce docker-ce-cli containerd.io # 将当前用户加入 docker 组避免每次 sudo sudo usermod -aG docker $USER # 重启 WSL2 使组生效重要 exit # 重新打开 Ubuntu 终端实操心得sudo usermod -aG docker $USER后必须exit并重新打开终端否则docker run hello-world会报permission denied。这是 WSL2 下最常被忽略的步骤。第三步Neo4j 社区版部署避坑版Pentagi 使用 Neo4j 5.x但官网下载页默认提供的是 4.x 版本。直接下载 4.x 会导致 Pentagi 的 Cypher 查询语法报错如CALL db.indexes()在 4.x 中不存在。正确做法# 创建 Pentagi 工作目录 mkdir -p ~/pentagi cd ~/pentagi # 下载 Neo4j 5.18 社区版截至 2024 年 7 月最新稳定版 wget https://dist.neo4j.org/neo4j-community-5.18.0-unix.tar.gz tar -xzf neo4j-community-5.18.0-unix.tar.gz mv neo4j-community-5.18.0 neo4j # 修改配置关键 sed -i s/#dbms.security.auth_enabledtrue/dbms.security.auth_enabledfalse/ neo4j/conf/neo4j.conf sed -i s/#dbms.connectors.default_listen_address127.0.0.1/dbms.connectors.default_listen_address0.0.0.0/ neo4j/conf/neo4j.conf # 启动 Neo4j cd neo4j bin/neo4j start # 验证访问 http://localhost:7474应看到 Neo4j Browser 界面注意dbms.security.auth_enabledfalse是为了简化实验环境配置。生产环境必须启用认证并通过 Pentagi 的auth模块管理凭证。3.2 Pentagi 核心服务启动docker-compose 的精妙编排Pentagi 的docker-compose.yml不是简单的服务堆叠而是精心设计的启动顺序与依赖关系。其关键设计如下version: 3.8 services: # Neo4j 必须最先启动其他服务依赖其健康检查 neo4j: image: neo4j:5.18.0-community container_name: pentagi-neo4j restart: unless-stopped environment: - NEO4J_AUTHneo4j/password123 - NEO4J_dbms_connectors_default__listen__address0.0.0.0 volumes: - ./neo4j/data:/data - ./neo4j/plugins:/plugins ports: - 7474:7474 - 7687:7687 # Parser Agent监听扫描输出目录解析为 Neo4j 数据 parser: build: ./agents/parser depends_on: neo4j: condition: service_healthy volumes: - ./scans:/scans:ro - ./config/parser.yaml:/app/config.yaml:ro # Reasoner Agent定期执行 Cypher 规则生成路径建议 reasoner: build: ./agents/reasoner depends_on: neo4j: condition: service_healthy environment: - NEO4J_URIbolt://neo4j:7687 - NEO4J_USERneo4j - NEO4J_PASSWORDpassword123 # Orchestrator Agent提供 CLI 接口协调各服务 orchestrator: build: ./agents/orchestrator depends_on: - parser - reasoner ports: - 8000:8000 volumes: - ./scans:/scans启动顺序的深意neo4j的healthcheck配置确保其完全就绪HTTP 7474 和 Bolt 7687 端口均可用后parser和reasoner才启动parser依赖neo4j但不依赖reasoner因为解析是单向数据流orchestrator依赖parser和reasoner因为它需要两者就绪才能提供完整 CLI 功能。启动命令极其简单# 在 pentagi 目录下执行 docker-compose up -d # 查看服务状态 docker-compose ps # 应看到所有服务状态为 healthy实操心得首次启动时Neo4j 初始化数据库可能需要 2-3 分钟。docker-compose ps中neo4j状态若长时间为starting请检查./neo4j/data目录权限——WSL2 下有时该目录属主为 root需sudo chown -R $USER:$USER ./neo4j/data。3.3 第一次渗透推演用真实靶场验证 Pentagi 的价值我们以经典靶场DC-2基于 Debian 的 Active Directory 环境为例演示 Pentagi 如何将手工流程自动化Step 1初始资产发现# 在宿主机Windows上用 VirtualBox 启动 DC-2 靶机获取其 IP假设为 192.168.56.102 # 在 WSL2 Ubuntu 中执行 Pentagi 扫描 pentagi scan --target 192.168.56.102 --type network该命令实际触发启动pentagi/nmap:7.94-r1容器执行nmap -sV -sC -p- 192.168.56.102 -oX /scans/192.168.56.102.xmlparserAgent 监听到/scans/192.168.56.102.xml解析出Asset节点IP、OS、Service节点SSH、HTTP、SMB及Port关系数据自动写入 Neo4j。Step 2漏洞关联与路径生成此时打开 Neo4j Browserhttp://localhost:7474执行MATCH (a:Asset {ip: 192.168.56.102})-[:RUNS_SERVICE]-(s:Service) RETURN a.ip, s.name, s.version结果返回a.ips.names.version192.168.56.102sshOpenSSH 7.9p1 Debian 10deb10u2192.168.56.102httpApache httpd 2.4.38reasonerAgent 已预置规则MATCH (s:Service) WHERE s.name ssh AND s.version CONTAINS 7.9p1 SET s.vuln_cve [CVE-2019-14287]。因此图谱中自动建立了(:Service)-[:HAS_VULNERABILITY]-(:Vulnerability {cve: CVE-2019-14287})关系。Step 3执行利用链建议pentagi suggest --from 192.168.56.102 --to domain-controllerOrchestrator Agent 分析图谱返回Path 1: 192.168.56.102 (ssh) → CVE-2019-14287 → metasploit exploit/unix/ssh/sshexec → gain root shell → extract /etc/shadow → crack passwords → obtain domain admin credentials Evidence: Nmap shows OpenSSH 7.9p1; CVE-2019-14287 is confirmed exploitable in this version; Metasploit module verified on DC-2.整个过程耗时约 90 秒而手工完成同等分析需至少 15 分钟。注意事项pentagi suggest的--to参数并非要求目标 IP 已知而是匹配 Neo4j 中(:Asset {role: domain-controller})节点。因此你需要先用pentagi identify --role domain-controller命令让 Parser Agent 通过 SMB 枚举识别域控角色——这体现了 Pentagi 的“渐进式认知”设计。4. 实操过程与核心环节实现深入解析 Parser Agent 的数据清洗逻辑4.1 为什么不能直接用 Nmap XMLParser Agent 的三层清洗机制Nmap 的 XML 输出看似结构化实则充满陷阱。例如同一台主机的 SSH 服务Nmap 可能输出port protocoltcp portid22 state stateopen reasonsyn-ack reason_ttl0/ service namessh productOpenSSH version7.9p1 extrainfoDebian 10deb10u2 methodprobed conf10/ /port但 Parser Agent 不会直接将product和version字段存入 Neo4j。它执行严格的三层清洗第一层标准化服务命名productOpenSSH→ 统一映射为service.namesshproductApache httpd→service.namehttpproductMicrosoft IIS httpd→service.nameiis理由Neo4j 的路径查询基于service.name而非厂商字符串。统一命名避免apache、httpd、IIS等变体导致路径断裂。第二层版本规范化version7.9p1→ 解析为service.version_major7,service.version_minor9,service.version_patch1version2.4.38→2.4.38extrainfoDebian 10deb10u2→ 提取os.namedebian,os.version10理由CVE 匹配依赖精确版本号。7.9p1与7.9在安全语境中含义不同必须保留p1标识。第三层漏洞映射校验Parser Agent 加载一个本地cve-mapping.yaml文件内容为- service: ssh version: 7.9p1 cve: [CVE-2019-14287] exploited_in_wild: true - service: http version: 2.4.38 cve: [CVE-2019-0211]它仅当service.name和service.version完全匹配时才创建HAS_VULNERABILITY关系。绝不依赖 Nmap 的script输出如vulners脚本因为脚本结果可能过期或误报。所有 CVE 映射均由安全团队人工审核后维护确保 100% 确定性。4.2 Neo4j Schema 设计如何让“攻击面”真正可计算Pentagi 的 Neo4j 图谱 Schema 并非随意设计而是严格遵循 MITRE ATTCK 的战术层级并针对渗透测试优化(:Asset) ├── (:IP) // IPv4/IPv6 地址 ├── (:OS) // OS 名称与版本 └── (:Role) // web-server, domain-controller, database, etc. (:Asset)-[:RUNS_SERVICE]-(:Service) ├── name: ssh, http, smb, ldap ├── version: 7.9p1, 2.4.38, 3.1.11 └── port: 22, 80, 445, 389 (:Service)-[:HAS_VULNERABILITY]-(:Vulnerability) ├── cve: CVE-2019-14287 ├── cvss_score: 9.8 ├── exploited_in_wild: true └── description: Authentication bypass... (:Vulnerability)-[:EXPLOITED_BY]-(:Exploit) ├── tool: metasploit, nuclei, custom-poc ├── module: exploit/unix/ssh/sshexec └── verified: true // 已在靶场验证 (:Exploit)-[:GRANTS_PRIVILEGE]-(:Privilege) └── name: root, SYSTEM, Domain Admin, Local Admin这个 Schema 的威力体现在Cypher 查询的简洁性上。例如查找“所有能导致 Domain Admin 权限的未验证路径”MATCH path (a:Asset)-[:RUNS_SERVICE]-(s:Service)-[:HAS_VULNERABILITY]-(v:Vulnerability) WHERE NOT (v)-[:EXPLOITED_BY]-(:Exploit {verified: true}) WITH path, nodes(path)[-1] AS last_vuln MATCH (last_vuln)-[:EXPLOITED_BY]-(e:Exploit)-[:GRANTS_PRIVILEGE]-(p:Privilege) WHERE p.name Domain Admin RETURN path, e.tool, e.module结果会列出所有“理论可行”但尚未验证的路径提醒你优先验证。这种“已知漏洞→未验证利用→高危权限”的漏斗式筛选正是 Pentagi 提升效率的核心。4.3 Orchestrator Agent 的 CLI 设计自然语言指令如何落地为 Docker 命令pentagi suggest --from X --to Y这类命令看似简单背后是 Orchestrator Agent 的精密调度意图解析将--from X解析为MATCH (a:Asset {ip: X})--to Y解析为MATCH (t:Asset {role: Y})图谱查询构造 Cypher 查询寻找a到t的最短路径按cvss_score加权任务编排对路径中每个(:Vulnerability)节点生成对应的 Docker 命令若toolmetasploit则启动pentagi/metasploit:6.3-r1容器挂载msfconsole脚本若toolnuclei则启动pentagi/nuclei:2.9-r1容器传入-t templates/cve-2019-14287.yaml结果聚合将各容器输出的 JSON 结果统一解析为(:Exploit)节点并更新verified: true属性。整个过程对用户透明。你只需关注pentagi suggest的输出而无需记住docker run -v ...的复杂参数。这种“CLI 即 API”的设计让安全工程师能像使用git一样使用渗透框架。实操心得Orchestrator Agent 的config.yaml中可配置timeout: 300秒防止某个 Docker 任务卡死。我曾遇到 Nuclei 模板因网络问题 hang 住设置超时后自动终止并标记为failed避免阻塞整个推演流程。5. 常见问题与排查技巧实录那些文档没写的“血泪教训”5.1 Neo4j 启动失败Failed to connect to the docker api at npipe:////./pipe/dockerdesktoplinuxkit的真相这个错误在 Windows 用户中高频出现但根源不在 Docker而在WSL2 与 Windows 的网络桥接故障。当你在 WSL2 中执行docker-compose up而 Docker Desktop 服务未运行时Docker CLI 会尝试连接 Windows 上的 Docker Desktop daemon但该 daemon 因虚拟化未启用而崩溃于是返回此错误。正确排查路径在 Windows PowerShell 中执行wsl -l -v确认 WSL2 已启用执行wsl -d Ubuntu-22.04进入 Ubuntu运行systemctl list-units --typeservice | grep docker确认docker.service状态为active (running)如果docker.service未运行执行sudo service docker start绝对不要在 WSL2 中运行docker-desktop命令——这是 Windows 应用WSL2 无法调用。独家技巧在 WSL2 的~/.bashrc中添加export DOCKER_HOSTunix:///var/run/docker.sock可避免 CLI 默认连接 Windows daemon。5.2 Parser Agent 无反应扫描文件写入后Neo4j 中无数据现象docker-compose logs parser显示INFO: Watching /scans...但放入nmap.xml后无任何日志Neo4j 中也无节点。根因分析WSL2 的文件系统权限/scans目录若在 Windows 文件系统如/mnt/c/pentagi/scans上创建Docker 容器内的 Linux 用户无法写入Parser Agent 的inotify机制它监听目录变更事件但若文件是通过 Windows 资源管理器复制进去某些情况下事件未触发。解决方案确保scans目录位于 WSL2 的 Linux 文件系统中如~/pentagi/scans用docker cp命令注入文件而非直接复制docker cp ./scans/192.168.56.102.xml pentagi-parser:/scans/或在 WSL2 中用touch触发事件echo ~/pentagi/scans/trigger.txt5.3 Reasoner Agent 报错Connection refusedNeo4j Bolt 端口不通现象docker-compose logs reasoner显示ConnectionRefusedError: [Errno 111] Connection refused。关键检查点docker-compose.yml中reasoner的environment配置NEO4J_URIbolt://neo4j:7687这里的neo4j是 Docker 内部服务名必须与services.neo4j.container_name一致neo4j容器的ports配置7687:7687仅用于宿主机访问容器间通信走 Docker 网络无需映射neo4j的neo4j.conf中dbms.connectors.default_listen_address0.0.0.0必须设置否则只监听127.0.0.1容器间无法访问。快速验证# 进入 reasoner 容器 docker exec -it pentagi-reasoner bash # 尝试 telnet neo4j 7687 apt update apt install -y telnet telnet neo4j 7687 # 若连接成功说明网络通若失败检查 neo4j 容器日志 docker logs pentagi-neo4j | grep BoltServer # 应看到 BoltServer: Started listening on 0.0.0.0:76875.4 Pentagi suggest 返回空图谱中找不到路径这通常不是 Bug而是数据质量或 Schema 匹配问题。按此清单逐项检查检查项命令/操作预期结果问题定位Asset 节点是否存在MATCH (a:Asset) RETURN count(a)0若为 0Parser Agent 未工作Service 与 Vulnerability 关系MATCH (s:Service)-[r:HAS_VULNERABILITY]-(v:Vulnerability) RETURN count(r)0若为 0CVE 映射文件未加载或版本不匹配Privilege 节点是否定义MATCH (p:Privilege) RETURN p.name包含Domain Admin若无需手动创建或运行