序言：AI 浪潮下的我们

笔者还记得第一次给 Claude Code 接入 ida-pro-mcp 时的震撼感。AI 一分钟之内读过的代码量，够笔者读十分钟，更别提 AI 远比笔者更懂汇编。那时笔者在想，初级逆向工作似乎不再需要人来做了。两周前，Anthropic 更是亲自下场，推出了 Claude Code Security。尽管技术原理上没有新突破，但各地的安全从业者普遍哀叹自己要失业。这类哀叹有点后知后觉，因为网络攻防的 AI 化是明面上的趋势，按理不需要到现在才大梦初醒。笔者在 24 年春的文章《人工智能可以指望深度学习》中写过：AI 的发展过程，就是不断打破「AI 永远无法 ×××」这类偏见的奋斗历程。两年时间过去，笔者很幸运地看到那篇文章中的大部分预测都成了真，AI 的能力边界也早已远远超过了当时的范围。

笔者不想在本文中讨论 AI 取代人类岗位的问题，因为那是全社会的问题，不是网络安全从业者要独自面对的问题。笔者不相信此事有除了 UBI（无条件基本收入）之外的解决之道。有些评论者强调「失业的只是低级劳工，业内顶尖人士永远不会失业」，或者劝别人去掌握「AI 所永远无法掌握的技能」，这是缺乏同理心且短视的。人类内卷的速度会有 AI 快吗？培养一位少年去拿 IMO 金牌，普遍需要至少 5 年的时间；然而从 ChatGPT 发布到 Gemini 2.5 Pro 摘金 IMO2025，仅仅用了 3 年时间。是人类社会该作为一个整体去适配 AI 对世界的影响，而不是人类个体该去匹配 AI 的发展速度。

既然 AI 大规模进入网络攻防领域已成必然，我们不妨来推演一番，看看下一个时代的 APT 攻击会是怎样的。为了方便没有 LLM 基础的读者，本文先介绍若干基础概念。愿意系统性学习 LLM 原理的读者可观看台大李宏毅的课程《生成式人工智慧與機器學習導論2025》。

背景知识：LLM、token、上下文窗口、thinking

ChatGPT 类的对话模型，一般被称为大语言模型。它们的工作可以简化地描述为：「对于一段文本，给它填写下一个字」。例如，输入「世界上最高的山是」这样一句话，LLM 会填写下一个字为「珠」；再继续给 LLM 输入「世界上最高的山是珠」，LLM 就会继续填写下一个字「穆」。循环执行这个过程，直到 LLM 表示不再需要填写下一个词为止。此时我们就有了完整的句子：「世界上最高的山是珠穆朗玛峰」。

上述任务就是 next token prediction（预测下一个词元）。具体实践上，并非一个汉字严格对应一个 token，而是会有一个被称为 tokenizer 的工具，将汉字字符串切成 token 序列再输入给 LLM，例如目前 GPT-5 模型的 tokenizer，大约每 100 个汉字切成 80 个 token；当代 LLM 也不一定是每次只预测下一个 token，例如 DeepSeek-V3 就一次性预测多个 token。

多轮对话是如何实现的？假设用户询问「世界上最高的山是哪座」，LLM 回答「珠穆朗玛峰」，接下来用户又询问「广东的呢」，此时 LLM 接收到的输入大致是：

user: 世界上最高的山是哪座
llm: 珠穆朗玛峰
user: 广东的呢
llm:

因此，LLM 在回答问题时，是有前几轮对话的记忆的。不过，每次能输入给 LLM 的 token 数量存在上限，这称为 context window（上下文窗口）。最早期的 ChatGPT 仅仅支持 4096 个 token 的输入，甚至塞不下本篇博客文章；但现在的 LLM 普遍有 128k 以上的上下文窗口，可以放入大量的指令和背景知识。我们在一个上下文窗口内输入给 LLM 的内容，被称为 prompt（提示词）。

想要用好 LLM，就要写好提示词。例如，要用 LLM 写一篇分析文章，直接说「对××话题写篇文」，效果就不如「对××话题写一篇 1500 字的分析文章，包含前言、分论点、结论，其中分论点至少三个」。对提示词进行优化的方法论，称为「prompt 工程」。相关技术细节可以参考本站 25 年春的文章《从 Cline 看 prompt 工程》。

