Loop Engineering 概念调研：从 Prompt Engineering 到自主 Agentic Loops 的范式转变

调研日期: 2026年6月24日
主题: Loop Engineering 作为 AI 工程新兴范式

1. 概念定义与核心思想

1.1 什么是 Loop Engineering？

Loop Engineering 是一种设计系统的实践——让系统自动地为 AI Agent 生成提示（prompt），而不是由人类手动逐轮输入提示。

三位关键人物在同一周内给出了几乎相同的判断：

“I don’t prompt Claude anymore. I have loops that are running. They’re the ones that are prompting Claude and figuring out what to do. My job is to write loops.” — Boris Cherny (Claude Code 创建者, Anthropic)

“You shouldn’t be prompting coding agents anymore. You should be designing loops that prompt your agents.” — Peter Steinberger (OpenClaw 创始人)

“Loop engineering is the practice of designing the system that prompts your AI agent, rather than typing each prompt yourself.” — Addy Osmani (Google Chrome 工程负责人)

一句话总结: Loop engineering 就是构建一个系统，让它按计划（schedule）和目标（goal）自动提示你的 Agent，而不是你手动输入每一个 prompt。

1.2 与传统 Prompt Engineering 的区别

1.3 核心理念

范式层级（Addy Osmani 提出的 AI 工程层次结构）：

1. Prompt Engineering — 优化单轮对话
2. Agent Harness Engineering — 设计单个 Agent 运行的环境
3. Loop Engineering — 在 harness 之上运行，按计划调度，生成子 Agent，自我供给

核心循环: 每个 loop 依赖一个四步机制：Act → Observe → Reason → Repeat

哲学转变:

• 过去: 杠杆在于"措辞"（写出完美的 prompt）
• 现在/未来: 杠杆在于"系统架构"（设计触发器、目标和验证）
• 构建一次 loop，每次运行都获得复利回报

关键洞察：Loop engineering 不是取代 prompt engineering，而是在其之上添加了自主控制结构。Prompt 和 context engineering 并没有消失，它们成为了 loop 内部的组件。

2. 关键构建模块

2.1 自动化调度（Automations / Scheduling）

使 loop 持续运行的触发机制——定期发现工作并分派任务。

四种 Loop 类型（Claire Vo 总结）:

1. Heartbeat loop — 固定间隔运行（如每15分钟）
2. Cron loop — 按计划时间运行（如每天上午10:15）
3. Hook loop — 由事件触发（如 PR 打开、测试失败）
4. Goal loop — 运行直到满足可验证的完成条件

关键实践: 停止条件要像合同一样写：

2.2 工作树（Work Trees）

Git worktree 为并行 Agent 提供隔离的工作副本，防止文件冲突。当多个 Agent 同时工作时，如果没有隔离，会导致静默覆盖、合并冲突、状态损坏。

# 从同一个仓库创建两个隔离的 checkout
git worktree add ../app-fix-login   -b fix/login-flake
git worktree add ../app-bump-deps    -b chore/bump-deps
# Agent 并行工作；绿色后合并分支

2.3 技能系统（Skills）

持久化的项目知识/约定，存储在 SKILL.md 文件中，防止 Agent 每次从头推导项目上下文。解决的问题是 Intent Debt（意图债务）——Agent 自信地猜测缺失的上下文，导致错误。

# .claude/skills/triage-ci/SKILL.md
---
name: triage-ci
description: Read overnight CI failures and open issues
---
1. Run `gh run list --status failure --limit 20` and read the logs.
2. Cross-reference open issues with `gh issue list --label bug`.
3. Group failures by root cause, not by individual test.
4. Append findings to TODO.md under "## Open", newest first.
5. Do NOT edit application code. This skill only triages.

2.4 子 Agent（Sub-Agents）

将"编写者"（maker）与"检查者"（checker）分离。编写代码的模型"太友好了"，无法公正地评价自己的工作。一个二级 Agent（通常使用不同的指令或更强的模型）来验证输出。

# .codex/agents/verifier.toml
name = "verifier"
description = "Adversarial reviewer. Gates a draft before it reaches a human."
model = "gpt-5.5"
reasoning_effort = "high"
instructions = """
Run the full test suite and lint before forming any opinion.
Check the diff against project skills and coding standards.
"""

关键原则: 验证者不需要更聪明，只需要不同——使用自己的评分标准（rubric）。

2.5 记忆/状态管理（Memory / State）

跨运行持久化状态，使 loop 在崩溃或上下文重置后能恢复。核心问题：模型在运行之间会遗忘；但仓库不会。

# STATUS.md — Agent 可读写的状态文件
## Completed
- [x] Fix login flake (commit abc123)
- [x] Bump deps to v2.1 (commit def456)

## In Progress
- [ ] Add error handling to payment module

## Blocked
- [ ] API rate limit issue — waiting for credentials

状态 vs 知识:

• Skills = 不变的知识（约定、构建步骤、项目结构）
• Memory/State = 变化的状态（什么完成了、下一步是什么）

3. 提出者和推动者

3.1 概念起源

