理解 Loop Engineering：写代码从手动挡到全自动

过去我们和 coding agent 的工作方式是你写一个 prompt读返回的结果再写下一个 prompt。你全程面对着这个工具一轮接一轮。现在一些走在前沿的工程师开始做一件不同的事他们不再一个个地 prompt agent而是设计一套系统让这套系统自己去驱动 agent 运行。这个转变有一个精确的描述从human in the loop变成human on the loop。你不再是循环里那个亲手转动齿轮的人而是站在循环之上设计循环、观察循环、在必要时介入。这就是 Loop Engineering。从 Ralph 到 /goalLoop 是怎么来的最早接触到 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回合制你发一个 promptagent 判断完成就停下。这就是最基础的交互模式每次对话本身就是一个小循环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 filepatterns 写进 AGENTS.md下一轮的 agent 比上一轮更懂你的项目。Ralph 就是例子progress.txt 和 prd.json 做了大部分工作bash 循环只负责把它们串起来跑。所以真正的门槛是两件事Harness 的质量CLAUDE.md / AGENTS.md 写得够不够好hooks 拦没拦住该拦的操作skills 有没有沉淀项目知识不到位loop 就是在自动化你的问题。目标的清晰度完成条件是测试全过且 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。从最简单的地方开始找到你工作中你自己是瓶颈的那个环节也许是每天早上检查 CI 状态也许是反复跑同一组测试问自己三个问题验证步骤能写成 skill 吗目标够清晰吗这个工作是不是按固定节奏来的从 Goal-based 开始先把验证环节交出去再考虑交出触发时机说实话大多数人都高估了 loop 机制本身有多重要低估了 harness 和 context。同样的 loop接入不同质量的 skills 和文档产出天差地别。与其花时间把 loop 搞得更花哨不如花时间把 AGENTS.md 和 skills 写好这些东西在每一轮 loop 里都在复利。Boris Cherny 那句我的工作是编写循环重点不是循环是工作变了。杠杆点迁移了改进一个 prompt 只作用于一次对话改进一个循环的效果复利到所有后续运行。设计你的 loop。但要像一个打算继续当工程师的人那样设计它。如果你觉得这篇文章对你有帮助欢迎点赞、分享你的支持是我持续创作的最大动力