Loop Engineering：让 AI Agent 自己跑起来的工程方法

前言

2026年6月的同一周，三个人各自说了一段话：

You shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents.

ai.gopubby.com/you-shouldn...

------ Peter Steinberger，OpenClaw（那条推文最终被浏览了800万次）
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.

x.com/sairahul1/s...

------ Boris Cherny，Anthropic Claude Code 负责人
Loop engineering is replacing yourself as the person who prompts the agent. You design the system that does it instead.

addyosmani.com/blog/loop-e...

------ Addy Osmani，Google Chrome

Loop Engineering 不是什么新工具，而是一种新的思维模式： 你的工作不再是引导人工智能，而是设计能够代表你引导人工智能的系统。

一、Loop Engineering 是什么？

1.1 从 Prompt 到 Loop：四层演进

过去两年，AI编程的工程化经历了四个台阶。

层级	方法	你做什么
Prompt Engineering	写好一条指令	你亲手写每一条 Prompt
Context Engineering	管好上下文窗口	你精心组织上下文，让 Agent 理解更准
Harness Engineering	给 Agent 套上缰绳	你配置规则、工具、权限，约束 Agent 行为
Loop Engineering	设计循环让 Agent 自运行	你设计系统，系统替你发 Prompt

你不再亲自 Prompt Agent，而是设计一个 Loop 来 Prompt Agent。

这里需要做一个区分：Loop Engineering不是智能体工作流。智能体工作流把多步调用串起来，步骤是你提前定好的，模型只负责在每步里填空。路径已知，模型执行。

Loop Engineering更进一步------你不再定义路径，你定义循环和验收标准。Agent自己决定每轮干什么、怎么干、干完谁来验。路径未知，系统探索。

Loop Engineering 在 2026 年 6 月被正式命名。2025 年夏天，工程师 Geoffrey Huntley 摸到了一个模式，他叫它 Ralph Loop------把编码 Agent 扔进一个无限 shell 循环：

while true; do  cat prompt.md | claudedone

每一轮读同一个 prompt 文件，改代码，然后清空上下文重来。下一轮拿到的是干净的上下文窗口，没有对话历史，只有上一轮留在文件系统里的状态。不聪明，但管用。

2026 年 4-5 月，工具层追上来了------Codex CLI 发了 /goal，Claude Code 紧随其后，用一个独立的小模型在每轮结束后检查完成状态。

6 月 9 日，Addy Osmani 发了系统化长文，把 Loop Engineering 拆成五个核心组件。每一层不是替代上一层，是在上面叠加------烂 Prompt 给你一个烂 Loop，烂得更快。用 Addy 的话说：Loop engineering sits one floor above the harness.

Harness 约束 Agent 怎么干活，Loop 决定 Agent 什么时候干、干完之后谁来接手、接完之后谁来验收。Harness 是单次执行的缰绳，Loop 是持续运转的流水线。

还有一点容易被忽略：Loop Engineering 不再是工具问题。 一年前你要写一堆 bash 脚本才能搭起一个循环，现在这些组件已经内置在产品中。

1.2 Loop能解决什么问题，不能解决什么问题

Loop Engineering听起来很强大，但不是所有任务都该用它。动手之前，拿候选任务过三个检查。

• 重复性。 你经常做这件事，设计系统的成本能收回来。偶尔一次的事，手动Prompt更划算。
• 可复核。 "完成"能表达成一条机器可以执行的检查。如果你定义不了"通过"长什么样，Loop就不知道什么时候该停。
• 有价值。 产出值得花Token。Loop有时间和金钱的底价，琐碎工作覆盖不了这个成本。

三条都满足，适合做Loop。

"可复核"这条值得展开：

Loop的质量完全由停止条件决定------/goal需要一个不需要人就能判断"完没完"的裁判。如果判断需要人，Loop就跑不了自主；如果判断能交给机器，Loop就能在你睡觉的时候跑。

所以搭Loop之前先回答一个问题：机器能不能独立判断这个产出对不对？能，搭高自主性Loop；不能，Loop仍然有用，但你需要参与定义停止条件。

ReAct 是一种提示范式，它解决的是"怎么让模型转起来"；Loop Engineering 是一种工程实践，它解决的是"怎么让这个循环在真实系统里跑得住"。

二、Loop Engineering 怎么做？

2.1 一个 Loop 的五步动作

(1). Discovery（发现）

Loop 被触发。触发源可以是 CI 信号、新的 Issue、一次 Commit，也可以是定时调度。Loop 启动后，Agent 开始感知当前状态------有哪些 open issue、哪些 CI 失败、哪些 commit 进来了。

