Loop Engineering：能放手的是执行，不能放手的是方向

两周前，loop engineering 这个词还没几个人听过。一条推文之后，它冲上了所有人的 timeline，大意是：别再一句句 prompt 你的 coding agent 了，去设计那个替你 prompt agent 的 loop。

我看到的第一反应不是新鲜，是"终于"。

因为它根本不是突然冒出来的。它是 human-in-the-loop 这件事一路演化的必然结果，人在 loop 里待的时间，本来就该越来越短。只要有人参与的地方，人就会成为整条流水线上执行效率的瓶颈。把人从一环一环里挪出去，是迟早的事。

但这里有个问题被很多人跳过了：人什么都不用管了，那还要人干嘛？

我的答案是：设计系统。设计一个能自循环、自演进的系统，让它自己发现问题、分析问题、设计方案、执行并验证，最后端到端交付一个可靠的"解决方案"。人退出的是执行，不是责任。

所以这篇想说的就一句话：

当执行能整段交给 agent，人能放手的是执行，不能放手的只剩两样。一是方向（往哪走），二是验证里还没被客观化的那部分（什么算对）。

为什么 loop engineering 是必然

先把"循环"这件事摆正。

做产品本来就是一个停不下来的 loop。只要产品上线，这个循环就无止境，因为需求是随时间被逐渐发现、甚至被重新定义的，而一个好产品的好，恰恰在于它能不能不断适应新需求。迭代不是产品的一个阶段，迭代就是产品本身。

过去这个 loop 的每一圈都得人来推：人收集反馈、人想方案、人写代码、人验收、人发版。人是发动机，也是限速器。loop engineering 说的事，本质上是把发动机换成 agent，人挪到方向盘后面。这跟我之前在 Build the harness, not the agent 里讲的是同一个方向：智能来自模型，人的活是造车不是造引擎。loop engineering 只是把"造车"这件事，从单次任务抬高到了整个迭代周期。

退出执行，不等于撒手

这里要划清一条界线，否则 loop engineering 很容易退化成它的反面。

我以前写过编排被高估，甚至判断编排式 AI 最终会消失。编排的本质是用确定性的代码替模型做每一步决策。模型越强，你框得越多，浪费得越多。

那"设计一个替你 prompt agent 的 loop"，算不算又把编排请回来了？

不算，而且方向正相反。编排是替模型决定每一步怎么走，设计系统是把"怎么走"更彻底地交出去，人只负责把这几件事立住：

方向：这个产品往哪走，什么做、什么不做。
信号：系统靠什么知道"这里有问题、值得改"。
验证：什么算"做对了"、可以交付。

这是 Context, not Control 的同一套哲学，只是抬高了一个 altitude。从"给单个任务足够上下文然后放手"，变成"给整个迭代系统足够的方向和验证标准然后放手"。

三个 loop，别混为一谈

"loop engineering"里的 loop 到处被人混着用，其实至少有三个，难度完全不同。

第一个，模型内核那个 loop。 就是那段二十行的 while：模型要调工具就调，调完把结果塞回去，循环到模型自己决定停下。这个 loop 属于 agent，是模型的判断力在跑，你不该去碰它。这点我在 harness 那篇已经讲透。

第二个，短期任务 loop。 一个有明确短期目标的端到端任务：给目标、执行、验证、交付。它相对好做，因为目标清晰、验证干净。跑个浏览器模拟用户点击、跑一遍单测，红了就是红了。业界说的"在 loop 里放一个能说不的东西（一个测试、一个类型检查、一个真实报错）"，说的就是这一层。

第三个，长期自进化 loop。 跨越很多次任务的自我演进：系统从一段时间的运行里捕获信号、诊断问题、提出改进、验证、发版，再进入下一轮。这个我在《Agent 的自我反思与自我进化》里拆成过八步。

后者比前者难得多。难就难在：短期 loop 的目标和验证是现成的，长期 loop 的"什么算变好"是要人去定义的。下面两节都在啃这个难点。

验证要分层，而且那条线在移动

人退出执行之后，"验证"立刻变成最尖的矛盾：我一边说人是瓶颈要退出，一边又说没有好 eval 不能开自进化的开关。那验证本身，是不是人最后、也是最大的那个瓶颈？

我的答案是：验证不是"全交给 agent"或"全留给人"的二选一，而是按能不能被客观化来分层。

