Loop Engineering（循环工程）：从概念到实战#

一、起源：一个共识在一周内成型#

2026 年 6 月初的短短一周内，三位分别身处不同 AI 巨头的人，几乎同时说出同一句话：

• Peter Steinberger（OpenAI/OpenClaw 作者）：“你不该再 prompt 编程 agent，你该去设计那些 prompt agent 的循环。”
• Boris Cherny（Anthropic Claude Code 负责人）：“我不再亲手 prompt Claude 了。我运行着一些循环，由它们负责 prompt Claude 并决定下一步做什么。我的工作变成了写这些循环。”
• Addy Osmani（前 Google Chrome DX 负责人）随后写了七千字长文，正式给这个概念定名：Loop Engineering。

Andrej Karpathy 补了一句：“把自己从瓶颈中移除。投进去极少的 token，让海量的事情在你的视角之外自动发生。”

用一句话概括定义（综合 Addy Osmani 与 Saulius 的表述）：

Loop Engineering 不再由你亲自向 agent 发送指令，而是设计一套系统——它自己发现工作、分发执行、验证结果、持久化进度、决定下一步，并按节奏定时运行。你从”循环里的操作员”变成”循环外的设计者”。

二、它在演进谱系中的位置#

关键区分（来自 shuji-bonji 的辨析）：

• 内层循环（inner loop）：单 agent 内部的 model → tools → context → repeat，ReAct 时代已解决，不是竞争焦点。
• 外层循环（outer loop）：原本由人类承担的”写 prompt → 读 turns → 写下一条 prompt”——这才是 Loop Engineering 在自动化的一层。

放在更长的演进脉络里看：2022 年 ReAct 论文奠定了”边想边做”的理论起点；2023 年 AutoGPT 把它初步工程化为可放手运行的早期产品；2025 年业界觉醒了”主动设计 Loop”的工程意识；2026 年 6 月 Addy Osmani 的长文《Loop Engineering》让它正式落地为一套系统化的工程体系。

三、核心架构：五步动作 + 六块积木#

来自 asixiv 整理的 Anthropic playbook 与 Addy Osmani 原文。

1
Discovery → Handoff → Verification → Persistence → Scheduling
2
 发现工作    分发执行    验证结果       持久化进度     调度下一轮

四、五个设计杠杆#

eesel.ai 把整篇拆解成五个可调的杠杆：

1. Tools（agent-computer interface）：agent 能干什么。Anthropic 在 SWE-bench 上花在优化工具的时间比优化 prompt 还多，并把这条经验命名为 ACI（agent-computer interface），相当于 agent 的 UI。Simon Willison 更偏好纯 shell 命令，因为”编码 agent 真的很擅长跑 shell 命令”。
2. Stopping conditions：成功条件 / 最大迭代 / 预算上限 / 无进展检测。没有终止逻辑的 loop 不是自主，是失控。 Anthropic 原话：“It’s also common to include stopping conditions (such as a maximum number of iterations) to maintain control.”
3. Context management：压缩（compaction）、笔记（NOTES.md）、子 agent 把几万 token 折叠成 1-2k 摘要。原因——recall 随 token 数增长而衰减，必须主动策展。
4. Verification：最被反复强调的一条——必须由独立上下文（理想情况下换模型）做评分，agent 不能批自己的作业。Anthropic 的做法是维护一份 200+ 条 e2e 特性列表，每条标 passes: false，agent 不能擅自标完成。
5. Guardrails：沙箱、最小权限凭据、预算上限。Simon Willison 给 Claude Code 一个独立 Fly.io 组织 + 5 美元预算，防止失控 loop 烧真钱。

eesel.ai 把这一切用一句话钉死：“在 loop engineering 里，验证就是设计本身。一个有优秀 prompt 但验证薄弱的 loop 依然会失败；一个 prompt 平平但验证强大的 loop 会收敛。“

五、详细案例：日志 Bug 自主修复闭环#

