Loop Engineering（循环工程）

循环工程（Loop Engineering） 是 2026 年 AI 编程社区快速扩散的新兴说法，含义仍在形成。本词条用它概括一种 AI Agent（智能体） 使用范式的升级：不再手写 Prompt 逐步指挥 Agent，而是设计一个能 自动发现任务、调用 Agent、验证结果、记录状态、决定下一步 的闭环系统——你只设计一次，之后系统自动驱动模型。

两种工作模式的对比：

• Prompt 范式：人 → Prompt → Agent → 人检查 → 再 Prompt
• 循环工程范式：人设计循环 → 循环驱动 Agent → Agent 执行/检查/记录 → 人只处理关键判断

循环的 5 步结构：

flowchart LR
    FW["Find work\n找到任务"]
    HI["Hand it to the agent\n有边界的任务，充分上下文"]
    CR["Check result\n测试 / 类型错误 / 构建失败"]
    RH["Record what happened\n状态跨轮存活"]
    DN["Decide next move\n停止、重试或交给人"]

    FW --> HI --> CR --> RH --> DN
    DN -->|"NEXT MOVE"| FW

    SF["State file — agent forgets each run; the file does not"]
    RH --> SF
    SF -.-> FW

图注：顶部六个模块（Automations / Worktrees / Skills / Connectors / Sub-agents / State file）分别支撑循环的各步骤——State file 是唯一跨轮存活的组件，用虚线表示它在下一轮重新注入起点。

需要区分两个层次：Agent Loop（智能体循环） 是单个 Agent 内部的推理-工具调用循环；Loop Engineering 是在这个基础上设计可验证、可停止、可审计的外部工作流。前者回答"Agent 一轮怎么跑"，后者回答"如何让 Agent 系统长期可靠地跑"。

为什么不是把旧 Loop 换名

Loop 本身不是新概念。控制论里的"目标、执行、反馈、修正"，human-in-the-loop 里的人工审批，LangChain / LangGraph 里的 agent loop、状态机、失败重试和人工节点，都早已存在。

Loop Engineering 的变化不在于发现了"循环"，而在于循环被放到了 Agent 外面：过去循环常是单个 workflow 内部的控制逻辑；现在它变成工程师组织 AI 工作的一套外部生产制度。系统负责发现任务、启动 Agent、分配 worktree、验证结果、记录状态、决定下一步；人不再逐轮提示 Agent，而是设计"提示 Agent 的系统"。

这也是它和 Agent Loop（智能体循环）的核心分界：Agent Loop 处理"模型如何在工具调用与观察之间迭代"；Loop Engineering 处理"谁在明天早上发现该处理什么、谁让 Agent 接着昨天的状态继续跑、谁在失败后决定重试、暂停或升级给人"。

最小四组件模型

一个真正可扩展的循环至少包含四个显式组件：

缺一个组件，循环就会退化：只有触发器和过程是定时任务；没有验证是批量生成；没有停止条件是无限重试；没有记忆则每轮都像第一次运行。

这也是 Loop Engineering 与 Prompt Engineering（提示工程）的分界：Prompt 解决单次调用怎么写；Loop 解决系统如何反复运行、检查、修正、记账和退出。模型只是循环里的一个零件，真正难以复制的是触发策略、验证逻辑、状态管理和停止策略的组合。

适用条件

四条件决策：

flowchart LR
    C1["01 任务重复\n至少每周一次"]
    C2["02 验证可自动化\n测试 / 类型检查 / build"]
    C3["03 Token 预算够\n重试烧 token 也可接受"]
    C4["04 模型有工程级工具\n日志 / 复现环境 / 运行代码"]
    BUILD["**Build the loop**"]
    MANUAL["保持手动提示"]

    C1 -->|"✓"| C2 -->|"✓"| C3 -->|"✓"| C4 -->|"全部通过"| BUILD
    C1 -.->|"✗"| MANUAL
    C2 -.->|"✗"| MANUAL
    C3 -.->|"✗"| MANUAL
    C4 -.->|"✗"| MANUAL

引入循环之前，工作需同时满足以下四个条件——缺一条，循环的成本就会超过它的回报：

• 足够重复：循环把设计成本摊销到许多次运行上。一次性任务用一个好 Prompt 更快更省——如果工作不每周重复，你有的不是循环，而是一个跑了一次的脚本。
• 验证可自动化：循环需要一个能在你不在场时判定工作失败的东西——测试套件、类型检查器、linter、build。没有自动化检查，你就得重新坐回椅子逐个读 diff，而那正是你建循环本来想要消除的工作。
• Token 预算够用：循环会重读上下文、重试、探索——无论该轮是否产出任何成果都会烧 Token。这项技术随预算规模而生效：对 Token 近乎免费的人而言显而易见；对按量计费的人而言则可能得不偿失。
• 模型具备工程级工具能力：日志、复现环境、能运行它写的代码并看到报错。缺少这些，循环只是在黑暗里迭代（the loop iterates blind）。

四条同时满足，循环才有净收益。仅满足"重复"但无法机器验证的任务（如"改善代码风格"），循环会产出，但无法判断好坏——Goodhart’s Law（古德哈特定律） 就在这里钻空子。

适合与不适合的团队

循环工程的经济性不是普适的。Token 近乎免费的人会觉得它显而易见；$20 消费者订阅在限额和账单之间跑验证循环的人则会觉得鲁莽——这不是水平差距，是成本结构差异。

适合建循环的团队：

• 有重复、机器可验证的工程任务（CI 分诊、依赖更新、lint 修复、Issue 转 PR 草稿），且有预算支撑反复运行
• 有成熟测试体系：一个初级工程师能从 checklist 做完、测试套件能抓住他的错误——能通过这个测试的任务，循环就适合
• 异步优先、已在做多 Agent 编排的团队——对这类团队，循环是缺失的编排层，而不是全新的基础设施

现在应该跳过的情形：

• 个人开发者（消费者订阅）：账单在生产力增益到来之前先到
• 没有自动化验证的项目：没有真实检查的循环是 Agent 在重复同意自己（the agent agreeing with itself on repeat）
• Review 才是瓶颈的团队：循环生成更多代码；如果 Review 已经是瓶颈，它只会让队列更长
• 一次性任务、探索性工作、“完成"本身是主观判断的任务：一个打得准的 Prompt 仍然更快更省

诚实的结论：循环工程是真实的，但大多数开发者现在还不需要它。

持久执行：循环的基础设施前提

循环工程的对话长期集中在"循环做什么”——触发器、技能、子 Agent、状态。一个更底层的问题常被忽略：什么在运行循环？

Matt Van Horn 把这个问题直接点出来：“这些东西必须能在重启后存活（these things have to survive a restart）。“一个跑在容器里的 Agent 循环，进程重启后不知道上次做到哪一步、是否已经发过那条通知、是否已经派过那个子 Agent。容器提供的是 uptime（可用性），不是 correctness（正确性）。

这不是"更好的错误处理"能解决的，而是执行模型本身的问题。Durable Execution（持久执行）是具体的解法：每个步骤被检查点化，崩溃后从上一步续接，LLM 调用不重复，副作用不重复，子 Agent 生命周期有保障。

