黄仁勋：Prompt正在过时，Loop才是新范式

Prompt已死，loop当立

这就是最近网上热传热议，然后老黄黄仁勋给AI新趋势画的新重点：

• Nobody writes prompts anymore. The new job is to write and handle loops.（现在根本没有人写Prompt了，新时代的核心工作是编写和管理loop。）

啥是loop？这个词直译过来是“循环”，换成AI圈的说法就是：

你不再亲手给AI下指令，而是设计一个系统，让系统替你下指令、替你验收、不合格自己重来，直到活干完

嗯？这不就是如今Agent那一套吗？为啥又搞个新概念出来？

暂且按下此疑惑不表，待我环顾一圈后发现，这个“loop”还真挺火——

除了老黄，“龙虾之父”Peter、“Claude Code之父”Boris Cherny、吴恩达等一众大佬全都在谈、在大力推loop。

• （Peter）别再给编程Agent写提示词了，去设计循环，让循环替你提示Agent。

• （Boris）我已经不给Claude写提示词了。我有一堆循环在跑，是它们在给Claude下指令、决定下一步做什么。我的工作，就是写循环。

而当“写loop”取代“写prompt”成为大佬们新的日常，loop显然已经越过了“又一个新概念”的阶段。

剩下的问题就只有：

loop具体是指什么？它怎么就突然火起来了？

loop到底是什么

要理解loop这个新东西，我们得先回顾一下之前的那套旧范式。

过去两年AI编程的标准动作是这样的：

你写一条prompt，AI吐一段代码，你看了不满意，再写一条，AI再改，你再看……

反正就是来回拉锯，人全程盯着。

卡帕西之前还侧面吐槽了“人就是瓶颈”这件事，而且劝告大家：

• 你不能坐在那里等着给每一步写prompt，你得把自己从流程中抽离出来

把人从流程中抽离出来，这正是loop要解决的事。

其核心逻辑只有一句话：

你定义一个目标，AI自己跑，跑完自己验收，不合格带着报错再来一轮，直到通过或者撞上预算上限才停。

此时人的角色就从“传话人”变成了“规则设计者”。

所以回到开头的疑问：这跟Agent有什么区别？

显而易见，Agent是干活的那个人，而loop是让这个人不用你盯着也能持续干活的那套管理机制。

没有loop的Agent，你提一句它动一下，本质上还是个听话的工具。

套上loop的Agent，才真正变成了一个能自转的系统。

原理听起来确实不复杂，但貌似仍有点抽象。

别急，我又去翻了下当前loop的实际落地情况，结果发现它其实已经藏在了我们熟悉的系统里。

围绕loop，产品落地层目前已经形成了“双雄对峙”格局

一个就是大家天天都在用的Claude Code，它围绕loop做了三件套：

/loop负责定时循环，/goal负责目标驱动（跑到验收条件满足为止），/schedule负责云端定时任务（合上电脑也能跑）

其中最精妙的设计是/goal，它背后藏着loop最关键的一条原则——自己不能判自己的卷子。

Claude Code把这条原则直接写进了产品架构：

写代码的是大模型，验收的是另一个独立的小模型Haiku，两个模型各司其职。

这样一来，Agent不会自己给自己打高分，验收才有真实的约束力。

另一个就是OpenAI Codex。

Codex的玩法更接近“自动化流水线+目标驱动+多个子Agent”的组合，在一些开发者的实际体验中，能看到最多8个Agent同时跑在各自的云端沙箱里，各干各的活，最后把结果汇总回来。

有意思的是，虽然两家的实现路径不太一样，但最终长出来的形态高度相似——

都是把复杂任务拆碎，分给多个Agent并行去跑，再统一汇总。

在公开评测和社区口碑里，两者的表现也已经非常接近。

这也说明一个问题，模型本身已经卷不出太大差别了，真正的差距在上层的loop编排

说到这儿，咱们直接看看“Claude Code之父”Boris Cherny每天怎么工作的就全明白了。

