前言

仔细阅读了《Loop Engineering: The Anthropic Playbook for Designing Systems That Prompt Your Agents》.

让我更进一步理解了Loop Engineering。其中感触最深的是：

循环使生成变得廉价，而使判断力变得稀缺
that loops make generation cheap and leave judgment scarce）.

循环不是一种被工具本身能力固化的工具。它会不加改变地放大你带来的任何东西：带来理解，它就放大理解；带来懒惰，它就放大懒惰。它是一个忠实的乘号，它乘以的是人本身。
A loop is not a tool whose quality is fixed by the tool. It is so strong that it amplifies, unchanged, whatever one brings: bring understanding and it amplifies understanding; bring laziness and it amplifies laziness. It is a faithful multiplication sign, and what it multiplies is the person.

分享出来和大家一起学习。

1. 核心定义

循环工程（Loop Engineering）不是教你如何更好地提示 AI，而是教你如何设计一个能自动提示 AI、自我运转并自我纠错的系统。 它的目的是将人类从“执行者”（在循环内）变为“设计者”（在循环外）。循环并非简单的定时重跑，而是一个能自我发现工作、隔离执行、独立验证、持久记忆并自动调度的闭环系统。

2. 底层基础：六大核心组成部分

这是搭建循环所需的“物理硬件”或基础设施。在实施前，请务必确认您的系统是否具备了这六个“器官”。按从底层保障到上层调度的逻辑排列如下：

好的，我将为您详细展开五个动作的说明，从设计意图、实施要点到常见反模式逐一拆解，便于您在实际构建循环时能准确落地。

3. 循环的五个动作：详细操作指南

这五个动作不是可选项，而是必须全部安装的强制流程。缺少任何一个，循环就会退化为第五章节所列举的五种失败模式之一。

3.1. 动作一：发现（Discovery）

一句话定义：让代理自行找到“今天该做什么”，而不是人类告诉它。

设计意图：发现是循环的“眼睛”。如果这一步做得不好，后续四个动作再漂亮，也只是在错误的事情上浪费算力。人类的价值不应消耗在“指派任务”上，而应集中在“判断结果是否正确”上。

实施要点：

常见反模式（盲目循环）：

• ❌ 人类每天早上手动告诉循环“修 Bug #123、#456、#789”。
• ❌ 发现逻辑硬编码在自动化脚本中，导致维护困难。
• ✅ 正确做法：循环自行读取数据源，自主裁定今日工作清单。

检查清单：你的循环是否能在无人干预下，独立输出一份“今天值得做的事情”清单？

3.2. 动作二：移交（Handoff）

一句话定义：将每个发现的任务安全、隔离地移交给执行代理。

设计意图：移交是循环的“手臂”。它的核心目的是隔离。如果多个代理同时修改同一份代码，会产生无法解决的合并冲突。移交的质量决定了并行效率的上限。

实施要点：

常见反模式（混乱循环）：

• ❌ 五个代理同时修改同一个目录，编辑相互覆盖，合并时一团乱麻。
• ❌ 任务粒度太粗（一个工作区修了三个不相关的 Bug），导致验证和回滚困难。
• ✅ 正确做法：每个任务独立工作区，互不干扰；每个工作区只做一件事。

检查清单：你的循环是否能在并行运行5个代理时，依然保持代码库整洁、无冲突？

3.3. 动作三：验证（Verification）

一句话定义：用独立的、持怀疑态度的另一个代理来检查生成器的输出，能说“不”。

设计意图：验证是循环的“刹车片”和“良心”。这是五个动作中最关键也最容易被跳过的一个。经验证明，生成器审查自己的代码会不自觉地自我表扬（“看起来没问题”）。验证的本质是引入对抗性视角，打破生成器的“自我说服链”。

实施要点：

常见反模式（点头循环）：

• ❌ 生成器写完代码后，调用 go test 看到全绿就宣称“验证通过”。
• ❌ 让同一个代理既写代码又做 Code Review。
• ❌ 评估器仅凭肉眼阅读代码，从不实际运行。
• ✅ 正确做法：换入一个独立代理，让它实际运行你的应用（如用 Playwright 点按钮），凭事实证据下结论。

检查清单：你的循环是否曾经对任意一个输出说过“不”？如果几百轮以来它从来没有拒绝过任何东西，那你的验证环节可能根本不存在。

3.4. 动作四：持久化（Persistence）

