当人类还需要坐在键盘前，逐行指导智能体工作时，核心能力是编写提示词。如今，智能体已经可以接收一个目标，然后自行运行，新的核心能力便是循环工程。
文章作者：CyrilXBT
文章编译、来源：ME News
2026 年 6 月，一周之内，三个人各自独立地得出了同一个结论。
OpenClaw 的开发者 Peter Steinberger 公开表示，人们应该停止直接给编程智能体编写提示词，转而设计那些能够自动向智能体发出指令的循环系统。
几乎在同一时间，Anthropic Claude Code 负责人 Boris Cherny 也表示，他已经不再直接向 Claude 输入提示词。现在，他运行的是一套套能够自动调用 Claude、判断下一步该做什么的循环，而他真正的工作，是编写和设计这些循环。
几天后，Google 工程师 Addy Osmani 对这一实践进行了系统总结，并给出了一个名字：
Loop Engineering，循环工程。
他们并不是凭空创造了这种工作方式，而是为一种已经悄然发生的变化命名。
因为在此之前，底层工具已经跨过了一个关键临界点：编程智能体开始能够在无人值守的情况下完成真正的任务；自动调度的成本足够低，反复定时运行一项任务不再显得浪费；单次智能体运行的成本也下降到了一个新的水平——与其花大量时间精心思考一次，不如让智能体尝试五次，成本可能反而更低。
这正是这份路线图存在的原因。
当人类还需要坐在键盘前，逐行指导智能体工作时，核心能力是编写提示词。如今，智能体已经可以接收一个目标，然后自行运行，新的核心能力便是循环工程。
下面是一条从提示词操作者走向系统设计者的完整 20 步路径。必须按照顺序推进，因为在这条路径中，步骤之间的先后关系，往往比任何单独一个步骤都更加重要。
为什么必须按照顺序构建
循环工程并不是一种“掌握了”或“没掌握”的单一技能，而是一套层层叠加的能力栈。每一层，都依赖下方基础是否足够牢固。
例如，在第 10 步建立真正的停止条件之前，就直接构建第 14 步的自动调度触发器，只会得到一个能够在无人值守状态下自动浪费资金的系统。过去它至少只会在你盯着屏幕时浪费资源，现在它可以自己持续烧钱。
同样，如果在完成第 6 步和第 7 步的可靠验证机制之前，就先搭建第 11 步的持久化记忆层，你可能会把一个过于宽松、不断放行错误结果的“评审者”所总结出的经验认真保存下来。
这不仅不会帮助系统进步，反而会让错误经验不断积累，使记忆层从“暂时无用”变成“主动有害”。
因此，跳过某些步骤并不只是少实现一个功能。更严重的问题在于，你会把那些看起来激动人心的高级能力，建立在一个根本无法支撑它们的基础之上，并且往往要等到系统已经规模化运行、造成实际后果之后，才会发现问题。
第一阶段：完成思维转变第 1 步：承认瓶颈在你，而不在模型
真正的第一步并不涉及任何技术。
你必须承认，在当前工作流中，限制效率的因素往往已经不再是模型能力，而是你本人仍然停留在循环之中。
每当你坐在电脑前等待模型回答，阅读结果，再输入下一条指令时，你就成为了整个系统中最慢的环节。
模型可以执行、验证和重试，而这些操作的速度远远快于人类逐步监督它完成任务的速度。
这一步没有对应的提示词，它是一项认知决策。
在你真正接受这一点之前，后续所有步骤看起来都会像是不必要的额外工作，而不是它们真正的意义——移除系统中最大的效率瓶颈。
第 2 步：不要再把更长的提示词等同于更好的系统
当模型输出出现问题时，人们最自然的反应，通常是在原来的提示词中再增加一条规则。
几个月之后，这种做法会制造出一堵由规则组成的高墙：内容密集、彼此矛盾，长到模型无法在工作记忆中同时处理所有要求。
最终，模型往往只能根据最近出现或看起来最显眼的内容进行模式匹配，并在不知不觉中忽略其他规则。
循环工程彻底改变了这种思路。
当问题出现时，你不再只是向提示词里添加一条新要求，而是为系统增加一个新的组件，例如：
- 增加一个独立验证步骤；
- 增加一个记忆文件；
- 增加一个定时触发器；
- 增加一个结构化评审环节。
随着外围系统能力不断增强，提示词本身应该越来越短，而不是越来越长。
第 3 步：把每项任务拆解为五个动作
无论具体任务属于哪个领域，循环中的每一次运行，都可以拆解为五个基本动作：
识别、交接、验证、持久化、调度。
识别（Discovery）
弄清楚真正需要完成的任务是什么。
交接（Handoff）
把任务交给负责执行的模型、智能体或工具。
验证（Verification）
依据真实标准检查结果是否正确。
持久化（Persistence）
记录本次运行发生了什么、学到了什么，避免经验在下一次运行时丢失。
调度（Scheduling）
决定这套流程什么时候再次运行。
大多数人的现有工作流，只明确包含了前两个动作：识别任务和交接任务，而且通常是在聊天窗口中手动完成的。
另外三个动作要么根本不存在，要么隐藏在人类自己的大脑中。
循环工程的核心，就是把这五个动作全部显式化，并尽可能实现自动运行。
第 4 步：找到第一个真正适合构建循环的任务
在开始搭建系统之前，先选择一项你已经在重复执行、并且能够明确描述质量标准的任务。
不要选择最困难的问题，也不要选择完全没有先例的创新任务。
第一个候选任务应该满足三个条件：
- 你需要反复执行它；
- 它拥有可以写下来的明确标准；
- 它有一个容易识别的“完成状态”。
换句话说，一位同事看到结果后，应该能够迅速判断这项任务是否被正确完成。
这一限制比表面上看起来更加重要。
如果一项任务没有清晰的完成标准，就无法构建真正的验证环节。而一个没有可靠验证机制的循环，并不是真正的循环，只是一次无人监督的猜测。
第二阶段：构建第一个循环第 5 步：先写“完成定义”，再写提示词
这是大多数人最容易跳过的一步，却也是决定后续系统能否正常运行的关键步骤。
在为智能体编写任何指令之前，先用清晰、自然的语言写下：一个正确结果究竟应该是什么样子。
你需要的是具体、可检查的标准，而不是“感觉不错”“看起来专业”之类模糊的质量判断。
可以使用以下模板：
任务名称：[任务名称]
完成定义（Definition of Done，DoD）：
- [具体、可检查的标准 1]
- [具体、可检查的标准 2]
- [具体、可检查的标准 3]
即使最终输出看起来完整且经过精心润色，只要缺少上述任何一项，这项任务就不能被视为已经完成。
如果你无法为当前选择的任务填写这份模板，就应该回到第 4 步，重新选择一项更适合构建循环的任务。
第 6 步：将“构建者”与“评审者”分离
这是所有循环系统中最重要的架构决策。
负责生成结果的角色，与负责检查结果的角色，必须彼此分离。
原因在于，当模型在生成内容之后立刻审查自己的输出时，它往往会倾向于为刚刚生成的答案辩护，而不是真正从批判角度审视其中的问题。
在一套合理的循环中，至少应该存在两个独立角色：
构建者（Builder）
构建者拥有一定的创造空间，负责生成第一个版本的结果。
评审者（Judge）
评审者接收构建者的输出，以及第 5 步制定的完成定义，并依据这些标准判断结果是否合格。
理想情况下，评审者还应该能够访问构建者无法访问的独立证据，例如：
- 测试套件；
- 原始资料；
- 实时数据；
- 权威数据库；
- 原始任务简报。
这样，评审者的判断才能建立在真实证据上，而不是用与构建者相同的思路，再生成一次主观意见。
第 7 步：给评审者提供客观依据，而不只是让它发表意见
如果评审者只能看到构建者的输出，它最多只能判断结果“看起来是否连贯”。
它无法判断结果是否真正正确。
因此，评审者必须拥有可以核对的客观依据，也就是 Ground Truth。根据具体语境，可以将其理解为“基准事实”“真实数据”或“权威依据”。
对于不同任务，客观依据也各不相同。
编程任务
客观依据是测试套件，以及代码真实运行后的输出结果。
内容生产任务
客观依据是原始资料和内容简报。评审者需要将原始资料与生成稿件并排比较。
研究任务
客观依据是任务明确要求使用的原始文件、论文、数据集或权威来源。
如果你无法明确说出评审者需要依据什么进行检查，那么你的循环就还没有真正的验证机制，无论评审者的措辞听起来多么自信。
第 8 步：先设计交接格式，再编写交接提示词
构建者的输出和评审者的结论，都需要采用明确定义的结构，而不能只是自由流动的自然语言。
否则，下一步的管理器就没有稳定、可靠的信息可以进行判断和路由。
构建者可以采用以下输出格式：
构建者输出：
- 最终交付内容；
- 对结果的信心程度；
- 已知的不确定性。
评审者可以采用以下输出格式：
评审结论：
- PASS：通过；
- FAIL：失败；
- NEEDS REVISION：需要修改；
- 发现的具体问题；
- 本次检查所依据的客观标准或原始证据。
第 9 步：在自动化之前，先手动完整运行一次
在接入自动调度和自动重试之前，先亲自手动运行一次完整的“构建者—评审者”流程。
仔细阅读评审者给出的判断，并问自己：
- 你是否同意它的结论？
- 它有没有放过一个你明知存在错误的结果？
- 它有没有错误地否定一个原本合格的结果？
如果评审者通过了一个你知道是错误的结果，或者否定了一个实际上没有问题的结果，应当先修正客观依据或完成标准，再继续搭建系统。
把一个错误的验证步骤自动化，只会让系统以更快的速度生产错误结果。
第 5 步至第 9 步的完整示例
为了让上述五个步骤更加具体，我们可以观察一个常见任务：把一份原始资料转化为一篇完整文章。
第 5 步：制定完成定义
这项任务的完成标准可以是：
- 草稿中的每一项事实，都能够追溯到原始资料中的明确内容；
- 草稿满足简报中的所有具体要求，包括篇幅、语气和结构；
- 原文的核心论点得到清晰保留，没有被无意义的填充内容稀释。
第 6 步：构建者生成草稿
构建者接收原始资料和内容简报，生成一版草稿。
与此同时，它还需要明确列出写作过程中存在的不确定性，例如：
- 某个数字是否真的出现在原始资料中；
- 某项结论是原文明确表述，还是由模型自行推断；
- 某一事实是否缺乏充分来源。
第 7 步：评审者对照原文检查
评审者同时接收草稿和原始资料，而不是只接收草稿。
它需要分别检查完成定义中的三个标准，并对每项标准单独给出通过或失败结论，而不是把所有维度压缩成一个模糊的综合分数。
将三个不同标准合并成一个总体判断，会掩盖究竟是哪一个维度出现了问题。这是许多原本能够运行的循环，逐渐失去反馈价值的最常见原因。
第 8 步：结构化交接
评审者的结论应该是一个结构化对象，而不是一段充满保留措辞的自然语言。
它需要输出三个明确的通过或失败结果，并针对每一项失败提供具体原因。
第 9 步：手动验证评审机制
在系统自动运行之前，手动执行一次完整流程，能够帮助你发现评审者是否过于宽松或过于严格。
过于宽松的评审者，可能因为文章写得流畅，就放过其中虚构的数据。
过于严格的评审者，则可能因为某种从未写入简报的个人风格偏好，错误地否定一篇合格文章。
这两种问题在第一次搭建时都很常见。
而在系统无人值守地运行 50 次之后再发现它们，远比第一次手动测试时解决问题更加昂贵。
第三阶段：补齐循环缺失的组件第 10 步：建立管理器和真正的停止条件
管理器（Manager）负责读取评审者的判断，并决定下一步操作。
停止条件也应该存在于管理器之中，而且必须被写成明确的硬逻辑，而不是一条模型可以通过自我解释绕开的软性指令。
例如：
停止条件：
- 最大修改次数：3 次；
- 第 3 次评审仍然失败时，将完整历史记录提交给人类处理，不得启动第 4 次修改；
- 质量标准：完成定义中的每一项都必须显示 PASS；
- 预算上限：如果任务成本超过 X，或运行时间超过 Y，无论当前状态如何，都必须立即停止。
一个没有真正停止条件的循环不是系统，而是一项等待暴露风险的负债。
为什么“结果足够好时停止”之类的软性指令并不可靠？
因为它只是一条建议。
当模型已经连续修改多次仍未通过时，为了给任务提供一个看起来令人满意的结局，它很可能说服自己相信“这一版已经足够接近标准”，从而自行降低判断门槛。
相比之下，由代码机械检查的迭代次数，或者管理器无法通过推理绕开的明确规则，不会出现这种问题。
第 11 步：增加持久化机制，让循环能够跨运行记忆
如果一套循环每次启动时都从零开始，它就不会记得上一次运行学到了什么。
因此，需要增加一个简单的持久化层。
可以为每一条真正的新经验建立一个文件，并在文件顶部用一句话概括：
- 学到了什么；
- 修正了什么；
- 为什么这项经验重要。
关键原则是：只记录尚未在其他地方保存的新知识。
重复的记忆不是知识，而是噪声。
要让持久化机制长期有效，必须在写入时保持克制。
人们很容易产生记录所有运行细节的冲动，但这样只会重现第 2 步提到的“臃肿提示词”问题，只不过这一次，膨胀的对象从提示词变成了记忆文件夹。
真正值得记录的经验，是那些一旦遗忘，就需要付出大量时间重新发现的内容，而不是某次按照预期顺利完成的普通运行记录。
第 12 步：定期进行记忆合并与整理
单纯增加持久化机制，最终也会产生与超长提示词类似的问题。
随着时间推移，系统会积累几十个文件，其中许多内容只是对同一问题的略微不同表述。
因此，应当按照固定周期对记忆文件进行整理。每周执行一次通常是一个合理频率。
整理过程包括：
- 审查现有记忆；
- 合并重复内容；
- 将多个相似经验压缩成一条更明确的原则；
- 删除已经被证明错误或过时的内容。
目标不是积累越来越多的文件，而是得到数量更少、信息密度更高的知识。
很多人会完全跳过这一步，因为它不会立刻带来肉眼可见的新能力，只是在预防未来的问题。
但恰恰因为它缺少即时反馈，才更应该被明确加入调度，而不是等到有人发现记忆文件夹已经难以管理时再处理。
在现实中，这种“以后有空再整理”的任务通常永远不会发生，直到系统性能已经因为大量矛盾、过时和半相关的记忆争夺上下文窗口而开始下降。
第 13 步：增加记忆召回环节
每次新任务开始时，让循环先扫描记忆文件中的一句话摘要，判断哪些经验与当前任务真正相关，并且只加载这些相关内容。
同时，还应当明确要求系统：如果现有记忆没有任何内容适用于当前任务，就直接说明没有适用经验。
不要因为记忆系统已经存在，就强行把过去的经验套用到一个完全不同的新问题上。
第 14 步：增加自动调度触发器
接下来，需要决定这套循环什么时候在没有人工启动的情况下自动运行。
触发方式可能包括：
- Cron 定时任务；
- 文件变化监听器；
- 基于日历的周期触发器；
- 某个外部事件或状态发生变化时触发。
这一步会把一套只能由你手动启动的系统，转变为一套能够在你睡觉时继续运行的系统。
讽刺的是，这通常是整份清单中最容易实现的一步，却也是许多人即使已经完成其他组件，仍然迟迟没有实施的一步。
第四阶段：扩展规模并强化可靠性第 15 步：在真正信任循环之前，对它进行压力测试
在把循环用于任何重要任务之前，需要主动针对四种故障模式进行测试。
测试一：不可完成的任务
给系统一个真正无法解决的任务版本，确认管理器能够按照停止条件退出，而不是无限循环。
如果一套循环只在能够成功完成的任务上接受过测试，它就从未证明自己拥有优雅失败的能力。
测试二：看起来合理但实际错误的结果
向评审者提供一个你明确知道存在细微错误的输出。
这个结果应该读起来非常流畅，但包含一个你有意植入的事实或逻辑错误。
观察评审者能否发现问题，而不是仅仅因为内容听起来合理就予以通过。
测试三：构建者与评审者共享模型盲区
如果构建者和评审者使用同一个底层模型，可以故意加入一个该模型经常犯的典型错误，观察评审者是否会放过它。
如果评审者与构建者拥有相同的盲区，那么第 6 步所设计的角色分离就失去了意义。
测试四：计算最坏情况下的运行成本
按照最大修改次数，使用最昂贵的模型调用和合理范围内最长的输出，计算这套循环在最坏情况下需要消耗多少成本。
然后诚实地问自己：
如果这笔数字出现在真实账单上，你是否会感到不安？
在信任循环处理重要任务之前完成这四项测试，能够提前发现绝大多数潜在问题。
否则，这些问题很可能会第一次出现在客户、管理者面前，或者直接体现在你的账单上，而不是出现在一次由你主动控制的测试中。
第 16 步：把不同任务路由给合适的模型
当循环能够稳定运行后，不要让所有角色都使用同一个你最喜欢的模型。
循环中的不同角色，对模型能力的要求并不相同。
构建者
构建者通常应该使用能力最强的模型。
因为它承担主要的复杂推理和内容生成工作。如果在这里使用能力不足的模型，第一版结果的质量会下降，后续可能需要更多修改轮次。
最终，修正低质量初稿所消耗的成本，可能高于一开始就使用更强模型的成本。
评审者
评审者负责依据明确标准进行检查，通常不需要太强的创造能力。
在标准足够具体的情况下，一个规模更小、成本更低、速度更快的模型，往往也能可靠地完成评审任务。
一个小模型如果依据极其明确的检查清单工作，其稳定性可能接近大模型，但成本和延迟都显著更低。
管理器
管理器只是按照已经写好的规则进行路由，几乎从来不需要使用最昂贵的模型。
它的任务是执行已经定义好的逻辑，而不是进行开放式推理。
此外，无论构建者和评审者表现如何，管理器在每一轮迭代中至少都会运行一次，因此，它的单次调用成本尤其值得关注。
合理的分层配置通常是：
- 强模型负责构建；
- 便宜而稳定的模型负责常规评审；
- 低成本模型或规则程序负责路由和管理。
循环系统中真正显著的成本优化，通常来自这种模型角色匹配。
很多人认为控制成本意味着减少循环数量或修改次数。实际上，更有效的方法，是让模型成本与循环中每个角色的实际难度相匹配。
第 17 步：先扩展到第二个循环，而不是同时搭建五个
第一个循环成功之后，人们很容易立刻尝试同时构建多个循环，平行处理五种不同任务。
即使当前架构已经能够支持这种扩展，也应当克制这种冲动。
你应该先让第一个循环稳定运行足够长的时间，直到你真正不再需要密切检查它的每一次输出。
这并不是指某次所有人都在认真观看的演示恰好成功，而是指它经过一段真实运行后，仍然能够持续通过人工抽查。
只有达到这一状态，才应该开始构建第二个循环。
第二个循环最好处理一种与第一个循环明显不同的任务。
这样才能验证底层架构是否具有真正的通用性，而不是仅仅针对同一个任务进行了越来越精细的调优。
第 18 步：为所有循环建立统一监控视图
当你同时运行多个循环之后，需要建立一个统一的监控视图，集中追踪所有循环的成本和停止条件触发情况，而不是只分别查看每一个循环。
单独来看，一套循环的任务预算可能完全合理。
但如果十套循环都各自在预算范围内运行，它们的总成本仍然可能达到一个令人意外的水平。
由于每个循环的独立数据看起来都很正常，这种风险往往直到汇总账单出现时才会被发现。
除了成功完成的任务之外，还需要专门记录每一次停止条件的触发。
如果某个循环频繁触及最大修改次数，而其他循环很少出现这种情况，它传递的信号可能不是“这项任务特别困难”，而是：
- 评审标准设置不合理；
- 评审者过于严格，导致任何结果都无法通过；
- 系统检查了错误的客观依据；
- 完成定义本身存在问题。
如果只追踪成功结果，并把每次人工升级都视为彼此无关的偶发事件，这种设计层面的模式就不会被发现。
第五阶段：成为真正的系统设计者第 19 步：不要再用“写了多少提示词”衡量自己
判断思维转变是否真正完成，最明显的标准，是你日常关注的指标发生了变化。
提示词操作者关心的是：
- 今天写了多少条有效提示词；
- 哪条提示词效果最好；
- 如何把提示词写得更加精巧。
系统设计者关心的是：
- 当前有多少套循环正在运行；
- 每套循环的可靠性如何；
- 系统为自己释放了多少时间；
- 哪些工作已经不再需要人工监督。
如果你仍然用输入了多少条提示词衡量自己的生产力，那么无论技术上已经搭建了多少循环，第 1 步要求的思维转变都还没有真正完成。
第 20 步：把五个动作教给另一个人
最后一步已经不再完全关于你自己的系统。
它用于验证你是否真正理解了这套方法。
你需要尝试在不依赖复杂术语的情况下，向另一个人解释五个基本动作：
识别、交接、验证、持久化、调度。
如果你能够只依靠这五个动作和前面的步骤，带领另一个人构建出他的第一套循环，就说明你已经完成了这份路线图描述的真正转变。
你不再是那个待在循环内部、不断输入下一条指令的人。
你成为了站在循环之外，设计系统并观察它自行运行的人。
跳过步骤后，会悄然积累的四种成本
在文章结尾，有必要给出一个警告。
跳过这份路线图中的步骤，往往不会立即导致系统崩溃。
它的失败通常是安静的，甚至在很长一段时间里都难以察觉，直到问题已经积累到相当严重的程度。
一、验证债务
当你跳过第 6 步和第 7 步，没有建立真正独立的评审者，也没有提供可靠的客观依据时，验证债务就会开始积累。
循环表面上看起来仍然在正常工作，因为生成结果“看起来还不错”。
直到某一个错误在几十次运行中不断累积，最终被人发现时，你才会意识到，系统从一开始就没有真正判断结果是否正确。
二、理解退化
当你跳过第 20 步时，就可能出现理解退化。
你仍然运行着自己曾经构建的循环，却已经无法清楚解释每个组件为什么存在，也无法在系统故障时有效调试。
原因在于，你从未真正内化这套架构背后的逻辑。
三、认知投降
如果第 1 步从未真正完成，就会出现认知投降。
即使验证系统已经通过长期运行证明了自己的可靠性，你仍然会因为习惯，手动复查每一项输出。
这种行为看起来谨慎，实际上却抵消了构建系统的全部意义。
四、Token 成本失控
如果跳过第 10 步，没有为循环设置真正的停止条件，就可能出现 Token 消耗和调用成本的失控。
你往往不会在系统开始失控的第一时间意识到问题，而是直到最终账单出现，才发现循环已经进行了大量无效调用。
上述所有成本都可以避免。
避免它们的方法，始终是同一种纪律：
按照顺序构建，不要跳过那些看起来不够精彩的步骤。
真正发挥作用的，往往正是那些最枯燥的部分：
- 明确的完成定义；
- 可靠的停止条件；
- 可以核验的客观依据；
- 独立的评审机制。
相比之下，那些听起来更有吸引力的部分——巧妙的提示词、复杂的系统架构图——远没有人们想象中那么重要。
真正决定系统质量的，是你所构建的系统是否知道：
- 什么时候自己是正确的；
- 什么时候自己是错误的；
- 什么时候必须停止。
这就是提示词操作者与系统设计者之间的全部区别。
区别不在于谁更加聪明，也不在于谁能写出更华丽的提示词。
真正的区别，是你是否有足够的纪律，认真构建那些枯燥、容易被跳过，却真正决定系统可靠性的部分。