Loop Engineering：如何优化 AI 代码生成与验证流程

AI 辅助代码生成可以缩短生成代码所需的时间，同时增加理解和验证代码所需的工作量。本文介绍如何设计流程，以保护人的时间、注意力和判断力：改进生成待评估候选方案的流程，并组织人类评估这些方案所需的证据。

这是我们将要优化的四个循环的概述。

• 失败模式、检查与响应目录
• 包含合同、检查结果和人工审查包的示例演练

引言

AI 辅助软件开发中的两个根本挑战是：精确且完整地说明意图，以及验证生成的代码是否满足该规范。本文主要关注这个等式的第二部分：验证 AI 编写的代码。

AI 辅助代码生成可以在相同时间内产出多得多的代码。一篇涵盖超过 50 万名 GitHub 开发者的 NBER 工作论文估计，在采用后的第 21–30 周，交互式编码智能体使每周更改行数增加了 958%，创建的 PR 增加了 86%，而每周仓库发布量增加了 20%。但据估计，从最初想法到产品发布，编写和测试代码仅占约 25–35% 的时间（Bain）。更快地生成更多代码会如何影响软件开发生命周期（SDLC）的其余部分？

更快的 AI 辅助代码生成可能造成的验证瓶颈

更快、更便宜的代码生成可能在下游流程中造成新瓶颈或加剧现有瓶颈。验证变得更加繁重有五个原因：

1. 更多代码到来的速度超过了人类审查的速度。 智能体在比读完这段话更短的时间内就能生成上千行代码，而人类的阅读速度却没有变化。Osmani，Agentic Code Review。Faros 的遥测数据将高 AI 采用率与合并 PR 数量增加 98%、审查时间延长 91% 相关联。Faros 2025。这样的体量可能超出审查能力：在 Faros 更大的 2026 年数据集中，未经任何审查（无论是人工还是智能体）就合并的 PR 上升了 31.3%，作者认为这更可能是由于审查者无法跟上节奏，而非有意绕过监督。Faros 2026。

2. 错误的代码看起来仍然非常可信。 找出错误可能需要更多时间，跨文件追踪变更并将行为与需求进行比对。JetBrains–Lund 研究。在 Sonar 的 2026 年调查中，61% 的开发者认同 AI 能生成看起来正确但不可靠的代码。Sonar。METR 在 2025 年初的研究也指出，花在审查、测试和修复不可靠 AI 输出（包括开发者最终丢弃的输出）上的时间，是导致任务完成变慢的一个因素。METR 分析。

3. 理解债务。 如果团队中没有人编写过该实现，审查开始时便不具备人类作者通常会带来的理解。Osmani 将代码与人类理解之间日益扩大的差距称为理解债务，并指出阅读彼此的 diff 过去会作为副作用传播对系统的了解。Osmani，Agentic Code Review。在 Anthropic 一项针对 52 名工程师学习新库的试验中，使用 AI 辅助的人完成时间大致相同，但在后续理解测验中得分低了 17 个百分点（50% 对 67%）。Anthropic。

4. 变更更大，携带的问题更多。 Faros 将 AI 采用率与平均 PR 规模增加 154%、每位开发者的 bug 增加 9% 相关联；其更大的 2026 年数据集报告该数字为 54%。Faros 2025，Faros 2026。在一项针对 470 个开源 PR 的研究中，CodeRabbit 发现 AI 共同创作的变更每个 PR 携带的问题约为 1.7 倍。CodeRabbit。因此平均而言，每次审查可能覆盖更多变更和更多需要修复的内容。

5. 检查也不可靠。 测试和静态分析有帮助，但没有人能为他们没想到要指定的行为编写测试。当 AI 改变行为并更新数百个测试以匹配时，问题就从“这段代码正确吗？”转变为那些测试变更是否必要。Osmani，Comprehension Debt。因此，一套通过的测试可能意味着测试被重写以与代码保持一致，这就是为什么评估者的检查和预期结果需要置于构建者无权更改的范围之外。

在过去十二个月里，我们一直在开发这些方法，我们运行了自己的流水线并用它来生成代码。为了让示例代码保持简洁易懂，我们选择了说明性示例，其中一些是假设性的，而非我们自己运行的结果。本文并未报告实测的节省量；该方法旨在供你在自己的工作流中测试。

1. 终端评估

什么是终端评估？

终端评估只判断自主尝试的结果，不判断其他任何东西。给定一个任务和成功标准，AI 系统自主工作，直到它认为已经生成了满足预定义成功标准的结果。然后由评估者根据标准检查该结果。在编码工作流中，结果是一个候选方案，标准是双方商定的规格说明。判定结果可以是通过或失败、部分得分或多项得分。最终判定告诉我们结果是否满足标准，但对系统如何达到该结果一无所知。

该判定让我们可以提出两个不同的问题：

1. 能力：这个已配置的系统能否执行该任务？成功的结果表明，在受测条件下它能够做到。
2. 可靠性：它成功的稳定性如何？在可比条件下重复该任务，可以让我们估计这种稳定性。一次成功的系统与 100 次尝试中成功 99 次的系统所展现出的东西是不同的。

