别再手敲Prompt 了！ Loop Engineering 机理结构来啦！

公众号名称：ElonMax

作者名称：ElonMax

发布时间：2026-06-16 11:58

别再写 Prompt 了，设计 Loops

你今天的编码智能体使用流程，大概率是这样的：

打开 Claude Code 或 Codex。写一条 prompt。看它修改文件。跑测试。报错了。把错误信息贴回去。等它修复。再跑测试。又报错了。你再贴。它再修。二十分钟过去了，你意识到自己干的活，跟一个监督实习生一遍遍重写同一段代码的人没有任何区别——只不过这个实习生的名字叫 Claude。

你不是一个人。绝大多数开发者的编码智能体使用方式，到今天为止，仍然停留在这条无尽的 Prompt → Edit → Test → Fix → Re-prompt 循环里。每一轮消耗的都是你最稀缺的资源：注意力。

2026 年 6 月 7 日，三个来自不同阵营的人，在同 48 小时内说了同一件事。

Peter Steinberger（OpenClaw 创始人）在 X 上发了一条推文，220 万次查看，撑爆了回复区。他说的是：“You shouldn’t be prompting coding agents anymore. You should be designing loops that prompt your agents.”

同一天，Boris Cherny，Anthropic 的 Claude Code 负责人，在台上说了几乎一样的话：“I don’t prompt Claude anymore. I have loops running that prompt Claude and figuring out what to do. My job is to write loops.”

而 Google 的 Addy Osmani 在同一天发表了一篇完整的博文，给这个新模式取了个名字——Loop Engineering。

这篇文章就是把那套框架拆给你看。它由 5 个构件加 1 个记忆系统组成，已经在 Codex 和 Claude Code 中完整内置。你可以今天就开始用它。

你不再是操作员了

它的改变只有一句：提示词不再是你的心智产出，而是系统的运行时输入。

你不再是一个 Prompt 操作员——不再坐在电脑前，每 90 秒写一条新 prompt，等它回复，判断下一步，再写下一条。你的角色变成了 Loop 架构师——设计一个可以在你不在场时自己决定下一步做什么的系统。

Loop 不是自动化。自动化是”做步骤一，然后步骤二，然后步骤三”——每一步都是预定义的。Loop 是”观察当前状态，决定下一步做什么，执行它，检查结果，然后决定是否再来一轮”。核心循环只有四个词：Act → Observe → Reason → Repeat。

Loop 核心循环：Act → Observe → Reason → Repeat

Loop 也不是 cron job。cron job 在固定时间运行一个固定脚本。Loop 运行的是一个自带决策器的智能体——它根据自己的观察结果决定当前时刻该做什么。你能信任它这么做，是因为 2026 年的 Codex 和 Claude Code 已经足够聪明，能够在合理范围内理解你设的目标和评价标准。

但光有聪明不够。Loop 能工作，是因为它背后有一套完整的构件框架支撑。

5+1 构件拆解

Addy Osmani 在这篇博文里把 Loop 的生命系统拆成了 5 个构件加 1 个跨运行记忆。这个框架后来被 Reach VB、Shann Holmberg 等多名社区成员确认接受。关键洞察是：这 6 样东西在 Codex App 和 Claude Code 中功能完全等价——你的 Loop 设计可以在两个工具之间移植。

Automations：心跳

Automations 是 Loop 的定时起搏器，/goal 由模型判断停止

Automations 是 Loop 的定时起搏器。没有它，Loop 是一个只能由你手动启动的单次运行。

它的工作机制很简单：你选择一个项目、写一段 prompt、设定一个频率（每天、每小时、每次 PR 合并后），然后在它发现某些事情时通知你。Codex 的 Automations Tab 中，每个 Automation 还可以配置在本地 checkout 还是后台 worktree 上运行。运行结果分两类：找到有用的东西 → 进入 Triage 收件箱；什么都没找到 → 自动归档。

OpenAI 内部用这个做日常 issue triage、CI 失败摘要、提交周报、甚至自动搜寻上周引入的隐蔽 bug。每个 Automation 还可以调用一个 Skill——所以你是把”日常发现的 prompt”写成了一个可维护的模块，而不是贴在计划表上永远不会更新的大段配置。

