从写 Prompt 到写 Loop

最近翻硅谷工程师的讨论，有个变化挺明显：以前大家比谁的提示词写得漂亮，现在开始比谁的循环设计得好。

OpenClaw 的创始人 Peter Steinberger 在六月初发了条帖子，被看了八百多万次。他说，别再忙着主动提示你的 coding agent 了，你该做的是设计循环，让循环去提示 agent。他的原话是 “you should be designing loops that prompts your agents”。Claude Code 的负责人之一 Boris Cherny 在一次访谈里说得更直接：我的工作就是写 loop。灵姐说 AI 的这期视频（原视频）把这股风潮和 Addy Osmani 的 Loop Engineering 框架串了一遍。我看完做了点延伸：有些点我们一年前就在踩坑，有些点视频讲得比我系统。

这篇就顺着「杠杆后移」这条线往下讲：Loop 到底是什么、它和我们已经熟的 Harness 是什么关系、真要上生产还差哪几块。

先分清两层：Agent Loop 和 Loop Engineering

Loop 这个词最近被用得有点混，其实它指的是两层东西。

一层是 Agent Loop，这是底层机制。任何一个 agent 干活，底层都是同一个闭环：设定目标 → 规划步骤 → 执行 → 观察结果 → 反思改进 → 回到目标继续。大部分人卡在「执行完输出结果」这一步就停了，这不是闭环。真正的闭环要对执行的过程和结果都做一次观察，看哪里值得改，再带着改进转下一圈。

另一层是 Loop Engineering，是把这个机制产品化、工程化。其实就是：你不再亲手转动这个循环，而是设计一套系统，让它自己定时醒来、自己执行、自己检查、自己纠偏。Agent Loop 是发动机，Loop Engineering 是你给发动机配的整套控制系统。

灵姐讲过一种很具体的玩法：让 Codex 去执行，再让另一个 AI（Claude Code 或 GPT）去观察反思。这相当于给执行者配了个第三方评审，逼它一圈圈往前迭代。这个分工很关键，后面会专门讲。

杠杆后移：从 Prompt 一路退到 Loop

要理解「为什么高手开始写 loop」，得看这个杠杆是怎么一步步往后退的。

• Prompt Engineering：杠杆在你的表达上。你琢磨怎么把一句话问好，让模型对单次输入理解得更准。
• Workflow / Context Engineering：杠杆在任务流和上下文上。你用确定性的逻辑链条、更完整的项目背景，提升模型对整个任务的理解和完成率。
• Harness Engineering：杠杆在运行环境上。你给 agent 搭执行环境、配工具、给权限框架和可验证的信号。Claude Code 和 Codex 在这一层都做得不错，精准执行的能力很强。
• Loop Engineering：杠杆在循环本身上。你设计一个能自我演进的闭环，让系统替你去提示、检查、纠偏。

这是我想强调的第一个点：Loop 不是凭空冒出来的第四个名词，它是这条线退到底的那一格。 在我自己的知识库里，前三层早就归并成了一个「驾驭工程（Harness Engineering）」的同心圆：Prompt 在最内圈，Context 包着它，Harness 包着前两层，再加上工具编排、状态持久化、错误恢复、验证循环。Loop 做的事，是把这个同心圆里最外圈的「验证 + 编排」那部分，在单个任务的维度上焊成一个会自己转的环。

打个比方你会更有体感。Karpathy 有个说法：模型是 CPU，上下文窗口是 RAM，你是操作系统，决定每个任务往内存里加载什么。Prompt 是你手敲一条指令，Harness 是你写好了操作系统，而 Loop 是你给操作系统挂上了 cron——它不再等你敲，自己到点就跑。

Addy 的五个模块加一层记忆

Addy Osmani 是长期负责 Google Chrome 开发者体验、现在聚焦 Google Cloud AI 与 agent 生态的工程领导者。他那篇 Loop Engineering 把一个长期运行的 agent 系统拆成了五个模块加一层记忆，每个模块都对应一个「长跑 agent 必须解决的问题」。有意思的是，Claude Code 和 Codex 早就都有这些组件，只是叫法不同。

挨个说一下，顺带讲讲我自己的对照。

Automation（自动化）：谁来启动循环。 这是整个 loop 的心跳。Codex 里是它的心跳机制，Claude Code 里是定时任务运行符。它解决的问题很朴素：没有它，loop 就只是被手工跑了一次，人还得不停去戳。有了它，循环能在固定频率或特定条件下自己醒来。

Worktree（隔离仓）：并行不打架。 多个 agent 同时干活会不会互相踩？Worktree 共享同一份 Git 历史，但每个有独立的文件副本，让并行不变成混乱。

这块我得泼点冷水。视频里「并行不打架」是理想态，我们实战下来发现没这么省心。真正的规则是：只在执行阶段并发，merge 阶段必须串行。盲目开 N 个 agent 全程并发，只是把串行的合并痛苦后置，最后变成 merge 地狱。而且 worktree 隔离不是 100% 可靠，agent 有时会没进 worktree 就直接改了主仓库，你得每个并发任务起来后立刻 git status 主仓库做验证。决定能不能并发的，从来不是 agent 数量，而是这些任务有没有碰同一个文件：碰了共享数据结构的，必须串行。这是我会写进 prompt 当硬约束的东西，视频点到为止，落地时坑都在细节里。

