最近 Loop Engineering 这个词突然热起来。很多人的第一反应是:AI 圈是不是又造了个新名词?
这个怀疑有道理。拆开看，Loop 里的东西大多不新——定时任务、workflow、状态机、重试、日志、权限、审批、验证、审计，全是软件工程里早就有的东西。
所以我不太建议把 Loop Engineering 当成一个全新的工程层，更不建议把它包装成“Prompt Engineering 之后的新职业”。更准确的说法是:
Loop Engineering 本质上还是 Agent Harness 那套基础设施，只是大家开始用一种更自动化、更持续的方式使用它。
它依赖的仍然是任务合同、上下文组装、工具权限、状态记录、验证器、成本上限、审批流、审计日志——这些都是 Harness / Runtime 早就在解决的问题。Loop 做的，只是把“一次性调用 Agent”变成“反复触发、观察反馈、更新状态、继续推进”的运行模式。
一、为什么大家现在才开始谈 Loop
过去一段时间，Agent 工程的讨论重心一直在往前挪。
最早谈 Prompt Engineering，关心的是:我要怎么问模型? 后来谈 Context Engineering，关心的是:我要给模型看什么? 再后来谈 Harness Engineering，关心的是:模型在什么样的工具、权限、状态和运行环境里工作，才不只是个会聊天的 demo? 现在谈 Loop Engineering，关心的变成:能不能让 Agent 不再等人一轮轮推动，而是在一个可控闭环里持续推进任务?
这个重心转移是真实的。但它不是因为 Loop 发明了一套新基建，而是因为前面那几层终于铺得差不多了。
当 Agent 已经能读上下文、调工具、写文件、跑测试、生成结构化产物、记录状态、等待审批——人自然会问:那我为什么还要手动复制报错、手动点继续、手动让它再试一次?
于是大家开始把 Agent 放进循环里。不是因为 Loop 神奇，而是因为 Harness 终于有条件撑起更长的运行过程了。
二、Loop 不是 Harness 之上的一层，而是 Harness 的一种用法
这是我想说的核心。
很多人画的是这样一张图:Prompt / Context / Harness / Loop，四层架构，一层比一层高。
这张图有点误导——它让 Loop 看起来像一个独立于、甚至凌驾于 Harness 之上的新层。更准确的关系是:
**Prompt 是一次任务表达。****Context 是一次任务的信息供给。****Harness 是一次 Agent Run 的运行边界。**Loop 是多次 Agent Run 之间的触发、反馈、验证和状态更新。
换句话说，Loop 不是脱离 Harness 的东西，它就是 Harness 被持续调用之后形成的运行方式。一条 Loop 能不能跑起来，完全取决于 Harness 有没有先把这些问题解决掉:工具权限、读写边界、失败重试、输出验证、状态落盘、成本上限、停止条件、人工审批。
这些没解决，Loop 跑得越久，只会把风险放得越大。
（有意思的是，在这波讨论中被频繁引用的 Addy Osmani，也把 Loop Engineering 描述成 “one floor above the harness”。但我更愿意把它理解成：它不是比 Harness 更高级的一层新基建，而是把 Harness 那套能力换成了一种连续运行的用法。
这里真正需要额外强调的，是跨多轮运行的状态。因为独立的 Agent Run 之间没有天然持久记忆，模型跑完一轮之后，下一轮能不能接着推进，取决于状态是否被写在对话之外，比如文件、数据库、issue、Linear board 或其他外部系统里。除此之外，Loop 需要的大部分能力，比如工具权限、上下文组装、隔离环境、验证器、审批和审计，本来就是 Harness 要解决的问题。）
三、真正变化的，是人不再当 Loop Controller
现在很多人用 coding agent，本质还是“人工 babysitting”:让它改代码 → 看输出 → 报错 → 复制错误 → 让它修 → 再跑 → 再复制 → 最后自己收尾。
这比纯手写快很多。但人还在当 loop controller——Agent 只是执行单元，每一轮的观察、判断、推动、叫停，全靠人。
Loop Engineering 真正值钱的地方，是把这部分低价值的推动交给系统。人不再管每一轮的“继续、再试、报错了、修一下”，转而去定义目标、范围、验收标准、权限边界和审批节点。
人的角色，从 Operator（操作员） 变成 System Designer / Reviewer（系统设计者 / 审核者）。
这才是它值得关注的点:不是多了个新词，而是 Agent 的使用方式正在从“对话式协助”走向“运行时托管”。
四、一个 Loop 里到底有什么
一个能用的 Agent Loop，通常就这几块——注意，每一块都是 Harness 早就有的能力:
- Trigger 触发器:什么时候启动?定时、CI 失败、issue 新增、指标异常，还是人工?
- Task Contract 任务合同:这次要做什么、范围多大、能做什么、禁止什么、什么算成功?
- Context Packet 上下文包:这次该读哪些文档、代码、日志、历史决策?哪些过期了、哪些只是背景?
- Execution 执行:Agent 按合同和上下文调工具、改文件、生成草稿或结构化结果。
- Harness 工具与边界:哪些工具可用、哪些命令要审批、哪些目录不能写、要不要在 sandbox / worktree 里操作?
- Validation 验证器:代码跑测试、数据过 schema、研究查来源、内容做事实核查、生产动作要人审。
- State Update 状态更新:这轮做了什么、为什么失败、下次从哪继续、有没有待人工处理的事?
- Stop / Continue / Review:什么时候继续、什么时候停、什么时候升级给人。系统不能无限空转。
你会发现这里没有任何玄学。它就是把 Harness 已有的能力串起来，让它们不再只服务一次 Agent Run，而是服务一个持续推进的任务过程。
五、那它跟普通自动化到底差在哪
“不就是 cron job 戴了顶 AI 帽子吗?”——这个吐槽不能算错。
如果你的 Loop 只是“每天 9 点调一次模型、生成一段总结、发到群里”，那它确实就是 cron + prompt。
但真正有价值的 Loop，不是定时调用模型，而是让 Agent 根据反馈改下一步。比如修 CI:
CI 失败 → 读失败日志 → 找到相关代码和测试 → 在隔离工作区试修 → 重跑测试 → 还失败就把新报错喂回去接着修 → 通过了生成 PR → 再让 Reviewer Agent 检查 diff → 最后交给人合并。
它跟普通脚本的差别就一点:不是机械重复同一条命令，而是每一轮根据观察结果改路径。以前 workflow 里跑的是确定性脚本，现在跑的是能理解上下文、选工具、解释失败、调整方案的 Agent。
这就是变化。但底座仍然是 Harness——没有工具权限、隔离环境、日志、测试、状态和审批，这条 Loop 跑得越久，越危险。
六、但别把 Loop 理解成“全自动”
Loop Engineering 最大的误解，就是把它当成“让 AI 自己一直干”。这很危险。
一个好的 Loop，不是约束更少，而是结构更多。它得明确:任务范围、工具权限、上下文来源、输出格式、验证方式、重试次数、成本预算、停止条件、审批节点、审计记录。
Agent 越能自动干活，越需要工程边界:
没有边界的 Loop，不是自动化，是失控。 没有预算的 Loop，不是生产力，是账单黑洞。 没有验证的 Loop，不是智能系统，是幻觉放大器。 没有状态的 Loop，不是工作流，是聊天记录堆积。 没有审批的 Loop，不是 Agent Runtime，是生产事故预备役。
所以真正成熟的 Loop，方向跟“放手”正相反:是把 Agent 关进一个可验证、可回滚、可审计、可停止的系统里。
七、什么任务适合做 Loop
不是所有任务都适合循环化。适合的，通常有五个特点:
- 重复发生——一次性的不值当，反复出现、模式相似、人工处理又烦的，才值得。
- 成功标准清楚——能跑测试?能过 schema?能查来源?能让 reviewer 判过没过?判不了的别全自动。
- 失败可恢复——能重试、能回滚、能停下来交给人?还是一错就把生产干崩?
- 权限收得住——能读就别给写，能开 PR 就别直接 merge，能出建议就别直接执行。
- 值回成本——Loop 要烧 token、工具调用、维护和 review 时间，不是所有事都配自动化。
照这五条筛:适合的是 CI 修复、PR 初审、issue triage、文档同步、changelog 生成、日志异常聚类、客服工单分流、研究资料收集、每日简报、持续监控告警;不适合的是高风险生产操作、没有明确验收标准的创意判断、权限边界不清的业务动作、失败代价高又不可回滚的决策。
一句话:验证便宜、失败可恢复、重复发生的任务，最适合 Loop。
八、Loop 真正说明的是什么
“Loop Engineering”这个词可能热一阵，也可能很快被下一个新词盖过。但它背后的趋势是真的:大家越来越不把 Agent 当成聊天框里的助手，而是当成 Runtime 里的一个执行单元。
过去我们优化的是一句话，现在我们设计的是一套能持续运行的系统——能触发任务、组装上下文、调工具、验结果、更新状态、控权限、留记录，还能在关键节点把人叫回来。
所以我对 Loop Engineering 的判断是:
概念有价值，但别神化。它不是新基建，而是 Harness 的自动化用法;它不取代 Prompt、Context、Harness，而是长在这些能力之上;它真正代表的，是 Agent 工程从“单次调用”走向“持续运行”。
未来真正有竞争力的，不是最会跟 AI 聊天的人，而是能把 AI 稳稳塞进可靠工作流的人——他知道什么时候让 Agent 自动跑，更知道什么时候必须摁停。
说到底，Loop 值得讨论，不是因为它发明了什么新东西，而是因为它把一件事摆上了台面:Agent 工程的关键，正在从“怎么让模型答得好”，转向“怎么让系统稳得住”。