利用不对称：AI攻击速度远超修补速度

多年来，智能合约安全领域一直流传着一个令人安心的说法：漏洞利用很难。要找到一个真正有利用价值的漏洞，需要一名熟练的技术人员花上数周时间仔细研读代码，并且还得靠大量运气。审计、漏洞赏金和形式化验证都建立在这一假设之上：攻击者的工作是缓慢的。

这个假设正在被打破。研究显示，AI agent 能够自主读取合约、发现漏洞，并快速、大规模地生成可运行且已验证的漏洞利用代码。一项研究得出结论，2025 年发生的区块链漏洞利用事件中，超过一半可以由当前的 AI agent 自主执行。攻击者的工作已经不再缓慢。

这发生在 DeFi 经历的一段艰难时期中，最近一个季度漏洞利用事件数量创下了纪录，被盗金额约为七十五亿美元。因此，对于任何部署链上代码的人来说，问题不在于这重不重要。而在于这种不对称到底是什么，有多少是真实的、有多少是炒作，以及当对方拥有和你一样的 AI 且激励更强时，防御该是什么样子。

智能合约安全中新的不对称性是什么？

这种不对称性体现在两个方面。首先，AI 大大压缩了发现和武器化漏洞的时间与成本，因此攻击者从慢速工作变成了快速工作。其次，经济上有利于攻击方：找到一处漏洞的攻击者能获取全部价值，而防御方必须覆盖所有漏洞，通常只能通过赏金获得一小部分报酬。再加上 AI 生成的代码带来了更多漏洞，攻击面增长的速度超过了任何人能保护它的速度。

安全一直存在结构性失衡。防御者必须在所有地方都是正确的。攻击者只需正确一次。

AI 加剧了这种失衡，因为它放大了成本低的那一方。过去，扫描数千个合约以寻找已知弱点是人类能力的瓶颈。现在，这是一个 agent 可以持续运行的循环。防御者仍然需要保护一切；攻击者现在可以自动搜索一切。

而且金钱的激励方向是错的。成功的攻击者获得全部奖励。而率先发现同一漏洞的防御者通常只能获得其中一小部分的赏金。当双方都能运行相同工具时，回报更大的那一方会更加努力地扫描。

AI 真的能写出可用的漏洞利用代码，还是这只是炒作？

这是真实的，但有一些限制。学术研究已经构建了 agent 系统，这些系统利用现成的模型，通过工具读取合约、制定策略，并通过实际执行来验证漏洞利用，因此只报告可用的攻击证明。在红队评估中，agent 针对训练截止日期之后被攻破的合约生成了价值数百万美元的漏洞利用，并且成功率超过一半。其限制在于在大型代码库中可靠地发现漏洞，而这个限制正在缩小。

实事求是的说法不是“AI 能黑掉一切”。这更具体，也更令人不安。

研究人员构建了一个系统，将模型与一些工具和反馈回路配对，然后通过在真实区块链状态上运行每个候选漏洞利用来进行验证。这个验证步骤至关重要。它过滤了模型的猜测，只留下真正有效的漏洞利用，而这正是早期 AI 安全声明空洞无物的假阳性问题。

在另一项红队测试中，agent 被指向数百个曾在现实中被利用过的合约，要求它们自己进行攻击。它们在比自身训练数据更新的目标上构建了价值数百万美元的有效漏洞利用，并且成功率超过一半。这项工作背后的经济模型值得深思：根据一项估计，攻击者在几千美元的漏洞价值上就能盈利，而防御者需要大约十倍的金额才能收支平衡。

目前的瓶颈在于如何在庞大且陌生的代码库中快速找到正确的弱点。这是一个搜索问题，而更好的工具、更大的上下文窗口以及能力更强的 agent 正是不断攻克此类搜索问题的关键。

但是 2026 年最大的黑客事件不是与代码无关吗？

是的，这正是需要我们诚实看待的细微之处。2026 年最大的损失来自操作层面，而不是 AI 破解精巧的代码。那些头条新闻级别的 DeFi 失败案例都是社会工程和治理妥协的结果，攻击者获得了特权访问权限，而不是破坏了合约。AI 驱动的漏洞利用是一个在其之下不断上升的威胁，加速了代码层面的军备竞赛，尽管最大的可见损失仍然来自人类被操纵。这两种情况同时存在。

如果你只读了这篇文章，你可能会认为每个合约都即将被自动掏空。但损失数据并没有这么说，假装不是这样是不诚实的。

今年最大的损失并不是 AI 发现了微妙的漏洞。而是攻击者通过耐心的社会工程获得了管理控制权，或者一个跨链桥信任了伪造的消息。合约本身往往按预期工作。而合约周围的人和信任假设却没有。

所以要同时把握两个事实。操作层面是当前最大损失发生的地方。AI 漏洞利用的不对称性是代码层面威胁快速演变的方向。严肃的防御者要为两者做好准备，并注意到最糟糕的代码漏洞通常不是外来零日漏洞，而是那些因部署量超过审查量而漏过的、有充分文档记录的漏洞类别。AI 非常擅长发现这些漏洞。

为什么一次性审计不再能保护你？

因为审计是一个快照，而威胁是持续存在的。某个时间点的审计证明了截至某个日期的代码安全，但 AI 扫描器每天都在针对你部署的合约运行，包括每次升级、集成和依赖项变更之后。“审计一次”和“持续被攻击”之间的差距就是突破口。防御思路应该从一次性证书转向持续、自动化的对抗性测试，其运行频率与攻击者一样高。

审计模型假设代码停止变化，而且攻击者只是偶尔出现。这两条都不成立。

