最近我在整理本地部署的 AI 工具清单时注意到一个叫 pentagi 的开源项目引起了圈内不少讨论。它不是一个普通的命令行小工具而是一套自带 Web 界面的多智能体安全验证框架核心思路是把大模型智能体、任务规划、工具调用和长期记忆整合在一起让安全测试人员可以在一台本地服务器上跑通“输入目标描述 - AI 自动规划 - 自动化执行 - 人工审核结果”的完整链路。我花了两天时间把它部署起来又跑了一个隔离环境下的授权验证场景先说结论pentagi 目前还不能完全替代有经验的安全测试工程师但它的多智能体协作方式和本地优先的设计思路确实解决了不少重复性劳动的问题。这篇文章就围绕 pentagi 是什么、它的核心模块怎么工作、怎么部署、实际用起来是什么体验以及我踩过的坑展开内容偏向实操给想尝试这个项目的朋友一份可以直接参考的笔记。1. PentAGI 到底是什么一次偶然发现的多智能体安全验证框架1.1 从名字和定位说起PentAGI 这个名字其实是 “Penetration Testing AGI” 的组合。不过别被 AGI 这词吓到它实际做的事情很具体用多个大模型智能体来协作完成授权范围内的安全验证任务。你不需要自己写一串串工具命令也不需要盯着终端一条条看输出而是在 Web 界面上用自然语言描述一下目标环境和验证目标框架里的规划智能体就会把大任务拆成小步骤执行智能体再去调用各种开源安全工具和脚本完成具体动作最终把结果整理回界面里供人工查看。我第一次看到这个项目时第一反应是“这不就是给 ChatGPT 装了个工具壳子吗”但仔细看它的架构说明之后发现pentagi 在设计上和其他“单个大模型生成命令”的方案有本质差别。它不是让一个大模型从头到尾做完所有事而是拆成了几个角色不同的智能体每个智能体负责一类工作相互之间还有反馈机制。这个思路我很认可因为真实的安全验证过程本来就应该是分阶段、分角色的。1.2 解决的痛点安全测试里的重复劳动和上下文断裂做过授权安全测试的朋友应该有体会真正花时间的不一定是某个漏洞的利用而是大量前置工作信息收集、端口识别、服务指纹探测、目录枚举、结果归类这些东西每一步都可能要切换工具、记录结果、整理到报告里。传统方式下这些动作往往靠人工一条条执行或者写一套半自动脚本但脚本的通用性有限换个目标环境就要改参数。pentagi 想解决的就是这个痛点。它把“规划”和“执行”分开规划智能体负责根据目标描述生成任务清单执行智能体负责调用具体的工具去跑跑完再把结果回传。整个过程记录在长期记忆模块里下次做类似项目时智能体可以调用历史经验不用每次从零开始。这种设计对个人测试者和小型团队来说能明显减少“CtrlC 复制结果再粘贴到笔记”这类琐碎操作。1.3 本地优先为什么数据不出服务器也很重要pentagi 另一个让我好感度很高的点是它的本地优先设计。整套框架用 Docker 部署在你自己的机器上数据库、文件存储、执行环境都在本地大模型部分虽然默认可以对接云端 API但同样支持配置本地模型服务。对于安全测试这类场景目标环境的信息往往涉及内部资产如果直接丢给一个公共网页对话框合规和隐私都存在隐患。pentagi 把数据留在了本地只把需要推理的文本发给模型接口重要资料不出自己的网络环境这个取舍在实践里非常实用。2. 核心机制与关键模块拆解它到底是怎么“自动”起来的2.1 多智能体分工规划者、执行者与代码执行模块pentagi 的系统里至少能看到几个角色完全不同的智能体模块。规划智能体负责拆解任务它的输入是用户在界面上填写的项目描述输出是一系列有先后顺序的验证步骤。执行智能体则更像一个“操作员”它接收规划智能体给它的单一子任务选择合适的工具、生成具体的命令或脚本然后触发执行。真正有意思的是pentagi 把代码/命令的实际运行放到了一个独立的执行模块里而不是让大模型直接在你的主机上跑命令。这个执行模块运行在 Docker 容器内与主框架隔离。这样做的好处首先是安全大模型生成的命令有时候会出错甚至可能因为推理内容不当导致危险操作放在隔离容器里跑至少不会直接破坏宿主机环境。其次是稳定即使某个脚本把容器里的环境搞乱了重启容器就能恢复不影响数据库和 Web 服务。2.2 长期记忆模块让智能体“记得”上次怎么做的长期记忆Long-Term Memory简称 LTM是 pentagi 比较核心的一个设计。它把每次任务执行过程中的关键信息比如目标环境特征、扫描命令、结果摘要、当时做的决策都写入数据库和向量存储。这样当你新开一个项目哪怕目标主机的 IP 和端口都变了只要任务类型相似规划智能体就能通过检索历史记忆参考之前用过的方法。我实际体验下来的感受是LTM 在“同类任务复用”上的效果非常明显。比如第一次跑一个 Web 应用的授权验证时规划智能体拆出来的任务可能比较粗糙可能会漏掉某些检查项但第二次再新建类似项目它给出的规划明显更有条理甚至会把上次执行过程中纠正过的错误步骤直接避开。这种积累式的进步确实有点接近“越用越顺手”的状态。2.3 Web 界面与任务可视化人工监督的关键入口pentagi 的 Web 界面不是一个简单的配置页而是一个完整的任务控制台。它把每个智能体的思考过程、正在执行的动作、命令输出、工具返回结果都实时展示出来。这里我必须强调一下这个设计在安全场景里非常必要。多智能体自动化并不等于“全自动无人值守”尤其是涉及实际目标环境的操作人工监督是底线。pentagi 的界面允许你在每一步执行前看到计划也可以在中途终止某个任务或者驳回智能体的下一步动作这就把“AI 自动操作”约束在了“人工可控”的范围里。管理员还可以在界面上查看每个会话的输入输出记录相当于给整个过程留了完整的审计日志。对于需要向客户或领导汇报的场景这些记录本身就可以作为执行证据节省了单独整理日志的时间。2.4 模型支持范围云端 API 与本地模型都能配pentagi 在模型对接上做得比较开放。它支持标准的 OpenAI 兼容接口也就是说凡是提供兼容 API 的模型服务都能接入。又想尝试本地模型的话也可以把模型列表指向本地的模型服务地址比如通过 Ollama 或 vLLM 起的本地接口。框架里不同角色可以使用不同模型规划智能体可以用逻辑能力强一些的大参数模型执行智能体对指令遵循能力要求高也可以单独指定一个合适的模型。这种灵活的配置方式让我这种既想省成本又不想牺牲效果的人有了不少调整空间。顺便提一个细节pentagi 的模型配置里包含了多个模型角色每个角色对应不同的 prompt 模板和使用场景。我第一次部署时只看了一个模型地址就以为配好了实际上要把各个角色对应的模型名都填对任务跑起来才不会报错。这一块我会在部署章节里细说。3. 本地部署与模型对接从零到 Web 界面跑通的完整记录3.1 部署前的环境准备部署 pentagi 需要的硬件门槛不算高但也不像普通 Web 应用那么轻量。官方推荐使用 Docker 和 Docker Compose 方式部署所以我先在服务器上准备好了这两个基础组件。内存方面如果你只是做小规模验证16GB 内存基本够用我自己的机器是 32GB 内存跑起来比较从容因为除了 pentagi 本身的容器还要跑数据库和模型接口服务内存大一点可以减少很多 swap 带来的卡顿。磁盘方面建议预留 20GB 以上空间。pentagi 的执行容器里会安装很多工具和依赖加上数据库存储和向量数据项目跑多了之后占用的空间增长得比想象中快。我一开始只给了 10GB跑了几个项目就报警了后来调整到 20GB 才算顺畅。3.2 部署步骤clone 仓库到初始化数据库部署过程大致分几步先克隆代码仓库然后复制环境变量模板修改关键配置项启动容器最后初始化数据库并登录 Web 界面。下面是我实际操作的简化流程每一步后面标注了需要特别注意的地方。克隆代码仓库到服务器本地目录进入项目根目录。复制环境变量模板文件.env.example为.env。编辑.env文件设置数据库连接信息、Web 登录密码、模型 API 地址和密钥。修改模型列表配置为规划、执行、提示生成等不同角色分别指定模型名称。执行docker compose up -d启动全部服务。等待容器初始化完成执行数据库迁移命令创建数据表结构和基础数据。打开浏览器访问 Web 界面地址使用配置的账号登录。这里有一个值得展开的坑数据库迁移命令一定要在数据库容器完全启动后再执行否则会报连接失败。我在第一次部署时因为急着跑迁移连续报了几次数据库连接错误后来检查日志发现是 Postgres 容器还在初始化多等十几秒就好了。3.3 模型配置不同角色用不同模型的实践建议pentagi 的模型列表配置文件里每种角色有对应的模型条目。我建议至少把规划智能体模型的参数调高一些因为任务拆解的质量直接决定后面所有执行步骤的质量。如果规划模型太弱它会给出非常笼统甚至互相矛盾的步骤执行智能体在下面只能干瞪眼。执行智能体的模型则要选择指令遵循能力强的它需要把规划步骤转成实际可跑的命令模型如果理解偏了产出的脚本很容易报错。如果使用 OpenAI 兼容 API需要在.env里填好接口地址和密钥如果用本地模型服务接口地址填本地地址即可密钥可以随便填一个占位符。但我个人不推荐用太小的本地模型来当规划智能体尤其是 7B 级别的模型在长任务拆解上的表现会比较吃力经常出现计划做到一半就逻辑断裂的情况。有条件的话规划角色尽量用 34B 以上或者云端强模型执行角色可以用中等规模的模型平衡成本。3.4 部署后的功能验证跑一个自带的 Demo 任务pentagi 设计了一套验证用的示例任务部署完成后可以在界面上直接创建一个测试项目让智能体跑一个无害的基础验证流程比如对本地回环地址或一个测试容器做端口识别。跑这个 Demo 的主要目的是确认模型调用链路、工具执行链路、数据库写入三个核心环节都正常。我第一次跑 Demo 时Web 界面上显示规划智能体在正常思考但执行智能体的命令一直不返回结果。查了日志才发现是执行容器里某些基础工具没有安装完整需要手动进容器补齐依赖。这里建议大家在验证阶段多观察日志输出而不是只看界面上的状态圆圈很多隐藏问题都会在日志里暴露出来。4. 实际使用流程与授权测试场景跑通一次完整的体验记录4.1 项目创建用自然语言描述验证目标在 Web 界面上新建项目时系统会要求填写项目名称、目标描述和范围限制。目标描述越具体规划智能体给出的任务就越有针对性。我的做法是尽量写清楚目标系统的 IP 或域名、已知的服务类型、验证范围比如只看 Web 层还是包括主机层、以及需要遵守的规则比如不进行拒绝服务测试、不尝试暴力破解等。这里要特别强调pentagi 本身只是一个工具它不会帮你判断目标是否合法。按照安全行业的基本准则所有验证操作只能在你有明确授权的环境中进行。我实际跑通的场景就是在自己隔离网络里起的一台测试虚拟机里面故意部署了带已知漏洞的 Web 应用整个流程完全可控不涉及任何未授权目标。4.2 任务执行从规划到执行再到结果整理的完整链路创建项目后规划智能体开始工作。以我那个测试虚拟机为例它给出了大致这样的步骤顺序先做主机发现和端口扫描然后对开放端口做服务指纹识别接着对识别出的 Web 服务做目录和文件枚举再根据发现的结果尝试检查是否存在已知漏洞最后生成一份总结报告。执行智能体会一步步执行这些规划步骤。每完成一步结果就会回传到规划智能体由它判断是否需要调整后续计划。如果某个步骤没有发现有用信息规划智能体可能会自动补充一个替代检查项如果发现了一个可疑服务它会决定在下一步做更深入的验证。我在界面上看着它一步步推进整体节奏大概相当于一个初级测试工程师在认真操作虽然效率不算飞快但每个步骤都有日志记录出问题的时候能快速定位到具体动作这一点人工操作反而不容易做到。4.3 人工介入在需要判断的地方踩刹车尽管 pentagi 自动化程度已经不低但我仍然建议在任何关键节点保持人工参与。我在跑测试任务时执行智能体在中途识别出一个可能有问题的服务打算运行一个带有破坏性的验证脚本界面上的计划预览里明确提示了这条命令的风险等级。我看到之后果断取消了这一步换了一个更温和的检查方式。这种“AI 提议 人工确认”的模式我觉得才是安全验证工具应该有的样子。它可以把重复、繁琐、确定性的工作交给自动化但把决策和风险判断留在人这一侧。pentagi 的 Web 界面在设计上给了这种人工干预的入口而不是让智能体一条路走到黑这点很关键。4.4 结果输出任务记录与报告沉淀任务全部执行完后pentagi 会把整个过程的执行记录、关键发现、命令列表和结果摘要汇总起来。我在实际使用中感受到这些记录本身就是一份不错的初步报告素材省去了手动整理屏幕输出和命令日志的大量时间。另外这些记录也会写入 LTM成为后续项目的“前车之鉴”。就是说我下次在类似目标上做验证时系统会记得这个环境里哪些服务已经探测过、哪些检查项没有发现异常避免重复劳动。这个能力在资产多、任务繁重的场景下价值会更明显。5. 踩坑记录与经验总结那些文档里不会细说的事5.1 问题一模型选错后面全部白费我一开始图省事给所有智能体角色都配了同一个中等规模的本地模型结果跑第一个验证任务时规划智能体给出的步骤就明显偏简单甚至漏掉了对 Web 目录的检查。执行智能体那边也因为模型指令遵循能力不足频繁出现命令拼写错误。后来我把规划模型换成了一个更强的模型执行模型保留中等规模整个任务质量立刻上了一个台阶。这给我的教训是不要为了省一点 API 费用或者内存占用在所有角色上都用最弱的模型尤其是规划这个环节模型能力不足会导致后续所有步骤连锁出错。5.2 问题二执行容器工具缺失任务卡在半路pentagi 的执行模块在 Docker 容器里但这个容器并不会预装所有安全测试工具。有些工具需要在任务执行过程中由智能体临时安装网络不好或者软件源有问题时安装过程会非常慢甚至失败。遇到这种情况我建议提前把常用工具手动装进执行容器或者把工具镜像构建为自定义镜像这样每次重启容器后工具还在不用反复安装。另一个办法是尽量让执行智能体使用容器里已有工具的能力减少临时下载依赖的次数但这就需要在 prompt 或者规划层做一些约束了。5.3 问题三数据库没有挂载持久化卷重启后数据全丢我在早期调试阶段为了方便没有仔细检查 docker-compose 里的卷挂载配置。有一次服务器重启之后发现 Web 界面上所有项目记录和任务日志都消失了心里确实凉了一下。后来检查才发现数据库容器没有挂载持久化卷容器一重建数据就跟着没了。解决方法是把 Postgres 的数据目录和 pentagi 的文件存储目录都挂载到宿主机目录并且定期做数据备份。如果你打算长期用 pentagi 来积累项目历史这个配置一定要在一开始就确认好不要像我一样用一次重启换一次教训。5.4 经验总结自动化工具的价值边界在哪里跑了几个项目之后我对 pentagi 这类多智能体安全验证工具的定位有了更清晰的认识。它最适合的场景是那些范围清晰、步骤可重复、结果可记录的验证工作比如常规资产检查、端口暴露面梳理、基线合规验证。在这些场景里它能把几个小时的重复人工操作压缩到几十分钟而且记录更完整。但如果你面对的是一个完全陌生的、逻辑复杂的目标环境需要高度创造性和经验判断的地方pentagi 目前还帮不上太大忙。它更像一个执行力和记忆力很强的助手而不是一个有独立判断力的专家。安全测试行业中真正稀缺的仍然是能够制定策略、理解业务风险、做出复杂决策的人类专家。工具负责把专家的意图更快落地这就是当前阶段我认为最合理的分工方式。