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 热潮里最清醒的声音。
