Command Palette
Search for a command to run...
Loop Engineering：Anthropic 设计智能体提示系统的方法论
Loop Engineering：Anthropic 设计智能体提示系统的方法论
Peter Steinberger Boris Cherny Addy Osmani
摘要
过去两年中，一系列以“XX工程”命名的术语紧随模型发布的节奏涌现。本文旨在考察其中最新出现的一个概念——“循环工程”（Loop Engineering）。该术语于2026年6月由Peter Steinberger、Boris Cherny和Addy Osmani独立提出，并由Osmani在书面形式中正式命名。与提示工程（prompt engineering）、上下文工程（context engineering）或测试台工程（harness engineering）不同，循环工程并非教导从业者如何更出色地完成任务，而是将从业者从直接执行任务的位置上移除。我们对该术语进行定义，将其定位为位于测试台（harness）之上的第四层架构，并将单次循环分解为五个关键步骤——发现（discovery）、移交（handoff）、验证（verification）、持久化（persistence）和调度（scheduling）——以及实现这些步骤的六个组成部分。我们特别关注生成器与评估器的分离：实证表明，要求Agent对自身输出进行评分时，往往倾向于给予好评；相比之下，调整一个独立的、持怀疑态度的评估器（evaluator）比促使生成器批判性地审视自身工作更为可行。本文调研了三个在实践运行的Loop案例，涵盖从一位工程师的晨间分类处理到Stripe企业级Pipeline每周合并超过1,300个机器生成的Pull Request的流程。同时，我们梳理了四个隐性累积的成本：验证债务（verification debt）、理解腐烂（comprehension rot）、认知屈服（cognitive surrender）以及Token爆炸（token blowout）。最后，本文提供了一份构建首个Loop的具体方案。核心观点在于：Loop使生成过程近乎零成本，而将判断力作为稀缺资源；同一个Loop，由不同的人构建，可能会产生截然相反的结果。
一句话总结
本文中，Peter Steinberger、Boris Cherny 与 Addy Osmani 将 Loop Engineering 引入为 Harness Engineering 之上的第四层，通过设计自我提示的 agent 循环，使从业者无需直接执行工作，并将每个回合分解为发现、移交、验证、持久化与调度，关键是将生成器与评估器分离，因为 agent 对自己产出的评分往往偏向自我赞扬。文章还考察了现实世界中的循环，从个人晨间事务分类到 Stripe 每周合并超过 1,300 个机器编写的拉取请求的流水线，表明循环使生成几乎免费，而判断力成为稀缺资源，且同一循环在不同人手中可能产生相反的结果。
核心贡献
- 本文将 loop engineering 定义为 harness engineering 之上的第四层，将一个循环回合分解为五个动作（发现、移交、验证、持久化、调度）和六个组成部分。
- 引入了生成器/评估器分离，实验表明 agent 会过度赞扬自己的输出，而独立调优的、持怀疑态度的评估器远比让生成器自我批判更容易实现。
- 文章调研了三个真实世界的循环，列举了四种隐藏成本（验证债务、理解衰退、认知放弃、token 激增），提供了具体的构建方法，并确立了循环使生成几乎免费，从而将工程价值集中于作为稀缺资源的判断力。
引言
作者审视了一种称为 Loop Engineering 的新范式，它将从业者从直接提示 AI 编码 agent 转变为设计能自我提示的自主系统。这之所以重要，是因为早期的提示工程、上下文工程和 harness engineering 方法都将人类保留在循环中，限制了可扩展性并需要持续关注。先前工作的关键局限在于人类必须充当时钟和决策者，无法脱身。作者的主要贡献是对 loop engineering 的正式定义、将循环回合分解为五个动作（发现、移交、验证、持久化与调度），以及强调生成器/评估器分离，从而在自动化生成的同时保持判断力。
方法
作者提出了一个用于工程化 AI agent 的分层框架，最终形成自我运行的循环架构。该框架由四个不同的层次堆叠而成，每一层都扩展了关注范围。如下图所示，该堆栈从底层的提示工程开始，经过上下文工程和 harness engineering，最终到达顶层的 loop engineering。
提示工程管理单次交互的措辞。上下文工程策划模型的视野范围。Harness engineering 为单次运行配备工具和动作。Loop engineering 则自动化整个过程，使系统能够按计划唤醒、生成子 agent，并将自身输出作为后续轮次的输入反馈。
一个功能完善的循环会执行由五个动作组成的具体周期，而非空转。如下图所示，这些动作形成一个连续的回合，为下一次迭代提供输入。
首先，发现识别值得做的工作，例如读取 CI 失败信息，使 agent 能够找到自己的任务。其次，移交将任务移至隔离环境（如 git worktree），以防止并行执行时的冲突。第三，验证检查结果，作为拒绝不良输出的关键机制。第四，持久化将状态保存到磁盘，使循环在上下文窗口清空后仍能存活。最后，调度自动触发下一回合。
为了实现这些动作，该架构依赖六个结构部件。自动化基于时间或事件触发循环。Worktree 为并行 agent 提供隔离。技能存储永久项目知识以减少意图债务。连接器通过 MCP 等协议将循环与外部工具连接。子 agent 将编写者与评判者分开。记忆确保状态在对话窗口之外跨天持久化。
最关键的架构决策涉及验证模块。作者指出，agent 倾向于赞扬自己的工作，导致出现“点头循环”，错误不断累积。为解决此问题，该框架采用了 Maker-Checker 原则。如下图所示，架构在结构上将 agent 分为生成器和评估器。
生成器编写代码。评估器（通常是另一个被指示假设代码有问题的模型）对其进行审查。关键的是，评估器通过运行测试或检查 DOM 来行动，而非仅仅阅读代码。
停止条件由一个全新的模型检查是否达到特定目标来管理。下面的代码片段展示了这一逻辑，其中一个小型快速模型在每个回合后检查条件。
为了大规模可靠性，作者描述了 Stripe Minions 流水线。该架构将确定性门控与概率性 LLM 步骤交错进行。如流水线图所示，流程从人类触发开始，随后由确定性编排器组装上下文。
LLM agent 编写代码，但随后立即运行一个硬编码的门控；agent 无法跳过此步骤。如果 lint 检查失败，agent 会进行修复。最后，一个硬编码步骤提交代码，随后进行人工审查。这种结构确保可靠性来自约束的质量，而非仅仅模型规模。
实验
评估对比了本地循环/桌面定时任务与云例程以及 GitHub Actions 定时触发器，用于在用户睡眠时运行后台工作。本地调度要求机器保持开机，但能实现频繁执行并直接访问本地文件；而云调度脱离本地状态运行，代价是最小间隔为一小时且每次都是全新克隆。比较表明，没有单一调度器能满足所有需求，并警告广泛流传的二手指标应被视为粗略参考，突显一手来源的更高可靠性。