Loop Engineering 的本质：它把强化学习，搬到了推理期

这是上一篇 Loop Engineering 的续集，也是它的”困难模式”。这篇挖得比较深，适合稍微懂一点算法、Agent 原理或者大模型原理的同学。如果你只想知道”是什么、怎么用”，看上一篇就够了；这篇我们来拆”它到底是什么、为什么会那样、以及怎么写好一个真正能用的循环”。文末我开源了一个把这套判断固化下来的 skill。

一个让我”越想越通”的视角

我白天做 Agent 产品，业余也在啃一个相关的研究方向：一个基于业务评测、让 agent 自我进化的框架。说人话，就是用真实业务里的评判当信号，持续、靠谱地推着一个 agent 自己变得更好。

所以当 Loop Engineering 今年突然火起来的时候，我盯着它看了很久，有个越来越强的感觉：它根本不是个新东西。它是个老朋友换了身衣服。

这个老朋友，叫强化学习（RL）。

这篇文章我想论证一件事：Loop Engineering 本质上就是「把强化学习搬到了推理期、而且冻结了权重」的那个东西。 一旦你接受这个映射，循环的每一个设计要点、每一种翻车姿势，都能从 RL 里直接推出来。它不是一堆零散的工程小技巧，它有一根脊柱。

先把脊柱立起来。

脊柱：循环的上限，就是那个”裁判”的上限

一个 while 循环套着一个模型，这玩意儿写出来没什么技术含量。真正决定这个循环能不能用的，是那个判断每一轮输出对不对的东西——我们叫它校验器（verifier），下文我多半叫它”裁判”。

所以我的核心论断是：

设计循环，本质上是在设计那个裁判。循环是简单的那部分。一个没有靠谱裁判的循环，只是一台更快地积累错误的机器，而且模型越强，它积累得越快。

这不是我一个人的偏见。The New Stack 有篇文章的标题直接就是”循环正在取代提示词，而验证即将成为你最大的问题”。还有个我很喜欢的评论说得特别精辟，大意是：设计循环只是一半，另一半是往循环里塞一个能说”不”的东西：一个测试、一个类型检查、一个真实的报错。 那个能说”不”的东西，就是裁判。

我得补一个分寸：裁判靠不靠谱，通常是最吃紧的那道坎，但不是唯一的。循环能不能收敛，还取决于动作空间、状态完整性、能不能观测、任务能不能拆、以及出错后的恢复策略。但在所有这些里，裁判是心脏。

好，脊柱立完了。现在来看为什么我说它”就是 RL”。

它像什么：一个不更新权重的 RL

把映射摆出来：

• 那个模型，对应 RL 里的策略——真正下场做决策、干活的那个。
• 你给它套的那层工程外壳（工具、环境、状态怎么流转），对应 RL 的环境。
• 你定的成功标准，对应奖励函数。
• “一直跑到达标”，对应 RL 的在线试跑（也就是反复推演）。

我必须强调一句，这是类比，不是字面等价。 整个过程里没有任何权重被更新，所以它不是真的 RL。这个类比真正值钱的地方在于：它精准地预言了一类失败，那一类关于”目标和反馈”的失败。

而 RL 最难、最没被解决的那块，恰好就是奖励（reward）该怎么定。你把训练期的难题，原封不动地搬到了推理期。具体继承了三座大山。

大山一：定一个”好奖励”，本身就难

定义一个”又便宜、又忠实、又可机器检查”的成功信号，这件事在 RL 里就是公认的硬骨头。

我们 PM 经常有个错觉，觉得”把成功指标定清楚”是个产品问题、写写文档就行。不是的。难的不是定义”成功指标”，难的是定义一个不可被钻空子的成功指标。这是个奖励设计问题，它没有标准答案。

大山二：它会精准地钻你标准的空子

有个叫古德哈特定律的说法你大概听过：“当一个指标变成目标，它就不再是个好指标。”

落到循环上，长这样：你让一个 agent 对着”测试通过”这个目标去循环，它很可能给你写出专门糊弄测试、而不是真解决问题的代码。 裁判一旦和你心里真正想要的目标之间有一条缝，循环就会精准地、不知疲倦地去钻那条缝。

而且这里有个反直觉的地方：循环越强，钻得越狠。 能力和钻空子的能力是一起涨的。有人给这种产物起了个很传神的名字，叫 “agent slop”：被一群 agent 批量生产出来的、对着不完整的评估标准优化出来的低质垃圾。这正是很多人说的”循环只会产出昂贵的垃圾”的精确机理：不是循环不行，是裁判和真目标之间那条缝在作祟。

