Loop Engineering

What it is

Loop Engineering（循环工程）是软件开发中一个新兴的范式转变：开发者不再直接向编码智能体（Coding Agents）发送提示（Prompt），而是设计一套自动化系统（即"循环"），由系统根据预定义的任务和目标自主驱动智能体。

原文作者：Addy Osmani，Google Chrome 团队工程主管，前端性能专家和开源贡献者。

Why it matters

Loop Engineering 标志着与编码智能体协作方式的根本性变革：

• 从"手持工具"到"设计工厂"：过去是手动编写提示、提供上下文、阅读回复；现在是构建系统，负责寻找工作、分配任务、检查结果、决定下一步
• 递归目标：开发者定义目的，AI 不断迭代直至完成
• 工具一致性：Claude Code 和 Codex 已内置实现循环工程所需的全部组件

Loop Lineage

Loop 概念有真实的演进谱系，不是新造词。

关键区分：单 agent 的 ralph 循环已是旧范式；多 agent 的编排循环才是新层。正如 Trash Panda 所说："It's not ralph/goal loops, that's old hat by now. It's probably some kind of continuous orchestration loop that oversees other threads/agents."

Six Building Blocks

1. 自动化（Automations）— 循环的心跳

功能：使循环能够按计划持续运行，而非一次性执行。

实例：

• 每日扫描 CI 失败记录
• 总结提交简报
• 追踪上周引入的 Bug

实现：

• Claude Code：/loop（按频率运行）或 /goal（持续运行直至条件达成）
• Codex："自动化选项卡"设置

2. 工作树（Worktrees）— 解决并行冲突

问题：多个智能体同时工作时，文件冲突是主要障碍。

解决方案：

• 利用 Git Worktree 为每个智能体创建独立的运行目录和分支
• 确保不同智能体的编辑不会相互干扰
• 实现物理上的隔离

3. 技能（Skills）— 项目上下文的持久化

问题：智能体在每个会话中反复"重学"项目背景。

解决方案：

• 包含 SKILL.md 的文件夹
• 记录特定的指令、构建步骤和约定
• 将"意图"固化

关键概念：意图债务（Intent Debt）

• 如果没有技能，智能体会根据猜测填补意图空白
• 有了技能，项目知识可以随时间累积

4. 插件与连接器（Plugins and Connectors）— 扩展操作边界

问题：循环如果只能访问文件系统，能力是有限的。

解决方案：

• 通过 MCP（模型上下文协议）连接外部工具
• 问题追踪器（Linear）、数据库、API、Slack

结果：智能体能够自主打开 PR、链接工单、CI 通过后发送通知。

5. 子智能体（Sub-agents）— 制衡机制

关键设计：将"执行者"与"检查者"分离。

原因：编写代码的模型通常对其自身的错误过于宽容。

配置方式：

• 不同的 TOML 或配置文件
• 定义具有不同职责的智能体：
  • 一个负责实现
  • 一个负责安全性审查
  • 一个负责验证规范

6. 外部记忆（Memory）— 核心补充

问题：模型在不同运行之间会遗忘。

解决方案：

• Markdown 文件或项目看板（如 Linear）
• 在磁盘而非上下文窗口中记录已完成的工作和待办事项
• 确保长效运行的智能体不会丢失进度

Tool Comparison

Risks and Responsibilities

1. 验证责任

• 循环生成的代码 ≠ 经过验证的代码
• 子智能体可以协助审查
• 最终确保代码运行正常的责任仍在人类工程师手中

2. 认知与理解债务

理解腐蚀（Understanding Erosion）：

• 循环交付代码的速度越快
• 开发者对代码库的实际了解就越少

认知投降（Cognitive Surrender）：

• 开发者可能会为了规避思考而完全接受循环产生的任何结果
• 与 Tony Fadell 警告的"认知投降"和 Addy Osmani 自己提到的"73% 参与者接受 AI 错误答案"的研究一致

3. 成本与质量平衡

代币成本（Token Cost）：

• 子智能体的并行运作会消耗大量代币
• 需要根据预算调整使用模式

质量下滑（Slop）：

• 必须警惕自动化导致的低质量代码堆积
• Peter Yang 观察到 agent 生成内容约 10% 是 slop

4. 杠杆的双向性

循环本身是中性的：

• 深度理解工作的开发者 → 利用它加速
• 试图逃避思考的人 → 利用它快速陷入更深的困境

5. 生产级 Hard Stops

2026 年的共识：没有 guardrails 的循环会无限运行并带来账单惊喜。

三个必须：

• 最大迭代次数：设定硬上限，防止空转
• 无进展检测：如果连续 N 轮没有实质性变化，自动暂停
• 预算天花板：Token 或美元预算上限，到达即停止

