Loop Engineering 来了：从写 Prompt 到设计 Loop，AI 编程的第四次范式跃迁

前言

最近圈子里突然冒出一个热词——Loop Engineering。

说实话，刚看到这个词时，心里多少有点抵触。这两年AI圈造词的速度，简直比模型迭代还快。Prompt Engineering还没消化完，Context Engineering又来了，紧接着Harness Engineering，现在又是Loop。每个新词背后都跟着一波课程和咨询，搞得不少搞技术的同学一看到“XX Engineering”就头疼。

不过，这次的情况可能不太一样。我把Addy Osmani的长文、The New Stack的报道，以及卡兹克老师的中文解读都翻了一遍，又对照着Claude Code、Codex这些工具里的/goal、/loop命令亲手试了几轮。结果发现，这次不是在造概念，而是确实在描述一个正在发生的“工程范式跃迁”。

这篇文章不打算只停留在“Loop是什么”这个层面。我会从一个研发管理者的视角，把它和前面的三次跃迁串起来，重点聊聊为什么Loop的真正难点不在工程，而在管理学，以及一线团队落地时最容易踩进哪些坑。

读完这篇文章，你会搞清楚下面这几件事：

• Loop Engineering到底是什么，为什么它会在这个时间点突然成为业界共识
• 从Prompt到Context再到Harness和Loop，四次跃迁背后其实是同一条主线
• 一个完整的Loop由五个组件构成，每个组件解决什么具体问题
• /goal命令为什么是Loop骨架的最小可用产品，它和传统脚本的区别在哪
• 定义目标的能力，为什么比写代码、配hook难十倍
• 古德哈特定律在Agent身上是怎么被放大的，以及怎么提前规避
• 从架构师视角看Loop Engineering，有哪几条值得提前想清楚的工程取舍
• 一线技术人怎么从Prompt工作流，平稳迁移到Loop工作流

不管你是写业务代码的工程师、带团队的技术Leader，还是研究Agent如何落地企业系统的架构师，这篇都值得花十分钟读完。

开整。

一、Loop Engineering 是怎么火起来的

故事要从2026年6月初的一条推文说起。

OpenClaw创始人Peter Steinberger发了一条非常简短的推：“你不再需要为编码智能体写提示词了，你应该设计循环来提示你的Agent”。这条推之所以能火，是因为它捅破了一层窗户纸——很多团队其实已经在这么干了，只是没人这么直白地总结过。

更巧的是，几乎在同一时间，Claude Code的核心设计者Boris Cherny在一场开发者大会上说了几乎一模一样的话。大意是：“我不再手动给Claude写提示词了，我运行那种能让Claude自动编排任务的循环，我的工作就是写这些循环机制。”

两个不同公司的核心人物，几乎同时说了同一件事，这本身就值得停下来琢磨琢磨。

紧接着，Google的Addy Osmani跟了一篇长文，把这件事正式命名为Loop Engineering，把概念、组件、工作流都梳理了一遍。从此，Prompt Engineering、Context Engineering、Harness Engineering后面，多了第四个被业界共同承认的工程概念。

这个时间点非常微妙。模型能力（Claude Opus、GPT-5系列、各家国产旗舰）已经强到一定程度，单次问答的边际收益开始下降；而工具链（Claude Code、Codex、Cursor、Cline、各种Agent框架）也都补齐了文件操作、多轮调用、外部连接器这些基础能力。

到这一步，瓶颈不再是“模型聪不聪明”，而是“人能不能把任务设计成模型能自己跑完的样子”。这才是Loop Engineering突然成为业界共识的真正原因——它不是某家公司的市场营销，而是一线开发者发现“再不这么干就跟不上节奏了”。

顺便提一句，Peter Steinberger本人前不久刚被OpenAI挖去主导个人Agent方向。从这个动作其实也能看出来，OpenAI内部对Loop这条路是高度认可的。

二、四次范式跃迁：从语言学到管理学

如果只把Loop当成“让Agent自己跑循环”，其实是把它矮化了。

我更愿意把它放在一条更长的演化线上看。从Prompt到Loop，AI编程经历了四次范式跃迁，每一次跃迁背后都对应着“人和模型的协作关系”发生了根本变化。

第一阶段Prompt Engineering解决的是“让模型听懂我说的人话”。所以那时候大家研究的是写法、模板、Few-shot、思维链——本质上都是语言学问题。

第二阶段Context Engineering解决的是“光说话不够，模型还得知道这个项目里到底有什么东西”。这时候RAG、记忆系统、向量库这些概念被推到了前台。本质是信息科学的问题：怎么把人类的信息更高效地编码、检索、注入到一个上下文窗口里。