下面这个案例来自腾讯新闻 2026/07 报道的真实生产环境（AI 云诊断系统维护），是迄今为止讲得最完整的一个 Loop Engineering 落地实例。

1
发现日志 Bug → 跨 3 个 Logstore 关联查询
2
           → 7 个子命令 + git log 交叉验证定位根因
3
           → 生成补丁
4
           → 跑完 334 条回归测试
5
           → 提交 CR
6
           → 预发部署
7
           → 集成验证
8
           → 钉钉通知审批

六、最小可运行示例#

基于 saulius.io 给出的 Python 骨架（用 Anthropic SDK），保留了 loop 的三个结构性特征：反馈信号、独立 verifier、跨轮记忆。

1
import anthropic
2
import subprocess
3
from pathlib import Path
4

5
client = anthropic.Anthropic()
6
MEMORY = Path("STATE.md")
7
RUBRIC = "all tests in tests/ pass; no new mypy errors; diff <= 200 lines"
8
MAX_ITERS = 20
9

10

11
def run_tests():
12
    """反馈信号——loop 的命脉"""
13
    r = subprocess.run(
14
        ["pytest", "tests/", "--tb=short"],
15
        capture_output=True, text=True,
16
    )
17
    return r.returncode == 0, r.stdout + r.stderr
18

19

20
def worker(goal, feedback):
21
    """生成器：写代码 / 修 bug"""
22
    memory = MEMORY.read_text() if MEMORY.exists() else "(no prior attempts)"
23
    prompt = f"""Goal: {goal}
24
Prior attempts and rejected approaches:
25
{memory}
26

27
Latest test feedback:
28
{feedback}
29

30
Diagnose the ROOT cause (not symptom), make the smallest fix,
31
do not refactor unrelated code."""
32
    resp = client.messages.create(
33
        model="claude-opus-4-7",  # 截至发稿已被 claude-opus-4-8 接替，4.7 仍为合法 ID；任选一个当前可用的 opus 级模型即可
34
        max_tokens=4096,
35
        messages=[{"role": "user", "content": prompt}],
36
        tools=[{"name": "edit_file", "description": "edit a file"}],
37
    )
38
    return resp
39

40

41
def verifier(goal):
42
    """独立 checker——换上下文，最好换模型"""
43
    passed, output = run_tests()
44
    if passed:
45
        return True, "tests green"
46
    resp = client.messages.create(
47
        model="claude-haiku-4-5",  # 故意换一个模型
48
        max_tokens=1024,
49
        messages=[{"role": "user", "content": f"""
50
Goal: {goal}
51
Rubric: {RUBRIC}
52
Test output: {output[:4000]}
53
Does this meet the rubric? Answer ONLY 'PASS' or 'FAIL: <reason>'."""}],
54
    )
55
    verdict = resp.content[0].text
56
    return verdict.startswith("PASS"), verdict
57

58

59
def loop(goal):
60
    for i in range(MAX_ITERS):
61
        feedback = run_tests()[1] if i > 0 else "(first run)"
62
        worker_resp = worker(goal, feedback)
63
        # 执行 worker 的 tool_calls（编辑文件、跑命令）...
64
        ok, verdict = verifier(goal)
65
        # 落盘——agent 会忘，仓库不会
66
        MEMORY.write_text(f"\n## iter {i}\nverdict: {verdict}\n")
67
        if ok:
68
            return f"done in {i+1} iterations"
69
    return "hit max iters"
70

71

72
loop("fix: company name with single quote crashes bill save")

三个结构性选择的含义：

• run_tests() 是反馈信号——没有它就只是链式调用。
• verifier() 跑在独立上下文、用不同模型——这是能说”不”的关键。
• MEMORY 落盘——明天接着今天，而不是从零重复。

Claude Code 里同样形态的对应物：/loop 让 agent 按时间表重复执行；/goal 设定一个目标，agent 持续工作直到达标或卡住（每个 turn 后由一个独立的小模型判断”完成条件是否达到”——这正是 maker/checker 分家应用在停止条件本身）；hooks 让特定事件确定性触发脚本（agent 编辑文件就自动跑 lint，一轮结束前自动验证构建）。