一句话定义：将本轮的状态、结论、产出物保存到对话之外的持久存储中。

设计意图：持久化是循环的“记忆硬盘”。代理的上下文窗口一刷新就失忆，如果结果只活在聊天记录里，循环就永远在原地打转。持久化让循环具备累积性——今天的结论是明天的基础。

实施要点：

常见反模式（健忘循环）：

• ❌ 把所有结论只写在聊天窗口里，第二天刷新后一切归零。
• ❌ 状态文件只存在于本地，没有提交到仓库，云端调度器读取不到。
• ✅ 正确做法：每轮结束前，将关键发现、已完成项、待办项、阻碍项全部写入磁盘并提交。

检查清单：你的循环是否能在你合上电脑一周后重新开机时，准确记得上周干到哪一步了？

3.5. 动作五：调度（Scheduling）

一句话定义：让循环“活”起来——按定时或事件自动触发下一轮，无需人类点击“运行”。

设计意图：调度是循环的“心脏起搏器”。没有调度，你拥有的只是一份写得不错的脚本，需要你手动拉绳才能动一下。调度让循环从“工具”变成“员工”。

实施要点：

常见反模式（手动循环）：

• ❌ 循环跑得再好，但人类忘了点“运行”，它就安静地躺平。
• ❌ 把本地 /loop 当成“无人的云端作业”，一关机就傻眼。
• ✅ 正确做法：根据任务性质选择合适的调度器——本地高频率，云端真自主。

检查清单：你的循环能否在你休假一周、电脑关机的情况下，每天依然自动运行并产出成果？

4. 运行机制：五个动作如何在六大部件上实施

有了上面的“基础设施”，循环运转时的 5 个动作 就不再是抽象的概念，而是对 6 个部件 的具体调用和组合。

5. 开箱即用：最小可行的循环工程样例

这是论文提供的“麻雀虽小，五脏俱全”的完整骨架。您可以直接复制此模板启动您的第一个循环。

# 1. 调度 (Scheduling) -- 依赖【自动化】部件
# 文件: .github/workflows/triage.yml
on:
  schedule:
  - cron: '0 6 * * *' # 每天早上6点（云端）运行

jobs:
  triage:
    runs-on: ubuntu-latest
    steps:
      # 2. 发现 (Discovery) -- 依赖【技能】+【连接器】部件
      - name: 读取CI失败和待处理Issue
        run: claude --skill morning-triage

      # 3. 持久化 (Persistence) -- 依赖【记忆】部件
      # 技能会自动写入 ./state/triage.md 并提交回仓库

      # 4. 移交 (Handoff) + 验证 (Verification) 
      # 依赖【工作区】+【子代理】部件
      - name: 并行修复
        run: |
          for finding in $(parse ./state/triage.md); do
            claude --worktree "fix/$finding" \
              -goal "tests pass and lint is clean" \
              "draft a fix for $finding"
          done
      
      # 5. 人工审核 (Human Review) -- 最后的防线
      # 注意：PR是打开的，但【绝不自动合并】，不确定的放入 ./inbox/

您必须自定义的部分：

1. 技能文件 (.claude/skills/morning-triage/SKILL.md)：告诉代理去读哪些 CI 日志、哪些 Issue，以及如何判断优先级。
2. 状态文件 (./state/triage.md)：记录上一轮发现了什么，处理到了哪一步。

5.1. 启动顺序建议

论文明确建议：不要一上来就追求“五个全装 + 大规模并行”。安全的成长路径是：

核心原则：先证明它能停住，再让它跑起来。 一个不会拒绝的循环，跑得越快，离灾难越近。

6. 避坑指南：对 Loop Engineering 的 5 大常见错误理解

在实际操作中，您的循环并不一定会因为代码写得好而成功，反而会因为观念上的偏差而失败。以下是论文指出的五个致命误区：

7. 终极准则：两条必须遵守的“黄金铁律”

1. 生成器与评估器必须分离。
   这是循环的“刹车片”。如果没有独立的评估器（即另一个子代理），您的循环就是一台没有刹车的跑车。先证明它能停住一个坏的结果，再放手让它去跑一百个好结果。

2. 永远不要移除人工审核点，并设置预算上限。
   在运行前设置每日 Token 上限和最大重试次数，防止一个死循环 Bug 烧光账户余额。同时，永远不要删除检查点（如要求人工点击合并 PR）。那个检查点，是您保持工程师控制权、避免被机器“架空”的最后一道门。