自主渗透测试 Agent 架构对比：Strix、pentagi 与 PentestGPT

自主渗透测试 Agent 需要完成的远不止“调用一个扫描器”。它要拆分任务、操作真实工具、记住长任务状态、处理失败，并为最终结论提供可以复核的证据。模型的决策能力只是其中一部分，运行器和权限边界决定了系统是否能被可靠运维。

本文依据 Qsec 在 2026 年 9 月的研究，比较 Strix、pentagi 与 PentestGPT 的三种路线。架构描述属于原文所研究版本的快照，不是对各项目当前版本的完整审计，也不包含本站实测的发现率或安全排名。

先看五个共同设计问题

从这个角度看，三者的差异不是“用了多少个 Agent”，而是将自由规划、组织治理和确定性校验放在什么位置。

Strix：Agent 图与运行器约束

目标输入与执行域

原文将 Strix 归纳为 CLI、看板与 CI 集成的工具形态。输入可以是代码目录、仓库或 Web 目标，再由 root agent 拆分为侦察、验证和报告等子任务。

编排域负责维护 Agent 状态、消息和预算，执行域承载真实工具操作。原文研究版本使用基于 Kali 的容器沙箱，并通过代理观察工具流量。输出包括发现、验证材料、报告及适合流水线使用的结构化结果。

这一分层把“决定做什么”和“实际产生副作用”放在不同组件中。容器和代理提供隔离与审计能力，但效果仍取决于挂载、网络权限、凭证注入和工具实现，不能仅凭“在 Docker 里”判断范围外操作不可能发生。

两层约束各自解决什么

提示词层规定 root agent 主要做编排，子 agent 执行具体任务，并通过消息协调。运行器层管理生命周期、停滞检测、子任务重建和预算收尾。

两层约束的强度不同。提示词描述期望行为；运行器可以用代码判断某个任务是否结束、是否超出调用预算，以及失败后是否允许重试。授权范围如果只存在于系统提示中，则仍需额外的执行时校验，才能形成更可靠的边界。

原文把会话压缩、工具调用推进和分级预算对应到三个长任务问题：历史过长、空转不前和成本失控。其流程可以概括为：

输入目标与范围
    → root agent 拆分任务
    → 子 agent 在沙箱中调用工具
    → 收集并复核发现
    → 汇总报告

异常回路：停滞干预、子任务重建、预算耗尽后收尾

工程收益与代价

Strix 路线强调减少从输入目标到交付结果的操作步骤。复现材料与实际工具记录能降低部分误报，但“PoC 执行过”仍不自动保证归因正确或业务影响判断准确。

代价主要来自沙箱镜像、代理与编排框架的运行成本，以及对底层 SDK 行为的依赖。团队需要检查恢复机制是否会重复执行有副作用的动作，并明确验证阶段允许到什么程度。

pentagi：消息链与角色治理

平台形态

pentagi 更接近可自托管的持续测试平台。原文描述的组件包括 Go 后端、React 前端、PostgreSQL，以及任务链、日志、追踪和模型调用观测能力。

任务从 Web 界面进入消息链引擎，执行器按角色推进。记忆和情报层为后续步骤提供检索，报告与观测层把过程呈现给团队。原文提到生产部署的主控与 Worker 隔离建议，其价值在于把管理面与执行面分开。

角色矩阵与模型分工

执行者、编码者、安装者等角色处理操作任务；规划、搜索、记忆、报告和反思等角色提供辅助。不同角色可以配置不同模型、温度和成本参数。

这种设计允许把较强推理模型留给规划，把低延迟模型用于规则较清楚的步骤，但成本是否更低，要看任务长度、失败重试和角色间传递的上下文，不能只比较单次调用价格。

原文研究版本还包含工具配额、重复行为检测以及接近迭代上限时的收尾提示。它们限制单个任务无限循环，并给模型保留生成报告的机会。

图谱记忆与任务流转

原文将状态存储归纳为时态知识图谱：工具结果和事实进入外置记忆，供跨阶段、跨任务检索。典型流程是：

创建任务和消息链
    → 规划者拆分步骤
    → 执行器处理子任务
    → 工具观察写入记忆与日志
    → 反思与监控纠偏
    → 报告汇总