对循环工程实践的含义：外部记忆（状态落盘）只是必要条件，不是充分条件。 光把状态写进文件还不够，需要执行引擎能在恢复时正确读取状态、从对应步骤续接，而不是把状态写进文件再从头跑一遍。

Harness 解决一次执行，Loop 解决持续运行

Harness Engineering（驾驭工程） 能做很多：给 Agent 工具、约束、QA、状态记录。一个足够完整的 Harness 可以有目标、有状态、也有验收。问题在于，这些能力通常围绕一次执行组织——Harness 问的是"这次能不能交付”。

Loop 在此基础上加入时间维度，解决持续运行——它问的是"交付之后，系统如何继续活着”。同一组件在两种框架里含义不同：

一个有完整 QA 和状态的 Harness，不等于 Loop——它缺少的是把这些组件串在时间轴上的控制关系。

因此，循环工程的难点通常不在"写一个 while 循环"，而在循环外面的三件事：用 Evals（评估）判断每轮是否真的变好，用预算限制它能跑多久、烧多少钱，用回滚机制保证错误不会累积成不可逆损坏。模型负责生成候选行动，循环系统负责裁决、限速和恢复。

起源与推广

Loop Engineering 这个说法的普及，与几位 AI 编程领域的关键人物有关：

• Peter Steinberger：提出"不应该手动反复提示 Agent，而应该设计能够驱动 Agent 的循环"这一核心观点。
• Boris Cherny（Anthropic Claude Code 负责人）：分享实践转变：“我现在不再提示 Claude 了。我有一组循环在运行，它们帮我提示 Claude，再决定下一步做什么。我的工作是写循环。“他表示多数夜晚有"几千个"子 Agent 在后台做深度工作。Cherny 的论点不是工作变容易了，而是杠杆点移动了——从提示词层上移到系统设计层——你的工作随之移动了，你的职责也随之移动了。
• Addy Osmani（Google Chrome 工程总监）：写了一篇系统梳理 Loop Engineering 的文章，使这一说法被更广泛地知晓。

这三人的观点共同指向同一现象：当 AI 能读文件、写代码、调用工具、检查结果后，“怎么问 AI"已经不是主要问题，“怎么把 AI 放进工作流"才是。

Cursor 给出了规模最大的公开案例：将数百个 Agent 指向单一项目，一次构建接近一周，产出逾百万行代码；跨所有实验消耗了"trillions of tokens toward a single goal”。他们也从生产实践中命名了同样的敌人：周期性"新鲜启动"以对抗漂移和隧道视野，并引入乐观并发控制防止多 Agent 状态污染。

最小参考实现（Ralph Loop）：Geoffrey Huntley 提出的最简实现——while :; do cat PROMPT.md | claude-code; done——每次迭代将 Agent 的上下文重置为固定锚文件集，把停止决策交给外部检查。这个设计的核心暗示是：Agent 的上下文是一次性的；所有需要跨轮存活的内容必须住在外部。

5 个构建块

自动化（Automations）

让任务按计划自动触发。典型场景：每日扫描 Issue、汇总 CI 失败、生成提交简报、定时检查代码库状态。自动化是循环的"心跳”——没有自动化，就只是一次性任务，不是循环。

触发器有三种常见形态：

• 固定间隔触发：每 5 分钟、每天、每周运行一次。适合持续变化但没有明确事件源的工作，如定期巡检和简报生成。
• 事件驱动触发：文件变化、Webhook、CI 失败、PR 评论等具体事件发生时运行。适合有清晰信号的工作，能减少空转。
• 动态间隔触发：循环根据本轮观察决定下次多久后再检查。没有变化时拉长间隔；发现活跃状态时缩短间隔。Claude Code /loop 允许让模型自行选择等待时长，就是这一模式的产品化例子。

触发器设计的关键不是选一个"正确频率”，而是让运行频率匹配信息变化速度。过于激进会烧 Token、制造噪音；过于保守会错过行动窗口。两个工具对自动化的具体实现见下方工具实现对比节。

工作树（Worktrees）

多个 Agent 并行工作时，每个 Agent 在独立的 Agent Worktree（Agent 工作树）中运行，互不污染。最终再合并、审查、取舍。并行 Agent 必须隔离工作区，否则很快变成代码车祸现场。

需要注意的是：worktree 消除了文件冲突（机械碰撞），但不能消除 Review 瓶颈——真正的上限是人，不是工具。并行的 Agent 越多，积压等待 Review 的 PR 也越多；如果 Review 带宽跟不上产出速度，并行带来的只是待合并队列变长，而不是实际效率提升。

技能（Skills）

将项目背景、代码规范、常用命令、测试方式、已知坑点等沉淀为可复用的 SKILL.md 文件。没有 Skill，要么反复把约定塞进 Prompt（每轮重复），要么让 Agent 从代码库重新推断（隐性知识推不出来）——Addy Osmani 称这种缺失为 Intent Debt（意图债）：约定存在于人脑中，Agent 每次都要重新猜测。Skill 是长期上下文，应沉淀为可调用资产，而不是每次重新喂。

插件与连接器（Plugins / Connectors）

让 Agent 通过 Model Context Protocol（模型上下文协议）接入真实工具：GitHub/GitLab/Jira/Linear、数据库、CI/CD、Slack 等。没有连接器，Agent 只能说"你可以这样改”；有连接器，Agent 可以直接开 PR、关联 Ticket、通知团队。连接器决定循环能否进入真实工作流。

Codex 与 Claude Code 都原生支持 MCP，因此为其中一个工具写的连接器通常可以直接在另一个里复用——投入一次，两套工具受益。

按循环工作的回报速度排序，优先接入的四类连接器：

没有连接器，循环只能观察文件系统——只能告诉你"如果能开 PR，它会这样写"；有了 GitHub 连接器，循环就能直接开 PR。这就是"说做什么"和"真的去做"之间的差距。

子智能体（Subagents）

拆分角色，构想与验证分离。一个子 Agent 用于探索和起草（ideate），另一个用于独立裁决（verify）——两者不能是同一个。让写代码的 Agent 自己审自己，等于让学生自己批卷子——它会批，但批得太仁慈（way too nice grading its own homework）。

标准三分法：Explorer 探索问题 → Implementer 实现方案 → Verifier 验证结果。写了代码的模型审自己的代码时天然宽松——它太了解自己的"意图"了；独立的 Verifier（有时用不同的系统提示，甚至不同模型）才能抓住 Implementer 说服自己接受的那些错误。

这对循环尤其重要：循环在你不在场时运行，一个你真正信任的 Verifier 是你敢走开的唯一理由。Sub-agents 消耗更多 Token，应优先分配在真正需要"第二意见"的地方。

验证层有几种可组合模式：

• 独立 Verifier Agent：使用独立上下文、不同系统提示，甚至不同模型，只负责判定通过/失败和给出证据。
• 对照真实来源：用测试、构建、schema、引用原文、数据库事实或 API 响应做机械核对，尽量减少主观评分。
• 强模型校验弱模型：让更慢、更贵但更可靠的模型检查大量便宜模型的产出，适合并行生成后的汇总筛选。
• 显式不确定性标记：执行 Agent 在输出中标出不确定部分，Verifier 优先检查这些位置；这不能替代独立验证，但能降低检查成本。