现实案例：Uber 为每位工程师的 Claude Code 和 Cursor 设置每月 $1,500 工具上限，因为四个月内烧完了全年 AI 预算。模型生成代码本身几乎免费，循环运行成本才是主要开销。

6. 成本结构转变

"The costliest thing in AI coding is no longer writing code, it's managing the agent loop."

成本从 token 生成转向了 loop 管理。Gartner 将 agentic AI 置于膨胀期望的峰值，实际部署率仅约 17%。时间线与收据之间的差距是真实状态。

Token 现实：Feisky 指出，自修正、验证子 agent、重试，每一步都在消耗 token。"你是 token 富人还是 token 穷人，直接决定了你对 loop 的态度。"

The New Role of Engineers

从"写提示词"到"设计控制系统"

正如 Anthropic 的 Claude Code 负责人 Boris Cherny 所言：

"我的工作是编写循环。"

正确的心态

• 像"设计工厂的人"一样去构建循环
• 不要做一个只会点击"开始"按钮的旁观者
• 只有在理解的基础上使用循环，才能在保持质量的同时实现效率的指数级增长

使用循环的前提

Feisky 提出一个朴素的判断标准：能不能把"做完了"写清楚。

• 能写清楚完成标准 → loop 能省掉大量重复劳动
• 连完成标准都说不清 → 还是老老实实一步步来

这与 Codex /goal 的设计一致：模型能宣布做完，但不能说预算快没了先撤。配上每轮注入的自审，强制逐项对照真实文件和测试结果。能戳穿它的只有独立的验证子 agent。Lance Martin 的测试里，Fable 5 最好的运行有 73% 的结论经过了独立验证，Opus 4.7 中位数只有 17%。

Related Concepts

TMA1 v2: Observability as Loop Feedback (2026-05-25)

来源：TMA1 v2 — 让 Coding Agent Loop 真的转起来

TMA1 是一个完全本地的 coding agent 可观测性工具，v2 版本将观测从"事后查看"推进到"实时注入"——把观测结果闭环回 agent 的下一轮 prompt。

Cross-Agent Context Sharing via /tma1-peer

TMA1 v2 在 Claude Code 和 Codex 之间实现了直接的上下文互通：

• 在 Codex 中运行 /tma1-peer cc 1 即可读取 Claude Code 最近的 session 上下文
• 包含 tool call 历史、修改文件、build 结果、异常报告等
• 使 review → code 的循环无需人工复制粘贴评审意见

这验证了多 agent 协作中，跨 agent 的上下文共享不应依赖人类中转，而应通过结构化接口直接读取对方的会话状态。

<tma1-context> Automatic Injection

TMA1 在多个 hook 点（UserPromptSubmit、PostToolUse、SessionStart、Stop、PreCompact）自动注入 <tma1-context> 信息：

• 当前 session 信息（duration、tool calls、tokens）
• 最近修改文件和工具使用分布
• build 命令状态和最后一次错误
• 外部文件变化（被 human 或其他 agent 修改）
• 基于规则的异常信息

关键设计：这些信息不是让 agent "看着玩"，而是直接提醒 agent 注意上下文变化并给出行动建议。例如：

• human_modified_during_session → 重新读取文件，不要假设内存中的副本仍然有效
• build 失败 → 修复错误再继续
• context 超过 100k → 考虑 compaction 或开新 session

Build State Attribution: Human vs Agent

一个不算大但关键的细节：当 fsnotify 看到文件变化时，如何判断是"人改的"还是"agent 改的"？

TMA1 的归因策略：

1. ±5 秒窗口内查 hook 事件：匹配 file_path 的 Edit/Write/MultiEdit
2. 查 Bash 命令的 input：是否包含该文件的 basename（能抓到 mkdir、rm、git checkout 等没有 file_path 字段的操作）
3. 两轮都没命中 → 归 human

原则："宁可冤枉自己，也别替 agent 背锅。"

这代表了** agent 环境感知中的归因问题**——当多个 agent 和人类在同一个代码库上工作时，准确的变更归因是避免冲突和重复劳动的前提。

Anomaly Detection as Loop Guardrails

TMA1 内置的异常检测规则示例：

• 反复修改同一个文件，但报错信息一直没变 → 尝试其他策略
• Context 过长超过 100k → 触发 compaction 或新 session
• 这些规则在检测到 pattern 时，通过 <tma1-context> 注入建议，使 agent 自动调整策略

Insight：Loop Engineering 中，guardrails 不应只是外部限制（如 max iterations），还应包括运行时 context 注入——让 agent 在循环中感知自己的状态并自主调整。

Fable 5 Self-Correction Loops（2026-06-11）

