调研截至：2026-06-14。公开检索没有找到 Boris Cherny 对 “Loop Engineering” 的完整定义文本；可核实材料集中在他对 Claude Code /loops 和 Routines 的展示与推荐。这里把 “Loop Engineering” 限定为这类持久 Agent 自动化的工程抽象：定时触发、长期运行、多会话并发、可恢复状态、权限边界、验证证据和人工升级路径。

Loop Engineering cover

查重结果

本博客已有 Agent Loop、Ralph Loop、Goal、Harness Engineering、Hook 体系等相邻文章，但还没有专门讨论 Loop Engineering 的博文。关键词检索覆盖了：

  • Loop Engineering
  • loop engeering
  • loop engineering
  • 循环工程
  • 反馈回路
  • Agent Loop
  • Ralph Loop

相邻文章有这些：

已有文章 主要讨论 补位关系
AI Coding Agent 的 Hook、Loop 与插件体系 Codex、Claude Code、OpenCode、OMC 的运行时结构 已经写到 loop 与 hook，但没有以 Boris 的 /loops 宣传为主线
Goal 模式深度研究 Goal、Ralph Loop、completion predicate 提供完成谓词和循环停止条件的基础
Harness Engineering：长程 Agent 的工程化底座 长程 Agent 的工具、状态、验证环境 为 loop 工程化讨论提供背景
Agentic Coding 深度解析 从代码补全到 Agentic Coding 提供开发范式迁移背景

空位很明确：关键不是再泛泛讲 “Agent 会循环”，而是把 Boris 这次宣传里的 /loops、Routines、夜间多 Agent 深度工作，放进一个更硬的工程框架里。

Boris 这次宣传到底新在哪里

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 推广的重点不是 “怎样把 prompt 写得更好”，也不是 “怎样让单个 coding agent 多试几次”。重点是把 coding agent 从一个交互式终端工具，推进到一种持久自动化系统。

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

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

Boris 展示的主界面更像：

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

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

这就是这里采用的 Loop Engineering 语境。

一个严格定义

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

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

更压缩的定义是：

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

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

从 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。

/loops 和 Routines 为什么是分水岭

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

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

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

flowchart TD
  A["Human intent"] --> B["Loop spec"]
  B --> C{"Trigger"}
  C -->|cron| D["Local /loops"]
  C -->|server schedule| E["Routines"]
  D --> F["Claude Code sessions"]
  E --> F
  F --> G["Agent workers"]
  G --> H["Repo / files / tools"]
  H --> I["Evidence"]
  I --> J{"Gate"}
  J -->|pass| K["Review queue"]
  J -->|fail| L["Recovery ladder"]
  L --> F
  J -->|needs judgment| M["Human escalation"]

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

四层循环

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

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

多数讨论只盯着第一层，也就是 “agent 内部怎样 while-loop”。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
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:
  description: "发现高价值依赖升级机会，生成候选修复和风险说明"
done_evidence:
  - "生成升级清单"
  - "每个候选项包含风险、测试建议、回滚路径"
  - "只为低风险项创建候选分支"
observation:
  commands:
    - "npm test"
    - "npm run build"
    - "npm audit --json"
budget:
  max_runtime_minutes: 90
  max_branches: 5
recovery:
  retry:
    max_attempts: 2
  pause_when:
    - "需要生产凭证"
    - "依赖许可证不明确"
    - "测试环境不可用"
review:
  output: "dependency review queue"

这个 spec 的价值不在格式，而在边界。它把 Agent 的夜间活动限制在可审计范围内。

完成谓词比目标描述更重要

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

1
帮忙优化代码质量。

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

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

完成谓词至少包含：

维度 问题 示例
行为证据 什么现象算完成 失败测试变绿，目标页面可点击，构建通过
变更边界 哪些文件、接口、环境不能动 不改公开 API，不碰生产配置
验证入口 用什么命令或观察面判定 npm run build、E2E 截图、性能阈值
审阅产物 人类看到什么 diff、报告、候选分支、风险列表
停止条件 什么时候不再继续 三次同类失败、权限不足、证据冲突

没有完成谓词的 loop，会把 “完成” 交给模型自述。长程 Agent 最不该依赖的就是自述。

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

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

坏观察面会把 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 恢复。具体框架不同，原则一致：长期循环需要可恢复状态，不能只依赖模型记忆。

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

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

持久 loop 应该内置恢复阶梯：

分类 条件 动作
Retry 临时失败，重试可能恢复 限次重跑，记录原因
Repair 失败原因明确，权限足够 修改实现、测试夹具或配置
Replan 同一路径多次失败 缩小目标，换方案
Pause 缺少权限、凭证、业务判断 保存状态，等待人类输入
Abort 目标冲突、风险超限、证据不足 停止并报告已知事实

这个阶梯看似普通，却是 /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 只是放大器。工程纪律足够时，它放大产出；工程纪律不足时，它放大混乱。

Claude Code 本身也是一个 Loop 系统

2026 年的 “Dive into Claude Code” 论文基于公开 TypeScript 源码分析了 Claude Code 的设计空间。论文把 Claude Code 的核心描述为一个简单的 while-loop：调用模型、运行工具、重复。但更重要的部分在 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 直接部署生产。
  • 不让 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 不是生产力系统，而是延迟爆炸的任务生成器。

最终框架

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

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

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

1
2
3
4
5
6
Loop = recurrent trigger
     + constrained authority
     + recoverable state
     + observable feedback
     + evidence-based stop
     + human review

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

在这个语境里，Loop Engineering 不是口号。它是 Prompt Engineering 之后更接近软件工程本体的一层：把 Agent 的重复行动变成可控、可审计、可恢复、可停止的工程资产。

参考资料