你的协议会发生变化。你升级合约、添加集成、引入新的依赖项，每次更改都可能重新引入之前审计已清除的某类漏洞。与此同时，攻击者的扫描器不会休假。它会在你每次变更后重新检查你。

记住我以加快登录速度

这就是为什么一份干净的审计报告是必要的，但已不再足够。防御的问题不再是“我们通过审计了吗”，而是“我们以与某人测试我们相同的频率和对抗性在测试自己吗”。这种重新定位就是整个游戏的关键。

AI 时代的智能合约防御实际上是什么样子的？

扭转这种不对称性：首先用攻击者的剧本持续地对自己进行测试。在部署之前，使用 AI 引导的模糊测试和不变性测试来锤打你自己的代码；强制执行成熟的模式，使整个漏洞类别无法存在；添加链上断路机制来限制任何一次资金抽干造成的损害；监控实时行为以发现异常；并对每次部署设置自动对抗性检查的门禁。目标不是写出完美的合约，而是建立一个系统，让一个被发现的漏洞不意味着全盘皆输。

防御策略是具体的。以下是它在实践中的样子。

首先，像攻击者搜索那样进行测试。由模糊测试驱动的属性和不变性测试，会向你的代码抛出数千个生成的输入，以打破你定义的规则。这与攻击方使用的机器速度搜索相同，只是指向内部。

// 防御：一个不变量在部署前被模糊测试以数千种方式锤打
function invariant_backingNeverLessThanShares() public view {
    assertGe(collateral.balanceOf(address(vault)), vault.totalShares());
}

第二，编写代码时让整个漏洞类别无法存在。最常被利用的模式是众所周知的，其修复方法也是众所周知的。在外部调用之前更新状态，防范重入，让代码结构而不是你的警觉性来强制执行这一点。

function withdraw(uint256 amount) external nonReentrant {
    require(balance[msg.sender] >= amount, "余额不足");
    balance[msg.sender] -= amount;                      // 先更新状态
    (bool ok, ) = msg.sender.call{value: amount}("");   // 最后进行外部调用
    require(ok, "转账失败");
}

第三，假设某些东西仍然会通过，并在链上限制爆炸半径。速率限制或断路机制可以将一次完全的资金抽干转变为一次可生存的事件，因为合约本身拒绝以超过设定速度的速度流失资金。

function _enforceRateLimit(uint256 amount) internal {
    if (block.timestamp > windowStart + 1 hours) { windowStart = block.timestamp; outThisWindow = 0; }
    outThisWindow += amount;
    require(outThisWindow <= MAX_PER_HOUR, "触发速率限制"); // 资金抽干被限制，而非完成
}

第四，将对抗性测试作为门禁，而非一个里程碑。将静态分析、不变性测试和 AI 辅助扫描集成到流水线中，这样未能通过的代码就无法部署。

## 不通过对抗性检查则不允许部署
- run: slither . --fail-high
- run: forge test --match-test invariant
- run: ai-audit scan --severity high --fail-on-found

第五，监控实时系统。持续的监控能够学习合约的正常行为，并标记出异常的调用序列或代币流，这能为你争取暂停的时间，以便在事情开始出错时及时反应。在 AI 节奏的攻击中，这几分钟就是事故与灾难的区别。

开发者现在应该如何应对？

将安全视为一个持续的、对抗性的系统，而不是一次性事件。在别人之前，先在自己代码上运行 AI 驱动的模糊测试和不变性测试。通过构造对已知漏洞类别进行加固。添加链上断路机制，使任何单一漏洞都不会致命。实时监控并准备好暂停机制。对部署设置自动化检查的门禁。并且记住操作层面：像保护代码一样努力保护密钥、治理和信任假设。

下次部署前的简短检查清单：

• 你是否正在用属性和不变性测试来模糊测试自己的合约，速度达到攻击者扫描你的级别？
• 你是否已经通过构造（而非仅仅通过审查）消除了已知的漏洞类别？
• 链上速率限制或断路机制是否限制了任何单一漏洞利用的最大损害？
• 是否已部署实时监控，并具备经过测试的暂停能力，以便你在几分钟内做出反应？
• 当自动化对抗性检查失败时，你的流水线是否会阻止部署？
• 你是否像保护代码一样认真地保护操作层面（密钥、管理员权限、治理、跨链桥信任），因为那里仍然是最大损失的来源？

如果你能对上述列表全部回答“是”，那么你并没有让你的协议变得不可攻破——因为没有人能做到。你只是让它成为了那种即便发现一个漏洞也不会导致你完蛋的目标，这才是现实可行的胜利。

防御者的优势在于首先攻击自己

令人不安的事实是，驱动新一轮漏洞利用的相同能力对你也是可用的。能够在你合约中找到漏洞的 AI agent，无论你是否运行它都能找到它。唯一的问题是，谁先运行它。

这就是不对称性迫使你采取的策略。你无法通过每季度一次的审计报告来打败一个持续不断的机器对手。你需要通过采用它的节奏来战胜它：持续的对抗性测试、能关闭整个漏洞类别的强化代码、能限制任何单一失败影响的运行时控制，以及让你能在资金抽干完成之前做出反应的监控。

AI 编写漏洞利用的速度比人类修补的速度更快，这并不是绝望的理由。这是一个理由，让你停止将安全视为快照，而开始将其视为一个活的系统，它像有人测试它一样无情地测试自己。能够在这个时代生存下来的协议，将是那些首先将攻击者最好的工具用在自己代码上的协议。

围绕链上代码构建持续的、对抗性的、运行时的安全，而不是依赖一次性审计，是决定一个协议能否在 AI 漏洞利用时代生存下来的验证工作。这正是我们所从事的工作。

• 原文链接： medium.com/@ancilartech/...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～