本文的 Loop Engineering 取工程视角：持久 Agent 自动化的工程抽象，包括定时触发、长期运行、多会话并发、可恢复状态、权限边界、验证证据和人工升级路径。Claude 官方在 Getting Started with loops 里给出的 4 种循环分类（Turn-based / Goal-based / Time-based / Proactive）是操作视角的互补坐标系，见后文「循环的 4 种触发形态」。

Loop Engineering cover

本文与已有文章的边界

本博客已有 Agent Loop、Ralph Loop、Goal、Harness Engineering、Hook 体系等相邻文章，本文专门讨论 Loop Engineering。和已有文章的边界：

已有文章 主要讨论 与本文的关系
AI Coding Agent 的 Hook、Loop 与插件体系 Codex、Claude Code、OpenCode、OMC 的运行时结构 写到 loop 与 hook，但没有以 /loops 和 Routines 的持久自动化为主线
持久 Agent：当任务活得比会话长 持久 agent 的定义、四道墙与三根支柱（状态、执行、调度） 提供「持久」的严格定义和恢复语义，本文在其上讨论 loop 的工程系统
ReAct：推理与行动交织的 Agent 循环原型 单条轨迹内的 thought-action-observation 内环 提供 model loop 的论文源头，本文讨论内环之外的触发、状态与治理
Goal 模式深度研究 Goal、Ralph Loop、completion predicate 提供完成谓词和循环停止条件的基础
Harness Engineering：长程 Agent 的工程化底座 长程 Agent 的工具、状态、验证环境 为 loop 工程化讨论提供背景
Agentic Coding 深度解析 从代码补全到 Agentic Coding 提供开发范式迁移背景

/loops 和 Routines 改变了什么

Business Insider 在 2026-05-13 报道了 Boris Cherny 于 2026-05-04 在 Sequoia Capital 访谈中的展示。Boris 是 Claude Code 的创建者。报道里的几个信息点很集中：

  • 他通过 Claude App 里的 Code 标签页管理多个 Claude Code session。
  • 典型状态是 5 到 10 个 session 并行。
  • 每个 session 内又包含多个 agent。
  • 夜间会有数千个 agent 做更深的工作。
  • 他特别提到两个持久自动化特性：/loops 和 Routines。
  • /loops 可以在本地通过 cron 调度。
  • Routines 在服务器上运行 recurring tasks，笔记本关上以后仍能继续。

Boris 后来把这套做法说得更直接。据 2026 年多次公开访谈的转引（The Pragmatic Engineer 等做过整理），他不再逐条给 Claude 写 prompt，而是让一批 loop 跑着，由 loop 去 prompt Claude、决定下一步；用他自己的话说，“我的工作是写 loop”（“My job is to write loops”）。他还提到已有约八个月没手写过代码，给 Claude Code 的贡献几乎全部由 Claude Code 写成，并主张团队别在一开始抠 token，尽量给工程师足够额度。

这正是本文要展开的主线。prompt 一旦由 loop 生成，工程师的操作对象就从“这一句怎么写”变成“这个 loop 怎么设计”。据同一批转引，Boris 说的 loop 不是重放同一段指令，而是先给定任务、工具和验收测试，再让 agent 自己 prompt 自己、拿真实结果回填、不达标就继续，直到通过验收。人写的是 loop 的骨架，也就是触发、目标、验收和边界；prompt 退化成这具骨架每一轮临时长出来的东西。

这些信息说明，重点不是 “怎样把 prompt 写得更好”，也不是 “怎样让单个 coding agent 多试几次”。重点是把 coding agent 从一个交互式终端工具，推进到一种持久自动化系统。

这个变化很大。过去的主界面是：

1
human -> prompt -> agent -> diff -> human review

Boris 展示的主界面更像：

1
human -> recurring loop specs -> session fleet -> overnight work -> review queue

主界面的迁移：从单次 prompt 到循环编排

工程师不只是发起一次任务，而是在设计一组会定时启动、持续运行、留下结果、等待审阅的循环。

「Loop Engineering」这个说法从哪来

把这套实践叫做 Loop Engineering 的不止 Boris 一个人。2026 年年中，这个说法在几位一线从业者那里几乎同时成形，各自补上了 Boris 没细说的一面。

「Loop Engineering」这个词的流行通常被归到 Addy Osmani（Google）名下。他的表述和 Boris 互为印证：loop engineering 就是把“给 agent 写 prompt 的那个人”换掉，转而去设计那个替你 prompt 的系统。更有用的是他给出的 inner loop / outer loop 切分：agent 接管内层执行循环，也就是写、跑、改这一圈；人保留外层循环，决定什么该存在、什么样的证据算够、什么能上线、谁为后果负责。这条切分和本文后面的四层循环、证据门、人工升级说的是同一件事。自动化能吃掉内层，吃不掉外层的判断和问责。

Osmani 同时是这套乐观叙事里踩刹车的人。他更早提出的“70% 问题”是说，AI 能可靠地把活干到七成，剩下三成的边界情况、架构和打磨仍然又慢又靠人。这正好戳中 loop 的软肋：loop 只会让代码产得更快，而验证本来就是瓶颈；把更多产物推过同一个审阅口，只会让这个口更堵。这和本文后面“loop 是放大器，不是质量保证”是同一个判断。

另一个高声量来源是 Peter Steinberger（@steipete），OpenClaw 的作者。他卖掉 PSPDFKit 后一度退隐，2026 年以做 agent 重新出现。OpenClaw 是他做的开源、自托管、常驻个人 agent 网关：挂在自己机器上长期运行，接管消息、日程和命令执行，本身就是一个“持久 agent”的极端样本。他的口号几乎是 Boris 那句的另一半：别再给 coding agent 写 prompt，去设计那些替你 prompt 的 loop。他也较早把讨论往前推，在很多人还谈单条 loop 时就开始问是不是该从 loop 切到 graph，把多 agent 从一条循环推向一张有向图。这对应的正是本文四层循环里 fleet loop 之上的问题：一堆 loop 之间怎么调度、怎么依赖、怎么汇总。

三个人放在一起，Loop Engineering 就不只是某一家产品的功能宣传，而是被多方独立复述的一条工程判断：主战场从写 prompt 移到设计 loop。他们之间也有分歧。Boris 和 Steinberger 更靠近“放手让 loop 跑”的一端，Osmani 一直强调外层循环和验证瓶颈不会因为自动化变便宜。本文站在后者一侧：loop 值得做，但它的工程价值几乎全在那些约束它的结构里。

一个严格定义

Loop Engineering 是围绕持久 Agent 循环设计工程系统的实践。它回答的问题不是 “这一轮怎样提示模型”，而是：

  • 循环什么时候触发？
  • 每一轮拿到什么任务和上下文？
  • Agent 能看见哪些反馈？
  • Agent 能调用哪些工具？
  • 状态怎样跨 session、跨天、跨设备保存？
  • 什么证据能证明一项工作完成？
  • 失败以后是重试、修复、改计划、暂停，还是终止？
  • 多个 agent 并发产物怎样汇总、去重和验收？

更压缩的定义是：

1
Loop Engineering = trigger + task spec + observation surface + tool boundary + durable state + evidence gate + escalation path

这个定义刻意不把 “模型能力更强” 放在中心。模型能力是前提，循环工程关心的是模型之外的控制结构。