从 OpenAI o1 和 DeepSeek-R1 开始，主流模型普遍提供 thinking 能力。所谓 thinking，就是先输出一些草稿性的内容，最后再输出正式回答。thinking 可以大幅提升 LLM 的逻辑能力，当前最强 LLM 榜单可以参考 lmarena 网站，排行在前的几乎全部是 thinking 模型。

大模型 API 调用一般按 token 消耗量计费，且输出 token 一般比输入 token 更贵。thinking 过程产生的草稿属于输出 token，所以 thinking 模型的调用价格比较昂贵。不过，主流供应商（OpenAI、Google DeepMind、Anthropic）都提供了调整思考强度的选项，可以帮助用户控制成本。笔者编写本文时的旗舰模型是 Claude Opus 4.6，输入价格 5 USD / 1M token，输出价格 25 USD / 1M token。

背景知识：RAG、tool use、MCP

在 LLM 落地后的极短时间内，人们发现，很多情况下，我们需要 LLM 有一些背景知识。但上下文窗口是有限的，不可能把完整的背景知识放入 prompt。于是，我们用上了 RAG 技术。它的原理大致是：假设笔者要做某产品的智能客服，那么笔者就找到产品的说明书，先切成很多个片段（每个片段大约几百字），然后通过 embedding 模型把这些文字片段映射到高维向量。embedding 模型有一个特点：两个片段，它们的语义越相似，那么它们对应的向量就越接近。现在用户向智能客服提了一个问题，我们先把用户的问题也通过 embedding 模型转化成向量，再从向量数据库里面找 5 个与该向量最接近的向量，把检出的这 5 个向量对应的文本作为背景知识附加到 prompt 中，再输入给 LLM。现在，上下文里面就有了与用户问题最相关的几条知识，LLM 也就能依据事实作答了。

上述流程可以整理为：「用户输入 → RAG 模块查询相关文档 → 输入给 LLM → 输出给用户」，LLM 只是流程中的一个结点，不控制任务流程本身，因此是 workflow（工作流）。再来看另一个经典例子：我们有一个数据库，想通过自然语言进行查询。那么，我们可以构建 workflow：「用户输入 → 拼接上建表语句等背景知识 → 由 LLM 输出一个 SQL 语句 → 将 SQL 语句的执行结果反馈给用户」。这个工作流被称为 Text-to-SQL。

然而，有些时候，单条 SQL 语句不一定能实现目标。例如，现在有一个软件漏洞数据库，每一行都是用自然语言来描述「××软件有某某漏洞」。那么，如果用户提问「列出今天爆出 RCE 漏洞的软件，并查询这些软件的其他漏洞」，此时必须执行两次查询：第一次查出今天爆出的所有 RCE 漏洞，由 LLM 从漏洞描述中提取软件名称；再执行第二次查询，查这些软件对应的历史漏洞。

所以，我们会倾向于设计一个循环，让 LLM 自主决定下一次行动是「通过 SQL 查询数据库」还是「对用户输出结果」。在此情况下，提示词会包含：任务指引；用户输入的问题；之前历次 SQL 的执行结果。如果 LLM 认为信息还没有收集完毕，则输出一个 SQL 语句，由系统执行，把结果放进下一次 LLM 调用的上下文；否则用自然语言输出答案。这就是一个典型的 agent（智能体）而非 workflow，因为任务流程是由 LLM 的判断来控制的。这类「不断调用工具直到输出最终答案」的 agent，一般称为 ReAct agent。

我们把「通过 SQL 查询数据库」这样的能力称为「工具」。我们可以给 LLM 提供很多个工具，例如查 SQL 的工具、执行 Python 的工具、上网搜索的工具，每个工具会有一段话描述它如何使用。LLM 会阅读所有工具的描述，自行判断是否使用工具，如果使用工具，则会输出工具调用的参数（一个 json）。

当前，想要给 LLM 提供工具，一般靠 MCP server 实现。一个 MCP server 里面包含若干个可供 LLM 调用的工具。我们可以在电脑上安装 Excel MCP，让 LLM 获得读写 excel 表格的能力；可以提供 Weather MCP，让 LLM 查询天气……详情可参考本站 25 年文章《MCP 协议：连接 LLM 与世界》。我们在 Cherry Studio 上给 LLM 配置 MCP 之后，它可以自行多次调用工具，直到输出最终结果，所以它是 agent 而非 workflow。

背景知识：通用智能体、skill