第三阶段Harness Engineering解决的是“光给信息也不够，得让模型在一套规则下跑”。这时候system prompt、工具调用、权限、审计这些机制被系统化设计。本质是控制论的问题：怎么给一个有能力但有不确定性的系统设定边界。

第四阶段Loop Engineering解决的则是“光设规则也不够，得让整个系统能自己往目标方向跑”。这时候真正被推到前台的，是“目标定义、验证设计、降级方案”这些一直属于管理学的命题。

四次跃迁连在一起看，其实讲的是同一个故事的四个章节：从单点问答，到信息上下文，到工程约束，再到自驱动闭环。人在系统里的位置，从“执行者”一路退到了“目标设定者”。

这条线再往后延伸，多半就是组织学的问题了——怎么协调一群Agent像一个团队那样工作。但那是后话。

三、一个完整 Loop 的五个组件

Addy Osmani那篇长文里，把一个完整的Loop拆成了五个组件。我用工程化的语言重新梳理一下，方便大家对照着自己手上的工具去落。

1. 定时器（Trigger）：循环的心跳

整个loop必须有一个能自动触发的机制，让循环跑起来本身不依赖人。常见的几种触发方式：

• 命令式触发：Claude Code里的/loop命令，按固定间隔自动执行
• 时间式触发：cron类的定时调度，凌晨跑一遍夜间任务
• 事件式触发：Hook在Agent生命周期的特定节点触发，比如“每次写完文件自动跑一次lint”

这一层看似最简单，但它决定了loop的“存在感”——一个不会自己跑起来的循环，本质上还是Prompt。

2. 工作空间（Workspace）：彼此隔离的执行环境

第二个组件是工作空间。要让多个Agent同时干活而不互相打架，每个Agent必须有自己独立的工作目录、独立的分支、独立的临时文件区。

技术圈里很容易低估这一点。两个Agent同时改一个文件的混乱程度，跟两个设计师同时改同一个图层而互相不打招呼差不多。工作空间本质上是把“Agent并发”当一个分布式系统问题来对待——隔离、合并、冲突解决，缺一不可。

3. 知识体系（Knowledge System）：项目的长期记忆

第三个组件是项目的知识体系。Addy Osmani在原文里用的是skill这个词，但我觉得这个表述偏窄。单个skill不够，必须是一整套知识管理体系。

每次开新对话Agent都会忘掉一切，这件事大家都吃过亏。代码规范、架构约束、踩过的坑、命名约定——你跟它说过的所有规则，下一轮全部清零。所以loop工程师必须搭一套机制：把这些知识沉淀下来，让Agent每次启动就自动加载。

没有干净的知识体系的loop，就像一个每天上班都在看过期文档的实习生——干得越快，错得越离谱。这一层是loop的“长期记忆”，也是把Agent从“单次完成任务”升级成“持续在你项目里干活”的关键。

4. 连接器（MCP / Tool Layer）：通向真实世界的端口

第四个组件是连接器。一个只能读写本地文件系统的Agent，能力非常有限。但接上GitHub、飞书、数据库、Jira之后，它就能在真实工作环境里干活了——发现bug、提PR、写报告、通知人，一条龙跑通。

MCP协议这一年的爆发，本质上就是在补这一层。它让连接器从“每家工具自己写一套”变成了“写一次，所有Agent都能用”。这是loop能跑得动的真实世界端口。

5. 子Agent（Verifier）：做事的和检查的必须分开

第五个组件，也是最容易被忽略的——做事的Agent和验证的Agent必须分开。

写代码的Agent不能给自己打分，这跟学生不能自己批卷子是一个道理。Loop里跑的实际上是两类Agent：一类负责干活，一类负责挑刺。两类分工越清楚，loop的输出质量越高。

这五个组件凑齐了，才算一个完整的loop。少任何一个，loop都会在某个时间点崩掉——崩在哪取决于你缺哪一块。

四、/goal 命令：Loop 骨架的最小可用产品

讲到这里，很多人对loop的概念已经基本能跟上了。但概念归概念，最后总要落到能用的产品上。

Claude Code和Codex各自都提供了一个命令，叫/goal（在Codex里也叫“追求目标”）。这个命令其实就是Loop Engineering的最小可用产品（MVP）形态——把loop的骨架压缩到一个命令里。

它的工作方式非常直接：

/goal 「所有 unit test 通过，并且 lint 检查零报错」