这两个问题针对的都是一个已配置的系统，而不只是模型本身。配置包括供应商的模型和运行框架（合起来即供应商的智能体），以及我们在其周围添加的任何东西：自定义运行框架、工具、上下文、运行限制、图或流水线。改变其中任何一项，结果都可能改变，因此必须针对新配置重新测量能力和可靠性。

为了进行公平比较，应使用相同的任务和成功标准，保持预算和重试策略可比，并纳入不成功的尝试。

同一主题的变体

基于智能体的基准测试（评估）、提示工程、规格驱动开发（SDD）和循环工程，是同一个底层过程的四种变体：给 AI 一个任务，让它自主尝试该任务，然后评估结果。每种变体强调该过程的不同部分，但都不禁止采用其他变体所强调的实践。

例如，独立评估者、强制停止条件和自动交接通常与循环工程相关联，但没有什么能阻止 SDD 方法采用自动交接。它们是否出现取决于系统的实际设计。开发者认为自己正在实施的方法论，既不保证这些实践会被纳入，也不禁止使用它们。

图 1：一个过程，四种方法。展开每种方法可查看实践和引用。共享路径包括返工、重试耗尽和升级；没有哪一条是某种方法独有的。

合作编写一致性契约

在我们的编码工作流中，人类在运行前批准各项义务，并在之后决定是否合并合格的候选方案。这些决策将人类判断置于 AI 自主工作的两端。人类和 AI 可以合作履行这两项职责。Osmani，Own the Outer Loop。

在流程开始时，人类和 AI 可以协同将意图转化为义务：代码必须做什么、保留什么、绝不允许什么。与其让人类独自编写这些义务，然后将其隔着墙扔给 AI，不如让人类和 AI 合作编写和完善它们，并在出现歧义时加以解决。我们将经批准的义务称为一致性契约。人类最终负责确保一致性契约全面表达意图。意图在一致性契约中被指定得越准确、越完整，错误就越难从评估者眼皮底下溜过。

将义务转化为检查

每项义务还需要一种评估一致性的方式。人类和 AI 在构建开始之前就制定检查、预期结果和证据要求，确定哪些可以自动检查，哪些仍需要人类判断。测试、抽象语法树（AST）检查和运行时观察可以为特定属性提供证据，并且可能足以表明所考虑的候选实现已满足一致性契约的某些义务。检查设计必须同时处理违规行为和预期行为：一个既能通过预期实现、也能通过有缺陷实现的检查，几乎说明不了什么。契约及其权威检查在有界运行期间保持固定。任何 AI 代理都不得在运行过程中悄悄更改义务或检查。相反，它可以提出更改建议，如果被接受，则需要重新运行整个流程。

评估候选实现

当构建返回一个候选实现时，控制器代码会调用一个独立评估者，使用这些检查依据契约对其进行评估。评估者位于构建循环之外。其检查、预期结果和停止规则不受构建者更改权限的约束。它记录评估了哪个候选实现、运行了哪些检查、发现了什么以及哪些仍未验证。构建者的完成消息并不决定是否合格，缺失的证据不能算作通过。独立性保护评估免受构建期间所做更改的影响；它并不能消除需求或检查覆盖范围中的缺口。

停止条件决定接下来会发生什么。满足合格要求的候选实现进入人工审查。被拒绝的候选实现连同未通过的义务和支持性发现返回构建阶段，前提是仍有重试机会。重试次数耗尽则停止运行，且没有合格的候选实现。需要人类判断的歧义或其他问题会暂停流程并提出该问题。这些决策由控制器强制执行，而不是留给构建者自行决定是否继续或宣布自己已完成。

人工审查

一旦评估器判定某个候选方案合格，人类就必须决定是否接受它。这正是运行前准备好的各项检查发挥作用的地方。凡是能够确定性验证的内容都应加以验证：测试、AST 检查与运行时观察能够解决它们所能承担的职责，而它们记录的结果就是既定事实，审查者无需重新推导。剩下的则是任何机械检查都无法裁定的主张，例如需求是否捕捉到了意图、行为是否符合产品需要，以及该变更如何融入周边系统。AI 会为每项职责汇集一个视图，将职责本身、检验它的各项检查及其结果、为满足它而生成的代码、未解决的问题以及与之相关的其他证据整合在一起，使审查者从需要判断的主张出发，而不必从头重建证据。

通过这种方式，确定性验证将人类的注意力与判断力预算引导到真正需要它们的主张上。可靠的判定让审查者能够依赖既定结果，专注于尚未解决的判断，把精力花在证据耗尽之处。这种依赖取决于检查覆盖率以及与候选方案绑定的证据，并且不确定性要像通过结果一样可见；一个薄弱的检查，或者一个能让有缺陷实现通过的检查，几乎确立不了什么。审查者仍然需要理解该变更如何融入周边系统及其后果是什么。即便 AI 无法裁定这一判断，它也能帮助汇集和审视证据。由人类决定是否合并。

一个例子：存储读取失败