我们很自然地想到，如果给 LLM 提供一些基础工具，例如读写电脑上的文件、执行 bash 指令、浏览互联网，那么它将形成一个通用 agent，可以如同员工一样工作，例如帮我们写代码并测试。Claude Code 就是典型的通用 agent，它内置很多工具，并且可以连接 MCP server 以获得更多的工具；它可以读写文件，因此可以把需要记住的内容写进文件，供下一次运行时读取。它还有上下文压缩功能，当 prompt（包括系统指令、工具描述、用户指令、历次工具执行结果等）长度超过阈值时，自动总结 prompt 中的重点，压缩成更短的 prompt。而且，它还能调用 subagent——例如，当 Claude Code 想要在源码树中查询某个关键词时，它能启动一个子 agent，任务是「在目录下查询×××，把结果整理之后汇报」。subagent 读了大量的文件，上下文里充满了噪音，但主 agent 只读取 subagent 整理后的报告，因此主 agent 的上下文窗口不会被文件内容塞满。

当我们想要给通用 agent 教一项特殊技能，我们该如何实现？目前最主流的方式是编写 skill 文档。例如，如果我们想要让 Claude Code 学会查询明天是否有火烧云，我们可以编写下面的 SKILL.md，放入 ~/.claude/skills/sunsetbot/：

---
name: sunsetbot
description: 查询某地明天是否有火烧云
---

用 Playwright MCP 操控 chrome 浏览器，打开 https://sunsetbot.top/ 网站，填入要查询的地点，点击「搜索」按钮。两秒钟后，读取页面，如果「火烧云鲜艳度」数值大于 0.05，则有火烧云。

这个网站更详细的使用手册，位于本 skill 目录下的 `manual.md`。

当 Claude Code 收到「火烧云查询」任务时，它会读取上述 skill 文档，然后按照指示调用工具，帮用户解决问题。如果它认为有必要，则还可以进一步读出 manual.md 中的内容。

当前的主流通用智能体有 Claude Code、Codex、OpenCode、OpenClaw 等。它们用到的技术是相似的，包括上下文工程、记忆管理、内置工具和内置 skill，可以参考本站上个月的文章《从 nanobot 看 context 工程》。至此，我们介绍完了本文所需的全部理论基础，该开始讨论 AI 将如何改变网安行业了。

第一性原理

欲评估 AI 会如何改变一项行业，我们可以运用「第一性原理」。这是马斯克成天挂在嘴边的词，意思大致是：直面原始需求，假设现有的解决方案全都不存在，从零开始分析，要完成这个需求，最关键的制约因素（也就是瓶颈）在哪里。

现在试着采用第一性原理分析 AI 如何改变「翻译」行业。乍一看，翻译这项业务的需求是多变的，输入内容可能是短至几个字的短语，可能是长至几十万字的鸿篇巨制；应用场景包括学术论文、生活博客、商务谈判、出国旅游与当地人交流；可接受的延迟级别也从同声传译的秒级到世界名著的以年为单位。然而，抽丝剥茧，翻译业务的原始需求是：将 A 语言的文本重新表达成 B 语言文本。所以，核心瓶颈是「需要翻译者同时通晓 A、B 两种语言及其文化，并采用符合场景的表达方式」。我们知道，这正是 AI 的长处，所以我们看到 AI 已经颠覆了翻译行业，日常翻译领域已经没有人类的饭碗了。

接下来分析「CRUD 类软件开发」行业。此类软件开发的原始需求是：把用户心里所期望的功能转化为软件。于是，它有两大瓶颈：一是如何描述用户的需求（毕竟用户一般最开始也无法明确指出自己要什么）；二是如何把需求落地（架构设计、选型、代码开发）。传统上，这两大瓶颈都需要专业人员，即产品经理和程序员。我们发展出了高级语言和软件工程学，它们很大程度上缓解了需求落地瓶颈，我们用 Python 实现需求远比用汇编简单；但第一项瓶颈的解决仍然比较依赖人力。现在，在 AI 时代来重新分析这两大瓶颈：需求落地这个瓶颈几乎可以被 AI 完全解决；需求分析的瓶颈由于需要与用户交互，所以仍然存在。那么，如何用 AI 提升需求分析效率？这也是明摆着的，让 AI 来跟用户随时交流。所以我们可以想象未来的 CRUD 软件开发会是什么形态：用户向 AI 描述初始需求，AI 引导用户越来越细化需求，并产出原型产品供用户使用，收集用户反馈和新需求，推动软件迭代，直至用户满意为止。

