Loop Engineering 循环工程：别再 Prompt Agent 了，去设计让 Agent 自己跑的循环

2026 年 6 月，OpenClaw 创始人 Peter Steinberger 发了一条浏览量超 800 万的推文：

❝"You shouldn't be prompting coding agents anymore. You should be 「designing loops」 that prompt your agents." （别再给编程 Agent 写提示词了，去设计能提示你的 Agent 的循环。） ❞

紧接着，Claude Code 之父 Boris Cherny 在回顾 CC 一周年时说，他现在的工作已经不是写代码、也不是调 Agent，而是——「"写 Loop"」。Google 工程师 Addy Osmani 随后把这套打法系统化为 「Loop Engineering（循环工程）」。

这篇文章想把三件事讲透：① Loop Engineering 到底解决什么问题、和你已经熟悉的 Prompt/Context/Harness 是什么关系；② 一个 Loop 落地需要的「五块积木 + 一个记忆」；③ 把它和 「DeepAgents、ReAct」 摆在一起，看清这条"从内到外层层包裹"的演进链。文末附一个「最小可运行的 Loop 示例」。图文并茂，建议收藏。

一、从 Prompt 到 Loop：我们到底在往哪走

过去两年，我们用 AI 编程助手的方式，本质都是"一问一答"：你写一条 prompt，它给一段结果，你看一眼、再写下一条。「人始终站在循环里」，是那个一轮一轮发指令的操作员。

Loop Engineering 的主张很激进：「把人从"循环里的操作员"挪到"循环外的设计者"。」 你不再逐轮 prompt，而是设计一个系统——它自己发现该做什么、分发执行、检查结果、记住进度、决定下一步，然后定时再跑。

放到 Agent 工程的演进脉络里，它是最新的一层抽象跃迁：

Addy Osmani 给了一句最精准的定位：

❝「"Loop Engineering sits one floor above the harness. The harness runs on a timer, it spawns little helpers, and it feeds itself."」（循环工程坐在 harness 上面一层。harness 靠定时器跑起来、派生小助手、自我喂料。） ❞

记住这个"上面一层"——它是理解后面所有内容的钥匙。

二、Loop 的解剖：五块积木 + 一个记忆

Addy Osmani 把一个能跑起来的 Loop 拆成 「5 块结构性积木 + 1 个外部记忆」。好消息是：到 2026 年中，这六块「已经内置进 Claude Code 和 Codex」，命名略有差异、能力相同，你基本不用从零造。

心智模型是这样的：「五块积木负责"循环怎么跑起来、跑得稳"，第六块记忆负责"跑得久、能接力"。」

积木 ① Automations —— 循环的"心跳"

按计划自动触发循环，并完成「任务发现 + triage（分类）」：有发现的进收件箱，没发现的自动归档。这是让"一次性运行"变成"真正循环"的关键。

• 「Claude Code」：/loop 把节奏转成 cron 定时；hooks 在 Agent 生命周期节点触发 shell；可挂到 GitHub Actions 持续跑。
• 「Codex」：Automations 标签页配"项目 + 提示词 + 触发频率 + 本地检出 / 后台 worktree"。

❝⚠️ 这是「头号烧钱点」：调度循环 + 每轮验证模型，token 消耗很快。务必「从慢节奏、紧目标起步」，观察几天成本再放量。 ❞

积木 ② Worktrees —— 并行而不互相覆盖

让并行的多个 Agent 「不会互相覆盖文件」。git worktree = 独立工作目录 + 独立分支，但共享同一仓库历史。Codex 内置支持；Claude Code 用 git worktree / --worktree / 子 Agent 的 isolation: worktree，每个助手拿到一个用完自动清理的检出。

❝💡 关键限制——「"你仍是天花板"」：worktree 只解决机械冲突，解决不了「审查瓶颈」。你能 review + 合并多少，才决定能并行跑多少 Agent。 ❞

积木 ③ Skills —— 不再每次重新解释你的项目

把项目知识（约定、构建步骤、目录结构）写进一个含 SKILL.md 的文件夹，避免每次会话都让 Agent 重新猜。Codex 用 $ / /skills 调用，也会在任务「匹配描述时自动触发」——所以「朴素精确的描述胜过花哨描述」。没有 Skill，循环每轮从零推导；有了 Skill，知识在每次运行间「复利累积」。

