Loop Engineering 是什么？
Loop Engineering 不是写更好的 prompt，是把"下指令的人"从自己换成一套你设计好的系统。
- Boris Cherny（Claude Code 负责人）："我已经不 prompt Claude 了，我的工作是写 loops"
- 从 ReAct 到 Ralph Loop 到 Claude Code /goal，底层逻辑是从"手工"到"工业"的范式迁移
- 六大构件：自动化触发、工作区隔离、技能沉淀、MCP 连接器、子代理分离、外部状态持久
- 关键前提：任务高度重复，验证可自 动化，团队有充足 Token 预算
- 适合 CI 故障排查、依赖更新等标准化流程；不适合架构重构等需要人类判断的决策
Loop 越顺畅，人越容易停止思考——验证偷懒和理解债比 token 账单更危险。
什么叫 Loop Engineering
最好的定义来自 Google Cloud AI 总监 Addy Osmani：
Loop engineering is replacing yourself as the person who prompts the agent. You design the system that does it instead.
以前是你给 Agent 写提示词，Agent 干完等你下一条指令；现在是你设计一套系统，让系统去给 Agent 下指令。
Claude Code 负责人 Boris Cherny 说得更直白：
"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."
这不是修辞。他在采访里描述了自己的实际工作流：同时开着 5 个 Claude Code 终端、5-10 个浏览器会话——他在设计循环，不是在写 prompt。
OpenAI Codex CLI 创始人 Peter Steinberger 也发了条推文："你不该再给编程 Agent 写提示词了。你该设计一套循环，让循环去提示 Agent。"底下有人回"但 token 很贵啊"，他回了一句："没错。可难道你的时间真不值钱吗？"
三个在 AI 编程工具上最有发言权的人，说了同一件事。
Prompt Engineering → Loop Engineering
过去三年，人跟 Agent 的交互方式经历了三次跃迁：
| 阶段 | 模式 | 人的角色 |
|---|---|---|
| 2023-2024 | Prompt Engineering | 逐条写指令，Agent 是执行者 |
| 2024-2025 | Agent 工具链 | 配置工具、权限、运行环境 |
| 2025-2026 | Loop Engineering | 设计循环系统，系统驱动 Agent |
说白了，Prompt Engineering 是"手工业"——每个任务都要人亲手把需求翻译成 prompt，Agent 干完等你下一条指令。人始终卡在流程里。
Loop Engineering 是"工业文明"——把流程抽象成循环系统，定义好触发条件、工作方式、验证标准，系统自己跑。人的位置从操作者变成设计者。
这不是"prompt 写得更好"，是把写 prompt 这件事本身给外包了。
一个 Loop 的结构与构件
一个 Loop 的运行结构可以拆成五步：
Loop ≠ cron。 cron 只负责定时触发，跑完固定脚本就结束；Loop 在 cron 之上多了一个决策体——每轮都要读状态、判断该不该继续、决定下一步做什么。所以 Loop = cron + decision maker。
Osmani 把 Loop 拆成了六个部分：
- 自动化机制（Automations）——心跳触发器。定时运行，自动发现和分类任务。比如每天早上扫 CI 日志、读 issue 列表、检查依赖更新。
- 工作区隔离（Worktrees）——多个 Agent 并行工作时互不踩脚。每个 Agent 在自己的 git worktree 里操作。
- 技能文件（Skills）——把项目知识和开发规范沉淀为文件。Agent 启动时加载，不需要每次重新解释"我们的规范是什么"。CLAUDE.md 就是最典型的 skill 文件。
- 连接器（Plugins/Connectors）——通过 MCP 协议让 Agent 接入 GitHub、Slack、Linear、数据库等真实工具。
- 子代理（Sub-agents）——生成者和评估者分离。"自己给自己的作业打分"是最不可靠的验证方式。Anthropic 内部的最新实践是生成器-评估器-规划器三件套，评估器用独立的上下文窗口，不看生成器的推理过程。
- 状态/记忆（State/Memory）——持久化任务进度。用外部存储记录"做了什么、下一步是什么"，保证跨会话不重来。
这六个里，状态记忆是最被低估的一个。Agent 掉线、上下文溢出、会话结束——这些不是意外，是常态。没有外部状态，每次重启都是从零开始。Cherny 的做法是把每个错误和修正都写进 CLAUDE.md："Every mistake an agent makes, the correction goes into CLAUDE.md. Future sessions do not repeat it."
技术演进：从 ReAct 到工业级 Loop
Loop Engineering 不是凭空冒出来的，有一条清晰的技术线：
- ReAct（2022，Google/Princeton ）：Thought → Action → Observation 循环，奠定了 Agent 自主工作的基础模式。
- AutoGPT（2023）：第一个把"目标分解→子任务执行→反思→循环"产品化的项目，100K GitHub stars，也因为无限循环和恐怖 token 账单出了名。
- Ralph Loop（2025.7，Geoffrey Huntley）：极简 shell 循环——每轮从磁盘读 prompt 文件，Agent 改完代码退出，重启再来。状态全在文件系统里：代码、TODO 文件、git 历史。解决了上下文溢出和模型提前"摆烂"两个核心痛点。
- Claude Code /goal（2026.5）：产品化 Loop。
/goal命令让用户描述目标，Agent 自己分解、执行、验证、循环，直到完成或触发终止条件。
从手工 prompt 到系统化 loop，这条线走了四年。
什么时候用，什么时候别用
AlphaSignal 提了四个硬前提：
- 任务高度重复
- 验证机制已自动化
- 团队有 Token 预算
- Agent 有完整工具权限
缺一个就别上 Loop——你会花更多时间调试一个"跑了 47 轮的状态机"，不如自己动手。
适合： CI 故障排查、依赖更新、lint 修复、Issue → PR 标准化流程。这些活输入输出格式稳定，对错可自动判断，人类判断权重低。
不适合： 架构重构、产品设计、需要大量上下文权衡的复杂决策、目标模糊无法客观验收的探索、开了几百个 Agent 就当交付的 multi-agent 幻想。这些活"正确答案"不唯一，需要经验和直觉。
设计你的 Loop
写 Loop 不是写死板脚本。核心是给循环装上六个"保险丝"：
- 硬迭代上限——最多跑 N 轮，超了就停
- Token/成本预算——烧到上限自动终止
- 无进展检测——连续 N 轮输出没变化，退出
- 熔断器——工具连续失败 N 次，报错交给人类
- 终止标准——可自动验证的完成条件，不是 Agent 自己说"我好了"
- 独立验证——verify 才是 Loop 的可信部分，plumbing 只是水管。跑测试、读结果、独立校验是循环能跑下去的根基；怎么 verify 只有你自己的业务才能写。
- 人类检查点——不可逆操作（merge、deploy、删数据）前必须等人确认
种子 prompt 比想象中更重要。Loop 跑的是你第一条 prompt 规格出来的方向——第一轮歪一点，后面 N 轮就在自信地朝错误方向反复猜测，烧掉的是你看不见的几千几万 token。
需求描述、停机条件、测试用例必须人写人审、对齐后再启动。
种子规格、停机条件、测试用例一旦模糊，loop 不会停下来问你——它会自信地朝错误方向反复猜测，把 token 烧干净再交一份看起来"完成"的报告给你。
并行的天花板在带宽，不在工具。orchestrator 能拉起多少个并行 Agent 不重要——真正能跑多少个 Loop 由你的 review 带宽决定。Agent 写得再快，最后还得有人读、有人 review、有人 merge。loop 数超过你能 review 的 throughput，剩余的 agent 就只是"开着的进程"，不是交付。
Loop 不是 set-and-forget。 区别在于：脚本跑了你不需要看，Loop 跑了你必须看——只是不用每步都看。
真正危险的不是 token 账单
Loop 跑起来以后，三个更隐蔽的问题会慢慢浮现：
验证偷懒。 Loop 能自己跑了，人就容易"跑完了？那应该没问题吧"。但 Agent 的"完成"只是一个声明，不是证明。它完全可能在最后一轮跳过了测试步骤然后告诉你"全过了"。
理解债。 Agent 写得越多，你读得越少。三个月后出 bug，你连这段代码是哪个 Loop 写的都不知道。Cherny 通过 CLAUDE.md 做知识沉淀来解决——但前提是你得写，而且得持续写。
认知投降。 这是 Osmani 最担心的：
"When the loop runs itself it's very tempting to stop having an opinion and just take whatever it gives back."
Loop 越顺畅，人越容易放弃判断。工程师的核心能力不是写代码，是判断什么是对的。Loop 把这个判断权从你手里拿走了——不是它抢走的，是你自己交出去的。
真正复利的是 skill，不是 loop 本身。Loop 只是水管——把规格、验证、产出串起来。长期价值不在循环本身，而在循环里沉淀下来的能力：业务怎么理解、怎么验证、怎么测试。把每轮的修正都写入 skill 文件（CLAUDE.md 之类），loop 才有复利。
两种 loop 用户的结局。 A 模式：人在自己理解的代码上跑得更快，loop 是放大器；B 模式：人开始回避理解，只收结果，loop 是逃避工具。小项目 B 或许还能赌，大项目关键行不通——区别不在 loop，在人。
Osmani 最后的建议值得刻在屏幕上：
"Build the loop. But build it like someone who intends to stay the engineer, not just the person who presses go."
References
- Loop Engineering —— Addy Osmani, 2026
- Agentic Loops: From ReAct to Loop Engineering —— Data Science Dojo, 2026
- awesome-loop-engineering —— GitHub
- 02. Loop Engineering 什么是 Loop 以及如何写好一个 —— AI_Julie, 哔哩哔哩