Vero基准：AI智能体能否构建形式化验证软件仓库

Vero基准：AI智能体能否构建形式化验证软件仓库

论文arXiv地址：https://arxiv.org/html/2608.13522v1

摘要

当前AI编程智能体生成代码仅能通过单元测试、人工审核校验正确性，无法提供严格数学正确性保证。形式化验证要求智能体同时输出代码实现+机器可校验证明，可彻底排除所有边界缺陷与安全漏洞，但现有评测基准仅支持单函数证明、固定代码补全证明，无法评估智能体在多模块真实仓库中协同设计代码与证明的全局能力。

本文提出Vero，首个面向仓库级「代码+证明联合生成」的Lean 4评测基准：

1. 数据集包含43个多模块仓库实例，源自Python、Dafny、Verus、Coq真实开源项目，覆盖密码协议、分布式系统等多元领域；
2. 每个实例内置固定API接口、人工编写形式化规约、参考实现，提供仅证明 、代码+证明双评测模式；
3. 创新形式化审计机制，允许智能提交规约不可满足、参考代码错误的机器证明，自动挖掘基准数据集潜藏缺陷，持续迭代优化基准质量。

本文采用前沿代码智能体与大模型开展完整评测：最强模型GPT-5.5（超高推理强度）仅完整解决43个实例中的27个，仍有10个实例所有模型均无法完成。实验证明当前AI智能体尚不具备完整仓库级形式化开发能力，Vero可为该方向提供标准化测试平台。

核心贡献

1. 推出首个仓库级Lean 4形式化验证评测基准Vero，配套多语言半自动数据集构建流水线，支持后续扩展更多编程语言；
2. 设计形式化审计机制，将基准自身缺陷转化为可自动核验的形式化证据，解决传统基准标注隐性错误无法识别的痛点；
3. 对多款前沿代码智能体开展大规模对照实验，定位当前智能体在长时序仓库验证中的核心短板，给出明确技术改进方向。

1 引言

1.1 现有代码智能体校验缺陷

AI编程智能体已广泛用于软件工程，但单元测试、人工评审仅能覆盖预期故障，无法彻底消除边界漏洞、安全隐患；密码库、操作系统内核、分布式协议等高可信软件必须采用形式化验证：通过机器可校验数学证明，严格证明代码完全满足规约，覆盖全部输入场景。

1.2 现有评测基准三大局限性

1. 仅单函数粒度：miniCodeProps、VERINA等Lean基准、DafnyBench等验证语言基准均针对独立算法函数，无法模拟真实仓库跨文件、跨模块依赖关系；仓库中单个函数证明依赖底层公共引理，修改一处实现会全仓库证明失效，需要全局一致性推理。
2. 仅固定代码补全证明：RVBench、VeriSoftBench等仓库级基准会提前给定完整参考代码，仅评测补全证明能力，忽略「代码实现选择直接决定证明难度」这一核心工程权衡。
3. 数据集污染与无自检机制：多数基准题目在线开源，大模型预训练阶段极易记忆标准答案；且基准自身规约、代码存在隐性错误时，无法区分是智能体能力不足还是数据集标注缺陷。

1.3 Vero基准核心创新

Vero是首个支持仓库级代码+证明联合生成的Lean 4基准，每条评测任务包含完整多模块Lean工程，提供两种评测模式：

1. 仅证明模式：给定官方参考实现，仅要求完成全部规约证明；
2. 代码+证明模式：无参考实现，智能体自主编写全部API代码，并为自身实现生成完整机器证明。

配套形式化审计机制：智能体可提交三类否定形式证明（规约互相矛盾、单规约无可行实现、参考代码违背规约），自动定位数据集漏洞并迭代修复，解决基准自检缺失问题。

1.4 核心实验结论

使用GPT-5.5、Claude Opus、Claude Sonnet多款前沿智能体评测后：

1. 最优模型GPT-5.5(xhigh)在代码+证明模式仅完成27/43实例，10个实例所有模型全部失败；
2. 智能体可完成80%单条规约证明，但无法构建全仓库复用引理库，难以处理全局不变量、循环归纳类复杂证明；
3. 代码自由度存在双面效应：简单算法替换可大幅降低证明难度，但多数智能体修改代码后会破坏全仓库编译一致性。