他自述去年11月卸载了IDE，一个月没打开过，索性删了。

现在他手下几百个小Agent同时跑，有的扫GitHub issue，有的读Slack上的用户反馈，有的监控CI失败。每个Agent在自己隔离的代码分支里干活，一个写代码，另一个跑测试验收。

搞不定的才进他的收件箱，等他来做判断。

据他透露，自Opus 4.5以来，其所有代码都是Claude Code写的，如今大部分代码都是直接在他的手机上完成。

• 接下来是循环，Agent之间互相提示，中间无需人工审核。

看到没，loop的终极形态已经很清晰了：

人不写代码，也不写prompt，只写规则和判断，剩下的全交给loop

怎么loop起来

那么，我们该怎么loop起来呢？

X上有个叫Codez的博主已经都替大家总结好了，他发了一份14步实操roadmap，这里我挑了一些干货。

step 1：先别急着建，先做“4条件测试”

loop不是什么活儿都能往里面塞，瞎建只会亏钱。

在动手之前，先回答四个问题：

• 任务重复发生吗？
• 有自动化验收手段吗？
• Token预算扛得住吗？
• Agent有“高级工程师”的工具吗？

图片由AI生成

四个全过，才值得建loop。

step 2：从最小可行loop开始

第一次别搞花活，就建一个四件套：

• 一个触发器（Automation）：定时跑、事件触发跑都行。Claude Code里用/loop，Codex里用Automations面板。
• 一个技能（Skill）：把项目上下文写进STATE.md，让每次运行不用重新解释一遍。
• 一个状态文件（State File）：用Markdown记下“做到哪了、什么成了、什么挂了”，下次接着跑。
• 一个门禁（Gate）：测试、类型检查、构建——能自动拦住坏结果的东西。

而且顺序很关键：先手动跑通一次→写成Skill→包进loop→最后才上定时。

• 跳步是loop死在生产环境的主要原因。

step 3：做“拆卷子”的人，别做“判卷子”的

整个loop设计里最重要的一条原则前面已经提过了——写代码的和验代码的，必须分开。

落地到具体操作就是：

用一个模型（或者子Agent）负责写，用另一个独立的模型（或者子Agent）负责验收，验收的那个不能看到写代码的那个的推理过程。

为什么这很重要？因为模型给自己写的代码打分时，往往“手太松了”。

所有“看起来不错”的代码，在独立验收器面前大概率能挑出一堆毛病。

step 4：别人踩过的坑就别再踩了

附几个避坑指南。

1、没有硬停止条件。loop跑到你发现账单或者被限流才停，所以需要设Token上限、迭代次数上限、时间限制。

2、状态不落地。Agent的记忆是短时的，今天学到的东西明天就忘了，所以需要写进状态文件（STATE.md），每次运行接着读。

3、让loop碰“需要判断”的活。架构重写、鉴权代码、支付逻辑、产品方向决策，这些别让loop碰。loop适合干“对错清晰、机器可验证、不依赖人的判断”的活，比如Lint自动修复、依赖更新PR、CI失败分类、Flaky测试复现。

4、不读Diff。loop合入代码越来越快，你对代码库的理解越来越浅。这叫“理解力债务”——真正的代价不是Token账单，而是某天你要调试一个团队里没人读过的系统。所以建议你读Diff，哪怕只是扫一眼。

step 5：衡量指标就一个

别管烧了多少Token、开了多少PR、跑了多少次任务。

唯一有用的指标是：每个被接受的改动，平均成本是多少

如果你的“被接受率”低于50%，说明你在做loop本该替你省掉的评审工作，即loop在亏钱。

从提示词到loop，四次范式跃迁

原理和方法搞懂了，最后的问题只有一个：

loop为什么现在火了？

虽然严格来说，loop Engineering这个概念只有不到三周的历史。

但它不是凭空蹦出来的，往回拉一下时间线就能看到一条很清晰的演化路径。

这条路径大佬们也已经替大家总结好了，咱直接抄作业：

