Loop 到底是什么：AI 编程正在从 Prompt 走向后台编排

引爆争论的不是技术名词，而是工程角色的变化

这轮 AI coding 讨论之所以会炸开，不是因为大家第一次见到循环执行，而是因为 Peter Steinberger 把一句话说得非常极端：别再 prompt coding agents，而该去设计能替你 prompt agents 的 loops。它击中了很多人的直觉：大家已经隐约感觉到，真正拉开差距的那层，不再只是“会不会写一句好 prompt”，而是“有没有能力把 agent 放进一套稳定、可重复、可长期运行的系统里”。

“Here's your monthly reminder that you shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents.”

Matt Van Horn 这篇长文厉害的地方，不是跟风喊口号，而是把这句话拆开，追问它到底在说什么。作者最后得出的核心判断很清晰：loop 的重点不是模型更聪明了，而是工程抽象层级又上移了一层。以前你亲手写代码，后来你亲手 prompt agent，现在开始，你在设计让 agent 自己工作、自己检查、自己继续的后台流程。

所以这场争论真正值得翻译成中文的，不是“loop 是不是新瓶装旧酒”，而是它在逼每个工程团队回答一个问题：你是在使用 AI，还是在运营一个 AI runtime？

Loop 到底是什么

如果只用一句大白话解释，loop 就是一个你写的小程序或工作流，它会帮你完成下面这件事：

• 把任务交给 coding agent；
• 读取 agent 产出的代码、日志、测试结果或评论；
• 判断任务有没有完成；
• 如果没完成，就继续追加上下文或触发下一轮；
• 必要时再调另一个 agent 去修、审、验证或拆子任务。

换句话说，你不再亲自站在回路内部，一轮轮盯着对话框输指令。你开始站在回路外面，定义输入、停止条件、验证条件、升级条件、预算边界。模型在这里不再是主角，它只是 loop 里的一个决策器或执行器。

“Now I don't prompt Claude anymore. I have loops that are running. They're the ones that are prompting Claude and figuring out what to do. My job is to write loops.” — Boris Cherny

这句话为什么重要？因为它把角色切换说得很彻底：人从操作员变成编排者，模型从助手变成子程序。如果你接受这个视角，那你接下来关心的就不会是“这个 prompt 有没有更花哨”，而是“这个 loop 如何验证、如何恢复、如何节流、如何停止”。

Loop 的五代谱系：从 ReAct 到后台编排

“loop” 之所以在社交媒体上经常鸡同鸭讲，是因为它至少混了五层不同语义。把这五代谱系捋清，很多争论会自动消失：

第一代：ReAct 的学术 while-loop

模型思考、调用工具、读回结果、继续推理。一个模型，一个任务，人类在旁边盯着。这是最原始的 agent loop。

第二代：AutoGPT 的目标自驱动

给定一个目标后让它自己持续 prompt 自己，想法很激动人心，现实里却经常空转、幻觉和无限循环，给行业留下“agent 很会自嗨”的坏名声。

第三代：Geoffrey Huntley 的 ralph loop

真正实用的改进不复杂：每轮都重置到稳定锚点，避免对话无限膨胀；用固定 prompt 文件和固定上下文，而不是让 agent 在历史消息堆里迷路。它把“纪律”引进了 loop。

第四代：/goal 和产品化 loop

到了 2026 年，Codex 和 Claude Code 开始把这种能力收编成正式产品，用户不用自己先写一层 bash while-loop，就能获得“继续直到做完”的执行体验。

第五代：orchestration loop

这才是当前真正的新层：一个 loop 不只是管一轮任务，而是能并发调度多个 agent、定时运行、跨会话续跑、持久保存状态、在崩溃后恢复。单 agent 的 ralph loop 在这个语境里已经不新，新的部分是它被包进了一个更重的 runtime。

所以，Matt Van Horn 文章里最值得保留的判断是：今天被称为 loop 的东西，核心不是 while，而是 orchestration。

它是不是只是一个“戴帽子的 cron”？

这是整个讨论里最尖锐也最健康的吐槽。答案应该分两半说：

• 是：调度层确实很像 cron，甚至很多真实系统底层就是 cron 在触发。
• 不是：cron 运行的是固定脚本，而 loop 的执行体里放着一个能基于当前状态做决策的模型。

普通 cron 更像闹钟：时间到了就执行固定动作。loop 更像值班经理：它不仅被叫醒，还会看现在发生了什么、决定该怎么做、做完要不要继续、要不要升级处理、是否已经超预算。