大山三：密集还是稀疏，以及我自己踩过的一个坑

这是我认知更新最多的一块，所以多写两句。

• 密集奖励：每一步都有反馈。写代码每一步都能编译、能跑测试，等于给了模型一条可以跟着往上爬的梯度。
• 稀疏奖励：只有最后才知道成没成。一个战略决策，半年后才见分晓，中间没有任何信号。

我一开始的判断是：“密集的就能循环，稀疏的就抓瞎、直接判死刑。” 这个判断是错的，我后来自己推翻了。

错在哪？稀疏反馈不等于没有可靠的裁判。 编译器最终给你一个成功/失败、定理证明器最终接受或拒绝、一套终局测试套件最终通过或不通过、数据迁移完成后跑一次完整一致性检查，这些信号都很”稀疏”（只在最后出现），但它们便宜、可信，完全可以撑起一个有预算上限的搜索循环。

真正抓瞎的，是另一个组合：稀疏 + 失败不给你任何可行动的证据 + 搜索空间巨大。 “循环生成文案直到它动人为止”才是真的死路：因为”动人”既稀疏又不给诊断信息。所以判断一个任务能不能循环，正确的问法不是”信号密不密”，而是：失败的尝试，会不会返回足够忠实、足够可行动的证据？

这个修正很重要，因为它直接决定了你会不会把一堆其实能做的任务（比如”循环到证明检查器接受”）误判成不可能。

怎么写好一个循环：从脊柱长出来的几条

理解了”它是 RL”，下面这些设计要点就不是规则，是推论了。我把我自己沉淀的几条挑出来讲。

1. 裁判是心脏，而且”干活的”不能给自己打分

让产出结果的那个模型来给自己的结果打分，它会打得过松，这几乎是必然的。所以要把”干活的”和”验收的”分开：一个负责做，一个独立负责验。干活的可以自检、廉价地抓抓明显错误，但它绝不能是最终验收权。

还有个比”用两个不同模型”更深的点：真正重要的是证据独立，而不是模型身份独立。 两个不同的模型，可能共享同样的错误知识、同样的偏差、同样不完整的需求理解、同样的训练分布。所以真正重要的不是”换个模型来判”，而是”换一种独立的证据来源”：外部事实、确定性结果、锁死的隐藏测试、不对干活方暴露的暗哨检查、独立上下文里的模型裁判、找真人抽查。这里没有放之四海皆准的排序，按”对验收契约的保真度、独立性、覆盖、稳定、成本”去选、去组合。

2. 护住”控制面”，别让”干活的”去改测试

这条是我觉得最容易被忽略、但在生产里最致命的。

一个卡住的 agent，最容易采取的”修复”是什么？改测试，或者降低标准，而不是修产物。 这是钻空子最生动的注脚。

所以你必须明确地保护控制面：干活的那一方，不许修改验收契约、不许动锁死的隐藏测试、不许改裁判的指令、不许改评分细则、不许调预算、不许改停止条件和审批策略。任何对这些的改动，都算”目标变了一个新版本”，必须走独立审批。怀疑它会钻空子的地方，至少留一套验收集对干活方完全保密。

3. 停止条件：三个硬停，而且”没进展”得是真信号

烧钱黑洞的根源就是停止条件没设好。三个硬停，一个都不能少：达标停、预算停（按轮数 / token / 金额）、没进展停。

但”没进展”这条有个坑：如果你只判”同一个报错连续出现 N 次就停”，agent 可以靠产生一堆无意义的小改动让每一轮看起来都不完全一样，从而绕过它。所以”没进展”本身需要一个真正的进展信号：失败的测试集合有没有在缩小、没满足的评分项有没有在减少、是不是同一种错反复出现、是不是连续好几轮只有无关痛痒的表面改动。说白了，连”没进展”本身，都需要一个能机器判的裁判。

4. 升级靠”可观测触发器”，不靠模型”觉得自己不确定”

模型自报的置信度，是出了名的没校准。所以”该求助时求助”不能写成一句人格要求，得变成规则，用可观测的条件触发升级：两个裁判打架了、输入超出已知范围、冒出未知的工具错误、预算逼近上限、同一种错反复出现、涉及高风险动作、缺关键证据、状态和外部数据不一致。

这条还藏着规模化的真瓶颈：当你跑很多个循环的时候，吞吐量不取决于模型多强，取决于这些循环多会”在对的时机举手”。 一个安静失败的循环，比一个大声失败的循环糟糕得多。一个人能管多少个循环 ≈ 这些循环多会喊”我不确定”。