Claude Code 通过不同的入口点实现了同一个能力：/loop（按固定间隔重复运行某条 prompt 或命令）、/goal（一直运行直到某个条件成立）、scheduled tasks（类 cron 调度）、hooks（在智能体生命周期的特定点触发 shell 命令），以及退到 GitHub Actions 上运行整个流程。

特别说一下 /goal。它才是最接近 Loop Engineering 灵魂的原语。你在 Claude Code 中输入 /goal 然后写一句类似”确保 test/auth 目录下所有测试通过且 Lint 干净”的描述。然后你直接走开。Codex 也有同名的 /goal。它背后的机制是：每一次执行结束后，由一个独立的小模型（不是写代码的那个模型）来检查停止条件是否满足。这就是”制造者与检查者分离”原则在停止条件上的最直接应用——自己的作业自己判分永远是宽松的。

Worktrees：并行不打架

Worktrees 并行隔离 + 审查者瓶颈

一启动并行，文件冲突就会立刻出现。两个智能体同时写同一个文件，跟两个工程师同时改同一行代码、没有事先通过气，一样的灾难。

Git worktree 就是解决这个问题的标准方案。它创建一个独立的可写工作目录，使用同一个仓库历史，但在自己的分支上修改。Agent A 的修改物理上不可能触及 Agent B 的 checkout。

Codex 将 worktree 支持直接内置于线程级。每个新线程自动获得一个隔离的 worktree。Claude Code 通过 git worktree 命令、--worktree 启动参数以及 Sub-agent 定义中的 isolation: worktree 配置来实现同样的隔离。

但这里有一个关键限制。Addy Osmani 在另一篇《Orchestration Tax》中明确指出了：worktrees 解决了机械冲突，但你，作为审核者，仍然是吞吐量的天花板。你的审查带宽决定了你实际能并行运行多少个 Loop 线程，而不是工具。worktree 是必要的基础设施，但它没有解决”你需要亲自审阅每一条 AI 生成的 diff”这个根本约束。

Skills：让智能体不再像个金鱼

Skills 解决 Intent Debt：写一次，每次读

每次你重启 Claude Code 或 Codex，它对你的项目了解程度跟第一次见面是一样的。它不知道你的编码约定、不知道你用的是哪个测试框架、不知道你讨厌用 Lodash。它从头开始猜。

一个 Skill 就是你把这些信息写下来的地方。它就是一个文件夹，里面有一个 SKILL.md 作为主文件，加上可选的脚本、示例代码、参考文档和静态资产。Codex 的 Agent Skills 和 Claude Code 的 Agent Skills 使用完全相同的格式。当智能体发现一个任务的描述与某个 Skill 的元数据匹配时，它会自动加载并执行这个 Skill。你也可以用 $skill-name 或 /skills 显式调用。

Addy Osmani 有一个很精巧的概念叫 Intent Debt（意图债务）：一个智能体每次启动都是冷启动，它会用自信的猜测填补你意图中的每一个空洞。Skill 就是你写在外部的那份”不再需要每次重说的意图”：编码规范、构建步骤、测试命令、“我们不这么做是因为有一次线上事故”——写一次，每次读。

没有 Skills 的 Loop 每一轮都从零重新发现你的项目。有 Skills 的 Loop 开始积累。积累的方向是对的还是错的，取决于你写在 Skill 里的内容质量。

Plugins & Connectors：触及真实工具

一个只能看文件系统的 Loop 是一个小到几乎无用的 Loop。Connectors——基于 MCP（Model Context Protocol）构建——让智能体可以阅读你的 Issue Tracker、查询数据库、访问 staging API、向 Slack 发送消息、读取监控告警数据。

Codex 和 Claude Code 都实现了 MCP。你用其中一个工具编写的 Connector 通常可以直接在另一个工具上运行。

这是”给你一个补丁你自己打”和”系统自动开 PR、链接 Linear ticket、CI 通过后通知频道”之间的全部区别。Connector 让 Loop 可以在你的真实环境中行动，而不只是告诉你”如果能做我会怎么做”。

Plugins 在此基础上再加一层：把 Connector 和 Skills 打包在一起，让你的队友一次安装就能复制你的整套 Loop 设置。Connector 是线路工程师，Plugin 是线路工程师加上操作手册。

Sub-agents：写代码的人不能同时是检查代码的人

