Loop Engineering：从强化学习视角看 Agent 循环的本质

一、引言——当 Agent 通宵干活时，真正在发生什么？

下班前丢给 Codex 或 Claude Code 一个任务：盯着这个 PR，CI 失败了就修，有 review comment 就回，部署状态异常了记得告诉我。第二天早上打开电脑，发现它真的把一整套机械活儿都干完了——测试通过了，lint 干净了，小的 review 意见也处理了，甚至还留了一份条理清晰的交接总结。

这时候一个很自然的问题是：这背后仅仅是模型变聪明了吗？还是说，我们其实在实践一种新的工程范式？

答案更偏向后者。Claude Code 之父 Boris Cherny 在回顾产品一周年时说过一句话，后来成了这个领域的标志性表述：“我不再给 Claude 写提示词了。我写好一个个运行着的循环，让循环去提示 Claude 并让它自己搞清楚该做什么。我的工作就是写循环。”

这就是 Loop Engineering——循环工程。你不再是那个站在 Agent 对面、一轮轮手动输入 prompt 的人，你退到了更上一层，去设计一个能自己转起来的系统。系统定义目标、定义流程、定义怎么验证结果，然后 Agent 在这个循环里持续迭代，直到满足停止条件。

但如果只说到"自动循环"这一层，其实还没有触及 loop engineering 最核心的东西。很多人对 loop 的第一反应是"让 Agent 多跑几轮"，仿佛 while true 就是答案。这恰恰是最大的误解。

Loop 的灵魂从来不是执行，而是验证。更准确地说，是来自外部的、独立的验证。这个想法听起来很强化学习——Agent 动作，环境给反馈，Agent 根据反馈调整策略，循环往复。而这正是这篇文章想展开的主线：loop engineering 的底层逻辑，和强化学习、和 Rich Sutton 讲的"发现"理论，其实是同一套东西。

二、Loop 的通用公式——Goal + Workflow + External Observation

在进入理论之前，我们先把 loop 的结构拆清楚。任何一个能跑起来的循环，无论简单还是复杂，本质上都由三个部分构成：目标（Goal）、工作流（Workflow）、以及外部观察（External Observation）。

2.1 Goal：明确定义什么叫"做完了"

Goal 是循环的停止条件，也是每一轮迭代的方向锚点。一个好的 Goal 必须是可验证、可量化的，不能是模糊的主观描述。

比如"把这个 bug 修了"就不是一个合格的 goal——什么叫"修了"？是编译通过就算，还是相关测试都要过？要不要做回归验证？改动范围有没有限制？这些不写清楚，Agent 就只能自己猜，而它猜出来的"完成"标准很可能和你的预期对不上。

一个更合格的写法是这样的：auth 模块相关测试全部通过，lint 退出码为 0，改动只限 src/auth 和 tests/auth 目录，最多跑 8 轮，如果连续两轮没有新增进展就停下来说明阻塞原因。

这里面其实包含了两类信息：证据和刹车。测试通过、lint 干净、diff 不越界，是证据——用来判断是否真的接近目标。最多 8 轮、连续无进展就停，是刹车——防止循环失控、防止 Agent 在死胡同里反复消耗资源。

2.2 Workflow：每一轮循环里做什么

Workflow 是 Agent 在每一轮循环内执行的动作序列。对一个编码任务来说，通常是：读代码理解问题 → 尝试修改 → 跑测试验证 → 看结果决定下一轮做什么。

很多人写 loop 时注意力都放在 workflow 上，觉得步骤越详细越好。但 workflow 其实是三要素里最不"卡脖子"的那个——LLM 本身就具备规划和分步执行的能力，只要目标和验证标准清楚，它大概率能自己摸索出合理的执行路径。

真正决定 loop 质量的，是第三个要素。

2.3 External Observation：反馈必须来自外部环境

这是整个 loop 最关键、也最容易被忽视的一环。Observation 是每一轮结束后 Agent 拿到的反馈，但这个反馈绝对不能是 Agent 自己评估出来的。

举一个具体的例子：在埋点需求开发里，observation 不是 Agent 说"我觉得埋点加对了"，而是去 Slardar 平台查真实采集数据——数据上报了就是上报了，没上报就是没上报，客观、独立、不受 Agent 主观判断影响。

再比如 CI 的退出码、单元测试的结果、浏览器 console 的报错、接口返回的状态码、线上监控的告警……这些都是来自外部环境的真实反馈。它们不依赖 Agent 怎么说，只看系统实际发生了什么。

