当Claude Code创始人宣布不再亲自写提示词，而是设计自动调度系统时，这标志着开发者角色从'操作员'向'架构师'的范式转移。本文将拆解Loop Engineering的本质，带你穿透新名词迷雾，看清AI工作流从内循环到外循环的完整进化图谱。
2026 年 6 月，Claude Code 的创造者 Boris Cherny 在 Anthropic 开发者大会上说了段话：
我已经不给 Claude 写提示词了。我有一堆循环在跑，它们负责给 Claude 下指令、决定下一步做什么。我的工作，就是写循环。
一年前他还在编辑器里老老实实写代码。去年 11 月他把编辑器卸了，同时开十个 AI 并行干活。到了今年，他连指挥 AI 都懒得干了。
几乎同一天，OpenClaw 创始人 Peter Steinberger 在 X 上发了条帖子，一句话拿了 220 万阅读量：
别再给 coding agent 写提示词了。你应该设计循环来提示你的 agent。
第二天，Google 工程总监 Addy Osmani 写了篇博文，给这个东西正式命名：Loop Engineering，循环工程。
三家头部公司的人，一周之内，不约而同指向同一个方向。这就不是巧合了。
然后我的第一反应是：Harness Engineering 我还没学完呢，Loop 又来了？
你可能跟我一样。PE 刚搞明白，CE 来了。CE 还没消化，HE 来了。HE 的文章还存在收藏夹里没看完，LE 又冒出来了。
每隔两三个月一个新词，到底是学还是不学？到底是真的技术升级，还是这帮人又在造新词？
这篇文章就回答这一个问题。
我的结论先亮：Loop 不是 Harness 之上的新楼层，它是 Harness 长出来的外循环。你不需要重新学一门新学科，你需要理解的是，这个外循环跟你已经知道的东西到底是什么关系。
先别急着聊 Loop，咱把这几年的概念过一遍。排一排你会发现，表面上是新词不断，底下藏着一条特别清楚的线。
2023 年，提示词工程（Prompt Engineering）。
那时候的 AI 就是个一问一答的客服。你问一句它答一句，答得好不好全看你怎么问。一个好提示词和一个烂提示词，产出质量能差三倍。所以整个行业都在研究怎么把问题问得更精准，这门手艺就叫提示词工程。
核心能力：把话问明白。
2024 年，上下文工程（Context Engineering）。
AI 开始能用工具了。它不只是回答问题，还能自己查资料、调 API、读文件，一口气干几十步。听起来很爽对吧？但问题也来了：干到第二十步，它把第一步说过的话忘得一干二净。
金鱼记忆。
所以你得当它秘书：哪些材料递给它看，哪些先收起来别干扰它，什么时候把之前的结论重新提醒它一遍。这套管信息输入的活儿，就叫上下文工程。
核心能力：管它能看见什么。
2025 年，驾驭工程（Harness Engineering）。
AI 开始能干几个小时的大活了。光管信息输入不够了，你得给它配完整的工作环境：工位在哪、工具有哪些、权限开到多大、出了错谁来检查、检查不过怎么纠正。
这就不是秘书的活了，这是包工头的活。你得搭一整套系统，让 AI 在里面可靠地运转。这套系统就叫 Harness，搭这套系统的工程就叫驾驭工程。
核心能力：给它一个能干活的环境。
2026 年，循环工程（Loop Engineering）。
AI 能连续干几天了。不光能干，还能同时开几十个、几百个实例并行。一个人管不过来了。
你需要一套自动调度系统：什么时候启动 agent、启动完干什么、干完谁来检查、检查不过怎么重试、记录存在哪、什么时候该收工。
你从包工头，升级成了定规矩的人。
核心能力：设计那个替你管 agent 的系统。
你看这条线了吗？表面上是四个新词的更替，底下是同一个变量在持续增长：AI 能连续自主工作的时间长度。
一问一答的时候，你管的是一句话。干几十步的时候，你管的是信息流。干几个小时的时候，你管的是运行环境。干几天的时候，你管的是调度系统。
人的角色也在同步变化：提问者、秘书、包工头、定规矩的人。
每一轮新词的本质，不是前一个被淘汰了，而是 AI 自主性又上了一个台阶，人必须跟着往上挪一层。
所以这几个概念是叠加关系，不是替代关系。提示词没死，它砌在每一个循环里面。上下文没过时，没有好的上下文管理，你的循环跑起来也是一坨。
概念先落地，不玄乎。
以前你用 AI 干活，流程是这样的：你写一条提示词，AI 跑一轮，你看结果，觉得不对再写一条，AI 再跑一轮。来回循环，但每一轮都是你在按回车。
你就是那个人肉调度器。AI 再强，你不按回车它就停着。
Loop Engineering 做的事情，就是把你从这个循环里拿掉。
你不再一轮轮手动输入了。你设计一套系统：这套系统自动给 AI 派活、AI 干完之后自动检查结果、检查不过自动让它重做、做到什么程度算完你提前定义好、整个过程记录在案。
用 Addy Osmani 的定义：你不再是那个提示 agent 的人，你设计那个替你提示 agent 的系统。
打个比方。
以前你是监工，站在工地上盯着工人干活，干一步你看一眼，不对你喊一嗓子。工人干活的速度再快，也被你的盯盘速度卡死了。
现在你是定规矩的人。你写了一本操作手册、设了一套验收标准、安排了一个质检员，然后你走了。工人按手册干活，质检员按标准验收，出了问题有复盘机制。你第二天回来看报告就行。
你的价值从”盯”变成了”建”。
这就是 Loop Engineering 最核心的一句话。不是什么高深的技术，就是一个角色转变：你不再坐在键盘前一轮轮和 AI 对话了，你在设计”谁来跟 AI 对话、什么时候对话、对话完怎么检查”这套系统。
这是我听到最多的一个反应：这不就是个定时任务吗？我家闹钟还能七点准时响呢。
Reddit 上有人更直接：这就是戴了顶帽子的 cron job。
我先说结论：你对了一半。调度层确实就是 cron。Boris 自己的 loop 就跑在 cron 上。Claude Code 的 /loop 命令底层就是定时调度。如果你对 loop 的全部理解是”一个按定时器跑的东西”，那这个东西 1975 年就发明了。
但闹钟和管家的区别在哪？
闹钟只会按点响，管家会看情况办事。
一个真正能跑起来的 loop，缺一不可这六样东西：
第一，目标。什么算干完？不是”尽量做好”这种废话，是”所有测试通过且 lint 无报错”这种可以被机器验证的条件。没有明确目标的 loop，就是一个永不停歇的烧钱机器。
第二，上下文。agent 得知道什么？项目的技术栈、代码规范、已知的坑、之前做过的决策。你不告诉它，它每一轮都从零开始推导，效率极低还容易犯同样的错。
第三，动作。允许它干什么？能改哪些文件、能调哪些工具、能不能自己开 PR。权限太大容易搞破坏，权限太小啥也干不了。
第四，反馈。谁来说”不行，重做”？这是最关键的一环。写代码的和检查代码的必须是两个人。让 AI 检查自己写的东西，就好比让小学生自己批期末卷，回回一百分。
第五，状态。干到哪了记在哪。模型没有跨会话的记忆，这轮跑完，下一轮它全忘了。必须有一个外部存储，可以是一个 Markdown 文件、一个任务看板、一个数据库，让每一轮都先读上一轮的记录再接着干。
第六，退出。什么时候收工。这个听起来最简单，但最容易被忽略。没有退出条件的 loop，它不会自己停，只会一直跑一直烧 token，直到你的额度见底。
少了退出：拧不上的消防栓。你设了一个 loop，每五分钟跑一次检查。但你忘了设退出条件。它在那儿欢快地跑了八个小时，480 次调用，每次都是完整的上下文窗口。第二天早上你看账单，人傻了。
少了反馈：自己夸自己。你让 AI 写代码然后自己检查自己写的代码。它每一轮都觉得自己干得漂亮，信心满满地给你交差。你一看，功能倒是有了，但测试全是假的，覆盖率数据是它编的。越跑越偏，最后给你交一坨大的。
少了状态：每天都是新来的。你让 AI 每天早上 9 点跑一遍代码审查。但你没给它接状态存储。它每天早上都像第一天入职一样，昨天审过的文件今天再审一遍，昨天提过的建议今天再提一遍。干到第十轮，还在重做第一轮的活。
所以回到那个质疑：是不是就是定时任务？
定时触发是 loop 的触发方式之一，确实没什么新鲜的。但设计一个具备目标、上下文、动作、反馈、状态、退出六个要素的自运转系统，这不是定个闹钟能搞定的事。
闹钟是 loop 的骨架，那六件套才是 loop 的血肉。
好，到全文最核心的部分了。
如果你之前了解过 Harness Engineering，你可能会困惑：这些东西 Harness 不是讲过了吗？目标、上下文、验证、状态管理，这些不就是 Harness 的四大模块吗？
没错。所以 Loop Engineering 到底跟 Harness 是什么关系？
答案是：Harness 里面本来就有一个 loop，那是内循环。Loop Engineering 做的是外循环。它被从 Harness 里面单拎出来之后，运行环境变了。
你让 AI 修一个 bug。它的工作过程是这样的：
思考、行动、观察、再思考。这个过程会反复循环，直到测试通过或者它认为任务完成了。
这就是 ReAct 循环，agent 最基础的工作模式。学术界研究了好几年的东西，核心就这四步。
这个循环发生在一次对话内部，是 agent 自己在跟自己迭代。你按了回车之后，它在里面转了好几圈，最后给你一个结果。
在 Claude Code 里面，对应的命令是/goal。你给一个完成条件，比如”所有测试通过且 lint 无报错”，然后走开。agent 自己在里面循环，每跑完一轮有个独立的评估模型（默认是 Haiku）检查条件是不是满足了。满足就停，不满足就继续。
内循环的核心问题是：agent 在一次会话中，怎么一步步推理、行动、自我纠正。
这是 Harness Engineering 管的范畴。你的 CLAUDE.md 规则、Skills 文件、Hooks 验证、权限约束，全都是在服务这个内循环：让 agent 在一次会话中跑得更可靠、更高效。
现在换一个场景。
你不是只修一个 bug。你希望每天早上 9 点，AI 自动去 GitHub 上找所有标了 bug 的 issue，挑最高优先级的那个，自己开一个分支，修好，跑测试，然后开 PR。
这里面有一个关键变化：不是你按回车了。
启动 agent 的不是你，是一个定时任务。决定修哪个 bug 的不是你，是 agent 自己去 issue 列表里找的。修完之后检查的不是你，是另一个 agent。决定下一步的也不是你，是系统根据检查结果自动安排的。
你的角色从”参与者”变成了”设计者”。你设计的不是提示词，而是整个调度机制：什么时候触发、触发后干什么、干完谁来验、验完怎么存、存完下一轮怎么接上。
外循环的核心问题是：跨越多次会话，agent 的运行被谁调度、怎么调度。
在 Claude Code 里面，对应的是/loop（定时触发）、Hooks（事件触发）、Scheduled Tasks（跨会话持久化）。
想象一个医院的夜班制度。
内循环是值班医生处理一个病人的过程：看症状、做判断、开药、观察反应、根据反应调整方案。这个过程可能来回好几轮，直到病人情况稳定。一个好医生在这个循环里越转越快、越转越准，这就是 Harness 在做的事。
外循环是医院的排班系统：几点交接班、夜里谁值、急诊来了通知谁、处理完的记录存在哪、早上交班的时候怎么汇报。排班系统决定的是”什么时候哪个医生在岗”，不是”医生到了之后怎么看病”。
Harness 是让医生看病看得好。Loop 是让医院的排班跑起来。
外循环跑不跑得起来，完全取决于内循环够不够可靠。如果值班医生连基本诊断都做不好，你排班系统再精密也白搭。
如果你读过我之前写的 Harness Engineering 的文章，你知道 Harness 有四个核心模块：约束、告知、验证、纠正。
现在把 Loop Engineering 号称的核心组件拉过来，逐个对应：
你看出来了吗？Loop Engineering 声称的每一个核心组件，在 Harness 的四模块框架里都已经有了归属。
那 Loop 到底新增了什么？
就一样：触发机制。
Harness 讲的是”agent 在一次会话里怎么跑得好”，但它没有回答”谁来启动这次会话、什么时候启动、启动多少个”。
Loop 把这个问题接过来了。触发方式有三种：按时间（定时任务）、按事件（PR 被打开、CI 挂了）、按目标（跑到条件满足为止）。加上多 agent 并行编排和跨会话状态持久化。
但这些东西，是一个全新的工程学科吗？
很多文章把 PE → CE → HE → LE 画成四层楼，一层摞一层，暗示每一层是前一层的升级。
我认为这个画法有问题。
更准确的关系是一棵树：
Loop 不是 Harness 之上的新楼层。它是 Harness 体系里”生命周期管理”这个维度，被单独拎出来、放大讲了一遍。
为什么现在被单独拎出来了？因为 2026 年 Claude Code 和 Codex 都把 /loop、/goal、automation 这些能力上线了。产品功能先行，概念后补。不是先有了理论再有了实践，而是工具到位了，有人给它起了个名字。
这不是坏事。一个好的命名能让实践显性化，让更多人意识到”哦原来我也应该这么做”。但如果你把它当成一个需要从零学起的新学科，那就被词唬住了。
有一篇深度分析文章写过一句话，我觉得说得特别准：
Loop 并不是提示词的替代品，它是提示词的容器。每一个被研究的架构中的每一个循环，最终都锚定在某个人花时间思考或手写的文档上。
Loop 能跑起来，是因为里面的提示词足够好。提示词足够好，是因为写的人在 Harness 上花了足够多的时间。
Boris Cherny 说他不写提示词了，但他花了 2025 年的大部分时间在写 CLAUDE.md、写 loop 规范、跑五个并行 Claude Code 实例观察哪些模式有效哪些不行。那些工作就是 Harness Engineering。没有那些积累，他的 loop 不可能跑起来。
所以你不需要焦虑”又要学新东西了”。你需要的是把 Harness 搞扎实，然后加个触发器。
讲完了是什么和为什么，来聊怎么做。
这部分我不贴命令行，因为大部分读者不需要知道具体的代码语法。你需要理解的是思路，知道每一步在干什么、为什么这么干。
核心动作：给 AI 一个明确的完成条件，让它自己跑到满足为止。
大部分人用 AI 的习惯是：给一条指令，看结果，不满意再给一条。来回很多轮，每一轮都是你在判断”行不行”。
内循环的思路完全不一样。你在一开始就把”什么算行”定义清楚，然后让 AI 自己去达成。
比如你要让 AI 把项目里所有的 Jest 测试迁移到 Vitest。传统方式是你一个文件一个文件地指，改完看一眼，发现漏了再补。内循环的方式是你一开始就说：所有文件迁移完成、没有 Jest 依赖残留、全部测试通过。然后让它自己去跑。
这里面最重要的能力是什么？不是写代码，是定义”完成”。
你不用教 AI 怎么改代码，它比你会。但你必须告诉它什么才叫改好了。这个”交付标准”是你定的，AI 只管往那个标准跑。
好的完成条件有三个特征：
可验证：能用机器检查的，不是人肉看的。”代码更整洁”不是好条件，”lint 无报错且类型检查通过”才是。
具体：不能模糊。”把功能做好”不行，”登录页面能正常注册、登录、找回密码，三条路径的测试全部通过”才行。
有边界：别贪多。一次内循环解决一个明确的问题，不要塞十个需求进去。
还有一条被反复验证的铁律：干活的和检查的不能是同一个。AI 写完代码让另一个独立的模型来判断条件是否满足，而不是让它自己说”我觉得做完了”。这就像考试不能自己给自己批卷。
内循环跑通了，你已经能做到”定一个目标，让 AI 自己跑到达标为止”。下一步是把这件事自动化起来，不再需要你手动按开始。
外循环有三种触发方式，适用场景不一样：
定时触发：值班表模式。
你设一个周期，比如每 30 分钟、每 1 小时、每天早上 9 点。到点了 AI 自动启动，执行你预设的任务，干完自动记录结果。
适合什么场景？重复性的监控和巡检。比如每隔一段时间检查一下 CI 有没有挂、依赖有没有安全漏洞、文档链接有没有失效。不需要人盯着，但需要有人定期看。
事件触发：警报器模式。
不按时间跑，按事件跑。有人提了 PR，触发一次代码审查。CI 挂了，触发一次自动修复。有新的 issue 被标了 bug，触发一次诊断。
适合什么场景？需要即时响应的工作流。事件发生了才启动，没事不跑，比定时触发省 token。
目标触发：项目制模式。
不看时间也不看事件，只看条件。”把这 200 个文件的测试框架全部迁移完”就是一个目标触发的外循环。它会一直跑，直到条件满足或者达到预算上限。
适合什么场景？一次性的大规模任务。明确的终点，跑到为止。
三种触发方式可以组合。比如你设一个定时触发的外循环，每天早上 9 点去 GitHub 找新的 bug issue，找到了就启动一个目标触发的内循环去修，修完自动开 PR。这就是外循环套内循环的典型模式。
这是我最想说的一点。
很多人看到 Loop Engineering 的文章，第一反应是去折腾 /loop、定时任务、多 agent 编排这些花哨的东西。但你退一步想：如果你的 AI 连一次性的任务都做不好，你让它自动反复做，不就是在自动化生产垃圾吗？
Harness 没搭好就上 Loop = 自动化生产垃圾。
具体来说：
你的 CLAUDE.md 还没写清楚项目规范？agent 每次启动都在瞎猜，跑十轮猜十次。
你的验证机制还没建？agent 自己夸自己干得好，跑十轮错十轮你都不知道。
你的权限约束还没设？agent 一兴奋把生产环境的数据库给你清了，跑一轮就够你哭。
所以正确的顺序是：
第一步，搭 Harness。把项目的 CLAUDE.md 写清楚、Skills 文件准备好、Hook 验证配好、权限设对。让 AI 在一次对话里就能可靠地完成一个任务。
第二步，用内循环。给一个明确的完成条件，让 AI 自己跑到达标。你先试几次，确认它在无人值守的情况下能稳定交付。
第三步，加外循环。确认内循环稳了，再加定时触发或者事件触发。从小循环养起，不要一上来就搞”每五分钟跑一次全量代码审查”这种大的。
Boris 自己也是这么过来的。他花了大半年在 Harness 上打基础，写规范、跑实验、沉淀经验，最后才敢说”我不写提示词了，我写循环”。
那些看起来毫不费力的人，都是在你看不到的地方使足了劲。
回到开头的问题：PE、CE、HE、LE，到底是造新词还是真升级？
我的回答是：每个新词的出现都对应了一次真实的能力跃迁，但它们之间是叠加关系，不是替代关系。
提示词工程没死，它砌在每个循环的底层。上下文工程没过时，没有好的上下文管理你的循环跑不起来。驾驭工程是骨架，循环工程是骨架上长出来的新能力。
所以下次再有新词冒出来，先别焦虑，就问一句：AI 又能多干多久了？
如果答案是”更久了、更自主了”，那你要跟着调整的就是一件事：你在这个系统里扮演的角色往上挪了一层。
我们曾经学怎么写代码。后来学怎么让 AI 写代码。现在要学的，是怎么造那个”让 AI 自己写代码”的系统。
但不管怎么挪，有一样东西从来没变过：你得知道什么是好的、什么是对的。这个判断力，loop 替不了你。
我是小普，我们下次见。
参考来源：
本文由 @小普 原创发布于人人都是产品经理。未经作者许可，禁止转载
题图来自作者提供
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。