企业官网建设流程全解析

1. 项目概述：Pentagi——一个面向渗透测试场景的自主AI代理实验框架

“Pentagi”不是某个已发布的商业产品，也不是某家大厂官宣的开源项目，而是一个由社区开发者自发组合命名的技术概念缩写——Penetration +ArtificialGeneralIntelligence（或更务实地说，AutonomousAgents forInformation Security）。它精准踩在当前三个高热度技术交汇点上：渗透测试（pentesting）的工程化瓶颈、大语言模型驱动的自主智能体（LLM-powered autonomous agents）的能力跃迁，以及Docker容器化带来的可复现、可编排、可审计的运行基座。我第一次在GitHub issue里看到这个词，是在一个叫redteam-llm-playground的私有仓库讨论中，有人用它代指“一套能自动完成信息收集→漏洞识别→利用尝试→报告生成闭环的轻量级红队AI代理系统”。后来在几个安全工具链的Docker Compose示例里反复出现pentagi-core镜像名，才确认它已从口头代号演变为实际落地的模块命名规范。

这个名称背后真正解决的问题很具体：传统渗透测试高度依赖人员经验与手动操作，一次完整Web应用评估动辄耗时数天，重复性任务（如子域名爆破、端口扫描、CMS指纹识别）占去60%以上时间；而现有AI安全工具要么是单点能力封装（比如只做漏洞描述生成），要么是黑盒SaaS服务（无法审计推理过程、无法接入内网靶机）。Pentagi的设计初衷，就是把LLM当作“红队指挥官”，把Nmap、Nuclei、SQLMap等经典工具当作“执行士兵”，再用Docker为每位士兵配发标准化装备包和隔离战场——所有动作都在容器内完成，每一步输入输出都可记录、可回溯、可重放。它不追求替代渗透工程师，而是让工程师从“操作员”升级为“战术设计师”：你定义目标范围、设定风险阈值、编写策略规则，剩下的侦察、试探、验证，交给AI代理集群去跑。适合三类人深度参考：一是想快速搭建红队AI实验环境的安全研究员，二是需要自动化交付渗透报告的乙方团队技术负责人，三是高校网络安全课程中设计AI+安全交叉实验的教师。它不是魔法盒子，但确实能把一次标准渗透流程的准备时间从8小时压缩到45分钟，且全程留痕——这才是真实世界里最值钱的部分。

2. 整体架构设计与技术选型逻辑

2.1 为什么必须用Docker作为底座？——不是为了时髦，而是为了生存

很多人第一反应是：“渗透测试用Docker？是不是太重了？” 实际上，恰恰相反——Docker在这里解决的是不可替代的生存级问题。我曾用纯Python脚本集成过LLM调用+Nmap扫描，结果在客户内网部署时崩溃三次：第一次是靶机防火墙拦截了Python进程的原始socket连接；第二次是客户IT部门禁用了/usr/bin/nmap路径，脚本找不到二进制文件；第三次最致命——不同Linux发行版的libpcap版本差异导致Nmap在CentOS上正常，在Ubuntu上直接core dump。这三次失败让我彻底放弃“裸跑”思路，转而拥抱容器化。Docker的核心价值在此刻凸显：它把环境依赖、权限控制、网络隔离、日志归集这四座大山一次性扛走。

具体来说，Pentagi的Docker设计遵循三个铁律：
第一，工具镜像原子化。每个安全工具（Nmap、Nuclei、ffuf）都独立构建基础镜像，例如pentagi/nmap:7.94只包含Nmap二进制、必要库和最小化Shell，镜像大小严格控制在35MB以内。这样做的好处是更新单一工具时无需重建整个平台，且能精确控制工具版本——渗透测试中，Nmap 7.93和7.94对某些WAF的绕过能力可能差一个关键commit。
第二，代理运行时沙箱化。LLM Agent不直接调用宿主机命令，而是通过Docker API启动临时容器执行任务。例如当Agent决定“对target.com进行目录爆破”，它会调用docker run --rm -v /tmp/pentagi-data:/data pentagi/ffuf:2.0.0 -u https://target.com/FUZZ -w /data/wordlists/directory-list-2.3-small.txt -o /data/reports/ffuf-target.json。这个命令的每一个参数都是动态生成的，但执行环境完全隔离，即使ffuf因超时被kill，也不会影响Agent主进程。
第三，数据流管道化。所有中间产物（扫描结果、POC验证日志、截图）统一存入挂载卷/tmp/pentagi-data，并按{timestamp}_{task_id}_{tool_name}格式命名。这使得后续LLM分析时，能精准定位“哪次Nmap扫描发现了8080端口，紧接着哪次Nuclei扫描在该端口检测到Spring Boot Actuator未授权访问”。没有这个结构化数据管道，AI代理的推理就成了无源之水。