积木 ④ Plugins & Connectors —— 接入真实工具

基于 「MCP（模型上下文协议）」，让 Agent 读问题追踪器、查数据库、调 staging API、发 Slack。这是"提出修复建议"的 Agent，与"自动开 PR、关联工单、CI 过了通知频道"的循环之间的「分水岭」。Codex 与 Claude Code 都支持 MCP，连接器通常能跨工具复用。

积木 ⑤ Sub-Agents —— 分离"创造者"与"检查者"

把**写代码的 Agent（maker）「和」检查代码的 Agent（verifier）**分开——maker 对自己的产出太宽容，需要一个指令不同、甚至模型不同的第二 Agent 把关。

• 「Codex」：.codex/agents/ 下的 TOML（名称 / 描述 / 指令 / 可选模型与推理强度）。
• 「Claude Code」：.claude/agents/ 子 Agent + Agent 团队互相传递工作。

❝这正是 /goal 底层做的事：「用一个全新模型判断循环是否完成」，而不是让干活的模型自评。 ❞

第六块 Memory —— 循环的"脊柱"

模型在两次运行间会忘光一切，上下文窗口也装不下长期状态。所以记忆必须「落盘」，而非塞进上下文。核心原则一句话：

❝「"Agent 会遗忘，仓库不会。"」 ❞

Memory 保存的是「变化的状态」（已试过什么、什么通过了、还剩什么待办），载体可以是 markdown 文件、GitHub issue 列表、Linear 看板。第二天的运行读取它，从昨天停下处接力。

三个最容易混的机制，一张表分清：

三、把 Loop / DeepAgents / ReAct 摆在一起

很多人会问：这跟我熟悉的 「DeepAgents、ReAct」 是不是一回事？答案是——它们恰好构成一条「从内到外、层层包裹」的链，谁都没取代谁。

先各用一句话定位：

• 「ReAct」：最基础的「推理-行动循环」。Simon Willison 的定义就是它的精髓——"An LLM agent is something that runs tools in a loop to achieve a goal." 形态是 Thought → Action → Observation → … 直到收敛。
• 「DeepAgents」：LangChain 在 LangGraph 之上的 「harness」，用四根支柱——「Planning、Sub-agents、虚拟 File System、详尽 System Prompt」——把"朴素 ReAct 在复杂多步任务上太脆弱"补强。它官方原话是"「same core tool-calling loop」, but with planning, filesystem, sub-agents"——「内核仍是 ReAct」。
• 「Loop Engineering」：不是框架，是「范式」。它"坐在 harness 上面一层"，让 harness 定时跑、自我喂料、跨天接力。

一张表把三者拉开：

它们如何嵌套，才是最准确的理解——一套「俄罗斯套娃」：

❝「Loop Engineering（外循环）」 每次心跳发现一个任务 → 拉起一个 「DeepAgent（harness / 内循环）」 作为 worker → DeepAgent 内部跑 「ReAct（最内核）」 的 Thought→Act→Obs 把任务做完 → verifier / /goal 把关 → 写回 「Memory」 → 等下一次心跳。 ❞

一句话收束：「ReAct 决定"一步怎么想怎么做"；DeepAgents 决定"一个复杂任务怎么做完做稳"；Loop Engineering 决定"很多任务怎么自动地、跨时间地一直做下去"。」

❝另一个等价视角（philschmid）：DeepAgents 主攻 「inner loop」——Agent 在「一个任务内」自我验证、迭代；Loop Engineering 主攻 「outer loop」——Agent 靠持久化 memory / skills / rules 把经验「带到下一个任务」。 ❞

四、一个最小可运行的 Loop

光说概念太虚，我们写一个「真能跑」的最小外循环。任务很具体也可验证：「自动确保 notes/ 下每个 .md 笔记都带合规 front-matter（title / tags / updated 三个字段）」。它是一个安全的 「closed loop」——目标明确、能收敛、带轮次与重试上限防烧钱。

主控循环长这样（伪代码，六大组件都标了出来）：