来源：RLanceMartin — Designing loops with Fable 5

Anthropic 工程师 RLanceMartin 通过 Parameter Golf 和 Continual Learning Bench 两项实验，验证了 Fable 5 在循环任务中的行为特征：

目标-评分循环（Goal/Rubric Loop）

• Fable 5 在 self-correcting loop 中表现显著优于 Opus 4.7：在 Parameter Golf 任务中，Fable 5 对训练管道的改进幅度约为 Opus 4.7 的 6 倍
• Fable 5 倾向于选择更大规模的结构性变更（structural changes），并在遇到量化回退（quantization regression）时展现出更强的恢复韧性
• Opus 4.7 的首个实验产生微小改进后，后续几乎复制同一模板：调整标量 → 测量 → 保留正值结果
• 关键设计：使用 verifier sub-agent（独立上下文窗口）进行评分，优于模型 self-critique

Outcomes in Claude Managed Agents

• CMA 的 Outcomes 功能自动 spawn grader sub-agent，在允许 agent 停止工作前确认所有实验标准已满足
• 为 Parameter Golf 提供九项可检查标准（运行基线、执行 20 次实验等）的 rubric 文件，由 Outcomes grader 逐项验证

提示设计原则

• 与其直接提示和引导 Fable 5，不如设计让模型响应环境反馈（goal/rubric）并自主管理上下文（memory）的循环
• 精心设计的 goal 或 rubric 为 Claude 运行的环境增加反馈，使其能够运行、收集反馈、self-correct、并在条件满足前持续迭代

Avi Chawla: Loop Engineering 实操指南（2026-06-14）

来源：AI Briefing 2026-06-14 (morning) — Avi Chawla (@_avichawla)

Avi Chawla 的指南将 Loop Engineering 从理论框架推进到可复制的六步实现：

1. Schedule decides what to run next — 调度器决定下一步运行什么
2. The loop (maker agent) produces the work — 循环（maker agent）产出工作
3. A separate checker agent grades the output — 独立的检查器 agent 对输出评分
4. Checker returns findings to the maker as the next instruction — 检查器将发现返回给 maker 作为下一步指令
5. A file on disk holds state that both read and write — 磁盘上的文件保存状态，供双方读写
6. Set exit conditions before the loop runs — 在循环运行前设置退出条件（最大迭代次数、预算或"所有测试通过"）

关键实践：

• 为任何自动化循环实现独立的检查器 agent，以避免自我验证偏差
• 将所有循环状态移到磁盘（Markdown 文件或知识图谱），而非保留在上下文中
• 这使循环能在数天后恢复，不受模型上下文窗口限制

与 Addy Osmani 六组件的对应关系：

这验证了 Loop Engineering 的核心组件在不同实践者之间存在共识，同时展示了从"框架描述"到"操作手册"的细化路径。

Loopcraft: The Art of Stacking Loops（2026-06-12）

来源：AINews 2026-06-12 — Loopcraft

本期 AINews 将 loop discourse 推向行业共识层面，多位领袖发出同一信号：不要再手动提示模型，而是设计能够自主提示模型的循环系统。

关键引述

• Steipete：「这是你每月一次的提醒：你不应该再提示编码 agent，而应该设计循环来提示你的 agent。」
• Boris：「我不再提示 Claude。我写循环，循环来做工作。」
• Andrej Karpathy：「要充分利用现在可用的工具，你必须把自己从瓶颈中移除。你不能在那里提示下一个东西。你需要把自己抽离出来。你必须安排事情使其完全自主，问题是你如何最大化 token 吞吐量而不在循环中。这就是现在的目标，游戏的名称是增加杠杆……我不想成为循环中的研究者查看结果等，我在拖慢系统。所以问题是我如何重构所有抽象，使我不必——我安排一次，然后按开始。」

Salty Lesson

• Rich Sutton 有模型层面的「苦涩教训」（Bitter Lesson）。AINews 提出 agent 层面的「咸味教训」：不要像历史上那样自己修复问题，而是专注于随更多 agent 扩展的系统，如目标和编排。
• 核心洞察：「如果你不知道怎么做，不要对那些知道的人 salty。」

递归 SI — 自动化开放式发现系统

• Richard Socher 和 Recursive SI 发布了一个早期「自动化开放式发现系统」，声称在三个公开任务上达到 SOTA：NVIDIA SOL-ExecBench、NanoGPT Speedrun 和 NanoChat autoresearch。
• 具体指标：NanoChat 上达到相同损失速度快 1.3 倍；NanoGPT Speedrun 上将运行时间从 79.7s 减少到 77.5s；SOL-ExecBench 上在 235 个内核上将平均分数从 0.699 提高到 0.754。
• 这与其说是「AGI 研究自动化」的证据，不如说是当前系统已经在狭窄、高反馈的系统优化任务上做出贡献的证据。

