一场正在发生的范式转变：Loop Engineering（循环工程）

声明：本文是对 Addy Osmani 文章 Loop Engineering（2026 年 6 月
7 日发布）的独立解读与延展分析。文中核心概念（如"循环工程"六大组件框架、“理解债务”、"认知投降"等）属于原作者 Addy Osmani
的原创思想，本文通过重新组织结构、补充原创图解、加入个人分析视角进行二次创作。所有图解均为作者独立绘制。

Anthropic Claude Code 负责人 Boris Cherny 最近说了这样一句话：

“我不再直接提示 Claude 了。我有正在运行的循环来提示 Claude 并弄清楚该做什么。我的工作是编写循环。”

开发者工具先驱 Peter Steinberger 也表达过类似观点：

“你不应该再亲自提示编程代理了。你应该设计循环来提示你的代理。”

这不仅仅是一句口号。过去两年里，我们与 AI 编程代理的交互模式是这样的：你写提示 → AI 执行 → 你读结果 → 你再写提示。代理是工具，你全程掌控它，一轮接一轮。

但现在，一个新的范式正在浮现——循环工程（Loop Engineering）。你不再亲手驱动每一轮，而是构建一个小型系统，让它自己发现工作、分配任务、检查结果、记录进度、决定下一步。你不是在提示代理，你是在设计提示代理的系统。

上图清晰地展示了两种范式的区别——

• 左侧旧范式：你作为中央枢纽，手动驱动每一轮交互，带宽消耗大
• 右侧新范式：系统自主循环运行，你的角色转变为"设计循环 + 审查结果"

循环需要什么？六大核心组件

Addy Osmani 提出了一个极简框架：“一个循环需要五个东西，再加一个地方记住东西”。这六个组件构成了循环工程的完整基础设施：

下面这张架构图展示了组件之间的协作关系：

左侧三个「基础设施组件」为中央子代理提供支撑，右侧状态存储实现跨会话记忆。虚线箭头代表反馈闭环——状态文件中的信息会反哺给下一轮自动化触发，形成持续改进的飞轮。

两种关键的循环原语

自动化模块提供了两种核心运行模式：

• /loop：按固定频率重新运行（如每天早上 6 点）
• /goal：持续运行直到你设定的条件为真，每轮运行后由独立的第三方小模型检查是否完成

/goal的设计哲学很值得玩味——写代码的代理不负责给自己评分。这种"制衡机制"正是循环能在你不在场时仍然可信的关键。

“代理会遗忘，仓库不会”

关于状态存储，原文中有一句话让我印象深刻：

“The model forgets everything between runs so the memory has to be on disk and not in the context. The agent forgets, the repo doesn’t.”

代理每次会话都是"冷启动"的，会遗忘之前的一切。所以循环的进度、尝试记录、审查结果必须持久化到磁盘（Markdown 文件或 Linear 面板）。没有状态存储，循环就像一个每天醒来都失忆的人。

关于技能（Skills）：消除"意图债务"

代理每次会话开始时会填补你意图中的空白，并做出自信的猜测——这被称为"意图债务"（Intent Debt）。技能的作用就是将意图显式编码：项目约定、构建步骤、“因为我们出过事故所以不这样做”——写一次，代理每次运行时读取。没有技能，循环每次从零推导项目；有了技能，它会不断累积经验。

一个完整循环的一天

让我们用一个真实场景来串联所有组件。以下是一个生产环境中循环的典型运行流程：

注意中间的并行阶段（06:10）——工作树 A 和工作树 B同时运行：

• 工作树 A：子代理负责起草修复代码，读取技能文件遵循项目约定
• 工作树 B：子代理 B 独立审查代码，不信任子代理 A 的产出

这就是"实现与验证分离"的核心价值。两个代理在独立分支上工作，互不干扰。

到了早上 9 点，当你打开电脑时，循环已经完成了大部分工作。你的任务是：

1. 审查已经开好的 PR
2. 处理分类收件箱中循环无法自动完成的复杂事项
3. 更新技能文件，让明天的循环更聪明

工具无关的抽象层

一个关键的洞察：循环的底层结构已经超越了单一工具的边界。无论是 OpenAI 的 Codex 还是 Anthropic 的 Claude Code，六大组件的映射几乎一致：

两者都使用SKILL.md和MCP——为其中一个编写的技能和连接器，通常可以直接在另一个中使用。

循环解决不了的三个问题

循环改变了工作方式，但它不会删除你。Addy Osmani 在文中用了大量的篇幅提醒读者：随着循环变得更强，三个问题反而变得更加尖锐。

1. 验证仍然是你（人类）的责任

无人值守运行的循环也在无人值守地犯错。将验证子代理与制造子代理分离，正是为了让循环的"完成了"这句话更有意义——但即便如此，"完成"只是一个声明，不是证明。

“Your job is to ship code you confirmed works.”

2. 理解债务（Comprehension Debt）

循环越快地发布你没有亲手写的代码，"代码库里存在的东西"和"你实际理解的东西"之间的差距就越大。一个顺畅的循环只会让理解债务增长得更快——除非你主动阅读循环产出的每一行代码。

3. 认知投降（Cognitive Surrender）——最危险的陷阱

当循环自动运行，很容易就不再有自己的判断，只是接受它给出的一切。Addy 将这称为认知投降。

设计循环，当你带着判断去做时是解药；当你用它来避免思考时是催化剂——同样的行动，相反的结果。

这一点尤其值得警惕。两个人可以构建完全相同的循环，但得到完全相反的结果：A 用它在深刻理解的工作上加速，B 用它来完全避免理解工作。循环不知道区别——你知道。

我的思考

在我看来，"循环工程"这篇文章之所以重要，不在于它提出了什么全新的技术——六大组件大多已经在现有产品中存在。它的价值在于提供了一个认知框架，让你从"提示技巧"的思维层面，升级到"系统设计"的思维层面。

几个值得深思的点：

第一，杠杆点在转移。一年前要构建类似的循环，你需要写一堆 bash 脚本并持续维护。现在这些组件直接内置于产品中。门槛降低意味着更多人会开始尝试，但也会更多人陷入"认知投降"。

第二，工程师的角色不会消失，但会升级。循环设计比提示工程更难，而不是更容易。你需要同时具备系统思维（设计循环）、领域知识（编写技能）和工程判断力（审查结果）。这不是"按下开始按钮等结果"的工作。

第三，Token 成本是隐形门槛。文中提到的子代理模式——每轮都有独立的探索、实现、验证代理——意味着 Token 消耗可能是传统模式的数倍。这对个人开发者和小团队来说是一个现实约束。

第四，直接提示仍然有效。不要把循环工程教条化。有些场景下，直接提示代理反而是最高效的方式。循环工程是工具箱中的一件新工具，不是要替换所有旧工具。

总结

最后，用 Addy Osmani 的那句话作为收尾：

Build the loop. Stay the engineer.

构建循环，但仍然做个工程师。不是像只负责按下"开始"按钮的人，而是像一个打算继续深刻理解代码的人。代理会遗忘，仓库不会——你设计的循环、编码的技能、写入的状态文件，这些才是跨越时间和会话持久存在的东西。

循环工程不是终点，它是一个工程师在 AI 时代的新起点。