Loop Engineering：AI 编程范式的下一次跃迁
摘要：2026年6月，一条12个字的推文引爆了整个 AI 编程圈。“你不该再手动给 Agent 写提示词了，你应该设计让 Agent 自己驱动自己的循环系统。” 这就是 Loop Engineering —— 一种从「人驱动 AI」到「系统驱动 AI」的根本性转变。本文将带你彻底搞懂它。
一、从一条推文说起
2026年6月7日凌晨，Peter Steinberger（OpenClaw 创始人、OpenAI 开发者）在 X 上发了两句话：
“Here’s your monthly reminder that you shouldn’t be prompting coding agents anymore. You should be designing loops that prompt your agents.”
帖子在24小时内突破了500万浏览量，整个 AI 开发者社区陷入了激烈讨论。
几天前，Anthropic Claude Code 的创始人兼负责人Boris Cherny在一场邀请制活动上说了几乎相同的话：
“我现在不再自己给 Claude 写提示词了。我有循环在跑，它们负责提示 Claude 并判断下一步怎么做。我的工作，是写循环。”
两段话，数百万浏览，以及随之而来的巨大困惑——因为几乎没有人能说清楚"循环（Loop）"到底是什么。
随后，Google 工程师Addy Osmani发表了一篇博客，将这个概念正式命名为Loop Engineering，并给出了清晰的定义框架。
二、Loop Engineering 到底是什么？
2.1 一句话定义
Loop Engineering：你不再手动一轮一轮地给 AI Agent 写提示词，而是设计一套系统，让这套系统按目标、按计划，自动持续地驱动 Agent 工作，直到完成目标。
用更直白的比喻来说：
| 旧模式 | 新模式 |
|---|---|
| 你开车，手动转向、踩油门 | 你造了一辆自动驾驶汽车 |
| 你是 AI 的"驾驶员" | 你是 AI 系统的"工程师" |
| 每一步都需要你介入 | 你定义目标，系统自动跑到完成 |
2.2 核心机制：五步闭环
一个完整的 Loop 工程系统，会自动完成以下五个动作，不断循环：
┌─────────────────────────────────────────────────────┐ │ │ │ 发现工作 → 分配 Agent → 执行任务 │ │ ↑ ↓ │ │ 决定下一步 ← 持久化状态 ← 验证结果 │ │ │ └─────────────────────────────────────────────────────┘- Discover（发现工作）：主动扫描任务队列、PR 列表、Issue 面板等，找到需要处理的工作
- Assign（分配 Agent）：将任务分配给合适的子 Agent 或工具
- Act（执行）：Agent 实际运行、写代码、调用工具、修复 Bug
- Verify（验证结果）：检查输出是否达标，测试是否通过，目标是否满足
- Persist（持久化状态）：记录已完成的工作，保存上下文，供下一轮循环使用
如果验证不通过，Loop 会自动重试或调整策略，而不是等你来介入。
三、AI 交互范式的进化史
Loop Engineering 不是凭空出现的，它是 AI 开发方法论自然演进的结果。
第一阶段：Prompt Engineering（~2024）
核心关注点：如何问出一个好问题
- 你写一条精心设计的提示词
- AI 给出一次回答
- 你根据结果再写下一条提示词
- 瓶颈：你是整个流程的瓶颈，每一步都需要人工干预
第二阶段：Context Engineering（2025）
核心关注点：设计 AI 看到的整个"信息环境"
- 不再只关注单条提示词的质量
- 开始系统性地设计 System Prompt、Memory、Tool 定义、历史记录
- Anthropic 将其定义为"Prompt Engineering 的自然进化"
- 瓶颈：仍然是单次运行，不具备自主持续运行的能力
第三阶段：Harness Engineering（2025~2026初）
核心关注点：为单次 Agent 运行配好所有装备
- 给 Agent 配置工具集、文件权限、沙箱环境
- 相当于"准备好工作台"，但 Agent 跑完一次就结束了
- 瓶颈：Harness 装备的是单次执行，不是持续自主运行
第四阶段：Loop Engineering（2026）
核心关注点：设计替代"你"的自动驱动系统
- Agent 不再是你调用一次就结束的工具
- 而是在一个循环系统中自主发现工作、执行、验证、迭代
- 你的角色从"操作者"变成"系统设计者"
Prompt Engineering ↓ Context Engineering ↓ Harness Engineering ↓ Loop Engineering ← 我们现在在这里四、Loop 的类型与结构
4.1 最简单的 Loop 是什么样的？
从技术视角看，一个 Loop 的核心极其简单：
# 伪代码：最简 Loop 结构whilenotgoal_met(state):work=discover_work(state)result=agent.execute(work)verified=verify(result)state=persist(state,verified)ifneeds_human_review(result):notify_human_and_pause()就是for-loop+LLM call+结果验证。正如一位开发者犀利地评论：
“我今年发布的每个 AI Agent 都是一个 for 循环、一次 LLM 调用，加上 JSON 解析外面套一个 try/catch。唯一算得上’智能’的，是月底的 Anthropic 账单。”
Loop 的神奇之处不在于循环本身，而在于你怎么设计循环体里的决策逻辑，让它不会"跑偏"。
4.2 调度触发方式
| 触发类型 | 说明 | 适用场景 |
|---|---|---|
| 定时触发（Cron） | 每隔 N 分钟/小时执行一次 | 定期巡检、PR 监控 |
| 事件触发 | 收到新 Issue/PR/消息时触发 | CI/CD 集成、Webhook |
| 目标驱动 | 设定完成条件，达成即停 | 复杂编码任务 |
| 递归触发 | 每次执行结果决定是否继续 | 探索性任务 |
4.3 Claude Code 的原生 Loop 支持
/goal命令（Claude Code v2.1.139，2026年5月发布）：
/goal"将所有 API 接口迁移到新版 SDK，确保测试全部通过"Claude 会自动：
- 跨多轮持续工作
- 每轮结束后由独立评估模型检查目标是否达成
- 追踪已消耗的时间、对话轮数和 Token 数量
- 达成目标才停止，否则继续迭代
Boris Cherny 分享的入门实战案例：
/loop babysit all my PRs. Auto-fix build issues, and when comments come in, use a worktree agent to fix them.翻译：让 Claude 持续监控我所有的 PR，自动修复 build 报错，有人评论就开一个独立的 worktree Agent 去处理。
五、一个完整的实战 Loop 示例
场景：自动化代码审查与修复系统
┌──────────────────────────────────────────────────────┐ │ Loop 控制器 │ │ 触发条件：每30分钟 OR 新PR创建事件 │ └────────────────────────┬─────────────────────────────┘ │ ↓ ┌──────────────────────┐ │ 发现工作 │ │ 扫描所有 open PR │ │ 过滤出需要处理的 │ └──────────┬───────────┘ │ ↓ ┌──────────────────────┐ │ 分配子 Agent │ │ 每个PR → 独立 │ │ worktree Agent │ └──────────┬───────────┘ │ ↓ ┌──────────────────────┐ │ 执行 │ │ ① 读取PR变更 │ │ ② 运行测试 │ │ ③ 分析失败原因 │ │ ④ 编写修复代码 │ └──────────┬───────────┘ │ ↓ ┌──────────────────────┐ │ 验证 │ │ 测试全通过？ │ │ 代码风格合规？ │ └──────────┬───────────┘ ✓ │ ✗ ┌──────────┼──────────────┐ ↓ ↓ 提交修复 Commit 重试（最多3次） 更新 PR 描述 OR 标记需人工介入 │ ↓ 持久化状态 记录本次处理结果 等待下一轮触发六、Loop Engineering 的核心挑战
Loop 很强大，但也带来了新的工程挑战：
6.1 "认知债务"问题
这是目前最被低估的风险。
“Loop 发了修复，但不等于你理解它怎么修的。”
— Addy Osmani
当 Loop 替你写了成百上千行代码，你可能逐渐失去对代码库的理解。Loop 是杠杆，不是替代你判断力的工具。建议：
- 定期 Review Loop 提交的变更，而不只是看测试是否通过
- 保留关键模块的 “人工理解” 义务
- Loop 可以跑，但工程师需要保持 “我还能接管” 的能力
6.2 Loop 失控与成本爆炸
Uber 在2026年6月的教训：AI 工具的预算在4个月内耗尽了全年额度，随后对每人每工具设置了月度上限。
防护措施：
# 必须设置的安全边界loop_config={"max_turns":20,# 最大轮次"max_tokens":100_000,# Token 上限"timeout_minutes":60,# 超时强制停止"require_human_review":[# 这些操作必须人工确认"delete_files","modify_production_config","send_external_requests"]}6.3 状态管理复杂度
多个 Loop 并行运行时，状态同步是核心难题。推荐使用：
- 独立 Git Worktree：每个 Agent 有自己的工作目录，共享 Git 历史
- 结构化状态存储：用数据库或文件记录每个任务的处理状态，避免重复处理
七、如何开始实践 Loop Engineering？
第一步：识别你的"重复手动循环"
找到你日常工作中，你在做的那些循环动作：
- 每天早上检查昨晚的 CI 结果？
- 每次有 PR 就手动跑代码审查？
- 每小时刷新一次日志看有没有报错？
这些都是 Loop Engineering 的候选场景。
第二步：从最简单的 Loop 开始
# Claude Code 最简入门/goal"运行所有测试，修复所有失败的测试，直到测试全部通过"不需要复杂的架构，一个目标 + 一个 Agent + 一个验证条件，就是你的第一个 Loop。
第三步：逐步添加复杂度
在简单 Loop 跑通之后，再考虑：
- 加入定时调度（Cron）
- 加入事件触发（Webhook）
- 拆分为多个专注子 Agent
- 加入状态持久化
第四步：建立监控和干预机制
Loop 需要可观测性：
- Trace 日志：记录每次 Loop 的执行路径
- 人工干预钩子：超过阈值时自动暂停并通知
- 回滚机制：Loop 出问题时能快速撤销
八、与旧范式的本质区别
| 维度 | Prompt Engineering | Loop Engineering |
|---|---|---|
| 执行主体 | 你 | 系统 |
| 执行节奏 | 你一问它一答 | 自主持续运行 |
| 失败处理 | 你看结果、重写提示词 | 自动重试、自动调整 |
| 核心技能 | 如何写出好的提示词 | 如何设计可靠的自动化系统 |
| 工程复杂度 | 低 | 高（需要设计状态管理、验证逻辑、安全边界） |
| 潜在收益 | 提升单次交互质量 | 真正的自动化、24小时无人值守运行 |
九、总结
Loop Engineering 代表了 AI 编程范式的一次重要跃迁。它的本质是：
把你从"AI 操作员"升级为"AI 系统设计师"。
你不再需要坐在屏幕前，一轮一轮地喂给 AI 提示词。你设计一套系统，定义好目标和验证条件，然后让系统替你驱动 AI 工作，直到完成。
但这也意味着新的责任：
- 你需要设计更好的系统，而不只是写更好的提示词
- 你需要保持对代码的理解，不能让 Loop 造成"认知债务"
- 你需要建立安全边界，防止 Loop 失控或成本爆炸
Loop 是杠杆，不是替代品。工程师需要保持判断力，Loop 的价值在于解放你的时间，让你专注于更高层次的系统设计。
参考资料
- Boris Cherny, Anthropic Claude Code — Acquired Unplugged (WorkOS, June 2, 2026)
- Peter Steinberger (@steipete) — X, June 7, 2026
- Addy Osmani (Google) — “Loop Engineering” Blog Post, June 8, 2026
- MindStudio — “What Is Loop Engineering? The New Meta for AI Coding Agents”
- Data Science Dojo — “Agentic Loops: From ReAct to Loop Engineering (2026 Guide)”
- Lushbinary — “Loop Engineering: The Guide for AI Agents”