提示：不要试图用Docker Desktop在Windows上跑Pentagi全栈——Virtualization Support Not Detected错误不是配置问题，而是架构冲突。Pentagi默认假设运行环境为Linux服务器（推荐Ubuntu 22.04 LTS），Docker Engine直连，避免Desktop层的抽象损耗。Windows用户请使用WSL2，并确保/etc/wsl.conf中启用[kernel] systemd=true。

2.2 LLM Agent为何不选闭源API？——成本、可控性与审计刚性

热搜词里高频出现“无限制无审核生成式AI”“无禁词虚拟AI聊天”，这恰恰暴露了当前AI安全工具的最大陷阱：把LLM当成黑盒聊天机器人用。Pentagi明确拒绝调用ChatGPT或Claude API，原因有三：
其一，成本不可控。一次完整渗透流程平均触发127次LLM调用（信息收集阶段32次、漏洞分析阶段45次、利用策略生成阶段50次），按GPT-4 Turbo 0.01$/1K tokens计算，单次测试成本超$15，而客户支付的渗透服务费通常在$2000-$5000区间。更致命的是，当Agent需要反复重试某个高风险利用步骤时（比如调整SQLMap payload绕过WAF），token消耗呈指数增长，账单可能瞬间失控。
其二，响应不可靠。我在实测中发现，同一段Nmap XML输出喂给不同厂商API，漏洞严重性评级差异高达3个等级（Critical→Medium）。这是因为各家模型训练数据中安全知识覆盖不均，且API返回格式不统一（有的返回JSON，有的混杂Markdown表格），迫使你在Agent层写大量解析适配代码——这违背了“让AI专注决策，让代码专注执行”的设计哲学。
其三，审计不可行。客户要求提供渗透过程全链路审计日志，包括“为何判断此端口存在漏洞”“依据哪条CVE描述生成利用方案”。闭源API只返回结论，不提供思维链（Chain-of-Thought）中间步骤。Pentagi强制所有LLM运行在本地，使用Ollama加载llama3:70b-instruct-q8_0量化模型，配合自定义System Prompt：“你是一名资深红队工程师，所有回答必须包含【推理依据】、【技术原理】、【验证方法】三部分，禁止使用模糊表述如‘可能’‘大概’”。这样生成的每条指令都自带可追溯的决策树。

注意：不要迷信“70B大模型一定更好”。在渗透测试场景中，模型尺寸与效果并非线性正相关。我对比过llama3:8b和llama3:70b在CVE描述理解任务上的准确率：8B模型为82.3%，70B模型为83.1%——仅提升0.8个百分点，但推理延迟从1.2秒飙升至8.7秒。Pentagi默认采用8B模型，仅在“生成0day利用PoC”等极少数高复杂度任务中动态切换至70B，这是经过237次压测后确定的性价比拐点。

2.3 Autonomous Agents的分层设计——指挥官、参谋、士兵的权责分离

Pentagi的Agent架构不是单体AI，而是三层协同体，每层解决不同维度的问题：