更准确的说法不是“loop 是新魔法”，也不是“loop 只是 cron 换皮”，而是：

Loop = 调度器 + 决策器 + 验证器 + 停止条件 + 持久状态。

如果你只拿到了调度器，那还只是 job；如果你把后面四层都包起来，它才开始像一个值得单独命名的 runtime 单元。

while within_budget() and not done():
    task = planner.decide(state)
    result = agent.run(task)
    evidence = validator.check(result)
    state = memory.update(task, result, evidence)
    if no_progress(state):
        break

这段伪代码看起来没什么神秘感，但生产价值恰恰来自这份“不神秘”：loop 的价值不在语法，而在你把哪些工程约束放进这个骨架里。

Loop 真正的门槛不在编排，而在验证闭环

这篇原文里我最认同的一点，是它明确把焦点从“多 agent 很酷”拉回到“verification 才是决定成败的东西”。一个没有反馈闭环的 open loop，生成的不是自动化，而是更快的错误累积。

为什么很多人第一次做 agent 自动化会翻车？因为他们只定义了“让它继续干”，却没定义“怎样算干对了”。于是系统只能不断地产生看起来合理的提交、回复、总结或修补，但没有任何一层在持续问：它真的工作了吗？真的修好了吗？真的符合目标吗？

真正能上线的 loop，至少要有三类验证器：

• 结果验证：测试、lint、编译、截图比对、DOM 检查、schema 校验。
• 过程验证：是否卡在同一步、是否重复同一类报错、是否在低价值地重试。
• 风险验证：是否触发删除、发布、写外部系统、超权限操作，需要升级到人工确认。

真正可用的 loop 不是“写 → 写 → 写”，而是“写 → 跑 → 看 → 判 → 再写”。

如果你已经在用 Hermes、Claude Code、Codex，这个判断尤其重要：prompt 可以临时写，validator 必须长期养。前者是消耗品，后者才是生产资料。

新的成本中心：不是写代码，而是管理 loop

社交媒体很容易把 loop 描述成“一次设置，永久起飞”的自动驾驶。但真正进入生产后，你会发现最贵的已经不是单次模型调用，而是整条回路的治理成本。

原因很简单：如果模型本身越来越便宜，真正烧钱的就是这些问题：

• 它会不会无限重试？
• 它会不会在错误方向上高速前进？
• 它会不会把一条小问题放大成很多次无意义的调用？
• 它会不会同时开太多 agent，导致成本和噪音一起爆炸？

因此 2026 年以后谈 loop，不能只讲“更 autonomous”，还必须同步设计三类硬停止：

1. 最大迭代数：超过 N 轮就停；
2. 无进展检测：连续几轮没有新增证据或没有降低失败数，就停；
3. 预算上限：按 token、美元、运行时长、并发数任意一项触线即停。

这是原文那句 punchline 的真正含义：贵的不是模型，而是 loop management。你不只是买了一台会写代码的机器，而是接手了一套要被治理的生产系统。

比 loop 更值钱的，是它调用的 skill

Matt Van Horn 文章最后的落点非常对：loop 只是 plumbing，skill 才是资产。这句话适合直接刻在所有 agent 团队的墙上。

为什么？因为 loop 本身不生产知识，它只负责搬运、调度和复用。真正让系统复利的，是这些内容有没有被沉淀成稳定 skill：

• 这个项目如何启动与验证；
• 某类故障应该先查什么、后查什么；
• 发布前有哪些硬门禁；
• 什么情况下必须停下来交给人工；
• 某类任务的输出格式和质量标准是什么。

如果这些经验每次都靠 agent 现场即兴发挥，那 loop 只会重复花钱重新发明轮子。相反，如果你把它们固化成可命名、可触发、可更新的 skill，那么 loop 就能以很低的边际成本调用成熟能力。

把这个视角放回实际工作，会得到一个非常实用的优先级：

1. 先把高频动作抽成 skill；
2. 再给每个 skill 配上验证条件；
3. 最后才讨论要不要把它们串进 loop 自动跑。

顺序别反。先上 loop、后补 skill，通常只会把混乱自动化。

给 Hermes / Codex / Claude Code 的落地清单

如果你看完文章想马上开始搭第一套 loop，最稳的不是一上来做“全自动开发团队”，而是先从一个闭环短、风险可控的场景切入。下面这套清单基本适用于 Hermes、Codex、Claude Code、Cursor Agent 等所有工具：

1. 先选一个高频但边界清楚的场景

