分类是核心产品：用AI Agent审计以太坊协议代码

以太坊基金会协议安全团队关于针对真实协议代码运行协调AI Agent的笔记，包括我们如何组织工作、哪些内容经得起推敲，以及客户端团队和安全研究人员可以从中借鉴什么。本文自成一体；后续文章会更深入地讨论各个客户端。

我们一直在运行什么，以及让我们惊讶的是什么

在以太坊基金会的协议安全团队，我们一直在针对网络所依赖的各种系统（如系统软件、密码学代码和必须正确的合约）运行协调的AI Agent。这些代理发现了真正的漏洞。其中一个现已公开：libp2p的gossipsub中一个可远程触发的panic（恐慌），这是以太坊共识客户端运行的P2P层的核心部分，已修复并披露，并归功于团队。

代理发现漏洞并不令人惊讶。令人惊讶的是，用于发现漏洞的工作量如此之少，而用于区分真正漏洞和看似真实漏洞的工作量却如此之多。

本文是为希望做同样事情的客户端团队和安全研究人员准备的。它涵盖了如何组织代理、候选漏洞在被视为发现之前必须达到的标准，以及让结果值得信赖的习惯。

其他地方的团队也正在收敛于相同的方案。Anthropic的前沿红队构建了一个能够针对自身系统的代理。Cloudflare也针对自身系统进行了类似操作。每个人都落入了同一个循环：将能力强大的模型指向代码库，让它搜索，并对返回的结果进行分类。因此，真正的问题是如何在不被自信满满的噪声淹没的情况下做到这一点。

先提一个警告：用于代理驱动审计的工具发展迅速，任何具体的设置都会在几周内过时。因此，本文刻意聚焦于方法（这些方法是持久的），而非工具。披露本身是一个话题，可能会单独成文。

代理是一种搜索工具，而不是预言机

指向代码库的代理是一种搜索工具，很像模糊测试器。区别在于返回的内容。模糊测试器给你一个崩溃和堆栈跟踪。代理给你更多东西，包括一份报告（调用链、影响声明、建议的严重性）以及支撑它的工件（artifacts），比如一个你可以针对真实代码运行的概念验证（proof-of-concept）。

所有这些都使结果易于阅读和信任，尤其是可运行的概念验证。所以，不要数一个代理产生了多少个候选漏洞，而要数有多少个最终被证实是真实的。

工作如何组织

我们并行运行多个代理针对一个目标。它们通过仓库本身进行协调，共享版本控制中的状态，没有中央进程分配工作。一个代理将声明写在其他代理能看到的地方，执行工作，然后提交。

我们这种方法来自Anthropic关于如何协调的工作报告，其协调方式相同。没有需要构建或维护的中央协调器，出现问题的可能性也更小。

角色由发现的工作生成：

• 侦察（Recon）：将攻击面转化为具体、可测试的假设。不是"审计解码器"，而是"此字段在此点之后被信任；这里是它应保持的属性、它可能被破坏的方式，以及能够解决它的证明。"
• 狩猎（Hunting）：获取一个假设，追踪代码路径，并尝试构建一个复现器（reproducer）。
• 补缺（Gap-filling）：查看哪些被接受、哪些被拒绝，编写下一批假设，并跟踪覆盖率，以便代理不会反复覆盖同一区域。
• 验证（Validation）：独立重新检查每个候选漏洞，移除重复项，并做出决定。

我们没有发明这个流程。Cloudflare描述了相同的阶段：侦察、并行狩猎、独立验证、去重、报告，他们的报告帮助塑造了我们的流程。

以下是候选漏洞在被视为发现之前的样子：

目标：      攻击者实际可触及的组件和入口点
不变量：    必须成立的属性
机制：      可能被破坏的具体方式
成功：      可观察的证明：panic、停滞、接受无效输入
复现器：    一个自包含的工件，可针对真实代码运行
去重：      一个键，这样两个代理就不会追逐同一件事

这个模式的存在是有原因的。它强制形成一个具体、可测试的声明和明确的完成定义。一个必须写下可观察证明的代理无法退回到"这看起来有风险"。

可复现，否则等于没发生

有一条规则比任何其他规则都重要。在没有自包含的工件能够针对真实代码复现故障，并且能由非编写者运行之前，候选漏洞就不算发现。

复现器不读取报告，也不关心模型听起来有多自信。它要么运行，要么不运行。

其大部分价值在于它捕获的误报。其中三种反复出现，每一种都是代理因错误原因而通过的情况：

• 仅在调试构建中发生的panic。按软件实际发布的方式编译并运行，值只是绕回（wrap around）。什么都不会崩溃。看起来像崩溃，但并非如此。
• 一个复现器用手工构建了某个内部值，而任何真实输入都不可能产生这个值，因为攻击者控制的所有路径都会更早地拒绝它。该漏洞只"复现"于一个无法通过任何可达路径调用的函数。
• 在形式化验证工作中，一个通过的证明并不代表你想要的含义。该语句无论代码做什么都平凡为真，或者它比你想要捕获的属性更弱。验证器满意，但定理并没有约束你实际关心的行为。