三段式 Sub-agents：探索 → 实现 → 验证

这是所有构件中结构回报率最高的一个。

原因非常直接：写出代码的那个模型对自己产出的评价太仁慈了。它总是倾向于认为”这应该差不多了”。

解决办法是：第二个智能体，用不同的指令、有时用不同的模型，来检查第一个智能体的产出。

Codex 允许你在 .codex/agents/ 目录中以 TOML 文件格式定义自己的 Sub-agent。每个 Sub-agent 有自己的名称、描述、指令以及可选的模型和推理努力级别。这意味着你的安全审查员可以使用一个高推理努力级别的强模型，而你的探索者可以是一个快速只读的小模型。

Claude Code 将 Sub-agent 放在 .claude/agents/ 目录下，并提供了 agent teams 让多个 Sub-agent 之间可以传递工作。

最常用的三段式分工是：一个 Agent 做探索（查找相关代码、读取文档），一个做实现（修改代码），一个做验证（对照规格、跑测试、审查 diff）。

这听起来会多消耗 Token——每个 Sub-agent 都需要自己的模型调用和工具调用。确实如此。所以要把 Sub-agent 用在”第二意见值得付钱”的地方。当你不在场时运行的 Loop，一个你信任的验证者是唯一让你能安心走开的理由。

第六个：State——模型会忘记，仓库不会

前面 5 个解决的是”怎么运行”。State 解决的是”怎么记住运行了什么”。

这听起来过于基本，不值得占一个位置。但它可能是整个架构中最能决定成败的构件。原因是模型在两次运行之间什么都记不住——上下文清零、进程终结、一切关于上一次运行状态的信息全部消失。

解决办法是一个朴实到荒谬的方案：一个 Markdown 文件、一个 JSON 文件、一个 Linear Board、一个 SQLite 数据库。随便选一个最顺手的，然后让每一次运行都在开始时读它，在结束时追加到它。

这个文件记录的是：什么被尝试了、什么通过了、什么失败了、什么还在进行中。它同时是通信协议（不同 Sub-agent 之间通过这个文件交换状态）和持久化层（明天早上的 Automations 从这里接上昨天停止的位置）。

“Agent forgets. The repo doesn’t.”

以上 6 样东西在 Codex App 和 Claude Code 中都有各自的实现方式，名字不完全一致，但能力是完全重叠的。

构件	在 Loop 里的职责	Codex App	Claude Code
Automations	定时发现 + Triage	Automations Tab（选项目、写 prompt、定频率、结果集中到 Triage 收件箱）+ /goal	Scheduled tasks + /loop + /goal + hooks + GitHub Actions
Worktrees	并行隔离	每条线程内置隔离 worktree	git worktree + —worktree 参数 + Sub-agent isolation:worktree
Skills	编码项目知识	Agent Skills（SKILL.md），\$name 或自动匹配调用	Agent Skills（SKILL.md）
Plugins/Connectors	接入真实工具	MCP Connectors + Plugins	MCP Servers + Plugins
Sub-agents	分工（写 vs 检查）	.codex/agents/ TOML 定义	.claude/agents/ + agent teams
State	跨运行记忆	Markdown / Linear via Connector	AGENTS.md / progress files / Linear via MCP

关键结论：一旦你注意到形状是相同的，你就会停止争论哪个工具更好，开始设计一个在任一个工具上都能跑的 Loop。

一个完整的 Loop：从清晨到 PR

把以上 6 个构件拼在一起，一条日常 Loop 大概长这样。

早上 6 点，一个 Automation 在 Codex 或 Claude Code 中被触发。它调用一个叫”每日 Triage”的 Skill。这个 Skill 读取昨天的 CI 失败记录、当前未分配的 Issue、以及最近 24 小时内的合并提交。它把这些信息整理成一份摘要，写入 State 文件（假设是一个 Markdown 文件）。

Automation 的 prompt 中有一条规则：对于每一个 CI 失败，如果失败原因清晰且在项目中修复它所需的工时评估为”小”——就尝试修复。

对于这个”值得修”的信号，Automation 在一个隔离的 Worktree 中启动一个 Sub-agent。这个 Sub-agent 的使命是”阅读 CI 日志 → 定位失败代码 → 编写修复 → 确保所有相关测试通过”。当它认为自己完成了修复，它调用第二个 Sub-agent——验证 Agent——来审查 diff 并确认测试覆盖率没有下降。