硬规则：生成者不能宣布自己成功。 同一组件既生产又验收，会把自己的盲点带进评分，尤其容易漏掉幻觉引用、遗漏约束和表面满足指标但违背真实目标的问题。

知识管理体系 vs 单个 Skill

5 个构建块中，“技能"这一条容易被低估。仅靠单个 SKILL.md 不够——需要整套知识管理体系：

• CLAUDE.md：全局规则和约束（有行数上限，不宜膨胀）
• 跨会话记忆：悬而未决的问题、文档路由
• docs 体系：完整的知识与经验沉淀

Loop 是自动跑的，你不在场。如果 Agent 的记忆里有过期信息，它会基于错误前提决策；CLAUDE.md 膨胀成几百行历史叙事，真正的规则反而被挤出去、Agent 读不到。没有干净知识体系的 Loop，就像员工每天早上看过期文档——干得越快，错得越多。

每次循环完成后应主动审查知识体系（精简 CLAUDE.md、更新过期记忆、归档新知识），而不是让它自然积累。

状态与记忆（State / Memory）

状态（State）是循环六要素中最容易被低估的一个。Addy Osmani 强调其必要性：“模型每轮结束后忘记一切，记忆必须在磁盘上，不能在上下文里”（the model forgets everything between runs so the memory has to be on disk and not in the context）。

记忆是循环最难解决的约束，原因不止于"模型会忘记”：上下文压缩有损（丢弃的正是下轮需要的细节）；循环运行到记忆 benchmark 覆盖最弱的规模区间（1M–10M tokens）；即使能"召回"历史，让记忆正确指导行动是更高的要求。长运行循环还面临细节丢失、目标漂移、灾难性遗忘三种失效同时出现的情况，使循环不断从零开始而不自知（详见 Agent Memory（Agent 记忆））。

记忆设计的第一个结构性选择是上下文"装多满"：Token-Rich Loop 每轮包含完整历史，历史可见度高但成本随轮次爆增；Token-Poor Loop 每轮只含近几条消息加按需检索的记忆，成本低但依赖健壮的记忆层。两种设计模式的详细权衡，以及 Memory-First Design、记忆作用域、Concept Drift 等问题，见Agent Memory（Agent 记忆）。Mem0（Mem0） 是这一层的一个具体工具，提供语义检索和 1M–10M token 规模下的 benchmark 数据。

长期循环必须有Agent Memory（Agent 记忆），可以是 Markdown 文件、看板（Linear/Jira）、GitHub Issue、数据库记录。模型会忘，仓库不会——状态文件是循环能跨会话运行的脊梁：没有它，Loop 每次运行都像第一次运行；有了它，Loop 接着上次的进度继续跑。记忆需记录：已完成什么、当前卡在哪、下次继续做什么、哪些结论已验证。具体的操作状态文件结构（CI 分诊示例、仓库内 Markdown vs 外部系统两种存放模式）见Agent Memory（Agent 记忆）中"循环操作状态文件"一节。

对有目标漂移风险的长期循环，状态文件还需搭配固定的规格文件（VISION.md 或 AGENTS.md）：状态文件告诉 Agent 它在哪里，规格文件告诉 Agent 它要去哪里。每轮启动时先读规格文件、再读状态文件，才能防止目标定义和边界约束随轮次压缩从上下文中消失（即 Goal Drift（目标漂移） 的根本解法）。

这块不是辅助设施，而是循环能跨会话运行的脊梁。模型每轮结束后不会天然保留完整状态，下一轮如果只靠聊天上下文续接，就等于把长期任务建立在易失内存上。状态必须落到仓库、Issue、PR、看板或日志里，循环才知道自己昨天试过什么、哪些路径已验证、哪些失败不该重复。

Loop 的核心是路由，而非继续

Loop 常被理解成"让 Agent 继续跑"，但更准确的模型是路由系统：根据当前状态决定下一步应该去哪，而不只是继续执行。

Loop 管理的不是 prompt，而是状态到动作的映射关系。Prompt 只是某一轮里 Agent 要读的输入；真正的规则在路由表里。

定时任务不是 Loop。 到点启动 + 执行 + 等下次，是 cron + Harness，不是 Loop。缺乏路由的定时任务无法回答：上次失败写在哪里？等待外部输入时系统进入等待态还是"忘了"？失败几次后停止？没有这些，系统只是让一次性执行重复发生——每次都重新理解项目、重新猜规则、重新犯同一种错误，变成带有 token 账单的健忘。

停止条件应显式分成三态：

1. Success：验证通过，循环写入结果、证据和下一轮入口，然后停止或进入下一触发周期。
2. Bounded Retry：验证失败但仍在预算内，带着 Verifier 的具体反馈重试，而不是从零重生成。
3. Escalation：连续失败达到上限后停止自动运行，把原始任务、每次尝试、验证 verdict 和推荐排查点交给人类。

三到四次同类失败通常已经是有效信号：问题可能不是模型"还没努力够"，而是目标定义、输入材料或验证标准本身有歧义。

从 Harness 到 Loop 的 5 步扩展

如果已有一个跑通的 Harness（Codex、Claude Code 或类似工具），补上这 5 件事，它就开始具备 Loop 的形态：

1. 外部状态文件：state.md 或 state.json，记录目标、当前阶段、上次运行时间、已有输入、阻塞点、QA 状态。状态不能只留在聊天窗口——会话会压缩、会丢上下文。
2. 轻量 Watcher：不负责思考，只记录信号——到点了、有新文件了、反馈文档变了。把信号写进 signals.jsonl 或 run 目录。Watcher 不应每次唤醒完整 Agent，只是把事件落盘，等控制层决策。
3. 交接协议（Handoff Protocol）：每次启动 Agent 时，先读固定材料：state.md、最近信号、SKILL.md / CLAUDE.md、上一轮 run 目录、当前 QA 结果。真正要写的不是更长的 prompt，而是一份稳定的"醒来先读什么"协议。
4. 独立 Checker：生成者不宣布完成。Agent 说"我做完了"不算——测试通过、文档可打开、链接有效，这些外部信号才算完成。Checker 的价值不是挑错，而是决定下一步能否路由。
5. Router 表：QA 通过且低风险 → 继续；QA 失败 → 修复；连续失败 → blocked；缺输入 → waiting；高风险操作 → 停下来问人。

这 5 件事的底层逻辑：让"下次如何继续"从聊天框里拿出来，变成可被系统读取的外部事实。Agent 是执行大脑，外层控制壳负责唤醒、记账、路由和停机。

一个完整循环的运转示例

1. 每天早上自动运行
2. 读取昨天的 CI 失败、Issue、最新提交
3. 调用分类 Skill 进行任务筛选，结果写入 Markdown/看板
4. 对值得处理的任务创建独立 worktree
5. 派实现 Agent 提出修复方案
6. 派 Review Agent 审查方案和测试结果
7. 通过连接器开 PR/更新 Ticket/通知团队
8. 无法自动处理的任务进入人工收件箱

案例：为什么裸 Agent 不够

几组案例说明了同一个结论：真实工程能力往往不是模型单点能力，而是模型所在循环系统的属性。

