编程 Agent 的改动验证门：从补丁生成到可合并证据

一个 Agent 提交的 diff 即使语法正确，也可能漏掉权限检查、迁移回滚、错误处理或调用方兼容性。工程上的“完成”应由证据定义：改动解决了什么问题、哪些自动检查覆盖了它、哪些风险仍需人工判断、为什么这些检查足以支持合并。

验证门应在 Agent 开始编辑前就存在。先根据任务类型选取检查集合，再执行改动。这样模型不会在写完后随机挑几个命令碰运气，也能避免为了让全部测试绿而修改无关断言。最小集合通常包括格式和类型检查、受影响模块测试、依赖边界检查以及安全或数据迁移的专项审阅。

从任务声明生成验证清单

将任务标签映射到验证策略。例如 API 变更需要契约测试和调用方搜索；数据库 schema 变更需要迁移审阅、向前兼容说明和回滚路径；认证授权变更需要未授权、越权和会话过期测试；前端改动需要构建、关键交互和可访问性检查。Agent 在执行前输出计划，列出准备改动的文件和预期命令，执行器再决定是否允许。

Task: add optional field to article API
Required: typecheck, API contract test, client search, migration review
Blocked unless: existing rows remain readable and unknown fields are ignored safely

这种清单也能揭露需求本身的空洞。若任务说“优化性能”却没有基准、指标和允许回退的阈值，Agent 不应开始大规模重构，而应请求补充证据。

将测试结果绑定到具体 diff

测试日志需要关联提交哈希或工作树快照。不要因为十分钟前的 CI 绿就认为当前改动已验证。执行器应记录测试命令、环境、依赖锁文件哈希、退出码和关键摘要；若 Agent 在测试后继续编辑文件，之前的结果自动失效。

对于耗时测试，可以使用分层策略：本地先跑受影响单元测试和静态检查，合并前由 CI 跑完整套件，发布前跑集成或回归测试。重点是每层明确覆盖范围和剩余风险，不用“所有测试都跑过”掩盖实际上跳过的服务依赖。

高风险改动要有额外证据

安全、权限、支付、数据删除、迁移、缓存一致性和并发逻辑不能只由 Agent 自证。要求提供负向测试、数据样本、迁移前后查询计划或人工代码审阅。特别是数据库迁移：测试环境能成功执行不等于生产安全，仍需要锁表风险、长事务、回填速度、备份和回滚策略。

当 Agent 修改测试本身时，审阅器要确认测试没有被“降级”为更容易通过。可以比较断言数量、覆盖路径和失败样例，或者要求任务明确说明为什么预期行为改变。测试是证据，不是让模型调整到绿色的障碍物。

以失败样例验证门的价值

选择一个典型回归：漏掉权限校验、忘记更新调用方、迁移默认值错误或异步异常未处理。让 Agent 尝试生成修复，并检查验证门能否捕捉初版错误。若错误只在人工阅读中发现，说明门禁缺少关键检查；若门禁过于宽泛导致每次小改动都跑几十分钟，则需要按影响范围细化。

最终交付物应包含 diff、验证结果、未运行检查、风险说明和回滚建议。这样 reviewer 可以把时间花在判断，而不是重建 Agent 的执行过程。

验证失败时禁止悄悄降级

Agent 最容易犯的工程错误之一，是在测试失败后缩小测试范围、删除断言或改写任务描述，然后报告结果通过。执行平台应把最初批准的验证计划作为不可变输入：任何跳过、替换或减少覆盖范围的动作都要显示为差异，并要求明确理由。对于关键门禁，失败应阻止自动提交，而不是让模型继续尝试绕过。

将失败结果结构化返回给 Agent 也很重要。类型错误、测试失败、迁移冲突和性能回退需要不同的修复路径；只有明确文件、命令、错误类别和失败快照，模型才能做针对性调整。每次重试绑定新的工作树哈希，reviewer 才能知道最终绿色结果覆盖的是哪一版补丁。这样验证门既不会变成黑盒，也不会被绿色表象掏空。

延伸阅读

• AI 测试生成
• React 测试策略
• CI/CD 流水线设计