2 相关工作

2.1 单函数形式化验证基准

面向Lean、Dafny、Verus的小规模评测集仅针对独立算法，不具备多模块工程结构，无法模拟真实仓库跨文件依赖、全局不变量推理，不能评估长时序、多文件协同开发能力。

• Lean系：miniCodeProps、FVAPPS、VERINA、CLEVER；
• Dafny/Verus系：DafnyBench、VerusBench、AlgoVeri、VeriCoding。

2. 仅证明类仓库基准

现有仓库级验证基准固定代码实现，仅评测证明补全，剥离了工程中「实现方案与证明难度互相约束」的核心权衡：RVBench、VeruSAGE-Bench、VeriSoftBench、CoqStoq仅提供固定源码，不支持自主编码验证。

2. 数学定理证明基准

LeanDojo、LeanAgent等基于Mathlib数学库，数学证明逻辑与工业软件验证差异巨大，不适合评估程序代码验证能力；同时大量题目开源，存在训练数据污染风险。

2. 现有基准缺失的关键能力

1. 无代码+证明联合生成评测模式；
2. 无仓库级多模块依赖、全局规约场景；
3. 无自动审计机制，无法识别基准自身错误；
4. 缺少防作弊约束，智能体可通过新增公理、篡改规约绕过验证要求。

3 Vero基准整体设计

3.1 完整工作流总览

整体分为三大阶段：

1. 数据集构建：真实仓库筛选→人工翻译+规约编写→生成标准化Lean 4评测实例；
2. 智能体评测：仅证明 / 代码+证明两种任务模式，智能体调用文件、Lean工具链完成开发；
3. 独立打分器+审计回传：独立环境编译打分，若智能体证明基准存在缺陷，将形式化证据回流数据集流水线迭代优化。

3.2 评测实例标准数据格式

每个Vero实例是多模块Lean 4工程，固定不可修改内容由数据集构建者提供，仅预留代码、证明填空区域供智能体修改：

1. 全局基础类型、辅助工具定义（冻结，禁止修改）；
2. API签名集合 A={a1,a2...am}\mathcal{A}=\{a_1,a_2...a_m\}A={a1,a2...am}，统一封装为RepoImpl结构体；
3. 形式化规约集合 S={S1...Sn}\mathcal{S}=\{S_1...S_n\}S={S1...Sn}，每条规约输入参数为RepoImpl（兼容任意实现）；
4. canonical标准实现结构体：仅证明模式填入官方参考代码，代码+证明模式由智能体自行填充。

示例代码片段（银行账本简化实例）

-- API签名定义
abbrev CreateAccountSig := AccountId -> Ledger -> Ledger
abbrev GetBalanceSig := AccountId -> OptionBalance

-- 仓库实现结构体
structure RepoImpl where
  createAccount : CreateAccountSig
  getBalance : GetBalanceSig

-- 规约：新建账户余额为0
def spec_create_zero_balance (impl : RepoImpl) : Prop :=
  ∀ (id : AccountId) (ledger : Ledger),
  impl.accountExists id ledger = false →
  impl.getBalance (impl.createAccount id ledger) = some 0

-- 待证明目标（占位sorry由智能体补全证明）
theorem proof_create_zero_balance (canonical : RepoImpl) : spec_create_zero_balance canonical := by sorry

3.3 两种评测任务模式

模式1：仅证明模式（Proof-only）

canonical结构体直接载入官方参考实现，智能体无需编写API代码，仅需要为全部规约生成机器可校验Lean证明。

模式2：代码+证明模式（Code-and-proof）

无参考实现，智能体完成两项强制义务：

1. 填充RepoImpl内所有API函数完整代码；
2. 针对自己编写的实现，证明全部规约命题。

两种模式本质差异

