2026 年 6 月，三个人在一周内不约而同地想到了同一个点子。
OpenClaw 的构建者 Peter Steinberger 公开表示，你不应该再直接给编程 Agent 下指令，而是应该设计那些能驱动 Agent 的循环。几乎同一时间，Anthropic 旗下 Claude Code 的负责人 Boris Cherny 也说，他不再直接提示 Claude 了，而是通过循环来驱动 Claude 并让 Claude 自己决定下一步做什么，他的实际工作变成了编写这些循环。几天后，Google 工程师 Addy Osmani 把这个概念写成了文章，并给它取了个名字：循环工程 (loop engineering)。
他们并非凭空创造了这种做法。他们只是给已经发生的变化命了名，因为底层的工具已经悄然跨过了一个门槛。编程 Agent 已经变得足够可靠，可以在无人监督的情况下完成真实的任务。任务调度的成本也足够低了，以至于按定时重复运行一个任务不再显得浪费。单次运行 Agent 的成本已经大幅下降，以至于尝试五次的花费，比小心翼翼思考一次还要少。
正是这个门槛，催生了这份路线图。当一个人类需要坐在键盘前，逐行指挥 Agent 的时候，核心技能是提示词工程。而现在，当你可以把目标交给 Agent 并让它自行运行时，核心技能变成了循环工程。这是一条从前者通往后者的完整 20 步路径，并且步骤的顺序比任何单个步骤都更重要。
在具体步骤之前，先说明为什么顺序特别重要。循环工程并不是一个要么有、要么无的单一技能。它是一个栈，每一层都依赖于下面一层的稳固可靠。如果你在还没有一个真正的停止条件（第 10 步）之前，就构建了一个定时调度触发器（第 14 步），那只是意味着你自动化的一个系统现在可以在无人监督的情况下浪费钱，而不仅仅是你盯着它的时候。如果你在还没有真正的验证机制（第 6、7 步）之前，就构建了持久化存储（第 11 步），那意味着你正在仔细记录一个可能会轻易通过糟糕输出的"评审官"所给出的经验教训，这让持久化层变得有害，而不仅仅是无用。在这个列表里跳步，不仅仅是错过某个功能。它意味着把看似华丽的部分搭建在一个实际上无法支撑它们的基础之上，并且只有在规模扩大后出了问题，你才会发现这一点。
第一阶段：思维转变（第 1 步至第 4 步）
第 1 步：接受你就是瓶颈，而非模型
真正的第一步并非技术性的。而是要承认，你当前工作流程中的限制因素不是模型的能力，而是你本人在循环中的存在。每当你坐下来等待响应、阅读它、然后输入下一条指令时，你就是这个系统中慢得多的那一环。模型在行动、验证和重试方面的速度，远远快于你监督它执行的速度。
这一步不需要任何提示词。这是一个决定。除非你真正相信这一点，否则之后的每一步看起来都像是多余的负担，而不是它实际上的意义——消除真正的瓶颈。
第 2 步：停止将更长的提示词等同于更好的系统
当事情出错时，本能反应是在同一个提示词里添加另一条指令。几个月下来，这会形成一个庞大、自相矛盾、规则密布的提示词墙，模型已无法一次性记住所有内容，于是它会匹配最近出现的模式，而悄悄忽略其他部分。
循环工程将完全取代这种本能。你不需要在提示词中添加新规则，而是为系统添加一个新组件。比如一个验证步骤、一个记忆文件、一个调度触发器。提示词本身应该随着周围系统的能力增强而变得更短，而不是相反。
第 3 步：学会把每个任务看作五步动作
循环中的任何一次迭代，无论具体领域如何，都可以分解为五个步骤。发现——弄清楚实际需要做什么。交接——将任务传递给将要执行它的东西。验证——对照真实情况检查结果。持久化——记录发生的情况，以免丢失。调度——决定何时再次运行。
当前大多数人的工作流程中，只有两个步骤是明确的——发现和交接，而且都是手动在聊天窗口里完成的。另外三个步骤要么不存在，要么在人的脑海里无形地发生。循环工程的实践，就是让这五个步骤都变得明确和自动化。
第 4 步：确定你的第一个真正的候选任务
在构建任何东西之前，先挑选一个你已经重复做过、并且如果需要你能写下其标准的任务。不是你最棘手的问题。不是完全新颖的事情。是一个有真实、可识别的完成标准的任务，一个同事看到后能立即判断是否已正确完成的任务。这个约束条件比你想象的要重要得多。一个没有明确完成标准的任务，无法为其构建第三步（验证），而没有真正验证的循环就不是一个循环，它只是一个无人看管的猜测。
第二阶段：构建第一个循环（第 5 步至第 9 步）
第 5 步：在编写任何提示词之前，先写下完成标准
这是大多数人跳过的一步，也是决定后续一切能否成功的关键一步。在给 Agent 写下任何一条指令之前，先用通俗的语言，准确地写出一个正确结果应该是什么样子。需要的是具体、可检查的标准，而不是一种模糊的"感觉不错"。
[任务名称] 的完成标准：
- [具体、可检查的标准 1]
- [具体、可检查的标准 2]
- [具体、可检查的标准 3] 即使输出看起来完整或漂亮，只要缺少上述任何一项，此任务就视为未完成。
如果你无法为你选择的任务填好这个标准，请返回第 4 步，另选一个。
第 6 步：分离构建者与评审官
这是任何循环中最重要的架构决策。产出的角色和检查的角色必须分开，因为一个模型在产生输出后紧接着进行自我审查时，往往会倾向于捍卫自己的输出，而不是真诚地审视它。
"构建者"获得创造空间，并生成第一版草稿。"评审官"则接收构建者的输出以及第 5 步中的完成标准，除此之外不需要其他东西来动摇它的判断。理想情况下，"评审官"还能访问到"构建者"没有的东西——一个测试套件、原始源文档、实时数据，这样它的裁决就基于真实证据，而不是像第一个判断那样形成的又一个主观意见。
第 7 步：给予评审官事实依据，而非仅仅是意见
一个只看到构建者输出的"评审官"可以告诉你输出是否看起来合乎逻辑。但它无法告诉你是否真的正确。对于编码任务，事实依据是测试套件和实际的执行输出。对于内容任务，它是原始的源材料和简报，与草稿并列对比。对于研究任务，它是应该被使用的实际文档。
如果你无法指出你的"评审官"将对照检查的具体事实依据是什么，那么你的循环还没有真正的验证机制，无论"评审官"的语言听起来多么自信。
第 8 步：在编写交接提示词之前，先定义好交接格式
构建者的输出和评审官的裁决都需要一个定义好的结构，而不是自由流动的散文，否则下一步的"管理者"就没有可靠的路由依据。
构建者输出：可交付成果 + 置信度 + 已知的不确定性
评审官裁决：通过 / 不通过 / 需要修改 + 发现的具体问题 + 对照检查了哪些事实依据
第 9 步：在自动化任何东西之前，先手动完整跑一遍
在设置调度或自动重试之前，自己手动完整地执行一次"构建者—评审官"的序列。批判性地阅读评审官的裁决。你是否同意它的判断？如果评审官通过了你知道是错误的东西，或者失败了实际上没问题的东西，请在继续前进之前修复事实依据或标准。自动化一个有问题的验证步骤只会更快地产生有问题的结果。
第 5 步到第 9 步的实例演示
为了让最后五步更具体，这里展示它们在一个真实、常见的任务上如何运作：将原始源文档转化为一篇成品内容。
第 5 步的完成标准：草稿中的每一个事实性陈述都能追溯到源文档中实际存在的内容。草稿满足简报中的所有特定要求：篇幅、语气、必须的结构。核心论点清晰呈现，没有被填充内容稀释。
第 6 步的"构建者"接收源文档和简报，生成草稿，并明确声明在写作过程中不确定的地方——一个它不完全确定是否在源文档中的数字，一个它推断出来而非直接陈述的声明。
第 7 步的"评审官"同时收到草稿和原始源文档（不仅仅是草稿），并分别对照三个完成标准进行核查，逐一返回通过或不通过的结果，而不是一个混合的总体分数。将三个不同的检查合并成一个单一的裁决，会掩盖到底是哪个维度出了问题，而这正是一个工作中的循环悄悄停止提供有用反馈的最常见原因。
第 8 步的交接格式意味着评审官的裁决作为一个结构化对象到达——三个明确的通过或不通过结果，并附有任何失败的具体原因。
根据第 9 步，在自动化之前手动跑一遍，这能发现你的评审官是否过于宽容（因为文笔流畅而放过一个包含虚假统计数据的草稿），或者过于严格（因为一个从未出现在简报中的风格偏好而否定草稿）。这两种失败模式在第一次尝试时都很常见，而且手动捕捉一次比在循环已经无人值守运行了 50 次之后再发现要便宜得多。
第三阶段：添加循环缺失的拼图（第 10 步至第 14 步）
第 10 步：构建管理者及其停止条件
"管理者"阅读"评审官"的裁决，并决定下一步做什么。这也是循环停止条件所在的地方，它必须被写为硬逻辑，而不是模型可以说服自己绕过的软性指令。
停止条件：
- 最大修订次数：3。在第 3 次裁决失败时，将完整历史记录升级给人类处理，不要尝试第 4 次循环。
- 质量标准：完成标准中的每一项都必须显示为"通过"。
- 预算上限：如果此任务超过 [X] 成本或 [Y] 时间，无论当前状态如何，立即停止。
一个没有真正停止条件的循环不是一个系统。它是一个等待出问题的潜在风险，等着任务变得真正无法解决的那一天。这里需要理解软性指令失败的具体原因，而不仅仅是接受它。"当它足够好时就停止"这个指令在提示词里只是一个建议，而一个压力足够大的模型（在已经失败了几次修订后），往往能说服自己相信当前尝试已经足够接近可以通过了，这正是因为它想要产生一个令人满意的任务解决方案。一个由代码机械检查的硬性迭代计数器，或者由管理者无法绕过的明确规则，就不存在这种失败模式。
第 11 步：添加持久化，让循环能跨次运行记住经验
一个每次运行时都从零开始的循环，无法记住上次学到了什么。添加一个简单的持久化层：每个真正的新教训一个文件，顶部有一行摘要，记录学到了什么、纠正了什么以及为什么它很重要。关键的是，只记录其他地方尚未捕获的内容——重复的记忆是噪音，不是知识。
让这一步长期有效的纪律是在写入时的克制。本能的反应是记录会话中发生的一切，这恰恰会产生本路线图在第 2 步中警告过的臃肿转录问题，只是被移到了一个记忆文件夹中，而不是提示词里。一个值得写下来的教训，应该是如果被遗忘将会花费真正的时间才能重新发现的东西，而不是对按预期成功完成的例行工作的记录。
第 12 步：按计划进行整合处理
仅靠持久化最终会产生与臃肿提示词相同的问题——几十个文件，许多都在说同一件事的略微不同版本。按固定计划（每周一次比较合理）审查记忆文件，合并重复内容成单个更精炼的教训，并删除任何后来被证明是错误的文件。目标是文件更少但每个文件内容密度更高，而不是一个不断增长的堆。
这一步是大多数人完全跳过的，因为它本身不会产生任何可见的新能力，它只预防未来的问题。这种"隐形"正是需要明确安排计划的原因，而不是等到有人注意到记忆文件夹变得笨重时才去做——实际上，这意味着直到循环的性能已经开始在相互矛盾、部分相关的教训争夺相同上下文窗口的重压下下降时，它才会发生。
第 13 步：添加召回步骤
在任何新运行开始时，让循环扫描记忆中的一行摘要，识别哪些教训与实际当前任务相关，并仅加载那些相关的内容。明确指示它，当记忆中没有适用的内容时要说明这一点，而不是仅仅因为存在记忆，就强行将一个不相关的过去教训套用到新情况上。
第 14 步：添加调度触发器
决定这个循环何时运行，而不需要你手动启动它。一个 cron 任务、一个文件监控器、一个重复的日历驱动触发器。这一步是将一个你按需运行的系统转变为一个在你睡觉时运行的系统的关键步骤。它通常是整个列表中单个操作起来最简单的步骤，也是人们在构建了其他所有东西后却最常懒得去实现的步骤。
第四阶段：扩展与加固（第 15 步至第 18 步）
第 15 步：在信任循环之前，先进行压力测试
在依赖这个循环做任何真实事情之前，有目的地针对四种失败模式进行测试。
给它一个真正无法解决的任务版本，确认管理者确实会停止，而不是永远循环下去——因为一个只在它能完成的任务上测试过的循环，从未真正展示过它知道如何优雅地失败。
给评审官一个你明知有细微错误的输出——一个读起来不错，但包含了你故意植入的特定事实或逻辑错误的内容——确认它确实能抓住这个缺陷，而不是放过听起来合理的东西。
如果构建者和评审官共享同一个底层模型，给评审官一个该模型会典型性犯的错误，看看它是否会放行这个错误——因为一个共享构建者盲点的评审官，违背了第 6 步分离的整个目的。
计算循环运行到其最大修订限制的最坏情况成本，使用你最昂贵的模型调用和最长的合理输出，并诚实地判断这个数字，如果出现在真实账单上，是否会让你感到震惊。
在信任一个循环处理任何重要事情之前运行这四个测试，可以捕捉到绝大多数原本会在客户、老板或你自己的银行账单面前第一次显现的失败，而不是在你有意运行的可控测试中。
第 16 步：将任务路由到正确的模型，而不是每次都使用同一个
一旦循环运行起来，要抵制将其每个部分都运行在你最喜欢的单一模型上的习惯。构建者角色通常受益于你能力最强的模型，因为它在进行实际的艰难推理，一个较弱的模型在这里会产生更差的初稿，而修复它所花费的修订周期成本，比一开始就生成好的成本更高。
评审官角色，对照特定的书面标准进行检查，通常在更小、更便宜、更快的模型上也表现得同样可靠，因为它不需要创造力，只需要一致性——一个较小的模型对照一个极其明确的检查清单进行核查，其效果通常能与大型模型媲美，而成本和延迟却低得多。
管理者角色，根据你已经写下的规则进行路由，几乎完全不需要你最昂贵的模型，因为它执行的是你已指定的逻辑，而非开放式推理——而且无论构建者和评审官表现如何，它每次迭代至少运行一次，这使得它的单次调用成本比其原始能力更重要。
这种分层方法——昂贵的模型用于构建，廉价的模型用于常规检查的评审，便宜的模型用于路由——通常是循环中真正成本节约的来源。大多数人认为成本控制意味着更少的循环或更少的修订。实际上，它来自于将模型成本与你已构建的循环中每个特定角色的实际难度相匹配。
第 17 步：扩展到第二个循环，而不是一次性做五个
第一个循环工作后，诱惑是立即再构建几个，并行处理五个不同的任务，因为架构技术上现在可以支持了。抵制这个诱惑的时间要比你感觉舒服的更久。让一个循环运行得足够可靠，以至于你真正停止了仔细检查它的输出——这意味着它在一段真实的时间内持续通过了你自己手动抽查，而不仅仅是每个人恰好都关注的单次成功演示运行。只有到了那时，才开始第二个循环，处理一个不同的任务，理想情况下，是一个与第一个完全不同任务映射上的任务，这样你就是在测试底层骨架是否具有通用性，而不是仅仅进一步调优同一个任务。
第 18 步：为自己提供所有正在运行的循环的共享视图
一旦你有多个循环在运行，跟踪所有循环的成本和停止条件触发情况的共享视图，而不是孤立地看每个循环。一个具有合理单任务预算的循环，单独看起来完全没问题。十个各自在预算内的循环，其总和仍然可能达到惊人的总数，而无人注意到，直到总账单到达——正是因为每个单独循环的跟踪看起来都正常。
具体记录每一次停止条件触发，而不仅仅是成功完成。如果一个循环持续撞到其修订上限，而其他循环很少发生，这告诉你它的评审官标准校准有误——太严格以至于永远无法通过，或者完全对照错误的事实依据进行检查——而不是说底层任务本身就很难。如果你只跟踪成功，并将每次升级视为一个孤立、不显眼的事件，而不是关于该特定循环设计的数据点，那么这个模式是看不见的。
第五阶段：成为系统设计师（第 19 步和第 20 步）
第 19 步：停止用编写的提示词数量来衡量自己
转变已经发生的最明显迹象，是你日常关注点的变化。一个提示词工程师会跟踪自己写了多少个好的提示词。一个系统设计师会跟踪有多少个循环在运行、每个循环的可靠性如何、以及有多少自己的时间被那些不再需要监督的系统归还给了自己。如果你仍然在用输入的提示词数量来衡量自己的生产力，那么无论你技术上构建了多少个循环，第一步的思维转变都还没有完全落实。
第 20 步：教会别人这五个步骤
最后一步实际上不再是关于你自己的系统。它是在确认你是否真的内化了这个转变，方法是不使用行话向别人解释它。发现、交接、验证、持久化、调度。如果你能仅使用这五个步骤和上述步骤，引导另一个人构建他们自己的第一个循环，那么你已经完成了本路线图所描述的实际转变。你不再是在循环内部输入下一条指令的人。你是设计它的人，站在外面，看着它运行。
如果你跳步会无声累积的四种成本
值得以一个警告来结束，因为在本路线图中跳步不会大声地失败，它会安静地失败，其后果只在很久以后才会显现。
验证债务当你跳过第 6 步和第 7 步时累积——构建没有真正评审官或没有真正事实依据的循环。循环看起来在正常工作，因为输出看起来没问题，直到一个错误在几十次运行中无声累积，才有人注意到。
理解衰退当你跳过第 20 步时出现——运行着你曾经构建过一次，但如果它坏了，你再也无法解释或调试的循环，因为你从未真正内化每个组件存在的原因。
认知投降当第 1 步从未真正扎根时发生——当你在验证系统已经证明自己之后很长一段时间里，仍然出于习惯手动双重检查每个输出，从而完全违背了构建系统的初衷。
令牌爆炸是当你跳过第 10 步时会发生的事情——运行没有真正停止条件的循环，只有在账单到来时才发现实际成本。
这些成本中的每一个都是可以避免的，而且每一个都可以通过同样的纪律来避免。按顺序构建步骤。不要跳过那些看起来不耀眼的步骤。那些无聊的步骤——完成标准、停止条件、事实依据——才是真正起作用的。那些听起来有趣的部分——巧妙的提示词、复杂的架构图——远不如你构建的系统是否真正知道何时正确、何时错误以及何时停止来得重要。
这就是提示词工程师和系统设计师之间的全部区别。不是聪明才智。而是对于构建起来很无聊、很容易被跳过的部分的纪律。
关注 @cyrilXBT 获取本路线图中每一步背后的精确循环模板和构建者-评审官-管理者设置。