Geoffrey Huntley — “Ralph Wiggum” 技术（2025年5月）

Loop engineering 的前身是 Geoffrey Huntley 在 2025 年 5 月创造的 “Ralph Wiggum” 技术（以《辛普森一家》角色命名）。核心思想极其简单：一个 bash while 循环，反复给 AI Agent 相同的 prompt，每次迭代强制上下文重置，利用文件系统（而非对话历史）作为记忆：

# 原始的 Ralph loop：相同的 prompt，全新的上下文，直到完成
while ! grep -q "ALL TASKS DONE" STATUS.md; do
  claude -p "Read PLAN.md and STATUS.md. Pick the next unchecked
             task, implement it, run the tests, commit on success,
             and update STATUS.md. Then stop." \
         --dangerously-skip-permissions
done

“That’s the beauty of Ralph - the technique is deterministically bad in an undeterministic world.” — Geoffrey Huntley

Huntley 的关键洞察：

• 状态存在于文件和 git 中，而不是 LLM 的内存中
• 在上下文污染积累之前，刻意切换到全新上下文
• “Ralph 不是一个会编码的循环”——它是一个有 3 个阶段、2 个 prompt、1 个循环的漏斗

Boris Cherny — Claude Code 创建者（2026年6月）

Boris Cherny 在 2026 年 6 月的 Acquired Unplugged 播客中说了那句引发全网讨论的话。他在采访中透露：

• 他白天保持 5-10 个 session 开放，运行数百个 Agent
• 每晚有数千个 Agent 在运行
• 他的 loop 包括：看护 PR（自动 rebase）、保持 CI 健康（修复 flaky tests）、每 30 分钟聚类 Twitter 反馈

Peter Steinberger — OpenClaw 创始人（2026年6月7日）

Peter Steinberger（PSPDFKit/Nutrient 创始人，OpenClaw 项目创建者——GitHub 历史上最多 star 的新仓库）发布了一句被广泛传播的话：“You should be designing loops that prompt your agents.”

Addy Osmani — 命名这个学科（2026年6月7日）

Google Chrome 工程负责人 Addy Osmani 在 2026 年 6 月 7 日发表了综合性文章 “Loop Engineering”，正式命名了这个学科。他将 Boris Cherny 和 Peter Steinberger 的观点综合为一个系统性的框架，提出了 loop engineering 的 6 个原语（primitives）。

3.2 主要推动者

4. 实际工具和实现

4.1 Claude Code 的 Loop 命令

/goal 命令

设置一个会话级的"Stop hook condition"——Claude 在 LLM 判断条件满足之前不能结束轮次。

# 设置目标
/goal all tests in test/auth pass and the lint step is clean

# 带预算限制
/goal coverage for src/billing is at or above 90% or stop after 20 turns

# 非交互式运行
claude -p "/goal CHANGELOG.md has an entry for every PR merged this week"

关键细节: 一个独立的、更小的模型检查停止条件，所以编码 Agent 不会"自己批改自己的作业"。

实际案例: 一位开发者运行了 9 小时 27 分钟的自主 /goal session：

• 4 个自 paced /goal 命令链式执行
• 45 个 commits
• 14,259 行代码/文档
• 416 万行数据从公共 registry 导入

/loop 命令

按时间间隔运行——更接近 cron 风格的外部循环。

# 每24小时运行一次
/loop 24h "Check staging URLs for all changed pages"

# 每小时检查 CI 状态
/loop 1h "Check CI pipeline status and report failures"

/goal vs /loop 对比

4.2 OpenAI Codex 的 Automations

Codex 的 Automations 功能允许你调度定期运行的后台任务。核心特性包括：

• Worktree Isolation: 自动化在专用后台 worktree 中运行，不触碰你的活跃本地分支
• Triage Inbox: 结果路由到 app 的 “Triage” 部分，作为你的个人开发者收件箱
• Skills 集成: 结合 MCP 和自定义 Skills 实现复杂任务
• 沙盒设置: 可锁定为"只读"模式，或完全访问但限制允许的终端命令

4.3 其他实现

• Anthropic Routines: 将 loop 移到服务端——Agent 自动在服务器端运行 loop，不需要本地保持终端打开
• Hermes Agent（Nous Research）: 实现了 ReAct runtime 的 loop 架构，支持自主任务执行循环、Cron 调度、Skills 系统、子 Agent 生成
• OpenClaw: Peter Steinberger 创建的开源 AI Agent 项目，实现了完整的 loop engineering 架构
• TrueFoundry: 企业级 Agent Harness，包含 AI FinOps（预算、配额、速率限制）和 MCP Gateway

5. 最佳实践和设计模式

5.1 如何设计一个好的 Loop

任务是否"Loop-Shaped"？

在构建 loop 之前，确保任务通过三个检查：

1. 重复性（Repetitive）: 足够频繁，值得付出设计成本
2. 可审查性（Reviewable）: “完成"可以被定义为 Agent/验证者能实际运行的检查
3. 价值性（Valuable）: 输出值得 token/时间成本

“入职新员工"心智模型

设计 loop 时，把它想象成入职一个新员工：

