为什么 AI 漏洞挖掘项目普遍选择 LLM 自主探索？从 HexStrike、Strix 到 ARTEX、XBOW 的架构思考
近两年，AI 自动化渗透测试领域出现了大量开源项目。
从 PentestGPT、CAI、HexStrike AI，到 Strix、Shannon、PentAGI，再到 ARTEX，以及商业化的 XBOW，越来越多系统开始尝试让大语言模型（LLM）自主完成漏洞研究。
它们的基本工作方式看起来很相似：
给 AI 一个目标，提供浏览器、终端、HTTP 客户端、扫描器等工具，让模型自行判断下一步做什么。它可以分析网站、提出漏洞假设、执行测试，再根据结果调整策略。
这与传统漏洞扫描器有明显区别。传统扫描器主要回答“这个目标是否符合某个已知漏洞特征”，而 AI Agent 希望回答的是“面对这个陌生系统，我应该研究什么”。
但研究这些项目时，一个问题值得思考：
难道是因为后者太复杂？还是因为让模型自主探索确实更有效？
进一步的问题是：如果研究方向由 LLM 自己决定，那么当它从一开始就没有意识到某个安全问题时，系统又该怎么办？
这篇文章尝试从公开项目架构、研究论文和第一性原则三个角度分析这个问题。
一、先看看这些项目究竟在做什么
在讨论架构优劣之前，需要纠正一个容易产生的误解：
实际情况远比这个复杂。
1. HexStrike AI：优先解决 AI 能使用什么工具
HexStrike AI 是工具集成路线的典型代表。
它通过 MCP 等接口，将大量成熟的网络安全工具提供给 AI Agent，覆盖信息收集、资产扫描、Web 漏洞检测、漏洞利用及其他安全任务。
这种设计很容易理解。
假设模型发现一个疑似 SQL 注入点，它没必要重新编写完整的注入检测器，可以调用 sqlmap。
发现了某个服务，也不必自己实现端口探测协议，可以调用 Nmap。
LLM 负责判断使用什么工具、提供什么参数、怎样理解输出；工具负责执行具体工作。
这条路线最大的好处是快速获得广泛的执行能力。
但需要注意，工具数量和漏洞发现能力不是一回事。
拥有 150 种工具，不代表系统知道应该什么时候使用它们，更不代表能够发现 150 种工具都没有明确覆盖的未知业务逻辑漏洞。
工具解决的是“能不能执行”，而不是全部的“为什么值得执行”。
2. Strix、CAI：把渗透测试变成多个 Agent 的协作
Strix 采用了更明显的多 Agent 设计。
其公开的 Root Agent 协调机制会将侦察、漏洞分析、利用验证和报告等工作交给专门的子 Agent。不同 Agent 可以围绕独立任务工作，再共享重要发现。
CAI 则更像一个面向网络安全研究的通用 Agent 框架，强调工具调用、Agent 角色、任务交接和不同执行模式。（截至本文撰写时，CAI 原仓库已归档。）
这种路线的出发点并不复杂。
一个人同时负责资产发现、代码审计、权限研究、漏洞利用和报告整理，很容易失去重点。
LLM 也一样。
所以，系统将不同工作交给不同 Agent，希望通过专业分工降低单个模型的上下文负担，并提高并行探索能力。
问题在于：
如果所有 Agent 都没有意识到某个字段代表潜在的跨租户授权关系，那么增加协作角色，也不一定能发现这个问题。
3. Shannon：让源码指导漏洞研究
Shannon 走的是另一条有代表性的路线。
它不仅依赖运行时的 HTTP 响应，也利用应用源码发现潜在攻击路径，然后通过浏览器和命令行工具进行真实利用验证。
这种做法有明确优势：
当系统能够直接看到代码时，很多原本需要从外部猜测的逻辑，就有机会通过数据流、调用关系和权限判断进行分析。
但它也有适用条件。
源码审计和黑盒赏金研究并不是同一种问题。面对没有源码的陌生网站，研究者仍然需要通过有限的外部行为逐步推断系统的内部逻辑。
Shannon 因此展示了另一个方向：不是无限增加 Agent 自由度，而是提供更强的目标信息，让模型提出更有根据的攻击假设。
4. PentAGI：Agent 也可以拥有长期记忆和知识图谱
PentAGI 说明，“LLM 主导”与“结构化知识”并不矛盾。
根据其 2026 年 10 月公开文档，PentAGI 使用 PostgreSQL 和 pgvector 保存执行历史与语义记忆，还支持可选的 Graphiti/Neo4j 知识图谱。
它把长期记忆、工作记忆和执行历史区分开来，使 Agent 可以检索此前的研究结果，而不必每次从零开始。
这意味着，部分开源项目已经意识到一个问题：
如果模型每执行一次任务都忘记之前做了什么，那么长期研究必然产生大量重复工作。
不过，保存历史依然不能直接解决研究决策问题。
系统可以准确记住“这个接口返回了 403”，却不一定知道这个 403 背后隐藏了什么重要的权限规则。
5. ARTEX：结构化资产图与自主探索并存
ARTEX 是非常值得研究的一个案例。
它并非简单的工具编排项目。
从公开保留版本来看，ARTEX 采用了两张相互关联的图：
资产图（Asset Graph） 保存域名、IP、服务、应用、接口等资产及其关系。
探索图（Exploration Graph） 保存研究目标、意图、事实、发现，以及这些内容之间的关联。
两张图的职责不同。
资产图回答：“系统有哪些东西，它们之间有什么关系？”
探索图回答：“围绕这些东西，我们研究了什么，发现了什么，还有哪些方向？”
执行流程也有明确分工。
Planner 根据探索状态提出新的研究意图，Worker 使用真实工具执行，再把观察结果写回图中。图发生变化后，Planner 可以重新判断下一步。
ARTEX 还实现了跨 Worker 执行记录检索和跨轮次待办，用于降低信息丢失及多步骤攻击链中断的问题。
因此，认为 ARTEX 完全不依赖结构化建模是不准确的。
只是，资产图和探索图并不自动替代 LLM 的语义判断。
即使图里记录了一个新的业务字段，也仍然需要研究者意识到，这个字段可能意味着一种此前没有考虑过的权限边界。
需要说明的是，ARTEX 原作者已于 2026 年 10 月 8 日宣布停止开源版本维护，本文讨论的是公开留存版本的架构。
6. XBOW：商业系统为什么仍然高度依赖 Agent？
XBOW 是这一领域更具有实际参考意义的商业案例。
它并不是开源项目，因此我们无法像检查 ARTEX 那样审计完整源码。
但 XBOW 官方已经公开了相当明确的技术思路。
它并不让一个大型 Agent 从开始一直运行到结束。
相反，它采用短生命周期 Agent、全局协调机制以及独立的漏洞验证机制。
简单理解：
局部 Agent 专注于具体研究任务，全局协调器负责维护攻击面的整体视图，减少重复探索，并根据结果决定接下来需要研究的方向。
XBOW 在 2026 年 4 月的技术文章中明确承认，单个长期运行的 Agent 容易积累错误假设、误解响应，并最终偏离有效方向。
它还指出，如果没有协调机制，成千上万个 Agent 可能反复测试相同的攻击面。
所以 XBOW 并不是完全依赖 LLM。
它实际上把模型不擅长的全局协调、部分状态管理和结果验证交给了外部机制。
但即使如此，它仍然让 LLM 承担大量具体攻击策略和新研究方向的生成工作。
二、为什么 LLM 主导探索会成为如此普遍的选择？
比较这些项目之后，我认为原因主要有五个。
原因一：未知漏洞不是一个能够完整枚举的检测规则集合
这是最根本的技术原因。
传统漏洞扫描器依赖已知的检测逻辑。
例如，SQL 注入可以通过构造不同输入，观察响应差异；某些权限问题可以通过身份切换和资源归属差分进行验证。
这些都是能够部分形式化的问题。
但是，真实业务系统中还存在大量没有标准检测模板的问题。
例如：
- 订单转让后，原用户是否仍然具有退款权限？
- 审批流程结束后，是否还能通过另一个接口修改审批内容？
- 一个只用于展示的字段，是否意外参与了服务器的授权判断？
- 两个单独看起来正常的业务接口，组合起来是否突破了原有安全限制？
这些问题的困难不一定在于 HTTP 请求怎么发送。
更困难的是：研究者需要先意识到，这里可能存在一种值得验证的安全约束。
LLM 在理解自然语言、业务语义、代码片段和复杂上下文方面具有优势，可以从不同信息中产生新的解释。
相比要求开发者提前写出所有可能的业务安全规则，让模型自主提出研究问题，是一条很自然的技术路线。
当然，LLM 能够提出假设，不代表假设一定正确。
原因二：工具已经成熟，重新实现没有太多价值
网络安全行业积累了大量成熟工具。
对于一个新项目，直接集成现成工具，再让 LLM 组织调用，通常比重新开发扫描、解析和利用能力更快。
这不仅缩短开发周期，也降低了维护负担。
而且模型升级之后，某些研究和工具使用能力可能直接提升，无须重新编写大量检测规则。
这是一项真实的工程优势，不应该被简单理解为“开发者为了省事”。
但是，快速整合工具的优势也有边界。
当瓶颈从工具执行转向业务语义理解、长期规划和实验选择时，继续增加工具未必带来同等收益。
原因三：自主 Agent 更容易进行端到端评估
很多公开研究使用 CTF、VulnHub、HackTheBox、XBOW Benchmark 或其他可复现靶场。
这类评估通常有相对明确的目标和成功条件。
例如：
是否获得 Flag？是否完成指定攻击链？是否成功证明某个漏洞？
给 Agent 目标和工具，然后衡量任务成功率，是一种清晰、可复现的研究方法。
相比之下，长期漏洞研究系统要评估的事情复杂得多：
它是否正确理解了业务关系？是否降低重复测试？是否合理排除错误假设？是否遗漏未知的高价值攻击面？是否增加实际可提交漏洞？
这些问题不仅需要更长的实验周期，有些还缺少容易自动评分的标准答案。
因此，公开 Benchmark 的结构，可能间接鼓励开发者优先优化端到端 Agent 的攻击完成能力。
这是一种评估环境对技术路线的影响，而不是对开发者动机的判断。
原因四：结构化建模有成本，而且不保证收益
假设研究者发现了 1,000 个 API。
一种方法是将这些接口逐步交给 LLM，允许模型选择有价值的方向。
另一种方法则是先整理：
接口属于什么功能、涉及什么身份、操作什么资源、处于什么业务状态、与其他接口有什么关系、已经做过哪些测试。
后一种方法能够提供更完整的研究上下文，但需要额外成本。
例如，判断两个接口是否操作同一个业务资源，本身可能就需要新的实验。
更麻烦的是，系统可能把推测记录成事实。
一旦错误判断被持久保存，后续研究者就可能不断受到它的影响。
所以，结构化建模不应该以“收集尽可能多的信息”为目标。
它必须证明，保存和组织这些信息，确实改变了后续研究行为，并带来了足以覆盖成本的收益。
原因五：自由探索对陌生目标具有更好的适应空间
假设一个系统只支持预定义的身份、资源和状态模型。
当目标使用一种完全不同的业务机制时，系统可能无法准确表达这种机制，更无法制定相关实验。
LLM 自主探索则具有一定优势。
它可以根据新观察修改理解，提出此前没有预先编码的研究问题。
这对于未知漏洞尤其重要。
因此，不能因为确定性程序更加稳定，就直接把全部研究决策变成固定规则。
这正是前沿系统普遍保留 LLM 自主探索能力的根本理由之一。
三、不过，研究正在表明：更自由不一定更有效
如果只看架构介绍，很容易得出一个过于简单的结论：
LLM 越自由，越容易发现未知漏洞；结构化规则越多，越容易限制创造力。
事实并没有这么简单。
2026 年的一些研究已经给出了值得对照的实验结果。
1. AWE：专用检测流程可以更便宜、更有效
AWE: Adaptive Agents for Dynamic Web Penetration Testing 尝试把结构化的漏洞测试流程嵌入较轻量的 LLM 编排系统。
在论文报告的 104 项 XBOW Benchmark 测试中，AWE 对 XSS 和盲注等特定漏洞类型取得了不错的结果，同时降低了部分计算和 Token 成本。
但是，对比项目 MAPTA 在更广泛的探索覆盖方面具有优势。
这说明两种能力之间存在现实取舍：
2. Intentest：结构化事实和意图可以改善长链执行
2026 年 9 月的 Staying on the Attack Path 提出 Intentest。
它使用事实与研究意图构成的有向无环图，保存已经验证的状态，以及后续研究方向与前置事实的依赖。
在论文使用的 CTF 基准中，Intentest 报告了 88.2% 的总体成功率，以及 75.0% 的困难任务成功率。
这支持一种判断：
如果结构化状态不只是存储信息，而是直接影响后续任务安排，那么它可能显著改善长时间、多步骤的自动化研究。
但这些结果来自特定基准，不能直接等同于真实生产环境的未知漏洞发现率。
3. 另一项研究发现：增加记忆并没有改善结果
更有意思的是，2026 年 9 月的 Big Enough to Break Out 却得到了不同的结果。
研究者为两种 PentestGPT 架构增加了覆盖记忆机制，希望减少上下文丢失和重复探索。
但在该研究所使用的少量测试目标中，增加记忆没有改善任务结果。
进一步检查发现，一些失败并不是系统忘记了此前的信息，而是模型没有根据已经掌握的信息推进正确的攻击路径。
换句话说：
这项研究样本有限，也不能说明长期记忆没有价值。但它说明，增加数据库、上下文和知识图谱，并不会自动提高漏洞发现率。
4. Excalibur：重要的不只是下一步能做什么，而是值不值得做
2026 年 2 月的 What Makes a Good LLM Agent for Real-world Penetration Testing? 分析了 28 个 LLM 渗透测试系统，并深入比较其中五个代表性实现。
研究将部分失败归因于工具能力不足，另一部分则归因于规划和状态管理。
其中一个关键问题是：Agent 缺少对当前任务难度和可完成性的合理估计。
它可能在某个低价值方向上持续消耗资源，也可能始终进行侦察和枚举，却迟迟不推进真正有价值的实验。
因此，研究提出了难度感知的规划机制，根据证据、任务难度、上下文负担和历史结果调整研究策略。
这提示我们：
综合这些实验，至少可以得出一个谨慎结论：
LLM 自由探索和结构化研究状态都有价值，但任何一方都不能被视为解决全部问题的充分条件。
四、进一步追问：AI 为什么会漏掉从未想到的漏洞？
现在可以回到最初的问题。
假设我们已经拥有：
- 足够强大的 LLM；
- 大量安全测试工具；
- 多个可以并行工作的 Agent；
- 持久化数据库与知识图谱；
- 完整的实验历史；
- 独立的漏洞验证器。
为什么系统依然可能漏掉未知漏洞？
因为这些能力并没有直接消除漏洞研究最根本的困难：
一个简单例子
假设某个订单接口返回：
{
"order_id": 123,
"owner": 1001,
"delegated_owner": 1002,
"status": "paid"
}
看到这段数据，AI 可能得出一个很普通的结论：
这是一个订单对象，其中包含订单所有者和被委托人。
这个理解没有明显错误。
但假设实际业务中存在两种可能。
delegated_owner 是合法的订单协作权限。用户 1002 可以在特定条件下访问订单。
delegated_owner 只是内部任务分配字段，不应该改变订单访问、转让或退款权限。
两种系统完全可能返回相同的 JSON。
仅凭这一段响应，研究者无法确定究竟是哪一种规则。
但是，如果 AI 没有意识到这里可能存在不同的安全含义，它可能根本不会提出后续问题。
例如：
这个委托关系是否有有效期？是否影响退款权限？订单转让后，原用户还有没有访问能力？
于是，一个潜在的业务逻辑漏洞，就可能在完全正常的 HTTP 响应中被忽略。
没有明显报错，没有异常状态码，也没有典型漏洞特征。
五、从第一性原则看，这个问题为什么不可彻底消除？
在数学上，可以把一个系统的真实内部状态或安全规则记作 (H)，把研究者已经获得的观察记作 (D)。
假设存在两种不同的解释 (H_1) 和 (H_2)。
如果它们在当前观察条件下产生完全相同的数据分布：
[
P(D\mid H_1)=P(D\mid H_2)
]
那么仅凭这些观察，我们就无法从证据上区分两种解释。
这叫做不可辨识性（Non-identifiability）。
通俗地说：
你看到的现象，可能由不同的内部机制产生。
在没有更多信息之前，即使让一个非常聪明的模型反复分析，它也无法确定哪种解释是真实的。
模型可以猜测，可以提出假设，但不能把猜测当作证据。
所以，未知漏洞研究至少包含三个不同的问题。
研究者根本没有发现某个关键接口、业务状态或身份关系。
相关信息已经出现，但研究者没有意识到它可能对应某种安全边界。
研究者已经提出有价值的假设，却把有限时间和请求浪费在其他方向。
它们表面上都表现为“没有发现漏洞”，但原因完全不同。
第一种需要获得新信息。
第二种需要改进解释与问题生成。
第三种需要改进实验选择和预算决策。
如果系统不区分这些情况，就很难真正改善研究效果。
六、增加 Agent 数量能否避免遗漏？
XBOW 使用大量短生命周期 Agent，一个重要原因就是避免单个 Agent 的局部判断长期控制整个研究过程。
这种方法确实具有合理性。
假设单个 Agent 发现某种漏洞线索的概率为 (p)。
如果多个 Agent 的发现事件完全独立，那么使用 (n) 个 Agent，至少有一个发现该线索的概率为：
[
P(\text{至少发现一次})=1-(1-p)^n
]
例如，假设单个 Agent 的发现概率为 20%。
| Agent 数量 | 至少一个发现的理论概率 |
|---|---|
| 1 | 20.0% |
| 2 | 36.0% |
| 4 | 59.0% |
| 8 | 83.2% |
这里的数字只是独立性假设下的数学演示，不是 XBOW 或其他项目的实际测量结果。
现实中，这个独立性条件往往无法满足。
不同 Agent 可能使用相同模型、相似提示词和相同观测信息。
它们可能全部把某个关键字段解释为普通业务数据。
如果某种探索策略对特定问题的发现概率实际上是零，那么按照同样的策略运行更多 Agent，也不会改变结果。
当然，不同模型、研究视角和探索方法可能降低共同盲点。
但多 Agent 的价值来自探索差异，而不只是数量。
七、那么应该如何降低未知漏洞遗漏？
根据前面的分析，我认为真正值得关注的不是某一种数据库、图结构或者 Agent 框架，而是以下几个研究机制。
1. 不要只记录“做过什么”，还要知道“什么仍然未知”
很多系统会保存接口列表和测试记录。
例如：
GET /api/orders/123 已经测试过。
但“测试过”究竟代表什么？
它可能只是匿名访问过一次，也可能只是完成了一个 SQL 注入检测。
这并不意味着该接口的身份权限、对象归属、状态变化和跨接口关系都已经得到验证。
因此，研究覆盖应当与具体条件绑定。
例如：
哪个身份、哪个资源、什么状态、验证了什么约束、得到了什么证据？
这不是要求穷举所有组合，因为那通常不现实。
而是避免把局部测试结果错误地扩展为整体安全结论。
2. 从正常行为中主动寻找值得解释的安全关系
传统检测通常重视异常响应。
但未知业务逻辑漏洞的线索未必异常。
一次正常订单转让、一次审批通过、一次角色切换，都可能揭示新的安全边界。
因此，研究系统不能只根据明显错误生成假设。
它还需要观察正常业务流程中的身份、资源、状态和数据流关系，并尝试提出问题：
为什么允许这种操作？什么条件下不应该允许？是否存在另一个接口可以绕过这个限制？
关键是提出可验证的问题，而不是把所有正常行为都臆测成漏洞。
3. 对重要观察形成竞争性解释
当系统发现一个新的业务机制时，不应该立即接受模型给出的第一种解释。
例如，看到 delegated_owner，可以同时保留两个假设：
- 它实际赋予了某种资源操作权限。
- 它只是一个展示或内部管理字段。
随后选择能够区分这两种解释的实验。
如果实验结果支持第二种解释，就不应继续围绕第一种解释无意义地重复测试。
这种方式可以降低模型过早形成固定判断的风险。
4. 优先执行能够改变判断的实验
研究预算有限，不可能测试所有组合。
因此，实验价值不应只用“成功触发漏洞的可能性”衡量。
一次实验即使没有发现漏洞，也可能证明此前的解释错误，或者发现一种尚不了解的业务关系。
可以用一个简化的决策模型表示：
[
V(e)=P(v\mid e)\cdot I(v)+\lambda G(e)-C(e)
]
其中：
- (P(v\mid e))：执行实验 (e) 后发现有效漏洞的估计概率。
- (I(v))：相关漏洞可能产生的安全影响。
- (G(e))：实验预计能够减少多少重要未知。
- (C(e))：请求、时间和模型等成本。
- (\lambda)：信息增益在当前研究阶段的权重。
这个公式只是用于说明选择原则，并不是可以直接套用的精确收益计算器。
真实系统中的概率和信息价值很难准确估计。
但它表达了一个重要思想：
5. 让结构化知识辅助研究，而不是替代未知假设生成
知识图谱、关系索引和历史事实可以帮助研究者找到此前遗漏的关联。
例如，某个新接口使用了与旧接口相同的资源对象，那么此前已经确认的权限关系可能成为新的研究线索。
但应该明确区分两件事：
“两个接口存在关联”是可以通过证据支持的事实。
“因此这里存在权限绕过”只是一个尚未验证的假设。
确定性程序适合完成关系计算、去重、状态比较、预算约束和证据校验。
LLM 则适合解释业务意义、提出新问题和设计区分性实验。
两者并不是互斥方案。
6. 不要把“没有想到问题”当成“没有安全问题”
这是最容易被忽略的一点。
当模型没有产生新的漏洞假设时，实际可能存在三种情况：
研究已经覆盖了当前可观察范围内的重要问题。
研究还缺少关键身份、资源或业务流程信息。
研究者虽然拥有相关信息，却没有意识到其中的安全意义。
这三种情况不能用相同的结论表达。
尤其不能因为一个 Agent 没有提出新问题，就宣布某个应用不存在其他安全风险。
更合理的做法是记录当前研究边界，在出现新的接口、业务状态、身份关系或其他有价值证据时重新评估。
八、未来的方向是更多 Agent，还是更强的研究系统？
我认为这是一个需要实验回答的问题，而不是单纯的架构信仰。
可以设想三种系统：
直接让模型探索目标，使用现成工具完成实验。
在相同工具基础上，增加可信事实、测试历史、覆盖条件和关系检索。
在方案 B 基础上，利用真实证据、成本、覆盖缺口和不确定性，动态决定继续、转向或停止。
究竟哪一种更好？
如果目标只是一个非常简单的靶场，方案 A 完全可能最便宜、最快。
如果目标涉及长期运行、多身份、多资源及大量重复接口，方案 B 和 C 可能具有优势。
但也可能出现另一种情况：
复杂的建模系统消耗了大量成本，却没有提高真实漏洞发现率。
因此，应该把三种方案放在相同模型、相同工具、相同授权目标和相同预算下比较。
评价指标也不应只有发现漏洞的数量，还应包括真实有效漏洞、重复率、误报率、实验成本、探索深度和发现时间。
尤其要观察：
当一个初始 Agent 没有想到某个研究问题时，其他机制究竟能不能帮助系统发现它？
这比单纯统计工具调用次数、Token 消耗或者完成了多少扫描任务更能反映自主研究能力。
九、结语：漏洞研究真正的瓶颈是什么？
回到文章最初的问题：
现在答案应该比较清楚了。
首先，工具集成速度快，可以充分利用成熟安全工具。
其次，LLM 对陌生目标具有较强的语义适应能力，能够提出预定义检测器没有覆盖的研究问题。
再者，端到端 Agent 更容易通过靶场和 Benchmark 进行评估，开发者也更容易衡量进展。
更重要的是，真实业务安全约束无法被一个有限的通用规则库完整描述。未知漏洞研究必须保留提出新解释、新假设和新实验的能力。
但是，随着任务越来越复杂，单纯依靠自由探索也会暴露问题。
Agent 可能遗忘信息，可能重复测试，也可能已经掌握关键证据，却始终没有选择正确的研究方向。
因此，我们看到不同项目逐步采用外部记忆、结构化状态、全局协调、专业分工和独立验证。
这不是两条完全对立的技术路线，而是不同系统在探索灵活性和工程可靠性之间寻找平衡。
最终，还有一个比架构选择更基础的问题：
这句话并不意味着未知漏洞无法被发现。
它意味着研究系统必须持续创造新的观察机会，保留合理的不确定性，允许竞争性解释，并通过真实实验修正已有判断。
没有任何一个 LLM、知识图谱或者多 Agent 系统，能够保证找出开放环境里的全部未知漏洞。
我们真正能够优化的，是在有限预算下，尽可能减少重要的认知盲区，提高新问题被提出、被验证并最终转化为真实安全发现的机会。
漏洞研究的下一次突破，未必来自更大的工具库或更多的 Agent。
它也可能来自一个更基础的进步：
参考资料
以下资料以项目官方文档、公开源码和原始研究论文为主。项目能力以相应公开版本为准；商业厂商披露与学术基准结果不等于独立的真实赏金效果证明。
- HexStrike AI — GitHub
- Strix — GitHub
- CAI: Cybersecurity AI — GitHub
- Shannon — GitHub
- PentAGI — Architecture；Memory and Knowledge
- ARTEX — 公开源码及架构备份
- XBOW — AI for Pentesting: Strengths, Weaknesses, and Where XBOW Fills the Gaps，2026-04-08
- XBOW — How XBOW Ranked #1 in Autonomous Penetration Testing，2025 年
- PentestGPT: An LLM-empowered Automatic Penetration Testing Tool，2023 / USENIX Security 2024
- What Makes a Good LLM Agent for Real-world Penetration Testing?，2026-02-19
- AWE: Adaptive Agents for Dynamic Web Penetration Testing，2026-03-01
- Staying on the Attack Path: Structured State for Long-Horizon Automated Penetration Testing，2026-09-07
- Big Enough to Break Out: Tracking the Rising Capability of LLM Penetration-Testing Agents，2026-09-09