Loop Engineering：从单次对话到自动化循环

摘要：本文深度剖析谷歌 Chrome 团队主管 Addy Osmani 提出的“循环工程”概念，观察研发范式从人驱动提示词向系统设计循环转移，拆解其核心组件架构与局限。

在过去的两年里，大模型席卷了软件开发流程。然而，随着开发者频繁在对话框中编写、修改并复制提示词，这种将“人类作为提示词工程师”的交互模式已触及瓶颈，繁琐的手工干预使得研发效率的提升曲线开始放缓。

针对这一瓶颈，谷歌 Chrome 团队主管、知名技术作家 Addy Osmani 近日发表博客文章，指出我们可能正处于“循环工程”（Loop Engineering）的新范式转移中。他援引了 OpenClaw 作者 Peter Steinberger 的研判“应该设计能够提示 Agent 的循环系统”，以及 Claude Code 创建者 Boris Cherny 编写自动化循环的经验，主张把提示词本身进行工程化设计。

什么是循环工程？

在 Addy Osmani 的论述中，所谓“循环工程”的本质是将提示词的调度与处理逻辑工程化，用一套具备自治能力的自动化系统来封装大模型的调用。

在这种范式下，“循环”被定义为一个拥有“递归目标”的闭环任务。开发者不再针对某行代码做单次提问，而是为系统定义一个终极目标，智能体便会进入迭代状态，自主运行多轮请求，直到该目标被达成。

这种转变的关键在于研发驱动力的移交。传统的 AI 辅助开发中，人类负责发现问题、分配任务、检查代码、记录状态并做出决策。

而在循环工程中，这 5 项职责全面收纳进系统流程中，研发驱动力从“人类驱动”转向“系统驱动”，工程师则退回到了系统架构师的位置。

循环的五个组件与一个记忆机制

根据 Addy Osmani 的梳理，构建一个能够长期运行的循环系统，需要鲁棒的架构支持。具体而言，一个合格的“循环”必须包含以下 5 个核心功能组件，以及 1 个独立的外部记忆机制。

1. Automations（自动化组件）

循环的“心跳”，主要执行定时发现与任务分流。在 Codex App 中表现为专用的 Automations 标签页，在 Claude Code 中则表现为预设时间表、/loop 指令或 hooks 关联。其核心作用是在后台不断轮询监控报警与未处理的任务。

2. Worktrees（工作树隔离）

用于隔离并行功能开发。智能体在独立的 Git 工作区工作，避免多个任务在同一个工作目录并行时代码发生覆盖冲突。Codex App 内置了独立工作树，Claude Code 则依靠标准的 git worktree 命令实现环境防冲突隔离。

3. Skills（意图与规约沉淀）

将项目的具体知识与构建测试意图固化下来，直接对抗随项目膨胀而累积的意图债务。通常将项目定制化指令（如构建流程、测试断言）写入 SKILL.md 中，避免智能体每一次运行都在重新猜测项目的开发规范。

4. Plugins & Connectors（插件与外部连接器）

打通工具链的关键组件，使智能体能够触达真实世界的系统。通常基于模型上下文协议（MCP），让智能体可以原生接入 Linear 任务板、Slack 频道、生产环境数据库及 GitHub 存储库。

5. Sub-agents（子智能体分工）

实现制造者（Maker）与检查者（Checker）角色的职责分离。在 .codex/agents/ 或 .claude/agents/ 中定义分工，由写代码的智能体负责产出修复方案，独立的审查智能体负责在合规与测试边界上进行卡点。

6. State / Memory（外部状态存储记忆）

由于智能体本质上是无状态的，循环机制必须在单次会话上下文之外维护状态。Addy Osmani 强调，这种记忆通常以本地 Markdown 文件（如 AGENTS.md）或 Linear 看板的形式保存在代码仓库之外。因为 Agent 可能会遗忘，但代码库与状态文件不会。

完整循环示例：自动化流如何运转

为了生动呈现“异步自治”的研发体验，Addy Osmani 在文章中分享了他自己每天运行的一个典型自动化循环。

在每天早晨人类工程师尚未抵达工位之前，后台定时自动化脚本已悄然启动。系统首先拉取昨天的 CI 构建日志和 GitHub 上的待修复 Issue，然后将分析结果写入 Markdown 文件或 Linear 看板。

紧接着，系统针对识别出的待修复 Issue，利用 Git Worktree 在后台开辟出一个完全隔离的分支空间。写代码的智能体（Maker）开始在独立的分支里起草修复代码；与此同时，负责验证的智能体（Verifier）读取 SKILL.md 中配置的项目指令，自动进行本地构建并循环测试，发现错误即命令 Maker 自我纠错，直至所有的测试集绿灯通过。

在测试全部通过后，连接器会自动把修改推送并向 GitHub 发起 Pull Request。当工程师坐在电脑前时，他只需对已经就绪的代码补丁进行终审，而无法被自动闭环的复杂问题则会安全地保留在收件箱中等待人类处理。

循环解决不了的三件事

然而，即便自动化循环展现出了惊人的生产力，Addy Osmani 依然清醒地在文中提醒读者：循环工程绝非万能的解药。在大语言模型生成代码的速度发生指数级增长的同时，开发者也将不可避免地遭遇以下 3 个隐性挑战。

1. 验证责任的滞留

智能体所声称的“任务已完成”仅仅是它的文字声明，而绝不是技术上的确凿证明。测试套件本身可能存在逻辑盲区，AI 甚至可能会去修改测试用例本身以迎合结果。如果人类放弃在最后关卡的仔细确认，研发循环就会在顷刻间变成“无人值守地制造故障”。

2. 理解力债务的快速积压

当系统运行完全被自动化循环接管，开发者没有亲自写过、甚至从未通读过的代码行数将呈指数级增长。长此以往，团队对整个庞大系统的全局理解力就会产生严重的债务断层。

3. 认知妥协与投降的诱惑

面对智能体自动起草、表面天衣无缝的修复代码，人类的本能往往是贪图舒适，直接予以点击合并。这种放弃独立思考、全盘投降于算法黑盒的姿态，不仅是现代软件工程中最大的安全稳定性隐患，同时也是最危险的思维逃避。

构建循环，但保持工程师身份

回到宏观层面，循环工程对软件行业的真正影响在于，它将效率杠杆点向上推了一层。正如 Boris Cherny 所判断的，虽然 AI 的演进移动了开发者的效率杠杆支点，但软件工程的工作本身并没有变得简单。设计一套鲁棒的、能够自愈的循环系统，比直接编写提示词或者自己写代码，难度只增不减。

同样的自动化循环，可能会产生截然相反的结果。优秀的开发者能够运用高阶的判断力，将重复的体力劳动剥离给循环，让自己专注于更高维度的架构与业务逻辑；而逃避思考的开发者，则可能将循环变成遮蔽自己理解技术细节的黑盒。构建循环，但要保持你的工程师身份。

相关资源

原文博客
Codex App 自动化文档
Claude Code / Agent Skills 指南