从Prompt→Context→Harness→loop，一共四次

简单来说，从2023~2024年，这是Prompt Engineering的天下。

当时大家都在琢磨一件事：提示词怎么写才能让AI好好干活。

写得好和写得不好，出来的东西天差地别，所以那会儿“会不会写prompt”基本就等于“会不会用AI”。

这一阶段，人和AI的关系还停在最表面那层——你说一句，它回一句，细到每一个指令都要人亲自敲。

但随着模型能力增强、上下文窗口变长，以及RAG和代码库接入逐渐普及，问题开始发生第一次迁移。

大约在2024到2025年前后，行业开始强调“Context Engineering”的重要性，关注点从“怎么问”变成了“给AI看什么”。

也就是说，AI不再只依赖一句提示词，而依赖你提供的整个背景。

这一阶段，信息组织能力开始比写prompt更重要，控制粒度从“一句话”上移到了“一堆信息”。

到了2025~2026年，随着Agent系统逐步进入真实开发流程，问题继续往外扩展。

这时人们发现，光给信息和上下文也不够了，AI得能接工具、能跑代码、能调接口、能走权限审批。

因此，你得给它搭一个能干活、能约束、能调取真实世界资源的运行环境。

“Harness Engineering”正是为此而生。

而在Harness的基础上，“loop Engineering”成了最新的进化方向。

如果说Harness解决的是“AI能不能在真实环境里干活”的问题，那loop解决的就是“AI能不能在这个环境里持续干活、自己推进任务、不需要人一步步盯着”的问题。

它的核心不再是单次执行能力，而是一个闭环系统的运行能力。

所以从Prompt到Context，再到Harness，再到loop，看起来像是概念的更替，但本质上是一条连续的迁移路径：

人类对AI的控制粒度不断上移，从“写一句话”，变成“提供信息”，再变成“搭建系统”，最终变成“设计循环”

一个逐渐解放人类双手的过程。

实际上，虽然loop这玩意儿刚在工业界火起来，但学术界其实早就有了类似理念。

而且很多重要工作都和我们今天熟悉的一个人有关：姚顺雨（腾讯那个）。

他在大模型Agent方向最具代表性的工作之一，是2022年的ReAct框架（Reason+Act）

这篇工作在ICLR 2023拿到Oral级别，也在后续获得了上万引用量。

ReAct做了一件很关键的事：把“推理”和“行动”绑定成一个循环过程

大模型不再是一次性输出答案，而是先进行可解释的思考，再调用工具执行动作，执行之后再观察环境反馈，然后进入下一轮推理。抽象出来就是：

• 思考→行动→观察→再思考→再行动…

这个结构本质上就是一个最早被系统化表达的“agent loop”雏形。

在ReAct之后，这条路线被不断扩展，比如Reflexion引入“从错误中学习”的反馈机制，Tree of Thoughts扩展成多路径搜索式推理，以及后续一系列tool-use agent工作逐步完善“规划+执行+反馈”的完整链路。

这些学术成果一点一点往前拱，最终才在工程界收敛成今天所说的“loop系统”。

所以从学术视角看，loop不是某一个人的发明，它是一条逐步收敛的技术路径。

只不过在这条路上，恰好有个我们熟悉的华人站在了一个关键节点上。

最后不得不感慨，从Prompt到loop，AI的发展还是太快了。

太快带来的后果是，有人兴奋激动，也有人难掩担忧。

而loop Engineering的命名者、Google工程主管Addy Osmani，正是后者当中的一员。

他在《loop Engineering》这篇长文里写得很明白：

• 还很早期。我持保留态度。token成本你必须非常小心。

卡帕西的话更让人深思，他在红杉资本AI Ascent 2026大会上引用过一句让他本人反复回想的话：

• 你可以外包你的思考，但你没法外包你的理解。

翻译翻译，AI可以替你想办法，但你自己得真懂问题本身。

这大概是整场loop热潮里最清醒的声音。