考虑一个无法读取先前已保存数据的应用程序。其契约要求它报告失败并保留原始数据。一个报告了错误但用空列表覆盖数据的候选方案只满足了该职责的一半。评估器必须同时检查失败响应和已存储数据的保留情况。

随附的 演练 通过这个例子展开，其中的示例文档展示了符合性契约、可执行检查、对有缺陷候选方案的拒绝、修复以及移交人工审查。其 审查包 将需求与变更后的代码及检查结果关联起来，同时指出审查者仍需解决的问题。应用程序是否使用了被评估的代码路径？所选案例是否充分？恢复行为是否符合产品需要？该候选方案的历史仅作说明之用，并非一次记录在案的运行。

仅凭最终结果无法解释什么

当我们只衡量最终结果时，就把开发候选方案的自主过程当作一个黑箱。判定结果并不显示中间的计划、变更、检查或修正。一次成功的尝试可能毫无差错地推进；另一次可能引入若干错误并从中全部恢复。两者得到相同的成功判定。一次失败的尝试告诉我们系统未达到标准，但仅凭判定本身无法解释它在哪里或为何失败。最终判定具有 较低的诊断分辨率：它们报告结果，却让过程的大部分得不到解释。

理解这些差异需要考察中间过程，以及一个结果如何影响下一个结果。我们需要看到错误在哪里出现，它们是传播了还是被纠正了，以及这些纠正付出了多少时间和 token 代价。仅凭最终判定无法回答这些问题。更广泛的可靠性评估还会考察轨迹、鲁棒性以及失败的后果。普林斯顿可靠性研究。

思想实验：假设评估是完美的

为便于论证，假设一致性契约捕获了所有意图，且评估器和资格规则都是完美的。只有符合该完全捕获意图的代码才能被判定合格并提交人工审查。这是一个思想实验，并非对当前系统的断言。它保证的是合格候选的正确性，而非构建过程一定能在预算内产出一个合格候选。

即使有这道完美的关卡，构建过程在产出正确候选的过程中仍可能犯错、恢复并在无用功上浪费资源。更早的检测和纠正能在时间、token 和人工注意力上节省多少？更早的检测和纠正是否意味着能在给定的重试预算内产出一个合格候选？这些就是接下来我们深入构建循环内部时要考察的问题。假阳性（即违反某项义务却仍通过审查的候选）的可能减少，属于稍后的讨论，届时我们会放宽完美评估的假设。

2. 设计内循环

回到第 1 节中的存储读取示例。该演练的一致性契约包含义务 TD-08：当存储的数据无效、不可读或不受支持时，应用程序必须返回一个可区分的读取失败结果，且不得覆盖或清除原始存储字节。我们将沿着该义务中“保留”这一半，追踪其经过准备、规划交接以及可能捕获其遗漏的检查。

在构建循环内，智能体、流水线或图会进行规划、编写、检查和修订，以构建出符合给定规范的代码。构建和外部评估构成内循环；人工设计和审查界定外循环。下图展开构建循环：准备、行动、可选的检查与纠正，以及提交给评估器。

在我们的完美评估器假设下，内循环中的外部评估正是确立生成代码候选正确性的环节。让我们深入构建循环的内部运作，看看如何改进为评估器产出候选的路径。

我们关注构建循环中两类错误来源，它们需要不同的应对方式。它们并非唯一可能的来源；能力限制、工具故障以及契约或检查中的缺陷同样重要：

• 环境因素（缺少前提条件）：智能体缺少它需要的东西，例如一项从未到达它那里的义务、缺失的应用或 API 知识、被截断或被埋没的上下文，或者一个行为异常的工具。
• 智能体失败模式：智能体拥有所需信息却仍然出错，例如忽视明确要求、误读清晰的工具输出，或在有失败记录的情况下仍将检查报告为通过。

一项关于编码智能体失败的研究说明了第二个来源为何重要。失败作为一个过程考察了基于终端的编码智能体如何失败。研究人员在 Terminal-Bench 任务上，于三种编码智能体脚手架中分别运行了七个前沿模型，并保留了 1,184 条失败轨迹和 610 条成功轨迹。对于每次失败的运行，他们识别出一个决定性的错误——即决定最终失败的那个错误，它是事后识别的，未必是最先出现的——并对其根本原因进行了分类。大多数决定性错误（57.9%）是认知性的，而非能力相关的：智能体错误处理了它已经拥有的信息。他们的类别包括忽视规范、误读输出和忽略信号。他们还发现，成功的运行中也包含错误，随后得到恢复。总之，这些发现支持考察判定背后的过程，而不仅仅是判定本身。

这项研究对我们的目的有用，但它回答的是与我们不同的问题。它的类别与我们所说的智能体失败模式（在第 2 节“区分缺少前提条件与智能体错误”中定义）有重叠，但这种重叠并非等同。它们并非由我们更狭窄的检验来定义，即智能体在相关步骤是否拥有充分、准确且可用的信息，因此我们无法说它统计的错误中有多少符合我们的定义。该研究还为每次失败运行只统计一个决定性错误，而在我们自己的运行中，我们经常在单次运行中看到多种失败模式，因此它的占比无法告诉我们每种模式总体上出现的频率。而且，尽管它分析了恢复，却没有单独区分我们这类错误，因此它无法告诉我们其中有多少可以被恢复，无论是智能体自行恢复还是通过干预恢复。