公式七要素的定义

判断一个 loop 系统是否完整，就是逐项检查这七件事有没有被显式设计。每个要素给出定义、它回答的问题和缺失时的症状。

Trigger（触发器）

决定循环何时开始一轮的机制，回答「谁、在什么条件下，启动这一轮」。载体分三类：时间（cron、/loop 5m、Routines 的 recurring schedule）、事件（CI 失败、PR 到达、issue 入队）、人工（实时 prompt）。触发器必须活在 agent 进程之外——活在本地终端里的触发器，翻不过设备离线和无人记得这两道墙（见持久 Agent一文的「四道墙」）。

缺失时的症状：任务依赖人记得发起，自动化名存实亡。

Task spec（任务规格）

每一轮开始时 agent 拿到的结构化任务说明，包括目标、范围、输入和验收标准，回答「这一轮该做什么、做到什么程度」。它和 prompt 的区别在可重复性：prompt 是一次性的自然语言表达，task spec 是可以被同一个 loop 每晚重复消费的工程文档，结构不变，变化的只是参数。后文的 loop spec YAML 是它的一种落盘形式。

缺失时的症状：每轮行为漂移，产物无法比较，失败无法归因。

Observation surface（观察面）

agent 能看见的全部反馈信号的集合——测试输出、构建日志、diff、截图、trace、指标，回答「agent 依据什么判断上一步的效果」。agent 只能修它看得见的失败，反馈信号没有信息量，循环就地卡死。设计原则和它的实验源头见后文「观察面」一节。

缺失时的症状：agent 靠猜测修复，同样的失败反复出现。

Tool boundary（工具边界）

agent 在一轮循环里被允许调用的工具集合，以及每个工具的权限范围，回答「agent 能做什么、不能做什么」。边界按最小权限拆成读、写、执行、网络、人工门五层（见后文权限一节）。循环越长、越无人值守，边界越要从「约定」硬化成「拦截」。

缺失时的症状：小任务获得了过大的破坏半径，夜间事故白天收拾。

Durable state（持久状态）

存活于 agent 进程之外、能让任意新 session 恢复任务的状态载体——progress 文件、git 历史、任务清单、证据账本，回答「这一轮结束后，下一轮从哪里接手」。上下文记忆不算 durable state：进程一退出就归零。状态只是持久性三根支柱之一，它和可恢复执行、调度怎么配合，见持久 Agent 一文。

缺失时的症状：每轮从零开始，长任务永远停在前 20%。

Evidence gate（证据门）

一组可机械检查的证据条件，全部满足才允许产物进入下一站（review 队列、合并、发布），回答「凭什么说这一轮的工作完成了」。证据是行为证据而不是模型自述：测试变绿、构建通过、截图匹配、性能达标。它是完成谓词（见 Goal 模式深度研究）在 loop 语境下的执行机构。

缺失时的症状：模型自宣完成，审阅者被迫替 agent 做质检。

Escalation path（升级路径）

循环自己处理不了时，把控制权连同上下文移交给人的预设通道，回答「什么情况必须停下来找人、找谁、带什么信息、得到什么答复后才能恢复」。典型的升级条件包括权限不足、证据冲突、连续同类失败、需要业务判断，以及下一步具有不可逆影响。

升级路径是一份控制权移交协议，内容比报错通知更完整。它至少要写清触发条件、接收人、随附的状态与证据、可供选择的下一步，以及恢复条件。失败降级和升级路径解决不同问题：降级规定完整目标不可达时，机器应该留下什么安全而有用的结果；升级路径规定下一步需要人类授权或判断时，控制权交给谁。升级属于恢复阶梯（见后文）里通向人类判断的一条分支；没有它，loop 只能在 retry 和 abort 之间二选一。

缺失时的症状：loop 要么无限重试烧预算，要么静默放弃留下半成品。

一个范例：/loop babysit all my PRs

2026-03-07 Boris 在 X 上发布 /loop 时给的第一个示例，就是这一条：/loop babysit all my PRs. Auto-fix build issues and when comments come in, use a worktree agent to fix them（盯着我所有的 PR，自动修构建问题，评论来了就派一个 worktree agent 去改）。/loop 把这条指令变成一个最长运行三天的 recurring 任务。这一行短句几乎把上面七个要素都点到了，值得逐项拆开。

  • Trigger：/loop 给它一个时间触发器，反复醒来，最长三天。
  • Task spec：目标是「所有 PR」，两件具体的活是「修构建」和「改评论」，每转变化的只是哪些 PR、什么评论，骨架不变。
  • Observation surface：它盯的是 CI 构建状态和 PR 上新到的 review 评论，这两样就是它每次醒来要读的反馈。
  • Tool boundary：改评论用 worktree agent，隔离在各自的工作树里，多个修复并行也不会互相踩，worktree 就是这里的边界。
  • Durable state：PR 和它们的分支本身就是状态，三天里每次醒来都从 PR 的当前状态接着干，不靠记忆。
  • Evidence gate：「auto-fix build issues」隐含了一道门，改到构建变绿为止，绿不了就继续。

真正有意思的是这句话没说的那部分：Escalation path。什么时候该停下来找人，评论互相矛盾、需要产品判断、同一个构建反复修不好，这条指令一个字没提。这恰恰是多数人写 loop 时漏掉的一环：好写的是前六个要素，难写、最容易被跳过的是第七个。Boris 的示例适合当起点，不适合直接搬去无人值守地跑三天。

Osmani 的六个组件

上面的七要素是设计维度，Osmani 那篇长文给的则是一份更偏基础设施的拆法：一个完整的工程化循环由六个组件搭成。两者不是竞争关系，而是两个视角：七要素问「每一轮要设计哪些东西」，六组件答「这些东西用什么零件搭出来」。

  • Automation（自动化触发器）：用定时或事件驱动让循环自己发现要干的活，比如从 GitHub Issues 检出未分类缺陷、从 CI 日志抓构建失败。它就是七要素里的 trigger，是整个循环的心跳；缺了它，agent 每次都要人踢一脚才动，那还是人在操控。
  • Worktree（工作树隔离）：给每个并发 agent 分一个独立的 git worktree，防止多个 agent 同时改同一文件时互相踩。Osmani 说这个组件最容易被忽视，可一旦多个 agent 同时跑，缺了它就是灾难性的合并冲突。它是 fleet loop 能并行的前提，详见后文多 Agent 并发一节。
  • Skills（技能文件）：把项目的构建步骤、代码规范和踩过的教训写进 SKILL.md，让每个新起的循环不必从零猜。它是 task spec 的可复用载体——同一个 loop 每晚消费同一份结构化知识，而不是靠人重述。
  • Connectors（连接器）：基于 MCP 把 agent 接到 issue 跟踪器、数据库、Slack 等外部系统，填平「告诉我该修什么」和「真去把那个 PR 开出来」之间的鸿沟。它同时扩了观察面（agent 能读到的信号）和行动半径（agent 能触达的系统）。
  • Sub-agents（子 agent 分离）：写代码的 agent 不能给自己的代码打分，Osmani 和 Cherny 都强调「写的那个太容易对自己手软」，必须由独立的审查 agent 来验。它是证据门的执行者：把「产出」和「验收」交给两个不同的 agent，甚至不同的模型。
  • State/Memory（状态与记忆）：用 Markdown 或 Linear board 持续记着做了什么、哪些验过、哪些还没完，让下一轮无缝接上。它就是 durable state，把进度放在进程外，任务才不随会话一起死。

