基础设施如何改变自动化渗透：Agent 的能力边界不只由模型决定

最近一年以来，AI 自动化渗透领域有一个很明显的趋势：大家都在关注模型。

哪个模型额外增强了 Cyber 能力，哪个模型能够完成更长的任务，哪个模型在 Benchmark 上取得了更高的成功率，哪个模型刷到了更高的靶场排行榜。

这些研究当然有价值。

但在实际工程中，我逐渐形成了一个不同的认识：

很多时候，Agent 最大的问题反而是它根本不具备可靠完成这件事情的基础设施。

一个模型可以理解 HTTP 协议，可以阅读 JavaScript，可以分析漏洞原理，甚至能够提出正确的攻击假设。

但如果它无法可靠地控制浏览器、恢复动态 API、处理复杂认证、维护网络会话，或者执行已经成熟的漏洞利用代码，那么这些推理能力就很难转化成实际的渗透结果。

我认为，自动化渗透真正需要解决的，不只是模型能力问题，而是如何将模型的认知能力转化为真实环境中的操作能力。

01. 给 Agent 增加工具，不等于给 Agent 增加能力

很多 Agent 项目喜欢强调工具数量。

HTTP 请求、Shell、Python、Nmap、Nuclei、浏览器、各种漏洞扫描器……

工具越来越多，Agent 看起来也越来越强。

但是工具的存在并不意味着，Agent 能够借此实现有效的渗透。

换句话来说就是，工具未必“趁手”。

例如，一个 Agent 拥有浏览器工具，它可能能够打开网页、点击按钮、填写表单，但接下来呢？

页面中的动态接口如何发现？JavaScript Bundle 如何分析？请求之间的认证状态如何保持？

某个业务操作到底调用了哪些 API？接口参数和权限关系如何恢复？

这些问题不是多注册几个工具就能解决的。

同样，一个 Agent 拥有 Shell，也并不意味着它能够稳定完成复杂的 Java 反序列化分析。

如果每次遇到一个 Gadget，都需要模型自己拼接代码、管理依赖、处理字节流和调试执行环境，那么大量 Token 最终会被无意义地消耗在本来可以由确定性程序完成的工作上，甚至于污染了模型的推理上下文。

02. CDP：从能够访问网页，到真正理解 Web 应用

现代 Web 应用早已不是简单的 HTML 页面和几个静态接口。

大量业务逻辑隐藏在 JavaScript、动态路由、异步请求和浏览器状态中。

如果 Agent 只依赖 HTTP 请求和响应，它看到的往往只是应用的一部分。

这也是为什么我认为 CDP 对自动化渗透非常重要。

CDP 不只是让 Agent 能够打开 Chromium。

它提供了一个观察和控制真实浏览器运行过程的接口。

通过它，可以获取：

• 动态页面和 DOM 状态
• 浏览器实际发出的网络请求
• JavaScript 加载和执行行为
• Cookie 与认证上下文
• 页面交互和业务流程
• 浏览器控制台与运行时错误

这些信息让 Agent 不再只是根据静态响应猜测应用行为，而是能够观察应用真正发生了什么。

更重要的是，浏览器操作与 HTTP 请求捕获可以形成统一的证据来源。

03. JavaScript 逆向与 API 重建：不要让 Agent 从零猜测接口

另一个非常典型的问题是前端 API 发现。

传统扫描器通常依赖爬虫、字典和有限的页面交互寻找接口。

但现代 SPA 可能将大量业务接口隐藏在 JavaScript Bundle、动态路由和前端状态管理逻辑中。

仅仅通过目录扫描，很容易遗漏大量真实业务接口。

所以即使在自动化渗透还没有流行的时代，就已经有很多红队师傅们创造了不少基于 JS 解析的接口发现和敏感凭据检测的工具。

但是当我们来到了自动化渗透时代，不少架构选择了让 LLM 自己阅读所有 JavaScript 文件，这产生大量重复分析和上下文消耗，而且分析效果完全取决于模型能力。

我更倾向于把这部分工作工程化。