状态外置可以减少对模型上下文的依赖，但写入的“事实”仍需要来源、时间和可信度标记。如果把目标页面的未经核验陈述写成高可信记忆，错误和提示注入也可能跨任务传播。

工程收益与代价

平台路线适合多人协作、长周期留痕和统一观察多个测试任务。代价是组件更多、部署调参更复杂，多角色串行调用也可能增加等待和费用。

站内的 CyberStrikeAI 平台与审批机制分析可以作为补充阅读：除了任务如何推进，还需要明确哪些步骤由执行器允许、哪些必须获得人工确认。

PentestGPT：从任务树到受约束计划

论文版本的人机协作

PentestGPT 最初是 USENIX Security 2024 论文项目。原文将早期架构概括为三类会话：推理会话选择下一步，生成会话把决策转成命令，解析会话把工具输出整理成结构化信息；渗透任务树保存全局状态，人类在过程中介入。

这种形态把部分判断留在人机对话里，方便研究和监督，但也带来交互成本与状态一致性问题。任务树本身不能保证每个节点都来自真实证据。

自主模式的三个约束层

原文研究的后续 agent 模式把更多约束移到代码中：

计划语言。 监督者的决策需符合结构化格式，目标来自授权范围，某些任务需要引用已有观察。编译和校验环节可以拒绝格式不合法或缺少前提的计划。

任务租约。 执行者获得当前任务的有限授权，任务种类、目标和阶段都应清楚。发现、测试、验证等阶段的职责可以分别限制，避免一次任务隐式扩大为任意操作。

证据接地。 结论需要定位到真实工具记录中的内容，并配合独立审计检查。这样能够发现一部分“报告说完成，但工具没有做”的不一致。

逐字匹配仍有局限：存在于输出中的字符串不一定真实，也不一定支持报告中的因果结论。目标服务可能返回伪造文本，工具本身也可能失败。因此，证据定位是必要的审计条件，不能独立代替语义和业务影响复核。

工程收益与代价

这一思路适合研究 Agent 权限与证据机制：把自由文本决策转成可检查的结构，使规划、执行和结论之间有更明确的契约。

代价是约束体系更复杂，任务串行推进可能影响速度，对模型稳定输出结构化指令也有要求。其隔离能力还依赖接入的外部 Agent 后端，不能把计划校验等同于完整沙箱。

三种编排思路对照

这些区别是原文的分析框架，不是功能互斥清单。一个项目也可能同时拥有预算、角色、代理和结构化计划；具体选型应回到准备部署的版本及实际配置。

共同工程原则与未解决问题

三个项目都把工具层、执行隔离、外置状态和验证记录视为核心组件。这反映出自主 Agent 的可靠性需要系统工程支持，无法只依赖一次更长的提示词。

仍有几类问题需要实测。首先是证据完整性：引用过的结论可以核验，未引用的推断仍可能出错。其次是目标内容中的提示注入：页面既是测试对象，又可能试图指挥测试工具。再者是授权执行：文本范围声明是否由网络层和工具层共同强制，需要逐项确认。

此外，原文没有给出统一的第三方基准，不能据此比较发现率、误报率或“攻破能力”。同一任务的成功率也受到模型、工具权限、超时和重试策略影响。

对 Agent 生态的整体背景，可继续阅读 AI 安全项目与工具分工，再把具体项目放回自身工作流中评估。

下一阶段需要度量什么

原文提出的未来方向仍有参考价值：统一证据格式和外部评测，把授权范围落实到执行时校验，记录模型与工具成本，并与漏洞管理、工单及复扫流程衔接。

选择工具时，可用同一组已授权的测试目标比较四项结果：发现是否可复现、报告是否有原始依据、动作是否遵守范围、总时间与费用是否可接受。执行效率、组织治理和证据强度应一起评估。

研发团队可能更看重快速接入代码和 CI；长期运营的安全团队可能更看重任务管理、观测与审批；研究团队则可能优先研究计划约束和证据机制。最终选择取决于验证后的需求匹配，不能仅依据仓库热度。

参考仓库：Strix、pentagi、PentestGPT。