比如：PR 守护、日报整理、固定格式的数据清洗、例行站点巡检、评论修复、回归测试。不要一开始就上“帮我持续推进整个项目”。

2. 把 skill 写出来，再决定要不要循环

先把任务步骤、输入输出、风险边界、验证方式写成 skill / runbook。没有 skill 的 loop 只会重复猜。

3. 为 loop 设计 5 个必备字段

• goal：目标是什么；
• state：当前知道什么、做到哪里；
• validator：什么证据算成功；
• stop rules：什么时候必须停；
• escalation：什么情况转人。

4. 不要只给“做什么”，还要给“怎么证明做成”

例如“修好 PR”不够，应该写成：修好 PR，直到 CI 通过、关键 reviewer comment 被回复、`git diff` 只覆盖目标模块。

5. 把状态外置，不要只活在会话里

用 git、文件、数据库、任务板、issue comment、session recap 等任一种外部状态面，让 loop 在重启后还能知道自己做到哪一轮。能恢复，loop 才能真正后台化。

6. 把人工确认放在高风险边界，而不是每一步

读文件、跑测试、生成草稿这种事可以自动。删除、推送、上线、外部发送、资金相关、权限变更等动作必须升级到人工 gate。

7. 从单 loop 开始，再考虑 loop of loops

很多团队一上来就想 orchestrate 多 agent，结果一层都没稳。更健康的顺序是：先做一个能稳定自证的单 loop，再让它去协调 review loop、fix loop、report loop。

四个现在就能落地的 loop 原型

如果要把抽象概念落到“今晚就能做一个”的程度，我建议从下面四个原型入手：

原型 A：PR babysitter loop

定时扫自己负责的 PR：检查 CI、回复评论、在本地 worktree 修小问题、重新跑验证。这个场景天然有清晰状态和停止条件，非常适合练手。

原型 B：site watchdog loop

定时检查页面可达性、关键 DOM、证书、构建产物、截图差异。它不需要很强创造性，但特别适合把“验证优先”的习惯养起来。

原型 C：research-to-brief loop

按固定主题拉取信息源、去重、排序、摘要，再把最终版本输出到 Telegram。这里的关键不是抓取，而是筛选标准和版式标准是否已经沉淀成 skill。

原型 D：comment-to-fix loop

监听 issue / PR comment 或消息队列，把明确问题交给 agent 修，再交给 validator 决定是否闭环。这类 loop 的价值在于把“收到反馈 → 修复 → 再验证”做成自动流水线。

这四类原型有个共同点：它们都不是让 agent 自由探索世界，而是在一个边界清楚、证据清楚、停止条件清楚的局部回路里迭代。这正是 loop 最容易成功的地方。

什么时候不该上 loop

最后要泼一点冷水：不是所有任务都值得 loop 化。以下几类场景，今天仍然更适合直接对话、人工执行或半自动：

• 目标本身不清楚：连成功标准都没说清，自动化只会把歧义放大。
• 反馈特别慢：一轮验证要几个小时甚至几天，loop 很容易变得昂贵而迟钝。
• 高不可逆风险：涉及删库、对外发布、客户消息、资金流转，没有强人工 gate 别放开自动跑。
• 技能本身还没稳定：人都还没把流程做顺，就先让系统去重复，往往只是稳定地重复错误。

判断一个任务是否适合 loop，有个很好用的问题：如果这个任务交给一个非常勤奋但不够聪明的实习生，我能不能用一套 checklist 把它管住？ 如果答案是不能，那它大概率也不适合直接 loop 化。

结语：别再只学怎么问 AI，要学怎么运营 AI

把这篇文章翻成中文之后，我觉得最应该留下来的，不是“loop 这个词很潮”，而是这句话背后的工作方式变化：AI 编程正在从一次性 prompt，过渡到后台运行的持续系统。

这意味着工程师、产品经理、独立开发者接下来最重要的能力，会越来越像这些词：skill design、validator design、state management、handoff、budgeting、escalation、orchestration。它们共同构成的，不再只是“会不会用 AI”，而是“能不能把 AI 纳入生产系统”。

所以这篇文章的最终答案可以压缩成一句话：

别再总想着自己待在 loop 里给 agent 下指令；把高频动作沉淀成 skill，把验证做成门禁，把停止条件写清楚，然后让 loop 在你睡觉时继续工作。

Peter Steinberger 说的是抽象层级上移，Boris Cherny 说的是工程角色上移，Matt Van Horn 说的是成本中心上移。把这三句话合在一起，你就会明白：2026 年之后，AI coding 的主战场已经不只是模型，而是 runtime。