• 你需要告诉他们项目约定（Skills）
• 你需要给他们工具和权限（Connectors）
• 你需要定义"完成"意味着什么（Goal/Verification）
• 你需要设置报告结构（Memory/State）
• 你需要设置安全边界（Guardrails）

5.2 常见的设计模式

模式 1: Maker-Checker 分离

[Maker Agent] → 编写代码/执行任务
      ↓
[Checker Agent] → 验证输出（不同的模型/指令）
      ↓
[通过?] → 是: 提交结果 / 否: 返回 Maker 重试

模式 2: Triage → Isolate → Execute → Verify → Report

1. Trigger: 自动化每天早晨运行
2. Triage: triage skill 读取 CI 失败、开放 issues、最近 commits
3. Isolate: 对可操作项打开隔离的 git worktree
4. Execute: Sub-agent A 起草修复
5. Verify: Sub-agent B 根据项目 skills 和测试审查草稿
6. Action: Connectors 打开 PR 并更新 ticket
7. Fallback: 未处理项进入人工 triage inbox

模式 3: Open Loop vs Closed Loop

模式 4: 验证成本阶梯

核心洞察: 一个有免费验证者的困难任务（flaky test）比一个有昂贵验证者的简单任务（单行文案修改）更容易自动化。

5.3 成本和 Token 消耗的考量

斯坦福数字经济学研究（“How Do AI Agents Spend Your Money?"）发现：

1. Agentic 任务极其昂贵: 比代码推理和代码聊天消耗多 1000 倍 的 token
2. Token 使用高度可变且本质随机: 同一任务的运行可能相差 30 倍 的总 token
3. 更高 token 使用不等于更高准确率: 准确率通常在中等成本时达到峰值
4. 模型间差异巨大: 在同一任务上，Kimi-K2 和 Claude-Sonnet-4.5 平均比 GPT-5 多消耗超过 150 万 token

三个强制性护栏

1. 硬性迭代上限: 停止卡住的 loop
2. Diff 检查: 如果最近的通过停止改变任何东西，终止运行
3. 花费上限（token 或美元）: 在账单之前结束运行

真实案例: Uber 在 4 个月内耗尽了全年 AI 预算，之后将工程师 AI 花费上限设为 $1,500/人/月。

5.4 失败模式和限制

生产规则: 一个只读取的 loop 只需要一个时间表；一个写入的 loop 需要一个排序证明和爆炸半径限制，才能获得时间表。

6. 行业影响和未来展望

6.1 对软件工程的影响

角色转变

• 从 Prompt Engineer 到 Loop Engineer: 核心技能从"措辞"转向"系统设计”
• 从 Developer 到 Builder: Boris Cherny 预测"软件工程师"将溶解为"builder”
• 人类审查成为瓶颈: 人类审查带宽是你能有效运行多少 Agent 的天花板

生产力数据（Spotify 案例）

• 99% 的工程师每周使用 AI 编码工具
• 94% 报告 AI 提高了生产力
• PR 频率增加 76%

新的工程层次

┌─────────────────────────────────────────────┐
│  Loop Engineering                           │  ← 设计自主系统
│  (调度、验证、状态管理、护栏)                │
├─────────────────────────────────────────────┤
│  Agent Harness Engineering                  │  ← 设计 Agent 运行环境
│  (工具、权限、沙盒、上下文管理)              │
├─────────────────────────────────────────────┤
│  Context Engineering                        │  ← 管理上下文窗口
│  (RAG、文档、历史、工具选择)                 │
├─────────────────────────────────────────────┤
│  Prompt Engineering                         │  ← 优化单轮指令
│  (措辞、格式、few-shot examples)             │
└─────────────────────────────────────────────┘

6.2 未来发展方向

短期（2026年下半年）:

1. Loop 语法正在消亡: 模型已经开始自主发起 loop
2. 服务端 Loop: Anthropic 的 Routines 将 loop 移到服务器端
3. 更好的验证工具: 独立的验证模型和自动化审查工具将变得更加成熟
4. 企业级治理: Agent 库存、身份管理、集中策略、统一可观测性

中期（2027-2028）:

1. Loop 市场: 预构建的、可共享的 loop 模板和 skills
2. 自适应 Loop: Loop 能根据运行结果自动调整自己的参数
3. 跨组织 Loop: 多个组织的 Agent 通过标准化协议（MCP）协作

长期趋势:

1. 自主软件工厂: 完整的软件开发流程由 loop 编排，人类只在关键决策点介入
2. Loop 的 Loop: 元循环（meta-loops）设计和优化其他 loop
3. 验证的自动化: 形式化验证和自动证明技术使更多任务可以无人值守

6.3 关键警告

“A loop running unattended is also a loop making mistakes unattended.” — Addy Osmani

“The durable skill is deciding what is safe to automate unattended.” — Blake Crosley

“Done is a claim, not a proof.” — 多位 Loop Engineering 实践者的共识

7. 参考资源

核心文章

官方文档

视频/播客

本文基于 2026 年 6 月的公开信息编写。Loop Engineering 是一个快速发展的领域，具体工具和功能可能已有更新。