最近社区里聊AI Agent做安全测试的人越来越多了pentagi这个名字也频繁出现在各种文章和讨论里。我自己把整个项目拉下来跑了几轮从部署到对话式发起扫描、再到人工确认执行整个过程确实和以前写脚本、敲命令的渗透方式很不一样。这篇就把我对 pentagi 的理解、部署过程、实际用法以及踩过的坑整理出来。1. pentagi是什么把“AI规划安全工具执行人工审批”串起来的框架1.1 传统渗透测试的痛点和AI入场的坑做安全测试的人都知道一次标准的渗透测试工作流大概长这样信息收集、端口扫描、服务识别、漏洞探测、漏洞利用、后渗透、报告输出。每个环节都有对应的工具nmap、hydra、sqlmap、ffuf、meterpreter各有各的用法。问题在于这些工具之间的数据是割裂的扫描结果需要人工去读、去判断、再手动敲下一条命令。整个流程非常依赖测试者的经验和临场判断稍微复杂点的目标一个人从早忙到晚可能才刚把信息收集做完。AI Agent 入场之后很多人第一反应是“让大模型帮我跑完整个渗透测试”。这个想法听起来很美好但实际落地的时候很容易翻车。大模型确实会写命令、会读输出但它在真实环境里的行为没那么可靠有时候它会编造一个不存在的工具参数有时候它会因为上下文太长忘了前面的扫描结果更麻烦的是如果完全放权让AI自动执行一旦它生成了一条破坏性命令后果很难控制。我在测试的时候见过不少类似案例AI自信满满地要往生产环境里丢 exp还好当时设计了人工确认环节。1.2 pentagi的定位与核心设计思想pentagi 这个项目本质上是对“AI做渗透测试”这个想法的一次工程化收敛。它不是让AI直接接管终端而是做了一个中间层AI负责规划、生成命令、分析结果但真正执行命令之前必须经过人的确认。它把 PentestGPT 的对话式引导思路和 AutoGPT 的自主任务分解能力结合到一起跑在 Docker 容器里通过安全的沙箱环境控制 AI 的权限边界。我觉得它的核心设计思想可以总结成三个词可控、可追溯、可交互。可控是指所有AI生成的操作都没有被静默执行必须显式批准可追溯是指每一步的命令输入和结果输出都会写入审计日志出了事能查可交互是指它不是一次性把整个测试方案丢给你而是像同事一样跟你对话边做边汇报。这个定位对真实环境很重要毕竟安全测试讲究授权范围、讲究风险控制不能用“赌一把”的心态去跑自动化。2. 部署前必须搞清楚的架构逻辑2.1 两个核心容器agent容器与cui容器部署 pentagi 之前我建议先搞明白它的运行架构。整个系统跑起来之后会有两个核心容器名字分别对应 agent 和 cui。cui 容器是“对话用户界面”你可以把它理解成前台接待负责把你在终端里敲的指令、上传的文件、提的问题包装成结构化的消息传给后端。agent 容器才是真正干活的它里面跑着 LLM 推理、工具调用逻辑和沙箱环境。这两个容器之间的通信不是简单的HTTP请求而是基于内部事件流。cui 容器收到用户消息后会转成事件推送给 agentagent 处理完生成回复事件再传回 cui最终渲染成你看到的对话内容。这个设计的好处是解耦以后如果你想做自己的前端界面只需要对接事件流就行不用动 agent 内部逻辑。另外要理解一点agent 容器里跑命令并不是直接在你宿主机上执行而是有一个独立的 shell 环境。AI 生成的每一条命令都是在容器内部被 fork 出来执行的。这就意味着即使AI发疯跑了一条rm -rf破坏范围也仅限于容器内部不会波及宿主机。2.2 LLM跟工具之间是怎么通信的现在大模型做 Agent 的主流方案是 Function Callingpentagi 也是走这条路。它把每个工具定义成可供模型调用的“函数”工具列表包括运行shell命令、创建文件、搜索进程、管理 docker 网络等。模型在对话过程中如果判断需要执行某个操作不是生成一句“我要运行nmap”而是生成一个结构化的函数调用请求比如调用 run_command 并带上参数。这个请求会先被 pentagi 的中间层拦截。中间层会做两件事一是检查这个命令是否符合预设的白名单规则二是把“人工确认”请求发回给用户。只有用户点了批准命令才会真正下发执行。命令输出会被捕获并作为函数调用结果返回给模型模型再基于这些结果做下一步决策。这个循环就是整个 pentagi 工作流的基础。所以你在使用的时候会感觉到一种“卡顿”AI每走一步都要停下来等你确认。这不是bug而是一种刻意设计的安全机制。你可以把它看作“人在回路”的强化学习框架只不过这里的反馈是人工审批不是梯度更新。2.3 环境准备与首次启动部署环境的准备比较直接。pentagi 依赖 Docker 和 Docker Compose 插件建议宿主机是 Linux 发行版我用的是 Ubuntu 22.04。存储方面agent 容器内会需要跑一些扫描工具镜像本身就包含了不少常见工具但如果你想加自定义字典或私有 exp要提前规划好挂载目录。内存建议至少 8GB如果模型走本地推理显存反而是更关键的瓶颈。我用的是 OpenAI 兼容的 API 后端所以没有在本地跑模型。如果你是离线环境也可以接 Ollama 之类的本地推理服务但要留足显存预算。初次启动之前需要先在.env文件里配置好 API Key、模型名称和危险命令白名单。这一点很关键后面我会专门讲配置细节。3. 从配置到跑通实际部署里的关键细节3.1 配置文件里的几个核心开关第一次看 pentagi 的配置文件时我有点眼花缭乱但其实需要重点关注的也就几个核心开关。第一个是模型提供方provider的配置。pentagi 支持多种 LLM 后端我测试时用的是 OpenAI 兼容接口。这里要特别提醒如果走代理网关或者自建的兼容服务base_url一定要写对很多“连不上模型”的问题都是因为这个地址末尾多了个斜杠或者少了/v1导致的。第二个是危险命令白名单。默认情况下pentagi 对命令执行有比较严格的管控很多高危操作会直接被拦截。你可以在配置里显式声明哪些命令允许AI执行比如nmap、curl、python3等等。这块需要根据你的测试目标灵活调整但又不能放得太宽。我的做法是“最小授权”只把当前任务确实需要的工具加进白名单其他一律保持默认拦截。第三个是会话超时和上下文长度。渗透测试往往是一个长对话几十轮交互下来Token 很容易耗尽。pentagi 提供了上下文截断机制但我建议你在使用层面也注意每隔一段就把历史会话导出存档别让单个会话无限膨胀。3.2 选择模型后端的注意事项模型选型对 pentagi 的实际效果影响非常大我自己的对比经验是不同模型在处理长上下文和 Function Calling 的准确性上差别很大。如果你用的是 GPT 级别的商业化模型Function Calling 的稳定性通常没问题但要注意成本一次完整的内网扫描可能产生非常可观的 Token 消耗。如果用的是开源模型本地部署便宜是便宜但“指令遵循”能力和长对话记忆会弱一些有时候会重复调用同一个工具或者答非所问。还有一个小细节模型返回的内容如果包含大段扫描结果会让 token 数量飙升。比如让AI跑一个全端口 TCP 扫描nmap 输出的结果可能几百上千行这些都会作为上下文的组成部分送回给模型。我的处理方式是在提示词里要求 AI 在分析结果时做摘要而不是复述全文同时养成定时清理陈旧上下文的好习惯。3.3 用Docker Compose启动的标准流程pentagi 提供了现成的 Docker Compose 编排文件整个启动流程并不复杂。我的标准操作流程是这样的git clone https://github.com/strukturag/pentagi.git cd pentagi cp .env.example .env vim .env在.env文件里我主要改这几项# 选一个模型提供方 PROVIDERopenai # API Key和模型名 API_KEYsk-xxxxxxx MODELgpt-4o # 允许AI执行的危险命令逗号分隔 DANGEROUS_CMDnmap,curl,wget,python3,hydra,sqlmap # 数据持久化目录 VOLUME_PATH/opt/pentagi/data配置好之后直接启动docker compose up -d docker compose logs -f cui首次启动会拉取镜像agent 镜像比较大需要等一会儿。启动成功后进入 cui 容器的交互界面docker exec -it pentagi-cui-1 /app/pentagi.py界面会显示一个交互式提示符在这里可以开始和 AI 对话。有一点要注意如果你修改了.env里的危险命令列表需要重建容器才能生效单纯重启不一定管用。我一开始就是因为改了配置没重建导致AI反复要求执行命令却被拦截排查了半天才发现是配置没加载。4. 实战用对话驱动一次内网端口扫描4.1 第一轮对话描述目标与授权范围跑通部署之后就可以开始正儿八经的对话式渗透了。我的第一个实验目标是一台测试内网机器大概处于10.10.10.0/24网段。启动 cui 界面后第一句话我给的并不是“扫端口”而是先做了个“背景设定”目的是让 AI 明白测试范围和工作边界。我当时是这么描述的“我现在要对 10.10.10.0/24 网段做一次授权范围内的初步信息收集目标是识别存活主机和开放端口不要做漏洞利用只做无损探测。”这里把“授权范围内”和“不做漏洞利用”两个条件提前锁死是非常有必要的。因为大模型在对话过程中容易被“渗透测试就是要拿到shell”这类预设带偏你不划清边界它可能会自主选择更激进的路径。AI 收到这条消息后会先生成一个执行计划列出它准备用什么工具、分几个阶段、每阶段做什么。这一步相当于“动工前的方案评审”如果这个计划里有你不认可的操作可以当场纠正不用等它做出来再叫停。4.2 AI生成命令并等待确认的过程计划评审通过后AI 开始执行第一步。它会调用工具函数生成一长串命令比如先做 ICMP 存活探测nmap -sn 10.10.10.0/24但注意这个命令并不会立刻执行。在 cui 终端里你会看到一条“待确认”的提示显示 AI 想执行的命令全文、目标对象、以及这个操作可能带来的影响说明。这时候你有三个选择批准执行、拒绝执行、修改命令。我习惯在批准前把命令复制到本地检查一遍确认没有奇怪的参数拼接再回车批准。这一步其实就是最终防线AI 的自动化再强也无法越过人的判断。命令执行完成后输出结果会回传到模型上下文里。AI 会根据回显内容做分析比如告诉你这个网段有多少台主机存活、每台主机的 TTL 值、哪些 Mac 厂商信息值得关注。这个“读回显并总结”的能力是 pentagi 相比传统脚本扫描最有价值的地方。以前我需要盯着终端一行行看现在AI会直接把关键结论提取出来。4.3 结果回填与下一步建议一轮扫描结束后AI 不会停下来等你手动布置下一轮。它会基于当前结果主动给出下一步建议。比如存活主机确认后它会建议对某些主机的特定端口做服务版本探测nmap -sV -p 22,80,443,3306 10.10.10.5同时给出这么做的理由因为这些端口对应的服务可能存在公开漏洞版本信息有助于后续做漏洞匹配。如果你同意只需要确认即可。这个“生成方案-人工确认-执行-分析-再生成方案”的循环会持续推进整个测试过程直到任务目标达成或者达到安全边界。我在整个测试过程中发现pentagi 的上下文管理做得比我想象中好。它会在对话中自动摘要前面的扫描结果而不需要完整保留所有原始输出。这使几十轮对话之后它依然能准确记得目标网段里有哪几台主机、各自的开放端口不会“失忆”。5. 跑完一轮后我踩过的坑和总结的经验5.1 人机交互环节最容易出问题的几个地方第一个坑是“过快批准”。因为确认流程太顺滑人容易产生机械操作看到 AI 生成了命令就直接回车根本没有仔细看。我有一次在测试中差点让 AI 执行一条针对宿主机网络命名空间的ip link set命令这个操作一旦在错误的环境下执行影响范围就不是一个容器能控制住的了。后来我给自己的使用定了铁律任何命令在批准之前要默读一遍特别是对网络配置、iptables、磁盘分区这类敏感操作必须谨慎再谨慎。第二个坑是“边界漂移”。这不是 bug而是 AI Agent 对话的通病。测试进行到第30轮时AI 可能会忘记第3轮设定的“不做漏洞利用”边界转而提出要尝试某种已知 exp。pentagi 虽然有人工确认机制但如果你没仔细想就批准了边界就形同虚设。我现在会在每轮重大操作前主动再强调一次边界条件相当于给 AI 做一次“提醒注入”。第三个坑和工具链有关。AI 生成的命令里经常会出现工具不存在的情况比如某些私有的辅助脚本。我在部署时给 agent 容器额外挂载了一个tools目录里面放了一些我自己写的辅助脚本同时在提示词里告诉 AI 有哪些可用工具这样它就不会一遍遍生成“不存在的工具命令”。5.2 长会话和Token消耗的教训Token 消耗是我这次实际体验里最“肉疼”的部分。端口扫描本身不贵贵的是把扫描结果反复读给模型听。一次完整的 TCP 全端口扫描输出轻松上万 token而如果目标网段再大一点一次任务几十万 token 就没了。我试过一次比较完整的测试消耗量大概是普通对话的50倍。针对这个问题我的经验是不要直接用全端口扫描先让 AI 用常见端口列表做个初步探测筛出存活服务后再针对性做细节扫描。同时在提示词里要求 AI 在返回结果时自动截断只输出关键状态和 Banner。另外如果任务量大可以拆分成多个会话而不是试图在一个会话里跑完全部流程。每个会话围绕一个子任务跑完导出记录再开启新会话。这样既能控制上下文长度也能减少模型“遗忘”导致的错误。5.3 权限与日志管理值得注意的细节最后想提醒一下部署层面容易忽略的问题。pentagi 的数据库和会话日志默认存在持久化目录里这些日志里包含非常敏感的信息比如目标 IP、扫描策略、甚至部分授权信息。如果这台机器是团队共用权限控制一定要收紧。目录权限设置成700或750普通用户不可读。再说 agent 容器的网络模式。默认情况下agent 容器可以与宿主机共享部分网络能力这样它才能扫描内网。但这同时也意味着攻击面扩大了。建议在部署时明确规划好 agent 容器能访问的网络范围必要时用 Docker 网络策略限制 egress 流量。pentagi 的默认配置相对保守但我们使用时要清楚它毕竟是一个能执行命令的容器不是玩具。还有一点是关于对话日志导出的。pentagi 可以把会话记录导出成文件用于后续审计这项能力建议每次任务结束都用起来。安全测试讲究可追溯AI 做过的每一步操作如果有完整的审计日志不管是验收还是复盘都会从容很多。最后再分享一个小技巧在开始正式测试前先用一个临时目标跑一遍完整流程检查配置、工具、权限是否都正常。这个“彩排”的成本很低但能帮你避开很多真正测试时才发现的环境问题。我每次换新环境部署 pentagi 都会这么干一遍后面正式用起来就顺得多。