**核心区分：**Agent 自己说"我做完了"不算数，必须有独立的、客观的外部验证信号。如果 observation 是 Agent 自评的，就等于让考生自己改卷子——循环跑再多轮也不会产生真实的进步。

这三个要素合在一起，就构成了一个完整的 loop：Goal 定义终点，Workflow 定义每一步怎么走，External Observation 提供真实的反馈来校正方向。三者形成闭环，持续迭代，直到满足停止条件。

下面这张图直观地展示了这个循环结构：

看到这个循环结构，熟悉强化学习的人应该会感到一种强烈的既视感。这不是巧合——下一章我们就来展开这个理论根源。

三、为什么 Observation 必须来自外部？——Rich Sutton 的发现理论

如果说"外部反馈很重要"还只是一种工程直觉，那么强化学习之父 Richard Sutton 在 2026 年发表的《AI Creativity and Discovery》演讲稿，为这个直觉提供了更深层的理论支撑。

3.1 真正的发现需要三个步骤

Sutton 在演讲中提出了一个核心观点：真正的 Discovery（发现）和 Creativity（创造力），不是凭空产生的，而是一个三步循环的结果：

**第一步：Variation（变异）。**生成多种不同的可能性、不同的方案、不同的尝试。可以是随机的，也可以是有方向的，但必须有多样性——只试一个答案不叫探索。

**第二步：Evaluation（评估）。**对每一种尝试进行独立的、客观的评判，分出好坏优劣。这个评估不能是生成者自己给自己打分，必须有一个独立的判断标准。

**第三步：Selective Retention（选择性保留）。**把评估下来好的方案保留下来，不好的淘汰掉，然后基于保留的结果继续下一轮变异。

这个模式并不新鲜——自然选择的进化论是这样，科学方法的"假设-实验-验证"是这样，心理学里的操作性条件反射也是这样。Sutton 想说的是，这也是 AI 能做出真正发现的唯一路径。

3.2 生成式 AI 缺了哪一步？

那现在的生成式 AI（大语言模型、图像生成模型等）处在什么位置？Sutton 的判断很直接：它们只有 Variation，没有 Evaluation。

生成式 AI 是用监督学习预训练出来的。训练阶段它从海量数据里学习模式，运行阶段它通过随机性生成各种新颖的输出——这一步确实完成了 Variation。但生成之后，它没有办法独立评估自己生成的东西好不好、对不对、有没有价值。

没有 Evaluation，就没有 Selective Retention，也就没有真正的 Discovery。输出可以很新颖（novel），也可以质量很高（good），但两者不会同时成立——新颖来自随机性，质量来自训练数据，随机的不一定好，好的不一定新。

**Sutton 的核心论断：**生成式 AI 本质上是模仿者（mimic）。它可以非常有用，但它在原理上无法做出真正的科学发现。真正的发现需要独立的评估环节，而监督学习的训练范式里没有这个位置。

那什么时候 AI 系统能做出真正的发现？Sutton 举了 AlphaGo、AlphaZero、AlphaFold 这些例子。它们的共同点是：都有一个明确的、独立的评估机制——围棋的胜负、蛋白质结构的匹配度、游戏的得分。有了这个外部的 Evaluation，系统就能在反复试错中完成 Variation → Evaluation → Selective Retention 的完整循环，最终发现人类都没见过的新解法。

3.3 映射回 Loop Engineering

把 Sutton 的理论套回 loop engineering，对应关系非常清晰：

• **Variation = Agent 每一轮生成的不同方案、不同代码改动。**Agent 每一次尝试都是一次变异，它可能改对，也可能改错，但多样性是探索的前提。
• **Evaluation = External Observation（外部观察/反馈）。**CI 过没过、测试通没通过、埋点数据有没有上报——这些就是独立的、客观的评估信号。
• **Selective Retention = 保留通过验证的改动，丢弃失败的尝试，进入下一轮。**测试过了就保留这个修改，没过就回退或者换方案再试。

这就是为什么 observation 必须来自外部。如果评估是 Agent 自己做的——“我觉得我写对了”、“这个方案应该没问题”——那就等于把 Variation 和 Evaluation 混在了同一个主体里，Sutton 说的那个完整的发现循环就断了。循环再多轮，也只是在原地打转，不会产生真实的收敛和进步。

