夜雨聆风在之前的文章里，我写过一个判断：AI Agent 开发越来越快，人反而开始成为卡点。
后来我越来越确定，问题不是 AI 不够强，而是工作流还停在“每一步都等人确认”的模式里。AI 已经会跑了，但路上每隔一小段就有一个人工确认口。
所以我后来在工程迭代里搭了一个多 Agent 的迭代 loop。
做法并不神秘，有点像把一个聊天窗口拆成一支小队：产品 Agent 负责产品设计，技术 Agent 负责技术方案设计，编码 Agent 实现和自测，评估 Agent 从证据和用户视角验收，中间由总控 Agent 串起来。评估不过就返工，证据够了才收束；人仍然在，但不再卡在每一步确认中间，而是负责兜底、连接和拍板。
做完这套以后，我才发现，最近外面开始讨论的 loop engineering，本质上讲的就是这件事。只不过我一开始不知道它有这么时髦的名字。
这个词最近变热，很多讨论都在说，不要再只是手写一轮轮 prompt，而是设计能让 AI agent 持续执行任务的系统。
Business Insider 那篇关于 loop engineering 的文章里，提到了 automation、worktrees、skills、plugins/connectors、sub-agents 这些组件。
OpenAI 介绍 Codex 时，也强调它可以在独立云环境里读写代码、运行测试、给出终端日志和测试输出，最后交给人 review。
Anthropic 的 Claude Code 文档里，则把 subagents、hooks、skills、worktree isolation 这些能力拆得更细。
这些说法表面上是工具能力，背后其实是同一个方向：
AI 不再只是回答你的一句话，而是在一个有目标、有反馈、有边界的工程系统里推进任务。
接下来，我就结合这套实践，讲讲我是怎么理解和实践 loop engineering 的。
不是改 prompt，而是工作流
我一开始也以为问题是 prompt 不够细。
AI 做偏了，我就补背景。它改多了，我就补边界。它问我下一步，我就把“不要做什么”“遇到什么情况停下来”写得更长。写到后面，prompt 已经不像提示词，更像一份小合同。
这当然有用，但很快会遇到天花板。因为真正的问题不是某一句 prompt 不够好，而是整个工程工作流还在等我。
这套 loop 真正成立的核心，其实不是产品 Agent、技术 Agent、编码 Agent 或评估 Agent，而是总控 Agent。
因为没有总控，多个 Agent 只是多个执行者。它们各自很努力，最后一起把结论端到你面前，继续等你拍板。
总控 Agent 的作用，更像调度台。它不亲自把每个零件拧上去，但要知道谁该先动、谁该等、哪里该返工、哪里该叫人。
它的 prompt 结构大概是这样的：
你是本轮迭代的总控 Agent。输入：- 本轮目标：[本轮目标]- 输入材料：[用户反馈 / 日志 / 代码位置 / 上轮失败记录]- 允许修改范围：[允许修改范围]- 禁止触碰范围：[禁止触碰范围]- 必跑验证：[测试命令 / 日志检查 / 人工验收项]你的职责：- 判断 [本轮目标] 是否清楚；不清楚先停下来问。- 调度产品 Agent、技术 Agent、编码 Agent、评估 Agent。- 控制每个阶段能否进入下一阶段。- 记录关键决策、失败样例和返工原因。- 当风险超出 [允许修改范围] 时，把人叫回来。阶段：1. 产品设计：明确用户问题、目标体验、P0 / 非目标。2. 技术方案：把产品目标翻译成工程方案和验证方式。3. 编码实现：按边界实现并自测。4. 效果评估：根据证据判断通过、返工或叫人。5. 迭代复盘：分析本轮流程哪里需要优化。硬规则：- 目标不清，不进入技术方案。- 没有验证方式，不进入编码。- 自测和失败复验没完成，不进入评估。- 评估证据不足，不能假装通过。- 超出 [允许修改范围]，必须叫人。
这不是完整 prompt，只是示意。真正重要的是它背后的结构：总控 Agent 不直接替所有角色干活，而是负责判断目标是否稳定、阶段能不能往下走、失败要回到哪里、什么时候必须把人叫回来。
其他 Agent 的 prompt 就更像专门岗位，不需要都写成一大段合同。
比如产品 Agent，我更关心它能稳定交出一张“产品判断卡”：
你是本轮迭代的产品 Agent。输入：[用户反馈] [当前状态] [失败样例] [上轮遗留问题]你只负责产品设计，不写代码，不选技术方案。输出：- 本轮核心问题：[一句话说明]- 目标体验：[用户应该感受到的变化]- P0 / 非目标：[本轮必须做什么，以及明确不做什么]- 验收标准：[哪些证据说明目标达成]- 边界样例：[哪些情况必须特别验证]
这里最重要的不是多了几个 Agent，而是这件事从聊天变成了工作流。前者像一群人轮流发消息，后者更像一条能往前流动的小型产线。
还有一个细节很关键：聊天记录不能替代文档。
如果所有结论都只留在对话里，下一轮还是要靠人重新读上下文。工作流真正跑起来以后，每轮迭代都应该留下稳定产物：目标是什么，方案是什么，改了什么，测了什么，评估结论是什么，哪里需要返工。
工作流靠稳定产物让下一轮接得上。
prompt 解决的是一轮对话怎么问，workflow 解决的是一段工程工作怎么自己往前走。
必须知道什么时候停
loop 最危险的地方，不是它跑不起来，而是它停不下来。
它可以一直修改，一直总结，一直给下一步建议。看起来很努力，但如果没有停止条件，努力本身没有意义。
所以我在这套流程里提出了一个概念：门。
门不是形式上的审批，更像一套刹车和路牌。它告诉系统：这里可以继续，这里要返工，这里风险太高，得把人叫回来。
产品门解决的是目标稳定性。用户说“把这个功能优化一下”，听起来很正常，但这句话本身还不能直接进入技术方案。产品 Agent 要先把问题拆清楚：这次优化的是速度、交互、文案、稳定性，还是用户理解成本；本轮必须做什么，哪些先不做。这个门过了，后面的 Agent 才不会在一个模糊方向上越跑越远。
技术门解决的是可验证性。技术 Agent 可以提出方案，比如改状态管理、改接口处理、补异常路径，但它还要说明怎么证明方案有效：跑哪些测试，看哪些日志，复验哪些失败样例，哪些路径需要人工验收。这样编码 Agent 接到的就不是一句“去改”，而是一段有验证方式的工程任务。
编码门解决的是实现准出。编码 Agent 改完以后，除了给出 diff，还要留下自测结果、失败样例复验情况和没覆盖到的风险。这样评估 Agent 看到的不是一句“我改好了”，而是一组可以检查的证据。
评估门解决的是结果判断。评估 Agent 不负责帮代码找理由，它要看证据是否足够，体验是否真的变化，风险是否还在。如果不够，就回到方案或实现；如果风险超出边界，就把人叫回来。
如果涉及上线，还会多一道线上生效门。本地通过不等于线上生效，部署包准出也不等于用户真的用到了新行为。这个门的意义，是把“我本地验证过了”和“用户那里已经生效了”分开。
这些门的名字不重要。重要的是每一段工作都有一个判断点：现在是可以继续，应该返工，已经可以收束，还是需要人介入。
好的 loop 不只是让 AI 继续往前跑，也要让系统知道什么时候该慢下来，甚至停下来。否则它不是闭环，更像踩着油门找出口。
核心是反馈进化，不是自动化
我后来判断一个 loop 有没有价值，不只看它跑了多少轮，而是看每一轮之后系统有没有变得更聪明一点。跑圈本身不值钱，跑完以后知道下次怎么少摔一跤，才值钱。
如果一次失败只是被贴回聊天里，下一轮还是可能犯同样的错；如果测试挂了但没有归类，Agent 也不知道该优先修哪类问题；如果评估没过只是让编码 Agent 自己解释，那它很容易把失败说成“基本完成”。这些情况看起来都在循环，其实只是把同样的不确定性又搬运了一遍。
所以我真正看重的是两层反馈。
第一层是任务内反馈。
测试失败，会进入实现返工；日志异常，会作为排查证据进入下一轮；用户视角验收不过，会触发评估返工，而不是让编码 Agent 自己解释。失败样例也会被留下来，变成下一轮检查项，复验通过才算真的修掉。
第二层是流程级反馈。
每次迭代结束后，我不会只看“这次功能有没有做完”，还会回头看整个迭代过程哪里卡住了。
有时候是产品目标一开始没讲清，导致后面返工；有时候是技术方案没有把验证方式设计好，编码 Agent 做完以后才发现不好证明；也有时候是编码 Agent 边界不够清楚，改了不该改的地方；还有时候是评估 Agent 只看测试结果，没有从用户视角判断。总控 Agent 自己也会被复盘：它是不是太晚才裁剪范围，或者太晚才把人叫回来。
这些记录会反过来优化下一版 workflow 和 skill。
自动化只是让 AI 多跑几轮，反馈进化是让任务本身和这套 loop 都比上一轮更好。
loop 不是万能药
说到这里，容易把 loop 讲得很美，像什么任务都应该被装进一台自动运转的小机器里。
但我现在反而会更谨慎一点。
loop 的价值不是“完全不用人”，而是让低风险动作可以连续推进，让测试和检查先跑起来，让失败自动进入下一轮。
但不是所有任务都值得 loop。
简单直接的任务不需要，人 30 秒就能目检的改动，没必要搞一套多 Agent 流程。
探索型任务也未必适合，目标还没想清楚、反馈信号还没有，先 loop 起来很容易变成一堆 Agent 一起发散。
高风险任务更要谨慎，删数据、改 schema、动支付、生产部署，这些地方不是不能 loop，而是不能让 loop 自己越权。
还有一个很现实的问题：多 Agent 是烧 token 的，而且是倍数增长。这不是形容词，是账单。
我这套多 Agent loop 跑一次完整迭代，产品、技术、编码、评估、总控每个角色都要读上下文、写结论、再互相衔接。实践下来，经常一轮迭代就能把 5 小时的使用限额烧完。
一个 Agent 犹豫一下已经够贵了，多个 Agent 再互相读上下文、写文档、做评估，成本会涨得很快。没有清楚反馈信号和停止条件时，这笔账很不值。
适合 loop 的任务，通常有几个特征：有测试、日志、截图、用户行为这类反馈信号；需要多轮试错和修正；低风险动作比较多，可以提前授权；失败样例能被记录并复验。
最近AI工程化的概念看起来一波接一波，但我觉得它们背后其实是同一个问题：
人到底应该怎么和越来越能干的 AI 协作？
prompt engineering 关注的是，怎么把一句话问清楚。
context engineering 关注的是，怎么把足够的上下文交给 AI。
harness engineering 关注的是，怎么给 AI 接上工具、环境、评测和执行框架。
到了 loop engineering，问题又往前走了一步：当 AI 已经能持续执行、反复验证、自己修复，人应该站在哪里？
我现在的答案是，人不应该卡在每一步确认里，也不应该完全退出。人更应该负责定义目标、设置边界、判断风险、处理异常、做最终取舍。
未来这个方向最后会叫什么，我不知道。也许 loop engineering 这个词会热一阵，也许很快会被新的说法替代。
但真正重要的不是词，而是看清人的价值和位置。
AI 越能执行，人越要知道什么值得做、什么不能碰、什么情况必须停下来。
