2026 年 AI 编程范式革新：Loop Engineering 登场，利弊几何？

【AI 编程范式更新背景】

2026 年 6 月，AI 编程圈在短短一周内经历了一次词汇的强制更新。

【关键人物观点与行动】

5 月 31 日，Claude Code 的创建者 Boris Cherny 在一次采访中提到，他从 2025 年 11 月起就卸载了自己的 IDE，那个月他提交了 259 个 PR，"没有一行代码是自己敲的，全是 Claude Code 写的"。他还指出自己已经不再给 Claude 写提示词，而是写循环，让循环去提示 Claude，然后循环会自己判断下一步做什么。

6 月 7 日，OpenClaw 作者、现任职于 OpenAI 的 Peter Steinberger 在 X 上发了一条后来获得约 800 万次浏览的推文："每月提醒你一次：你不应该再给编程 Agent 写提示词了。你应该设计循环来提示你的 Agent。"

【Loop Engineering 的命名与理论框架】

6 月 10 日前后，Google Cloud AI 总监、前 Chrome 开发者工具负责人 Addy Osmani 发表了一篇长文，将这个新范式正式命名为 Loop Engineering（循环工程），并给出了系统的理论框架。

Osmani 将 Loop Engineering 定位为过去三年 AI 开发范式演进序列的最新一级。2023 年是提示词工程（Prompt Engineering），人类逐字逐句地编写指令；2024 年是上下文工程（Context Engineering），通过精心组织的文件、规则和文档来让模型更好地理解项目；2025 年 Osmani 自己提出了 Harness Engineering（脚手架工程），用一个结构化框架管理单个 Agent 执行单个任务；而 2026 年的 Loop Engineering 站在所有这些之上：脚手架管理一个 Agent 跑一个任务，循环则决定跑哪些任务、何时开始、以及什么算完成。用 Osmani 的话说："你不再是那个提示 Agent 的人，你是设计那个提示 Agent 的系统的人。"

【Loop Engineering 的组件拆解】

Osmani 将一个完整的工程化循环拆解为六个组件：

第一个是 Automation（自动化触发器）。用定时或事件驱动的机制让循环自动发现需要处理的任务，比如从 GitHub Issues 中检出未分类的缺陷或从 CI 日志中发现构建失败。

第二个是 Worktree（工作树隔离）。为每个并发 Agent 分配独立的 git worktree 目录，防止多个 Agent 同时修改同一文件时发生冲突。Osmani 指出这个组件"最容易被忽视，但一旦多个 Agent 同时运行，没有它就会产生灾难性的合并冲突"。

第三个是 Skills（技能文件）。用 SKILL.md 文件将项目的构建步骤、代码规范和已知的"教训"编码下来，使得每个新启动的 Agent 循环不需要从零开始猜测。

第四个是 Connectors（连接器）。基于 MCP 协议将 Agent 连接到 Issue 跟踪器、数据库、Slack 等外部系统，填补"告诉我该修复什么"和"真正打开那个 PR"之间的鸿沟。

第五个是 Sub - agents（子 Agent 分离）。Osmani 和 Cherny 一致强调，写代码的 Agent 不能给自己的代码打分，"写代码的那个太容易对自己手软"。必须由独立的审查 Agent 来验证输出。

第六个是 State/Memory（状态与记忆）。用 Markdown 文件或 Linear Board 持续追踪已经做了什么、哪些通过了验证、哪些还未完成，使得下一次循环可以无缝接续。

【The Hive 架构展示】

这套框架的运转逻辑在 Cherny 的实际操作中得到了最具体的展示。一位开发者在 X 上根据 Cherny 的公开采访逆向还原了他称为 "The Hive"（蜂巢）的三层架构。第一层是本地循环，通过 Claude Code 的 `/loop` 命令在会话开启期间以最小一分钟的间隔重复运行；第二层是云端路由，利用 Anthropic 在 2026 年 4 月推出的云端克隆仓库功能，以最小一小时的间隔运行，机器关机后依然继续；第三层是集群，通过 `/batch` 命令动态创建数百甚至数千个 worktree 隔离的子 Agent 并行处理大规模任务。