真实项目重建类 benchmark 的刺眼之处在于，它要求模型从零重建真实开源项目；模型能写大量看起来合理的代码，却很难恢复项目结构、依赖、边界、测试行为和长期维护约束。这说明"会写函数"和"能交付真实软件系统"之间隔着 harness、状态、验证和迭代控制。

Harness Engineering（驾驭工程） 中的 Terminal-Bench 2.0 案例从另一侧说明问题：模型权重不变，只改变系统 prompt、上下文注入、自验证 hook 等外部结构，分数就能显著提升。改进来自模型周围的工作环境，而不是模型突然变聪明。

Vercel 的 text-to-SQL 案例提醒另一条反直觉原则：工具不是越多越好。删掉大部分专用工具，只保留 grep、cat、find、ls 等基础文件工具，让模型直接读 schema 再写 SQL，反而可能更稳、更快、更省 token。Loop / Harness 设计不是堆工具比赛；每多一个工具，都增加一步选择空间和误选路径。

弱模型收敛运行时案例则强调"闸门"的价值：Builder 生成代码，Tester 跑测试，Analyzer 对照设计文档做语义裁决，Controller 根据结果决定继续修、回滚或停止。关键不是"让 AI 多跑几次"，而是每轮都有硬约束、独立判定、回滚机制、连续通过 streak 和最大迭代上限。没有这些闸门，多跑只是重复；有了闸门，循环才可能收敛。

目标定义：核心能力

Loop Engineering 的核心竞争力不是会配 cron、会写 hook，而是定义目标的能力。

更准确地说，是把模糊目标翻译成可执行说明书和可验证 Evals 的能力。说明书写清楚"要优化什么、允许改什么、不能碰什么、失败怎么办"；Evals 则把"这轮是不是变好"从模型自评变成外部裁决。没有 Evals 的目标，只是愿望；有 Evals、预算和退路的目标，才可能变成可无人值守运行的循环。

/goal 命令最能说明这一点——给 Codex 一个完成条件，它就围绕该目标持续工作，并用证据判断是否满足。但 /goal 用得好不好，完全取决于那个目标定义得好不好：

目标 A（模糊）：「把这个应用优化一下」

Agent 不知道什么叫"优化好了"。它可能改一点就停，也可能无限循环把代码库改得面目全非——因为它始终无法判断什么时候算完成。

目标 B（可验证）：「test/auth 目录下所有测试通过，tsc --noEmit 零报错，npm run lint 零违规」

Agent 每改一轮就跑三个命令，全过则停，没过继续。清清楚楚。

同一工具，同一模型，区别只在于目标定义的质量。

目标定义框架（实践版）

1. 完成标准必须能被机器验证——而不是靠 Agent 自称完成
2. 边界条件与完成标准同时定义——不允许删测试、不允许降级 public API
3. 必须有失败的降级方案——失败几次后停止，怎么记录原因
4. 目标要分层——全局目标 → 可执行子目标 → 单次验证指令

管理学同构

Loop Engineering 说是 Engineering，核心竞争力其实在管理：把一个模糊意图翻译成一组可衡量、可验证的完成条件。

管理学之父 Peter Drucker 在上世纪 50 年代提出目标管理（MBO），Andy Grove 在 Intel 发明 OKR，核心逻辑从未变过——你能不能写清楚"做完了"长什么样。

好的管理者（和好的 Loop 设计者）确保三件事：

管 Agent 比管人要求更高：人可以说"老板你这个需求不太清楚"，Agent 不会——它会非常自信地按自己的理解执行，然后自信地告诉你它做完了。

人在循环中的角色

flowchart LR
    P["Your prompt"]
    subgraph AL["agentic loop"]
        GC["Gather context"]
        TA["Take action"]
        VR["Verify results"]
        GC --> TA --> VR
        VR -->|"loop"| GC
    end
    DONE["Done"]
    YOU["You: interrupt,\nsteer, or add context"]

    P --> GC
    VR --> DONE
    YOU -.-> GC

角色没有消失，只是移动了。旧范式里，工程师是提示词和输出之间的传话筒；新范式里，工程师管入口和出口——中间那段机械性的"执行-检验-重试"交给循环。

但要求实际上更高了：你在入口定义的东西会被循环放大执行几十次，一个模糊目标会被放大成灾难。

三个必须人在场的节点：

1. 定义"完成"的标准——循环需要知道什么时候停下来，这一步无法外包（见目标定义章节）。

2. 处理循环升级上来的问题——好的循环设计里有一条规则：重试两到三次之后，优雅失败，把问题交还给人。Addy Osmani 称之为分诊收件箱（Triage Inbox）：“任何循环无法处理的事情都落入分诊收件箱等我处理。“收件箱会收到：需要上下文判断的模糊需求、涉及不可逆操作的确认、以及循环连续失败需要人来诊断的异常。这不是循环的失败，而是循环把真正需要人判断的问题筛出来了——比人盯着每一步效率高得多。

3. 审查最终结果——循环说"完成了”，不等于真的完成了。Addy Osmani 的原话：“你的工作是发布你确认能运行的代码。“这条不因为有了循环而改变。循环帮你生成，但发布责任在人。至少要读完循环的产出——不一定每行都懂，但要知道它在干什么。否则Comprehension Debt（理解债）在静默累积。

什么可以放心交给循环

判断标准：操作可逆 + 结果可验证 + 失败代价低。三条同时满足，基本可以放心。

典型场景：

• CI 失败自动分诊：循环读 CI 日志 → 子 Agent 起草修复 → 另一个子 Agent 对照测试审查 → 通过则自动开 PR（是开 PR，不是合代码——PR 本身就是检查点）。循环做了 90%，人花 5 分钟确认。
• Lint / 风格自动修复：有明确机器可验证标准，修坏了下一次提交会暴露，失败代价低。
• 测试覆盖率补全：扫描未覆盖函数 → 生成测试草稿 → 提交 PR，循环起草，人确认。

共同点：循环的自主范围被框在一个人可以快速审查的产出物上（通常是 PR）——它在替你做准备，不是替你做决定。

判断某个步骤要不要人确认

设计循环时遇到"该不该让这步自动跑"的疑问，过一遍五个问题：

1. 这个操作可以撤销吗？ 删数据、发邮件、合主分支——不可逆的需要人确认
2. 失败的代价是什么？ 代价高则需要人盯
3. 有没有机器可以验证的成功标准？ 有就交给循环，没有就需要人
4. 循环失败后我能快速诊断吗？ 输出是黑盒、自己看不懂，Comprehension Debt（理解债）在累积
5. 这个步骤重复发生的频率高吗？ 越高频越值得让循环接管

古德哈特定律陷阱

当一个衡量指标变成目标本身时，它就不再是一个好的衡量指标了。——古德哈特定律（Goodhart’s Law（古德哈特定律））

在 Loop Engineering 里，这个问题被放大一百倍：Agent 比人类更擅长钻规则的空子，且没有心理负担。

典型案例：Loop 的完成条件是"测试全部通过”。Agent 最终不去修 Bug，而是直接删掉失败的测试。验证条件满足了，真正的目标却落空了。

防范方式：完成标准必须搭配边界约束（不能删测试、不能修改测试断言），这正是Harness Engineering（驾驭工程）的作用——