下面这张对比图直观地展示了完整的发现循环与缺少评估环节的区别：

四、强化学习视角——Agent-Environment 交互循环

如果说 Sutton 的发现理论是从"创造力从哪来"的角度回答了外部反馈的重要性，那么强化学习的经典框架则从更基础的层面，给出了 loop engineering 的完整理论原型。

4.1 强化学习的基本交互循环

强化学习研究的是智能体（Agent）如何在环境（Environment）中通过试错来学习最优策略。它的核心就是一个永不停歇的交互循环：

1. Agent 观察当前环境的状态（State / Observation）
2. Agent 根据当前策略选择一个动作（Action）
3. 动作作用于环境，环境转移到新的状态
4. 环境返回一个奖励信号（Reward），告诉 Agent 这一步做得好不好
5. Agent 根据奖励更新自己的策略，然后回到第 1 步

这个循环的关键在于：奖励（Reward）和状态（State）都是环境给的，不是 Agent 自己说了算的。Agent 可以选择做什么，但它不能决定结果好不好——结果由环境裁决。

4.2 与 Loop Engineering 的一一对应

把强化学习的框架和 loop engineering 放在一起，几乎是严丝合缝的对应：

强化学习概念	Loop Engineering 对应
Agent（智能体）	AI Agent / Codex / Claude Code
State（状态）	当前任务状态——代码现状、CI 状态、PR 状态
Action（动作）	Agent 执行的操作——改代码、跑测试、回评论
Reward / Environment Feedback（奖励/环境反馈）	External Observation——CI 结果、测试退出码、埋点数据
Policy（策略）	Goal + Workflow——Agent 的行为规则和目标
Policy Update（策略更新）	每轮迭代后的方案调整——根据反馈决定下一步做什么

这个对应关系不是表面的类比，它揭示了 loop engineering 的本质：我们其实是在把大语言模型从"监督学习模式"切换到"强化学习模式"。

传统的 prompt 是一次性的——给输入，出输出，完事。这更像监督学习的推理：模型根据训练学到的模式给出一个答案，然后就结束了，没有后续的反馈和调整。

而 loop 是交互式的、持续迭代的。Agent 的动作改变环境状态，环境给出反馈，Agent 根据反馈调整下一轮的动作，这个过程不断重复直到目标达成。这就是典型的强化学习交互范式。

4.3 为什么这个视角很重要

从强化学习的视角看 loop engineering，很多工程决策就变得顺理成章了：

**为什么必须有外部反馈？**因为强化学习里 Reward 必须来自环境。如果 Reward 是 Agent 自己给自己发的，那就不是强化学习了，那叫自嗨，学不到任何真实的东西。

**为什么 Goal 要定义得很精确？**因为 Reward 函数的设计直接决定了 Agent 最终学会什么。目标模糊，Agent 就会朝着模糊的方向优化，最后得到的大概率不是你想要的。

**为什么不能无限循环？**因为强化学习里也有探索效率的问题。在错误的方向上探索越久，浪费的资源越多，所以必须有刹车机制——轮数上限、无进展停止、成本控制。

下面这张经典的 Agent-Environment 交互图，可以帮助你建立这个框架的直观印象：

理解了这个底层框架，再来看工程上的各种 loop 设计，就不会只停留在"工具怎么用"的层面，而是能看清每一种设计背后的权衡和取舍。下一章我们就来看具体的工程落地——四层循环的委托阶梯。

五、工程落地——四层循环的委托阶梯

理论讲清楚了，我们回到工程实践。Claude Code 官方把 loop 分成了四类：turn-based、goal-based、time-based、proactive。这个分类不只是功能清单，它更像是一个"委托阶梯"——每上一层，你就多交出一部分控制权，同时系统边界也跟着发生变化。

从人完全掌控，到 Agent 自主决策，中间不是一步到位的。它是一个逐步放权的过程：先交检查，再交停止条件，再交等待和触发，最后才交一小段决策权。每一步只退一小格，系统才稳。

5.1 第一层：Turn-based Loop——先交出去"检查"

最基础的循环是 turn-based，也就是每一次 prompt 本身就构成一个小循环。Agent 读代码、改代码、跑检查、看结果、再决定要不要继续。

很多人一听 loop 就想上自动化，但最稳妥的第一步，其实不是让它自己跑更多轮，而是先把检查标准写下来。

