过去我们和 coding agent 的工作方式是：你写一个 prompt，读返回的结果，再写下一个 prompt。你全程面对着这个工具，一轮接一轮。

现在，一些走在前沿的工程师开始做一件不同的事：他们不再一个个地 prompt agent，而是设计一套系统，让这套系统自己去驱动 agent 运行。

这个转变有一个精确的描述：从human in the loop变成human on the loop。你不再是循环里那个亲手转动齿轮的人，而是站在循环之上，设计循环、观察循环、在必要时介入。

这就是 Loop Engineering。

从 Ralph 到 /goal：Loop 是怎么来的

最早接触到 Loop 的概念，是今年 1 月份很火的一个 Claude Code 插件：Ralph。

它本质上是一个 bash 脚本驱动的循环，如图

理念很简单：开发功能 → 检查是否符合预期 → 继续开发 → 继续检查，直到全部完成。记忆不靠上下文窗口，靠 git commit 和文本文件。

1 月份还没有 Loop Engineering 这个词，但循环执行的理念已经成型了。

到了 5 月份，Codex 发布了/goal功能，你设定一个目标，Codex 会一直执行直到目标完成。很多用户发现它可以进行十几小时甚至好几天的超长任务。

6 月份，两条推文让这个理念推广得更深。OpenClaw 的作者 Peter Steinberger 发表推文：

别再手动 prompt coding agent 了，你应该设计一套循环机制，让这个循环自己去驱动 agent 运行

Claude Code 负责人 Boris Cherny 几乎同期发表了类似的看法：

我不再 prompt Claude 了。我正在运行一些循环，这些循环会 prompt Claude 并决定要做什么。我的工作是编写循环

至此，Loop Engineering 拉开帷幕。

四种 Loop 形态

很多人以为 Loop 就是"一个 while 循环跑到底"。但 Claude Code 团队在最近发布的 Getting started with loops 中，给出了一个更系统的分类。按触发方式、停止条件和适用场景，Loop 分为四种：

Turn-based Loop（回合制）

你发一个 prompt，agent 判断完成就停下。这就是最基础的交互模式，每次对话本身就是一个小循环，agent 在内部经历"读代码 → 改代码 → 跑测试 → 确认结果"的多轮迭代。

适合短任务、探索性工作。

Goal-based Loop（/goal）

你定义一个可验证的完成条件，agent 会一直迭代直到条件满足，或者达到你设定的尝试次数上限。

比如：

/goal 把首页的 Lighthouse 分数提到 90 以上，最多试 5 次

这里有一个关键设计：判断"是否完成"的不是做工作的那个 agent 自己，而是一个独立的 evaluator model。做作业的和判作业的分开，这一点至关重要，后面会展开。

Time-based Loop（/loop, /schedule）

按时间间隔重复执行同一个 prompt。比如每 5 分钟检查一下 PR 的 CI 状态，有失败就修：

/loop 5m 检查我的 PR，处理 review 意见，修复失败的 CI

/loop在本地运行，关机就停。/schedule把任务搬到云端，关掉电脑也能继续跑。

适合需要跟外部系统（CI、PR review、Slack）对接的周期性工作。

Proactive Loop（主动式）

最复杂也最强大的形态。结合/schedule、/goal、sub-agents 和 auto mode，构建一个完全无人值守的工作系统。

比如：每小时检查反馈渠道的 bug 报告，发现了就自动 triage、修复、review，全程不需要人参与。

适合有清晰定义、反复出现的工作流。

Verification：保证 Loop 产出能用

Loop 跑起来不难，难的是跑出来的东西能不能用。核心是验证。

Boris Cherny 在 Claude Code 的开发中观察到：给模型一种验证自己工作的方式，质量提升 2-3x。

为什么差这么多？因为模型有一个肉眼可见的 bias：它对自己的产出过度宽容。

Anthropic 的 Prithvi Rajasekaran 做过一个实验：让同一个 agent 既写代码又判断质量。结果是，它会发现问题，再说服自己这些问题不重要，最终给自己打"通过"。而且这稳定复现，self-evaluation 在系统层面就是不可靠的。