• 指挥官层（Orchestrator Agent）：运行在pentagi/core:latest容器中，职责是全局任务调度与状态管理。它接收用户输入的目标URL、资产范围、风险偏好（如“禁止主动利用”），将其拆解为有序任务序列（Task Graph）。例如输入https://demo.testfire.net，它会生成：① DNS枚举 → ② 子域名发现 → ③ 端口扫描 → ④ Web指纹识别 → ⑤ 漏洞扫描 → ⑥ 高危漏洞验证。关键设计在于，它不直接执行任何工具，只向消息队列（RabbitMQ）发布任务指令，并监听各任务容器的退出码与输出文件哈希值，动态调整后续路径——若③端口扫描发现8080端口关闭，则跳过⑤漏洞扫描中针对Tomcat的专项检查。
• 参谋层（Analyzer Agent）：运行在pentagi/analyzer:latest容器中，专精于结构化数据解读。当Nmap扫描完成，它读取nmap-output.xml，提取IP、开放端口、服务Banner，再调用本地CVE数据库（离线NVD镜像）匹配已知漏洞，生成结构化报告片段：{"ip":"192.168.1.10","port":22,"service":"OpenSSH","version":"7.9p1","cve":["CVE-2019-14889"],"severity":"High"}。它的核心能力是“把非结构化扫描结果转化为机器可消费的实体关系图”，这是LLM无法替代的确定性工作。
• 士兵层（Executor Agent）：即前述的Nmap/Nuclei等工具容器，纯粹执行命令。它们不联网、不读取外部文件、不写入宿主机——所有输入通过-v挂载卷注入，所有输出强制重定向到指定JSON文件。这种设计让每个士兵都是“一次性的”，符合渗透测试的最小权限原则。

这种分层不是过度设计，而是应对现实约束的必然选择。去年我们为某金融客户做合规渗透，监管要求“所有自动化工具执行必须有独立签名与时间戳”。分层架构下，只需在Executor容器启动时注入--signature $(openssl dgst -sha256 /path/to/task.json | cut -d' ' -f2)，即可实现每条命令级审计，而无需改造LLM模型本身。

3. 核心模块实现与关键配置详解

3.1 Docker镜像构建：从Dockerfile到生产就绪的12个细节

Pentagi的镜像构建不是简单FROM ubuntu:22.04 && apt install nmap，而是经过12道工序打磨的生产级实践。以pentagi/nmap:7.94为例，其Dockerfile核心片段如下：

# 基础镜像选择：alpine而非ubuntu，体积从220MB降至12MB FROM alpine:3.19 # 安装nmap时禁用所有非必要组件，仅保留核心扫描能力 RUN apk add --no-cache \ nmap=7.94-r0 \ && rm -rf /var/cache/apk/* # 创建非root用户并设置UID，避免容器内root提权风险 RUN addgroup -g 1001 -f pentagi && \ adduser -S pentagi -u 1001 # 设置工作目录与权限，强制所有操作在/data下进行 WORKDIR /data RUN chown -R pentagi:pentagi /data USER pentagi # 暴露标准端口仅作声明，实际不开启任何服务 EXPOSE 22 80 443 # 定义入口点，强制参数校验与超时控制 ENTRYPOINT ["/bin/sh", "-c"] CMD ["exec nmap -sS -T4 --max-retries 2 --host-timeout 300s \"$@\"", "nmap"]

这12个细节中，有7个是普通教程绝不会提及但线上必踩的坑：

1. Alpine替代Ubuntu：不是为了“轻量”，而是规避glibc兼容性问题。Nmap官方预编译二进制依赖musl libc，Alpine原生支持，Ubuntu需额外安装兼容层，增加不可控变量。
2. 精确版本锁定：nmap=7.94-r0中的-r0表示Alpine仓库中的确切revision号。若只写nmap=7.94，下次构建可能拉取7.94-r1（含安全补丁），导致扫描行为微变——这在渗透测试中是灾难性的，客户可能质疑“为何上次没发现这个端口”。
3. --no-cache参数：防止apk缓存污染镜像层，确保每次构建镜像SHA256值唯一，便于审计溯源。
4. 非root用户强制切换：USER pentagi必须放在WORKDIR之后，否则chown命令会因权限不足失败。这是Dockerfile语法陷阱，新手常在此处卡住。
5. WORKDIR权限预设：chown -R pentagi:pentagi /data必须在USER指令前执行，因为只有root能修改目录所有权。顺序错乱会导致容器启动即报错Permission denied。
6. ENTRYPOINT与CMD的协作：ENTRYPOINT固定为shell wrapper，CMD传递实际参数，这样既能校验-p参数合法性（防命令注入），又能统一添加--host-timeout等安全超时。
7. EXPOSE仅为文档声明：Pentagi所有工具容器均不监听端口，EXPOSE仅用于docker inspect时查看元数据，避免新人误以为需映射端口。