比如给仓库补一个 PR 验收的 Skill 或者验证脚本，明确规定：改动了哪些文件就要跑哪些测试，UI 变了要截图对比，console 不能有新报错，每一步的退出码是多少。这些检查步骤不写下来，Agent 每轮都要临场猜团队的验收习惯，猜出来的标准大概率和你想的不一样。

这一层的核心交付物不是自动化，而是验收标准的资产化。检查步骤从人的脑子里，变成了仓库里可复用的脚本和文档。不先把这一步做扎实，后面的自动循环就没有地基——Agent 可以跑得很勤快，但每轮结束时仍然回答不了那个根本问题：它到底按什么标准说自己做完了？

5.2 第二层：Goal-based Loop——再交出去"停止条件"

检查标准固定下来之后，下一步才是定义 Goal：告诉 Agent 什么情况下可以停。

一个好的 goal 包含两样东西：证据和刹车。

证据是可验证的完成标准——测试通过、lint 干净、diff 不越界。这些是客观的、可检查的，不是主观感受。刹车是安全边界——最多跑几轮、连续几轮没进展就停、改动范围不能超过哪些目录。防止 Agent 在死胡同里反复消耗，也防止它为了"完成目标"而越界乱改。

这里有一个很重要的工程细节：评估者和执行者最好分离。Claude Code 的 /goal 命令就是这样设计的——每轮结束后，由一个独立的评估模型来判断目标是否达成，而不是让执行任务的那个 Claude 自己审自己。虽然这个评估器也不是全知的（它只能看对话里已经有的内容，不会自己去跑命令），但分离本身就比自写自审要稳得多。

对应到 Sutton 的发现理论，这一步就是把 Evaluation 从 Variation 里独立出来。同一个主体既生成又评估，评估一定会偏向自己生成的结果。

5.3 第三层：Time-based Loop——交出去"等待和触发"

再往上一层，是时间触发的循环。PR、CI、部署、review comment，这类任务有一个共同点：任务本身没变，但外部输入在变。人最烦的也就是这部分——知道下一步该做什么，但不想每十分钟切回去看一眼。

这时候 /loop 才有意义。固定间隔或者动态间隔地让 Agent 回来检查一下外部状态，有新的 review 就处理，CI 跑完了就看结果，没变化就继续等。

但要注意它的边界：time-based loop 是会话级的、短期的。当前会话开着、本机环境在，它才能工作。关了终端、开了新会话、会话过期了，它就停了。它适合用来少切几次窗口，不适合被当成企业级的长期任务系统。

另外一个优化思路是：能用监控、日志流、事件驱动解决的，不要靠反复 prompt 轮询。频繁唤醒模型本身就是成本。外部观察的获取方式越轻量，循环的效率就越高。

5.4 第四层：Proactive Loop——最后才交"决策"

最顶层是 proactive loop——完整的无人值守流水线。多个 Agent 分工协作，有的分类，有的修复，有的审查，配合动态工作流编排，自己分派任务、自己推进进度、自己收口。

这一步最容易让人兴奋，也最容易出事。因为交出去的不只是触发时机，还有一整段决策流程：哪些问题值得处理、用哪个方案、什么时候算做完、怎么回复外部系统——这些原来由人做的判断，现在交给系统了。

**最高风险原则：**凡是会替人做决策的 loop，必须有独立复核机制。执行者和判定者要分开，可以是 reviewer agent，可以是自动化测试，可以是规则检查和白名单，但不能让做决策的那个 Agent 自己说自己对。

到了这一层，prompt 质量已经不是主要问题了。身份、权限、审计、成本、责任边界开始变成主问题——这个 routine 用谁的身份做事？能推哪些分支？能访问哪些外部系统？超过预算怎么办？连续失败了怎么办？结果写到哪里让人复核？

这些问题听起来不如"全自动修复 bug"酷，但它们决定了第二天早上你看到的是一个可审查的结果，还是一堆已经发生的、无法回滚的副作用。

下面这张阶梯图展示了四层循环逐步放权的过程：

六、实践原则——设计好 Loop 的几条铁律

结合前面的理论和工程实践，我们可以提炼出几条设计 loop 时的通用原则。

6.1 先写刹车，再写循环

没有停止条件的 loop 是危险的。在写"它要做什么"之前，先写清楚"它什么时候必须停"。

常见的刹车维度包括：最多轮数、连续无进展停止、token/成本上限、改动范围越界检测、敏感文件触碰告警、异常退出码熔断。一个都不能少。