要了解我们想知道的东西还需要进一步的工作：标注一次运行中的每一个错误，而不仅仅是决定性的那个；依据我们的定义对每个错误进行分类，这意味着要确定智能体在该步骤拥有什么信息；衡量每一类错误被恢复的频率，包括自行恢复和通过诸如针对性检查或修正等干预恢复；并在不同模型、框架和任务上重复这些测量，进行足够多次重复运行以考虑不同尝试之间的差异。在那之前，请将 57.9% 视为证据，表明错误处理可用信息很常见且值得考察，而不是一个可以套用到我们自己循环中的比率。我们把这项工作留给后续研究。

配套的演练文档 Following a Candidate from Conformance Contract to Human Review 追踪了一条需求从合规契约到人工审核的全过程：即本节开头描述的义务 TD-08。这里我们深入构建循环，看看在产生满足该义务的候选结果的过程中，错误是如何出现的。在这个例子中，一个规划阶段从未被告知失败的读取必须保留已存储的数据，这就存在环境问题。而一个规划阶段被告知了这一点，却仍然计划用空存储替换不可读的数据，这就存在失效模式。

这两类来源出现在构建循环的不同位置，因此我们以不同方式处理它们：

许多真实事件同时混合了两种来源，而现有记录往往无法说明究竟发生了哪一种。我们将这种不确定性视为需要保留的信息，而不是靠猜测来消除的麻烦。下面的三项活动与表格相对应：第一项主要预防环境错误。观察和纠正适用于任一来源：检查可以在原因未知之前就确定缺陷并证明修复的合理性。

上图中各步骤底部的标签标明了接下来描述的三项活动各自适用的位置。

三项活动改善了产出评估者候选结果的路径：

1. 为成功设置好阶段（PREPARE 步骤）。准备每个阶段所需的上下文和工具，并安排工作以避免可预防的错误。
2. 观察发生了什么（CHECK 步骤）。检查中间工作是否存在可观察的错误，将缺失的前提条件与智能体的错误区分开来，并在做出任何更改之前记录所发生的情况。
3. 当证据支持时进行干预（DECIDE 和 CORRECT + VERIFY 步骤）。判断证据是否支持进行纠正，然后在证据可靠的最早节点纠正工作并验证纠正。

ACT 步骤是智能体自身的工作，SUBMIT 将候选结果交给评估者。这三项活动改善了它们周围所发生的一切。

一份配套指南，设计内循环：准备、失败模式与应对，为这三者提供支持，我们在行文中会随时引用它。它从困难的成因入手，因为不完整的规格说明、缺失的信息或失效的工具，与智能体所犯的错误需要不同的补救措施。接着，它将常见问题——例如目标不清晰、信息过时、上下文过多、权限模糊、任务过大和评估薄弱——与一种设计实践、证明其有效的证据以及衡量成本配对。然后，它列出了十五种反复出现的智能体行为，例如不忠实的交接、跳过的工作以及未经证实地声称检查已通过，每种行为都附有建议的检查方法和应对措施。最后，它展示了学习循环如何选择保留哪些机制。每当你定义智能体的任务、流水线阶段或两个阶段之间的边界时，都可以把它当作设计检查清单来使用。其中的模式和检查项是可供测试的工作指导，而非详尽的分类体系或经过验证的检测套件。

活动 1：为成功搭建舞台（PREPARE）

阶段是构建循环中的一个工作单元：单个智能体会话中的一个步骤，流水线中的一个角色（如规划、实现或审查），或图中的一个节点。阶段之间通过交接传递工作。每个阶段设置得如何，以及阶段和交接如何安排，决定了有多少错误会到达后续的检查环节。以下指导来自我们与智能体协作的通用原则，涵盖支持性环境、上下文策略、验证和实现。配套指南中关于准备工作的一节对此进行了汇总。

为每个阶段提供其所需

为每个阶段赋予明确的职责、相关的义务、准确的应用和 API 知识、合适的工具以及获取更多信息的途径。当工作在阶段之间流转时，保留需求和尚待解决的问题。在控制器代码中以机械可检查的方式强制执行权限和强制转换。配套指南中的预防性设计指导将这些实践汇集在一起。

一次性提供所有内容并不等同于提供有用的上下文。Anthropic 的上下文工程指导描述了渐进式检索以及在压缩过程中丢失重要细节的风险。更窄的任务和专家型智能体有助于管理信息，但每一次交接都会带来另一个丢失信息的机会。对于存储读取示例，TD-08 的两个部分——报告失败和保留已存储的数据——以及关于存储接口的相关事实，都需要到达对其做出决策的阶段。

刻意设计阶段和交接

在添加检测器之前，先问一问工作的安排本身是否正在制造困难。在规划—实现—审查流水线中，实现阶段需要的是控制性义务和相关应用事实，而不仅仅是规划者的结论。交接应携带对这些来源的引用、已做出的决定以及仍然悬而未决的问题。它应指明自己描述的是哪个候选方案或起始状态。这些要求同样适用于单个智能体会话内的各个阶段以及相互独立的智能体。

