Loop Engineering 完全指南：原理拆解、核心组件与实战案例

一、引言：当循环变得比人更可靠

2026 年 6 月，AI 工程领域发生了一次认知转折。三件事情几乎同时发生：

Anthropic 开发者大会上，Claude Code 创始人 Boris Cherny 说了一句话，被在场数千名开发者反复引用：

"I don't prompt Claude anymore. I run loops that prompt Claude and decide what to do next. My job is to write loops."
（我不再提示 Claude 了。我设计循环来提示 Claude，然后判断下一步做什么。我的工作是设计循环。）

几乎同一时间，前 Google 工程师 Addy Osmani 发表了一篇题为《Loop Engineering》的专题文章，正式命名了这个正在形成的新范式：

"Loop engineering is replacing yourself as the person who prompts the agent. You design the system that does it instead."
（循环工程就是用你自己来取代那个手动提示 Agent 的人。你设计一个系统，让它来做这件事。）

紧接着，OpenClaw 创始人 Peter Steinberger 在 X 上发帖呼应：

"Monthly reminder: you should no longer prompt programming agents yourself. You should design loops that prompt agents."

三条信息指向同一个方向：人应该退出"提示→等待→检查→再提示"的循环，把这件事交给系统来做。

这篇文章从原理到实战，系统拆解 Loop Engineering——它是什么、由什么组成、有哪些变体、以及真实的团队如何在生产环境中落地。

二、为什么我们走到了 Loop？

要理解 Loop Engineering 为什么在 2026 年爆发，得先回看之前走过的路。

从 Prompt 到 Loop：AI 工程的四次进化

阶段 时间 核心问题 解决方式
Prompt Engineering 2023–2024 怎么让模型一次回答更准？ 优化措辞、角色设定、CoT
Context Engineering 2025 怎么让模型知道更多？ RAG、MCP、记忆管理
Harness Engineering 2026.02 怎么让 Agent 不犯同样的错？ AGENTS.md、Linter、权限系统
Loop Engineering 2026.06 怎么让 Agent 自己驱动自己？ 自动化循环 + 验证 + 重试

每一次进化都解决上一层的瓶颈，同时把"人"进一步推离执行环节。

Prompt 时代：人在循环里，每一步都要写指令。
Context 时代：人还是循环的一部分，但 Agent 已经能检索信息了。
Harness 时代：Agent 能独立完成任务了，但"启动它"仍然是人。
Loop 时代：人彻底退出执行循环，变成"设计循环的人"和"验收结果的人"。

用 Addy Osmani 的话说：

"You write a small program that handles discovery, planning, execution, verification, and iteration, and the loop calls the model on a schedule until a stopping condition is met."

三、Loop 的核心解剖：五个零件

任何一个最小可运行的 Loop，都由五个零件构成。缺一个，它就不是真正的循环。

3.1 Goal（目标）

什么算"完成了"？

这不是哲学问题，是一个可以被程序检验的布尔表达式。

  • ❌ "优化得更好" → 不是 Goal（没法程序判断）
  • ✅ "npm test 全绿且 tsc --noEmit 无报错" → 是 Goal
  • ✅ "代码覆盖率从 72% 提升到 80%" → 是 Goal
  • ✅ "修复 Issue #1234 描述的 bug，且回归测试全部通过" → 是 Goal

Anne Gentzkind（Codex 产品负责人）的表述非常精准：

"A regular prompt says: do this next. A Goal says: keep working until this outcome is true."

3.2 Trigger（触发器）

什么时候开始跑这个循环？

没有触发器的循环需要你手动启动——那你还是在循环里。

常见的触发器类型：

类型 实现方式 适用场景
定时触发（Heartbeat） /loop 5m、Cron 盯 CI、定时检查
Cron 触发 Linux Cron、GitHub Actions 夜间批处理、每日报告
事件触发（Hook） Git Hook、Webhook PR 创建时自动审查、CI 失败时自动修
目标驱动（Goal） Codex /goal 命令 持续修到测试变绿

3.3 Prompter（提示生成器）

每次循环应该给 Agent 发什么指令？

Prompter 不是简单的"把同一个 prompt 反复发"。好的 Prompter 会：

  • 根据上一轮的验证结果，调整下一轮的指令
  • 把失败信息（测试输出、lint 报错）融入新的 prompt
  • 不让 Agent 每次都从零开始理解上下文

3.4 Agent（执行器）

谁来做实际的工作？

Agent 是实际执行任务的模型实例——读文件、写代码、调 API、查数据库。