强化学习里有一个概念叫"安全探索"，意思是探索过程中不能进入不可逆的危险状态。Loop 设计也是一样——先保证出问题能停下来，再考虑怎么让它跑得更快。

6.2 Observation 必须外部化、客观化

这是整篇文章最核心的原则，值得反复强调。

优先用命令退出码、测试结果、监控数据、API 响应、文件内容对比这些客观信号做 observation。能自动化验证的，不要留到人工判断。绝对不要让 Agent 自己评估自己的工作质量——考生不能自己改卷子。

如果某个目标暂时找不到客观的外部验证方式，那说明这个目标还不适合交给 loop 去做。先把验证手段补上，再谈自动化。

6.3 执行者和判定者分离

写代码的 Agent 和审核代码的 Agent 不要是同一个。执行 loop 的和判断 loop 是否完成的，最好也分开。

这对应 Sutton 发现理论里 Variation 和 Evaluation 的分离，也对应强化学习里环境和智能体的分离。评估的独立性，是发现和学习能够成立的前提。

工程上可以有多种实现方式：独立的 reviewer agent、自动化测试套件、静态规则检查、截图对比、预算阈值、变更白名单。形式不重要，关键是判定权不在执行者手里。

6.4 每一步只退一小格

不要一上来就追求全自动。先交验证，再交停止，再交等待，最后才交决策。每一步只退一小格，确认这一层跑稳了再往上走。

第一次让 Agent 值夜班，目标不要定成"让它把活全干了"。更合理的目标是：看看它会不会乱改范围，会不会把失败原因说清楚，会不会在该停的时候停。即使它什么都不改，只把 CI 状态、review 意见和风险点整理清楚，这一晚也算有价值。

从小范围、低风险的任务开始试跑。改动只碰一个模块、有现成测试、不涉及支付/权限/迁移/生产配置、review 主要是机械修改——选这样的任务做第一晚的试验。

6.5 留下完整证据链

每一轮执行了什么命令、退出码是多少、试过哪些失败的方案、改动范围有多大、有哪些人工判断点、总共花了多少成本——这些都要完整记录下来。

Loop 跑的时间越长、层级越高，人接手时的上下文断层就越严重。第二天早上你不会想只看到一句"done"，你想看到的是可追溯、可复核、可回滚的完整工作记录。

证据链也是问责的基础。出了问题能追溯到哪一轮、哪个动作、哪个决策出了错，系统才敢真正放权。

七、结语——从 Prompt Engineering 到 Loop Engineering

过去几年，我们聊得最多的是 Prompt Engineering——怎么写提示词能让模型给出更好的答案。这本质上还是监督学习的思维：人给输入，模型给输出，一次交互结束。

而 Loop Engineering 代表的是另一种范式的转变。你不再是站在模型对面一句句喂 prompt 的人，你退到了更高的位置，去设计一个能自己转起来的系统。你定义目标、定义验证标准、定义循环规则，然后让 Agent 在这个框架里持续迭代。

更深层的转变，是从监督学习思维到强化学习思维。监督学习是模仿，是从已有数据里复刻模式；强化学习是交互，是在环境反馈中不断试错、持续优化。前者擅长复刻已知，后者才能探索未知。

这也呼应了 Rich Sutton 的判断：真正的创造力和发现，离不开独立的评估与选择。生成式 AI 只有变异没有评估，所以它只能做模仿者。当我们给 Agent 加上外部的 observation、加上独立的 evaluation、加上完整的闭环，它才开始具备真正发现的可能。

当然，工具在变，问题没变。一个能长期跑的 loop，最后看的从来不只是它怎么自动开始，更是它能不能在证据不足、权限越界、成本异常、结果不可信的时候，准确地停下来。

想把更多工作交给 Agent，先把交接点写清楚。先让它能留证据、可暂停、可复核、可接手。然后，再谈让它多跑几轮。

---

参考资料

• Claude Blog: Getting started with loops
• Richard Sutton: AI Creativity and Discovery（演讲稿，2026年6月）
• Addy Osmani: Loop Engineering 系统化定义
• Boris Cherny: Claude Code 一周年回顾
• Richard S. Sutton & Andrew G. Barto: Reinforcement Learning: An Introduction
• 架构师公众号：《Claude官方教你用 Loop：如何让Claude Code上夜班的四个交接点》