其他5个细节体现在CI/CD流程中：镜像构建必须通过Git Commit Hash触发，每次推送都生成形如pentagi/nmap:7.94-gitabc123的标签；镜像扫描集成Trivy，阻断CVE评分≥7.0的漏洞；构建缓存禁用，确保零依赖污染；多阶段构建中，build-stage安装编译工具，final-stage仅复制二进制，彻底剥离dev依赖；最后，镜像Manifest中嵌入SBOM（Software Bill of Materials），供客户审计供应链。

3.2 Agent通信协议：基于AMQP的消息队列设计

Pentagi摒弃HTTP RESTful API，采用AMQP协议（通过RabbitMQ实现）作为Agent间通信总线，原因直击痛点：

• 异步解耦：Orchestrator发布任务后无需等待Executor完成，可立即处理下一个任务。在扫描100个子域名时，若用HTTP同步调用，平均RTT 200ms × 100 = 20秒纯等待；AMQP下，所有任务并发投递，总耗时≈单个最长任务耗时（约8秒）。
• 死信队列（DLX）容错：当Executor容器因OOM被Kill，RabbitMQ自动将消息路由至DLX，Orchestrator消费DLX消息后，可选择重试（加指数退避）、降级（改用更保守扫描参数）或告警。这比HTTP超时重试更精细。
• 优先级队列：为高危任务（如SQL注入验证）设置priority=10，低危任务（如robots.txt解析）priority=1，确保关键路径永远优先执行。

消息体采用Protocol Buffers序列化（非JSON），定义如下：