解法是maker-checker 分离：写代码的和检查代码的必须是两个独立实例。/goal就是这么设计的，完成条件交给独立的评估 agent ，不是做工作的 agent 自己打分。

但分离还不够，验证本身也分层：跑测试、跑 linter 是确定性的，没有歧义；让另一个 agent 做 code review 或用 Playwright 检查真实 UI，有用但有判断误差；最终人还得看。你能自动化的是验证的执行，不是验证的责任。

Loop 背后真正重要的事

很多人觉得 Loop Engineering 的重点是循环本身，怎么触发、怎么停、跑多久。但用下来越来越觉得：真正决定 loop 产出质量的是 harness。

Addy Osmani 说得精确：Loop engineering sits one floor above the harness。

Harness 是单个 agent 的运行环境，包括 system prompt、tools、hooks、sandbox、memory，决定单次运行的质量。Loop 只决定什么时候启动、什么时候停、怎么在多次运行间传状态。

精心设计的 loop 套上粗糙的 harness，跑再多轮也是在重复垃圾。但如果 harness 本身质量过关，loop 每跑一轮都在积累：learnings 写进 progress file，patterns 写进 AGENTS.md，下一轮的 agent 比上一轮更懂你的项目。

Ralph 就是例子：progress.txt 和 prd.json 做了大部分工作，bash 循环只负责把它们串起来跑。

所以真正的门槛是两件事：

1. Harness 的质量：CLAUDE.md / AGENTS.md 写得够不够好？hooks 拦没拦住该拦的操作？skills 有没有沉淀项目知识？不到位，loop 就是在自动化你的问题。
2. 目标的清晰度：完成条件是"测试全过且 lint 干净"，还是"把功能做好"？前者有明确终止信号，后者让 agent 自己定义"好"，它会定义出一个对自己最宽容的标准。

Loop 没那么美好的地方

说完好处，说说容易被忽略的代价。

Loop 越高效，你越不了解自己的项目。你没写的代码越多，你的理解和实际代码之间的 gap 就越大，Addy Osmani 管这个叫理解债务（comprehension debt）。

Loop 跑得越顺，你越信任它、越直接接受它的产出，最后连判断都省了，这就是认知投降（cognitive surrender）。

前者是你不再了解代码，后者是你不再动脑子

解决方案也很简单：每次 loop 跑完，把 commit 的 diff 过一遍，不改也要看。毕竟 agent 说"done"和这东西真能上线之间的那步，永远是你的责任。

同样是设计 loop，一个人带着判断力设计，系统放大的是他的判断力；另一个人为了省事设计，系统放大的是他的偷懒。

还有个边界：不是所有工作都需要 loop。探索性的、一次性的、需要大量人类判断的任务，好好写一个 prompt 往往比设计 loop 更有效。Loop 最适合模式清晰、反复出现、完成标准可验证的工作。如果你还在搞清楚"这件事该怎么做"，先把事想明白再说。

怎么开始

如果你想试 Loop Engineering，不用一上来就搭 Proactive Loop。从最简单的地方开始：

1. 找到你工作中你自己是瓶颈的那个环节，也许是每天早上检查 CI 状态，也许是反复跑同一组测试
2. 问自己三个问题：验证步骤能写成 skill 吗？目标够清晰吗？这个工作是不是按固定节奏来的？
3. 从 Goal-based 开始，先把验证环节交出去，再考虑交出触发时机

说实话，大多数人都高估了 loop 机制本身有多重要，低估了 harness 和 context。同样的 loop，接入不同质量的 skills 和文档，产出天差地别。与其花时间把 loop 搞得更花哨，不如花时间把 AGENTS.md 和 skills 写好，这些东西在每一轮 loop 里都在复利。

Boris Cherny 那句"我的工作是编写循环"，重点不是"循环"，是"工作变了"。杠杆点迁移了：改进一个 prompt 只作用于一次对话，改进一个循环的效果复利到所有后续运行。

设计你的 loop。但要像一个打算继续当工程师的人那样设计它。

如果你觉得这篇文章对你有帮助，欢迎点赞、分享，你的支持是我持续创作的最大动力！