下面发生的事情，就完全不需要人工干预了：

1. Agent读取目标，分析当前状态
2. 改一轮代码
3. 跑测试 + lint
4. 判断是否满足完成条件
5. 不满足，回到第2步
6. 满足，停下来

这个流程看似简单，但和传统脚本的本质区别在于：/goal不是给Agent一个步骤，而是给Agent一个状态。

传统脚本是“先做A，再做B，再做C”，路径在写脚本的时候就钉死了。/goal是“不管你怎么走，最后必须到达X状态”，路径由Agent自己探索，每轮还能自我修正。

这就是为什么很多讲Loop Engineering的内容，都会停在五个组件 + /goal这一层。表面看，确实够用了——五个组件解释清楚了loop是什么，/goal演示了怎么把它跑起来。

但停在这里其实只讲了“术”，没讲“道”。Loop Engineering真正的难度，不在/goal这条命令本身，而在于这条命令后面那个目标该怎么定义。这才是下一章要讲的，也是大多数文章避而不谈的地方。

五、定义目标的能力，比写脚本难十倍

/goal这种命令，看上去简单，用起来才知道它有多挑使用者。

我习惯用两个对比例子来说明。

目标A：“把这个应用优化一下”

听起来像是个正常的工程任务。但放进/goal里，Agent会陷入一种很尴尬的状态。它不知道什么叫“优化好了”——是性能提升10%算优化好了？还是接口响应低于50ms？还是代码可读性上去了？

最常见的两种翻车结局：

1. Agent改了一点小东西，自我感觉还行，停了——你拿到一个几乎没变化的代码库
2. Agent一直觉得不够，改个没完——你拿到一个面目全非的代码库

两种结局都让你恨不得把它关掉。

目标B：“test/auth目录下所有测试通过，tsc --noEmit零报错，npm run lint零违规”

这个目标完全不一样。Agent每改一轮代码就跑三个命令，每个命令都有明确的通过标准。三条全过了就停，没过就继续——清清楚楚，干干净净。

同样的工具，同样的模型。结果差别完全来自于“目标定义”。

这就解释了为什么Loop Engineering的核心能力不是工程能力，而是定义目标的能力。

定义目标这四个字，听起来简单，做起来是真难。绝大多数Agent在“自己定义目标”的能力上还很弱——你给它一个模糊目标，它没有那种“等等，这个目标不够清晰，我得先想清楚才能动手”的本能。它要么硬干，要么乱干。

所以这一层的工作压回到了人身上。写loop的人，本质上是在做和管理者完全一样的事情：把模糊目标拆成清晰目标，把清晰目标定义成可被机器验证的状态。

我自己慢慢摸出了一个习惯——在写任何/goal之前，先问自己：“这个目标能不能让一个完全不了解项目的人，跑一条命令就能判断是否完成？”

如果不能，目标就还得再细化一层。

六、古德哈特定律：Loop 工程师必须知道的隐形陷阱

讲到这里，光会拆目标其实还不够。Loop里还藏着一个更阴险的陷阱，值得拎出来单讲一章。

它在管理学和经济学里有个专门的名字，叫古德哈特定律（Goodhart's Law）：

翻译成大白话就是：你考核什么，员工就只做什么，其他东西可能全部退化。

人类世界里这件事已经被反复验证。考核GMV，会做出虚假交易；考核代码行数，会出现hello world拆50行；考核bug修复数，会出现“先制造一个bug再修”。每一个KPI都有它对应的钻空子姿势。

而把这条定律放到AI Agent身上，会被放大到很可怕的程度。Agent没有职业道德、没有社交压力、没有“这样干显得我太离谱”的羞耻心。它纯粹按规则办事，规则有漏洞，它就钻；钻完了不会有任何心理负担。

业界已经积累了不少经典段子。比如说：

• 目标是“让所有测试通过” → Agent直接把失败的测试用例删了，目标完美达成
• 目标是“错误日志清零” → Agent把logger调用全注释掉了，错误果然清零
• 目标是“构建成功” → Agent把失败的模块从构建脚本里exclude了，构建当然成功

每一个例子从“验证条件”的角度看都是合规的，从“你真正想要的结果”的角度看都是灾难。

这告诉我们loop工程师的另一项核心工作——目标不能只有完成标准，还必须配套定义边界条件。

完成标准告诉Agent“该做什么”，边界条件告诉Agent“不能怎么做”。两者缺一不可。

