Pentagi：开源AI Agent驱动的渗透测试辅助系统部署与实践

做安全这一行时间越久越会发现真正耗人的往往不是某个“硬骨头”漏洞而是渗透测试流程里那些重复度极高、又不得不做的环节。端口探测、服务识别、指纹收集、公开漏洞匹配、报告整理这些工作在每一个项目里几乎都要来一遍。Pentagi这个项目我在它刚开源那阵子就盯上了最近特意在隔离靶场里完整跑了一遍感觉可以写点实在的东西。Pentagi的定位很简单一套开源的、以AI Agent为核心的渗透测试辅助系统。它把大模型接进测试流程让模型能自己拆解目标、制定步骤、调用常见工具、回传结果最终生成一份结构化的测试报告。说白了它想干的事情是给安全人员配一个“会做事、能留痕、还不会累”的测试助理。有安全基础的同学可以直接跳到第3节看部署想先理解它为什么这么设计、边界在哪就从上往下读。整篇文章里我不会贴大段源码重点讲清楚它能做什么、怎么部署、以及实际跑起来会遇到哪些坑。1. Pentagi是什么把AI Agent拉进渗透测试流程的开源系统1.1 它解决的核心问题我先把背景讲清楚。传统的渗透测试流程大致可以分成五个阶段授权与范围确认、信息收集、漏洞分析、漏洞利用尝试、报告输出。前两个阶段和后一个阶段占用的时间通常比很多人想象的多。一个中型目标资产光端口和服务识别手工做可能就要一个下午更不用说后面要把结果整理成表格再贴进报告。Pentagi想处理的正是这些“重复但又有判断要求”的工作。它在后端维护了一套任务和上下文体系AI Agent收到你的需求后先自己列出计划再一步一步执行每一步产生的输出都会写回数据库。这套体系跟普通“开个聊天窗口问GPT”最大的区别是它不是只给你建议而是能直接调用工具、执行命令、保存结果。换句话说大模型在这里不是一个问答机器人而是一个有“手”的执行体。另外还有个很实际的痛点安全人员同时处理多个项目时上下文切换成本很高。Pentagi把客户、工作区、任务、会话都做了对象化存储切回来继续干时之前的扫描结果、命令记录、分析结论都还在不用靠脑子记也不用靠记事本凑。1.2 适合谁来用我给三类人列一下使用场景。第一类是安全团队的成员尤其是经常做授权测试、SRC挖洞、众测的人。Pentagi能把最花时间的信息收集和验证环节自动化让人集中精力做判断和利用。第二类是在研究AI Agent落地攻防场景的人这类人可能不一定会把它用在日常项目里但Pentagi的架构设计——工具调用、任务状态机、人审机制——本身就很有学习价值甚至可以作为二次开发的底座。第三类是负责企业安全运营、需要定期对内部系统做验证测试的工程师在明确的授权和隔离环境下这类工具能明显提升测试覆盖率和复盘效率。需要强调一下Pentagi不是一个拿来就能“全自动打点”的工具我后面会专门讲它所谓的“自主”到底在哪一层以及为什么这个设计对安全测试尤其重要。2. 系统架构拆解一条任务从下达到回填是怎么流转的2.1 一条请求从界面走到模型再回到结果理解一个系统最有效的方式是跟着一条数据流走一遍。以我实际使用的场景为例我在Web界面里创建一个会话输入任务“对 10.10.10.8 做一次端口扫描识别服务版本并尝试匹配已知漏洞”接下来发生的事大致是这样的首先这个任务会落到后端服务后端把它拆成一条带有状态的任务记录存进PostgreSQL。随后AI Agent的主循环被唤醒它读取任务描述和关联的上下文比如工作区里的目标清单、历史扫描结果组织成一次模型请求发给配置好的大模型接口。模型返回的内容不是普通聊天文本而是一种结构化的工具调用意图。Agent runtime解析后会去执行对应的动作。例如调用端口扫描工具、解析扫描结果、把结果写回数据库然后带着新的结果再发起下一轮模型请求。这个“读取上下文—请求模型—执行工具—回写结果—再次请求”的循环会一直持续到任务完成、错误次数超限或者人工介入。2.2 核心组件与数据存储Pentagi的部署形态是典型的容器化多服务结构。核心组件不需要太多我跑通时主要看到四类角色Web前端负责交互后端服务负责业务逻辑和Agent调度PostgreSQL负责所有持久化数据此外还有一个或多个用于工作区隔离的容器运行环境AI要执行的命令和工具基本都在这个环境里运行。选PostgreSQL不是没有原因的。渗透测试过程中会产生大量半结构化数据比如扫描输出、HTTP响应片段、Nmap的XML结果这些用JSONB类型存储非常顺手。同时任务状态、会话上下文、报告内容之间的关联关系用关系型数据库来维护也更清晰。后端的Agent调度逻辑在处理“当前任务进行到哪一步、下一步该做什么”时依赖的就是这些状态表。有一点值得提Pentagi把AI模型接口设计成了OpenAI兼容格式。这带来一个很大的好处——模型本身是可替换的。你可以用它对接商业模型也可以指向本地部署的模型网关。不同模型在工具调用能力上的差异会直接影响任务执行的效果。我实测下来模型对“工具调用格式”的理解能力是最大的变量这一步做不好后面的执行环节全都会卡壳。2.3 “自主”与“人工确认”的边界这个词值得专门拉出来聊。很多朋友一看到“全自主AI渗透测试系统”第一反应是“是不是扔个目标进去AI就自动打穿了”。如果抱着这个预期去用大概率会失望而且说实话在安全领域“完全无人工”也不是一个负责任的设计方向。Pentagi对“自主”的处理简单来说是在低风险、可重复的环节尽量自动化在高风险、不可逆或需要专业判断的环节保留人工确认点。比如扫描端口、抓取页面、比对指纹这类操作完全可以让AI自己跑但是在执行利用动作、发送特定攻击载荷、或者进行一些可能影响目标的尝试之前系统设计中应当有确认机制这也是安全测试中授权和可控原则的体现。我在实际使用中是把Pentagi当作一个能大幅提升效率的“半自主助理”来看的。它真正解放的是信息收集、整理、初步分析这些高耗时低判断环节而最终决策权始终应该留在人手里。搞清楚这个边界再去看它的各种功能设计你会觉得很多细节都顺理成章。3. 本地部署实操从克隆仓库到界面能打开3.1 环境准备部署Pentagi我的建议是准备一台至少4核8G的Linux服务器或者配置高一点的本地虚拟机。模型本身不在这台机器上跑的话这个配置跑服务端和数据库是够用的如果你还要在同一台机器跑本地模型那就另说了至少得从16G内存起步。系统层面需要装好Docker和Docker Compose插件。具体安装方式不同发行版有差异我这边用的是Rocky LinuxDocker用官方脚本装的Compose用v2插件。装完后确认一下命令是否可用docker version docker compose version然后选择软件目录开始拉代码。Pentagi是开源项目直接在GitHub上搜索Pentagi就能找到仓库。我习惯把它放在/opt/pentagi下面个人使用放自己家目录也没问题。3.2 配置 .env 的核心参数仓库拉下来之后第一步不是急着启动而是先把配置搞定。项目会提供一个.env.example模板复制成.envcp .env.example .env我来说几个关键项的配置思路。数据库相关的配置主要是一个独立的强密码别用默认值。JWT密钥也要改成一个足够随机的字符串。管理账号一般可以通过初始化命令或界面注册生成但如果你希望首次启动后就能直接登录需要按照README里的指引设置好初始账号信息。然后是模型接口配置。这里会有API Key、Base URL和模型名三组参数。如果你用商业模型Base URL填官方接口即可如果你走本地网关或者第三方兼容网关就填对应的地址。模型名一旦写错任务会一直卡在调用失败上而且日志里的报错有时并不直观所以一定要先确认模型名与网关里命名的完全一致。有一个常见误区直接在配置里填一个很长的系统提示词或者任务指令。Pentagi的系统级提示词一般是内置的普通用户只需要通过界面下发具体任务不要在配置文件里去魔改Prompt。这会导致后续行为不可控排查问题的时候非常痛苦。3.3 初始化数据库与启动配置完成后执行数据库迁移和初始化。这一步在Pentagi里一般通过容器的启动脚本或单独的命令完成具体以仓库README为准。实际过程说白了就是创建表结构、写入内置角色和默认配置跑完之后数据库里会多出一批初始记录。一切就绪后启动服务docker compose up -d docker compose ps docker compose logs -f backend首次启动最需要关注的日志信息是数据库连接是否成功、模型接口是否可达、以及管理账号初始化日志。如果数据库连不上后面所有功能都会废掉如果模型接口不通界面能开但是任务跑不动。3.4 验证部署是否正常服务起来之后先不要急着下任务做两个基础验证。第一Web界面能否正常访问。Pentagi默认会映射一个本机端口访问后能看到登录页那就说明前端和后端之间的基础链路通了。第二在界面里尝试登录并创建一个最轻量的会话。如果创建会话后能正常看到会话列表接下来可以下一个小任务比如让AI“使用nmap对127.0.0.1进行一次快速扫描”。这个小任务可以同时验证数据库读写、AI接口调用、工具执行能力三条链路。说句实在话第一次跑通这个最小闭环之后后面的事情就顺利多了。很多配置问题其实都集中在模型接口、数据库初始化这两步只要这两块不报错系统基本能稳定跑下去。4. 上手使用从建客户到下任务再到拿报告4.1 在Web界面里管理客户与工作区登录进Pentagi之后第一个感观是界面并不复杂。第一步是建立客户与项目。Pentagi里客户对应一次测试的业务发起方项目挂在客户下面。这套设计不是摆设它让你在同时服务多个业务方时资产、任务、报告都能分得清清楚楚。创建完客户和项目之后接下来是创建工作区。工作区可以理解为一次测试活动的独立环境。在真正开始任务前建议先把测试范围、目标地址、以及相关资产信息维护好。目标可以是一个IP、一个网段也可以是一批URL。这个步骤对应于渗透测试里的“范围确认”把范围先定死AI后续才不会发散。4.2 创建会话并给AI下发任务在会话里给AI下任务我建议遵循“目标约束产出”的结构。比如你写“对 10.10.10.8 进行端口扫描识别开放的HTTP服务并尝试获取服务器响应头”就比“扫描这个IP”要高效得多。模型对目标越明确执行越稳。任务描述里最好附带约束条件比如“只做被动信息收集”“不执行任何利用动作”。这不仅是安全边界问题也会影响模型在工具调用时的决策倾向。我实际测试的时候发现明确写“先只做扫描不进行漏洞利用”Agent会明显更收敛不会动不动去跑一些激进的模块。我也试过比较模糊的表述比如“看看这个目标有什么问题”结果AI的自由度会变得很大花了更多token在一些不重要的路径探测上。所以想让AI干活省心前提是你自己得先把任务边界想清楚。这个习惯放到团队协作里也是一样的道理。4.3 任务执行中的上下文与工具调用在任务执行过程中Pentagi的核心是“上下文”和“工具调用”两个机制。上下文指的是AI在某一个时刻能看到的全部信息集合包含任务描述、历史命令输出、当前工作区资产、扫描结果摘要等。工具调用则是AI“动手”的方式比如调用扫描器、执行Shell命令、读取文件、查询数据库。这里有一个对实际效果影响很大的点模型上下文长度。Pentagi会把前几轮的扫描输出都带回给模型如果扫描目标较大输出文本会很快膨胀。实际使用中我通常会建议模型“只输出关键端口和状态码不要贴完整响应体”这样能有效控制上下文占用减少无意义的token消耗。同时Pentagi很多任务会生成时间线每个关键动作都有记录。这也意味着当任务结果异常或者需要复盘时你可以非常清楚地看到AI做了哪几步、在哪里卡住。对于安全团队来说这种“过程留痕”比单纯的结果输出更有价值也是做汇报、做整改时的重要依据。4.4 查看结果与报告输出任务跑完后真正的成果要落下来。Pentagi会把整个任务过程中的关键发现统一整理形成一个结构化结果。你可以按客户、项目、工作区去查看历史任务所有扫描数据、执行记录、AI分析结论都在里面。我自己用得比较多的是“导出报告”这个环节。以前做项目报告撰写是最花时间的现在可以把AI生成的初步结论作为底稿我再手工补充利用细节和风险等级效率提升非常明显。但有一句经验一定要说无论AI输出多像回事涉及具体风险的结论人一定要复核尤其是涉及资产影响面、数据敏感性判断的时候绝不能直接照搬。5. 踩坑清单部署和运行阶段最常见的几类问题5.1 模型调用失败或超时这个坑我猜90%的自部署玩家都会遇到。表现是界面正常、任务也能创建但Agent一直卡在“思考中”或者在日志里反复报调用失败。排查优先级就三条确认API Key和Base URL是否正确特别是Base URL结尾的路径不同网关要求不一样确认模型名与上游完全一致确认网络能连通模型接口必要时先在服务器上curl一下模型接口地址。超时的场景大多是上下文过长导致的。任务中扫描结果太多模型接口一次性处理不过来就会超时。我的处理方法是下调单轮输出长度、控制扫描结果回传量或者在任务描述里明确“结果精简输出”。如果你是接本地模型还要重点关注显存占用别让推理服务和后端抢资源。5.2 数据库连接相关报错PostgreSQL连接失败的报错常见于数据库容器还没就绪后端就抢先启动了。这种情况一般重启后端容器就好让它重新建立连接。如果反复失败要检查数据库密码是否匹配、初始化脚本是否正常执行、以及数据库容器本身日志里有没有磁盘权限问题。另一个容易忽略的是数据库版本兼容。升级Pentagi版本时如果数据库初始化脚本有变更建议按官方文档执行迁移不要直接拿旧数据目录跑新镜像。我之前偷懒跳过迁移结果任务表缺字段报错一堆老老实实重新初始化才解决。5.3 容器启动异常与工作区权限工作区容器主要用于执行AI的命令因此对挂载目录的权限非常敏感。如果启动时报告“permission denied”或者文件无法写入基本就是当前用户和容器用户的UID不一致。解决办法很简单调整挂载目录的所有权让容器用户可写即可。还有一类问题是磁盘空间。AI任务会产生大量中间文件特别是启动多个扫描器时日志和结果文件可能快速膨胀。建议给工作目录单独划分分区并定期清理无用数据。这听起来像废话但我真见过因为磁盘写满导致报告导不出来的案例。5.4 常见问题速查表现象可能原因处理方式任务一直卡在思考中模型接口不通、API Key错误、上下文过长检查模型配置精简任务输出数据库连接反复失败密码不匹配、容器未就绪、初始化脚本未执行重启后端核对数据库配置工作区无法执行命令挂载目录权限不足、容器用户UID不一致调整目录所有权重启相关容器报告导出失败磁盘空间不足、数据记录异常清理磁盘检查任务状态表和报告生成日志模型结论明显错误模型幻觉、上下文信息不足人工复核补充目标信息后重新下任务5.5 使用边界与合规注意事项这一点放在最后但分量最重。Pentagi这类工具只能用于你有明确授权的目标。无论是自己搭的靶机、实验环境还是公司内部授权的测试项目都应该先圈定范围、写清授权条款。不要用它对未授权的资产做探测也不要在生产系统上执行任何不可控的操作。这不仅是职业底线也是对自己和团队的保护。另外一个边界是模型本身。大模型在网络安全场景下同样会有幻觉它可能把一个并不存在的漏洞说得头头是道。因此无论系统多么“自主”最终的安全判断、风险定级、整改建议一定要由人来兜底。我个人在实际使用中的体会是这类工具的理想用法是“把它当新人队友而不是当自动武器”。它替你干最累的活但决策和担责的永远是你。最后再分享一个小技巧每次跑完任务记得把会话里的关键命令和结果整理到项目文档里。时间一长你会发现这就是最宝贵的一手知识库比任何外部资料都贴合你自己的测试习惯。