现在，我们运用第一性原理，分析 AI 会如何改变网络安全行业。攻击方的原始需求是攻破目标系统；防守方的原始需求是保护目标系统不被攻击方攻破。所以，我们接下来着力于分析攻击方的攻击策略，再倒推防守方的应对措施。网络攻击有两大难题：如何攻入指定系统、如何在防守方响应之前把攻击成果转化为收益（以供下一步攻击使用，或直接产生现实利益）。我们来讨论一个典型的攻击场景：攻击者先通过 RCE 漏洞攻破了某企业的官网，dump 出了用户表（包含密码 hash）；接下来运维方修复了漏洞、清除了木马，但攻击者通过本地撞库，获得了一些员工的密码，并以相同的密码登录这些员工的 VPN，进入企业内网，攻破了一些内网系统，获取到机密，在黑市上出售。这里有两场攻击：一场是针对官网的攻击，另一场是针对内网的攻击；有两项收益，dump 密码表的收益用于支撑第二场攻击，获取机密信息的收益用于变现。

「如何攻入系统」考验的是综合攻击能力，包含漏洞储备、黑盒漏洞挖掘、提权、社工等；「如何利用攻击成果」则更考验决策能力，是选择长期潜伏还是选择立即窃取关键数据，即使一小时后被发现也在所不惜？推理一番，我们能找到两个瓶颈：一是「通用攻击技术」，二是「对靶标的理解」。

先说通用攻击技术。它包含两个方向：一是漏洞储备，二是挖洞水平。我们知道，大部分黑客都会尝试利用 1day，而顶级 APT 组织一般还会囤积 0day 漏洞，甚至不乏永恒之蓝这种核弹级漏洞。这些 1day 和 0day，笔者将其归纳为漏洞储备。而对于没有已知漏洞的业务系统，攻击者需要现场挖洞，绝大部分系统是黑盒攻击。当然，挖洞水平高的团队在平时也能对公共组件挖出 0day 漏洞，所以挖洞水平可以提升漏洞储备。

通用攻击技术是不依赖于特定靶标的。提升通用攻击技术，可以提升对所有靶标的攻击能力。但另一个瓶颈，即「对靶标的理解」，是与靶标强绑定的。目标组织的网络拓扑；各个业务系统采用的软件组件；目标组织所采用的软件供应链；哪些人有哪些系统的高权限；目标组织员工的个人隐私……这些知识管理起来绝非易事，但它们拥有极高的价值。个人隐私能用于社工，掌握目标系统组件版本能让攻击不至于暴力扫描触发 waf，诸如此类。

下面，我们分析 AI 该如何用于解决这两大瓶颈。本文讨论有两个前提：一是攻击方乃属国家级 APT 组织，拥有最顶级的黑客和几乎无尽的算力资源；二是防守方是员工超过 10 万人的大型组织，且至少存在 20 个必须向互联网开放的复杂系统。

攻击方技术：通过 AI 管理情报

尽管没有直接证据，但笔者认为顶级 APT 组织已经将 AI 用于情报管理。原因很简单：情报管理的核心是知识检索和关联，AI 在这方面有天然优势。即使是简单的「把搜集到的情报录入数据库」和「用自然语言查询某目标系统的情报」，引入 AI 都能大幅节省人工。

利用通用智能体，APT 组织可以 7×24h 不间断地社工，把企业的所有员工进行大起底，找到他们的历史泄漏密码用来尝试登入，伪装成员工的亲友、供应商或甲方以进行钓鱼，还能实时监测研发员工的 Github 推送，从中寻找残留的 api key。甚至，通过社交媒体动态，APT 组织可以找出某系统专职运维员发的「加班加到凌晨，好累， 我要回去连着睡 10 小时」这类微博。这绝非危言耸听，因为上述工作都是技术上毫无难度的，以前没有监控到这个程度，无非是因为 APT 组织没有足够的人手。然而，引入 AI 之后，这些工作成本很低，而有潜在收益，没有理由不使用。