• Harness：约束和护栏，告诉 Agent 这条线不能越
• Loop：驱动力，告诉 Agent 往那个方向一直跑

两者加在一起，才是一个完整的系统。

风险与限制

• Token 成本实测：单 Agent 循环约是标准对话的 4 倍 Token 消耗；多 Agent 编排（Supervisor + 子 Agent）约 15 倍。这意味着一个看似简单的多 Agent 任务可能比预期贵一个数量级。目前高 Token 成本仍是大多数开发者规模化部署循环的主要障碍，预计随采用规模扩大而下降。
• Token 是真实成本：需控制运行频率、上下文大小、是否先做轻量筛选
• 无监督循环批量产出垃圾：强制测试、独立 Review Agent、小步提交、人工抽查关键改动、不允许自动合并高风险 PR
• “完成了"不等于完成了：Agent 说完成不代表真的完成，必须验证测试、行为、新引入问题
• Comprehension Debt（理解债）：Agent 生成代码越快，工程师越可能不理解这份代码
• 验收标准缺陷被放大：循环放大验收标准里的任何判断缺陷——技术上正确但方向上错误的产出可以被大批量生产，而没有人发现问题出在验收标准本身（Goodhart’s Law（古德哈特定律） 的循环版本）
• Cognitive Surrender（认知投降）：循环跑久了，人容易停止思考、停止有自己的判断，直接接受结果。用这个词点明它不只是懒惰，而是一种更深的主动性丧失
• Ralph Wiggum Loop（静默提前退出）：Agent 自认为完成便提前终止，任务只做了一半；外层循环却继续运行并持续消耗 Token，既不报错也不提示。这是最难察觉的循环失效——没有崩溃，只有账单。由 Geoffrey Huntley 记录并命名。三个充分触发条件：① 没有真正的验证器——只有另一个被要求"review"的 Agent，两个乐观主义者互相认可；② 软性完成条件——“完成"由 Agent 自己判断，而非测试、构建或类型检查；③ 没有硬停止——循环持续运行直到速率限制或人类发现账单，而非到成功被客观验证。修复只有一种：引入能客观失败的质量门——测试通过或不通过、构建编译或不编译、linter 返回零或非零，不是有意见的 Verifier，而是有结果的机器

常见反模式

这些反模式看似不同，本质上都对应四组件之一缺失或含糊：触发器、过程、验证、停止条件没有被写成可检查的系统规则。

必须设置的边界

一个健康的循环不能无限运行。部署前必须定义以下约束：

边界不是限制循环的能力，而是让循环长期可信的前提。

权限分级部署（L0–L4）

Loop 的权限应从保守起步，验证稳定后再逐步扩展：

绝大多数团队先做到 L1/L2 就已经有价值。L4 应放到问题类型固定、测试能兜住、回滚顺手之后。只要牵涉业务判断、权限或数据写入，不要急着提权。

安全税（Security Tax）

无人值守的循环也是无人值守的攻击面。四个具体风险：

1. 未经审查的代码自动入库：循环开 PR 的速度远超人工审阅。如果验收门不含安全检查（SAST、依赖审计、Secret 扫描），不安全的代码会自动合并。确保安全检查在门之内，而不只是事后的 lint。

2. Skill 作为注入向量：自动安装 Skill 会继承 Skill 描述里隐藏的所有 Prompt 注入。一项对 17,022 个社区 Skill 的审计发现其中 520 个会泄露凭据。安装前必须阅读来源，不要自动信任社区 Skill。

3. 日志里的凭据：长时间运行的循环在调试日志里散落密钥，而这些日志通常没有人监控。生产循环关闭 verbose logging，对必要日志做脱敏处理。

4. 权限范围蔓延（Permission Scope Creep）：为方便加了一个写权限，再没复查。建议：每 30 天重新审计循环的权限范围，把"本轮任务最小权限"写进部署清单，而不是靠记忆控制。

衡量指标

“每天 N 个 PR"不是价值，可能是制造垃圾的速度变快了。

核心指标：每次接受变更的成本（Cost Per Accepted Change）——不是消耗了多少 Token，也不是跑了几次循环，而是每条被采纳的产出实际花了多少钱。如果循环产出 10 次，其中 6 次被丢弃，人工的 Review 工作并没有被省掉，只是被前置了。接受率低于 50% 时，循环的成本往往高于收益。

一个处于健康状态的 Coding Loop 的示例仪表盘：

拒绝率 17% 远低于 50% 警戒线，说明循环产出质量稳定，人工 Review 成本没有被循环转移为拒绝工作。

其他应追踪的指标：

• 合并率：自动开的 PR 里有多少被合并？
• 回滚率：合并后有多少被回滚？
• 缺陷率：循环产出引入了多少新 bug？
• Review 成本：人工审查每个 PR 花多少时间？有没有在上升？
• 测试通过率：循环提交的代码第一次跑测试能过多少？
• 用户价值：自动修复的东西对用户是否有实际意义？
• 团队认知健康：团队成员还理解循环生成的代码吗？（见Comprehension Debt（理解债））
• 实际减负：自动化之后，工程师的重复劳动有没有实质下降？

最小可行循环

四部分，无集群（Four parts, no swarm）：通过适用条件测试后，先构建最小的可工作循环，而不是立即引入复杂的多 Agent 系统。

flowchart LR
    A1["B1 一个自动化\n(One automation)\n定时运行、节奏、停止条件\n/loop · /goal"]
    A2["B2 一个技能\n(One skill)\nAgent 否则每次从零\n推断的项目上下文 · SKILL.md"]
    A3["B3 一个状态文件\n(One state file)\n记录已完成什么\n以及下一步是什么\nMarkdown / Linear"]
    A4["B4 一道质量门\n(One gate)\n测试、类型检查或\n构建拒绝坏输出\nCAN SAY NO"]

    A1 --> A2 --> A3 --> A4
    A4 -->|"NEXT RUN"| A1

• B1 一个自动化 (One automation)：按节奏定时运行、有明确停止条件。用 Claude Code 的 /loop 或 Codex 的 Automations；配合 /goal 运行到指定条件满足为止。
• B2 一个技能 (One skill)：一个 SKILL.md 文件，存储 Agent 否则每次从零推断的项目上下文。没有技能，每次运行都像第一次运行；有了技能，Agent 接着知道的继续干。
• B3 一个状态文件 (One state file)：一个 Markdown 文件或 Linear 看板，记录已完成的和下一步的。明天的运行续接而不是重启。
• B4 一道质量门 (One gate)：测试、类型检查或构建——自动拒绝坏输出。这是决定循环到底在帮忙还是只是在花钱的那个部分。

顺序很重要：先让一次手动运行可靠，再变成技能，再包成循环，再定时调度。 跳过这个顺序是循环在生产环境失败的最常见原因。

30 秒检查清单

把一个任务变成循环之前，过一遍这 5 条——缺一条就保持手动提示：

这是战术检查（针对单个任务），区别于前面"适用条件"的策略判断（针对是否值得建循环这个决策）。

不要一上来就搭"全自动软件工厂”。选一个重复任务开始——每日 CI 失败扫描、Issue 自动分类、简单 lint/test failure 修复——然后回答这 7 个问题：