The Hive 的飞轮效应很有启发性：第二层的云端路由将发现写入文件，第一层的本地循环读取这些文件后采取行动，大型工作被拆分给第三层集群并行处理，结果汇总后，一个每周运行一次的例行循环将所有经验提炼并写入 CLAUDE.md，这意味着 "你的 Agent 每周都比上周更聪明"。社区已从 The Hive 中反推出了七种可复用的循环模版，包括监控 PR、挖掘 Slack 反馈、清理僵尸 PR、自动分类 Issue、以及从失败的会话中提取模式写入项目规范。

【Loop Engineering 的潜在危险】

然而，Osmani 的文章中最令人印象深刻的部分并非框架本身，而是他对 Loop Engineering 潜在危险的三种警告。

第一个危险是成本爆炸。多个子 Agent 在前沿模型上并行运行，Token 消耗可能是预期的 5 到 10 倍。Steinberger 也坦诚自己 "无限 Token 玩得很开心" ---- 这是 OpenAI 员工的福利，普通用户没有这种奢侈。

第二个危险来自 Anthropic 自己对 Agent 循环的研究，揭示了三种失败模式：偷懒（50 个安全问题发现了 20 个却声称 "已全部修复"）、自我美化（给自己的输出打虚高的分数）、以及漂移（经过多轮迭代后，最初设定的 "不要做 X" 规则在第 47 轮中悄然消失）。这恰好解释了为什么 "制造 Agent" 和 "审查 Agent" 必须严格分离。

第三个也是最重要的危险，被 Osmani 称为 "理解债务"（Comprehension Debt）：每一个未经阅读就被合并的 PR，都在扩大循环产出的代码量和开发者真正理解的部分之间的鸿沟。他用一句可以刻在工作站旁的话做了总结："循环报告'完成'只是它的说法，不是真正的正确证明。用你能理解的工作上它是杠杆，用来逃避理解，就是在加速自己的衰落。"

【Loop Engineering 与过去范式的差异】

从日常开发者的视角来看，Loop Engineering 与过去范式最直观的差异在于交互频率的根本改变。在提示词工程时代，开发者与 AI 之间是一对一的对话回合 ---- 你发一条指令，它给一个结果，你评估，然后发下一条。循环工程则将这种交互压缩为配置阶段的一次性投入：定义目标、设置验证条件、指定停止标准，然后让系统在开发者离开键盘后自主运转。

Claude Code 和 Codex 在 2026 年中都已原生支持这一模式 ---- 前者提供 `/loop`（按设定间隔重复运行）和 `/goal`（运行直到某个条件被满足），后者提供了等效的 `/goal` 加定时自动化。两家竞品几乎不约而同地实现了同一套组件，竞争的焦点已经从 "谁的模型更强" 微妙地转向了 "谁能让循环的设计门槛更低"。这种趋同本身就是一个强烈的信号：当基础设施层的共识已经形成，范式就不再是一种观点，而是一种正在被协议化的标准。

【对 Loop Engineering 的质疑声】

这场讨论也引发了值得注意的质疑声。Reddit 上有批评者指出，Loop Engineering 本质上是 ReAct 模式、Agent 循环和任务调度的重新包装 ---- "同一片灌木丛，换了个名字再爬出来"。一张 Simpson 恶搞图在开发者社区流传，嘲讽从 "提示词工程师" 到 "上下文工程师" 再到 "循环工程师" 的无休止标签更迭。

Anthropic 自己的团队也坦承，Cherny 的人均合并量提升 8 倍的指标 "几乎肯定高估了真实生产力"。但即便承认这些批评有一定道理，Loop Engineering 的六个组件精确定义了一个此前模糊地存在于高级开发者直觉中的工程实践集合，在 Osmani 的文章之前，这些实践以 "个人工作流" 的形式散落在 Cherny 的终端里、Steinberger 的推特长文中、以及无数不语者的私下配置里。它最大的价值或许不在于发明了新东西，而在于把分散在各处的实践收束为一套可传授、可复制、可工具化的体系 ---- 这正是 "工程" 二字区别于 "技巧" 的本质：前者可以被讨论、被改进、被教给下一个新加入团队的开发者。