syntax = "proto3"; message PentagiTask { string task_id = 1; // UUID v4, 全局唯一 string tool_name = 2; // nmap, nuclei, ffuf... string target = 3; // 目标地址，支持domain/ip/cidr map<string, string> params = 4; // 工具特有参数，如nmap的"-p 1-1000" int32 priority = 5; // 0-10, 默认5 int32 timeout_seconds = 6; // 任务最大执行时间 string output_path = 7; // 容器内输出文件路径 }

关键配置在docker-compose.yml中：

rabbitmq: image: rabbitmq:3.12-management environment: RABBITMQ_DEFAULT_USER: pentagi RABBITMQ_DEFAULT_PASS: securepass123 volumes: - rabbitmq_data:/var/lib/rabbitmq # 启用插件支持优先级队列 command: > sh -c "rabbitmq-plugins enable rabbitmq_priority_queue && exec docker-entrypoint.sh rabbitmq-server" pentagi-orc: build: ./orchestrator environment: RABBITMQ_URL: amqp://pentagi:securepass123@rabbitmq:5672 # 设置QoS，避免Orchestrator内存溢出 PREFETCH_COUNT: "10"

实操心得：Prefetch Count必须设为10而非默认的无限。当Orchestrator处理速度慢于任务生成速度时（如批量导入1000个域名），无限Prefetch会导致RabbitMQ将所有消息推入Orchestrator内存，最终OOM崩溃。设为10意味着Orchestrator最多缓存10条待处理消息，其余留在RabbitMQ队列中，既保障吞吐又防崩。

3.3 LLM本地化部署：Ollama + 自定义Prompt Engineering

Pentagi的LLM运行时基于Ollama，而非直接调用transformers库，原因在于运维友好性：Ollama提供统一CLI、模型自动下载、GPU显存智能分配（支持CUDA/NVIDIA Container Toolkit）、HTTP API兼容性。部署命令仅需两行：

# 在宿主机安装Ollama（Ubuntu） curl -fsSL https://ollama.com/install.sh | sh # 拉取并量化模型（自动选择最优精度） ollama pull llama3:8b-instruct-q8_0

但真正的技术难点在于Prompt Engineering。Pentagi的System Prompt不是简单“你是个安全专家”，而是结构化决策引擎：

你是一名持有OSCP认证的红队工程师，正在执行客户授权的渗透测试。你的输出必须严格遵循以下格式： 【任务类型】信息收集|漏洞识别|利用策略|报告生成 【输入数据】简述接收到的原始数据（如Nmap XML片段） 【推理依据】引用NIST SP 800-115或OWASP Testing Guide第X章，说明为何此现象指向特定风险 【技术原理】用不超过3句话解释漏洞成因（禁用术语堆砌，举例：Spring Boot Actuator未授权访问=管理员接口暴露在公网，攻击者可直接调用/shutdown端点关机） 【验证方法】给出1条可立即执行的curl命令或nmap命令，要求包含--data或-p参数体现验证意图 【风险评级】CVSS 3.1分数（0.0-10.0），必须计算：BaseScore = round( (AttackVector * 0.85) + (AttackComplexity * 0.5) + ... , 1) 【行动建议】明确写出下一步指令（如“启动nuclei -t cves/CVE-2023-1234.yaml -u https://target.com”） 禁止输出任何与上述结构无关的内容，禁止使用“可能”“或许”等模糊词汇。

这个Prompt经过27轮迭代优化。早期版本允许LLM自由发挥，结果生成大量“建议使用Burp Suite抓包分析”这类无效建议——而Pentagi环境根本没装Burp。最终版强制结构化输出，使后续Parser能100%准确提取【行动建议】字段，直接转换为Docker命令。实测显示，结构化Prompt使任务指令生成准确率从63%提升至94.2%，且减少87%的后处理代码。

3.4 数据持久化设计：挂载卷的黄金分割法则

Pentagi的数据流分为三类，对应三种挂载策略：

• 瞬态数据（Transient）：单次任务中间文件（如Nmap临时PCAP、ffuf爆破缓存），生命周期=容器存活期。挂载方式：-v /tmp/pentagi-tmp:/tmp，宿主机路径设为tmpfs内存盘，避免SSD写入磨损。
• 持久数据（Persistent）：扫描报告、漏洞证据截图、任务审计日志，需长期保存。挂载方式：-v /opt/pentagi/data:/data，宿主机路径为RAID1阵列，启用chown 1001:1001确保容器内pentagi用户可写。
• 共享配置（Shared Config）：Wordlist字典、NVD CVE数据库、自定义PoC模板，所有容器只读共享。挂载方式：-v /opt/pentagi/config:/config:ro，ro标志防止Executor意外修改配置。

关键细节在于/data目录的子目录规划，这是保证LLM能精准定位数据的基石：

/opt/pentagi/data/ ├── tasks/ # 任务元数据，按YYYYMMDD组织 │ ├── 20240520/ │ │ ├── task_abc123.json # Orchestrator生成的任务定义 │ │ └── task_def456.json ├── reports/ # 结构化报告，按task_id索引 │ ├── task_abc123/ │ │ ├── nmap.json # Executor输出的标准化JSON │ │ ├── nuclei.json │ │ └── analyzer_output.json # 参谋层生成的CVE关联报告 ├── evidence/ # 二进制证据，按工具分类 │ ├── screenshots/ # 浏览器截图，命名含timestamp │ └── payloads/ # 成功利用的payload，含原始请求/响应 └── logs/ # 审计日志，按容器名分割 ├── orchestrator.log ├── analyzer.log └── executor_nmap.log

这套目录结构被硬编码进所有Agent的代码中。当Analyzer Agent处理task_abc123时，它自动读取/data/reports/task_abc123/nmap.json，写入/data/reports/task_abc123/analyzer_output.json。这种强约定消除了配置文件依赖，让整个系统具备“零配置部署”能力——只要挂载卷路径正确，容器启动即可用。

4. 实操全流程演示：从零部署到首次渗透测试

4.1 环境准备：5分钟完成生产级初始化

在Ubuntu 22.04服务器上，执行以下命令完成Pentagi环境搭建（全程无需root密码，所有操作在普通用户权限下完成）：

# 1. 安装Docker Engine（非Docker Desktop） curl -fsSL https://get.docker.com | sh sudo usermod -aG docker $USER newgrp docker # 刷新组权限，避免重启 # 2. 安装Ollama（自动适配CUDA） curl -fsSL https://ollama.com/install.sh | sh # 3. 创建Pentagi专用目录结构 mkdir -p /opt/pentagi/{data,config,logs} sudo chown -R $USER:$USER /opt/pentagi # 4. 初始化挂载卷（关键！） sudo mkdir -p /tmp/pentagi-tmp sudo mount -t tmpfs -o size=2g tmpfs /tmp/pentagi-tmp echo "tmpfs /tmp/pentagi-tmp tmpfs size=2g 0 0" | sudo tee -a /etc/fstab # 5. 下载Pentagi核心镜像（国内用户替换为阿里云镜像源） docker pull pentagi/core:latest docker pull pentagi/analyzer:latest docker pull pentagi/nmap:7.94 docker pull pentagi/nuclei:3.2.0 # 6. 启动RabbitMQ（带Management UI） docker run -d \ --name rabbitmq \ -e RABBITMQ_DEFAULT_USER=pentagi \ -e RABBITMQ_DEFAULT_PASS=securepass123 \ -p 5672:5672 -p 15672:15672 \ -v rabbitmq_data:/var/lib/rabbitmq \ rabbitmq:3.12-management

注意：mount -t tmpfs命令必须执行，否则Executor容器在/tmp写入大文件时可能耗尽磁盘空间。我曾因忽略此步，在扫描大型资产时触发宿主机OOM Killer，强制杀死所有Docker进程。tmpfs大小设为2GB是经过压力测试的平衡点：足够容纳100个并发Nmap扫描的临时文件，又不至于占用过多内存。

4.2 首次任务提交：手动生成一条渗透指令

不依赖任何前端界面，直接通过curl向Orchestrator API提交任务（Pentagi默认启用HTTP API，端口8000）：

# 构建任务JSON（注意：target必须是域名，IP需先DNS解析） cat > task.json << 'EOF' { "target": "testphp.vulnweb.com", "scope": "subdomain", "risk_preference": "high", "initial_tasks": [ {"tool": "nmap", "params": ["-sV", "-p-", "--min-rate", "1000"]}, {"tool": "nuclei", "params": ["-t", "/config/templates/cves/", "-u"]} ] } EOF # 提交任务（Orchestrator会自动拆解为多个子任务） curl -X POST http://localhost:8000/api/v1/tasks \ -H "Content-Type: application/json" \ -d @task.json # 返回：{"task_id": "task_7f8a2b3c", "status": "accepted"}

Orchestrator接收到请求后，执行以下动作：

1. 生成UUIDtask_7f8a2b3c，创建/opt/pentagi/data/tasks/20240520/task_7f8a2b3c.json
2. 向RabbitMQpentagi.tasks队列发布两条消息：
   • 消息1：{"tool_name":"nmap","target":"testphp.vulnweb.com","params":["-sV","-p-","--min-rate","1000"],"output_path":"/data/reports/task_7f8a2b3c/nmap.json"}
   • 消息2：{"tool_name":"nuclei","target":"testphp.vulnweb.com","params":["-t","/config/templates/cves/","-u"],"output_path":"/data/reports/task_7f8a2b3c/nuclei.json"}
3. 返回HTTP 202 Accepted，不等待执行结果

此时，可通过docker logs -f pentagi-orc实时观察Orchestrator日志，看到类似输出：
INFO: Task task_7f8a2b3c accepted. Queued 2 subtasks to RabbitMQ.

4.3 执行过程监控：从容器日志到结构化报告

Executor容器启动后，日志输出被重定向至/opt/pentagi/logs/executor_nmap.log。典型日志片段：

2024-05-20 14:22:31 INFO Starting nmap scan for testphp.vulnweb.com 2024-05-20 14:22:31 DEBUG Executing: nmap -sV -p- --min-rate 1000 testphp.vulnweb.com -oX /data/reports/task_7f8a2b3c/nmap.xml 2024-05-20 14:27:15 INFO Scan completed. Exit code: 0. Output size: 12.7MB 2024-05-20 14:27:15 INFO Converted nmap.xml to /data/reports/task_7f8a2b3c/nmap.json

关键在最后一行：Executor不仅执行Nmap，还调用内置nmap-xml-to-json工具，将原始XML转换为结构化JSON。生成的nmap.json核心字段：

{ "scan_info": {"args": "nmap -sV -p- --min-rate 1000 testphp.vulnweb.com", "start": 1716214951}, "hosts": [ { "address": "74.125.239.147", "ports": [ { "portid": "80", "protocol": "tcp", "state": "open", "service": {"name": "http", "product": "Apache httpd", "version": "2.2.14"} } ] } ] }

Analyzer Agent监听/data/reports/task_7f8a2b3c/nmap.json变化，一旦文件写入完成，立即触发分析流程：

• 解析hosts[].ports[]，提取Apache httpd 2.2.14
• 查询本地NVD数据库，匹配CVE-2011-3192（Apache Range Header DoS）
• 生成analyzer_output.json：

{ "task_id": "task_7f8a2b3c", "findings": [ { "cve_id": "CVE-2011-3192", "severity": "High", "cvss_score": 7.8, "description": "Apache HTTP Server 1.3.25 to 2.2.21 allows remote attackers to cause a denial of service via a Range header with many overlapping ranges.", "evidence": "Service banner: Apache httpd 2.2.14", "recommendation": "Upgrade Apache to version 2.2.22 or later." } ] }

整个过程全自动，无需人工干预。从任务提交到生成首份结构化漏洞报告，实测耗时4分38秒。

4.4 报告生成与人工介入点：何时以及如何接管AI

Pentagi的最终输出不是HTML页面，而是/opt/pentagi/data/reports/task_7f8a2b3c/final_report.md，内容为Markdown格式，包含：

• 执行概览（总耗时、调用工具数、发现漏洞数）
• 资产地图（IP-端口-服务拓扑图，由Graphviz生成）
• 漏洞详情表（CVE ID、CVSS分数、证据截图路径、修复建议）
• 附录（原始Nmap XML、Nuclei JSON、所有curl验证命令）

但Pentagi明确设计了人工介入锚点：在报告末尾，自动生成Human Review Required章节：

## Human Review Required The following findings require manual verification due to low-confidence detection: - CVE-2023-1234 (CVSS 6.2): Detected via Nuclei template 'cves/CVE-2023-1234.yaml'. Verification failed with HTTP 403. Please check if WAF is blocking requests. - SQL Injection in /login.php: Analyzer inferred from error message 'You have an error in your SQL syntax', but no PoC was executed. Manual testing recommended. Action items: 1. Run `curl -v 'https://testphp.vulnweb.com/login.php?username=test&password=test'` to confirm error message. 2. Use Burp Suite to test time-based blind SQLi on login form.

这个章节不是AI胡猜，而是基于Executor的退出码与日志关键词动态生成：当Nuclei返回exit code 1（表示未发现漏洞）但Analyzer仍标记为Medium风险时，触发此提示；当SQLMap执行因超时中断，Analyzer检测到"timeout"字样，即标注需人工验证。这体现了Pentagi的设计哲学：AI负责高效覆盖，人类负责关键决策——两者不是替代关系，而是增强关系。

5. 常见问题排查与独家避坑指南

5.1 Docker相关故障速查表

5.2 LLM与Agent协同故障诊断

问题：Orchestrator持续消费RabbitMQ消息但无Executor响应

• 排查路径：docker ps \| grep executor→ 若无容器运行，检查docker logs pentagi-orc是否有`Failed to start executor container: permission denied