硅谷大佬都在聊的 Loop Engineering：到底在卷什么？

最近几天，硅谷 AI 圈最火的关键词不是 Harness，也不是 Agent Skills，而是一个新概念：

Loop Engineering（循环工程）

短短几天内，OpenAI、Anthropic 两位核心技术负责人几乎同时提到了同一个观点：

这可能意味着 AI Coding 的工作方式正在发生新一轮变化。

---

从 Prompt Engineering 到 Loop Engineering

6 月 7 日，OpenAI 工程师、OpenClaw 创始人 Peter Steinberger 发了一条推文：

翻译过来：

6 月 2 日，Claude Code 缔造者 Boris Cherny 在访谈中也表达了类似观点：

意思是：

两位业内核心人物同时提到同一个方向，这通常意味着某种趋势已经开始形成。

---

从 Prompt 到 Loop：我们到底在跃迁什么？

先聊最根本的问题：为什么突然要搞 Loop？

答案很现实：人成了新的瓶颈。

相信天天用 Claude Code、Cursor 的同学都有体感：现在模型写代码的速度，早就超过你读代码、审代码的速度了。你写一条 Prompt，它 30 秒输出两百行代码，你得花 5 分钟去查有没有坑。模型越快，你越累，最后你反而成了整个流程里最慢的那个环节。

过去的范式叫「人在环中（Human-in-the-loop）」：人写提示词、人审查输出、人调整指令、人推进进度。模型能力弱的时候，人盯着是必须的，整个工作流程是这样的：

人在整个流程中始终处于核心位置。但当模型输出能力已经远超人类处理速度，这套模式就走不通了。 于是整个行业的抽象层级，开始一步步向上跃迁：

AI 工程范式的四次升级

很多人把 AI 开发的发展过程总结成四个阶段：

• Prompt Engineering：琢磨怎么把一句话说精准，让模型听懂需求

• Context Engineering：琢磨怎么喂对上下文，减少模型胡说八道

• Harness Engineering：琢磨怎么搭工具链、加护栏，让模型能真实落地干活

• Loop Engineering：琢磨怎么设计自运转闭环，让系统自己迭代，人站在循环之外

---

什么是 Loop Engineering

可以这么理解：

传统模式：

人写 Prompt
 ↓
AI 输出
 ↓
人检查
 ↓
继续 Prompt

Loop 模式：

人设计规则
 ↓
Loop运行
 ↓
Agent执行
 ↓
自动检查
 ↓
失败反馈
 ↓
再次执行
 ↓
直到完成

开发者不再亲自参与每一次交互。

而是站在循环之外，负责设计规则。

---

Loop 本质是什么

即：

缺一个都不完整。

---

一个完整 Loop 的六层结构

Chrome 团队曾经将现代 Agent Loop 拆解成：

五个构建模块 + 一个记忆层

1. Automations（自动化）

负责触发循环。

例如：

• 定时检查 Issue
• 定时跑测试
• 定时生成 PR
• 定时分析日志

Claude Code 中：

/loop 、 /schedule、 Hooks、 Github Actions

Codex 中：

Automations、 Triage Inbox

作用：让任务持续运行 而不是执行一次就结束。

2. Worktree（工作树隔离）

多个 Agent 同时工作时最大的风险：

修改同一个文件，最终出现冲突。

所以需要：

Agent A
   ↓
Worktree AAgent B
   ↓
Worktree B

相互隔离。

避免互相覆盖代码。

3. Skills（技能库）

很多团队每天都在重复解释同样的事情：

• 我们的项目使用 NestJS
• 统一使用 Prisma
• 提交规范遵循 Conventional Commit

这些内容其实应该沉淀。

例如：

.claude/skills

.codex/skills

把项目规则变成技能。

后续所有 Agent 都能直接复用。

4. Plugins / Connectors

Agent 光会写代码没用，得能对接真实的工作流。能提 PR、能改工单、能发通知、能查数据库、能跑 CI，这才叫能干活的 Agent。

这一层就是 Loop 的「连接器」，让 Agent 能触达真实的开发工具链。现在的行业标准是 MCP 协议，Claude Code 和 Codex 都在全面支持。

Agent
 ↓
MCP
 ↓
各种工具

让 Agent 真正拥有执行能力。

5. Sub Agents

很多人犯的错误：

同一个 Agent 既写代码 又验代码

结果：

自己给自己打满分

正确方式：

所以必须做分工：写代码的是 maker，查问题的是 checker，各司其职，互相校验。把一个大任务拆成多个小角色，流水线作业，既专业，又能避免「自产自销」的闭环失效。