APT 组织不仅应该由 AI 维护靶标知识，还应该允许 AI 基于情报自主策划一些新任务。例如，渗透过程中见到某系统采用了小众开源组件，就记录在情报库中，启动新任务以对该开源组件进行漏洞挖掘；又如，当攻击方尝试攻击某 IP，发现被某厂商的 waf 产品封堵，AI 可以实时记录状况，细化对目标网络布防的建模，同时启动新任务寻找该厂商 waf 的绕过方式……AI 成为所有情报的汇点，且时刻为攻击行为提供最新的情报支持，同时调度 agent 执行开源软件漏洞挖掘等子任务，应该是未来 APT 的一大特色。

攻击方技术：自动进化的挖洞能力和漏洞库

AI 可以用来挖出新漏洞，这是众所周知的。agent 在 CTF 竞赛的 web 方向（偏向黑盒漏洞挖掘）、开源软件代码审计方面都表现出色，而且还能熟练使用 fuzzing 等技能。本文最关心的问题是：这些技能可否自我进化？如果 AI 的挖洞能力能在无人工干预的情况下自主提升，那么我们可能迎来挖洞领域的 AlphaGo 时刻。

笔者的回答是：能。甚至现有的 skill 范式就能做到这一点。让我们来执行一个思想实验：假设要让 AI 精通 SQL 注入。那么，我们首先用旗舰 LLM 写一个最基本的 SQL 注入指南作为 skill 文档，接下来启动 100 个 agent，让它们按照指南对一些目标实施攻击。一轮结束后，整理这 100 个 agent 的输出，获得大量的实践经验，然后通过裁判 agent 执行实验，保留那些合适的改进，并更新 skill 文档。下一轮，又让这 100 个 agent 基于新 skill 去尝试改进……很显然，这样一遍遍迭代下去，skill 的水平会越来越高。这套方案所产出的核心资产是 skill，而 skill 是非常方便复用的，后方的研究型 agent 发现的新技术，更新到 skill 中，马上就能被前线的实战型 agent 使用，并给出实践反馈，反哺研究。

笔者估计，通过大规模 agent 实验来迭代 skill，应当是 AI 领域的通用进化思路。只要目标是良定义的（不像绘画那样充满主观感受），也许都能采用这套方案进行优化。当然，这套方案也是吞金巨兽，消耗海量的 token 只为了优化一版 skill。但它的成果有足够的吸引力：挖洞能力越强，则挖掘 0day 的效率也越高，而 skill 可以给无数个 AI 使用，相当于有了海量的挖洞专家，可以夜以继日地生产 0day。这对 APT 组织来说是相当诱人的。

有一个话题值得单独拿出来讨论：AI 专用的安全工具。我们现在常用的 sqlmap 等工具，都是为人类设计的，甚至还有些 GUI 工具从未考虑过被自动操控。这些工具对 AI 而言不够灵活。笔者预测，未来 AI 将会另起炉灶，产出大量的仅供 AI 使用的安全工具，例如把 sqlmap 重构为 libsqlmap，并提供使用手册及二次开发指引。agent 工作时，现场编写代码调用其能力，并视情况二次开发 libsqlmap 本身。这套方案虽然不再能被人类轻易上手，但能为 AI 提供远超以往的灵活性。

写到这里，我们已经逐步绘制出了未来的攻击图景：APT 组织内有成千上万的挖洞 agent，每天都在产出漏洞，而且囤积了大量的永恒之蓝级别 0day；他们每小时都会迭代出一版最新的攻击指南，每个攻击 agent 都是黑盒攻击专家，精通各种攻击方式，还很能绕 waf；防守方每个员工的社媒都被日夜监控，常用密码已经被 APT 组织掌握，身边还充斥着钓鱼者；防守方的业务系统每次引入新的开源组件，立刻被 APT 组织通过自动化的资产测绘系统探测到，并启动 agent 研究开源组件漏洞，以便在攻击波次中打出……笔者将这样的攻击方式称为「饱和式 AI 攻击」，因为 APT 组织可以突然打出海量并发的真实攻击，使防守方过载，并在成功突破防御后以极高的速度收集成果。如果防守方采取传统的应对方式，则必然会被淹没在告警的海洋中，被人工反应拖慢时间，等到防守方连接到受害服务器排查情况，重要数据早已被盗完了。

