最近几天，硅谷 AI 圈最火的关键词不是 Harness，也不是 Agent Skills，而是一个新概念：
Loop Engineering（循环工程）
短短几天内，OpenAI、Anthropic 两位核心技术负责人几乎同时提到了同一个观点：
不要再给 AI 写 Prompt 了，而是去设计 Loop。
这可能意味着 AI Coding 的工作方式正在发生新一轮变化。
从 Prompt Engineering 到 Loop Engineering
6 月 7 日，OpenAI 工程师、OpenClaw 创始人 Peter Steinberger 发了一条推文：
翻译过来：
不要再亲自给 Coding Agent 写提示词了。
你应该设计循环，由循环去给 Agent 写提示词。
6 月 2 日，Claude Code 缔造者 Boris Cherny 在访谈中也表达了类似观点：
I don't prompt Claude anymore.
I have loops that are running.
My job is to write loops.
意思是：
我已经不再直接给 Claude 写 Prompt。
我有一些持续运行的循环，它们会自动决定下一步做什么。
我的工作变成了设计这些循环。
两位业内核心人物同时提到同一个方向，这通常意味着某种趋势已经开始形成。
从 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
可以这么理解：
Loop Engineering 就是设计一个能够自我迭代、自我反馈、自我修正的 Agent 工作闭环。
传统模式：
人写 Prompt
↓
AI 输出
↓
人检查
↓
继续 Prompt
Loop 模式：
人设计规则
↓
Loop运行
↓
Agent执行
↓
自动检查
↓
失败反馈
↓
再次执行
↓
直到完成
开发者不再亲自参与每一次交互。
而是站在循环之外，负责设计规则。
Loop 本质是什么
Loop = Cron + Decision-maker + Feedback + Guardrails。
即：
定时器+决策器+反馈系统+安全护栏
缺一个都不完整。
一个完整 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 A
Agent 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）
分支走向：
- 成功 满足停止条件，退出循环，交付任务。
- 失败 将报错和失败写入 State，下一轮
build_prompt自动吃进这个报错。Agent 用上一轮的失败来提示自己，完成自我喂养。
Step 5：设置坚固的护栏（Guardrails）
没有出口的 Loop 不是系统，那是你的破产账单。必须死死卡住三个上限：
- 最大迭代次数： 通常严格限制在 15-50 次之间。
- 无进展检测： 如果发现连续几轮生成的
fingerprint（指纹）或 Tool Call 完全一样，说明 Agent 陷入了鬼打墙，立刻强杀。 - 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 输出，不用再一条条审查代码。你要做的，是设计好规则、搭好闭环、设好护栏，让系统自己去迭代。
毕竟，真正的效率革命，从来都是让人从循环里跳出来。