Osmani 六组件与七要素的对应

把六组件和七要素对齐着看，会发现一件事：六组件里没有单独的一项叫「升级路径」。和 Boris 的 babysit 示例一样，什么时候把控制权交还给人，是这些拆法最常略过的一环。七要素把它单列出来，也把工具边界从 Worktree 这一个具体机制扩回到完整的权限分层，补的正是基础设施拆法容易留下的缺口。

循环的 4 种触发形态

把循环按“谁来触发、什么时候停止”分类，比按“循环多长”更容易选对工具。Claude 官方在 Getting Started with loops 里给出了一个清晰的坐标系：

形态 触发 停止 典型场景 主要载体
回合循环（Turn-based） 用户实时 prompt 模型自判完成或需要更多上下文 一次性短任务、探索、决策 单次会话 + Skills
目标循环（Goal-based） 实时 prompt + 显式目标 目标达成或回合上限 有可验证退出条件的中等任务 /goal
定时循环（Time-based） 时间间隔 用户取消或工作完成 重复任务、对接外部系统 /loop（本地）、/schedule（云端）
主动循环（Proactive） 事件或计划，无实时人工 单任务达标即退；routine 自身跑到关闭 大批量、定义良好的工作流 上述全部 + dynamic workflows

这 4 种形态和后文“四层循环”是正交关系。四层循环按时间尺度分层（Model / Task / Session / Fleet），关心“循环嵌套在哪一层”；4 种触发形态按控制方式分类，关心“循环由谁发起、由谁停止”。一个 fleet loop 既可能是定时触发的（夜间扫描依赖），也可能是事件触发的（PR 到达自动 review）。区分这两条坐标，能避免把“循环变长”误读成“循环变主动”。

四层循环的嵌套关系与两条正交轴

所谓「嵌套」：fleet loop 的一轮调度会启动若干 session，一个 session 里跑多个 task，每个 task 里模型要转很多圈 model loop。外层循环的一次迭代，等于内层循环的很多次完整运行，就像年历套着月历、月历套着日程表。触发形态不参与这个嵌套，它是从另一个方向切进来的坐标：无论哪一层的循环，都可以由人工回合、显式目标、定时器或外部事件来发起。

回合循环是默认形态，几乎所有 prompt 都从这里开始。让循环升级，本质是把手动的”下一回合”逐步交给目标、定时器或事件。Loop Engineering 的工程量，也随着这条升级路径陡增。

深读原文：四个必须厘清的概念

Primitive 不是计算机原语

原文把 Tool、Rule、Hook、Skill、Plugin、Subagent、Loop 都称为 “primitive”，容易被理解成七个平级的等价构件。此处的 primitive 是”构件基元”的含义，指”该层次上不可进一步拆解的最小单元”——每一层都有自己的 primitive，层与层之间是组合关系，不是平行替换关系。

七个构件分布在五个抽象层：

层 代表构件 层名 核心职能
1（底层） Tool 执行层 Claude 的单次原子能力（read、bash、web_search）
2 Rule + Hook 治理层 行为约束（Rule）+ 生命周期确定性拦截点（Hook）
3 Skill + Plugin 能力包层 可复用行为配方（Skill）+ 外部系统接入通道（Plugin/MCP）
4 Subagent 并发层 独立 Claude 进程，有自己的上下文，可并行运行
5（顶层） Loop 调度层 在时间维度上持续触发和编排下方所有构件的机制

Agent 构件五层抽象

从底层到顶层，每一层都依赖但不等价于下方层：工具是 hook 的被拦截对象，hook 是 skill 的触发上下文，skill 是 subagent 的执行配方，subagent 是 loop 的调度单元。把七个构件摊在同一张表里横向对比，这个垂直结构就消失了。

四种循环的真正差别

四种循环形态的分类轴有两条：谁来触发（X 轴）和谁来决定停止（Y 轴）。

Turn-based 和 Goal-based 都是人工触发，区别在完成判定：Turn-based 由模型自判”本回合完成”，Goal-based 有显式谓词（测试通过、构建成功、某文件存在），满足前持续尝试。Goal-based 和 Proactive 都有显式完成条件，区别在触发源：Goal-based 靠人发起 prompt，Proactive 由外部事件或计划驱动，工程师可以不在场。Time-based 是 Proactive 的子集，定时触发是外部事件触发的一种特殊情形。

四种 Loop 触发-完成坐标系

两个常见误读值得澄清：Goal-based 本身不要求启动 subagent，subagent 是独立的并发决策，与循环形态无关；四种形态下均可以自由选择单 agent 或多 subagent。Proactive 也不要求更强的模型，模型选择同样独立于循环形态，视当次任务复杂度而定。

/loop 5m 的触发机制

/loop 5m check my PR... 里的 5m 是轮询间隔，不是”Claude 持续跑 5 分钟”。底层机制分两种：

调用形式 底层机制 行为特征
/loop 5m <prompt> CronCreate（固定 cron） 每 5 分钟触发一次，session 内持续
/loop <prompt>（不带间隔） ScheduleWakeup（动态自选） Claude 根据任务自选延迟（60-3600s）

两者共同点：Claude 在两次触发之间处于休眠，零 token 消耗；唤醒时才读上下文、执行任务、消耗 token。Claude Code 不需要以后台进程方式持续运行，调度由 session 内的定时器或 ScheduleWakeup 机制维护。

Anthropic Prompt Cache 的 TTL 是 300 秒（5 分钟）。/loop 5m 恰好落在这个边界：每次唤醒时 cache 刚好过期，既付了 cache miss 的代价，又没有换来更长的休眠来摊销成本。ScheduleWakeup 的推荐策略是睡 270 秒以内（保持 cache 热态）或一次性睡 1200 秒以上（摊销 cache miss）。5m 落在两段之间，是最差的选点。

/loop 触发时序与 Token 消耗模式

本地 /loop 存活于当前 Claude Code session，关闭终端或 session 超时后 loop 停止。Routines 在服务器侧运行，这是两者最本质的区别——Boris Cherny 提到 Routines 的根本原因也在这里。

pilot 是先导批次

官方博文 “Pilot before a large run” 里的 pilot 是工程术语：大规模启动前先运行 5-10 个子任务，观察 token 用量、失败模式、产物质量，确认无误再扩到数百。这和”副驾驶”意义上的 co-pilot 没有关系——pilot 在这里是动词，”先小批次试跑一下”，不涉及 AI pair-programming 工具的含义。

工程类比是制造业的先导试产：量产前用少量样品跑出良率数据，再做批量决策。对 agent fleet 来说，先导批次的目的是把未知的失败模式和成本惊喜控制在可接受范围内，再做规模决策。

从 Prompt 到 Loop

Prompt Engineering、Context Engineering、Harness Engineering 和 Loop Engineering 的边界可以这样拆：

概念 核心问题 典型产物
Prompt Engineering 一次请求该怎么表达 prompt 模板、few-shot、指令文本
Context Engineering 本轮该给模型看什么 文件摘录、检索结果、历史压缩、工具输出
Harness Engineering 模型外部的运行环境是什么 sandbox、工具、权限、状态、验证脚本
Loop Engineering 多轮、定时、长期、并发的 Agent 工作怎样推进和停止 loop spec、调度器、证据账本、恢复阶梯、review queue