设计每个阶段的一个实用方法是回答五个问题：它负责什么，它必须知道什么，它可以改变什么，它必须返回什么，以及如果它无法完成会发生什么？然后检查各阶段之间的边界。如果两个工作者可以编辑同一状态，他们的更改如何协调？如果一个工作者返回不完整的结果，后续工作能否将其与完成区分开来？在答案可以机械地强制执行的地方，将规则放入控制器代码中。在需要解释的地方，保留证据和升级路径。

对于我们的规划阶段，这意味着规划当存储数据无法读取时应用程序如何响应，了解存储如何加载和保存，并有权提出实现工作，同时保持已批准的义务固定不变。它的交接必须保留义务的两个部分，报告失败并保持存储字节不变，并识别未解决的问题。关于存储接口的缺失事实应导致检索或在实现依赖该计划之前明确阻止。

拆分工作可以减少每个代理必须处理的信息，但也可能将需要一起考虑的事实分开。将失败读取报告和存储数据保留保留在一个任务中，可能比独立委派它们并在之后修复集成错误更可取。单独的审查者可能会增加有用的审查，或者只是重复同样的误解。将拓扑视为一种需要测试的设计选择。更长的提示或更大的图本身都不是解决方案。

活动2：观察发生了什么（检查）

在改变循环之前，我们需要知道实际出了什么问题。将两个错误来源分开有助于区分需求、信息传递、工具和协调中的问题与代理如何使用其收到内容中的错误。

区分缺失的先决条件与代理错误

在本文中，代理失败模式是指在配置的代理已展示的能力范围内，尽管在相关步骤拥有充分、准确和可用的知识与上下文，但在任务上反复出现的错误决策或行动模式。失败模式引发的错误是被支持为匹配该模式的观察到的实例。示例包括忽视明确要求、误读清晰的工具输出或尽管有记录的失败却报告检查已通过。

这种区分很重要。缺少基本API知识的代理需要被提供该知识。收到并忽视明确要求的代理则呈现出不同的问题。已确认的缺陷可能值得修复，而其原因仍未解决。这些模式不必在每次尝试中都出现，自发恢复或指示纠正都无法保证。

内环工程伴侣将通用原则与智能体行为目录相结合。缺失的知识、过多的上下文和不完整的规范属于其预防性设计指导；行为条目则处理在具备充分前提条件下仍出现的错误。每个条目都将一个可识别的模式与建议的检查、响应和纠正验证联系起来。使用这些来选择要调查的机制；它们并非详尽的分类法，也不是经过验证的检测套件。

先观察再干预

一个实用的起点是以观察模式运行建议的检测器：记录其发现而不改变构建过程，然后检查接下来发生了什么。对于存储读取示例，记录规划交接是否在读取失败时保留了已存储的数据，以及实现对其做了什么处理。智能体恢复了吗？评估器拒绝了候选方案吗？该信号是否涉及真实缺陷？这可以在添加中断之前揭示放置不当或过多的误报。它并不能告诉我们如果进行纠正会发生什么；那需要下面讨论的对比运行。

活动 3：当证据充分时进行干预（决定与纠正 + 验证）

在循环中追踪一个遗漏

回到存储读取示例。规划智能体收到义务 TD-08 以及关于存储接口的相关事实；假设它已展示出处理此类变更的能力。

在这个假设中，它的交接仍然计划通过保存空存储然后报告读取失败来从不支持的已存储版本中恢复。该计划报告了失败，但丢弃了保留原始数据的要求。实现阶段遵循该计划，已存储的数据被覆盖。源契约从未被更改。错误出现在中间产物丢失了一项义务，而后续工作依赖了它。这说明了伴侣的不忠实的交接模式。

实现者可以重新阅读契约并恢复。在我们的完美评估器假设下，如果最终候选方案没有做到，它将被拒绝。这两种可能性都不能使该遗漏对过程无害：依赖的代码和测试可能在纠正开始之前就已经围绕它构建了。仅收到缩短交接的下游智能体也存在信息缺口；这并不自动构成另一个独立的故障模式激活。

我们可以在哪里干预？在交接处，在依赖实现开始之前，将拟议的工作与相关的源义务进行比较。明确的义务标识符列表允许对缺失引用进行机械检查。确认计划实际上保留了它们的含义可能需要语义审查。仅凭完整列表是不够的：在我们的示例中，一个计划通过标识符引用了 TD-08，但提议覆盖数据，它将通过第一项检查而未能通过第二项。

如果遗漏得到确认，返回一个具体的发现：该计划用空存储替换了不可读的数据，与 TD-08 保留原始字节的要求相矛盾；确定控制性义务和受影响的工作。将其恢复到计划中，并修复任何已经因该遗漏而衍生的实现或测试。不要为了迁就候选方案而削弱契约。