(2). Skill（执行）

Agent 不需要你粘贴一大段指令。你预先定义好 Skill（一个可复用的 Prompt 模板），Agent 通过 $skill-name 直接调用。Addy 的原话：

You fire $skill-name instead of pasting a giant wall of instructions into a schedule that nobody will ever update.

(3). Handoff（交接）

Agent 在独立的 Worktree 中工作，完成后把结果交给下一个 Agent。两个 Agent 写同一个文件，和两个工程师改同一行代码一样痛苦------Worktree 是隔离并行的基础设施。

(4). Verification（验证）

这是 Loop 的核心。 生成代码的 Agent 不应该自己验证自己的代码。用一个独立的 Evaluator Agent 来验收------不同的指令、有时甚至用不同的模型。Addy 说：

The model that wrote the code is way too nice grading its own homework.

(5). Persistence（持久化）

Loop 的产出需要落盘------PR、Ticket、Markdown 文档。Agent 的记忆不能只存在于上下文中，必须写入磁盘。Addy 的原则：

The agent forgets, the repo doesn't. The memory has to be on disk and not in the context.

五步流转的完整画面：

触发源(CI/Issue/Commit)
    → Discovery: Agent 感知状态
    → Skill: Agent 调用 $skill-name 执行
    → Handoff: Worktree 隔离，Agent 交接
    → Verification: Evaluator Agent 独立验收
    → Persistence: 结果落盘(PR/Ticket/Markdown)
    → Automation: 回到触发源，循环继续

2.2 构建 Loop 的六大组件

一个生产级 Loop 由六个部分组成：

(1) Automations------让 Loop 真正成为 Loop

没有 Automation 的 Loop 只是"你跑了一次的东西"。Automation 让 Loop 自动触发、自动循环。它可以是 cron 定时、CI 事件驱动、Issue 变更触发。

(2) Worktrees------Agent 的隔离工作区

Git Worktree 让每个 Agent 在独立分支上工作，互不干扰。没有隔离，两个 Agent 写同一个文件就是灾难。

(3) Skills------可复用的 Prompt 模板

Skill 把复杂的 Prompt 封装成 $skill-name，Agent 一行调用。Skill 里的 Prompt 是反复调过的，比临时手写更稳定。

还有一个容易混淆的区分：Skill 是创作格式，Plugin 是分发机制。 当你想跨仓库共享一个 Skill 或把几个 Skill 打包时，你把它做成 Plugin。在 Codex 和 Claude Code 中都是如此。

(4) Connectors (MCP)------Loop 的感知器官

Loop 不能只看文件系统。通过 MCP（Model Context Protocol），Loop 可以连接 Issue Tracker、Slack、Staging API、PR 系统等外部服务。

Connector 的真正价值在于：它让 Loop 从"告诉你修复方案"变成"自己打开 PR、关联 Linear 工单、CI 绿了之后在 Slack 通知你"。

Connector 是 Loop 能在你的真实环境中行动的原因，而不只是告诉你"如果可以的话我会这样做"。

(5) Sub-agents------分工协作的 Agent 网络

Generator Agent 写代码，Evaluator Agent 验代码。不同角色、不同指令、有时不同模型。Sub-agent 是 Loop 内部的分工机制。

在 Codex 中，你可以用 TOML 文件在 .codex/agents/ 下定义自己的 Agent------每个有名字、描述、指令和可选的模型及推理力度。于是你的安全审查员可以是一个高推理力度的强模型，而探索者是一个快速的只读模型。Claude Code 通过 .claude/agents/ 和 Agent Teams 实现同样的分工。

典型的三方分立：一个 Agent 探索，一个实现，一个对照规格验证。

Sub-agent 会燃烧更多 Token------每个都有自己的模型调用和工具开销，所以要把它们花在"值得付钱"的地方。

(6) Memory------Agent 的持久记忆

Agent 的上下文会丢失，但磁盘不会。Memory 把关键状态写入 Markdown、Linear、Issue，确保 Loop 跨轮次、跨会话持续运转。

六大组件的关系：

组件	作用	一句话
Automation	触发与循环	让 Loop 真正转起来
Worktree	隔离与并行	Agent 的独立工作区
Skill	复用与标准化	一行调用代替一墙指令
Connector	感知与连接	Loop 不能只看文件系统
Sub-agent	分工与制衡	写代码的和验代码的不是同一个
Memory	持久与传承	Agent 会忘，仓库不会