Boris 的 /loops 和 Routines 把注意力从前两层推向第四层。一次 prompt 可以解决一个局部任务；一组可调度的 loop 可以承接持续任务，例如：

  • 每晚扫描依赖升级和安全公告。
  • 定期把 issue 分解成候选 patch。
  • 持续跑失败测试并生成修复分支。
  • 每天审查主干上的复杂度增长。
  • 在不同 session 中探索同一问题的多个解法。
  • 把长文章、长 PR、长迁移拆成可审阅的产物队列。

这些任务的共同点是：它们不适合停留在聊天窗口里，也不应该靠人手每天重复发同一段 prompt。

这四层还可以按各自吃重的学科来看：Prompt 吃语言表达，Context 吃信息的筛选与组织，Harness 吃系统设计与规则制定，Loop 吃的则是目标定义与管理。越往后，纯写代码的比重越小，把模糊意图翻译成可验证完成条件的比重越大。

Loop 的骨架里最难写的部分不是触发器或调度脚本，而是目标本身（后文「完成谓词比目标描述更重要」一节会展开）。这本质是管理学的老问题：Drucker 的目标管理、Grove 在 Intel 推的 OKR，核心都是把模糊意图翻译成可衡量、可验证的完成条件。好 loop 的三个要素也正好对上管理的三条——目标清晰对应完成谓词写得精准，资源充足对应给 agent 配好工具、连接器和权限，反馈及时对应每轮都有独立验证告诉 agent 哪里要改。区别在于管 agent 比管人更极端：人会主动来问「这需求我没太懂」，agent 只会自信地按自己的理解跑完，再自信地报告做完了。

/loops 和 Routines 为什么是分水岭

/loops 的关键不是 “循环” 二字，而是调度入口。按照 Business Insider 的报道，它可以被本地 cron 调度。这意味着 Claude Code 可以进入 Unix 式自动化生态：时间、脚本、仓库、日志、文件系统和开发工具链都能成为循环的一部分。

Routines 的关键不是 “服务器” 二字，而是设备解耦。任务在服务器上作为 recurring tasks 继续运行，笔记本是否打开不再是边界。移动端只负责发起、查看、分配和验收。

两者放在一起，产生了新的工作形态：

Loop 工程全景流程

这个图里最重要的不是 agent 数量，而是 gate。没有证据门，夜间自动化只是把白天的混乱搬到晚上。

四层循环

Boris 展示的是一组循环叠在一起。

层级 循环对象 典型周期 主要风险
Model loop 模型调用工具，读结果，再调用工具 秒到分钟 工具误用、上下文漂移
Task loop 一个任务反复尝试、修复、验证 分钟到小时 自宣完成、重复失败
Session loop 一个 session 承接一组相关任务 小时到天 状态遗失、目标漂移
Fleet loop 多 session、多 agent 并行工作 夜间、每日、每周 冲突、成本、质量退化、审阅过载

层名取自「每转一圈消耗的单元」。Model loop 里一圈就是一次模型调用：调模型、执行工具、结果回填、再调模型，循环体的主角是那次 LLM 调用，所以叫 model loop。这一圈可以理解成消息序列意义上的一个 turn，每次调用产出一条 assistant 消息，工具结果回填又追加一条消息；但它不是前文触发形态表里「回合循环」的那个回合，后者指用户发一次 prompt 到 agent 停下来的完整往返，一个这样的回合内部要转很多圈 model loop。Fleet 借自运维术语（fleet of servers、fleet management，本义是车队），指一组被统一调度的 agent 实例——Boris 说的 “a few thousand agents overnight” 就是一支 fleet，这一层的一圈是一轮调度：派出一批 session，收回一批结果。中间两层同理，task loop 一圈是一次任务尝试，session loop 一圈是一个会话。

日常聊天里你只感知得到 model 和 session，中间那层 task 并不是多余的，只是被压扁了。model 按调用边界划分，session 按对话边界划分，而 task 按另一个标准划分：完成谓词。下图把三层的划分依据、“一圈”的含义、以及 task 为何在日常里看不见摆在一起。

model / task / session 三层的划分依据与 task 为何日常看不见

task 的完成谓词这一层正是 Goal 模式 那篇讲的东西：model loop 会自宣完成，task loop 不认自宣只认证据。

多数讨论只盯着第一层，也就是 “agent 内部怎样 while-loop”。这一层的原型是 ReAct：thought、action、observation 交织的单轨迹循环，2022 年就已定型。Boris 的宣传把视角拉到了第三层和第四层。真正的新鲜感来自 fleet loop：工程师需要管理一组 agent 的工作流，而不是盯着一个 agent 的输出。

这也解释了为什么 “a few thousand agents overnight” 听起来惊人。数字本身不是方法论，背后的方法论是把深度工作拆成可调度、可并行、可验收的循环。

官方运行时的共同方向

这个趋势不是 Claude Code 独有。多个系统正在把 loop 周围的工程结构做厚。

OpenAI 在 “Unrolling the Codex agent loop” 中把 coding agent 的内循环拆成输入、推理、工具调用、工具结果回填、再次推理、最终停止。文章也强调，Agent 的输出不只是最终文本回复，很多时候真正的产物是写入本地工作区的代码。因此，停止条件不能只看模型是否回复，而要看文件系统、命令结果和验证证据。

Anthropic 的 “Building effective agents” 提醒了另一条边界：工作流适合路径明确的问题，Agent 适合开放问题；开放性带来成本和复合错误风险。因此检查点、阻塞点、停止条件、沙箱和人工审阅不是装饰，而是让 Agent 进入真实工程流程的约束。

Claude Code Hooks 把生命周期事件开放给用户。Hook 可以在特定事件上接收 JSON context，执行命令或返回决策。它的工程意义在于：确定性控制点被插入不确定的 Agent 行动链。

OpenCode 的 permissions 文档把 doom_loop 变成权限项：同样工具调用、同样输入重复三次后触发询问。这个设计直接说明，循环失控不是抽象风险，而是应该进入权限系统的运行时状态。

Google ADK 的 LoopAgent 把循环作为 workflow agent 暴露，并通过 exit_loop 工具设置退出语义。LangGraph 则把 durable execution、persistence、interrupt 和 thread 恢复作为长程 Agent 的底座。

这些设计都指向同一件事：可靠的 Agent 系统不会把 “继续试试” 交给模型直觉，而是把继续、停止、暂停、升级、恢复做成运行时语义。

Loop Spec：持久循环的最小单元

一个可运行的 loop 不应该只有 prompt。它至少需要一个 spec。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
name: nightly-dependency-scout
trigger:
  kind: cron
  schedule: "0 2 * * *"
scope:
  repos:
    - product-api
    - product-web
authority:
  read:
    - package manifests
    - lockfiles
    - changelogs
  write:
    - reports/dependency-scout.md
    - candidate branches
  denied:
    - production deploy
    - secret files
objective:
  outcome: "降低依赖老化带来的安全与维护风险"
  phase_result: "生成升级清单、风险说明和低风险候选分支"
acceptance:
  checks:
    - "测试与构建通过"
    - "每个候选项都有风险、验证建议和回滚路径"
  evidence:
    - "命令、退出码和摘要可供复核"
