2026 年 6 月，一个新词热门了起来：Loop Engineering（循环工程）。
它的核心主张听起来近乎挑衅——你不该再亲自给 AI 写提示词了。
事情的引爆点是 OpenClaw 的作者 Peter Steinberger，发布的八百万人阅读的一条推文：你不应该再亲自给编程 Agent 写提示词了，你应该去设计那个驱动 Agent 的循环。
几乎同一时刻，Claude Code 负责人 Boris Cherny 也在公开场合表示：
他自己已经不再亲自给 Claude 写提示词了，而是让一堆循环跑着，这些循环会自己提示 Claude、自己判断该做什么，而他的工作就是写循环。
6 月 7 日，Google 工程师 Addy Osmani 在博客里给这件事正式起了个名字Loop Engineering。
随后，Anthropic 的工程师把这套实践写成了一份完整的手册：
https://drive.google.com/file/d/1qzKI4DKnyHRpXK1J3ATPqwaqLc0iNu-M/view?pli=1
我们把手册里最有价值的部分整理成了这篇文章：
读完你大概会明白，为什么一线工程师正在从「写提示词的人」，变成「设计循环的人」～！
什么是循环工程
过去两年，AI 圈冒出了一堆 XX 工程。
先是提示词工程，教你怎么把一句提示写好；后来是上下文工程，研究该往模型的窗口里放什么、删什么；再后来是 Harness 工程，关心一次 Agent 运行该带哪些工具、什么状态算完成。
但循环工程切入的角度，不太一样。
提示词工程、上下文工程、Harness 工程背后，本质都在讲同一件事：如何通过工程的方式，给 AI 提供最合适的输入。它们默认都有一个人坐在键盘前，一行一行指挥 Agent。
但循环工程把这个人从位置上删掉了：
你不再身处循环之内，而是站在循环之外，去构建那个循环本身。
也就是说，你写的东西，不再是给 Agent 的提示词，而是一个会自动向 Agent 发提示词的系统。你也从那个写提示词的人，变成了设计让 AI 自动写提示词的人。
把这四个工程放在一起，可以用一个金字塔来理解：从下往上，每一层关心的东西都比下一层大一圈。
最底下是提示词工程，关心一句话该怎么说。往上是上下文工程，关心一个窗口里该装什么。再往上是 Harness 工程，关心一次运行该带什么工具、怎么从失败里恢复。
而最上面是最重要的循环工程：关心怎么让这一切一遍又一遍自己跑起来。
在循环工程的新世界里，设计的系统会自己运转：它被定时任务唤醒，在循环里生成子 Agent 去干活，再把这一轮的结果喂给下一轮。
那么，为什么这个词偏偏在这个时候冒出来？
这是因为，过去半年围绕 Agent 的工具悄悄跨过了一个临界点：
模型和编程 Agent 已经足够可靠，能在没人盯着的情况下完成一件完整的任务；
单次跑一个 Agent 的成本降得足够低，所以反复按定时器跑任务不再显得浪费；
定时调度这种能力也进了主流工具，定时让 Agent 按照循环执行任务变得可能。
所以当零件都到位了，把它们拼起来这个动作，自然就同时在很多人脑子里冒了出来。
而名字总是滞后于实践几个月：在有人喊它循环工程之前，前沿的工程师们早就在写循环啦。
如何搭建循环工程
说到循环这个词，很容易让人误会成空转，但其实它每转一圈都在做具体的事。
具体的，Anthropic 的手册把循环拆成了五个动作：
1、发现：自己找出这一轮值得做的活；
2、交接：把任务移交出去，并且互相隔离；
3、验证：引入另一个 Agent 来说不；
4、持久化：把状态写到对话之外的地方；
5、调度：让它一轮接一轮地转下去。
这五个动作里少了任何一个，循环要么转不动，要么在原地打转。
这里有一个很好的例子，Osmani 用这套流程给自己搭建了晨间分诊循环：
每天早上，他会启动一个自动化定时任务，读取昨天失败的 CI 测试、还开着的 issue、最近的提交，然后 AI 会把值得处理的东西写进一个 Markdown 文件。
对每一项，循环工程开一个独立的 git 工作树：一个子 Agent 起草修复，第二个子 Agent 对照测试审查，然后自动开 PR、更新工单。针对循环工程无法处理的内容，会把它发到收件箱等人处理，与此同时，状态文件会保留，第二天等人确认好了接着干。
整个循环过程，全程不用人插手，但它会在恰好该等人的地方停下来。
手册也给出了这个例子和循环工程五个动作的对应关系：
搭建循环工程的关键
如果要从这份手册里挑出最值钱的一段，那就是关于「验证」的部分。
Anthropic 的工程师 Rajasekaran，他在做长时间运行的应用时发现了一个现象：让一个 Agent 给自己刚写出来的东西打分，它几乎总是信心满满地夸自己，但是人一眼就看出来质量很平庸。
为什么会这样呢？
因为代码被写出来的时候，Agent 的上下文里已经塞满了「为什么要这么写」的理由，所以它回头看自己的输出时，看到的不是结果，而是那条说服自己的链条。
而这个问题，「循环工程里，会被无限放大：如果每一次「这够好了吗」都由刚写完的那个 Agent 来决定，它每一轮都会对自己的判断认同，跑得越久，就会导致整体输出的质量变得很差。
Rajasekaran 试过让生成器对自己更严厉，效果很差。后来他换了思路，调教一个独立的评估器去怀疑一切，反而容易得多。
这里的核心思路是：你没法要求一个 Agent 跳出自己的视角，但你可以换一个 Agent 进来，因为它会带着完全不同的指令，从零审视这段代码。这个原则在银行业也有一个名字，叫制衡原则：几十年前银行就规定，录入一笔大额转账的人和审核这笔转账的人必须是两个人。
关于评估，社区里还有一个常用的校准方法：直接告诉评估器，默认假设这段代码是坏的，直到它被证明没问题。
与此同时，仅仅使用一个独立的评估器还不够，还需要让它使用合适的工具进行评估：
如果评估器只读代码，它判断的是「这看起来对吗」，不是「它跑起来对吗」。所以这里还要引入真正的代码：在前端任务里，Rajasekaran 把评估器接到了 Playwright，让它能真的打开页面、点按钮、截图、检查 DOM，像个 QA 工程师那样干活。
Claude Code 把这套生成、评估的结构变成了一个叫 /goal 的命令，给 Agent 一个停止条件，让它一直跑到满足为止，而且由一个全新的小模型来判断条件成不成立，不是干活的那个模型说了算。
如果用一句话总结这部分，那就是：
让生成器决定循环能产出什么，让评估器决定它不会产出什么。
这也是为什么说评估是做好循环工程的关键：评估器，决定了循环工程的下限。
循环工程的最佳实践和建议
此外，手册里提到了关于循环工程的一些最佳实践：
第一个经验：该让模型自动触发什么。
回到前面那个 Osmani 的晨间分诊的案例，这里有一个值得注意的细节：
自动化触发的应该是一个技能，而不是一堆没人在意的指令。因为技能可以复用、可以维护。
第二个经验，是什么可以信任模型，什么不可以。
这里要提到 Stripe 的 Minions：他每周合并超过 1300 个 PR，但没有一行是手写的。他的循环工程的触发很轻量：在 Slack 里 @ 一下机器人，或者加个 emoji 反应就行。
这里，他让模型稳定运行的关键是：能硬编码解决的事，就绝不交给模型。
所以他从来不让 LLM 自己去找上下文，因为模型不可控。Stripe 的做法是，在模型被定时任务触发之前，先用一段确定性的编排逻辑把上下文组装好：扫链接、拉 Jira、查文档、定位相关代码。
此外，他还有一个核心习惯：最关键的判断工作，绝不能交给模型，所以这 1300 个 PR 仍然是由人来审。
第三个经验：如何让循环真正在你睡觉时还在跑。
很多人以为本地反复跑 /loop 就等于让循环替自己值夜班。但本地循环需要机器一直开着，你合上笔记本盖子，它就停了。
所以如果你要循环工程真正可以在你睡觉时跑，你得用云端的定时调度或者 GitHub Actions。
第四个经验，注意循环工程带来的隐形成本：循环越好用，越危险。
为什么呢？因为循环跑得越爽，犯的错越不容易发现，有四笔隐形账单它在运行时绝不会提醒你。
第一种是验证债务。每个AI 生成的、被合并的 PR 都省了你的时间，但这个省下来的时间，往往变成了一堆没人验证的代码，可能会在某一天就成为线上的超级 Bug。如何避免呢？建议定期复盘 AI 生成的内容。
第二种是用进废退。你越习惯用 AI 写代码，你就越不擅长自己写代码。如何避免呢？每天读一个有代表性的代码，逼自己练习。
第三种是认知投降。循环工程越可靠，你越容易放弃自己的判断：它生成什么，你就用什么。针对这个问题，建议是给自己留一条底线：循环可以帮你执行任务，但不能替你做决策。
第四种是 Token 爆炸。循环一轮轮跑确实会产生不少的消耗，尤其是一些意外情况：比如一个 bug 就能空转一整夜，那么第二天，你收到的就不是修好的代码，而是一张意外的发票。针对这一点，建议循环开始前就设硬上限：包括每次运行的预算、每天的预算、最大重试次数。
手册里最后提到：
同样一个循环，两个人来搭，可能走到完全相反的终点，差别不在循环本身。
一个人用循环，是为了在自己已经理解的事情上跑得更快。他读代码，有方向感，知道哪里该信、哪里该停。循环放大的，是他原本就有的判断力。
另一个人用同样的循环，是为了从此不用再理解。代码能生成，计划能生成，PR 能生成，修复也能生成。六个月后，前者变强了，后者变成了一台自己看不懂的机器的看门人。
循环让生成这件事变得极其简单，门槛几乎被抹平了。剩下稀缺的是判断力，知道哪个方案是对的、哪条线该停、哪个输出能跑但从根上就错了。
所以这份手册最重要的一句话是：
去搭你的循环，但要像一个打算继续做工程师的人那样去搭它
——而不是一个只会按启动键的人。
学AI大模型的正确顺序，千万不要搞错了
🤔2026年AI风口已来！各行各业的AI渗透肉眼可见，超多公司要么转型做AI相关产品，要么高薪挖AI技术人才，机遇直接摆在眼前！
有往AI方向发展，或者本身有后端编程基础的朋友，直接冲AI大模型应用开发转岗超合适！
就算暂时不打算转岗，了解大模型、RAG、Prompt、Agent这些热门概念，能上手做简单项目，也绝对是求职加分王🔋
📝给大家整理了超全最新的AI大模型应用开发学习清单和资料，手把手帮你快速入门！👇👇
学习路线:
✅大模型基础认知—大模型核心原理、发展历程、主流模型（GPT、文心一言等）特点解析
✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑
✅开发基础能力—Python进阶、API接口调用、大模型开发框架（LangChain等）实操
✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用
✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代
✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经
以上6大模块，看似清晰好上手，实则每个部分都有扎实的核心内容需要吃透！
我把大模型的学习全流程已经整理📚好了！抓住AI时代风口，轻松解锁职业新可能，希望大家都能把握机遇，实现薪资/职业跃迁～
