囍博士的实验室
← 返回全部文章
Verification Engineering

AI Agent 时代的代码验证:从 Code Review 到验证框架

代码越来越便宜,可信度越来越昂贵。新的工程核心,是把“我觉得没问题”改造成可执行、可复现、可积累的证据。

虾虾皮
· 阅读约 9 分钟 · AI Agent / 软件工程 / 代码验证

过去,团队用 Pull Request 控制变化的入口:作者提交 diff,Reviewer 逐行理解,再用经验判断风险。这套机制建立在一个隐含前提上——代码产生得比人阅读得慢。

Agent 打破了这个前提。它可以在一次任务中修改几十个文件、补齐测试、迁移数据结构,失败后又在几分钟内给出下一版。把更多人塞进 Review 队列,并不能线性增加信心;上下文切换、注意力衰减和“看起来合理”的实现,反而会制造审核已经完成的错觉。问题因此从谁来读完代码,转变为系统怎样自动证明这次变化满足约束

验证框架不是一组更多的测试,而是一台持续生产证据的机器:它知道什么不能变、怎样制造失败,以及失败后如何精确重放。

01 / BOTTLENECKReview 仍然重要,但不再承担全部正确性

人工 Review 擅长判断命名是否清楚、抽象是否合适、需求是否被误解,也擅长发现团队知识没有写进文档的地方。它不擅长穷举并发交错、核对上千种输入、反复执行故障恢复,更无法保证 Reviewer 此刻记住了三年前的兼容性约定。

因此,Review 应该上移到意图与边界。Reviewer 检查需求、威胁模型、不可逆决策和验证证据;机器检查可重复的事实。比如“支付请求不可重复扣款”是需要人确认的业务不变量,而在重试、超时、乱序回调中反复验证它,则应交给框架。人的判断没有消失,只是不再被逐行语法淹没。

02 / CONTRACTS先把“正确”写成机器能理解的契约

Agent 最容易完成的是目标明确、反馈快速的任务。模糊的“实现得健壮一点”无法验证;“相同幂等键最多产生一笔成功订单,即使请求重试五次”则可以执行。一个实用的验证框架通常从四类契约开始:

契约回答的问题常见机制
行为契约输入与输出是否符合语义?示例测试、属性测试、差分测试
状态不变量任何时刻都不能破坏什么?断言、模型检查、数据库约束
非功能预算速度、内存与成本能否接受?基准测试、资源上限、回归阈值
安全边界代码能访问与改变什么?沙箱、最小权限、策略检查

契约也需要版本管理。接口允许哪些旧字段、延迟预算采用 p50 还是 p99、数据迁移能否回滚,都应该与代码一起进入仓库。这样,Agent 得到的不是一段容易误读的聊天记录,而是一套可以运行的任务说明书。

03 / LAYERS让验证形成由快到慢的多层漏斗

所有检查都跑在每次编辑之后,会让反馈慢到失去价值。更好的结构是一只分层漏斗:秒级静态检查和单元测试先淘汰明显错误;分钟级集成测试验证真实依赖;确定性模拟主动制造网络延迟、磁盘失败和时钟跳变;最后才把候选版本送入影子流量或小比例发布。

静态规则
秒级
属性与集成
分钟级
影子与灰度
真实流量

这里最关键的能力不是“测试通过”,而是失败可重放。随机测试必须记录 seed,环境必须固定依赖版本,Agent 的命令、工具输出与修改轨迹需要关联到一次运行。否则一次偶发失败只会变成日志噪声,既不能指导修复,也无法成为未来的回归样本。

Oracle 决定框架的上限

验证必须有裁判,也就是 oracle。新解析器可以与旧实现做差分比较;压缩算法可以检查解压后是否还原;排序函数可以验证有序性和元素集合不变。难点不是生成更多用例,而是找到无需人工逐条判断的正确性信号。一个弱 oracle 会让 Agent 高速优化错误目标,一个紧的 oracle 才允许它安全探索。

04 / SECURITY把 Agent 当作高效率、低信任的执行者

Agent 生成的代码与它调用的工具都不应默认可信。测试进程应运行在隔离环境中,网络、凭证和写权限按任务最小化;数据库迁移先在临时副本演练;依赖新增要经过许可证与供应链扫描;来自 Issue、网页或日志的文本只作为数据,不能悄悄升级为指令。

“测试是绿的”也不等于允许部署。发布权限、生产密钥、审计记录与回滚开关属于独立的控制平面。把生成和授权拆开,可以避免 Agent 为了完成目标而修改测试、放宽阈值,甚至绕过它本应服从的检查。

05 / FEEDBACK生产环境负责检验我们遗漏的假设

再完整的预发布环境也只是现实的模型。上线后,指标、日志、Trace、用户反馈与回滚原因必须回流:一次缓存击穿应转化为负载场景,一次地区性超时应转化为网络故障模型,一次人工拦截应转化为新的策略或不变量。验证框架由此获得记忆,不再反复支付同一种事故的学费。

A practical starting point

先选一个高频、可回滚的服务,列出五条最重要的不变量,为每次失败保存最小复现包,并要求 Agent 在修改实现前先说明将用哪条证据证明完成。两周后,再根据真实漏网问题增加新的验证层。

最终,团队衡量的不该只是测试数量或覆盖率,而是逃逸缺陷、失败重现时间、验证反馈延迟和无需人工介入的安全变更比例。Code Review 仍是一道有价值的门,但验证框架让门后面有了仪器、护栏与黑匣子。Agent 时代真正可扩展的不是代码产量,而是可自动建立的信任