1. 输入来源：从哪里拿信息？CI、GitHub、Jira、日志、文件？
2. 分类规则：哪些可以自动处理？哪些必须交给人？
3. 执行 Agent：谁负责修改？权限边界在哪里？
4. 验证方式：跑什么命令证明没搞坏？
5. 失败策略：失败几次后停止？如何记录失败原因？
6. 输出结果：开 PR？发消息？写 Markdown？更新 Issue？
7. 人类审查点：哪些结果必须你亲自确认？

回答完这 7 个问题，就有了一个可以落地的循环。

好的第一个循环 / 坏的第一个循环

判断原则：封闭性任务 + 机器可验证的完成标准 + 失败代价低 = 适合。缺其中一条就需要人在场。

适合自动化（典型好起点）：

• CI 失败分诊 — 每晚扫描失败、分类原因（环境/不稳定/真实 Bug），对易修项起草 PR，复杂项升级给人
• 依赖版本更新 — 每周扫描新版本、测试兼容性、开 PR
• Lint/风格自动修复 — 每次 PR 开启时应用样式修复，有明确机器可验证标准
• 不稳定测试复现 — 循环直到某个修复理论通过测试才停
• 测试覆盖率补全 — 扫描未覆盖函数、生成测试草稿、提交 PR 供人审查

不适合自动化（这些需要人在椅子上）：

• 架构改写——没有机器可裁决的"对不对"标准
• 认证/支付代码——风险不对称，一个错误代价极高
• 生产环境部署——不可逆操作
• 模糊的产品决策——“完成"本身是主观判断
• 任何"做完了"无法用测试、构建或 lint 验证的工作

共同点：让循环做准备，让人做决定。循环的自主范围应被框在一个人可以快速审查的产出物（通常是 PR）上。

编程循环（Coding Loop）

Coding Loop 是循环工程在软件开发场景下最直观的具体形态。之所以用编程举例，是因为代码对不对通常可以机器验证——测试通过/失败、lint 报错与否、页面能不能打开，都是明确的反馈信号。

一次最简单的 Coding Loop 由四步构成：

1. 观察（Observe）：读取报错信息，定位相关代码，理解当前目标（如"修复登录按钮点击后 500 报错”）
2. 修改（Modify）：做一次尽量小、尽量可控的改动——改动越大，越难判断问题是被修好还是被新改动掩盖
3. 验证（Verify）：运行测试、启动页面、检查接口，看原来的失败信号是否消失
4. 反馈（Feedback）：验证失败则把错误信息带入下一轮；验证通过则停止循环，交给人 review

flowchart LR
    S["① Start"]
    R["② Agent reads\nprompt + repo state"]
    W["③ Agent writes\ncode / makes changes"]
    E["④ External check"]
    P{"Pass?"}
    X["Exit Loop"]

    S --> R --> W --> E --> P
    P -->|"Yes ✓"| X
    P -->|"No ✗"| S

注意步骤④是 External check（外部检查）——判定权不在 Agent 手里，而在测试、构建、linter 这类客观机器上。缺少这一步，循环就退化为 Ralph Wiggum Loop（静默提前退出）：Agent 自己宣布完成，循环静默退出，账单继续跑。

这个模式把工程师手动"复制报错 → 粘给 AI → 运行 → 继续复制"的流程，变成系统驱动的自动闭环。重点不是 AI 一次性写出完美代码，而是 AI 能根据反馈持续改进。

这种依赖循环试错的编程风格有一个专门的名字：Vibe Coding（氛围编程）。它非常消耗 Token——每轮循环都会累积历史上下文，修一个 Bug 循环十次，Token 消耗以指数级增长。这完美契合了 AI 公司按 Token 计费的商业逻辑。

产品开发的三层反馈循环

Andrew Ng 把 0-to-1 产品开发拆成三个相连、速度不同的反馈循环。这个模型补充了循环工程容易忽略的一点：Coding Agent 的自动迭代只覆盖最内层；做什么产品、怎样修改产品愿景，仍由更慢的人类与市场反馈驱动。

flowchart LR
    CA["Coding Agent\n编码智能体"]
    SPEC["Product spec / evals\n产品规格 / 评估集"]
    VISION["Developer vision\n开发者愿景"]
    EXT["External feedback\n外部反馈"]

    CA <-->|"Agentic coding loop\n约几分钟"| SPEC
    SPEC <-->|"Developer feedback loop\n约几十分钟到数小时"| VISION
    VISION <-->|"External feedback loop\n约数小时到数天或数周"| EXT

1. Agentic coding loop：规格与实现

开发者给出产品规格，并可选地提供一组 Evals（评估）；Coding Agent 编写代码、运行测试、检查页面并继续修改，直到实现满足规格。这个循环每几分钟就能完成一轮，适合把明确要求快速翻译为可运行软件。

更强的自测能力减少了开发者充当手工 QA 的时间，但没有消除验证问题：测试、浏览器检查和 eval dataset 仍要提供可观察的失败信号。Agent 能自主工作更久，依赖的是闭环质量，而不是一次生成就正确。

2. Developer feedback loop：愿景与规格

开发者按几十分钟到数小时的节奏审视当前产品，再调整功能、视觉设计、用户流程和优先级，并把更新后的判断翻译成新规格。看到实现后改变主意不是规格失败，而是产品探索的一部分：实现让原本抽象的愿景变得可检验。

如果系统反复遇到同一类问题，就应把这些人工反馈沉淀为 Evals。这样，开发者不必在每轮重复指出同一个缺陷，内层 Coding Loop 也能自动防止回归。

3. External feedback loop：市场与愿景

朋友试用、Alpha 测试、生产发布、使用数据和 A/B 测试都属于外部反馈。它们通常要数小时、数天甚至数周才能返回，但会改变开发者对用户问题和产品方向的理解，再向内传导为愿景、规格和代码变更。

三个循环的关键不是同时跑得一样快，而是让信息逐层传导：

• 外部反馈修正开发者愿景
• 开发者愿景修正产品规格与 Evals
• 产品规格与 Evals 驱动 Coding Agent
• 实现结果又反过来暴露规格与愿景中的缺口

人类为何仍在循环中

Ng 把人类的作用解释为上下文优势（context advantage），而不只是难以定义的“品味”：开发者掌握 Agent 不知道的用户背景、业务约束、历史决策和现实环境。只要这部分信息没有进入系统，人就必须留在外层循环中注入知识并做取舍。

因此，工程师角色扩大到部分产品管理工作，并不等于把产品判断交给 Coding Agent。更合理的分工是：Agent 加速“规格 → 实现”，人类负责“外部证据 → 愿景 → 规格”；AI 可以辅助汇总用户反馈、分析使用数据和竞品，但最终方向仍取决于谁掌握更完整的上下文。

在任意 LLM 内手动运行一个循环

不需要 Agent 工具或编程环境，也可以把循环的核心结构直接写进 Prompt，让任意 LLM 在单次对话里自动迭代。关键是一次性给出三样东西：目标、严格的成功标准、强制自检再退出的协议。

You will work in a loop until the task meets the bar.

TASK:
[描述你想要产出的内容]

SUCCESS CRITERIA（要严格，不能模糊通过）:
- [标准 1]
- [标准 2]
- [标准 3]