2.3 循环堆叠：四层 Loop

www.langchain.com/blog/the-ar...

Loop 不是只有一个------你可以堆叠，每一层让内层更可靠。

第一层：Agent 循环。 模型反复调用工具，直到任务完成------这是内置循环，干活用的。Agent 的核心算法很简单：给 LLM 上下文，让它在循环中调用工具，直到任务完成。工具是 Agent 获得在真实世界中行动能力的关键。

第二层：验证循环。 Agent 执行后，输出按评分标准打分，不合格则带反馈重试。这一层让你能相信"循环说做完了"。评分器可以是确定性的（规则），也可以是 Agent 式的（LLM 作为裁判是经典做法）。

添加验证会增加每次运行的延迟和成本，但当质量比速度更重要时------大多数生产场景都是如此------这是值得的。

权衡之下：增加验证会增加延迟和每次运行的成本。当质量比速度更重要时（大多数生产应用场景都属于这种情况），这样做是值得的。

第三层：事件驱动循环。 事件触发 Agent 运行------新文档到达、定时调度触发、webhook 到达------Agent 就开始运行。这一层让你不用手动启动。Agent 不再是你手动调用的东西，而是在更大系统中持续运行的组件。

OpenClaw 的 "heartbeats"（心跳）就是一个例子：把 Agent 变成一个始终在线的、主动式助手。

第四层：爬山循环。 每次 Agent 运行都会产生一条 trace------记录模型做了什么、调用了哪些工具、评分器反馈了什么。这些 trace 包含关于什么有效、什么无效的高价值信号。爬山循环让一个分析 Agent 审视这些 trace，利用发现来改写 harness 的改进配置------prompt 调整、工具调整、评分器调整。这一层让 Loop 越跑越好。

LangChain 团队表示，他们已经思考循环 1 和 2 很久了，但重点应该转向循环 3 和 4------因为当 Agent 嵌入你的生态系统并根据你的标准持续改进时，价值才会复合增长。Satya（微软 CEO）这样框定组织层面的利害关系：尽早构建学习循环的公司，让人类判断力和 token 资本共同复合增长，将建立起难以复制的优势。

每一层都有人类监督的自然接入点：

循环层	人类介入方式
Agent 循环	在敏感操作/工具调用前要求人类输入
验证循环	人类可作为敏感工作流的评分器
事件驱动循环	人类可在输出返回给最终用户前审批
爬山循环	harness 改进可在部署前经过人类审查

自动评分器能检查链接是否可解析，但只有人才能注意到面向受众的框架是否有问题。这种来自上下文、经验和品味的判断力，正是人类审查的价值所在。

2.4 Generator-Evaluator 模式

Anthropic 的 Prithvi Rajasekaran 发现了一个关键问题：

When asked to evaluate work they've produced, agents tend to respond by confidently praising the work---even when, to a human observer, the quality is obviously mediocre.

Agent 给自己打分，永远是"优秀"。解决方案不是让生成者更谦虚，而是把生成和评估拆成两个独立的 Agent------类似 GAN 的 Generator 和 Discriminator。

这跟设计评审的直觉一样：做东西的人，最不适合判断东西好不好用。

LanceMartin 的 Fable 5 实验显示，验证子 Agent 的覆盖率是 73%，而自评只有 7-33%。把写代码的和验代码的拆开，差距巨大。

Rajasekaran 的实践：

Tuning a standalone evaluator to be skeptical turns out to be far more tractable than making a generator critical of its own work.

Evaluator 的设计原则：Assume the code is broken until proven otherwise. （假设代码是坏的，直到被证明没问题。）

三、三个真实的 Loop

3.1 Addy Osmani 的 Triage Loop

逐层拆解：

• 触发：每天早上自动运行（Automation + cron）
• 发现：调用 triage skill，读取昨天的 CI 失败、open issue、最近的 commit
• 分诊：发现写入 Markdown 或 Linear Board，形成待办列表
• 执行：每个值得处理的发现，打开一个隔离的 Worktree，派出 sub-agent 起草修复
• 验证：第二个 sub-agent 对照项目 Skill 和已有测试审查修复草案
• 行动：Connector 打开 PR、更新 Ticket
• 兜底：Loop 处理不了的，放进 triage inbox 等人工介入
• 记忆：状态文件记录"试过什么、通过了什么、还剩什么"，明天的运行从今天停下的地方继续

Addy 的总结：你只设计了一次，你没有 Prompt 任何一步。 这就是 Steinberger 那句话的落地实现。

