EVMbench解读：AI Agent如何检测、修复并利用智能合约漏洞

摘要

OpenAI 与 Paradigm 发布的 EVMbench，不再只让模型阅读代码后输出一段安全报告，而是把 Agent 放进可执行的区块链环境，分别评测漏洞检测、补丁修复和端到端利用能力。基准收录 40 次审计中的 117 个高严重度漏洞，并用确定性交易回放、链上验证和受限 RPC 构建可复现评分。本文分析三种评测模式、Harness 设计、结果差异及其对安全研发流程的启示。

背景：为什么智能合约需要可执行评测

智能合约控制大量链上资产，错误通常不可通过传统运维修复，攻击又能在短时间内完成。只评测模型能否解释漏洞，无法证明它能在真实仓库中定位问题、修改合约并保持业务行为，更无法判断它是否能将漏洞转化为完整攻击链。

EVMbench 从公开审计竞赛和 Tempo 区块链安全审计中整理任务。OpenAI 官方材料称，数据包含 117 个经筛选漏洞，来自 40 次审计。团队复用了已有概念验证与部署脚本；缺少材料时则手工补充。每个任务不仅要有已知答案，还必须能在隔离环境中稳定复现。

这使评测对象从"生成安全文本"转向"在状态化系统中采取可验证行动"。

技术要点一：Detect、Patch、Exploit评测不同能力

Detect：覆盖率比发现第一个问题更重要

Detect 模式要求 Agent 审计整个合约仓库，按真实漏洞召回率和相关审计奖励计分。难点不是找到一个显眼缺陷，而是持续搜索不同模块、理解跨合约调用并避免过早停止。

官方观察到，Agent 有时识别出一个问题后就结束任务。这说明安全审计需要显式的覆盖策略：维护已检查合约清单、枚举信任边界、追踪权限与资产流，并在提交报告前进行负向确认。

Patch：修复漏洞还要保留原有功能

Patch 模式要求 Agent 直接修改脆弱合约。评分同时检查漏洞是否消除、项目能否编译、正常功能是否保持。单纯删除危险路径或加入过强限制，可能让攻击测试通过，却破坏协议语义。

OpenAI 在构造任务时确认漏洞可被利用，并确保存在不会破坏编译的缓解方案。对工程团队而言，这类评测比补丁相似度更接近真实合并要求：安全修复必须同时满足回归测试、接口兼容与资产不变量。

Exploit：目标明确，反馈闭环最强

Exploit 模式把合约部署到本地链，要求 Agent 完成端到端资金抽取。评分器通过程序化交易回放和链上状态验证结果。GPT-5.3-Codex 通过 Codex CLI 在该模式取得 71.0%，而官方给出的 GPT-5 结果为 33.3%。

值得注意的是，Agent 在 Exploit 上表现最好。其目标非常清晰：持续尝试，直到资金被转移；每笔交易的成功、回滚和余额变化都提供强反馈。Detect 和 Patch 的完成条件更开放，Agent 更难判断"是否已经找全"以及"修复是否保持全部意图"。

技术要点二：Rust Harness如何保证可复现性

EVMbench 使用 Rust Harness 部署合约、确定性重放 Agent 交易，并限制危险 RPC 方法。Exploit 任务运行在隔离的本地 Anvil 环境，不连接真实网络；所用漏洞是历史公开问题。

这几个设计共同解决了安全评测的核心矛盾：

Agent 必须拥有真实执行能力，否则无法验证攻击链；
执行又必须与真实资产、公共 RPC 和外部账户隔离；
相同动作必须可以重放，才能比较不同模型和 Harness；
评分必须读取链上结果，而不是依赖模型自述"攻击成功"。

团队还为 Exploit 编写自定义 Grader，并主动红队测试评分环境，修补可能被 Agent 绕过的路径。自动化审计 Agent 也被用于检查任务环境的健壮性。

研发视角：评测结果揭示了什么

第一，明确、可执行的目标会显著改善 Agent 行为。余额变化和交易回执比自然语言评分更低歧义。内部安全任务应尽量构建机器可验证的完成条件。

第二，检测、修复与利用不是同一种能力。优秀的攻击规划不代表具备高召回审计能力；能找到漏洞也不代表能写出兼容补丁。采购或选型时不应把单一"安全能力分数"当作完整结论。

第三，Harness 是评测的一部分。RPC 权限、链状态、时间限制、编译器版本和测试覆盖都会改变最终结果。报告模型分数时，应同步公布环境镜像、工具权限、重试策略和资源预算。

第四，防守方需要利用同样的执行闭环。只让 Agent 生成审计意见价值有限；更有效的流程是让它复现漏洞、生成最小测试、提交补丁，并由独立验证器重新执行攻击。

实践建议

将智能合约安全流程拆成 Detect、Reproduce、Patch、Verify 四个阶段，分别记录结果。
为关键资产定义链上不变量，例如余额守恒、权限边界和清算条件。
在本地链或隔离 Fork 中运行 Agent，禁止连接真实钱包和生产 RPC。
限制 RPC 方法、目标地址和网络出口，使用一次性账户与测试资产。
对补丁同时运行攻击回归、正常业务测试、模糊测试和静态分析。
让第二个 Agent 或确定性脚本验证第一个 Agent 的结论，避免自评。
记录交易序列、编译器、依赖、Gas、初始链状态和随机种子，保证重放。
统计漏洞召回率、误报率、修复成功率、功能回归率及人工审查成本，而非只看总分。

风险与限制

EVMbench 不能覆盖真实智能合约安全的全部复杂度。样本主要来自 Code4rena 审计竞赛，经过长期实战审查的大型协议可能更难。Detect 模式以人类已知漏洞为真值；Agent 报告额外问题时，目前难以自动判断是真正的新发现还是误报。

Exploit 交易在评分容器中顺序重放，因此依赖精确时序、抢跑或复杂并发的攻击不在范围内。环境使用干净的本地 Anvil 链，不是主网 Fork，目前也只支持单链；部分场景需要 Mock 合约。

这项能力具有明显双重用途。研发团队应把高能力模型部署在授权、隔离、可审计的环境中，并将成果优先用于修复与防御，而不是把可执行利用流程暴露给不受控系统。

参考来源

OpenAI：Introducing EVMbench
https://openai.com/index/introducing-evmbench/