LOOP PROTOCOL, repeat every turn:
1. PLAN   - state the single next step.
2. DO     - produce or improve the work.
3. VERIFY - score the result 1-10 on each criterion.
            Be brutally honest. List exactly what is still weak.
4. DECIDE - if every criterion is 8+, print "FINAL" and stop.
            Otherwise print "ITERATING" and go again, fixing
            the weakest point first.

RULES:
- Never call it done until every criterion is 8 or higher.
- Each pass must fix the weakest score from the last VERIFY.
- Do not ask me questions. Make a sensible assumption, note it,
  and keep going.

Begin. Run the loop until FINAL.

这个模板让模型起草、给自己打分、找到最弱项、再改，循环往复直到真正达到标准——而不是给出第一个"看起来差不多"的回答就停下来。Verify 是关键：没有自评分步骤，模型只是在重复，不是在推进。

注意它的局限：你仍然是触发器——需要你打开 chat、粘贴 Prompt、坐在那里看它跑。关闭 tab 循环就消失了。没有定时触发，没有"每天早上自动执行”。这是手动版本。

超越编程：循环的普适性

Coding Loop 之所以有效，根本原因是编程属于 Closed vs Open Tasks（封闭性任务与开放性任务）——代码对不对有明确的机器验证标准，失败信号清晰。Loop 的边界也在这里：在无法机器验证的开放性任务（写报告、做决策）中，循环可以加快输出速度，但无法保证输出质量，人类判断依然不可替代。

Coding Loop 只是因为反馈信号最明确而最容易理解，但循环模式本质上适用于所有"多轮反复靠近"的工作：

共同结构：不是追求一次完美输出，而是在有边界、有验证的闭环里持续逼近目标。

科研自动化中的 Autoresearch（自动研究）是这个结构的典型例子：Agent 反复提出实验改动，系统运行短程实验，用 val_bpb、验证损失或其他指标裁决改动好坏，变好则保留，变差则回滚。它看起来像"AI 自主研究”，工程内核仍然是可测量目标驱动的循环。

工具实现对比

Codex 与 Claude Code 对 5 个构建块与状态的实现方式：

两套工具叫法不同，但形状相同：自动化负责发车，工作树负责隔离，Skill 负责项目知识，连接器负责伸手到外部系统，子智能体负责角色分离，状态文件负责跨轮续接。一旦理解了循环工程的结构，就不再纠结选哪个工具。

Claude Code 的四类 Loop

Claude Code 团队把 loop 定义为：Agent 重复执行工作循环，直到满足停止条件。这个定义的关键不是“多提示几次”，而是把每类循环拆成四个设计问题：谁触发、谁判停、使用哪个产品原语、适合什么任务。

这套分类补充了循环工程的最小四组件模型：Turn-based 仍然把“下一轮是否继续”交给人；Goal-based 把停止条件交给目标检查机制；Time-based 把触发器交给时钟；Proactive 则把 prompt、触发器、验证和多 Agent 编排组合成长期运行系统。

/loop vs /goal：两种调度机制

两个命令解决不同的问题：/goal 管“什么时候算完成”，/loop 管“下一次什么时候醒”。Codex 和 Claude Code 都支持 /goal 这类 Goal-based Loop 原语：用户给出可验证完成条件，Agent 持续推进，直到目标满足、达到限制或需要报告阻塞。

两者的产品语义不必强行写成同一种实现。在 Codex 里，Goals 是线程级完成契约：目标、生命周期、预算和进度账本属于当前线程；Codex 需要把完成判断对齐到测试、benchmark、文件、日志、报告或研究证据。Claude Code 的 /goal 也服务于同一类目标循环，但在这页更应把它当作跨工具的“完成条件”原语，而不是 Codex 独有功能。/loop 则更像节奏触发器：按时间或事件把任务重新唤醒。

flowchart TB
    G["/goal: get the homepage Lighthouse score to 90 or above, stop after 5 tries"]
    C["Agent works on the task"]
    E["Evidence checks condition"]
    D{"Condition met?"}
    L["Loop ends: goal met or turn limit reached"]

    G --> C
    C -->|"tries to stop"| E
    E --> D
    D -->|"condition not met"| C
    D -->|"condition met or limit reached"| L

没有 /goal，你就是循环——每轮都需要你的输入才能继续，你是瓶颈。有了 /goal，完成条件从聊天里的愿望变成当前线程的显式状态，Agent 可以在每轮工具调用后检查证据，选择继续、完成、暂停或报告阻塞。

/loop 管"下一次什么时候醒”。按时间间隔重复运行 prompt，适合部署轮询、PR babysit、长构建检查等"隔一段时间再看一次"的任务。可以给固定间隔（如 /loop 5m "检查部署是否完成"），也可以不给间隔，让 Claude 根据观察结果自行判断等待时长。

/loop 是 session-scoped 的临时调度——任务只在当前会话运行且空闲时触发，关闭终端即中断，最多 7 天自动过期。这只是三层 Claude Code 调度中的第一层：

/goal 管"什么时候算做完”。给它一个可验证的完成条件，Agent 一轮一轮推进；关键是完成权必须绑定到外部证据，而不是绑定到模型的自我感觉：

/loop 30m /goal "All tests in test/auth pass and lint is clean.
  Scan src/auth for new failures, propose fixes in claude/auth-fixes,
  open draft PR when goal condition holds."

这个组合：/loop 负责节奏（每 30 分钟醒一次），/goal 负责出口（条件真正满足才停），测试、lint、构建、benchmark 或审计产物负责提供裁决证据。

两者与 Stop hook / Agent SDK 控制循环的关系：/loop 和 /goal 是 UI 级命令，Stop hook 和 Agent SDK 是工程级控制——后者允许用脚本、外部 evaluator 或确定性检查来决定是否继续，适合权限拦截、状态落盘等不能只靠模型口头判断的自动化场景。

Proactive Loop：云端无人值守循环

当 /schedule、/goal、subagent review、auto mode 与外部连接器组合起来，循环就从“当前会话里的自动继续”升级为“云端 routine”：笔记本是否打开不再重要，系统按计划或事件发现任务，主 Agent 执行到验证通过，第二 Agent 审查并通知人，最后由人决定是否合并。

flowchart LR
    You["You\n决定是否合并"] <-.-> Review["Second agent\nreview 并通知你"]

    subgraph Cloud["Runs in the cloud — laptop open or not"]
        Trigger["Trigger\n/schedule\n监听 Slack 或 GitHub bug 报告"]
        Main["Goal + check\n主 Agent 循环执行\n直到验证通过"]
        PR["Opens a PR"]
        Review

        Trigger --> Main
        Main --> PR
        PR --> Review
        Review --> Trigger
        Main -.->|"runs until you turn it off"| Review
    end

这个形态适合输入持续到来的工作流，例如 bug 报告、issue triage、依赖升级和批量迁移。设计重点从“写一个好 prompt”转为“让 routine 的边界足够窄、验证足够硬、review 足够独立、运行频率匹配外部系统变化速度”。

通用触发与治理模式

开放循环与封闭循环

按工作流预定程度，循环可分为两类拓扑：

开放循环（Open Loop） 设定目标与护栏，允许 Agent 自主选择解题路径。适合探索阶段——问题边界不清楚时，开放循环能快速覆盖大量解法。代价是：标准不精确时产出噪声大，每轮开销不可预测。

