Loop Engineering 不是新楼层,是 Harness 长出来的外循环

4 评论 89 浏览 0 收藏 32 分钟

当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 长出来的外循环。你不需要重新学一门新学科,你需要理解的是,这个外循环跟你已经知道的东西到底是什么关系。

二、黑话简史:AI 能连续干活的时间越来越长了

先别急着聊 Loop,咱把这几年的概念过一遍。排一排你会发现,表面上是新词不断,底下藏着一条特别清楚的线。

2023 年,提示词工程(Prompt Engineering)。

那时候的 AI 就是个一问一答的客服。你问一句它答一句,答得好不好全看你怎么问。一个好提示词和一个烂提示词,产出质量能差三倍。所以整个行业都在研究怎么把问题问得更精准,这门手艺就叫提示词工程。

核心能力:把话问明白。

2024 年,上下文工程(Context Engineering)。

AI 开始能用工具了。它不只是回答问题,还能自己查资料、调 API、读文件,一口气干几十步。听起来很爽对吧?但问题也来了:干到第二十步,它把第一步说过的话忘得一干二净。

金鱼记忆。

所以你得当它秘书:哪些材料递给它看,哪些先收起来别干扰它,什么时候把之前的结论重新提醒它一遍。这套管信息输入的活儿,就叫上下文工程。

核心能力:管它能看见什么。

2025 年,驾驭工程(Harness Engineering)。

AI 开始能干几个小时的大活了。光管信息输入不够了,你得给它配完整的工作环境:工位在哪、工具有哪些、权限开到多大、出了错谁来检查、检查不过怎么纠正。

这就不是秘书的活了,这是包工头的活。你得搭一整套系统,让 AI 在里面可靠地运转。这套系统就叫 Harness,搭这套系统的工程就叫驾驭工程。

核心能力:给它一个能干活的环境。

2026 年,循环工程(Loop Engineering)。

AI 能连续干几天了。不光能干,还能同时开几十个、几百个实例并行。一个人管不过来了。

你需要一套自动调度系统:什么时候启动 agent、启动完干什么、干完谁来检查、检查不过怎么重试、记录存在哪、什么时候该收工。

你从包工头,升级成了定规矩的人。

核心能力:设计那个替你管 agent 的系统。

你看这条线了吗?表面上是四个新词的更替,底下是同一个变量在持续增长:AI 能连续自主工作的时间长度。

一问一答的时候,你管的是一句话。干几十步的时候,你管的是信息流。干几个小时的时候,你管的是运行环境。干几天的时候,你管的是调度系统。

人的角色也在同步变化:提问者、秘书、包工头、定规矩的人

每一轮新词的本质,不是前一个被淘汰了,而是 AI 自主性又上了一个台阶,人必须跟着往上挪一层。

所以这几个概念是叠加关系,不是替代关系。提示词没死,它砌在每一个循环里面。上下文没过时,没有好的上下文管理,你的循环跑起来也是一坨。

三、一分钟讲清楚 Loop Engineering 是什么

概念先落地,不玄乎。

以前你用 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 里面单拎出来之后,运行环境变了。

5.1 内循环:agent 在一次对话里怎么干活

你让 AI 修一个 bug。它的工作过程是这样的:

  1. 读报错信息,想想可能是什么原因(思考)
  2. 改一行代码(行动)
  3. 跑一遍测试看过不过(观察)
  4. 没过,重新分析报错,换个思路再来(再思考)

思考、行动、观察、再思考。这个过程会反复循环,直到测试通过或者它认为任务完成了。

这就是 ReAct 循环,agent 最基础的工作模式。学术界研究了好几年的东西,核心就这四步。

这个循环发生在一次对话内部,是 agent 自己在跟自己迭代。你按了回车之后,它在里面转了好几圈,最后给你一个结果。

在 Claude Code 里面,对应的命令是/goal。你给一个完成条件,比如”所有测试通过且 lint 无报错”,然后走开。agent 自己在里面循环,每跑完一轮有个独立的评估模型(默认是 Haiku)检查条件是不是满足了。满足就停,不满足就继续。