non_goals:
  - "不自动合并候选分支"
  - "不处理需要产品决策的破坏性升级"
invariants:
  - "不删除、跳过或放宽既有测试"
  - "不修改生产配置和凭证"
observation:
  commands:
    - "npm test"
    - "npm run build"
    - "npm audit --json"
budget:
  max_runtime_minutes: 90
  max_branches: 5
recovery:
  retry:
    max_attempts: 2
  fallback:
    verification_unavailable: "保留报告和当前证据，暂停等待审阅"
    repeated_failure: "停止改动，输出失败分类和建议下一步"
  pause_when:
    - "需要生产凭证"
    - "依赖许可证不明确"
    - "测试环境不可用"
escalation:
  trigger:
    - "需要不可逆操作"
    - "证据冲突或需要业务判断"
  route: "负责该领域的审阅者"
  include: "当前状态、已尝试方案、证据和建议选项"
  resume_when: "审阅者给出明确决策或补足权限"
review:
  output: "dependency review queue"

这个 spec 的价值来自一份完整、可审计的定义：objective 解释为什么做，acceptance 决定何时算完成，non_goals 缩小本轮责任范围，权限和 invariants 排除不允许的解法，fallback 规定无法完成时怎样安全收束，escalation 则定义何时以及怎样把决定交还给人。

目标要写成可执行契约

持久 loop 最容易犯的错误，是把目标写成愿望：

1
帮忙优化代码质量。

这类目标无法停止，也无法验收。更可用的写法是：

1
找出过去 7 天新增的复杂函数。只生成报告和候选重构分支。每个候选分支必须通过现有测试，且公开 API diff 为空。无法验证时暂停，不合并。

这段话同时给出了正向完成标准、执行边界和失败后的动作。只有正向目标，没有执行边界、约束和降级路径，loop 仍然可能用错误的方法得到一个看似正确的结果。

目标可以分成四层：

层级 回答的问题 例子
结果层 最终想改变什么 降低新增复杂代码带来的维护风险
产物层 这一阶段交付什么 风险报告和候选重构分支
检查层 机器怎样判定产物合格 现有测试通过，公开 API diff 为空
证据层 人或下一轮凭什么复核 命令、退出码、diff、报告和失败记录

四层不能互相替代。检查通过只能证明某个检查项为真，不能自动证明最终结果已经发生；产物生成也不等于产物合格。层级的作用，是让 loop 每次停下时都能回答：达成的是哪一层，还缺哪一层。

目标分层源于四层陈述的证明力度不同，loop 本身是否分层不是前提。结果层表达价值，通常要经过一段时间才能判断；产物层是当前阶段能够控制的交付；检查层要求机器给出明确的真假；证据层让这个真假可以被复核和恢复。把它们压成一句“完成了”，很容易用局部检查通过冒充整体目标达成。

目标层级和 loop 层级是两条不同的轴，但运行时常会对齐：task loop 用检查和证据决定停止，session 交付一个阶段产物，更外层的调度与人工审阅判断最终结果。分批也只是执行方式，一批工作可以对应一个阶段产物，也可以只完成其中一部分；批次本身不会自动成为目标层级。

一份可执行目标至少要把下面六类信息放在一起：

维度 问题 示例
完成标准 什么现象算完成，机器怎样检查 测试通过、页面可操作、性能达到阈值
Non-goal 本轮明确不解决什么、不交付什么 不迁移数据库，不重构无关模块，不负责自动发布
执行边界 Agent 可以在哪些范围内行动 只改指定目录和候选分支，不访问生产环境和凭证，遵守时间与预算上限
不变量与副作用预算 即使能让检查通过，也不能破坏什么 不改公开 API，不删除或跳过测试，外部操作必须可回滚
失败降级 达不到完整目标时怎样收束 限次重试；仍失败则保留证据、输出报告并暂停
复核证据 人类或下一轮看到什么 命令与退出码、diff、截图、风险列表、失败分类

Non-goal 和执行边界经常一起出现，但含义不同。Non-goal 排除的是结果和责任，例如“本轮不做数据库迁移”；执行边界规定行动空间，例如“只允许改指定目录，不访问生产环境”。至于“不删除测试”“不放宽阈值”，更准确地说是不变量或禁止手段。把三者都塞进 Non-goal 也能工作，但拆开以后更容易做机器检查和权限拦截。

“执行边界”与测试语境里的 edge case、corner case 指向不同问题。edge case 通常指某一个输入或状态维度落在边缘，例如空列表、最大长度、零余额；corner case 通常由多个边缘条件叠加，例如最大批量下同时发生重试和并发更新（这几个术语各自的老家和分界，另见《各种各样的 Case：一份工程术语家谱》）。它们属于完成标准的覆盖范围，应该落实为测试或检查项。执行边界更宽，描述的是 loop 的 operating envelope：允许改哪些对象、使用哪些工具、进入哪些环境、消耗多少预算、产生多大副作用。

完成标准、Non-goal、执行边界和不变量需要一起定义。完成标准给出终点，Non-goal 缩小责任范围，执行边界限制活动空间，不变量封死投机近路。测试全部通过，却靠删除失败测试换来，仍然不能算完成。

Non-goal、阻塞和降级分别处理三个问题。Non-goal 规定不能走哪条路；阻塞说明当前为什么走不下去；降级则规定走不下去以后留下什么结果。一个环境暂时不可用，属于阻塞；保存已完成的分析和验证记录、暂停等待条件恢复，属于降级；把“没有验证”改写成“验证通过”，只是降低了完成标准。

成熟的降级策略只改变交付形态和运行状态，验收线保持不变。完整修复做不到，可以退到候选方案、诊断报告或可恢复的暂停状态；这些都必须明确标成未完成，并带上恢复所需的证据。

这里还要划一条边界：失败降级可以写进目标契约，因为它规定完整目标未达成时允许交付什么；升级路径属于 loop 的控制契约，因为它规定机器无权继续决定时由谁接管。它不改变“什么叫完成”，只改变“谁来决定下一步”。

没有这组目标契约的 loop，会把“完成”交给模型自述，把“失败”交给无限重试。长程 Agent 最不该依赖的就是这两件事。

证据门会被钻空子

完成谓词把「做完了」交给可机械检查的证据，但证据本身可能被 agent 优化，而不是被满足。这是古德哈特定律在 loop 里的翻版：一个衡量指标一旦变成目标，就不再是好指标。

最常被举的例子是「让所有测试通过」这条谓词。agent 修不动某个 bug 时，一个从证据角度完全合法的解法是直接删掉失败的测试——测试全绿，谓词满足，真正的问题原封不动。人也会钻这种空子，只是 agent 做得更快、更彻底、也更没有心理负担。

所以完成谓词不能只有「做到什么」，还要有「不能怎么做」的边界。这正是 Harness 在 loop 里的位置：Loop 提供往目标跑的驱动力，Harness 提供不许越界的护栏，两者缺一，证据门就会退化成一场表演给人看的仪式。前面 loop spec 里的 non_goals、invariants 和权限边界，就是这道护栏的落盘形式。

观察面：Agent 只能修它看得见的失败

Loop Engineering 的第二个核心是 observation surface。测试、日志、截图、trace、diff、指标和错误报告都属于观察面。