Skill（技能）：让经验可复用。 Skill 解决的是「agent 每次不必从零理解项目」。它是封装好的、沉淀下来的工作流。这里要分清楚：Skill 本身是经验，Loop 是让经验循环跑起来的系统，一个是弹药，一个是枪。我自己的习惯是，一件事手动做上三到十次、确认稳定了，就把它编纂成 skill，再挂上自动化。好处是它永不退化，下次模型升级还能自动跟着变好。

Connector（连接器）：让 agent 长出手脚。 这里面是 MCP、插件、API 接口。很多人说 Codex 能剪视频，其实 Codex 本身不会剪，它是通过接入外部工具，把别人的能力变成自己的手脚。收发邮件、剪辑视频、生成音乐，这些能力 agent 本来都没有，是连接器一个个接上去的。

Sub-agent（子代理）：执行者和审查者分开。 Addy 在这块花的笔墨最多，原话是 “sub agents keep the maker away from the checker”。一个 agent 负责探索和编排代码，另一个负责对照规范做验证，两个角色、两个目标，分开循环。

这是我最认同的一块，也是我反复讲的玩法。很多人做任务只管创建，不做检查；或者就算检查了，也是同一个 agent 既当运动员又当裁判。Addy 说得很到位：执行本身值得花 token，审查本身也值得花 token，这两件事都重要。我把它总结成一条更硬的规则：别信 worker 的自我汇报，只信验证者。coding agent 是出了名的自信：build 没跑也会说 passed，测试没执行也会说通过了。所以执行者和审查者一旦不分离，过拟合和自我欺骗几乎是必然的。这条规则，是 loop 从「承诺」变成「合约」的关键。

Memory（记忆）：让 loop 产生复利。 模型会忘掉自己做过什么，但你把它写进仓库，它就不会忘。所以要定期写入记忆、更新记忆、复盘升级。没有记忆，loop 每一圈都是全新的、从头开始的；有了记忆，所有经验沉淀、所有错误规避、所有动作留痕，这个 loop 才是会产生复利的 loop。靠的就是文件系统给 agent 的跨上下文窗口连续性：模型记忆易失，仓库记忆持久。

把 Loop 看成一个控制系统

五个模块加一层记忆拼到一起，闭环就出来了，它其实就是一个标准的控制系统：

定时启动 → 读取外部输入 → 调用 skill 理解任务 → 建立彼此隔离的 worktree → 一组 agent 执行 → 一个独立的子 agent 审查规范 → 工具验证（dry run / 冒烟测试）→ 开 PR 更新任务 → 失败就记录原因重试 → 把全过程写入 memory → 进入下一轮。

你会发现，这套东西里真正稀缺的不是「让 agent 多跑几轮」，而是每一轮之间那些卡点：验证、隔离、审查、记忆。多跑几轮谁都会，把这几个卡点焊死才是工程。

真要上生产，还得补四块护栏

Addy 的框架已经挺完整，但灵姐补了四块，结合我自己的实操，这四块我觉得恰恰是从「玩具 demo」到「敢上生产」之间最硬的门槛。

第一块，验收标准。 loop 什么时候该继续转，什么时候该停下来，必须有个明确的标准。这个标准最好在你启动目标、写 goal 的时候就写进去。没有它，loop 要么提前收工，要么停不下来空烧 token。

第二块，权限边界。 尤其在企业里，这些东西能不能改、能不能删、能不能访问特定网络、能不能自动调付费 API、能不能直接往 Slack 发消息、能不能直接合并，最小权限原则都要写死。为什么这么较真？因为当模型真跑在企业任务里，token 成本、任务失败率、权限风险都会变成真实的钱、真实的事故。

第三块，Human Review / Human Gate。 权限边界的另一面，是人什么时候该介入。哪些情况超出边界需要人来观察，哪些节点 loop 必须暂停、等人拍板。权限边界和人工闸门，是同一件事的两面。

第四块，可观测性。 不只要结果可观察，整个 loop 的过程也得可观察：任务怎么拆的、每一步执行了什么动作，都要留痕。只有过程留痕，闭环执行时才有对比和审核的依据，才谈得上一圈圈提升。这一点和我一直信的判断对上了：当 SDLC 被 agent 压缩成「意图 → 构建 → 观察」的紧循环之后，唯一幸存下来的阶段就是可观测性。遥测数据应该闭环喂回 agent 当它的修复上下文，而不是只进人类的告警箱。

我会让读者记住的一句话

杠杆从 Prompt 退到 Loop，一共退了四格。每退一格，人就从流水线上往后撤一步：不再手搓每一句话，不再盯每一步执行。但有一样东西，无论退到哪一格都得始终攥在手里——验证。

盲目自动化和 Loop Engineering 的区别，不在于自动化的程度，而在于有没有把验证焊进每一轮。前者是让 agent 自己跑得更欢，后者是让 agent 每跑一圈都被一个独立的、可观察的检查卡一道。说到底，杠杆后移的本质，是验证位置的后移：从「做完之后人来抽查」，变成「系统里每一轮都自动发生」。

所以下次你想给 agent 写一段更长更漂亮的 prompt 之前，不妨先问自己一句：这件事，我能不能把它设计成一个会自己转、并且每一圈都能被检查的循环？能，它就是个生产系统；不能，它还只是一次性的对话。