3.2 Karpathy 的 AutoResearch------让 AI 跑你的 ML 实验

Andrej Karpathy 的 autoresearch 项目，回头看，也是 Loop Engineering 的一种形态。设计理念叫"一块 GPU、一个文件、一个指标"：

AutoResearch 组件	Loop Engineering 对应
program.md：你只写研究方向	Skill------你不碰 Python 文件，只写意图
无限循环，每 ~5 分钟一轮	Automation------固定节奏调度
Agent 修改 train.py	实现者 Sub-agent
训练运行 + val_bpb 评估	验证者（不是 LLM------是真实的训练结果）
保留/回滚代码，记录实验	Memory------维护最优状态

The core idea is that you're not touching any of the Python files like you normally would as a researcher.

------ Karpathy, AutoResearch README

这里的验证者不是另一个 LLM，而是真实的训练运行本身。val_bpb 降了还是升了，由数学决定，不由模型判断。这是最严格的客观验证形式。每小时约 12 个实验，睡一觉醒来，约 100 个完成的运行。

3.3 Stripe 的 Minions------1300+ PR 的 Loop

Stripe 的 Steve Kaliski 在 How I AI 中分享了 Minions 系统：

• 触发：Slack 中 @Minion bot + emoji
• 调度：LLM Orchestrator 分配任务
• 执行：Agent 在 EC2 上运行（cattle not pets------随时可以销毁重建）
• 连接：Jira + Sourcegraph 通过 MCP 集成
• 验证：Gate 机制------linter、commit、review 三道关卡
• 成果：1300+ PR 被 Review

Minions 的架构：

Slack @emoji 触发  → Orchestrator LLM 调度  → LLM Agent 执行（EC2, cattle not pets）  → Pipeline: linter → commit → review  → 1300+ PR reviewed

3.4 /loop 与 /goal------从今天就可以开始的 Loop

Claude Code 提供了两个互补的 Loop 原语，Addy 特别强调了它们的区别：

/loop------按节奏循环

/loop 5m check the deploy

含义：每 5 分钟让 Claude 检查一次部署状态。/loop 是按节奏重复------你定义频率，Agent 每隔一段时间跑一轮。

/goal------跑到目标达成为止

/goal all tests in test/auth pass and the lint step is clean

含义：Agent 持续工作，直到你声明的条件为真。/goal 是按条件终止------你定义终点，Agent 一直跑到终点。每轮结束后，一个独立的轻量模型检查条件是否满足，不满足就继续下一轮。

Addy 的总结： /loop re-runs on a cadence. /goal keeps going until a condition you wrote is actually true. 两者都内置了"验收者不是干活者"的 maker-checker 分离------这是 Loop 能让你走开的前提。

Codex 也有同样的 /goal，支持 pause/resume/clear。同一个原语，两个工具，这本身就是 Loop Engineering 不依赖特定工具的证明。

四、代价与风险

4.1 无人值守 = 无人纠错

A loop running unattended is also a loop making mistakes unattended.

------ Addy Osmani

Loop 跑得越快，你越容易对它产生信任。但快速产出的 PR 背后，可能藏着你看不见的 bug。

4.2 Comprehension Debt（理解负债）

The faster the loop ships code you did not write, the bigger the gap between what exists and what you actually get.

Agent 生成的代码在仓库中膨胀，你对代码库的理解却在萎缩。你"拥有"更多代码，但真正理解的更少。Addy 把这个命名为 Comprehension Debt------一个顺滑的 Loop 只会让它长得更快，除非你主动阅读 Loop 产出的每一行代码。

4.3 Cognitive Surrender（认知放弃）

When the loop runs itself it's very tempting to stop having an opinion and just take whatever it gives back.

Loop 自动运转时，最危险的不是它犯错，而是你停止思考。Addy 把这个命名为 Cognitive Surrender ------设计 Loop 本身可以是解药，也可以是加速器。当你带着判断力去设计，Loop 让你走得更快；当你为了逃避思考而设计，Loop 让你陷得更深。同一个动作，相反的结果。

4.4 Token 成本

Loop 持续运转意味着 Token 持续消耗。你必须对 Token 成本有清醒的认知和预算控制。Sub-agent 尤其昂贵------每个都有自己的模型调用和工具开销。

4.5 Orchestration Tax（编排税）

