Loop Engineering 到底是什么：为什么它不是普通的 Agent 提示技巧
先说结论：Loop Engineering 不是“把 prompt 写得更聪明”那么简单，它讨论的是比单次 agent run 更外层的一层系统。参考 alchaincyf/loop-engineering-orange-book 里给出的脉络，loop engineering 关心的不是某一次 agent 调用该给什么提示、配什么工具、怎样定义 done，而是那个会定时运行、会派生子任务、会做验证、会记忆历史、会决定下一步该做什么的外层机制。简单说，prompt engineering 是你在开车，harness engineering 是你把这次出车的配置调好，而 loop engineering 是你开始建一条能自己循环调度、自己检查、自己决定节奏的运输系统。
这个区别之所以重要，是因为很多人现在虽然已经在用 Claude Code、Codex、Cursor 或其他 agent 工具，但工作方式本质上还是“我盯着它，一步一步提示它”。今天让它写代码，明天让它查文档，后天让它整理结果，每一步都还是人类在当实时调度员。Loop engineering 关心的是：能不能把这个“实时调度员”也部分系统化，让人不再负责每一步提示，而是负责设计那个提示和验证会如何循环发生。
为什么它不是 prompt engineering 的同义词
最常见的误解，是把 loop engineering 理解成“更高级的 prompt engineering”。这其实不对。prompt engineering 仍然主要处理单次任务里的表达和约束：怎么提问、怎么设边界、怎么减少歧义、怎么要求结构化输出。就算再复杂，它关注的还是一次调用内部的质量。loop engineering 关注的却是调用之间的关系：这个系统多久跑一次、从哪里接输入、怎么拆成多个任务、哪个步骤要验证、失败后如何重试、哪些信息要留下来供下次循环使用、以及什么时候应该停。
如果说 prompt engineering 解决的是“这次问得对不对”，那么 loop engineering 解决的是“这套系统下一轮还会不会继续按正确的节奏转起来”。两者不是替代关系，而是层级关系。
一个 loop 至少要回答哪几类问题
如果用更工程化的语言去理解，一个真正的 loop 至少要回答六类问题。
1. 触发
它是定时触发、事件触发，还是人工确认后触发？如果连“什么时候该跑”都不清楚，那它还不算 loop，只是一次任务。
2. 输入
它每轮吃进去的是什么？是新 issue、新邮件、新日报、新数据变更，还是上轮未完成项？loop 没有稳定输入，就不会有稳定节奏。
3. 分解
它会不会把一个大任务拆成多个更窄的 agent 子任务？如果会，谁来定义拆分规则？哪些任务可以自动分出去，哪些不行？
4. 验证
谁来判断这轮结果算不算过关？一个核心提醒是，AI 不能天然地当自己工作的最终裁判。没有外部验证，loop 很容易越跑越偏，却自以为完成得很好。
5. 记忆
这轮跑完后，哪些信息要留下？是只留最终结果，还是要保留失败原因、环境差异、已知例外、下次应避免的路径？没有记忆，系统每次都像第一次做。
6. 下一步决策
它是结束、重试、降级、交给人、还是继续派生下一轮？这才是 loop 和单次 agent 调用最本质的区别。loop 不只是完成一次任务，而是负责决定这个系统下一拍怎么转。
为什么最近这个概念突然变热
这个词之所以最近更受重视，本质上反映的是 agent 使用习惯的成熟度变化。早期大家在证明“agent 能不能做事”，现在越来越多团队已经默认 agent 能做一部分事，于是讨论重点自然转向：如果它能做，那我们怎么让它定期做、稳定做、可验证地做，而且出了问题能恢复。也就是说，焦点从能力展示，转向循环系统设计。
这也是为什么 loop engineering 对 builder 比对围观者更有吸引力。它不是空泛地说“以后都是 agent”，而是把问题拉回到系统层：谁来发车、谁来验收、谁来记账、谁来纠错。对真正要落地自动化的人来说，这比再看一轮神奇 demo 要实用得多。
Loop 最容易被低估的三个难点
难点一：验证债
系统越能自动跑，人越容易偷懒不验证。但如果没有独立验证，loop 很可能只是更高频地制造错误。自动化越强，验证反而越要外置。
难点二：理解力腐蚀
一旦系统开始替你做越来越多事情，人会逐步失去对中间过程的理解。表面上效率更高，实际上团队越来越不知道它是怎么成功、为什么失败、哪一步最脆弱。这种“理解力腐蚀”是 loop 比单次 agent run 更危险的地方。
难点三：成本和上下文失控
Loop 一旦持续运行，就会把 token、上下文、子任务数量、失败重试次数一起放大。单次 run 看不出的问题，在循环系统里会迅速变成成本问题。你以为是在省力，结果可能是在持续燃烧预算和认知带宽。
一个更接近现实的 loop 长什么样
对多数团队来说，第一代 loop 不应该长得太宏大。更现实的形式往往像这样：
- 每天固定时间抓一批输入
- 按规则拆成几个小任务
- 让 agent 先跑出初稿或初步判断
- 用固定规则或人工 spot check 做验证
- 记录失败原因和待跟进事项
- 决定哪些进入下一轮，哪些交还给人
你会发现，这套东西和“让 AI 帮我写一段东西”完全不是一个量级的问题。它更像是在设计一个带节拍的生产系统，而不是一次性的助手调用。
什么时候你其实已经需要 loop engineering 了
有三个信号很典型：
- 你已经不是偶尔用 agent，而是每天都在重复相似任务
- 你发现自己不是在做业务本身，而是在不断手动调度 agent
- 你越来越需要“让系统自己继续跑下一步”，而不是每一步都等人盯着
只要这三个信号里有两个已经出现，你其实就不该再只讨论 prompt 技巧了。你需要开始讨论 loop。
对大多数团队，第一步应该怎么做
第一步不是直接造一个全自动大系统，而是先挑一条重复、低风险、可验证的工作流。比如日报整理、issue 初筛、资料抓取与初步总结、候选方案比较、或某类固定 QA。然后只做最小 loop：
- 固定触发方式
- 固定输入来源
- 固定验证动作
- 固定失败回退路径
只要这四件事还没固定，系统就还更像一串自动化脚本，而不是一个真正可维护的 loop。
最后一句话
如果说 prompt engineering 是“怎么把一次问答问对”，harness engineering 是“怎么把这一趟 agent run 配好”，那 loop engineering 讨论的就是“怎么让整个系统自己持续转起来，而且越转越清楚，而不是越转越失控”。真正的门槛不再只是会不会用 agent，而是你能不能设计一个替你持续驱动 agent、验证 agent、约束 agent、并从每一轮结果里学东西的外层系统。