首先，通过静态资源提取、JavaScript 解析和相关代码分析，恢复接口路径、请求方法、参数结构和相关业务信息。

然后将结果转换成结构化 API 描述，甚至于更极端一些，JS2OpenAPI。随后交给一个 AI Agent 回到目标网站进行复核和校验，保障准确性。

而结构化 API 重建能够让 Agent 从已经恢复的接口信息出发，进一步研究参数、权限和业务关系。

从而我们改善了 AI Agent 对于整个目标站点的感知能力，使其可以更加专注于问题梳理而不是不必要的工程问题。

与其让模型反复猜测已经存在于代码中的信息，不如先通过确定性分析把这些信息提取出来。

这也是我认为基础设施能够显著降低模型无效推理成本的一个典型例子。

04. 验证码、凭据与代理：真实渗透中的障碍不是靠 Prompt 消除的

很多自动化渗透 Demo 都喜欢展示模型如何自主发现漏洞。

但真实环境中，Agent 经常还没有进入漏洞测试阶段，就已经被各种执行障碍挡住了。

例如验证码。我们从没有 AI 的时代就已经开始使用 AI 进行反自动化了。

如果每次遇到验证码，都让通用 Agent 临时研究图像识别、浏览器交互和验证流程，那么这套系统很难形成稳定的执行能力。

我更倾向于将验证码分析纳入特定 AI 专家的专业方法论，并使用针对不同机制实现的确定性处理模块。

其他专家遇到认证障碍时，可以直接委派专家进行处理。

类似的问题还包括凭据分析和网络出口管理。

一个真实的渗透系统需要能够理解凭据的来源、类型和适用范围，也需要在网络出口受到 WAF 或地区策略限制时，按照授权策略调整出口条件。

默认保持出口稳定，在明确的环境阻碍下才进行调整，能够减少会话和风控状态的不确定性。

这些能力看起来与漏洞发现没有直接关系，但它们决定了 Agent 能否继续完成原本的测试任务。

正如“出来混，第一步应该是出来”。

05. 确定性 EXP：不要让模型每次重新实现已经存在的利用能力

这是我认为自动化渗透基础设施中非常重要的一部分。

目前不少 AI 渗透方案会给 Agent 提供大量公开 EXP 和 PoC，让模型自己选择、理解、修改和执行。

我一直对这种方式比较谨慎。

一个已经被研究人员分析过、已经有成熟利用代码的漏洞，为什么还需要模型每次在客户环境中重新研究一遍？

客户的生产环境不是 EXP 研发实验室。

EXP 研发应该在对应的源码、版本、构建和 Lab 环境中完成。

生产环境则应该调用已经验证过的确定性利用能力。

产品识别、漏洞适用性确认、触发方式、影响范围，我们应该在打出一个 EXP 之前先进行思考。

一个可靠的 EXP 插件应该有明确的适用条件、执行预算和证据语义，且便于被 AI 使用。

这才是我理解的 AI + EXP。

06. 指纹识别：从一次性扫描，到持续观察目标

还有一项基础设施经常被低估：被动指纹识别。

传统指纹扫描器通常需要主动发送请求，再根据响应匹配产品特征。

但在一个已经具备 HTTP 流量捕获和 CDP 的系统中，我们其实已经拥有大量真实请求和响应。

为什么还要为了识别技术栈，重复发送一批请求？

我更倾向于直接消费现有流量。

例如：

• HTTP Header
• Cookie 格式
• HTML 特征
• Favicon
• JavaScript 资源
• 静态资源路径
• TLS 特征
• 浏览器实际加载的组件

这些信息可以持续产生新的产品识别线索。

而且，真实流量还有一个额外价值：它能提供大量容易造成误判的负样本。

一个指纹规则可能在实验室里非常准确，但在真实企业环境中，CDN、WAF、反向代理、自研系统和二次开发都可能让它产生错误匹配。

所以我认为，一个真正有价值的指纹库，不应该只积累正样本，还应该不断积累真实环境中的误判经验。

在工程组织上，它可以作为旁路观察模块，在识别到有意义的新增信息后，通过现有 Steer 机制向当前 Agent 发送提示。

