不是写完再查，是边写边查：执行过程中的持续反馈

有了测试先行和 Trophy 测试，你建立了验证的锚和闸门。但还有一个时间维度的问题：什么时候验证？

如果等 Agent 写完所有代码再跑测试，你可能面对的是几十个失败的测试用例，每个失败都指向不同的问题。追溯和修复这些问题的成本很高，因为错误可能在 Agent 的 agentic loop 中早期就发生了，后续的代码都建立在一个有偏差的基础上。

更有效的方式是在执行过程中持续验证。Agent 每完成一个小步骤，立即运行相关的测试。如果测试失败，立刻修复，在偏差扩散之前纠正。这就是红-绿-重构的内环：写一个测试（红），写代码让它通过（绿），重构代码保持质量（重构），然后进入下一个测试。

持续反馈的价值在于缩短偏差的存活时间。在第一章中我们分析过：Agent 在长链推理中会逐渐偏离早期决策。如果一个偏差在第 5 轮循环中产生，到第 50 轮才被发现，那么中间 45 轮的产出可能都需要推倒重来。如果偏差在第 5 轮就被测试捕获并纠正，影响范围被限制在最小。

阶段闸门是持续反馈在更大粒度上的体现。进入编码阶段之前，必须存在机器可读的验收标准和至少一个 Trophy 测试的雏形。进入集成阶段之前，所有模块级测试必须通过。进入合并阶段之前，所有 Trophy 测试必须通过。每个阶段的闸门定义了明确的前置条件，Agent 只有在满足条件后才能推进到下一阶段。

如果测试在某个阶段揭示了规约的歧义或缺口，流程回退到规约阶段。暂停编码，更新规约，经审确认后再继续。这种回退机制确保问题在源头被修复，而非在下游被绕过。