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 Linux，Docker用官方脚本装的，Compose用v2插件。装完后确认一下命令是否可用：

docker version docker compose version

然后选择软件目录，开始拉代码。Pentagi是开源项目，直接在GitHub上搜索Pentagi就能找到仓库。我习惯把它放在/opt/pentagi下面，个人使用放自己家目录也没问题。

3.2 配置 .env 的核心参数

仓库拉下来之后，第一步不是急着启动，而是先把配置搞定。项目会提供一个.env.example模板，复制成.env：

cp .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 常见问题速查表

5.5 使用边界与合规注意事项

这一点放在最后，但分量最重。

Pentagi这类工具只能用于你有明确授权的目标。无论是自己搭的靶机、实验环境，还是公司内部授权的测试项目，都应该先圈定范围、写清授权条款。不要用它对未授权的资产做探测，也不要在生产系统上执行任何不可控的操作。这不仅是职业底线，也是对自己和团队的保护。

另外一个边界是模型本身。大模型在网络安全场景下同样会有幻觉，它可能把一个并不存在的漏洞说得头头是道。因此，无论系统多么“自主”，最终的安全判断、风险定级、整改建议，一定要由人来兜底。

我个人在实际使用中的体会是，这类工具的理想用法是“把它当新人队友，而不是当自动武器”。它替你干最累的活，但决策和担责的永远是你。最后再分享一个小技巧：每次跑完任务，记得把会话里的关键命令和结果整理到项目文档里。时间一长，你会发现这就是最宝贵的一手知识库，比任何外部资料都贴合你自己的测试习惯。