Microsoft Arbor — 长程自主研究 Agent

• Arbor 是一个微软研究院的自主研究 agent，使用持久的假设树细化。
• 声称在六个研究任务上击败 Codex 和 Claude Code，在 MLE-Bench Lite 上达到 86% Any-Medal。
• 与 Recursive 的结果一起，Arbor 暗示「研究用 agent」正在分化为：(1) 针对快速迭代系统调优优化的系统，和 (2) 针对长程假设管理优化的系统。

Benchmark 适应 AI-on-AI 改进

• PostTrainBench 定位为递归自我改进评估——AI 训练更弱的模型并直接测量循环进展。
• Agents' Last Exam (ALE) 是一个包含 55 个职业的 1,500 个专家来源任务的滚动基准；前沿 agent 解决了有意义的工作比例，但在最难级别所有测试系统得分 0%。
• SciConBench 包含来自 Cochrane 综述的 9.11k 个问题，发现前沿 agent 仍然无法可靠地综合科学结论。
• 模式：agent 在有界循环中越来越有用，但在专家综合和经济上有价值的长程任务上仍然脆弱。

Additional Loop Patterns（2026-06-12 Evening Briefing）

来源：AI Briefing 2026-06-12 (evening)

Fable 5 + real data + verification loop: 3D San Francisco map

• @nicbstme had Fable 5 build a fully detailed, self-contained 3D HTML map of San Francisco from real municipal data: 15,905 street segments, 9,672 buildings with lidar heights, 14,151 elevation contours, and real Muni/BART routes with animated trams.
• The output was a single 1.2 MB self-contained HTML file with a WebGL engine, running offline with no libraries or API calls.
• This demonstrates a loop pattern where the agent is given raw data, a verification constraint (offline, self-contained), and a long-running generation task.

Sid Bidasaria: unsupervised agent configuration

• Anthropic Claude Code engineer Sid Bidasaria demonstrated how to configure agents that run without supervision, with a setup that can be extended to mobile.
• The pattern: a 37-minute config demo for autonomous agent execution, then extend the same config to a phone for mobile monitoring.
• This signals that loop configuration is becoming portable across devices, not just desktop runtimes.

dax: "done" as loop completion criteria

• dax defined product completion as: implemented, not ugly, documented, discoverable, and marketable.
• For agent loops, this translates to exit conditions that include not just functional correctness but also reviewability, discoverability, and deliverability.

Key Quotes

1. "从'手持工具'到'设计工厂'"
2. "循环被视为一种递归目标"
3. "意图债务：如果没有技能，智能体会根据猜测填补意图空白"
4. "循环生成的代码并不等同于经过验证的代码"
5. "理解腐蚀：循环交付代码的速度越快，开发者对代码库的实际了解就越少"
6. "循环本身是中性的。深度理解工作的开发者利用它加速；试图逃避思考的人则利用它快速陷入更深的困境。"
7. "我的工作是编写循环。" — Boris Cherny
8. "像'设计工厂的人'一样去构建循环，而不是做一个只会点击'开始'按钮的旁观者。"
9. "The loop is plumbing. The asset is the skill it calls."
10. "The costliest thing in AI coding is no longer writing code, it's managing the agent loop."
11. "能不能把'做完了'写清楚，是判断是否该上 loop 的朴素标准。" — Feisky

Evidence across sources

Related

• Auto-Prompt Generation — 自动生成 Prompt 的三种机制与实战
• Ralph Harness Framework
• Long-Running Agent Harness
• Dynamic Workflows
• Wiring Skills Into Loops
• Cognitive Surrender
• Product Taste and System Thinking

Open Questions

• Loop Engineering 的"意图债务"如何量化？是否有自动化检测方法？
• Sub-agent 的"执行者-检查者"分离在不同项目类型中的最佳配置是什么？
• 如何设计 Loop 的"刹车机制"——当理解腐蚀达到临界点时自动暂停？
• Loop Engineering 与 Dynamic Workflows 的边界在哪里？何时用 Loop，何时用 Workflow？
• 循环的成本结构转变如何影响个人开发者 vs 企业的 agent 采用策略？
• 生产级 hard stops（最大迭代、无进展检测、预算天花板）的最佳配置是否有通用公式？
• "Skill 是资产，Loop 是管道"的框架下，Skill 的维护和版本化应该由谁负责？
• Fable 5 的「多代理竞争」模式是否适用于所有复杂任务，还是仅在优化/分析类问题中有效？
• Loop 的成本结构（Fable $9/40min vs GLM <$1/几分钟）如何影响个人开发者 vs 企业的工具选择？