然后从行为上验证修复，使用契约的四个代表性失败场景：不支持的版本、存储值不是对象、版本 1 信封中 todos 值不是数组，以及适配器读取错误。对于每一种情况，应用程序都应返回读取失败结果，保持存储字节不变，并且不进行任何保存调用。缺失数据仍应产生空列表；这检查修复不会简单地把每一次异常读取都变成错误。还要针对一个故意有缺陷的版本运行这些检查，该版本在读取失败时覆盖数据，并确认它因存储字节被更改而失败。这表明这些检查能够检测出这一特定缺陷。这些检查覆盖四个具体案例，而非所有可能的畸形输入。

有用的证据是源义务、不完整交接、依赖变更、发现、修复和已执行的检查结果。保留这条链可以让审查者检查修复了什么，而无需重建整个尝试过程。它还让我们能够测试干预是否有帮助。

检查需要目标和响应

存储读取示例为失败模式标签赋予了操作意义：可观察的遗漏、传播前的检查点、有界修复以及验证它的方法。其他模式需要不同的机制。关于测试通过的声明可以与执行记录进行比较。反复不成功的修复可以通过候选变更和重复发现来调查。这两种检查都不需要猜测模型的内部推理。

“寻找失败模式”这样的通用指令让这些决定悬而未决。选择相关证据在哪里变得可用、什么构成发现，以及响应应该是纠正、进一步调查、继续工作还是升级。机械检查可以比较标识符或执行记录。模型辅助检查可以评估摘要是否保留了需求的含义，但其判断需要限定。Anthropic 的代理评估指南讨论了这些评分器权衡，包括将模型判断与人工评估进行校准。

对于交接检测器，准备几个小案例：一个在读取失败时保留存储数据的计划；一个省略保留要求的计划；一个通过标识符提及 TD-08 但提议覆盖数据的计划；以及一个用不同措辞正确表达保留的计划。检查应区分遗漏和矛盾，而不拒绝合法的替代措辞，也不标记在尚未保存任何数据时合法创建空存储的情况。包括它未经过调优的案例。这测试机制是否检测到预期的缺陷，而不是它是否识别自己示例中的词汇。

单独测试纠正。检测器可以正确识别缺失的义务，却仍然提示无效的修复。智能体可能会在计划中添加一句话，而实现保持不变；或者停止覆盖数据，却开始将存储缺失视为错误，这与“缺失数据应产生空列表”的要求相矛盾。提供具体的发现和相关来源，限定允许的修复范围，并在之后验证受影响的行为和保留义务。反复失败的修复需要设定限制，并诚实地停止或升级；添加一个纠正智能体并不会让纠正按定义就变得可靠。

时机是另一个选择。交接的有用检查点是当它准备好指导依赖工作时。未完成的计划可能合理地省略作者仍在添加的细节。同样，在不完整编辑期间出现的暂时性测试失败可能不足以中断智能体。在证据可靠地确立问题、且避免的下游工作值得中断的最早点进行干预。有些约束必须在行动之前强制执行；可选的质量检查通常可以等到有一个连贯的产物。

早期检测仍然是一个实质性问题。在Failure as a Process中，一个实验性监控器读取部分轨迹，并试图识别那些已经通过回顾性标记的“锁定”点的运行，此后未观察到成功恢复。其最佳召回率为28.8%。这与检测已完成交接中的特定遗漏是不同的任务，但它说明了从部分历史中识别困难的难度。监控结果。目录为我们提供了调查目标，但仅仅命名它们并不等于检测器。

如上方的构建循环图所示，这些可选的检查和响应与常规恢复和提交到外部评估并存。

干预可能给我们带来什么？

比较三种可能的历史：智能体自己注意到遗漏；外部评估者拒绝候选并提示修复；或者中间检查在更多工作依赖它之前捕获它。早期干预可能节省返工。它也可能中断廉价的自我恢复、在误报上消耗令牌或引入新缺陷。其价值取决于这些历史之间的差异，包括检查和验证修复的成本。

有证据表明有针对性的干预可以帮助。Meta的Wink定期检查编码智能体的历史并提供纠正指导。其15天的生产A/B测试报告称，每个会话的令牌减少了5.3%，工程师干预减少了4.2%。这些是在该设置下的操作改进；它们并不确立最终代码的正确性或另一个循环中的等效节省。该论文的单独恢复评估判断的是检测到的行为停止和进展恢复，而不是独立验证的任务完成。

假设做一个思想实验，我们能够阻止或纠正我们所针对的每一处行为模式实例，包括它们的下游影响。那么候选方案将不会带有由这些实例造成的缺陷。消除这一类错误本身并不能确立完整的需求、充足的知识、正确的工具或完成任务的能力。我们仍然需要衡量所节省的工作量：有些错误本可以低成本地被纠正，而另一些则可能引发了大量返工。经验性问题关注的是结果和成本的变化，而不仅仅是检测器覆盖了分类体系中的多大比例。

在完美的终端评估下，早期检查不会为合格的代码增加任何正确性保证。当我们放宽这一假设时，额外的检查可能会暴露出评估器遗漏的违规，并防止虚假的绿色通过。那是一种潜在的额外收益。内环工程的主要动机是减少达到符合规范的候选方案所需的时间和 token（以及潜在的返工或重试）。