Addy 提到了一个容易被忽略的天花板：你的 Review 带宽决定了你能同时跑多少个 Loop，而不是工具。 Worktree 解决了 Agent 之间的机械碰撞，但你的审查能力才是真正的瓶颈。Loop 产出的 PR 最终需要人来签字------如果你开 10 个 Loop 但每天只能 Review 3 个 PR，剩下 7 个就是悬而未决的风险。

4.6 风险应对

风险	应对
无人纠错	Evaluator Agent + 人工 Review，"done" 是声明不是证明
理解负债	主动阅读 Loop 产出的每一行代码
认知放弃	每个 PR 必须人工确认，不能自动合并
Token 成本	设置预算上限，Sub-agent 只用在值得付钱的地方
编排税	Loop 数量不超过你的 Review 带宽

五、今天就开始：构建你的第一个 Loop

Step 1：选一个触发源

从最简单的开始------CI 失败、新 Issue、或定时检查。不需要一步到位，先让 Loop 转起来。

Step 2：写一个 Skill

把你的 Prompt 封装成 $skill-name。不需要完美，先跑起来再迭代。

Step 3：加一个 Evaluator

用 /goal 或独立的 Evaluator Agent 验收结果。记住：假设代码是坏的，直到被证明没问题。

Step 4：用 Worktree 隔离

如果你的 Loop 会修改代码，让 Agent 在独立 Worktree 中工作。避免 Agent 之间的冲突。

Step 5：把结果落盘

PR、Issue、Markdown------Loop 的产出必须持久化。Agent 的记忆在上下文里，仓库的记忆在磁盘上。

Step 6：加上 Automation

从 /loop 5m 开始，让 Loop 自动循环。观察几轮，调优 Skill 和 Evaluator，再逐步扩大范围。

六、核心心法

Loop Engineering 的关键不在技术栈，在思维方式：

1. 你设计系统，系统驱动 Agent------从"用 AI"到"用 AI 构建自动系统"
2. 生成和验证必须分离------写代码的和验代码的不能是同一个 Agent
3. 验收者假设代码是坏的------直到被证明没问题
4. Agent 会忘，仓库不会------Memory 必须在磁盘上，不能只在上下文中
5. Loop 不能只看文件系统------通过 Connector 连接外部世界
6. 两个 Agent 写同一个文件 = 两个工程师改同一行------Worktree 是必须的
7. Skill 的描述要无聊不要聪明------精确的描述让 Agent 在正确时机调用
8. Intent Debt 必须偿还------把意图写在外面，让 Loop 复利增长而不是从零推导
9. 同一个 Loop，相反的结果------Loop 不区分理解与逃避，你区分
10. Loop 可以堆叠------Agent 循环 → 验证循环 → 事件驱动循环 → 爬山循环，前三层自动化工作，第四层自动化改进

要点速查：

• 停止条件就是产品------Loop 的上限取决于你怎么定义"完成"
• 杠杆的支点移动了------要练的不再是写完美 Prompt，而是设计替你发 Prompt 的循环
• 五个组件加记忆------Automation、Worktree、Skill、Connector、Sub-agent，靠跨轮次存活的状态文件串起来
• 生成和验证必须分开------你信任的审核者，才是你能放手的前提
• Loop 可以堆叠------Agent 循环 → 验证循环 → 事件驱动循环 → 爬山循环，前三层自动化工作，第四层自动化改进
• 保持工程师的思维------设计 Loop 时，要像一个打算持续理解工作原理的人，而不是一个只按启动键的人

最后一点是 Addy 全文最深刻的洞察：

Loop 设计比 Prompt Engineering 更难，不是更容易。 Cherny 的重点不是工作变简单了，而是杠杆的支点移动了------从"写更好的 Prompt"到"设计更可靠的循环"。

Loop Engineering 奖励的东西，跟好的设计奖励的一样：判断力。你的目标定得怎样、检查机制信不信得过、读反馈时的品味------这些决定了 Loop 的上限。

所以------去搭你的 Loop。但要像一个打算一直做工程师的人那样搭，而不是一个只按启动键的人。杠杆没有取代你，只是挪了个位置。

关于OpenTiny

欢迎加入 OpenTiny 开源社区。添加微信小助手：opentiny-official 一起参与交流前端技术～

OpenTiny 官网：opentiny.design/

OpenTiny 代码仓库：github.com/opentiny

GenUI SDK 源码：github.com/opentiny/ge...

欢迎进入代码仓库 Star🌟TinyEngine、TinyVue、GenUI SDK、TinyRobot、NEXT SDK

如果你也想要共建，可以进入代码仓库，找到 good first issue标签，一起参与开源贡献~