你的工作是「写循环」：一文读懂 2026 年最新范式 Loop Engineering

John_ToDebug

147人浏览 · 2026-07-12 13:25:17

John_ToDebug · 2026-07-12 13:25:17 发布

本文基于 bestblogs.dev 的《Loop Engineering 完全指南》主题解读深度整理，综合 Addy Osmani、Boris Cherny、Andrej Karpathy、MacTalk 等多方观点。

引子：一句话引爆硅谷的新词

2026 年 6 月，硅谷 AI 圈又冒出一个新词——Loop Engineering（循环工程）。

它的起点有两个：一个是 Google Cloud AI 总监 Addy Osmani 的同名文章；另一个是 Claude Code 之父 Boris Cherny 那句被反复引用的话：

“我已经不再手动提示 Claude，而是写好一堆循环让它们去提示 Claude、并决定下一步做什么。我的工作就是写循环（My job is to write loops）。”

这句话之所以刺耳，是因为它宣告了一个姿势的转变：过去两年我们一直握着 AI 这把工具，现在我们要放手,去搭一个替我们握着工具的系统。

如果只能用一句话定义 Loop Engineering，那就是：

你不再亲自做那个提示 Agent 的人，而是去设计一套替你提示它的系统。

一、把它放进演进线里，才不会误解

要真正理解循环工程，不能孤立地看它，而要把它放进一条清晰的四层演进线里。从下往上，人离「关键路径」就更远一层：

层级	名称	提出时间	关注点
第 1 层	Prompt Engineering（提示词工程）	—	优化输入给模型的文字
第 2 层	Context Engineering（上下文工程）	2025 年中	怎样把恰当的信息填进上下文窗口
第 3 层	Harness Engineering（挽具工程）	—	设计单个 Agent 运行所在的工程环境（目标、上下文、权限、验证、回滚）
第 4 层	Loop Engineering（循环工程）	2026 年 6 月	让 Harness 跑在定时器上、自己派生小助手、自己喂自己

关键在于：这四层是叠层关系，不是互相取代。

Prompt 优化输入文字；
Context 决定填什么进窗口；
Harness 设计单个 Agent 的运行环境；
Loop 则坐在 Harness 的上面一层：让 Harness 按节拍运行、派生子 Agent、自我喂养。

所以《完全指南》特意把 Loop Engineering 定义为一个 DOMAIN（需要长期掌握的领域），而不是一次转瞬即逝的热点事件。如果你还没搞懂下面三层，建议先补齐，否则很容易把四个概念混为一谈。

二、姿势的改变：从「握着工具」到「搭个系统」

过去两年，从 Coding Agent 拿结果的方式是这样的：

你写一段好提示、给足上下文，敲一句、读一句、再敲下一句。它是工具，而你全程握着它。

循环工程改变的正是这个姿势：

你搭一个小系统，它自己发现要做的活、把活分出去、检查结果、把结论写下来，然后决定下一步。由这个系统去戳 Agent，而不是你。

这里有一个必须强调的澄清（来自 MacTalk 对 Boris Cherny 被误读的纠正）：

提示词并没有消失。 它依然在循环里，只是不再由你一句句手敲。循环工程只是 Agent 工具的自然进化。

这一点非常重要——很多人一听说「不再提示 AI」就以为提示词工程死了，这是彻底的误读。工程师的责任没有变，变的只是责任所处的层级。

三、核心拆解：五大模块 + 一处外部记忆

循环工程的完整定义是：你定义一个目的，AI 持续迭代直到完成。 它由五大模块加一处外部记忆构成，让「单次运行」变成一个「可以自己重复、自己推进的系统」。

好消息是：这五大模块今天在 Codex 与 Claude Code 上几乎一一对应，都已具备全部能力，你不再需要自己写一堆 bash 脚本去维护。

五大模块

模块	作用	Claude Code	Codex
Automations（自动化）	定时发现与分类，是循环的「心跳」	hooks/cron 调度	Automations 标签页 + Triage 收件箱
Worktrees（工作树）	并行隔离的底座：为同一仓库开出独立工作目录与分支，让多个 Agent 并行编辑而不互撞文件	git worktree 隔离	内建 worktree
Skills（技能）	把项目知识固化成 `SKILL.md`（指令 + 可选脚本），让循环不必每轮从零重建项目意图	Skills	Skills
Plugins / Connectors（插件 / 连接器）	用 MCP 接入真实工具：读 issue、查数据库、打 staging API、发 Slack	MCP 连接器	MCP 连接器 + `.codex/agents`
Sub-agents（子 Agent）	产出与检查分离：一个负责产出，另一个用不同指令甚至不同模型去审查	Sub-agents	`.codex/agents` 子 Agent

补充概念：Skill 是编写格式，Plugin 是分发方式。 MCP 是连接器的开放标准——因为 Codex 与 Claude Code 都讲 MCP，所以一个连接器常能两边通用。

一处外部记忆（循环的脊柱）

这是所有长周期循环依赖的同一个朴素技巧：

模型在两次运行之间会忘掉一切,所以你要给循环一根「脊柱」。

用一个对话之外的状态文件（一个 Markdown 文件，或一块 Linear 看板）记住进度，让明早的运行能接着昨天继续。

人会忘,仓库不会。 用看板而非对话历史来持有进度，Markdown 文件则是更轻量的等价物。

四、跑通最小循环：`/loop` 与 `/goal`

理论说再多，不如亲手跑一次。MacTalk 强调:先真用一次，再下结论。 最小循环靠两个原生命令:

