Loop Engineering：从 prompt 到 loop 的瓶颈迁移
当模型足够强、harness 足够完善之后，最后的瓶颈不是工具而是坐在键盘前亲自按回车的你——loop engineering 说的是，松手吧。
原文：面试官坏笑："你怎么看 Loop Engineering？"我反问："不就是 /loop 吗？让 Agent 循环干活"，他摇了摇头…
AI 圈造词的速度比很多人学习的速度快。2023 年是 prompt engineering，2025 年是 context engineering，2026 年初是 harness engineering，现在，2026 年 6 月，loop engineering 来了。
点火的是 OpenClaw 作者 Peter Steinberger，他 6 月 7 日发了一条推文（800 多万浏览）：「你不该再给 coding agent 打 prompt 了。你该去设计那个给 agent 打 prompt 的 loop。」给概念定名的是 Google Cloud AI 总监 Addy Osmani，他写了一篇长文正式定义这个词。同一周，Claude Code 创始人 Boris Cherny 在访谈里说了一句为整个概念背书的话：「我已经不 prompt Claude 了。是 loop 在运行着 prompt Claude、决定做什么。我的工作是写 loop。」
三个视角不同、来自一线的人在同一周说了同一件事。
四个 engineering 是同一场瓶颈迁移
每个新词出现的背后都是同一件事：上一个瓶颈被解决了，新的瓶颈暴露出来了。
2023 年：模型只会一问一答，瓶颈在「怎么说」。大家研究话术：角色扮演、思维链、少样本示例。这就是 Prompt Engineering——跟一个聪明但一根筋的实习生说话的技巧。
2025 年：模型变强了开始当 agent 干活，光会说话不够。话术解决不了「巧妇难为无米之炊」——agent 没看过你的代码、不知道你的规范。瓶颈从「怎么问」移到了「喂什么」。把对的代码、文档、工具、历史记忆，在对的时机塞进上下文窗口，这就是 Context Engineering。
2026 年初：模型能连续干几小时活了，卡脖子的变成了 agent 干活的「环境」：工具执行、权限边界、沙箱、子 agent 派遣、上下文管理。这一整套运行装备叫 harness（直译马具，可理解为 agent 的驾驶舱）。公式：Agent = 模型 + harness。同一个模型，驾驶舱不一样，能力能差出几倍。这就是 Harness Engineering。
现在：话术有了、材料有了、驾驶舱有了。但整条流水线上，唯一还需要人肉驱动的环节是——你坐在屏幕前敲下那条 prompt。你睡觉，它就停工。
这就是 Loop Engineering 瞄准的最后一环：设计一个系统，让「下一次回车」不再由你来按。
Loop Engineering 是什么
Osmani 的正式定义：「Loop engineering 就是把『亲自给 agent 写 prompt 的那个你』替换掉。你转而去设计那个代替你做这件事的系统。」
loop 本身：一个递归式的目标，你定义一个目的，AI 持续迭代，直到完成。
过去两年，你跟 coding agent 的协作是回合制：写 prompt、读输出、写下一条 prompt，agent 是工具，你全程握着，一回合不能松手。
Loop engineering 说的是：松手，把「发现任务、布置任务、检查结果、决定下一步」这套流程设计成一个能自己运转的循环，然后让循环去握 agent。
打个比方：以前你是客服热线的接线员，每个电话都要亲自接、亲自答；现在你升级成设计工单系统的人：电话怎么分流、哪类问题转给谁、办结标准是什么、搞不定的怎么升级到你——规则定好，系统自己转。
这里有一个关键的支点移动：以前写一条好 prompt，收益是「这一次回答变好」；现在设计一个好 loop，收益是「之后每一次循环都变好」。投入从消耗品变成了资产。
但反过来，设计 loop 也比写 prompt 难得多：要考虑触发、并行、验证、状态、止损，相当于从「说一句话」升级到「设计一套制度」。杠杆变长了，对握杠杆的人要求也变高了。
一个 loop 由什么组成
把跑起来的 loop 拆开看，零件出奇一致：五大件 + 磁盘记忆。
自动化：loop 的心跳
如果每次都要你手动启动，它只是一个你跑过一次的任务，不是 loop。
定时或事件触发才让 loop 活着：每天早上自动扫一遍 CI 失败、每次 PR 合并自动跑一轮检查。心跳有了，循环才是循环。
worktree：让并行不变成打架
loop 一旦跑起来，经常是几个 agent 同时干活。两个 agent 同时改同一个文件——像两个工程师挤在同一台电脑上改同一行代码，互相不打招呼。
解法是 git 的 worktree 机制：给每个 agent 一个独立的工作目录和独立分支，共享同一份仓库历史，但物理上互不干扰。各干各的，最后各开各的 PR。
skill：治好 agent 的「金鱼记忆」
agent 有个天生缺陷：每个会话都是冷启动，你项目里的规范、约定、坑，它一概不知。于是不得不像对金鱼一样，每个会话把项目重新解释一遍。更要命的是，没解释到的地方它不会留空，它会用一个自信的猜测填上。
skill 就是把项目知识写成文件放在仓库里，让 agent 该用的时候自己读。对 loop 的意义比对单次会话大得多：没有 skill，loop 每个周期都从零重新推导；有了 skill，知识是复利的。
connector：让 loop 摸到真实世界
一个只能看见文件系统的 loop 撑死算半个 loop。真实工作流不止于代码：读 issue 工单、查监控、发消息、开 PR。
connector（基于 MCP 协议的连接器）是把外部系统接进来的桥。接上之前，agent 只会告诉你「修复方案在这里」；接上之后，loop 会自己开好 PR、关联工单，等 CI 变绿后自己去频道里通知人。
sub-agent：写的人和查的人必须分开
五大件里最有用的结构性设计：把写代码的 agent 和检查代码的 agent 分开。
理由只有一句话：写代码的那个模型，给自己的作业打分时，实在太手下留情了。
让 A 出方案，让一个干净上下文的 B 来挑刺——B 没有「希望自己是对的」的包袱，挑出来的问题才是真问题。
记忆：loop 的命根子
模型在两次运行之间会忘掉一切。今天的循环干了什么、哪些做完了、哪些卡住了，明天的循环一概不知道。
解法朴素到让人意外：把记忆放在磁盘上而不是上下文里。一个 markdown 文件、一个任务看板，什么都行，只要它活在单次对话之外，记录着「做完了什么、下一步是什么」。
Osmani 的博客里有一句很妙的总结：「agent 会忘，但 repo 不会。」
五大件让 loop 转得起来，磁盘上的记忆让它第二天还接得上。
一个真实的 loop 长什么样
Osmani 给了一个他自己在用的 loop，任务是每天早上自动把项目里值得修的问题找出来、修好、提交审核：
- 每天早晨，自动化准时触发，调用一个负责分诊的 skill。
- 这个 skill 读昨天的 CI 失败记录、还没关闭的 issue、最近的提交，把「哪些问题值得处理」写进状态文件。
- 对每一个值得做的问题，开一个隔离的 worktree，派一个 sub-agent 进去起草修复。
- 第二个 sub-agent（checker）登场，对照项目的 skill 规范和现有测试，把草稿审一遍。
- 审过了，connector 自动开 PR、更新对应的工单。
- loop 搞不定的问题，不硬来，丢进待办收件箱，等真人来看。
- 所有经过都写回状态文件。明天早上的循环从今天停下的地方继续。
整个过程里，你只设计了一次，中间任何一步都没有写过 prompt。
一个好 loop 的标志：你只在设计时出现一次，之后只在收件箱前出现。
工具已经追上来了
一年前搭一个 loop 意味着写一堆只有你自己看得懂的 bash 脚本；现在，五大件全部内置在主流产品里。
| 部件 | 在 loop 里的职责 | Codex | Claude Code |
|---|---|---|---|
| 自动化 | 定时发现和分诊 | Automations 面板 + 分诊收件箱 | 计划任务、/loop、hooks |
| worktree | 隔离并行任务 | 每个线程内置 worktree | git worktree、隔离配置 |
| skill | 固化项目知识 | Agent Skills | Agent Skills |
| connector | 连接外部工具 | 基于 MCP 的 Connectors | MCP servers |
| sub-agent | 分头干活、写查分离 | 配置文件定义子 agent | 子 agent、agent teams |
| 记忆 | 追踪进度 | markdown 或接工单系统 | markdown 或接工单系统 |
两家产品的部件几乎一一对应，这意味着 loop 的设计正在变得工具无关。值得积累的是 loop 的图纸，不是对某家工具的肌肉记忆。
还有一个值得单独注意的细节：普通的循环是按节奏重复跑，跑完就完；而 /goal 类的能力是跑到你写的条件为真才停（比如「目录下所有测试通过且 lint 干净」），而且每一轮结束后由一个独立的模型来判断条件是否达成——这就是写查分离用在「什么时候算干完了」这个停止条件上。连「我做完了」这句话，都不让干活的 agent 自己说。
实操：最小 loop
一个烦过的场景：提了 PR，开始等 CI，挂了，切回去看日志改代码推送，再等，一下午切了八次窗口。
在 Claude Code 里，用一条命令交出去：
1
/loop 10m 检查当前分支 PR 的 CI 状态：有失败的检查就读日志、修复、推送；全部变绿后停下来，给我一句话总结改了什么
拆开看：10m 是心跳，中间那段是任务，最后一句是停止条件加汇报。敲下去就可以去干别的了。
也可以省掉间隔，直接 /loop 加任务，节奏由模型自己定——它会根据「CI 一般要跑多久」来决定多久看一次，不会傻乎乎地一分钟刷一次。
两个边界需要清楚：
/loop活在当前会话里，关掉电脑它就停了。想要睡觉时也在跑的 loop，要用计划任务或云端 routines。- 这个最小 loop 只有心跳、任务和停止条件，没有 worktree、没有写查分离的 sub-agent。这是起点，不是缺陷——先让最小循环转起来，觉得「它改的代码我不放心」再加 checker sub-agent，觉得「想同时盯三个 PR」再上 worktree。部件是一件一件长出来的。
三盆冷水
给概念定名的 Osmani 本人在博客里直说：「现在还早，我是持怀疑态度的。」
loop 改变了工作，但没有把你从工作中删除。有三个问题会随着 loop 越来越好用，变得越来越尖锐。
验证仍然归你
一个无人值守运行的 loop，也是一个无人值守犯错的 loop。你睡觉时它在干活，也意味着你睡觉时它在犯错。
就算按规矩配了负责检查的 sub-agent，checker 嘴里的「done」只是一个声明，不是一个证明。它说没问题，和真的没问题，中间还隔着你的眼睛。
理解债，越顺滑涨得越快
loop 交付你没写过的代码越快，「仓库里实际存在的东西」和「你脑子里真正理解的东西」之间的鸿沟就越大。这有个专门的名字：理解债（Comprehension Debt）。
它和技术债不一样：技术债是代码烂，理解债是代码可能不烂，但你不知道它为什么是对的。出问题那天，你面对的是一片自己「拥有」但不「理解」的代码。
一个顺滑的 loop 不会帮你还这笔债，只会让它涨得更快，除非你坚持去读 loop 的产出。
认知投降，最舒服的姿势最危险
loop 自己转起来之后，最舒服的姿势是：不再对产出有自己的观点，它给什么就收什么。这叫认知投降（Cognitive Surrender）。
Osmani 的博客里有一段很锋利的话：「带着判断力去设计 loop，它是解药；为了逃避思考去设计 loop，它是助燃剂。同一个动作，相反的结果。」
还有一笔现实的账：token 成本。loop 是按循环烧 token 的，sub-agent 每多一个就多一份开销。比较务实的花法，是把 sub-agent 用在「值得买第二意见」的地方，而不是处处双保险。
核心
loop engineering 的本质不是把你从工作里删除，而是把你的工作从「每次输入 prompt」升级到「设计生产 prompt 的系统」。前者是消耗，后者是资产。
瓶颈迁移的规律已经很清晰：模型每变强一截，瓶颈就往外移一层——从你说的那句话，到你给的材料，到它干活的环境，最后落到坐在键盘前的你本人身上。loop engineering 是这条迁移链的当前终点站，但不会是最后一站。
五大件（自动化 + worktree + skill + connector + sub-agent）加磁盘记忆，是让 loop 从概念变成能跑的工程结构。其中最反直觉但最重要的一点：连「我做完了」这个判断都不能让干活的 agent 自己说——checker 必须是另一个干净的上下文。
Osmani 的结尾值得反复读：「两个人可以搭一模一样的 loop，得到完全相反的结果。一个用它在自己深刻理解的工作上加速，另一个用它彻底逃避理解工作。loop 分不出区别，你分得出。」
评价
这篇文章把 prompt/context/harness/loop 四个工程概念串成一条「瓶颈迁移」的叙事线，思路是干净的，没有硬造差异感。
说得好的地方：
- 「消耗品 vs 资产」的类比把 prompt 和 loop 的核心差别说透了，比单纯讲「自动化」更准确。
- 三盆冷水放在文章末尾而不是藏起来，Osmani「解药 vs 助燃剂」那段引用是全文最有价值的一句话。
- 工具对照表（Codex vs Claude Code）直接可用，不是空谈。
有问题的地方：
- 「loop」本身的定义边界模糊。Cron job + CI + 一些 agent 调用，这和 2015 年的 Jenkins pipeline 区别在哪里？文章没有认真回答这个问题，只是用新词包装了旧概念。
- 文章把「现在就能搭」作为 loop engineering 当下可行的论据，但实际上提到的 Automations 面板、
/loop命令、cloud routines 都还很早期，可靠性、成本、调试体验都没有经过大规模验证。用「两家产品都有对照部件」来论证「工具已追上」，逻辑跳步了。 - 「理解债」和「认知投降」这两个概念并不是 loop engineering 独有的问题，用任何代码生成工具都有这个风险。把它们列为 loop 的「三盆冷水」有夸大特殊性之嫌。
- 文章没有讨论 loop 失控的工程风险：一个出错的 loop 可以在你睡觉时持续提交错误 PR、烧光 token 配额、甚至误操作外部系统（通过 connector）。「验证仍然归你」一笔带过了这个问题的严重性。