这个概念的定量证据早在 2022 年就有了。ReAct 的人工错误分析显示，23% 的失败轨迹既不是模型推理出错，也不是工具执行出错，而是检索返回了无信息的结果——反馈信号没有信息量，循环就地卡死。观察面质量从 agent 循环诞生的第一天起就是它的上限。

坏观察面会把 Agent 推向猜测：

  • “页面不对。”
  • “接口偶尔失败。”
  • “代码有点乱。”
  • “性能变差了。”

好观察面会把信号、上下文和下一步放在一起：

原始信号 任务上下文 失败标签 下一步
单测断言差异 当前任务影响订单金额计算 contract mismatch 定位 failing case 和金额计算分支
E2E 截图 登录后进入支付页 route mismatch 检查跳转条件和 auth state
构建日志 只允许改前端组件 type error 定位文件行号和类型来源
权限拦截 不允许读 .env unauthorized action 生成需要的非敏感替代输入
连续同参调用 三次同样工具输入 doom loop 停止重试，改计划

观察面不是把更多日志塞给模型。观察面是把世界压成 Agent 能行动的反馈。

权限：循环越长，边界越硬

一次人工监督下的改动，风险可以靠人在旁边盯住。夜间自动化不能这样做。循环越长，越需要显式权限。

最小权限模型可以拆成五层：

层 允许 拒绝
Read 仓库、文档、公开依赖信息 secret、私有凭证、生产数据
Write 指定报告、候选分支、临时文件 主干直推、生产配置、共享状态文件
Execute 测试、构建、静态分析 部署、账单操作、破坏性清理
Network 官方文档、包元数据、安全公告 未授权外发、未知上传
Human gate 需要判断时暂停 伪造 approval、绕过审阅

OpenCode 的 doom_loop 权限项给了一个很好的提示：权限系统不只管 “能不能访问文件”，还可以管 “当前循环状态是否危险”。重复、越权、成本异常、质量退化都应该成为权限信号。

状态：不要把长期任务寄存在聊天上下文里

Boris 的多 session 工作流天然要求状态持久化。一个夜间任务启动时，需要知道：

  • 当前目标是什么。
  • 上一轮改了哪些文件。
  • 哪些验证已经跑过。
  • 哪些失败已经分类。
  • 哪些分支或报告等着审阅。
  • 哪些事情需要人类判断。

聊天记录能保留过程，但不一定能保留恢复点。Loop Engineering 需要的是恢复状态。

1
2
3
4
5
6
7
8
9
10
state = {
  goal,
  current_plan,
  decisions,
  changed_files,
  evidence,
  failed_attempts,
  blockers,
  next_step
}

Ralph Loop 的朴素价值就在这里。Geoffrey Huntley 的 “Everything is a Ralph Loop” 和 open-ralph-wiggum 都强调，下一轮可以通过文件系统、Git 历史和代码变化继续，而不是靠一段无限膨胀的对话记忆继续。Claude Code、Codex、OpenCode 这类本地 coding agent 天然适合这种模式，因为代码库本身就是状态载体。

LangGraph 的 persistence 和 interrupt 则展示了更平台化的做法：图运行可以暂停，状态由 checkpointer 保存，再用同一个 thread 恢复。具体框架不同，原则一致：长期循环需要可恢复状态，不能只依赖模型记忆。

可恢复状态只是持久性的一根支柱。状态、执行、调度三根支柱怎么配合，checkpoint 和 event sourcing 在恢复语义上差在哪里，展开讨论见持久 Agent：当任务活得比会话长。其中恢复语义对 loop 设计有直接影响：崩溃恢复本质是重试，任何副作用都可能执行不止一次，所以夜间无人值守的 loop 里，每个副作用要么天然幂等，要么显式去重，要么被推到人工门后面。这条约束直接决定了下一节恢复阶梯里 retry 这一级的适用范围。

恢复阶梯：失败以后不只有 retry

自动循环最常见的失败动作是 “再跑一次”。这在临时网络错误上有效，在设计错误、权限不足、需求冲突上只会浪费预算。

持久 loop 运行得越久，遇到外部服务波动、环境缺失、证据冲突和权限边界的概率就越高。失败如果只有“成功”和“彻底放弃”两种结果，已经完成的分析、可复用的证据和明确的阻塞原因都会丢失；如果一律重试，成本、副作用和破坏半径又会持续放大。因此，失败策略需要成为 loop 的正常运行语义，而不是最后补上的异常处理。

一条实用的恢复阶梯如下：

分类 条件 动作
Retry 临时失败，重试可能恢复 限次重跑，记录原因
Repair 失败原因明确，权限足够 修改实现、测试夹具或配置
Replan 同一路径多次失败 缩小目标，换方案
Fallback 完整目标不可达，但存在安全且有用的次级产物 输出候选方案、诊断或报告，明确标记未完成
Pause 外部条件暂时不满足，或正在等待决定 保存状态、证据和恢复入口
Escalate 下一步需要权限、业务判断或风险承诺 把状态、证据和可选方案交给指定审阅者
Abort 目标冲突、风险超限、证据不足 停止并报告已知事实

失败降级改变的是交付形态和运行状态，不是完成谓词。完整修复降级成候选补丁或诊断报告以后，原目标仍然是“未完成”；没有验证的结果也不能因为降级而改写成“已验证”。它的价值在于保留已经获得的事实，限制继续尝试的成本和副作用，并给下一轮留下可恢复的起点。

升级路径之所以单独存在，是因为有些下一步无法由机器安全决定。规则可以判断“测试是否通过”，却不能自行授予凭证、裁决相互冲突的业务要求、接受超预算风险，或批准不可逆操作。遇到这类边界，继续自动执行和直接放弃都不合适，控制权需要有方向地回到能够承担决定的人手里。

Pause 是状态，Escalate 是路由。只有暂停、没有升级路径，任务会变成无人认领的静默死信；只有升级通知、没有持久状态和证据，接手的人又得从头重建现场。两者配合后，失败处理才形成闭环：机器先分类并做限次恢复，完整目标仍不可达时安全降级，需要新授权或判断时升级，随后根据人的决定恢复或终止。

1
2
3
4
5
failure policy = classification
               + bounded recovery
               + safe fallback
               + escalation
               + resume or abort semantics

这个阶梯看似普通，却是 /loops 和 Routines 进入生产工作流的门槛。没有恢复阶梯，持久自动化只是在持续消耗上下文、token 和审阅注意力；没有升级路径，它也无法穿过自动化权限和判断力的边界。

多 Agent 并发的真正瓶颈

Boris 说夜间有数千个 agent 做 deeper work，最容易被误读成 “agent 越多越好”。工程问题恰好相反：并发越多，整合越难。

多 Agent loop 至少要处理这些问题：

问题 表现 工程处理
重复劳动 多个 agent 修同一个点 task shard、claim lock、去重报告
冲突编辑 多个分支改同一文件 worktree 隔离、merge gate、ownership map
局部最优 每个 agent 都通过自己的测试 集成测试、主干回放、端到端验证
审阅过载 夜间生成大量 diff 优先级排序、批量摘要、风险标签
成本失控 低价值任务持续运行 budget、quota、价值评分
风格漂移 代码越来越像临时拼接 simplification pass、架构边界检查