注意：这个位置的模型选择对成本影响巨大。 一个 Loop 可能跑几十次迭代，选错模型（比如在简单任务上用旗舰模型）会让 Token 消耗迅速失控。

3.5 Verifier（验证器）

这轮产出达标了吗？

这是五个零件中最容易被低估、也最有价值的一个。

Verifier 的核心原则只有一个：

Generator 绝对不能给自己的产出打分。
（写代码的 Agent 和审代码的 Agent 必须是两个 Agent。）

因为让同一个 Agent 给自己的代码打分，结果一定是"写得太好了"。Anthropic 的工程团队发现：

"Tuning a standalone evaluator to be skeptical turns out to be far more tractable than making a generator critical of its own work."
（调教一个独立的评估器让它保持怀疑，比让生成器对自己苛刻得多。）

实践中，Verifier 甚至不需要和 Generator 一样强的模型。审代码需要的不是"写出更好的代码"，而是"检查是否满足标准"——所以可以用更便宜的模型来做验证，大幅降低成本。

完整的 Loop 流程图

          ┌─────────────────┐
          │   Trigger 触发   │
          │ （定时/事件/Goal）│
          └────────┬────────┘
                   ▼
          ┌─────────────────┐
          │  Prompter 生成   │
          │  下一轮指令       │
          └────────┬────────┘
                   ▼
          ┌─────────────────┐
          │   Agent 执行     │
          │ （写代码/调API）  │
          └────────┬────────┘
                   ▼
          ┌─────────────────┐
          │  Verifier 验证   │
          │ （独立检查达标）   │
          └────────┬────────┘
                   │
          ┌────────┴────────┐
          │                 │
        达标              不达标
          │                 │
          ▼                 ▼
       ┌──────┐      ┌──────────────┐
       │ 退出  │      │ 重试（带修正  │
       │      │      │  上下文更新）  │
       └──────┘      └──────┬───────┘
                            │
                            └──── 回到 Prompter

四、Open Loop vs Closed Loop

Loop 有两种基本形态，适用于完全不同的场景。

4.1 Open Loop（开放循环）

特点：不预设完整路径，给 Agent 一个大方向，让它自己探索。

适用场景：不确定要做什么——原型验证、未知领域调研、"帮我看看这个代码库有什么问题"。

优点：可能发现你没想到的问题和方案。

缺点：Token 成本不可预测。一个没有刹车的 Open Loop，一晚上能烧掉你一个月的 API 预算。

4.2 Closed Loop（封闭循环）

特点：预设完整步骤，每步都有验证标准，通过才进入下一步。

适用场景：明确知道要做什么——修特定 Bug、跑固定流程、批量处理同类任务。

优点：成本可控、结果可预测、适合无人值守。

缺点：灵活性差，遇到预设之外的情况会卡住。

实践建议：先用 Open Loop 探路，验证可行性。然后把验证过的路径固化成 Closed Loop 上生产。

五、Loop 的三个刹车：没有刹车的循环是 Token 焚烧炉

Loop 最直接的风险是无限运行。

如果目标定义模糊（比如"让代码更好"），Agent 会觉得永远还能"更好一点"。你一觉醒来，发现账单多了四位数。

三个必须设置的刹车：

# 伪代码：Loop 的基本安全机制
MAX_ITERATIONS=10        # 最多跑 N 次就停
MAX_COST_USD=5           # 最多花 X 美元就停
NO_PROGRESS_LIMIT=3      # 连续 N 次无实质进展就停

while ! goal.is_met && iterations < MAX_ITERATIONS && cost < MAX_COST_USD; do
    result=$(agent.run "$task")
    if ! has_progress "$result" "$last_result"; then
        no_progress_count=$((no_progress_count + 1))
        if [ "$no_progress_count" -ge "$NO_PROGRESS_LIMIT" ]; then
            break
        fi
    else
        no_progress_count=0
    fi
    iterations=$((iterations + 1))
done

六、实战案例详解

案例一：夜间自动修 Bug 循环（Claude Code 实现）

场景：一个中等规模的代码仓库，每天会产生新的 CI 失败和小 Issue。团队想让一个循环每天自动处理简单任务，早上人来 Review。

第 1 步：定义 Goal

{
  "goal": "修复昨日 CI 失败 + 处理 good-first-issue 标签的 Issue",
  "stop_conditions": {
    "max_iterations": 20,
    "max_cost_usd": 10,
    "target": "所有任务处理完 OR 测试全绿"
  }
}

第 2 步：设计触发器

每天早 6:00 Cron 触发：

0 6 * * * cd /repo && claude-code --goal "Fix yesterday's CI failures"

第 3 步：执行流程