对于我们的任务和智能体配置而言，哪些检查值得其成本？这是学习循环的职责。

3. 学习循环

改进准备工作或增加检查可能会改变生成符合规范候选方案所需的工作量。这种改变是否有益，取决于原本会发生什么，包括常规恢复、评估器驱动的返工以及干预本身的成本。

• 从设计、构建、评估、人工审查以及发布后发现的缺陷中收集证据。
• 将观察到的问题转化为可测试的变更，然后比较检测、修复、整体结果和人工投入。
• 当智能体或其工作条件发生变化时，重新评估支持，并建议保留、修订或淘汰哪些机制。

学习循环利用成功和失败运行中的证据来建议流程改进。Lilian Weng 的harness 工程综述探讨了将 harness 本身作为优化目标的更广泛理念。在此提出的安排中，AI 负责分析和建议；人类批准对循环的变更。

学习循环接收什么并建议什么

来源及其提供的证据

学习循环需要来自流程每个部分的证据，而不仅仅是构建部分。发布两周后报告的 bug 可能暴露出遗漏的义务、薄弱的检查或失败的修复，而每一种都指向不同的改进。其输入来自五个来源：

证据如何变成建议

学习循环随后分四步进行：

1. 重建发生了什么。将每个问题追溯到最早有证据的错误、促成该错误的条件以及未能发现它的检查。区分这两类错误来源有助于诊断问题所在，区分缺失信息、不完整的规范、薄弱的评估器、工具或协调失败以及智能体失效模式。如果记录无法说明，原因就保持未知。
2. 将问题与候选变更匹配。《通用原则》提示如何准备工作。行为目录提示检查与响应。
3. 提出一个有界变更。陈述假设以及什么证据会否定它。
4. 测试并给出建议。比较结果与成本，估计检测率和纠正率，并建议保留、收窄、修订或废止该变更。由人类批准；重新确认会在条件变化时重新审视该决定。

建议落在何处

由于证据贯穿整个过程，建议可以指向其中任何部分：

• 合同准备与审查。如果合同从未要求在读取失败时保留已存储的数据，那么改进交接检查器也无法恢复那项缺失的意图。
• 上下文准备与阶段设计。更好的 API 上下文、更简单的工作流或不同的工作划分，可能消除检测器否则会较晚发现的信息缺口。
• 检测器与纠正。添加、收窄、修订或废止某项检查或其响应。
• 评估。如果义务存在但测试走了错误的路径，就改进该检查。
• 证据交接。如果审查者花了一小时定位一个已经记录的结果，就改进证据的汇总方式。

将观察转化为可测试的变更

使用示例性的存储读取历史来制定一个有界提案：在实施之前，将规划交接与其来源义务进行比较，因为修复计划可能比修复由该计划衍生的工作成本更低。明确检查点、它可以返回的发现以及允许的纠正。说明什么会否定该提案：频繁误报、相比普通恢复没有改进，或引入其他缺陷的修复。这将像这样的遗漏转化为一个我们可以测试的假设。

比较整个过程

在重复的可比任务上测试所提出的交接检查，分别在有和没有干预的情况下进行，保持合同、评估器、智能体配置和预算策略固定。基线保留普通智能体恢复和评估器驱动的返工。比较两条路径直至通过资格认定或不成功的停止，包括检查和修复开销。纳入未用于开发该检查的代表性案例；一次成功的纠正无法确立可靠的收益。

将四个问题分开：是否发生了错误、检测器是否识别出它、纠正是否有效，以及整体运行是否改善。独立于检测器审查抽样的历史记录，以寻找遗漏的错误和误报。保留关于原因的不确定性。一个遗漏上附着的多个标签不会产生多个事件。

每次比较都从等效的干净状态开始，不将一次尝试的修复传递到下一次。在可行的情况下，随机化或交错条件，以减少服务条件变化解释结果的可能性。一小组手工制作的故障交接可以测试检测；它无法告诉我们这些交接在普通工作中出现的频率。使用有代表性的任务来估计实际价值，并报告有多少任务和重复支持该结果。

核算应包括：

• 检测：每个相关机会中确认的事件、遗漏的错误、误报以及检查发现问题的及时程度。
• 总成本：准备、协调、每次检查调用、纠正和重新检查，包括时间和来自不成功运行的可用令牌使用量。包括设置和维护工作。
• 结果和后果：在预算内完成、回归、逃逸的缺陷以及如果错误未被检测到的潜在损害。罕见的数据丢失缺陷可能证明一个仅凭频率会被忽略的检查是合理的。
• 人力投入：监督、澄清、审查证据和重建缺失的上下文。构建期间较少的参与可能意味着审查时较少的熟悉度；两者都要计入。

频繁触发的检查可能会中断廉价的自我恢复。更安静的检查可能会遗漏错误或阻止后果严重的逃逸。在证据允许的情况下估计逃逸的可能性和后果，并在不允许时说明不确定性。仅凭信号计数无法决定哪种机制属于循环。