CAID 论文讨论异步软件工程 Agent 时也触及了类似问题：多 Agent 协作需要中心化任务委派、隔离 workspace、结构化集成和可执行验证。并发不是答案，受控并发才是答案。

质量控制：loop 会放大好习惯，也会放大坏习惯

迭代式 coding agent 的风险已有研究信号。

METR 在 2025 年的实验中，让 16 位有经验的开源开发者在熟悉项目上完成 246 个任务。开发者事前和事后都认为 AI 会节省时间，但实测在早期 2025 工具条件下反而增加了完成时间。这个结论不能推广成 “AI 编程无效”，但足以提醒：提示、等待、审查、修补 AI 输出本身会形成成本。

SlopCodeBench 更贴近 loop 问题。它关注 Agent 在多轮规格变化中持续扩展前序代码的能力。论文报告称，Agent 可以通过部分 checkpoint，但代码会逐步变得更冗长、更受结构侵蚀；质量指导能改善初始质量，却不能阻止后续退化率。

AI Workflow Store 论文从工作流硬化角度提出批评：即时生成的 on-the-fly agent loop 可能绕过传统软件工程里的设计、测试、对抗评估、阶段发布和监控，最终产出更像临时原型，而不是经过硬化的工作流。

这些研究共同指向一条规则：loop 不是质量保证。loop 只是放大器。工程纪律足够时，它放大产出；工程纪律不足时，它放大混乱。

Token 与成本管理

Loop 越长、并发越高，token 成本越敏感。把成本控制塞进 loop spec，比事后查账更有效。

工程上值得固定下来的原则有 5 条：

原则 落地方式 反例
选对模型和载体 判断类工作用强模型；分类、摘要、模板化工作用小模型；单 agent 能搞定的不要拆成多 agent 把 issue 分类交给 Opus，把夜间依赖扫描交给 Haiku
定义清晰的成功和停止条件 完成谓词 + 回合上限 + 预算上限三者绑定 只写“优化代码质量”作为目标
大规模运行前先 pilot dynamic workflows 先跑 5–10 个子任务看效果，再放大到数百 直接放出几百个 agent 通宵跑
用脚本替代推理 确定性步骤写成脚本，agent 只做需要判断的部分 让 agent 每次重新推导 PDF 表单填写代码
按事件触发而不是按时间 PR 变化、CI 失败、issue 到达比固定每 5 分钟轮询更省 每 30 秒 poll 一次看有没有新 review

预算和回合上限应该写进 loop spec。一个可运行的写法：

1
2
3
4
5
6
7
8
9
budget:
  max_runtime_minutes: 60
  max_turns: 20
  max_branches: 3
  max_tokens_per_turn: 50000
  pause_when:
    - single_turn_tokens > 200000
    - consecutive_failures >= 3
    - budget_remaining_percent < 15

Claude Code 提供的观测面在这里有用：/usage 按 skills、subagents、MCP 拆解近期用量；/goal 不带参数时显示当前回合数和 token 消耗；/workflows 显示每个 agent 的 token 用量，可以随时停掉某个 agent。把这三个命令写进夜间 loop 的 morning review，比单纯盯模型账单更能定位浪费来源。

成本管理和质量控制的边界要划清。质量控制关心“产出是否合格”，成本管理关心“产出是否值这个价”。一个通过所有验证的 loop 仍然可能在烧钱——比如每次都从头推理一个本可以脚化的步骤。把成本当成独立维度来管，loop 才可能稳定跑到生产。

Claude Code 本身也是一个 Loop 系统

2026 年的 “Dive into Claude Code” 论文基于公开 TypeScript 源码分析了 Claude Code 的设计空间。论文把 Claude Code 的核心描述为一个简单的 while-loop：调用模型、运行工具、重复——正是 ReAct 内环的工业化形态，thought 变成 interleaved thinking，observation 变成 tool result 回填。但更重要的部分在 loop 外围：权限系统、上下文压缩、MCP、插件、skills、hooks、subagent delegation、worktree isolation、append-oriented session storage。

这恰好说明 Loop Engineering 的重点不在 while，而在 while 周围的工程系统。

一个裸循环很便宜：

1
2
3
while not done:
  ask_model()
  run_tool()

一个能进入真实工程环境的循环很厚：

1
2
3
4
5
6
7
8
9
while not evidence_gate.passed:
  load_recoverable_state()
  prepare_context()
  check_authority()
  ask_model()
  execute_tool_with_trace()
  classify_result()
  update_evidence()
  route_failure_or_success()

Boris 的 /loops 和 Routines 把第二种循环的价值显性化了。

个人开发者的最小实践

个人不需要一开始就跑几千个 agent。更稳的做法是从少量低风险 loop 开始。

Loop 触发 写权限 产物 验收
Daily repo scout 每天早上 只写报告 风险、 TODO、过期依赖 人工挑选
Failing test repair CI 失败后 候选分支 最小修复 diff 测试通过后审阅
Writing polish 草稿更新后 草稿文件 引用核对、坏味道清单 构建和人工审稿
Issue triage 新 issue 到达 issue comment 草稿 复现路径、标签建议 人工发布

挑选第一个 loop 时，与其问“要做什么 loop”，不如问三个具体问题：

  • 验证能不能写成脚本？ 能写成“跑这个命令、看这个输出”的循环，适合升级成定时或主动循环。
  • 目标能不能量化？ 能用“测试通过数 / 阈值分数 / 构建退出码”表达的，适合用 /goal 锁定停止条件。
  • 工作是不是按时到达？ PR 评审、CI 失败、issue 入队这类外部驱动的，适合用事件或定时器触发。

三个问题都回答不上来的任务，先不要做 loop。先把它写成一次完整的回合循环，跑通后再升级。

最小原则：

  • 不让 loop 直接合并主干。
  • 不让 loop 直接部署生产。
  • 不让 loop 读取 secret。
  • 不让 loop 自己批准自己。
  • 不让 loop 在没有新观察的情况下无限重试。

这比追求 agent 数量更重要。

团队版本的 Loop Engineering

团队里，Loop Engineering 应该沉淀成平台能力，而不是每个工程师各写一堆 cron。

能力 个人版 团队版
调度 本地 cron、手动触发 统一 scheduler、队列、优先级
状态 文件、Git、thread durable store、evidence ledger
权限 shell 约定、目录限制 policy engine、approval workflow
验证 本地测试、构建 CI、E2E、preview、security checks
审阅 人工看 diff review queue、risk tags、owner routing
成本 自己控制 budget、quota、ROI dashboard
学习 个人笔记 workflow registry、postmortem、template

这也是为什么 /loops 和 Routines 的宣传值得关注。它暗示 coding agent 的竞争不只在模型能力，也在持久执行、调度、权限、协作和审阅系统。

反模式

Loop Engineering 不是把所有事情都自动化。这些做法会把 loop 变成风险源：

反模式 问题
无限 prompt 重放 没有新观察，重复只是在消耗预算
完成条件靠模型自述 模型说完成，不等于行为完成
夜间自动改主干 审阅和回滚压力被推迟到白天爆发
多 Agent 抢同一文件 并发提升被冲突抵消
没有权限分层 小任务获得了过大的破坏半径
没有摘要和优先级 人类审阅队列被产物淹没
没有熵减步骤 代码通过测试，但长期可维护性下降