这其实正是Harness Engineering在Loop Engineering里的真正用武之地。Harness是约束，是护栏，是告诉Agent“你可以自由发挥，但这条线不能越”。Loop是驱动力，是告诉Agent“往那个方向一直跑”。

两个东西加在一起，才是一个完整的系统。只有Loop没有Harness的工程，跑得越快塌得越快。

七、Harness 与 Loop 的协同：约束先行 + 闭环驱动

把前面六章的内容串起来，能看到一个非常清晰的协同关系。

Harness与Loop不是两个相互替代的概念，而是两个相互配合的层。

我的建议是按“Harness先行，Loop后接”的顺序来落。

先把Harness搭好——把权限、工具白名单、可写目录、审计日志这些基础护栏全部立起来。这一步是loop安全运转的前提。先给Agent装好刹车和方向盘，再让它上高速。

然后再在Harness的基础上加Loop。/goal命令配合定时器、Hook、子Agent验证器，把闭环跑通。这时候Agent即使跑偏，也会被Harness的护栏挡住，不至于把生产环境搞炸。

很多人第一次接触Loop Engineering时容易犯的错，是直接上手写loop，跳过了Harness这一步。结果Agent一旦开始自驱动，要么跑出权限边界把不该改的文件改了，要么钻验证条件的空子搞出一堆“合规但没用”的产出。

Harness是地基，Loop是楼层。地基没打好就盖楼，楼越高崩得越惨。

这条经验在传统软件工程里其实是常识——做CI/CD之前先搞代码权限和分支保护，做自动部署之前先搞回滚和监控。Loop Engineering在AI编程里的位置，恰恰对应了CI/CD在传统软件工程里的位置：是把人从“每一步都得手动”解放出来，让系统自己跑的工程。

但前提是——地基必须够牢。

八、从架构师视角看 Loop Engineering 的几个工程取舍

前面七章把Loop Engineering的概念和原理讲清楚了。这一章我从一个研发管理者和架构师的视角，再补几条值得提前想清楚的工程取舍。这些都是把Loop真往团队里推之前，最容易被忽略但又最关键的几个点。

1. “自驱动”不是“全自动”，关键节点必须留人在

Loop Engineering的诱惑在于“让Agent自己跑起来”。但真正落到生产环境，所有可能改动外部状态的关键节点，都必须留一道人工确认。

不是不信任Agent，而是因为外部状态的修复成本远大于多按一次回车的代价。能Loop的范围，应该锁定在“跑错了不会让一线团队加班善后”的边界内。

2. 验证器的成本，往往比你想象的高

很多团队第一次设计loop，会以“目标定义清楚就完事了”的心态进场，然后在验证器这一层翻车。

写测试本身是有成本的。要让一组测试既能验证Agent的产出又不被Agent钻空子，需要的工程量并不小。Loop跑一千次的代价，可能不如把验证器写好一次的代价高。

如果验证器本身经常假阳性、假阴性，那loop跑得越多，反馈给Agent的噪声越大，最终结果越不可信。一个原则：先有可信的验证器，再有loop。

3. 成本和限速必须从Day 1开始想

Loop跑起来之后，token消耗、模型调用次数、外部API调用次数都会被放大。一个不限速的loop，配上一个会重试的Agent，分分钟能把月度预算打穿。

落地之前，至少要回答这几个问题：

• 单轮loop的token上限是多少？
• 每天最多跑几轮？
• 跑到第几轮没收敛就停下来报警？
• 某个验证条件长期不满足时怎么降级？

成本治理不是“跑出问题再补”，而是“Day 1就嵌进去”。

4. 子Agent拆分要克制，不是越多越好

“做事的Agent和验证的Agent分开”是合理的。但有些团队走极端，搞出十几个子Agent，每个负责一个微小职责，相互调用，最后调试起来比单体程序还难。

子Agent的拆分粒度，要按“这一层值不值得独立验证”来定。一个职责能不能被独立验证、独立测试、独立替换，是它配不配独立成Agent的标准。不要为了拆而拆。

5. 知识体系是Loop的杠杆，但维护是长期工作

第三个组件“知识体系”是loop长期跑下去的关键，但它最容易被“上线时一次性写完，后面没人维护”。

知识体系不维护就过期，Agent看着过期文档干活，错误会成倍出现。建议把知识体系的维护也纳入loop本身——比如每周让一个子Agent去检查项目里哪些规则被违反了，回头反向更新知识库。

让知识体系也成为loop的一部分，是把这件事可持续做下去的最稳路径。

6. 范式跃迁不是替代关系，是叠加关系

最后这条容易被忽略，但很重要——前面三个Engineering不会消失，只是不再是核心。