举一个简单的算术例子，一个检查在100次调用中每次花费20秒，在任何修复之前消耗33分20秒的累计检查时间。如果它发现十个真实问题，那么在这些案例中节省的时间必须覆盖总开销以及纠正和重新检查，才能使该机制总体上节省执行时间。这十次检测不是十次被挽救的运行。并行执行还意味着累计工作和挂钟延迟是不同的度量。将时间、令牌和人力投入区分开来，而不是将它们合并为一个生产力分数。

如果该机制能实质性减少后果严重的逃逸或人力工作，那么即使增加执行成本，决策仍可能支持它。相反，一个更快的运行如果交给审查者一个更难理解的候选方案，可能只是转移了负担而不是减少了负担。衡量证据包本身：审查者能否找到控制性需求、检查相关变更并看到支持性结果和未解决的限制？他们能否解释变更后的行为并识别其证据中的后果性缺口？在可比较的审查案例中，将这些判断与花费的时间一起评估，包括纠正误导性证据所需的努力。当更短的审查保持或提高了决策质量时，它是有用的。

同样的比较也适用于预防性设计。更好的 API 上下文可能比增加另一个审查者更有效地消除信息缺口。更简单的工作流可能避免交接损失。在可行的情况下，一次只测试一项变更，或明确正在测试的组合。保留完整历史，这样最终的绿色结果就不会掩盖反复出现的失败或代价高昂的完成路径。

将检测和纠正视为比率

Agent 行为可能是随机的：相同的任务和工作条件可能导致不同的错误，或对纠正做出不同的响应。一次成功的修复表明该纠正可以奏效，而不是每次错误出现时都会奏效。某个特定触发条件仍可能产生高度可复现的错误。记录每种模式出现和被纠正的条件，以便这些比率描述该机制将被使用的情境。

在 Wink 的评估中，LLM 评判员将 agent 在约 91% 的单次干预对话和约 79% 的多次干预对话中评为已恢复。恢复意味着检测到的行为停止，且 agent 在后续步骤中取得了进展。这些是评判得出的恢复率，不是保证，也不是经独立验证的任务完成率。

将链条中的每一环都视为一个待估计的比率：该错误类型在机会中出现的频率、检测器捕获它的频率，以及一旦捕获后纠正成功的频率。从反复出现的可比案例中估计每一项，并报告有多少案例支持它；少量观察会在两个方向上留下很大的不确定性。三个观察案例中的三次成功，与远低于 100% 的成功率是相容的。

这些比率应结合检测或纠正机制的成本以及漏检的后果，为增加或移除该机制的决策提供依据。当错误频繁或后果严重时，即使只是有时奏效的纠正也仍可能值得保留。在依赖该修复的后续工作开始前，检查每一次尝试的修复；失败或未经验证的修复需要有界的重试、诚实的停止或上报。修复检查本身也有覆盖范围限制，而且纠正本身绝不能使候选者合格。很少需要或很少奏效的机制，可能不值得其开销。随着模型、测试框架和任务组合的变化，持续进行测量。

随着系统变化重新认证

新的模型或厂商测试框架可能会改变哪些支持是有用的。Anthropic 报告称，当 Opus 4.5 基本解决了此前在 Sonnet 4.5 上促使他们进行上下文重置的过早收尾行为后，他们取消了上下文重置；自动压缩仍然处理上下文增长。这是一个针对特定配置修订支持的具体例子。测试框架设计报告。

Repeat the comparison after material changes to the model, harness, tools, context strategy or task mix. Include prior failures and representative new cases, and test the optional mechanism both enabled and disabled. Recheck the detector, too: fewer alerts could mean fewer errors, fewer opportunities or a changed error pattern it no longer recognizes. If evaluation changes, assess that change separately before interpreting a higher pass rate.

When both agent versions are available, four conditions separate improvement in the agent from improvement supplied by the mechanism:

Use the same task set and acceptance criteria across these conditions, with repeated attempts and recorded costs. A lower error rate with the check enabled cannot establish that the agent has taken over its responsibility. The disabled condition is essential to that decision. If an older configuration cannot be reproduced, state that limitation and qualify the current arrangement on its own evidence.

This gives “the model eating the harness” a practical test. Can the vendor agent perform this responsibility dependably enough under our conditions, with acceptable costs and consequences? Evidence can justify retaining, narrowing, improving or retiring custom support. The responsibility remains when its implementation moves. Removing an early intervention does not itself justify removing independent qualification or the human’s acceptance decision.

There is no universal threshold for keeping a check. A team may retain it only for security-sensitive changes, run it at handoffs instead of after every action, or replace a semantic review with a cheaper mechanical check for a narrower property. Record the scope of that decision and the evidence supporting it. Continue observing the relevant outcomes after a change so the learning loop can recommend restoring support if regressions emerge.

The useful output is a recommendation tied to evidence: what changed, which outcomes improved or worsened, what it cost and what remains uncertain. Human approval closes the learning loop. Start with one recurring problem or consequential obligation, test a focused improvement, and keep checking two outcomes: the time and tokens required to reach a conforming candidate, and the usefulness of its evidence for human review. If you have tried this, which mechanisms earned their place—and which turned out to cost more than they saved?