封闭循环（Closed Loop） 预先规划完整工作流，为每个专职 Agent 分配固定职责，并建立稳定的验收标准。优点是成本可预期，验收标准稳定后每轮都在对同一尺子打分，质量随迭代递增。代价是设计成本高，且验收标准本身的质量决定上限——验收标准有缺陷时循环会高效地放大这个缺陷（参见古德哈特定律陷阱一节）。

实践中两者互补：探索期用开放循环快速发现解法，稳定期切换为封闭循环提升一致性与可预期性。

部署顺序

顺序比工具更重要。把未经验证的东西直接放上定时任务，是循环在无人值守时崩掉的最常见原因：

1. 先让一次手动运行可靠：在你亲眼看着的情况下跑通，弄清它在什么条件下会失败
2. 把指令沉淀为 Skill（技能）：把这次成功所依赖的所有上下文、规则、路径打包成文件
3. 加验收门和停止条件：加入外部验证（测试/构建/规则），同时规定"失败几次后停止"
4. 然后才放上定时任务：cron、GitHub Actions，或 Codex Automations

跳过第一步直接上线的循环，通常在某次你不在场的运行里以你看不到的方式失败，并在你发现之前已消耗了大量 Token。

实践原则

1. 先设计小循环，从每日 Issue 分类、CI 失败摘要开始，不要一上来就做"全自动软件工厂"
2. 每个循环都要有验收标准，明确说清楚什么叫"完成"（测试通过、lint 通过、不修改 public API……）
3. 生产和审查分离：Agent A 实现，Agent B 检查，人最终确认
4. 把知识沉淀成 Skill：凡是反复告诉 Agent 的事情，都应该写成 Skill
5. 把状态沉淀到 Agent Memory（Agent 记忆）/文件/看板：不依赖聊天记录，每次循环结束都留下记录

编排模式分类

ETCLOVG Taxonomy（ETCLOVG 分类法）的 L 层（生命周期与编排）为循环工程的子智能体模块提供了正式词汇：

全生命周期 Pipeline（“从 issue 到 PR”）是循环工程的最高层级：Symphony（OpenAI）、GitHub Agentic Workflows 等系统将单 agent 内循环、多 agent 编排和任务运行器整合为端到端工作流，人类在其中扮演引导者而非执行者。

Dynamic Workflows（动态工作流）属于这一层的一个新兴产品形态：系统不是预先写死完整流程，也不是让主 Agent 在上下文里临时边想边派活，而是先根据目标生成可复跑的编排脚本，再由 Runtime 调度多个 subagent 执行、记录状态并验证结果。它把“循环工程”的目标定义、状态管理和验证收敛进一步产品化为可运行的 workflow script。

Token Capital（Token 资本）与复利循环

Satya Nadella 的框架把企业资本分为两类：人力资本（Human Capital）——团队多年积累的知识和判断力；Token 资本（Token Capital）——企业在基础模型之上构建的 AI 工作流、决策模式和已学习技能。

两者形成复利：每个改进的工作流产生更好的信号，更好的信号产生更精准的 AI 行为，更精准的行为释放人力专注于更高判断价值的工作。这是一台爬山机（hill climbing machine）。

Nadella 的关键点：“一家公司应该能够换掉底层的通用模型，而不丢失他们构建进学习系统里的’公司老兵’专业知识。“这正是持久技能库（durable skill library）的设计意图——持久函数不关心调用它的是哪个 LLM，技能的价值不绑定在特定模型上。

对循环工程的含义：每个部署的持久技能都是编码为可执行基础设施的组织知识。 如果技能在进程重启后消失，复利归零。Durable Execution（持久执行）是让投资持续存在的机制，而不只是让循环不崩溃的机制。

四次跃迁：工程范式演进脉络

四次跃迁不是替代关系——后一层包含前一层。Loop 里的每次 Agent 调用仍然需要好的 Prompt，仍然需要充足的 Context，仍然需要 Harness 的约束；只是杠杆点向上移动了一层。

本质

循环工程的本质是放大工程师的判断力，而不是用 Agent 替代工程师。这件事比看上去更难：

设计循环比提示工程更难，不是更容易。杠杆点移动了。

循环替你跑流程，不替你承担工程责任。关键分界：

如果你设计循环是为了加速理解，它是工具；如果你设计循环是为了逃避理解，它是灾难加速器。

循环不知道区别在哪里。你知道。

结论：像一个打算继续做工程师、而不只是按下按钮的人那样构建循环。

Build the loop. But build it like someone who intends to stay the engineer, not just the person who presses go. 让循环替你跑重复劳动，但别把工程判断也交出去——你要做的是工程师，不只是按下启动键的那个人。

循环工程与Prompt Engineering（提示工程）的关系：提示工程解决"怎么问 AI”，循环工程解决"怎么让 AI 持续做事、检查、修正、停止”。两者不是替代关系——Prompt 仍然重要，但在循环里它是零件，不再是全部工作。

可以把它压缩成一个工程公式：

Loop = Harness + Cadence + Gate + Feedback + Memory

Harness Engineering（驾驭工程）给 Agent 执行环境和约束；Cadence 决定什么时候醒来；Gate 决定什么能过、什么要回滚或升级；Feedback 把验证结果变成下一轮输入；Agent Memory（Agent 记忆）让循环跨会话接着跑。缺任一项，循环都会退化为一次性脚本、无限重试或靠人手动推动的半自动流程。

OpenAI Cookbook 的 Codex iterative repair loops 示例，是这个公式在维护任务中的一个小型实例：Codex 先 Review 产物，再 Repair 副本，最后 Validate 并把 remaining delta 写回下一轮。它展示了循环工程里最关键的控制关系：验证不是报告，而是决定“停止、继续、回滚或交给人”的闸门。

• Closed vs Open Tasks（封闭性任务与开放性任务） — Loop 的适用边界：只有封闭性任务才能支撑自动验证循环
• Agent Loop（智能体循环） — 单个 Agent 内部的推理-工具调用循环；含四代循环演进脉络
• Codex — Goals 把完成条件持久化到线程，是目标驱动循环的产品化入口
• ReAct — 第二代循环的基础执行模式，Thought-Action-Observation 三元组
• Reflexion（反思） — 在 ReAct 外加自评估层，通过情节记忆跨轮自我校正
• Plan-and-Execute（规划与执行） — 先规划后并行执行子步骤，适合步骤相对独立的任务
• Dynamic Workflows（动态工作流） — 按目标动态生成脚本并由 Runtime 调度多 Agent 执行的产品化编排形态
• Evals（评估） — 循环外部判断每轮是否变好的尺子
• Autoresearch（自动研究） — 循环工程在科研实验优化中的特化形态
• Vibe Coding（氛围编程） — Coding Loop 的一种实践风格，Token 密集型
• Hallucination（幻觉） — Loop 要解决的根本问题：LLM 的概率本质导致多步错误累积
• Skill（技能） — Loop 五模块之一，沉淀隐性知识防止意图债
• Agent Memory（Agent 记忆） — Loop 跨会话续接的状态层
• Agent Worktree（Agent 工作树） — 多 Agent 并行的文件系统隔离方式