内循环的核心问题是:agent 在一次会话中,怎么一步步推理、行动、自我纠正。

这是 Harness Engineering 管的范畴。你的 CLAUDE.md 规则、Skills 文件、Hooks 验证、权限约束,全都是在服务这个内循环:让 agent 在一次会话中跑得更可靠、更高效。

5.2 外循环:谁来启动 agent、什么时候启动

现在换一个场景。

你不是只修一个 bug。你希望每天早上 9 点,AI 自动去 GitHub 上找所有标了 bug 的 issue,挑最高优先级的那个,自己开一个分支,修好,跑测试,然后开 PR。

这里面有一个关键变化:不是你按回车了。

启动 agent 的不是你,是一个定时任务。决定修哪个 bug 的不是你,是 agent 自己去 issue 列表里找的。修完之后检查的不是你,是另一个 agent。决定下一步的也不是你,是系统根据检查结果自动安排的。

你的角色从”参与者”变成了”设计者”。你设计的不是提示词,而是整个调度机制:什么时候触发、触发后干什么、干完谁来验、验完怎么存、存完下一轮怎么接上。

外循环的核心问题是:跨越多次会话,agent 的运行被谁调度、怎么调度。

在 Claude Code 里面,对应的是/loop(定时触发)、Hooks(事件触发)、Scheduled Tasks(跨会话持久化)。

内循环 vs 外循环:打个比方

想象一个医院的夜班制度。

内循环是值班医生处理一个病人的过程:看症状、做判断、开药、观察反应、根据反应调整方案。这个过程可能来回好几轮,直到病人情况稳定。一个好医生在这个循环里越转越快、越转越准,这就是 Harness 在做的事。

外循环是医院的排班系统:几点交接班、夜里谁值、急诊来了通知谁、处理完的记录存在哪、早上交班的时候怎么汇报。排班系统决定的是”什么时候哪个医生在岗”,不是”医生到了之后怎么看病”。

Harness 是让医生看病看得好。Loop 是让医院的排班跑起来。

外循环跑不跑得起来,完全取决于内循环够不够可靠。如果值班医生连基本诊断都做不好,你排班系统再精密也白搭。

5.3 Harness 的四模块,全覆盖了 Loop 的需求

如果你读过我之前写的 Harness Engineering 的文章,你知道 Harness 有四个核心模块:约束、告知、验证、纠正。

现在把 Loop Engineering 号称的核心组件拉过来,逐个对应:

你看出来了吗?Loop Engineering 声称的每一个核心组件,在 Harness 的四模块框架里都已经有了归属。

那 Loop 到底新增了什么?

就一样:触发机制

Harness 讲的是”agent 在一次会话里怎么跑得好”,但它没有回答”谁来启动这次会话、什么时候启动、启动多少个”。

Loop 把这个问题接过来了。触发方式有三种:按时间(定时任务)、按事件(PR 被打开、CI 挂了)、按目标(跑到条件满足为止)。加上多 agent 并行编排和跨会话状态持久化。

但这些东西,是一个全新的工程学科吗?

5.4 不是四层楼,是一棵树

很多文章把 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 搞扎实,然后加个触发器。

六、怎么做:从内循环练起

讲完了是什么和为什么,来聊怎么做。

这部分我不贴命令行,因为大部分读者不需要知道具体的代码语法。你需要理解的是思路,知道每一步在干什么、为什么这么干。

6.1 先把内循环用起来

核心动作:给 AI 一个明确的完成条件,让它自己跑到满足为止。

大部分人用 AI 的习惯是:给一条指令,看结果,不满意再给一条。来回很多轮,每一轮都是你在判断”行不行”。

内循环的思路完全不一样。你在一开始就把”什么算行”定义清楚,然后让 AI 自己去达成。

比如你要让 AI 把项目里所有的 Jest 测试迁移到 Vitest。传统方式是你一个文件一个文件地指,改完看一眼,发现漏了再补。内循环的方式是你一开始就说:所有文件迁移完成、没有 Jest 依赖残留、全部测试通过。然后让它自己去跑。