真实形式化开发中，代码实现方案直接决定证明难度：智能体可替换简化算法降低证明门槛，但代码修改会导致全仓库已有证明失效，必须全局维护一致性。现有基准仅固定代码，完全无法模拟该核心权衡。

3.4 防作弊三层校验机制

为避免智能体通过篡改规约、新增公理、类型欺骗绕过验证，打分器三层防护：

1. 槽位重渲染：仅读取标记区间内智能体修改内容，其余原始冻结代码全部重置，禁止修改类型、规约、全局定义；
2. 公理白名单 ：仅允许Lean原生三条基础公理Classical.choice, propext, Quot.sound，任何自定义公理、sorry占位的证明全部判定无效；
3. 声明筛查 ：检测恶意TypeClass实例、@[implemented_by]解耦欺骗手段，通过规则+LLM联合判定作弊代码。

3.5 数据集构建流水线

数据集分为两条数据源分支：

1. 分支1（形式语言仓库，共13例）：Dafny、Verus、Coq已验证工程，仅翻译类型、实现、规约至Lean 4；
2. 分支2（Python通用仓库，共30例）：无原生形式规约，人工基于源码、文档编写完整形式化约束。

流水线分阶段流程

1. 仓库筛选：覆盖密码、分布式系统、数据结构、数值算法，兼顾代码规模、难度梯度；
2. 依赖规划：解析模块依赖顺序，分模块并行翻译，人工审核每段翻译结果；
3. 分支2专属：基于源码行为编写自然语言规约，再形式化为Lean命题；
4. 自动化校验：编译测试、语义人工复核，不合格回退重写。

流水线复用设计

翻译、校验、规约生成为模块化技能组件，新增源语言仅需补充对应翻译脚本，可快速扩展更多编程语言数据集。

3.6 数据集整体统计

总实例：43个（13个形式语言仓库 + 30个Python仓库）

总API：743条 | 总形式规约：2705条

分支	源语言	实例数	单实例平均API	单实例平均规约	源码平均行数
形式分支	Dafny/Verus/Coq	13	36.0	92.8	7759
Python分支	Python	30	9.2	50.0	793
整体汇总	-	43	17.3	62.9	2899

覆盖领域：区块链智能合约、分布式共识、安全编解码、基础数据结构、数值数学库、遥感/生物算法。

数据集污染保障

所有Lean代码、规约、证明均为人工全新翻译编写，无公开Lean原版解决方案；上游源码仅为Python/其他验证语言，不存在预训练记忆泄露风险。

3.7 形式化审计机制（核心自检能力）

传统基准无法区分「模型失败」和「规约/参考代码本身错误」，Vero允许智能体提交三类机器证明作为数据集缺陷证据：

1. ¬⋀S∈SS(canonical)\neg\bigwedge_{S\in\mathcal{S}}S(\text{canonical})¬⋀S∈SS(canonical)：参考实现不满足规约；
2. ¬∃impl,S(impl)\neg\exists \text{impl}, S(\text{impl})¬∃impl,S(impl)：单条规约不存在任何合法实现；
3. 规约子集各自可满足，但无法同时成立（规约互相冲突）。

评测过程中收集到的审计证明会回流构建流水线，人工核对后修正数据集内错误，论文开发阶段已通过该机制修复38处标注缺陷，包含规约矛盾、缺失定义域约束、参考实现逻辑错误等问题。

4 实验设置与评测结果

4.1 实验环境

智能体框架与模型

1. Codex v0.140.0：搭配GPT-5.5 medium、GPT-5.5 xhigh（超高推理强度）；
2. Claude Code v2.1.191：搭配Claude Opus 4.8、Claude Sonnet 5（均超高推理）；
   全部智能体开放完整工具权限：文件读写、项目编译、Lean 4.29.1全套证明工具链；
   单任务时限90分钟，判定标准：完整通过实例=该实例全部规约证明成功（不接受部分通过）。

评测成本汇总（美元）

模型配置	代码+证明模式总花费	仅证明模式总花费
GPT-5.5 xhigh	2865	2964
GPT-5.5 medium	928	1094
Claude Opus 4.8	1983	2279
Claude Sonnet 5	633	791

