我不再手动提示 Claude 了。我运行着循环，让 Claude 自己提示自己并决定下一步做什么。我的工作就是编写这些循环。
—— Boris Cherny，Anthropic 公司 Claude Code 的创始人和负责人。
大约两年来，每个人都在追逐的技能是提示工程。写好一条提示，提供足够的上下文，阅读输出，再写下一条提示。你像使用工具一样操控 Agent，一次一个回合。
那个时代正在悄然结束。
2026 年中，三位业界领袖在短短几天内不约而同地提出了同一个理念。Boris Cherny（Claude Code）表示，他现在的工作是编写循环。Peter Steinberger（OpenClaw 的创始人）对数百万开发者说："你不应该再手动提示编程 Agent 了。你应该设计循环，让循环来提示你的 Agent。" 而 Google 的 Addy Osmani 在一篇广为流传的文章中为这种模式命名：循环工程（Loop Engineering）。本文旨在深入解析循环工程究竟是什么，它解决了哪些问题，如何解决，提供一个你今天就能运行的代码演示，以及那些在 hype 帖子里没人会提的真实权衡。
什么是循环工程？
循环工程就是用你自己设计的一个系统来替代你作为提示 Agent 的那个人。你设计一个系统，让它来负责提示。
一个循环就是一个递归目标：你定义一个目的和一个可验证的停止条件，然后 AI 进行迭代——发现工作、执行工作、验证工作、记录进度——直到条件满足。你不再处于循环之中。你凌驾于循环之上。
你可以这样理解这个层级：
- 提示工程：你写一条好的指令。
- 上下文工程：你围绕指令组织正确的信息。
- Agent 工具链工程：你构建一个 Agent 运行的环境。
- 循环工程：你构建一个系统，让这个工具链按定时器运行，生成辅助 Agent，并验证结果。
旧的工作流程：写提示 → 阅读输出 → 写下一条提示（你就是那个循环）。
新的工作流程：设计一次循环 → 循环发现工作 → 循环分配 Agent → 循环验证结果 → 循环记录状态 → 重复（你负责审查和引导方向）。
循环工程解决的问题
问题 1：你就是瓶颈
在手动提示模式下，除非你输入，否则什么都不会发生。每一个回合都在等待人类。2026 年的 Agent 可以自主运行数小时，Claude Opus 级别的模型在困难任务上可以无人值守运行近五个小时——但人类驱动的聊天模式将它们限制在你的打字速度和注意力范围内。Agent 有 95% 的时间处于空闲状态，在等你。
问题 2：Agent 在会话之间会忘记一切
每次会话都是从零开始。模型会重新推导你项目的约定、构建步骤和来之不易的经验教训——或者更糟，用自信的猜测来填补空白。这就是 Osmani 所说的意图债务（intent debt）：未明确说明的意图，每次运行时都要重新偿还（或重新猜测）。
问题 3：Agent 给自己的作业打分
一个自己写了代码的 Agent，在审查时往往会过于宽容。"完成了"只是一个声明，而不是一个证明。没有独立的验证，自主运行会不断累积错误，而不是修复错误。
问题 4：并行 Agent 会相互冲突
一旦你在一个代码库上运行多个 Agent，它们就会开始互相覆盖对方的文件——就像两个工程师不沟通就提交到同一行代码一样，结果是一场灾难。
问题 5：重复性工作从未被自动化
CI 失败排查、依赖更新、不稳定测试排查、Issue 分类、每日 Bug 清理——这些工作无聊、没完没了，但非常适合 Agent 来做。然而，没有人会每天早上提示 Agent 去做这些事，因为你必须每天早上出现来执行提示。
循环工程如何解决这些问题：六大构建模块
一个真正能无人值守运行的循环，不是一条长提示。它是一个包含五种能力加一种记忆的小型系统。值得注意的是，Claude Code 和 OpenAI 的 Codex 现在都原生支持了这六种能力——循环的形态已经变得与具体工具无关。
- 自动化（Automations）：心跳
定时运行，自动进行发现和分类。这解决了问题 5。
- Claude Code： /loop 按节奏重新运行提示（从一分钟间隔到多天窗口），cron 定时任务，用于云端调度自动化的 Routines，生命周期钩子，或者用于在关闭笔记本电脑后仍能运行的 GitHub Actions。
- Codex： Automations 选项卡——选择一个项目、一条提示、一个节奏；发现结果会进入 Triage 收件箱，空运行会自动归档。
会话内最强大的原语是 /goal：持续跨回合工作，直到你编写的条件被可验证地满足——例如"test/auth 中的所有测试通过且 lint 干净"——然后你就可以走开了。
- 工作树（Worktrees）：并行隔离
Git 工作树为每个 Agent 提供其自己的工作目录和自己的分支，共享仓库历史。编辑操作根本不可能冲突。这解决了问题 4。
- Claude Code： git worktree，--worktree 标志，或者在子 Agent 上使用
isolation: worktree，这样每个辅助 Agent 都能获得一个全新的、自动清理的代码检出。 - Codex： 每个线程内置的工作树。
高级用户报告说，他们可以通过这种方式运行 10–15 个并行 Agent。
- 技能（Skills）：编码化的项目知识
一个技能就是一个包含 SKILL.md 的文件夹——你的约定、构建步骤，以及"我们之所以不这样做是因为那次事故"——一次编写，Agent 每次运行都读取。这解决了问题 2。没有技能，循环每次都会从零开始重新推导你的项目。有了技能，知识会不断累积。
- 插件与连接器（MCP）：触及真实工具
一个只能看到文件系统的循环是一个很小的循环。MCP 连接器让它能够读取你的 Issue 追踪器、查询数据库、打开 PR、更新 Linear 工单，以及在 CI 变绿时通知 Slack。这就是一个 Agent 说"这是修复方案"和一个循环交付修复方案之间的区别。
- 子 Agent（Sub-agents）：将制造者与检查者分开
这是整个模式中最重要的结构性思想。一个 Agent（或模型）负责编写；另一个不同的、带有不同指令的 Agent 负责验证。这解决了问题 3。Claude Code 的 /goal 内置了这一点：一个独立的模型负责评估停止条件是否满足，这样工作者就永远不会给自己的作业打分。
- Claude Code： .claude/agents/ 中的子 Agent，Agent 团队。
- Codex： .codex/agents/ 中以 TOML 格式定义的子 Agent——例如，一个高推理能力、强大的模型作为你的安全审查员，一个快速的只读模型作为你的探索者。
- 状态（State）：记忆主干
一个 Markdown 文件、一个进度日志、或者一个 Linear 项目——任何存在于对话之外并记录已完成和下一步工作的事物。听起来简单得不像回事。但这是每个长时间运行的 Agent 都依赖的唯一技巧：模型会在运行之间遗忘；但代码库不会。 这也从任务层面解决了问题 2，并且它让明天的运行能够从今天停止的地方精确地继续。结合自动化，它消解了问题 1——循环在你睡觉时工作。
一个真实循环的样子
这是一个参考形态（改编自 Osmani 自己的日常循环）：
- 一个自动化任务在代码库上触发。它的提示调用一个分类技能，该技能读取昨天的 CI 失败、开放的 Issue 和最近的提交，并将发现结果写入 STATE.md。
- 对于每个值得做的发现，循环打开一个隔离的工作树，并派遣一个制造者子 Agent 来起草修复方案。
- 一个检查者子 Agent 根据项目技能和现有测试审查草稿。
- 连接器打开 PR，关联工单，并发布到 Slack。
- 循环无法处理的任何事情都会进入一个分类收件箱——留给你。
- STATE.md 记录了尝试了什么、通过了什么、还有什么未解决。明天的运行将从这里继续。
来源与延伸阅读：Addy Osmani, "Loop Engineering" (addyosmani.com); The New Stack 关于循环工程的报道; Boris Cherny 在 Meta 的 Scale 大会上的炉边谈话及 CNBC 采访; Claude Code 关于 Routines 的文档 (code.claude.com/docs/en/routines); OpenAI Codex Automations 文档。
如果你根据这篇文章构建了一个循环，我很想看看！！请回复告诉我你首先自动化了什么。