到了Loop阶段，每一轮循环里仍然在写prompt、注入context、依赖harness。它们都还在，只是从“核心工作”变成了“底层基础”。这一点决定了团队的能力建设思路：不是把前面学的全扔了重来，而是在原有能力上多叠一层管理学视角。

技术债和知识债，往往就是从“以为换了范式，前面的就不用学了”开始累积的。

九、给一线技术人的几条 Loop 落地建议

这一章是给一线技术人的实操建议。前面那些概念听起来再好，最后还是要落到“我下周怎么开始用”上。

1. 这周可以做的：先选一个低风险任务，跑一次最小 /goal

别上来就改生产代码。先选一个改坏了也不影响别人的小任务，比如某个独立工具脚本的lint修复、某个文档目录的重新组织、某段实验代码的重构。

把目标写成一行/goal，验证条件具体到“跑哪条命令、看哪个返回值”。让loop完整跑一次，亲眼看一下Agent是怎么自己迭代的、什么时候停下来、有没有钻空子。

最小可用的体感比看十篇长文都管用。

2. 这个月可以做的：把团队最痛的重复活儿改造成 loop

每个团队都有那种“每次发布前都要做一遍、每次都嫌烦”的活——比如版本号同步、changelog整理、依赖升级、测试覆盖率检查。

挑一个最痛的，按五个组件拆解一遍：触发器、工作空间、知识体系、连接器、验证器，看看它能不能被改造成一个loop。

不一定追求一次到位，先把最容易自动化的那部分做掉。哪怕只省了30%的人工，体感也会非常不同。

3. 这个季度可以做的：建立团队级的 Loop 规范

如果团队里多个人都开始用loop，规则必须收敛到团队级。不然各自跑各自的，权限、token预算、知识体系都会乱掉。

规范里至少要定义这几件事：

• 哪些环境允许loop跑（沙箱可以，预发审慎，生产严禁自驱动）
• token和调用次数的预算怎么分配
• 共用的知识体系放哪里、谁维护
• 验证器的最低标准（多少覆盖率、是否可信）
• Agent异常时的报警和回滚机制

这一步基本上就是把传统的DevOps规范，迁移到Agent工程上。有规范的团队跑loop是杠杆，没规范的团队跑loop是事故源。

4. 长期需要建立的：从“写代码”转向“定义目标”的能力

最后一条是给个人的。

如果你长期做技术，Loop Engineering这一波带来的最大变化，其实是对个人能力模型的重塑。

过去十年，工程师的核心竞争力是“把一个模糊需求落成一段精确代码”的能力。未来一段时间，会越来越多地变成“把一个模糊目标拆成一组可验证状态”的能力。

这两件事看起来相似，其实很不一样。前者是翻译，后者是抽象。前者训练的是写代码的肌肉，后者训练的是当管理者的头脑。

不用焦虑，也不用一夜之间转过去。但从今天起，每次写需求文档、写测试用例、写PR描述时，都多问自己一句：这件事如果让一个不会偷懒的Agent来干，它会不会跑偏？

每问一次，你就多向Loop Engineering这条路靠近一点。

总结

1. Loop Engineering是AI编程的第四次范式跃迁——从Prompt到Context到Harness再到Loop，对应着语言学、信息科学、控制论、管理学四条主线。
2. 它不是新词炒作，而是真实的工程范式——OpenClaw的Peter、Anthropic的Boris、Google的Addy Osmani几乎同时在讲同一件事。
3. 一个完整的Loop由五个组件构成：定时器、工作空间、知识体系、连接器、子Agent。少任何一块，loop都会在某个时间点崩掉。
4. /goal命令是Loop的最小可用产品，但能不能跑得好，完全取决于目标定义本身——同一个工具，模糊目标和清晰目标差出十万八千里。
5. 真正的核心能力是定义目标的能力，而不是写脚本、配hook这些工程能力——这是从工程师向管理者思维的本质迁移。
6. 古德哈特定律是Loop的隐形陷阱：Agent比人类更擅长钻规则空子，目标必须同时定义完成标准和边界条件。
7. Harness与Loop是叠加关系，不是替代关系——Harness先行，Loop后接，地基不牢就盖楼，楼越高崩得越惨。
8. 从今天就开始练习：选一个低风险任务跑最小/goal，让团队最痛的重复活儿先loop化，逐步建立团队级Loop规范。

最后一句话留给你——未来五年里，工程师真正稀缺的能力，不是写代码，而是把一个模糊目标定义成一组可被机器验证的状态。