2026年6月，AI圈被一个词刷屏了：Loop Engineering（循环工程）。
事情的起因很简单。6月7日，OpenClaw项目的作者 Peter Steinberger 发了一条帖子，大意是：别再琢磨怎么给AI编程助手写更精妙的提示词了，真正值钱的本事，是设计一个能自动替你写提示词的系统。
这条帖子像一颗深水炸弹，6天之内收获了650万次浏览，直接把整个AI开发者社区炸开了锅。
第二天，Google 工程师 Addy Osmani 趁热打铁，发了一篇长文《Loop Engineering》，给这股浪潮起了名字，还拆解出了完整的架构骨架：自动化触发、工作树隔离、技能封装、外部系统连接、子智能体委派、持久化状态……
紧接着，Anthropic 负责 Claude Code 的 Boris Cherny 说了四个字，把这场讨论推向了高潮：
“I don’t prompt Claude anymore.”
“我已经不再手动提示 Claude 了。”
连造 AI 编程工具的人自己都不写提示词了，这说明什么？范式变了。
一、所以，循环工程到底是什么？
用一句话说：循环工程，就是设计一个能自动提示、检查、记忆、重新运行 AI 智能体的系统——你不再亲自在对话框里打字，而是去造一台替你打字、替你检查、替你迭代的机器。
旧世界的玩法：你打开 Claude Code，输入"帮我写一个用户登录模块"，等它吐代码，复制粘贴，跑测试，报错，再复制错误信息贴回去，来来回回，一整个下午过去了。
新世界的玩法：你丢给它一个目标——“让 payments-refactor 分支的 CI 变绿”——然后去睡觉。智能体自己拉代码、跑测试、读报错、定位问题、修bug、再跑测试、再修……循环往复，直到 CI 绿了，自动给你开一个 PR。你早上醒来，喝着咖啡审代码就行了。
本质区别在哪？
技能栈变了：从"写好一句话"变成了"设计好一个闭环系统"。这就是为什么它叫"工程"——不是写作，是系统工程。
二、事情不是一夜之间发生的：四层进化简史
循环工程不是凭空冒出来的。它其实是 AI 人机协作方式持续"向外迁移"的第四站。每一层都包裹着前一层，而不是取代它。
第一层：提示工程（2022-2024）
“你是一个资深Python工程师，请用FastAPI帮我写一个REST API……”
这是所有人入门AI的第一课。给模型定角色、拆步骤、给示例、让它Chain-of-Thought。玩的是措辞的艺术。但天花板也很明显——一个措辞完美的提示词，依然无法给模型它从未见过的事实。
第二层：上下文工程（2025）
“重要的不是你说的那句话，而是模型在那一刻看到的所有东西。”
2025年6月，Shopify CEO Tobi Lütke 给出了一个经典定义：上下文工程就是确保模型在推理时，能拿到解决当前任务所需的一切信息。 Andrej Karpathy 则把它形容为"用刚好正确的信息填满上下文窗口的微妙艺术"。
对话历史、检索到的文档、工具调用的输出、智能体的状态快照——这些才是上下文工程真正关心的东西。提示工程从此变成了上下文工程的一个子集。
第三层：脚手架工程（2026）
“光有聪明的模型不够，你得给它一个靠谱的环境。”
当 AI 智能体开始在生产环境里自主干活时，人们发现了一个新问题：模型本身很聪明，但一跑起来就各种掉链子——文件权限不对、环境变量缺失、依赖冲突、两个并行智能体互相踩文件……
脚手架工程（Harness Engineering）就是解决这个问题的。它在智能体周围搭建一整套"脚手架"：沙箱环境、工具接口、权限边界、反馈回路。让智能体从"聪明"变成"可靠"。
第四层：循环工程（2026）
“脚手架搭好了，但真正让智能体自主干活的，是那个迭代循环。”
循环工程是脚手架工程中最核心的那一部分——控制循环。它回答的不是"智能体需要什么环境？“，而是"什么样的循环能让智能体持续朝着目标前进？什么时候该停下来？”
它的理论祖先可以追溯到2022年普林斯顿和Google的 ReAct 模式（Reason + Act），核心发现是：一个在每次行动后观察结果再决定下一步的模型，和一次性回答的模型，行为模式完全不同。
三、一个好循环长什么样？拆解给你看
一个能无人值守跑一个小时的循环，需要的远不止一个目标和一台模型。下面是2026年实战中反复验证过的"标准配置"：
🔧 五大核心组件
🧩 Addy Osmani 的六块拼图
Google 工程师 Addy Osmani 在命名循环工程的同时，给出了一个更系统的架构框架：
● 自动化（Automations）：定时触发或事件驱动的启动机制
● 工作树（Worktrees）：每个智能体在自己的Git分支上干活，互不干扰
● 技能（Skills）：把可复用的能力打包成插件，随用随装
● 连接器（Connectors）：对接外部API、数据库、消息队列
● 子智能体（Sub-agents）：大任务拆小，分给多个AI并行处理
● 外部状态（External State）：跨运行持久化记忆，这次失败的经验下次能用
实际使用的节奏也很务实：先搞一个单验证循环跑通，等稳定了再加并行工作树。 别一上来就上全套。
四、循环的本质：一段伪代码就看懂了
剥掉所有花里胡哨的概念，一个智能体循环本质上就是一个控制循环——它更像一个恒温器，或者一个REPL（Read-Eval-Print Loop），而不是聊天框。
state = init_state(goal) # 初始化：目标 + 草稿板
for step in range(MAX_STEPS): # 硬上限，防止无限循环
thought = model.reason(state) # 第一步：推理，分析当前状态
action = model.choose_action(state) # 第二步：决策，选一个工具调用
result = tools.execute(action) # 第三步：执行，触及真实环境
state = update(state, thought, action, result)
state = compact(state) # 第四步：压缩，别让上下文爆掉
if verifier.passes(state): # 验证通过？→ 成功退出
return success(state)
if no_progress(state) or budget.exhausted():
return escalate_to_human(state) # 卡住了？→ 交还人类处理
return escalate_to_human(state) # 步骤耗尽 → 交还人类
就这十几行代码，已经是所有生产级循环的骨架。循环工程中90%的"工程"，都藏在这几个关键决策里：
● verifier.passes 怎么定义？—— 测试全绿？编译通过？还是LLM自己说"我觉得没问题"？
● compact 怎么压缩？—— 摘要旧步骤？丢弃工具输出？还是写入外部文件按需回读？
● no_progress 怎么检测？—— 连续三步结果一样？还是错误信息没变？
● tools 里放了什么？—— 给太多权限会出事，给太少干不了活
模型是中间那个固定的黑盒，工程在它周围。
五、一个真实的循环是怎么跑的
说一千道一万，不如看一个真实场景。假设你的任务是：把 payments-refactor 分支的 CI 弄绿。
旧做法：人肉循环
1. 手动跑测试 → 看到报错
2. 复制报错 → 粘贴到Claude Code
3. Claude给出修复 → 复制到编辑器
4. 再跑测试 → 又报错
5. 再复制报错 → 再粘贴……
6. 重复1小时，咖啡喝了三杯，人快疯了
新做法：循环工程
1. 设定目标："CI 全绿"，设定边界：最多改支付模块，别碰其他代码
2. 给智能体开一个独立的 git worktree，互不干扰
3. 给工具：终端、pytest、mypy、ruff
4. 启动循环 →
第1轮：读第一个失败测试 → 定位到 PaymentGateway.validate() → 修 → 跑测试 → 还红
第2轮：读新的失败 → 发现是 import 路径写错了 → 修 → 跑测试 → 绿了
第3轮：跑全量测试 + 类型检查 → 全绿 → 自动开PR → 停止
5. 额外机制：记录每次尝试，同一测试失败3次自动升级给你，不无限烧token
你早上起来看到的是一个已经开好的 PR，附带一条清晰的变更日志。 没有魔法，每一步都是精心设计的——目标、工具、记忆、停止条件。这种"精心设计"，就是"工程"二字的分量。
六、四种经典循环模式，选对的不选贵的
循环工程背后的学术积累，可以追溯到2022年。了解这些模式，能帮你少走弯路。
四种模式速查
① ReAct（推理+行动）— 一切循环的祖宗
2022年，Yao等人提出：让模型先推理再行动，行动后观察结果，再推理下一步。这个简单的交替模式，是所有现代智能体循环的基石。前面那段伪代码，本质上就是加了安全护栏的ReAct。
② Reflexion（反思）— 会从失败中学习的循环
2023年，Shinn等人在ReAct上加了两个东西：记忆 和 自我批判。每次失败后，智能体不只是重试，它会写一段"教训"（比如"上次失败是因为 import 路径写错了"），存进记忆，下次尝试时先读一遍。效果：单次会话内越跑越聪明，不需要重新训练模型。
③ 评估器-优化器 — 两个模型互相较劲
来自Anthropic的实践：一个模型负责生成，另一个模型负责打分。生成→评估→反馈→修改→评估→……直到评估通过。适合有明确验收标准的场景，比如"生成的代码必须通过所有单元测试"。
④ 编排器-工作器 — 组建一支AI舰队
也是Anthropic的实践：一个中央"编排器"把大任务拆成小任务，分发给多个"工作器"子智能体并行处理——每个子智能体有自己的独立上下文窗口，不会互相污染——最后汇总结果。这就是"在你睡觉时跑一队AI"的架构基础。
💡 一个来自实战团队的忠告
选最简单的能跑通的模式，别一上来就上重型框架。一个带确定性验证器的 ReAct 循环，胜过你调不通的豪华多智能体系统。
七、循环工程的"三座大山"
做循环工程，有三个坎绕不过去。跨过去了，循环能稳定跑一小时；跨不过去，它会溢出、鬼打墙、或者一本正经地撒谎。
⛰️ 第一座山：上下文管理
上下文窗口是智能体的"工作记忆"——相当于它的RAM，有硬上限。每一步都会追加思考、工具输出、错误信息，跑着跑着窗口就满了。更可怕的是 “上下文腐烂”：随着记录越来越长，模型对真正重要的东西的注意力越来越弱。
对策：
● 把旧步骤压缩成摘要，而不是保留全文
● 修剪过时的工具输出（三回合前的日志就别留着了）
● 把状态写到外部文件，让智能体按需回读
● 隔离子智能体：每个子任务在干净的上下文窗口里跑，只把结论传回来
⛰️ 第二座山：终止策略
一个没有终止策略的循环，就是一只没有刹车的高铁。它永远不会主动停下来。
健壮的循环至少需要四层"刹车"：
1. 验证器：目标达成了，停
2. 迭代上限：跑了100轮还没搞定，停
3. 预算上限：烧了50美元token还没结果，停
4. 无进展检测：最近三步什么都没变，说明在鬼打墙，停
⚠️ 终止策略不是"回头再说"的事，它是循环设计的一半。
⛰️ 第三座山：验证信号的可靠性
循环靠反馈来纠偏，如果反馈本身不可靠，循环就会朝着错误的方向"快速收敛"。
铁律：能用确定性验证的地方，绝不用模型判断。 一个测试跑不过就是跑不过，模型没法狡辩。
八、常见的循环翻车现场
踩过坑的人都知道，循环翻车的姿势就那么几种，提前知道能省一大笔API账单。
九、所以，循环工程到底改变了什么？
说白了，它改变了三件事：
第一：能力栈变了
以前，用AI编程的核心竞争力是"会写提示词"。现在模型自己都能写代码了，稀缺的能力变成了"设计一套能让模型持续正确产出的系统"。这是系统工程能力，不是文案能力——这也就是为什么大家管它叫"工程"。
第二：可靠性从"看运气"变成了"设计出来的"
一次性提示词，成不成功纯看脸。但一个每次行动后自动验证的循环，能把一个不稳定的生成器，变成一个持续收敛的可靠系统。 这和"验证优先"的原则一脉相承——凡是AI产出高风险结果的地方，这一套都管用。
第三：工作方式从"同步监工"变成了"异步放羊"
一个智能体在它自己的worktree里跑循环的时候，你可以同时跑好几个，然后一起审结果。"在你睡觉的时候跑AI"不是幻想，是已经发生的现实。 生产力的天花板，从"你打字有多快"变成了"你设计的循环有多聪明"。
十、别急着 all in：循环工程不是什么
新概念出来的时候，最容易过热。有几点需要清醒认识：
循环工程 ≠ 每个开发者明天都该搞个AI舰队。
一篇被广泛传播的反驳文章说得很好：大多数开发者现在还不需要智能体循环。 对于很多任务，打开Claude Code聊几句，比花半天搭一个完整循环快得多、也安全得多。
循环 ≠ 人不在循环里。
你依然拥有目标、定义"完成"的标准、判断输出是否正确的最终裁决权。一个优化了错误目标的循环，会以极高的效率做错误的事。没有真正的验证，一个更快的循环只是更快地产生错误答案。
真正的纪律是：在每个循环里，放一个真正的检查——测试、类型检查、或者人类审批。
十一、不止于编程：循环工程的思想如何迁移
虽然循环工程这个说法诞生于编程智能体的圈子，但它的核心思想——目标→行动→验证→重复——适用于任何可以被客观反馈检查的AI工作流。
举个简单的例子：把一份PDF转成PPT。
一次性做法的工具：你丢进去一个PDF，它吐出来一份PPT。排版乱七八糟，内容张冠李戴，数据对不上——但反正它"生成"了。
循环工程的做法：
1. 解析PDF，提取结构化内容
2. 生成大纲，规划幻灯片结构
3. 渲染初版幻灯片
4. 逐页对照原文检查：这个数字对吗？这个结论有出处吗？
5. 发现偏差→修正→重新检查
6. 直到所有幻灯片都通过验证
前者是"聊天框时代"的幻灯片工具，后者是"循环工程时代"的幻灯片工具。价值不在一次生成，在于一个能保持输出正确的闭环。
十二、常见问题速答
Q: 用最简单的话说，循环工程是什么？
A: 你不再手动一句句地提示AI，而是设计一个"行动→检查→决策→再行动"的自动循环，让AI自己跑，直到完成目标或遇到问题。
Q: 谁发明的这个词？
A: 2026年6月，两条线汇合。Peter Steinberger 先提出"真正的技能是设计循环，不是写提示词"；第二天 Google 的 Addy Osmani 给这个实践起了名字，并拆解了完整架构。
Q: 循环工程和提示工程、上下文工程是什么关系？
A: 不是替代，是叠加。提示工程管"说得好"，上下文工程管"看得全"，脚手架工程管"环境稳"，循环工程管"跑得对"。一层包一层，缺一不可。
Q: 我现在就需要学循环工程吗？
A: 不一定。如果你的工作是一次性的、交互式的，用Claude Code或Codex直接聊更快。循环工程适合： 重复性任务、长时间运行的任务、需要无人值守的任务——并且你能明确定义"什么叫做好了"。
Q: ReAct和Reflexion有什么区别？
A: ReAct（2022）是基础款：推理→行动→观察→再推理。Reflexion（2023）是进阶款：失败后会写"教训"存进记忆，下次尝试时先读一遍，在单次会话内越变越聪明。一个是单次循环，一个是会学习的循环。
Q: 怎么防止循环跑飞了？
A: 四道防线：验证器（目标达成→停）、迭代上限（跑N轮→停）、预算上限（烧X美元→停）、无进展检测（鬼打墙→停）。没有终止逻辑的循环，是新手最容易犯的也是最贵的错。
总结：一张图看懂循环工程
大模型应用课程，期待您的加入
|
|