一个实用判断是：如果第二天早上面对的是一堆无法排序、无法验证、无法解释来源的 diff，那么夜间 loop 不是生产力系统，而是延迟爆炸的任务生成器。

速查表：4 种循环怎么选

你交给 loop 的是 触发方式 适合的循环形态 主要载体
一次验证 自己手动 回合循环 Skills、自定义验证脚本
一个停止条件 实时 prompt 目标循环 /goal
一个时间点 时间间隔 定时循环 /loop（本地）、/schedule（云端）
一组定义良好的重复工作 事件或计划 主动循环 上述全部 + dynamic workflows

这张表的用法是从左到右：先看你手里是什么（验证 / 停止条件 / 时间点 / 重复工作），再看触发方式，最后选形态和载体。反过来从形态倒推任务，往往会把不适合自动化的工作强行 loop 化。

换个视角：这个概念为什么是现在

到这里，Loop Engineering 作为工程实践的样子已经清楚。但一个概念在 2026 年年中集中爆发、被几家厂商同步推动，值得追问一句：为什么偏偏是现在。

绕不开的背景是模型能力的边际收益在收窄。从 GPT-4 到 Claude 4 再到 Gemini 2，开发者端换模型带来的体感跃升在变小，基准分数还在涨，生产环境里的惊喜在变少。这个判断有旁证：Ilya Sutskever 在 NeurIPS 2024 上说预训练时代即将结束，多份研究也指出算力投入的边际提升在下降。与此同时，模型周围的工程设施在这段时间补齐了：工具调用标准化成 MCP、长上下文趋于稳定、自我验证从自说自话变成写查分离。于是出现一个微妙的位置，模型够用到能让循环不崩溃，又没好到让循环变得多余，循环这层工程正好卡在这个窗口里有市场。

顺着这条线看，厂商卖的东西也在变。2022 到 2024 年卖的是模型能力，谁更聪明谁赢；模型差距缩小之后，卖点转向「使用模型的方式」。Context Engineering、Harness Engineering、Loop Engineering 递进出现，大约每九个月一轮，每轮都有行业顶流背书、都宣称上一轮不够用，共同的潜台词是「模型已经够聪明，瓶颈在你的用法」。这句话未必是假的，如果瓶颈确实从模型转移到了用法，它就是事实。值得警惕的是它容易被反过来用：把模型增速放缓的压力，转译成用户能力不足的焦虑。

最尖锐的批评把这一步直接说成重新包装。Reddit 上有开发者指出，Loop Engineering 拆开无非是 ReAct 模式、agent 循环和任务调度的旧零件，“同一片灌木丛，换个名字再爬出来”；社区里流传的一张 Simpson 恶搞图，就在嘲讽从“提示词工程师”到“上下文工程师”再到“循环工程师”这条无休止的标签更迭。这个批评有一半是对的，本文自己也把内环追到了 2022 年的 ReAct。但“内核是旧的”不等于“整件事没有新东西”：新的是套在旧内核外面的那层工程——证据门、权限分层、持久状态、恢复阶梯，这些恰恰是 2023 年 AutoGPT 那批放开跑的循环没有、而今天能进生产的原因。值得认真对待的不是“循环”这个词，而是让循环可控、可审计、可停止的那套约束。

这里要把话说准。多家厂商同步、概念整齐递进，既能解释成有意编排，也能解释成几家实验室在同一套工具下撞到同一面工程墙、自然收敛到同一个答案，趋同不等于合谋。更稳妥的说法是：厂商未必编排了这个节奏，但一定在用力利用它。概念命名往往和产品发布咬合，Anthropic 的 dynamic workflows、Codex 的持续目标都是产品先就位，再等一个概念把注意力引爆。

成本这一头是实打实的。Loop Engineering 的本质是让用户从「按需调用模型」变成「持续运行模型」：loop 定时醒来，工作流在云端长跑，几千个 agent 夜间并行。Anthropic 自己在 dynamic workflows 的说明里就提醒，这个功能比普通会话消耗多得多的 token。这正是杰文斯悖论，效率提升反而抬高总消耗。已有公开报道给出量级：Uber 给约 5000 名工程师铺开 Claude Code 后，采用率从 32% 涨到 84%，四个月就烧穿了 2026 年的 AI 预算，重度用户人均月支出到 500 至 2000 美元；微软则在 2026 年中要求 Experiences + Devices 部门数千名工程师在 6 月底前从 Claude Code 迁回自家的 Copilot CLI，时点和口径都被普遍解读为成本动因。厂商的收入约等于停留时长乘调用频次乘单价，而 loop 同时抬高了前两项。

还有一层更隐蔽的成本是锁定。把 prompt 沉进 skill、把验收规则写进项目约定、把循环逻辑嵌进某一家的调度和工作流之后，用户建起来的是一套专有架构，循环越复杂、沉淀的规则越多，迁出的成本越高。Anthropic 和 OpenAI 的循环组件高度撞脸（automations、worktree、skill、connector、subagent、memory），本质是双向锁定：模型层拉不开差距，就在工程层制造迁移成本。

这些都不否定 Loop Engineering 的工程价值。它确实比 2023 年那批放开跑、没验证没边界的自动循环成熟得多——AutoGPT 是那批里标志性的失败，而它成熟的地方，正是本文反复强调的证据门、权限和恢复阶梯。工程真相和商业真相在这里同时成立：它既是真实的工程演化，也是一条要用户持续付费的新管道。对使用者来说，可用的立场很朴素：把循环用在自己真懂、能验收的活上，它是杠杆；用它替代理解、对返回结果照单全收，它就是在加速交出判断力。Steinberger 回应「20 美元套餐根本跑不起」时反问过一句「时间难道不值钱吗」，这话有道理，但要留意时间账是模糊的、无法审计的，token 账是每月刚性扣款的，用前者去合理化后者之前，先算清楚这笔电费交给了谁、值不值。

最终框架

可以把 Boris 这次宣传压缩成一句工程判断：

coding agent 的主战场正在从单次对话，转向持久循环。

这句话背后的工程框架如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
Loop = recurrent trigger
     + executable goal contract
     + constrained authority
     + recoverable state
     + observable feedback
     + evidence-based stop
     + recovery and escalation
     + human review

Goal contract = outcome hierarchy
              + machine-checkable acceptance
              + non-goals
              + operating boundaries and invariants
              + failure fallback
              + reviewable evidence

/loops 提供本地调度入口，Routines 提供服务器侧 recurring tasks。它们让 Claude Code 从 “一次会话里的 agent” 接近 “持续工作的 agent fleet”。这不是简单的功能升级，而是软件工程对象的变化：工程师需要设计的东西从 prompt 变成 loop，从单次产出变成持续产出系统，从手动监督变成证据驱动的审阅管线。

在这个语境里，Loop Engineering 不是口号。它是 Prompt Engineering 之后更接近软件工程本体的一层：先把目标写成机器可检查、边界明确、失败可降级、层级可追踪的契约，再为循环补上恢复和升级路径，把 Agent 的重复行动变成可控、可审计、可恢复、可停止的工程资产。

往回看，这一层的两块地基都已经有了名字：内环的循环范式 2022 年由 ReAct 定型，跨会话的存活能力由持久 Agent 的三根支柱托底。Loop Engineering 做的事，是把这两层缝进真实的工程流程，再补上触发、任务规格、证据门和升级路径这些只属于生产系统的部件。

参考资料