职责拆分。

互相制衡。

6. Memory（记忆层）

这是最容易被忽略的一层。

很多人以为：模型有上下文，就有记忆。

其实不是。

模型每次都会遗忘。

真正的记忆来自：

Markdown、Issue、数据库、看板、文档

只要信息存在仓库里。

下一轮循环就能重新读取。

---

如何设计一个真正可运行的 Loop

很多 Agent 项目失败，不是模型不够强。

而是 Loop 没设计好。

下面是最重要的五个步骤。

Step 1：设计停止条件（Defining 'Done'）

在让 Agent 跑起来之前，先问自己：Loop 怎么知道自己把活干完了？

如果无法用代码明确表达 “Done”，Agent 要么会化身“无情刷卡机”死循环下去，要么会过早放弃。常见的停止条件包括：

• 所有自动化测试全部通过（Green CI）
• 输出严格匹配指定的 JSON Schema
• 代码审计评分超过特定阈值
• GitLab/GitHub Pipeline 变成绿色

Step 2：构建 Context，而非手写指令

在循环中，每一轮的 Prompt 都不是固定的，而是根据当前状态（State）动态组装出来的。状态在移动，Context 随之更新，确保大模型始终能看到最新的“战况”。

Step 3：执行并捕获一切

Agent 行动之后，系统必须充当完美的监控器，疯狂抓取：代码的 diff、stdout / stderr、测试日志以及系统新状态。记住，失败不是终点，报错信息是下一轮 Prompt 最好的原材料。

Step 4：用反馈闭合循环（Feedback Loop）

分支走向：

• 成功 $\to$ 满足停止条件，退出循环，交付任务。
• 失败 $\to$ 将报错和失败写入 State，下一轮 build_prompt 自动吃进这个报错。Agent 用上一轮的失败来提示自己，完成自我喂养。

Step 5：设置坚固的护栏（Guardrails）

没有出口的 Loop 不是系统，那是你的破产账单。必须死死卡住三个上限：

1. 最大迭代次数： 通常严格限制在 15-50 次之间。
2. 无进展检测： 如果发现连续几轮生成的 fingerprint（指纹）或 Tool Call 完全一样，说明 Agent 陷入了鬼打墙，立刻强杀。
3. Token 预算上限： 超过设定金额直接熔断。

---

Loop 最大的成本陷阱

很多人刚上手 Loop，发现 Token 蹭蹭涨，效果还拉胯，大概率是踩了下面这些坑：

• 没做停止检查：无限循环，账单直接起飞
• 人还在环里：手动喂错误、改 Prompt，那不叫 Loop，叫你自己当循环引擎
• 丢弃失败输出：报错不存，下一轮还是从零开始，反复踩同一个坑
• 不加护栏：纯纯给云厂商打工
• 自产自销：写代码和验证是同一个 Agent，永远给自己打满分，循环等于摆设
• 不用 Skill：每次都重新讲项目规范，重复烧钱，输出还不稳定
• 上下文无限膨胀：每轮都把全量历史塞进去，到后面 Agent 连最初要干啥都忘了

优化思路

对应的优化思路也很明确，都是硅谷一线团队踩坑踩出来的经验：

• 协调者只做路由不做推理，窄上下文 = 少 Token
• 中间结果存在脚本变量里，别每轮都回传给协调者，避免上下文线性增长
• 每个子 Agent 只给它需要的文件，别把整个仓库都塞过去
• 短期记忆只留最近 3-5 轮，旧的直接落盘存文件
• 用心跳 + 随机抖动代替不间断运行，比如每 30 分钟左右伪随机唤醒一次，不用 24 小时连轴转
• 3-7 个 Agent 是黄金数量，太多就分层级，扁平堆 20 多个纯纯浪费资源

---

结语

其实回头看，Loop Engineering 一点都不玄乎。

软件工程几十年的发展史，本质就是不断提升抽象层级的历史：从机器码到高级语言，从手写代码到 IDE 补全，从 Copilot 到 Agent，再到今天的 Loop。我们一直在把重复的、机械的工作交给机器，把人解放出来去做更顶层的设计。

它不是要取代开发者，而是在重新定义开发者的工作。

以后你不用再纠结 Prompt 写得够不够精准，不用再守着屏幕等 Agent 输出，不用再一条条审查代码。你要做的，是设计好规则、搭好闭环、设好护栏，让系统自己去迭代。

毕竟，真正的效率革命，从来都是让人从循环里跳出来。