Nate Herk · 14:33 · 发布 2026-06-19 · 12.1万次观看(截至抓取) · 观看原视频
🔥 观众最高回放 06:15 — 引出接下来两个 demo 都来自 Matthew Berman 公开的 loop library。
主旨
用尽量直白的方式解释”agent loop”到底是什么,讲清验证环节比架构更重要,并用三个真实 demo 演示如何为不同任务设计可机读的完成判据。
核心论点
- Loop engineering 的本质是”替代自己去做那个提示者”,而不是造更复杂的 agent 编排。(→ 详解1)
- Agent loop 只有一个核心骨架:reason → act → observe → repeat,架构选型只是把它套到不同角色上。(→ 详解2)
- 真正决定 loop 好坏的是”完成判据”是否可机读、可自动验证,架构只是次要变量。(→ 详解3、详解5)
- 大多数任务其实不需要 loop,把”feedback 与迭代”那段外包给 agent 已经能换 90%+ 的质量提升。(→ 详解2)
- 「Peter Steinberger 在用我就也得用」是错配:他做的是 agent 开发,你做的是知识工作,可借鉴框架但不必照搬节奏。(→ 详解7)
知识点详解
1. 什么是 loop engineering
Nate 给”loop engineering”下了一个非常窄、非常操作化的定义:用一段系统去替代你”反复去 prompt 那个 agent”的位置。你不再是坐在屏幕前给反馈的人,你把目标与停止条件写清楚,让 AI 自己跑到那个停止条件。
“Loop engineering is replacing yourself as the person who prompts the agent. You design the system that does that instead.”(00:48)
具体到一段 loop,作者把它抽象成三件事——触发、动作、停止条件,英文原话是 “A loop is three things: a trigger, an action, and a stop condition”(00:20)。这套定义其实是 goal 模式的一个口语化版本:把目标 + 完成判据交出去,让 agent 自主推进,差别只在于 Nate 强调”系统替代人”这个角色,而不是”agent 替代人”。
更广义地看,这就是 Agentic Engineering 思想在工程节奏上的延伸——上游规格(目标 + 完成判据)决定下游产出,人退到只设计系统,而不是亲自干预每一轮迭代。
2. Agent loop 怎么工作:reason → act → observe
作者给出的最简骨架是 “An agent loop is just an AI that reasons on what to do, acts on what to do, starts implementing, and then it observes the result.”(02:51)。三者循环直到命中停止条件。
但他没有止步于给出骨架,还在 03:38 用一张「质量 vs 尝试次数」的图直白说明为什么 loop 有价值(03:38)。人工逐次给反馈时,第 N 次的产出质量大致是一条缓慢爬升的折线——你必须每次都自己看、自己评、自己改。把”feedback + iteration”这段外包给一个 agent 之后,同样一次对话里,AI 反馈会把质量曲线压成更陡的爬升段,跳过 1-2 轮你手动给反馈的过程(03:50)。换句话说,即使你根本不用任何”loop 架构”,只要给 agent 装上一个能自我验证的反馈环节,产出就会跳一级。
这段反馈环节,对应骨架里的 “observe”,也就是作者反复强调的”verification loop”(05:36)。在更技术化的术语里,observe = Agent 反思(自评自纠),reason = Agent 规划(目标分解)——本片的 reason-act-observe 是这两条更底层概念面向”loop”语境的口语包装。
作者还提醒一句看似反常识、其实关键的话:“the majority of tasks don’t need loops.”(05:27)。大多数任务,你只要一个 agent + 一个好的 prompt + 一次 terminal session 跑一遍就够,别上来就搭架构。
3. 验证比架构重要:何为”可机读的完成”
“We as humans are really, really good at defining what we want… we have to say, Okay, how do you know when that is done?”(04:44)
作者把”什么算完成”放在 loop 设计的核心位置。判断标准是 Definition of Done——他强调必须用尽量客观、可自动验证的方式表达:不要写”until you’re satisfied”,要写”average score >= 9”或”build succeeds”。
理想形态:loop 内每轮都要做一次自动检查,把”我做完没”变成”测试是否通过”或”指标是否达标”这种机器可验的硬信号。这一点,作者在 10:46 又用两个连续提问钉死:
“What does done mean? And then how will it check?”(10:46)
如果这两问答不上,loop 跑出来基本是”看起来完成”而非”真的可用”——这是个全片反复出现的主题。具体怎么”check”因任务而异,作者用三个真实任务分别示范。
4. 三种 loop 形态:solo / maker-checker / manager-with-helpers
作者在 05:29 给出三档可复用的 loop 形态:
- Solo loop:一个 agent 独自 reason-act-observe-repeat(他自己最常用的一档,见 05:27)
- Maker-checker loop:一个 agent 做活、另一个 agent 打分反馈——这与 Builder-Validator pattern 的核心思路一致,只是作者给它起了个更短的名字
- Manager-with-helpers loop:一个主 agent 当调度,分派多个 subagent 各自跑 loop,主 agent 居中收拢——这是 Multi-Agent 设计模式 的常见落地形态
这一档分类的实操含义是:不要一上来就搭第三档,先确认 solo 真的扛不住,再考虑加 checker,最后才上 manager。作者本人在 02:02 明确说:“Just having them do 24/7 work for me isn’t helpful”(02:02)——24/7 持续跑不是默认目标,人/任务的节奏决定 loop 的节奏。
5. Demo 一:缩略图打分(主观判据的失败模式)
第一个 demo 是 Matthew Berman 的 loop library 里的一条 prompt(06:18)。让 Claude Code 用 MrBeast 风格 rubric(清晰度、好奇心、情绪张力、视觉对比度)出 10 个缩略图概念,自评打分,挑前 3,各自找最弱项改一版,再重打分,最后在最强那个上继续迭代 “until you’re satisfied”(07:10)。最终跑出 V3,耗时 27 分钟。
这条 loop 的痛点作者当场点名:“until you’re satisfied” 是主观判据,容易让 agent 跑 3 小时还不肯停。如果想让 loop 更稳,应该让”打分”这件事本身交给一个独立的 scoring subagent,并事先在 eval 上校准它的评分一致性。这条 demo 的价值是把”主观 stop criteria 不可机读”这件事变成一个看得见的失败样本。
6. Demo 二:Three.js 飞机 + Abbey Road 复刻(客观判据的力量)
第二个 demo 是同一条 3.js 飞机 prompt,作者没细读但演示了结果:loop 反复开浏览器、旋转、检查渲染是否正确,最终在 V_N 给出一架能转动的 3D 飞机,比一次性”build me a 3D plane with, you know, 3.js”高到不知道哪里去(08:57)。关键差异:本次 loop 把”渲染对不对”作为可机读的判据——浏览器截图本身就成了 verification。
第三个 demo 是 Abbey Road 复刻:让 agent 用纯 HTML/CSS 复刻那张披头士封面图。loop 跑过 7 个版本,作者把 prompt 全文贴出来:
“If the average is above nine or equal to nine, then stop. And that’s when you end. The other thing it said is hard cap on eight passes.”(09:36,09:39)
也就是同时设了一个客观停止条件(分 >= 9)和一个 hard stop(无论分多高,8 轮就停)——“It was getting near that cap either way”(09:41)。这条 demo 的最终视觉极差(作者自嘲”yellow, black, gray, light blue… nothing like the picture”),但它把 verification 这个骨架完整跑通:每一版都自动截图、自动对比、自动评。每次截图后的 reflection 都是可机读的反馈信号,而不是主观判断。
把两个 demo 放一起,作者在 10:25 用一句话收口:
“The point being, it had the verification checks, it had the ability to take screenshots and look through each of its iterations.”(10:27)
结论很硬:loop 永远不会一次到位,但有 verification 的 loop 远比”一次对话”逼近终态;判定一个 loop 失败的标准不是它跑得慢,而是它的 done criteria 不可机读。
7. 让 loop 真正能用的 8 件套,以及它是否适合你
作者在 12:40 把”什么样的 loop 才真的能跑起来”压缩成 8 个要素(12:40):
- 可机读的 goal(对照 Definition of Done)
- Hard stop(如 8 轮上限,见 Abbey Road demo)
- 配套工具(verification 步骤必须能调起截图/跑测试等具体动作)
- memory(loop 跨轮要能记住前几版的产出,不能从头来)
- 独立 checker(打分 agent 与做工 agent 分离,见 Builder-Validator pattern)
- planning first(reason 阶段要先把任务拆开,见 Agent 规划(目标分解))
- logging(每一步要有可回看的记录,便于事后调 stop criteria)
- cost-vs-价值校准(loop 会烧 token,要给个”什么时候该停”的预算护栏)
作者自陈”a couple loops that have gone for 12 hours plus”(12:25)基本都不太有用——他更常用的形态是 35 分钟到几小时的”overnight run”——睡前发一个 loop,醒了看结果,这是 Ralph Loop 思路与 定时自动化循环 的混搭,而非”跑 4 天”那种常驻 worker。
最后是”是否适合你”这一段,作者明说:Peter Steinberger 那类写 agent 的 hardcore coder 适合把 loop 当主战场,你做知识工作、只是偶尔让 Claude Code 写点东西,套这套架构往往 over-engineer。You don’t have to drop everything and go try it. 这条提醒虽然口语化,但实操上对应一个反 FOMO 的核心方法论:用架构的门槛 > 任务本身的复杂度时,别上架构。
可执行步骤
- 在写任何 loop 之前,先回答两问:「什么算 done?」「怎么自动 check 出来?」答不出就别动。
- 把「打分 / 验证 / 截图」这类步骤独立成第二个 agent 或子任务,别让同一个 agent 既做工又自评。
- 任何”until you’re satisfied”类的停止条件,优先重写成可机读的硬条件(score >= 9、test passes、N 轮上限)。
- loop 跑 1 小时还没出结果就停手,人介入检查 done criteria 是否过严,而不是继续等 token 烧完。
- 第一次写 loop 直接用 solo 模式,确定 solo 真扛不住再上 maker-checker,最后才考虑 manager-with-helpers。
关联
- 印证:Definition of Done 与本片「可机读的完成判据」是同一概念,本片补充了一个具体反例(缩略图打分的 “until you’re satisfied”)和两个正面范本(average ≥ 9、8 轮 hard cap)。
- 印证:Builder-Validator pattern 在本片以「maker-checker loop」名再次出现,本质是同一种 1:1 doer+checker 拓扑,本片用缩略图 demo 给出该模式在主观判据任务上的失效案例。
- 印证:goal 在本片以「loop engineering」名展开,补充实操门槛(verification + hard stop)与”多数任务不需要 loop”的反 FOMO 边界。
- 互补:Ralph Loop 强调 PRD/任务清单驱动 + 测试门禁完成即停,本片强调”循环内每轮都有 verification”——前者管停止(完成即停),后者管内部(每轮自检),拼起来是更完整的”长任务自动化”。
- 同批互补:本片讲清 Agent loop 骨架与 Loop engineering 门槛后,Loop Engineer 入门 给”怎么把 loop 环境搭起来”的建造侧,Loop engineering 真香还是噱头 给”三大代价 + Harness 化”的批判侧。三篇合看是同主题的概念/建造/代价闭环。
一手来源与延伸
- Matthew Berman 的 loop library — 本片 demo 一、demo 二的来源,作者在 0:13 之后两次点名引用,内含可克隆的 Claude Code slash goal prompt 模板(具体仓库链接请自行检索,本笔记不收录未核验 URL)。
- Boris Cherny 的「不再 prompt coding agent」原帖 — 0:17 起被作者作为 loop engineering 兴起的标志事件引用;本笔记不收录未核验的社媒 URL。
术语
- Agent loop(代理循环):让 AI 反复 reason → act → observe 直到命中停止条件的运行模式。
- Loop engineering(循环工程):Nate 用的术语,指用一套系统替代人”反复去 prompt agent”的设计活动。
- Reason-Act-Observe(推理-执行-观察):agent loop 的三步骨架,也被作者简写为 think-act-see。
- Verification loop(验证循环):loop 内每轮 act 之后的”自检”环节,通常靠截图 / 测试 / 评分等可机读手段实现。
- Hard stop(硬停止):用最大轮数 / token 上限 / 时长上限给 loop 强制设的退出条件,与”until satisfied”型软停止相对。
- Definition of done(完成判据):loop 是否结束的可机读判断;本片反复强调必须客观、可自动验证。
- Solo / Maker-checker / Manager-with-helpers loop:loop 复杂度的三档分类,从单 agent 到 1:1 doer+checker 到 1:N 调度。
金句
“Loop engineering is replacing yourself as the person who prompts the agent. You design the system that does that instead.”(00:48)
→ 一句话把”loop engineering”从营销话术拉回具体动作:用系统替代自己反复去 prompt 这件事,而不是”造个超复杂的 agent 集群”。
“The point being, it had the verification checks, it had the ability to take screenshots and look through each of its iterations.”(10:27)
→ Abbey Road demo 视觉上完败,但骨架完美——判定一个 loop 失败靠”输出”还是靠”verification 是否可机读”,本片给的答案是后者(quote 后半句”understand how did this still not look like… what changes do we need to make”紧接同一段口播,虽不在此引文内但同段)。
立场与利益
- 与利益同向:「verification 决定 loop 好坏」这一主张——这是该作者本人在 Skool 社群里(免费 + 付费两档,见 description)反复兜售的”loop engineering”框架;主张本身是普适方法论,可独立验证,但采信前需自行对照其他来源——本片未点名同类替代方案,需要自己找。
- 利益中性:「多数任务不需要 loop」「solo loop 是最常用形态」——这两条劝你别买课也跑不远的主张对作者自己的”系统化 loop”营销不利,但作者依然明说,属于”承认短板型”主张。
- 与利益反向:「Peter Steinberger 那套是给 hardcore coder 看的,做知识工作的你不必照搬」——这条提醒把”如果你不跟大牛同节奏你就落后”的常见焦虑话术直接拆掉,与作者卖课冲动相反,可信度最高。
价值定位
本片面向刚开始接触”agent loop”概念、但对”是否要搭一套 loop 框架”还在犹豫的 Claude Code 用户——典型场景:每天用 Claude Code 做几小时知识工作或非大型代码任务,看到 Boris Cherny / Peter Steinberger 等人在喊”不再 prompt、只写 loop”,想知道这套东西对自己到底有没有用。
- 适合谁:已经在用 Claude Code 跑 slash goal 或
/goal的人;听过「agent loop」但被各种定义绕晕的人;对 Matthew Berman loop library 里 prompt 好奇但不会挑的人。 - 解决什么:把”agent loop”统一成 reason-act-observe 一个骨架;把”该建什么 loop”压成 8 条具体要素;用三个真实 demo 演示 verification 怎么写才算可机读。
- 认知 vs 实操:以认知为主,实操有限——具体 loop 模板、scoring agent 的 prompt、overnight run 怎么排都不在本片,需要去作者 Skool 社群取。
- 独有:本片在「verification > 架构」「多数任务不需要 loop」「你的工作用不上 Peter Steinberger 那一套」三个点上是较少见的反向声音,与多数 loop 营销内容形成对照。
自检问题
- 作者给”loop engineering”下的最简定义是什么? 答案:用一套系统替代自己作为”反复去 prompt agent 的人”,由人去设计这套系统。00:48
- Agent loop 的三步骨架是哪三步? 答案:reason(推理)→ act(执行)→ observe(观察),三者循环直到命中停止条件。02:51
- 缩略图 demo 的失败点是什么,作者建议怎么修? 答案:失败点是用了 “until you’re satisfied” 这种主观停止条件,容易让 loop 跑 3 小时还不停;修法是把打分交给一个独立的 scoring subagent,事先在 eval 上校准评分一致性。07:10
- Abbey Road demo 同时设了两个停止条件,分别是什么? 答案:一是客观条件 average score >= 9 即停,二是 hard cap 8 轮上限(无论分多高 8 轮就停)。09:36、09:39
- 作者在「适合谁」一段对 Peter Steinberger 那类宣传的明确态度是什么? 答案:作者明说”that doesn’t mean you have to drop everything right now and go try it”,不否认他人用法,但反对把那条路径默认套到知识工作者身上。13:10