3.1 发现工作阶段

Automation 触发后，通过 GitHub API 扫描：

  • 昨日失败的 CI Workflow
  • 标签为 good-first-issue 的新 Issue
  • 最近 Commit 引入的 lint 错误

产出任务列表，写入状态文件 loop-state.md。

3.2 隔离环境阶段

使用 Git Worktree 为每个任务创建独立的工作目录：

git worktree add ../fix-ci-123 -b fix/ci-123
git worktree add ../fix-issue-456 -b fix/issue-456

多个任务可以并行处理，互不干扰——这是 Loop 从"单线程"扩展到"多线程"的关键基础设施。

3.3 Writer Agent 执行修复

Writer Agent 读取 SKILL.md 了解项目规范后：

  1. 分析失败原因（读 CI 日志）
  2. 生成修复代码
  3. 本地运行测试确认修复有效

3.4 Reviewer Agent 验证

独立 Reviewer Agent（可用更便宜的 Sonnet 模型）：

  1. 检查代码是否符合项目规范
  2. 确认测试全绿
  3. 对比 Diff 和 Issue 描述，确认修复了正确的问题

3.5 输出结果

验证通过 → 自动创建 PR，发 Slack 通知
验证失败 → 放入 Triage Inbox，等待人工处理
更新 loop-state.md，记录已处理的任务

效果

每天早上打开电脑，2-3 个 PR 已经在等你 Review。简单的 lint 修复、依赖更新、test fix，Loop 已经自动处理了。你只需要看一眼 Diff，确认没问题，点 Merge。

你从"写修复代码的人"变成了"Review 修复代码的人"。杠杆倍率：至少 3-5 倍。

案例二：Web Scraping 自我修复循环

场景：一个爬虫项目，目标网站经常改版导致选择器失效，爬虫静默产出垃圾数据，直到有人发现。

这是 Loop Engineering 的完美测试用例——因为 Web Scraping 领域有一个大多数工程领域没有的优势：已经有现成的质量评估框架（Spidermon）。

第 1 步：定义验证标准（Rubric）

const rubric = {
  required_fields: ['name', 'price', 'url'],
  min_items: 5,
  min_fill_rate: 0.95,  // 95% 的字段必须非空
  max_error_rate: 0.05
};

第 2 步：分离 Maker 和 Checker

  • Maker（生成器）：Spider，负责爬取网页和解析数据
  • Checker（检查器）：独立的评估程序，对照 Rubric 打分——Generator 永远不会看到自己的评分，直到评估器报告结果

第 3 步：构建循环

#!/bin/bash
# 最小可运行的 Loop

MAX_ATTEMPTS=5
attempt=1

while [ $attempt -le $MAX_ATTEMPTS ]; do
    echo "=== Attempt $attempt ==="
    
    # 1. 执行爬虫
    scrapy crawl my_spider -o output.json
    
    # 2. 独立评估
    python evaluate.py output.json > eval_report.json
    
    # 3. 检查是否达标
    if jq -e '.passed == true' eval_report.json > /dev/null; then
        echo "✅ 质量达标！"
        break
    fi
    
    # 4. 不达标 → 让 Agent 修复爬虫
    echo "❌ 质量不达标，尝试修复..."
    cat eval_report.json | claude-code --goal "Fix the spider based on this report"
    
    attempt=$((attempt + 1))
done

效果

实测中，当模拟网站改版（重命名所有 CSS class、重组页面结构），爬虫的字段填充率瞬间降为零。Loop 立即触发，Claude 读取新页面的 HTML，把每个旧选择器映射到新等价物——修复目标在第一次尝试时即达成。

一个让开发者特别满意的细节：修复 Agent 试图验证自己的修复时，被拒绝执行任何验证。独立的 Rubric 重新运行在外部循环中，是评判补丁是否有效唯一的裁判。Maker-Checker 分离不是开发者手动写出来的，而是 Loop 的结构自然产生的。

案例三：使用 opencode-loop 搭建自我修正的开发循环

场景：一个 Python 项目，初始只有 8 个测试用例。开发者想验证：如果让 AI 自己写代码、自己 Review、自己跑测试，最终质量会怎样？

执行过程

  1. Goal 设定：为某个功能模块编写完整实现，测试覆盖率不低于当前水平
  2. Loop 配置：Writer Agent + Reviewer Agent + Test Runner
  3. Key 设计：
    • Verifier 独立于 Writer 运行
    • 每次修改后自动运行完整测试套件
    • 设置 Checkpoint：每轮迭代保存一次状态，防止无限循环中丢失进展
  4. 结果：大约十几分钟后，测试从 8 个变成了 23 个，全部通过。