Agent 自己决定是否需要进一步探索，甚至于可以结合自动化 Nday 匹配实现更智能化的利用。

07. 基础设施的价值在于扩大 Agent 的有效操作范围

把前面的能力放在一起，我们会发现一个共同点。

CDP 让 Agent 能够观察真实浏览器行为。

JavaScript 解析和 API 重建让 Agent 能够理解动态 Web 应用。

验证码专家和确定性验证码模块让 Agent 能够继续处理复杂认证流程。

代理基础设施让 Agent 能够应对网络出口变化。

EXP 插件让 Agent 能够调用已经工程化的漏洞利用能力。

被动指纹则让 Agent 能够从已有流量中持续获得新的环境认知。

它们共同改变了 Agent 能够完成的任务范围。

我更愿意把这个概念称为：

Operational Reach，或者说有效操作范围。

一个模型即使拥有很强的推理能力，如果它只能使用简单 HTTP 请求，那么它能够有效探索的目标空间和效率仍然有限。

当它拥有真实浏览器、JS 分析、结构化 API、专业认证处理和确定性 EXP 时，能够进入的业务流程和能够完成的安全检查就会发生变化。

模型推理能力很重要，但基础设施决定了这些能力能够在多大程度上转化成真实结果。

08. 基础设施不是越多越好

说到这里，可能有人会认为，我的意思是应该不断给 Agent 增加基础设施。

但是事实上，我认为基础设施本身也有一个非常容易失控的问题。

每增加一个模块，就会增加新的接口、状态、权限、失败模式和维护责任。

如果为了增加 CDP、JS Intelligence、EXP、指纹识别和代理管理，就不断增加独立 Agent、Manager、服务和协调机制，那么最后系统可能会变得比它原本要解决的问题复杂得多。

我更倾向于遵循一个原则：

能够通过现有执行抽象解决的问题，不要创造新的执行抽象。

例如，指纹识别可以通过旁路 Steer 提供增量信息，不必增加一个新的全局规划 Agent。

验证码可以由 Credential 专家委派处理，不必再建设一个独立的验证码编排系统。

EXP 可以作为独立插件运行时，作为一个 tool 接入，而不是把整个利用框架塞进专家 Skills。

基础设施可以很丰富，但它们之间的职责边界必须清晰。

我们不应该追求最少的代码，更不应该追求最多的组件。

我更关心的是：每增加一项基础能力，是否真正解决了一个此前无法可靠完成的问题？

如果答案是否定的，那么它就没有必要进入系统。

09. 模型进步不会让基础设施失去价值

最后还有一个问题。

既然模型能力一直在提升，那么未来是否还需要这么多确定性基础设施？

我的答案是肯定的。

模型的进步会让某些过去需要专门工程实现的能力变得更容易。

但这不意味着所有执行问题都会自动消失。

未来的 Coding Agent 可能拥有更优秀的上下文管理、工具调用和长期任务恢复能力。

我们完全可以借鉴这些进步，而不必为了所谓的自主研发重新实现所有通用 Agent 基础设施。

但真实 Web 应用的动态行为、复杂认证、产品版本差异、二进制构建条件和漏洞验证证据，依然需要领域知识与确定性工程能力。

就像你永远无法因为燃气灶很好用就认为我们不需要一口好锅。

基础设施的目的是确保整体 Agent 的下限，同时尽量提高上限。

结语：不要只问模型有多聪明，也要问它能够真正做什么

如果两个 Agent 使用相同的模型，一个只有 Bash Shell，另一个拥有 CDP、JavaScript 解析、API 重建、专业凭据处理、确定性 EXP 和完整的流量捕获能力，那么它们在真实渗透中的表现很可能存在明显差异。

这种差异不能简单归因于模型，因为后者已经拥有了更大的有效操作范围。

我越来越觉得，自主渗透系统的竞争不应该只是模型之间的竞争。

模型决定了推理能力的上限之一，专业方法论决定了探索的深度，而基础设施决定了这些能力能否真正进入复杂的现实环境。

一个只会思考、却无法可靠执行的 Agent，终究很难成为真正的渗透测试系统。