/loop：按设定的节拍重复运行一段提示，像心跳一样（接近 cron）。
/goal：持续运行直到你写的条件为真，每轮后由一个独立模型判定是否真的完成。Codex 也有同名的 /goal。

这里藏着一个关键的设计哲学。为什么 /goal 要用独立模型判定？因为:

写代码的模型给自己打分太宽容了。 循环里最有用的结构,就是让一个子 Agent 负责产出、另一个用不同指令甚至不同模型去审查。

切记不要把 loop 简化成一行定时脚本。 /loop 确实接近 cron，但 /goal 是按条件停止——设定可验收的目标，由独立模型每轮判定。再加上 worktree、skills、connectors、sub-agents 与外部记忆，循环才是一个「会发现、分配、检查、推进」的系统，而非一行 crontab。

建议的上手路径：

先读 Addy Osmani 的原文，再看 Paweł Huryn 的演进图，确保能清楚区分 prompt / context / harness / loop 四层；
在 Claude Code 或 Codex 里亲手跑一次 /loop 与 /goal，设一个可验收的停止条件让它自己跑到完成；
把循环补全成系统:接上 Automations（心跳）、Worktrees（并行隔离）、Skills（SKILL.md）、Connectors（MCP）、Sub-agents（产出/检查分离）；
给循环加上外部记忆脊柱 + 一个独立的检查者子 Agent。

五、进阶：堆叠循环（Stacking Loops）

当你能稳定跑一个循环之后，真正的进阶是 堆叠循环（stacking loops）——一层套一层。

Andrej Karpathy 的判断很直接：

未来很长一段时间的竞争,就是看谁能最高效地把循环叠起来。

他还有一句更本质的话，道出了堆叠的动机:

“我不想当那个盯着结果的研究员,我在拖慢系统。问题是怎么重排所有抽象,让我只需安排一次然后按下开始。”

换句话说,循环工程师的目标是把自己从瓶颈位置移出去。其实我们早已身处一层套一层的循环之中,只是现在要有意识地去设计它。

两个方向：Going Down vs Going Up

堆叠循环时,你要在两个方向之间做判断:

Going Down（向下,求稳）:用杠杆换取可靠性——把自动化退回到人工把关。适用于早期阶段,出问题时你要懂得往下退。
Going Up（向上,求快）:用可靠性换取杠杆——把原本人工的判断也交给一个新循环。适用于模型变强、你有信心的时候。

判断什么时候该往哪个方向走,正是「循环工程师」区别于「只会按开始的人」的地方。

对应 Karpathy 的那句箴言:别再亲手修,去做能随更多 Agent 扩展的系统。

六、进阶者必须盯住的三个成本与风险

向上堆叠不是免费的。进阶者必须同时盯住三个成本：

1. Token 成本会成倍上升

循环会自己花钱。子 Agent 各自跑模型、跑工具,token 消耗成倍上升。Addy Osmani 反复提醒:把「第二意见」花在真正值得的地方,而不是给每一步都配一个审查者。

2. 编排税（Orchestration Tax）

一个残酷的现实约束:

你能并行跑多少个 Agent,取决于你能认真看完多少 diff,而不是工具支持多少路。

工具支持 100 路并行没用,你只看得完 3 个 diff,那你的真实并行度就是 3。

3. 认知与理解的腐烂（Comprehension Debt）

这是最隐蔽也最危险的成本,《完全指南》用了很重的笔墨:

验证仍在你身上:循环无人值守,它犯错也无人值守;
理解力会腐烂:出活越快,你与代码之间的认知缺口越大,即所谓 comprehension debt（理解债）;
最危险的是:循环一顺,你就懒得有观点了。

七、灵魂拷问：同一个循环，两个人跑出相反结果

《完全指南》把整个讨论收在一句非常克制、也非常深刻的话上:

同一个循环,两个人能跑出完全相反的结果。 一个人用它在自己深刻理解的工作上跑得更快;另一个人用它来彻底回避理解。循环不知道区别,你知道。

这也解释了为什么作者反复强调:

设计循环比写提示更难,而不是更容易。

同一个动作,带判断地做是解药,为逃避思考而做是加速剂。

Osmani 的告诫堪称本文最好的结语:

设计循环,但要像一个打算「继续当工程师」的人,而不只是一个「按开始」的人。

八、常见误解快速澄清（FAQ）

Q1：提示词工程是不是死了?
不是。提示词依然在循环里,只是不再由你一句句手敲。它是 Agent 工具的自然进化。

Q2：Loop 就是 cron 定时脚本吗?
不是。/loop 确实接近 cron,但 /goal 是按条件停止——由独立模型每轮判定是否完成。再加上 worktree、skills、connectors、sub-agents 与外部记忆,它是一个完整系统。

Q3：它和 Harness Engineering 什么关系?
循环工程坐在 Harness 上一层。Harness 是单个 Agent 运行的工程环境;循环工程是「让 Harness 跑在定时器上、自己派生小助手、自己喂自己」。

Q4：我需要自己写一堆 bash 脚本来维护循环吗?
不需要。五大模块已经直接长在产品里(Automations / Worktrees / Skills / Connectors / Sub-agents),在 Codex 和 Claude Code 上几乎一一对应。好的实践不是绑死某个工具,而是设计一个换工具也成立的循环。

Q5：无人值守循环最大的风险是什么?
三件事会随循环变好而变得更尖锐:验证仍在你身上、理解力会腐烂(comprehension debt)、以及「循环一顺就懒得有观点」。