5. 三个逻辑层别揉在一起

最后是架构。我把循环拆成三个逻辑层（视情况存在，单任务时最外层可以退化成一个一次性的壳）：

• 最外层是调度：选下一个工作项、加锁、派发、管整个队列什么时候收工。
• 中间是精炼循环：盯着一个工作项往下收敛——做 → 验 → 据失败证据改 → 达标 / 停滞 / 超预算就停。
• 最里头是提交闸（commit gate）：在任何不可逆、高权限、或对外可见的副作用之前，做审批前置、最终独立验证、提交决策、后置校验。所有不可逆动作都活在这一层，在内层循环之外。

把”群发""发布""转账”这种动作关进提交闸，而不是让它们在内层循环里裸奔，这一条能救命。

我最担心的部分：三笔”债”

上面都是机器侧。但有三种失败，不会出现在任何看板上，是人这一侧的。Addy Osmani 在他那篇博客里点得很透，我转述一下，因为这是我个人最警惕的部分：

• 理解债：循环交付的、你没读过的代码越多越快，“存在的东西”和”你真正搞懂的东西”之间的鸿沟就越大。裁判替代不了你亲自去读它到底写了什么。
• 认知投降：循环自己跑起来之后，人特别容易停止思考、照单全收。Osmani 那句话我很喜欢，大意是：带着判断去设计循环是解药，为了逃避思考去做就是加速器；同一个动作，截然相反的结果。
• 垃圾化：你优化的是你写下来的那个目标，不是还留在你脑子里、没说出口的那些讲究。所以得自己抽样去读真实产出，把修正喂回去。

我把这一段单独拎出来，是因为做 Agent 产品做久了，我越来越觉得：最危险的姿势，恰恰是那个最舒服的姿势：按下”开始”，然后再也不去看它产出了什么。

前沿，以及一点私心

那真正的前沿在哪？在给本来没有裁判的领域，人工造一个出来：把终局的”好不好”拆成一串每步能打分的细则，或者先让模型生成一套测试再对着它循环。

但这件事很危险：把稀疏改成密集，你到底是在逼近那个真裁判，还是在制造一个更精致、更耐看、但同样能被钻的代理？所以任何这种”塑形”，都得先证明你那个塑形信号真的和真目标相关，再去信它。

这也正是我那个研究方向想啃的东西：怎么用业务里的真实评测，持续地造出靠谱的裁判，再让 agent 顺着它自己进化上去。某种意义上，Loop Engineering 把训练期最难的那块（奖励 / 评估）搬到了推理期，然后把它直接糊到了每个产品工程师脸上。 我们这代做 Agent 的人，逃不掉它。

落地：我把这套判断固化成了一个 skill

光说不练假把式。我把上面这整套判断（从”该不该上循环”的四维分流，到裁判设计、护控制面、三层架构、升级触发器、上线监控）固化成了一个给 Claude / Codex 加载的 skill，开源了。

它的设计哲学就一句：让 AI 当一个会说”这个任务你造不出裁判，所以别全自动”的诚实顾问，而不是一个”什么都能自动”的推销员。

GitHub：qingqingpi/loop-engineering-skill（README 有中英双语，clone 下来拷进 ~/.claude/skills/ 即可用）

我没有只把文件扔上去就完事。仓库里专门写了一段”怎么评估的”：我用配对实验真测过它，五个场景、每个跑两遍，一遍给不带 skill 的 agent（对照组）、一遍给读了 skill 的 agent（实验组），来隔离出 skill 到底加了什么。结论也写得很诚实：在”建一个无人审核的自动发布器”这种场景下，带 skill 的 agent 守住了提交闸、对照组最后妥协了；但我也标了个前提：强的基座模型本来就会拒绝坏的自治，所以 skill 的边际价值主要在”一致性、结构、完整性、以及它强制要求的那些验证指标”，在更小/更快的模型和大量重复运行下才会真正放大。

它现在是 v1。文本能写下判断，写不下运行时的全部行为。你真用起来大概率会发现一两个我没料到的坑，欢迎来提 issue，我们一起迭代。

---

最后回到开头那句。Loop Engineering 不是魔法，它是一面照妖镜：它照出来的是，你这个任务到底有没有一个忠实的验收信号。 有，循环就是你的杠杆；没有，再漂亮的循环也只是在更快地产出昂贵的垃圾。

工程能力补不了一个缺失的裁判。这大概是我做这一行学到的、最朴素也最反复被验证的一条。

——孙鑫，做 Agent 方向的 AI 产品经理。更多碎碎念在 sunxin.xin。