国内的高价值目标主要是政府和国企，但以现在的实际情况看，应该没有任何一家组织能对抗如此程度的攻击态势。他们连一年一度的攻防演练都需要提前几个月准备、需要从安全厂商要临时工，可想而知，对饱和式 AI 攻击毫无还手之力。哪家企业会率先被打穿，不是由它们的布防能力决定的，而是由它们对 APT 组织的价值决定的。笔者预计，在 2026 年的第三、四季度，顶级 APT 组织将实现攻击技法的自动进化，并囤积 AI 挖出的 0day 漏洞；第一次引起社会关注的饱和式 AI 攻击将于 2027 年底之前发生。

防守策略：把人赶出回路

现在，我们基于饱和式 AI 攻击的场景，逆推防守方应当采取何种策略。

传统模式下，防守方会有人员盯监控大屏，对安全设备的告警采取相应的处置措施。有些企业允许安全设备自动封禁攻击者 IP，但自动化程度也就到此为止了。一些容易影响业务的操作，例如编写 url 拦截规则，基本还是通过人工执行。这是典型的「人在回路」（human-in-the-loop）方案，即使防御系统自动生成了动作建议，也需要等待人类批准。人在回路保证了业务不会因为自动系统的误操作而中断，然而，饱和式 AI 攻击场景下，人在回路反而会成为防守体系的缺陷，因为人类的反应延迟会让攻击者获得巨大的时间窗口。人类的研判速度不可能追得上 AI 的攻击速度，即使人类只延迟了两分钟做出封堵决定，这两分钟时间也足够 AI 攻击者造成大量破坏、收集大量情报，而这些情报又将为下一个波次的攻击提供助力……我们很快就能推理出一个结论：要让防守动作的延迟赶得上攻击节奏，那就必须把人赶出回路，给 AI 授予完全的权限，靠 AI 执行防守。

接下来，在已经确定要把人赶出回路的前提下，我们再来看看市场上现有的方案。

「以 AI 对抗 AI」这个概念已经是很多网安从业者的共识，但说来说去，市场上非常成熟的产品只有一种，就是告警自动研判。它的主体是一个 workflow，对告警进行聚合和分析，会关联一些上下文，例如相同受害 IP 的历史警报。此外，这类产品一般会提供一个 agent 对话框，允许人类对分析结果提问，它去查询相关资料。理想状态下，每天各种安全设备产生的原始告警，最后会合并成几十条事件，然后由人类研读这些事件报告，而非观察原始告警。这些产品往往将自己标榜成 SOC 的「副驾驶」，但是，「副驾驶」的叙事存在一个隐含假设：它们假设每天的真实攻击数量是可以被人类分析完的，然而这显然不适用于饱和式 AI 攻击场景。想让这些告警研判产品在饱和式攻击中发挥作用，就需要把它们的分析结果直接送进后级 AI，不再顾虑人类用户的使用体验。但说句实话，这些产品普遍发布于通用 agent 时代之前，与现在的 AI 方法论差了一代，可能完全推倒重写会更有价值。

另一类不太成熟的产品，AI + SOAR，有希望发挥更大的作用。SOAR 系统已经接入了各类安全设备的 API，可以实现封堵等任务，比较适合担任下一代 AI 响应机制的基座。当我们允许 AI 自动编写 SOAR 剧本时，我们实质上就给 AI 赋予了直接操纵安全设备的能力。但目前笔者暂未听说哪个企业允许 AI 全自动地下发可能会影响业务的规则。这套方案的主要缺点在于，AI 有幻觉，容易误操作，这种锅目前是没有决策者愿意背的。

前文假设了 APT 组织拥有近乎无限的算力，但我们不能假设防守方有巨量算力。事实与之恰好相反——防守方的算力少得可怜。由于数据合规性原因，防守方几乎一定会要求 LLM 推理在本地服务器内进行；由于采购合规性原因，国内的高价值目标一般会使用国产 GPU，本身性能就不如英伟达产品，且 infra 能力的低下会进一步放大算力劣势。粗略估计，这些防守方执行 LLM 推理的成本，可能是世界顶级实验室的数倍到数十倍。用于安全的预算是有限的，在没有饱和攻击指征的前提下，防守方不太可能投入巨量算力在 AI 防御上，但如果不建立完备的 AI 防御体系，则第一波饱和式攻击就会是毁灭性的。

推演到这里，我们发现，防守方在算力上不如攻击方，在安全技术上也不如专业的攻击方。那防守方还有任何赢面吗？再次运用第一性原理来分析：防守方最颠扑不破的优势，是它对自己的资产拥有完全的控制权。破局之道，只能在其中。