如果两个 Sub-agent 都通过了各自阶段，Automation 通过 MCP Connector 创建一个 Pull Request，链接对应的 Issue，并在 PR 描述中引用 State 文件中的相关上下文。

如果修复尝试失败——测试仍然没有通过——Automation 会将这项任务标记到 State 文件中并放入你的 Triage 收件箱，不再继续消耗 Token。它不会永无止境地重试。

第二天早上同一个 Automation 再次触发时，State 文件中仍然写着”XXX 修复失败，等待工程判断”，但你昨天临睡前已经看了一眼那个 Triage 收件箱，做了一两个判断。Loop 接上你留下的状态继续运转。

看你在整个流程中做了什么？你设计了这个漏斗。你没有写任何一条”修复这个 bug”的 prompt。你早上在 Triage 收件箱里花了 15 分钟回答那些 Loop 没能力判断的问题。这个节奏跟 DevOps 团队处理告警的 On-call 流程几乎一模一样——系统自动过滤掉 90% 的噪音，把需要人类判断的信号留在你的桌面上。

三条硬刹车

上面描述的那条 Loop 看起来很美。它也有代价。2026 年 6 月的 Uber 提供了一个真实的注脚。

TechCrunch 报道：Uber 在短短 4 个月内烧完了全年的 AI 编码工具预算。之后将每名工程师每月的 Claude Code 和 Cursor 支出上限定为 $1,500/人月。

消耗从”写代码的成本”变成了”运行写代码的系统的成本”。这不是极端案例。这是 Loop 范式下的新常态。

任何一个能运行的 Loop，如果缺少以下三条硬刹车，它不是一个 Loop——它是一张开口的发票：

迭代次数上限

：一个卡住的 Loop 不能无限旋转
Diff 停滞检测

：当最近几轮已经没有任何代码变化时，停止运行
代币/美元支出上限

：在账单报警之前结束运行

这三个是必要非充分条件。它们是你的 Loop 设计在离开你视线运行时的最低安全约束。没有这三条，不要让你设计的 Loop 在没有监督时运行。

不是删除你，是转移你的支点

Loop Engineering 不是一个让你下岗的方案。它也不是一个让你可以放弃阅读代码的理由。

Boris Cherny 说”我的工作就是写 Loops”时，他说的不是那以后他就坐着喝咖啡了。他说的是他的支点变了。两年前我们写代码。一年前我们写 Prompt。现在，对于重复性的编码任务，我们设计 Loop。

但 Loop 不会自动解决三个问题：

验证仍然在你身上。一个无人监督的 Loop 也是一个无人监督地犯错误的 Loop。你设计验证 Sub-agent 来分开制造者和检查者，是为了让 Loop 的”它完成了”有些意义。但即使这样，“完成”是一个声明，不是一个证明。

你的理解会腐烂。Loop 送你代码的速度越快，你的代码库和你实际理解之间的鸿沟就越大。Addy Osmani 称之为 Comprehension Debt。一个流畅的 Loop 只是让这个债务积累得更快，除非你读它能送来的每一条 diff。

舒适的姿势是最危险的姿势。当 Loop 自行运转时，你非常容易停止拥有自己的判断，接受它给你的任何输出。Addy Osmani 称之为 Cognitive Surrender。设计 Loop 是当你使用判断力时的解药，也是当你用它来避免思考时的催化剂。同一件事，截然不同的两种结果。

“Two people can build the exact same loop and get completely opposite results. One uses it to move faster on work they understand deeply. The other uses it to avoid understanding the work at all. The loop doesn’t know the difference. You do.”

这就是为什么 Loop 设计比 Prompt 工程更难，而不是更简单。Cherny 的观点不是工作变少了。是支点转移了。

如果你想动手，起点不复杂。今天就可以打开 Claude Code 试一次 /goal，或在 Codex 中配置一个每天早上的 Automation。写一个你最熟悉的任务的 SKILL.md——哪怕只有三行。你需要的 5+1 个构件，都已经在你正在使用的工具里了。

Build the loop. Stay the engineer.

从 Prompt 操作员到 Loop 架构师：全貌升维图

内容效果不满意？点此反馈