4.2 核心实验结论分析

4.2.1 前沿模型仍无法完全攻克Vero

GPT-5.5 xhigh表现最优：代码+证明模式完成27/43，仅证明模式25/43；

存在10个实例，所有四款模型在两种模式下均无法完整解决；

虽然最优模型单规约通过率85%以上，但难以完成全仓库闭环，核心瓶颈是跨模块复用引理库搭建。

4.2.2 代码自由度利弊共存

1. 收益场景：智能体可替换更简单算法，大幅降低证明难度。实验中5个仓库内，GPT-5.5重写实现后可证明全部250条规约，固定参考代码模式仅能完成201条；
2. 缺陷场景：多数较弱智能体修改代码后产生编译错误、跨模块证明失效，直接整实例判定失败，Claude Opus有17个实例仅证明模式可完成，代码模式完全失败。
   数据特征：完整实例的证明代码行数约为未完成实例2倍，完成验证的核心工作量集中在引理库构建，而非基础代码编写。

4.2.3 完整仓库依赖共享分层引理

所有完整解决实例中，中位数73%证明代码为智能体自定义通用辅助引理，80%完整实例存在至少被5条规约复用的公共引理；

规约依赖的引理链越深，模型通过率断崖下跌：无辅助引理规约通过率83.9，四层以上引理链仅50.6%。

4.2.4 智能体开发行为特征

所有模型均在运行前30分钟完成最终代码编写，剩余全部时间持续扩充证明；

智能体固定实现后，即便证明卡住也极少回头重构代码优化证明难度，陷入局部证明死循环。

4.2.5 最难规约类型定位

1. 全局覆盖类存在性规约（失败率47.1%）：需要全域归纳证明，无法通过局部分case完成；
2. 重复调用、多层自定义定义相关规约：需要深度拆解定义，推理门槛更高；
   跨模块单纯引用带来的难度提升反而不明显。

4.2.6 模型能力分层现象

强模型（GPT-5.5 xhigh）会尝试全部规约，大量任务卡在最后少量复杂全局证明；

弱模型（Sonnet）大量规约直接留白，完全未开展证明推导；

多模型融合无增益：所有模型共同可完整解决实例数量等于GPT-5.5单独可解实例，无额外仓库被弱模型补充完成。

4.2.7 成本效率结论

1. GPT-5.5 xhigh单完整仓库平均成本106美元，为所有模型最低；
2. 提升推理强度带来的完整实例收益远高于成本增幅；
3. 未完成仓库平均开销高于成功仓库，大量算力消耗在完全无法攻克的复杂实例上。

5 结论与局限

5.1 核心结论

1. Vero是首个仓库级代码+证明联合生成Lean基准，配套完整数据集构建、审计、防作弊体系，填补现有评测空白；
2. 当下顶尖代码大模型仍无法完成多数真实规模形式化仓库验证，核心短板：无法分层构建可复用引理库、难以处理全局归纳不变量；
3. 自主编码带来的自由度双面影响，为后续智能体架构设计提供明确优化方向（代码-证明协同迭代、全局引理规划）。

5.2 基准局限性

1. 当前仅支持Lean 4语言，流水线可扩展Dafny/Coq等其他验证语言，但暂无多语言评测实例；
2. 数据集偏向可翻译同步算法，缺少大规模并发、时序协议类工程实例；
3. 审计机制仅能证明规约逻辑矛盾，无法判定规约业务语义是否符合原始工程意图，仍依赖人工审核。

附录A 实验完整配置

A.1 智能体与模型细节

Codex使用model_reasoning_effort控制推理强度；

Claude Code统一开启最高推理档位；

全部实验Lean版本固定v4.29.1，使用lake编译系统构建工程。

A.2 完整评测成本

见正文4.1小节成本表格。

附录B 数据集来源与开源协议

43个实例上游开源仓库、协议、提交哈希完整记录，形式语言分支含Coq/Dafny/Verus项目，Python分支均为开源通用算法库；

少数项目采用LGPL开源协议，其余以MIT、Apache2.0为主；