能记成标准与规范的，交给 agent 自验。 功能交互流程（跑浏览器模拟点击和使用路径）、可维护性、安全性、单元测试，这些 QA 的 gates，agent 完全可以自己判断、自己闭环。能做到什么程度，取决于人怎么去设计、怎么去"要求"agent 达标。
价值判断，留给人。 产品方向对不对、agent 考虑不周的盲区、那些还没被写下来的标准与规范，这些更高维的东西，目前得人来。

为什么线要划在"客观"这里？因为我在元能力那篇讲过一个坑：让 AI 自己出题自己改卷，测试 100% 通过，逻辑全是错的。agent 的自验只敢圈在有客观裁判的地方，一旦越进价值判断，就会陷入自我论证的闭环。

但真正关键的不是这条线划在哪，而是这条线会移动。

人留着的那部分活里，有一项是"把还没被记录下来的标准与规范补上"。一旦一条价值判断被想清楚、被写成可执行的规范，它就从"人的 eval"下沉成了"agent 的自验 gate"。换句话说，人在 loop 里一个持续的动作，是不断把自己的判断压缩成标准，这正是我说过的 Skill 的本质是压缩。每压缩一条，人机之间那条验证边界，就往 agent 那边挪一格。

终局不是人从验证里消失，是人一直退守在这条移动边界的最前沿，专做那些"还没被客观化"的判断。

这个 loop 是个 dial，不是开关

那人到底该退到哪？

没有标准答案。这个 loop 可大可小，取决于两件事：一是人希望退到哪里，二是系统是否真的能自把控到位。

说白了，人退出的程度，是系统当前可信度的一个函数。系统越能自己兜住，人能退得越远；但退到哪一格，是人主动选的，不是被技术单方面决定的。今天 eval 覆盖不够、系统还兜不住，那就少退一点、多守一点。我的原则一直没变：在没有足够好的 eval 覆盖之前，不打开自进化的开关。宁可慢一步。

信号也要分层，而且要谨慎挑

验证解决"做得对不对"，但还有一步在它前面：在人不再逐条打分之后，系统怎么先知道"这里有问题、值得改"？

候选的信号源不少：线上真实行为（留存、复用、Skill 调用步数下降）、self-play、A/B、另一个 agent 当裁判。都可能是信号源，但要谨慎选。有些信号有滞后效应，有些信号有误导性。

我现在的分法还是那条客观与价值的线：

可量化的信号，agent 自己判断并闭环。 比如线上错误数量、负面反馈的工单，这些客观、低歧义，可以直接驱动短回路的自我修正。
价值判断的信号，目前我倾向于人来提供。 因为价值这件事没有客观裁判，self-play 那条路又最容易自欺（自己出题自己解，前面说过它的毛病），让 agent 自己定义"什么算更好"，风险太大。

我的思考

写完这篇，几个判断对我更清楚了。

第一，loop engineering 不是编排，方向正相反。 它不是让人去写更复杂的流程图框住 agent，而是把执行决策更彻底地交出去，人只留方向、信号、验证三个控制点。把它误当成编排的人，会越做越重，最后又回到那个"用确定性代码替模型做判断"的老坑里。

第二，人退出执行，不是被淘汰，是岗位上移。 从执行者，变成系统设计者、方向守门人、和标准记录者。如果人什么都不用管，那确实不需要人；但恰恰因为要设计这个会自己跑的系统，对人的要求是更高了，不是更低了。

第三，人机那条验证边界会一直往 agent 移，推它的是人。 人不断把判断压成标准，标准一落地就交给 agent。所以人的长期价值，不在守住某条固定边界，而在永远站在边界最前沿，专啃那些还没被客观化的部分。这件事没有尽头，因为新需求会不断制造新的"还没被客观化"。

第四，方向是最后的锚，也是 AI 替代不了人的地方。 方向太窄，系统就发散不出去、适应不了多样的需求；太宽，功能多了就大而不精，丢了核心使用路径，上手成本反而高。当所有事情都能交给 agent 的时候，产品的方向是唯一不能放手的。AI 可以和人协同，但人仍然是那个感受真实世界、感受人际关系与资源网络的关键桥梁，而方向，正是从这种感受里长出来的。没有方向，连"什么算变好"都定义不了，再聪明的进化 loop 也只是空转。

把能交的都交出去，然后死死守住那个不能交的：方向。这大概就是 agent 时代，人该站的位置。