关键发现：不是 AI 本身变强了，而是 Verifier 和 Checkpoint 的设计让 Agent 可以在一个安全边界内反复试错，每次失败都转化为改进。

七、Loop Engineering 的三大风险

7.1 Token 焚烧炉（Token Furnace）

这是最直接的风险。没有停止条件的 Loop 会无限运行。

解决方案：

  1. 迭代上限：最多跑 N 次就停
  2. 预算天花板：最多花 X 美元就停
  3. 无进展检测：连续 3 次迭代没有实质性变化就停

"You did not build a loop. You built a very confident token furnace." —— 社区名言
（你没造一个循环，你造了一台自信满满的 Token 焚烧炉。）

7.2 理解力债务（Comprehension Debt）

Loop 跑得越快，你没读过的代码就积累得越快。这是传统"技术债"的 AI 加速版。

解决方案：

  1. 强制 Code Review——Loop 开的 PR，人必须看
  2. 保持 Diff 级别的理解——不需要逐行，但要知道每次改了什么
  3. 定期"理解力审计"——随机抽查 Loop 产出的代码

7.3 认知投降（Cognitive Surrender）

这是最隐蔽的风险。Loop 可以帮你放大思考，也可以帮你逃避思考。

  • 放大思考：你深入理解问题，设计精确的验证标准，用 Loop 自动化执行——你的判断力被放大了
  • 逃避思考：你不想理解问题，把一切都扔给 Loop，期待它自己搞定——你的能力在退化

判断标准：如果你能向别人解释清楚你的 Loop 为什么这么设计，你就是在放大思考。如果说不清楚，你就是在逃避。

八、什么时候该用 Loop？

Addy Osmani 和社区总结的三个判断标准：

标准一：这个任务重复吗？（Repetitive）

如果一个任务只会做一次，直接 prompt 就行了。Loop 的投入（设计触发器、写 Skill、设验证标准）只有在任务反复出现时才有回报。

标准二：成功标准可验证吗？（Reviewable）

"测试全绿"是可验证的。"代码写得好"不是。如果你说不清"什么算完成"，这个任务不适合 Loop。

标准三：值得投入吗？（Valuable）

设计一个 Loop 需要时间。如果任务每次只花 5 分钟、每月才出现一次，不值得。

三问答案：好，值，可验证 → 上 Loop。否则，别。

九、主流工具与基础设施

截至 2026 年 7 月，支持 Loop Engineering 的主流工具：

工具 支持形态 适用场景
Claude Code /loop 心跳模式、/goal 目标模式 终端开发、代码修改
Codex Goal 功能、Automations Tab 持久目标、定时任务
Hermes Goal 命令 跨 Session 持续工作
Linear Loops 功能 定时/事件触发的后台任务
Git Worktree 并行隔离 多 Agent 协同修改
MCP 标准工具接口 连接外部系统和数据源

十、结语

Loop Engineering 不是一个新发明——Anthropic 在 2024 年 12 月的《Building Effective Agents》一文中就已经描述了同样的生成-评估-循环模式。那时候它叫 Evaluator-Optimizer Pattern。Addy Osmani 自己也承认，他起这个名字时就已经在质疑它会不会被取代。

新的是什么？

是产品化的基础设施——Codex 和 Claude Code 把手工 Bash 循环变成了 \goal 命令。是社区规模——六周内数百万开发者讨论和实践这个模式。是模型能力——Claude Fable 5 足够可靠到可以长时间自主运行，而不需要人每隔十分钟干预一次。

Boris Cherny 用一个数据点做了最好的总结：他整整一个月没有打开 IDE——Claude Code 替他写下了横跨 259 个 PR 的所有代码行。

你不一定会像他那样极端。但如果你还在每次写 prompt、等回复、检查结果、再写 prompt 的循环里手动重复，那你应该停下来问自己一个问题：

"我能不能把这个重复的结构本身，变成一个程序？"

如果可以，那你已经在做 Loop Engineering 了。

本文基于以下来源撰写：Addy Osmani《Loop Engineering》；Boris Cherny 在 Anthropic 开发者大会演讲；Peter Steinberger X 推文；Mitchell Hashimoto《My AI Adoption Journey》；OpenAI《Harness Engineering》实践报告；Codex Goal 功能文档；掘金/腾讯云社区 Loop Engineering 实战案例；FrontierNews 关于 Web Scraping Loop 的报道；LangChain State of AI Agents 2025 调查报告。

posted @ 2026-07-27 16:41  小白跃升坊  阅读(270)  评论(0)    收藏  举报