七、四个会悄悄累积的债#

asixiv 把它们称为”loop 的四个静默成本”，会相互强化：

1. Verification debt（验证债）：验证器松一寸，生成器就放飞一丈。未被验证的产出会运行更久、花更多钱，进而产生更多未被验证的产出。
2. Comprehension rot（理解腐化）：你不再坐在循环里，对系统的理解会过期——你保留所有权，但失去理解。
3. Cognitive surrender（认知让渡）：把判断外包给 loop，自己逐渐看不懂产出。
4. Token blowout（token 爆炸）：失控 loop 会自动烧钱，与验证债互相强化。

最关键的防线：定期从”生产模式”切回”发现模式”——亲自跑一轮 loop，问问”这个压缩还配得上信任吗”。理解是不可转移的，权限可以下放，权威必须留在人手里。

shuji-bonji 把这条线画得很清楚：人坐在外层循环里是”发现模式”（对话、思考出声、探索性委派），把外层循环固化进系统是”生产模式”（指令文档、阶段切分、明确的验收标准）。Loop Engineering 不是全部的生产模式，而是把”循环这个动作本身”也外化到系统里的极端。每一次自动化都要重问：什么能交给系统同时保住它的理解？什么必须不交出去？

八、Claude Code 里的对应物#

Claude Code 已经把上面六块积木都内建了，对应关系：

值得单独提一句 /goal：它和 /loop 不是一回事。/loop 是按 cadence 重跑，/goal 是持续工作直到条件为真——每轮结束后由一个独立的小模型判断停止条件是否达到，写代码的那个 agent 不参与打分。这是 maker/checker 原则（银行业务里的大额转账录入与审核必须分人）应用在停止条件本身。Addy Osmani 原文的原话点明了这层设计意图：“a fresh model decides if the loop is done instead of the one that did the work, the maker and checker split applied to the stop condition itself。“

九、总结#

Loop Engineering 不是把 prompt 改成 while true。它是一个具体的设计动作：把外层循环——那个原本由你承担的”读 turns → 写下一条 prompt”的角色——拆进系统里，让系统自己发现工作、分发、验证、记忆、调度。

落地最小集合：自动化触发 + 工作树隔离 + Skill 固化约定 + MCP 连接器 + maker/checker 子 agent 分家 + 磁盘上的 STATE.md。最不可省略的是独立 verifier——agent 不能批自己的作业。

真实案例（腾讯的 1210 → 47）证明它有效；但 asixiv 的总结也清醒：“同一个 loop，两个人搭出来，结果可以是相反的”——差距就在那几个能说”不”的检查点上。

用一句话收尾，也是这个领域一周内收敛出来的共识：别再 prompt agent，去设计让 agent 自己跑的循环——但要像”打算继续当工程师”的人那样去搭，而不只是”按下启动键”的那个人。

参考来源#

• Addy Osmani《Loop Engineering》Substack 长文
• Saulius《Loop Engineering: Designing the System That Drives the Agent Instead of Prompting It》
• eesel.ai《Loop engineering explained: designing AI agent loops in 2026》五杠杆拆解
• shuji-bonji《Loop Engineering — Moving the Outer Loop into the System》内/外循环辨析
• asixiv.org《Loop Engineering: The Anthropic Playbook for Designing Systems That Prompt Your Agents》
• LangChain《The Art of Loop Engineering》
• Claude Code 官方文档《How Claude Code works》agentic loop 章节
• Oracle Blogs《What Is the AI Agent Loop?》
• 腾讯新闻《Loop Engineering 实战：实现从日志扫描到预发部署的全自主闭环》（2026/07）
• 腾讯云开发者《Loop Engineering 循环工程：别再 Prompt Agent 了》
• 百家号《Loop Engineering：被高估的循环》《AI 编程进入 Loop 新阶段》
• 知乎专栏《AI Agent 当下的热门范式 Loop Engineering 之深度剖析》