这里面最重要的能力是什么?不是写代码,是定义”完成”。

你不用教 AI 怎么改代码,它比你会。但你必须告诉它什么才叫改好了。这个”交付标准”是你定的,AI 只管往那个标准跑。

好的完成条件有三个特征:

可验证:能用机器检查的,不是人肉看的。”代码更整洁”不是好条件,”lint 无报错且类型检查通过”才是。

具体:不能模糊。”把功能做好”不行,”登录页面能正常注册、登录、找回密码,三条路径的测试全部通过”才行。

有边界:别贪多。一次内循环解决一个明确的问题,不要塞十个需求进去。

还有一条被反复验证的铁律:干活的和检查的不能是同一个。AI 写完代码让另一个独立的模型来判断条件是否满足,而不是让它自己说”我觉得做完了”。这就像考试不能自己给自己批卷。

6.2 再加外循环

内循环跑通了,你已经能做到”定一个目标,让 AI 自己跑到达标为止”。下一步是把这件事自动化起来,不再需要你手动按开始。

外循环有三种触发方式,适用场景不一样:

定时触发:值班表模式。

你设一个周期,比如每 30 分钟、每 1 小时、每天早上 9 点。到点了 AI 自动启动,执行你预设的任务,干完自动记录结果。

适合什么场景?重复性的监控和巡检。比如每隔一段时间检查一下 CI 有没有挂、依赖有没有安全漏洞、文档链接有没有失效。不需要人盯着,但需要有人定期看。

事件触发:警报器模式。

不按时间跑,按事件跑。有人提了 PR,触发一次代码审查。CI 挂了,触发一次自动修复。有新的 issue 被标了 bug,触发一次诊断。

适合什么场景?需要即时响应的工作流。事件发生了才启动,没事不跑,比定时触发省 token。

目标触发:项目制模式。

不看时间也不看事件,只看条件。”把这 200 个文件的测试框架全部迁移完”就是一个目标触发的外循环。它会一直跑,直到条件满足或者达到预算上限。

适合什么场景?一次性的大规模任务。明确的终点,跑到为止。

三种触发方式可以组合。比如你设一个定时触发的外循环,每天早上 9 点去 GitHub 找新的 bug issue,找到了就启动一个目标触发的内循环去修,修完自动开 PR。这就是外循环套内循环的典型模式。

6.3 一条铁律:内循环没跑通之前,别碰外循环

这是我最想说的一点。

很多人看到 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 替不了你。

我是小普,我们下次见。

参考来源:

  • Peter Steinberger (@steipete),X 帖文,2026 年 6 月 7 日
  • Boris Cherny (@bcherny),Anthropic Code with Claude 2026 大会演讲 + X 帖文
  • Addy Osmani,Loop Engineering,addyosmani.com/blog/loop-engineering/
  • Anthropic,Harness Design for Long-Running Apps
  • Anthropic,Claude Code Scheduled Tasks 文档,code.claude.com/docs/en/scheduled-tasks
  • LangChain,The Anatomy of an Agent Harness
  • Martin Fowler,Harness Engineering for Coding Agent Users
  • howborisusesclaudecode.com

本文由 @小普 原创发布于人人都是产品经理。未经作者许可,禁止转载

题图来自作者提供

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 内循环像医生看病,外循环像医院排班。排班再精密,医生水平不行也没用。所以先把内循环练好比什么都重要。

    来自广东 回复
  2. Loop的六要素里反馈需要独立的检查agent,这增加了架构复杂性和token成本。小团队可能还没赚回效率,就先被开销拖住。

    来自广东 回复
  3. 外循环依赖内循环的可靠性,这点说透了。没有扎实的Harness,Loop跑起来就是烧钱,设计六要素时反馈环节尤其关键。

    来自广东 回复
  4. AI自主工作时间越来越长,角色从操作员变成架构师。先梳理了PE到LE的演进,关键判断是Loop不是新楼层,而是Harness长出来的外循环。最后落到别焦虑,把内循环搞扎实再加个触发器。

    来自广东 回复