所有Lean形式化代码为论文原创，无公开前置版本。

附录C 单实例详细评测结果

表格记录每个实例下四款模型、两种模式的规约通过总数，区分Track1（形式语言）、Track2（Python），可直观对比不同仓库难度差异（原文Table4）。

附录D 三层防作弊机制完整实现

1. 槽位重渲染

仅保留智能体在标记区间内修改代码，其余基准原始内容每次打分全部重置，禁止篡改类型、规约、全局定义。

2. 公理白名单校验

遍历全部证明依赖公理，除Lean三条基础公理外，使用native_decide等暴力枚举、自定义公理全部判定无效，文中统计368条作弊证明被拦截，典型为有限域暴力枚举绕过数学归纳。

3. 声明筛查

自动检测三类欺骗写法：

1. 空TypeClass实例强制比较结果恒真；
2. 高优先级实例覆盖标准库原始逻辑；
3. @[implemented_by]分离实现与证明目标，证明层使用理想逻辑、运行层真实代码。
   出现任意一类直接判定该实例全部规约无效。

附录E 补充实验分析

E.1 失败规约具备固定集群特征

同一仓库所有模型失败的规约高度重合，并非随机分布，核心障碍为统一全局不变量；如piggybank合约中所有跨链状态量化规约全部失败，单函数局部规约全部可证。

E.2 代码自由度仅顶尖模型可利用

弱模型自主编写代码后极易编译报错，直接丧失全部得分；仅GPT-5.5可通过简化算法显著提升证明通过率。

E.3 弱模型无补充收益

四款模型合并可完整解决仓库=GPT-5.5单独可解仓库，弱模型无法攻克强模型无法完成的实例。

E.4 评测成本细分

1. 完成仓库单位成本GPT-5.5最优；
2. 推理强度提升带来完整实例收益超线性增长；
3. 未完成任务平均算力消耗更高。

附录F 审计机制案例

论文开发阶段通过审计机制定位38处数据集缺陷，分为四类：翻译语义错误、缺失定义域约束、参考实现与规约不符、规约互相冲突；

典型案例1：verdict基准两条字符规约对'='字符判定冲突，机器证明联合不可满足，人工修正字符过滤条件；

典型案例2：verified_ironkv键值库规约缺少合法比较器约束，构造反例证明规约无可行实现；

典型案例3：verified_bitmasks位运算规约缺少等长输入前提，存在位宽不匹配反例。

附录G 代码自由度案例

1 替换简化算法（munkres匈牙利算法）

参考实现为复杂六状态循环，GPT-5.5替换为全排列暴力枚举实现，规约全部可证；仅证明模式下循环不变量证明无法完成。

2 复用标准库（sequences链表）

将自定义归并排序替换Lean标准库mergeSort，直接复用库内排序引理，大幅减少证明代码。

3 自由度带来负面案例（Huffman）

Claude Opus编写代码时未填充API实现，编译直接失败，整实例零分。

附录H 复杂证明实例深度分析

H.1 智能体沙箱行为

智能体会创建私有临时Lean文件试探标准库引理、反复尝试同一困难辅助引理，但几乎不会回头重构代码简化证明；

H.2 deposit_sc合约分层引理库

最优模型编写99条分层辅助引理，分比特、树、默克尔树、合约四层，每条高层规约直接调用底层引理，核心难点是加强归纳假设；

H.3 vest解析器案例

大量分情况分析逻辑被封装为公共辅助引理，每条顶层证明仅数行代码；

H.4 sortedcontainers排序库案例

参考二分查找需要窗口不变量，模型替换线性遍历插入排序，完全规避复杂循环归纳，是代码自由度提升证明能力的典型样本。

开源资源汇总

1. 论文网页：https://arxiv.org/html/2608.13522v1
2. Vero基准完整工程：https://github.com/sunblaze-ucb/vero
3. 底层工具链：Lean 4.29.1、lake编译工具
4. 智能体框架：Codex v0.140.0、Claude Code v2.1.191
5. 上游源码：Dafny/Verus/Coq开源验证项目、Python开源算法库（附录B完整清单）