这些都不是新问题。这就像一个通过的测试，但实际上什么也没检查。新的是数量。代理编写无用的版本和真实版本一样快，并且同样自信。因此检查必须是自动化的。你不能指望代理自己发现错误。

信噪比是大部分工作

大多数候选漏洞是错误的、重复的或超出范围的。这不是方法的问题；这就是它的工作方式。目标是快速拒绝错误的候选，并用难以反驳的证明来支持真正的候选。

每一个幸存的候选漏洞都会接受两次独立检查。真正的攻击者在正常配置下是否真的能触及它？以及攻击者实现它需要付出什么代价，相比如果成功对网络造成什么代价？任何单个对等节点都能触发的漏洞，与需要特殊访问或大量资源的漏洞截然不同。

所有内容都会对照一个已知、已修复或已拒绝漏洞的持续运行列表进行检查。没有这个列表，代理会不断重新发现同一个已关闭的问题，并一遍又一遍地报告。

接受率因目标而异，这种差异本身就很有用。针对成熟且经过大量审计的代码运行，几乎没有什么能幸存下来，这本身也值得了解。"我们仔细检查了，什么都没发现"是一个真实的结果。针对探索较少的代码，或针对经过形式化验证的代码（其中机器检查的证明涵盖了模型，而部署的字节码仅被假定与之匹配）运行，就会有更多通过。

我们不是唯一发现分类是难点的人。Cloudflare的主要结论是，狭窄的范围胜过广泛的扫描。Anthropic生成了大约一千份候选报告，然后使用排序和专家评审将范围缩小到顶层，这些顶层报告的正确率约为86%。生成是容易的部分。我在这里不会公布我们自己的数字；与特定目标绑定，它们更多地说明了目标而非方法。

代理擅长什么，以及在哪里会误导

两方面都有炒作，所以这里列出一个清晰的清单，说明代理做得好和容易误导的地方。

这种分化在任务之间也并不稳定。Stanislav Fort在一系列真实漏洞上测试了多种模型，称这是一个……，即一个在某个代码库上恢复完整利用链的模型，在另一个代码库上可能连基本的数据流追踪都失败。你不能假设一次好的结果意味着下一次也会成立，这也是每个候选漏洞都要独立检查的另一个原因。

最后一行是重要的。单个代理会话擅长单步推理，而不擅长跨越一系列步骤的漏洞，其中每一步都是有效的，只是顺序错误。对于这些，代理不是搜索工具。它的工作是建议哪些序列值得通过一个……来运行。这样使用时，效果很好。用代理来替代测试框架（harness），它就会错过最昂贵的漏洞——那些只有在跨越序列时才会出现的漏洞。

保持诚实

少数几个习惯就能让代理的发现结果值得信赖，而且它们都不复杂。

• 每个工件的来源：由什么产生，在什么上下文中，针对哪个版本。一份发现应该是几个月后还能重新运行的东西。
• 关键点的确定性：一个环境，一种构建和运行方式，这样"可复现"在每台机器上都意味着同样的事情，而不仅仅是在被发现的那台机器上。
• 规范而非脚本：告诉代理什么重要——不变量和真正发现的门槛——而不是一个编号的流程。过度脚本化的代理会像过度指定的测试一样崩溃：在步骤不再有意义后仍然继续遵循步骤。一项研究发现同样的事情：额外要求将任务成功率降低了20%以上，成本提高了20%以上，作者建议将上下文保持在最低要求。
• 由人做最终决定：代理提出建议。它们不决定什么是真实的，什么是已知问题的重复，或者什么在何时披露。

瓶颈转移了

AI并没有取代安全研究人员。它转移了工作。过去用于提出和追踪假设的时间，现在被用于规模化地评判它们，包括构建预言机、运行分类、维护已知问题列表，以及处理披露。

瓶颈并没有消失。它从发现漏洞转移到了信任结果，这对它来说是一个更好的位置，因为这才是人类判断真正起作用的地方。但它仍然是一个瓶颈，忽视这一点就会导致你输出一个错误的"没问题"。

使这一切行之有效的实践并非新事物。可复现的故障、真正的预言机以及细致的分类，正是过去十五年里将模糊测试从研究课题转变为标准实践的相同实践。工具是新的。实践不是。

工具变化的速度有多快是一个悬而未决的问题。Nicholas Carlini，审慎且曾经自己也是怀疑者，……，尽管他仍保持很大的误差范围。如果生成方面的提升如此之快，判断方面也必须跟上，否则产出与实际验证之间的差距只会扩大。

对于以太坊所依赖的系统来说，这才是关键部分。代理让我们能够覆盖比手工多得多的领域。作为交换，它们要求我们更加审慎地判断，处理数量庞大得多的听起来自信的声明。这是一个值得的权衡，只要你记得判断才是真正的产品。

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