---
{
  "series": "Harness工程研究：让AI Agent好用的工程实践",
  "article_index": 4,
  "topic": "验证比生成更重要：Agent的瓶颈在检查阶段",
  "created": "2026-04-25",
  "deai_score": 88.0,
  "pipeline": "series"
}
---

当具备强大基础编码能力的前沿大模型让产出逻辑尚可的代码变得极度廉价时，另一个环节的缺失却在悄悄推高系统性风险：自动断言与测试环境。可惜的是，目前构建 Agent 的主流精力仍被错误地消耗在 System Prompt 的词句雕琢上。模型偶发的高质量表现给人一种产出即刻可用的错觉，但也埋下了隐患。

前三篇讨论了 Harness 的基本价值（《Harness比模型重要》）、输入端的 Context 治理（《Context是稀缺资源》）和约束机制（《约束让Agent更好用》）。这些都是让模型"写出好东西"的前提条件。但写出来之后呢？

很多团队卡在"写代码、看一眼、手动修"的低效循环里。模型生成的偶然性拉高了系统的隐性维护成本。若跳过对任务规格的真实运行验证，追求效率的初衷会推导出相反的结果。

Agent 能力的上限取决于它对输出结果的否定能力。在 OpenHands 这种开源项目的演进中，瓶颈在于检查变更是否符合特定的仓库规范。严密的验证构成了真正的技术高墙。当代码生成已经成为几美分就能买到的工业制成品，目视确认并提交的习惯正在制造系统性风险。

### 通用审美在实战中失效

OpenHands 的数据揭示了一个现状：在学术基准上优秀的专用代码验证模型（Critic Model），进入真实生产仓库后表现极差。Anthropic 的实验显示，这类模型处理真实 Pull Request 时的 AUC 分数仅在 0.45 到 0.48 之间，基本表现不如随机猜测。

脱离了特定项目上下文的广义代码审美在实战中无效。代码评估应聚焦于逻辑运行而非单纯的语法打分或风格判断。那种依赖 LLM 左右互搏（LLM-as-a-judge）的模式，在处理深水区逻辑时正表现出明显的疲态。一个没有运行过代码的 Agent，就像是在岸上点评游泳动作的教练，它的评论可能在美学上成立，但对业务逻辑下的 Bug 毫无感知力。

更换更强的模型无法解决可靠性问题。没有针对业务逻辑构建验证线圈，更强的生成能力只会让错误隐藏得更深，导致排查的难度指数级上升。

性能增长的杠杆点在工程手段对错误的强制正视。Claude Code 的实践数据提供了直接证据：在不更换底层模型的前提下，引入 Build-and-Self-Verify Loop（规划、构建、验证、修复）的端到端机制，SWE-bench 的分数提升了 13.7 个百分点。工程约束通过高频的失败反馈，强迫模型从概率幻觉回到物理客观实相。

如果验证逻辑本身也由模型生成，模型之间可能达成幻觉共识。这种共识往往源于模型底层训练数据的共同偏差。引入确定性的硬性验证是防止概率系统脱缰的锚点。

### 建立测试支架

Build-and-Self-Verify Loop 的核心是将"运行代码并捕获报错"设为决策链路中的强校验节点。这种逻辑需要从 Prompt 中剥离，封装成独立于模型之外的物理拦截器。

在实际操作中，我倾向于引入一套 Harness。通常将设计准则和执行进度记录在文件系统中，形成一种可追踪的状态机。每当任务完成，由独立的 Evaluator 去扫描文件系统变更，不达标即触发回滚。

这实则是 TDD（测试驱动开发）在 AI 环境下的复兴。以前推行 TDD 的阻力在于编写测试本身耗费人力，现在形势反转了。人负责定义系统的边界和断言，AI 负责填充实现。开发者从编写业务逻辑的角色，向定义边界条件和验收标准的角色位移。

这种设计存在一种内在的矛盾。如果 Evaluator 也是一个 Agent，它同样会产生幻觉。Agent 往往会可靠地表扬自己的平庸输出。当验证者和生成者基于相同的偏差达成一致，系统就会陷入锁死。目前的工程解法是引入非概率工具：Linter、类型检查和单元测试。它们在支架中扮演物理底线。没有通过 Linter 的代码不具备进入下一轮评估的资格。

Agent 在自我评估时会表现出系统性的自恋。打破这种幻觉共识必须引入外部性，即那些不以模型意志为转移的编译器错误、运行时崩溃或业务逻辑断言。

### 验证逻辑的按需定制

深度 Agent 的评估标准正变得高度异构，通用的评估模版已经不再适用。我们需要针对每个具体任务点编写定制验证逻辑（Bespoke test logic per datapoint）。针对数据库迁移的 Agent，其成功标准是表结构的准确变动；重构 UI 的 Agent，成功标准则是视觉回归测试的通过率。

在大规模迁移项目中，可能会出现这种现象：为每百行功能代码配套生成两倍规模的测试逻辑。虽然这种做法看起来笨重，但它确保了代码在真实环境下的存活率。

在这种定制化逻辑下，Rubric-Based Assessment（基于量表的评估）只能作为一种基线。在涉及金融结算等场景下，必须以硬性 Hook 的形式禁止任何绕过审计模块的数据库操作。这种强制性约束属于工程常识，不应在 Prompt 中让模型去遵守。

验证逻辑的位移要求我们重新定义开发者体验。当 Agent 尝试一种错误的实现路径时，系统能否在 10 秒内告诉它哪一个断言失败了？如果反馈周期拉长到分钟级，再强的模型也会在复杂的决策树中迷失方向。

在验证环节投入的时间，会在生成和调试阶段获得回报。当验证机制足够敏锐时，即使是中等能力的模型也能通过高频反馈逐渐逼近正确解。

### 验证成本的增长

我们要面对一个工程难题：验证本身的开销正在迅速增长。当每一个生成步骤都伴随着多次单元测试、类型检查和环境重置时，推理性成本会快速上升。我的判断是，业界即将迎来一个临界点，即验证开销将超过生成开销。

这种重心的偏移会带来一种新的焦虑。我们是否在用更昂贵的资源去检查原本廉价的产出？然而这种消耗是建立信任的必经之路。在软件工程史上，高质量的 QA 投入从来不低。

另一个隐蔽的问题是过度验证带来的僵化。如果验证逻辑过于严苛，甚至规定了代码的具体实现方式而非结果，Agent 的解题空间就会被极大压缩。它会开始尝试寻找绕过测试的作弊路径，比如在单元测试中硬编码期望结果。

如果团队还没有建立起能自动运行并反馈结果的沙箱，就不要急着尝试复杂的 Multi-Agent 协作。先实现一个针对每个提交的完整流程评估：让 Agent 提交代码，运行测试，修复直至通过。只有在这个流程被证明稳定后，才谈得上更高维度的讨论。

先从写一个能打断 Agent 错误行为的硬性断言开始。如果不知道从哪里入手，去检查项目中最近一次由 AI 生成的、跑不通的代码。那一刻的挫败感就是改进验证逻辑的需求起点。

一旦自动化的验证体系搭建完成，Agent 似乎就可以独立闭环工作了。此时，原本坐在电脑前逐行写代码的工程师会发现自己无事可做。人在这个高度机械化的系统中，究竟应该退到哪里？下一篇《人机协作是光谱》将回答这个定位问题。