def main():
    state = load_state()                    # ⑤ 记忆：从磁盘恢复，断点续跑

    for cycle in range(MAX_CYCLES):         # ⑥ 调度：心跳（sleep 模拟 cron）
        tasks = discover(notes_dir, state)  # ① 发现：扫描 + triage 出待办
        ifnot tasks:
            print("✅ 循环已收敛"); return   # closed loop 正常退出

        for path in tasks:                  # ② 分发（生产中可为每任务开 worktree 并行）
            rec = state[path]
            if rec["attempts"] >= MAX_ATTEMPTS:
                continue                     # 成本护栏：失败任务不无限重试
            rec["attempts"] += 1
            execute(path)                    # ③ 执行：maker（LLM 或 mock 兜底）
            ok, err = verify(path)           # ④ 验证：独立 verifier 重新读盘把关
            rec["status"] = "done"if ok else"failed"
            save_state(state)                # ⑤ 每步落盘，崩溃可续

        time.sleep(INTERVAL)                 # ⑥ 心跳间隔

关键设计点：

• 「③ 执行」和「④ 验证」是「两个独立环节」：maker 写完 front-matter 后，verifier 「重新从磁盘读取」再检查，「不信任」 maker 的自我汇报——这正是 Sub-Agents"创造者 / 检查者分离"的最小体现。
• 「⑤ 记忆」是 state.json：哪个文件 done、试了几次、上次报什么错，全落盘。删掉某个笔记的头部再跑，循环只会处理"重新变得不合规"的那个文件——这就是"Agent 会遗忘，仓库不会"。
• 「⑥ 调度 + 成本护栏」：MAX_CYCLES（最大心跳）+ MAX_ATTEMPTS（单任务最大尝试）共同防止 open loop 失控烧钱。

实测两条路径都正常：mock 模式下补全两篇笔记、跳过已合规的那篇，第 2 轮"发现 0 待办"自动收敛；切到真实 LLM 时即便 API 报错，也能看到「异常被记账 → 按上限重试 → 放弃 → 安全收敛」，护栏生效。

❝把这个例子里的 execute()（现在是简单 LLM/mock）「换成一个 DeepAgents / Claude Code 这样的 harness」，你就得到了第三节那条三层套娃：外循环调度 harness 作为 worker，harness 内部跑 ReAct。 ❞

五、什么时候该上 Loop，什么时候别碰

Loop Engineering 很性感，但不是银弹。给三条朴素建议：

1. 「先有靠谱的 harness，再谈 Loop。」 外循环调起来的执行单元如果本身就脆弱（单任务都跑不稳），那 Loop 只会让你「更快、更贵地」翻车。顺序是 Prompt → Context → Harness →（最后才）Loop。
2. 「优先 closed loop，慎用 open loop。」 边界明确、有可验证停止条件（如"CI 全绿"）的闭环，成本与风险可控；目标开放、没有明确终点的开环，最容易变成"无限烧 token 的永动机"。从慢节奏、紧目标起步。
3. 「守住"审查"这道关。」 自动化能放大产出，但「你能 review + 合并多少，才是真正的产能天花板」。别让循环跑得比你能审的还快——否则就是把技术债自动化生产出来。

六、结语

从 Prompt 到 Loop，变的不只是一个 buzzword，而是「人在系统里的位置」：

❝你不再是那个一轮轮敲 prompt 的操作员，而是「设计循环的人」和「守住合并的人」。 ❞

把这篇的脉络在脑子里过一遍就够了：

❝「Loop（外循环）定时唤醒 → 发现任务 → 分发到隔离环境 → DeepAgent（harness）执行 → ReAct 跑工具循环 → 独立 verifier 把关 → 写回 Memory → 下一次心跳接力。」 ❞

Boris Cherny 删掉 IDE、只写 Loop，未必是每个人都该立刻照搬的姿势。但他指向的方向很清楚：当"做好一次"已经被工具解决，「真正的杠杆，在于怎么让它自动地、跨时间地做很多次。」 这就是 Loop Engineering 想回答的问题。

延伸阅读

• Addy Osmani《Loop Engineering》：https://addyosmani.com/blog/loop-engineering/
• Phil Schmid《Agents: Inner Loop vs Outer Loop》：https://www.philschmid.de/inner-loop-vs-outer-loop
• LangChain Deep Agents 文档：https://docs.langchain.com/oss/python/deepagents/overview