防守方技术：紧跟开源情报的漏洞修复

尽管 0day 漏洞无法预先修复，但是 1day 漏洞抢修还是可以做到的。世界上不只是 APT 组织在挖掘开源组件漏洞；可以想见，大量的社区组织也在挖这些漏洞，并且会把挖到的漏洞公开出来。这带来了两方面影响：业余黑客拥有了更多的弹药，可以快速用于攻击；但防守方也可以根据开源情报，快速部署封堵策略，同时尝试修复漏洞。修复速度越快，风险暴露窗口就越短。最理想的情况下，社区挖洞效率与 APT 组织一致，此时 APT 组织将无法囤积 0day 漏洞。那么，1day 漏洞的封堵和修复速度就成为了决胜的关键。

一般来说，防守方首先要设定临时的安全设备策略，根据流量特征拦截攻击；接下来要根治漏洞，将其修复。然而，这些行为都是需要情报支撑的，防守方必须能以最快的速度拿到 1day 漏洞的详情。笔者估计，要求每个防守方自行建设 1day 情报平台（包括爬虫、流量特征规则生成、修复方案生成）并不现实，应该不久之后会有安全公司开始卖这类服务。但防守方即使拿到了现成的封堵规则和修复方案，由于系统部署的差别，修复方案也会需要由主机侧 agent 来落地。这对防守方的算力提出了要求。

防守方技术：宏观和微观智能体的协同

下一代的防守是以 agent 为中心的。防守方必须引入宏观的防御决策 agent，负责下发各类指令；与此同时，防御方也必须部署微观的 agent，作为传感器和机械臂。上一节已经提到了我们需要主机 agent 实现漏洞修复，但这些 agent 的能力不止于此。它们需要担负起观察系统状态的使命。主机侧 agent 可以对主机本身进行检查，至少包括：分析过去一段时间内的系统日志、应用日志；分析文件系统是否有明显异常；分析设备性能状况等。此外，宏观 agent 可能会下发任务，例如「所有机器都需要排查自己是否存在 /tmp/hacked 文件」，或者「某几台主机需要检查 nginx 日志是否有特定 url 访问」，这些任务都要靠微观 agent 落地。

建立这种宏观 + 微观 agent 系统之后，防守方的 AI 将终于能获得人类应急处置组的主要能力：观察告警、排查单个主机、设定安全设备规则等。举个应用案例：宏观 AI 在关注到某台主机被入侵后，可以一边关闭该主机的互联网访问，一边要求主机侧的微观 agent 排查 ssh 登录尝试日志。微观 agent 将排查结果汇报给宏观 agent，宏观 agent 发现其中有一些来自局域网的异常连接，于是向这些局域网主机上的微观 agent 下发排查任务……这样的系统既有整体调度，又能准确收集底层信息，比较适合应对 AI 攻击。

防守方技术：通过蜜罐阻止横向移动

在饱和式 AI 攻击时代，蜜罐将是阻止横向移动的最有力武器。攻击者想要横向移动，则很难完全不踩中蜜罐；当蜜罐遍布整个网络时，宏观 agent 便可以推断各个网络的受攻击情况。蜜罐还有一个额外的作用：收集攻击手法，甚至倒推攻击 skill。举个例子，如果攻击方对所有潜在的 SQL 注入点都会先尝试几个 payload，则防守方可以将这些 payload 作为攻击特征，部署到安全设备上。

结语

饱和式 AI 攻击是下一个时代的 APT 攻击模式。如果不能在攻击浪潮来临前建立 AI 驱动的防线，则防御必然失效。然而，AI 防御的落地实在太困难，不仅是技术问题，更是魄力问题。「在确保安全可控的前提下推广 AI 防御」之类的说法属于痴人说梦，AI 防御必定会导致业务中断，甚至是核心业务中断。但是防御方不太愿意主动接受这一事实，估计只能在被打穿之后被动接受这一事实。

纸上的推演很难提升防御水平，实战才是金标准。笔者预计，再过一段时间，就会有安全公司售卖 AI 红队服务，即 APT 组织的那套 AI 攻击系统的迷你版，对客户进行不间断的 AI 攻击。到那时，攻防对抗的实践会让防守方的响应能力大幅提升，可能会找到比本文的「宏观 + 微观智能体」更好的防守方案。