前言

大家好，这里是程序员阿亮！上一篇我们讲解到了harness工程，那么这一篇我们再来讲解一翻关于Loop工程的内容！

在过去的 AI 开发中，工程师们习惯于守在对话框前，一轮一轮地手动输入提示词，看着大模型吐出代码后复制粘贴、手动编译、发现报错、再复制报错投喂给模型。这种“人肉外循环”的工作流，在业内被称为 “Vibe Coding（氛围感编程）”。

然而，随着 Claude Code、Codex 以及各种自律智能体的相继问世，AI 编程工程化发生了一次深刻的范式转移：瓶颈不再是“下一句提示词该怎么写”，而是“如何设计让系统自律运行的闭环”。

谷歌云资深软件工程师 Addy Osmani 正式提出并体系化了 “Loop Engineering（循环工程）” 这一方法论。Anthropic 的 Claude Code 责任人 Boris Cherny 也曾公开表示：“我不再直接给 Claude 写提示词了。我写了一套循环系统去提示 Claude，并由这套系统判断下一步该做什么。我的工作现在是写这些‘循环（Loops）’。”

本文将为你深度拆解 Loop Engineering 的前世今生、核心架构，以及在实际软件工程中如何落地一个具备自愈能力的自律循环系统。

一、 循环工程是“新瓶装旧酒”吗？

初看“Loop Engineering”这个词，不少开发者可能会觉得这又是业界在制造新名词。诚然，它的底层技术借用了许多已经成熟的工程概念：

• Agent Loop / ReAct：AI 智能体“观察（Observe）-> 思考（Reason）-> 行动（Act）”的内层循环早就存在。

• Workflow / Graph：由有向无环图（DAG）或状态机控制的可控回边，在传统工作流引擎里早已是标配。

• Harness & Context Engineering：控制模型运行的外壳约束、拦截器和上下文管理。

既然技术是旧的，为什么“循环工程”会突然火起来？

因为 控制重心发生了改变。

在 2023 年至 2024 年，AI 辅助开发是单次请求驱动的。而在 2026 年的今天，任务是长期异步自律运行的。AI 可以在你睡觉的时候，连续读取几十个文件、修改代码、在沙箱中运行测试、审查并纠错、最终自动合并 PR。

在长达数小时、涉及数百次 LLM 调用的自律任务中，人工介入的成本过高。因此，我们需要将原本由人类扮演的“监控者、编译器、测试员和重试机制”彻底代码化、自动化。循环工程，就是专门研究如何设计、运行、监控并安全退出这些自主运行的“闭环控制系统”的工程学科。

二、 从自动补全到自愈循环：AI 编程的进化史

理解循环工程，可以先看 AI 辅助编程经历的四个进化阶段：

1. 第一阶段：自动补全（2023年）

   • 形态：行内代码补全（Copilot）。

   • 控制权：100% 在人类手中，AI 只负责猜测下一个单词。

2. 第二阶段：单次生成（2024年）

   • 形态：Chat 面板，Prompt 到代码的单轮输出。

   • 控制权：人类手动输入 Prompt，手动将代码搬运到 IDE，手动编译排错。

3. 第三阶段：多智能体并发（2025年）

   • 形态：由人工在看板或 CLI 中协调多个 Agent，各司其职，但依然需要人工确认转接。

4. 第四阶段：自主循环工程（2026年）

   • 形态：以 /loop 或 /goal 命令为代表。系统接收到一个高维度的目标（如：修复 issue #404），自主决定循环的起点，自己编译、自己查错、自我修正，直到达成目标。

三、 循环工程的六大核心要素

一个合格的“循环”绝对不是简单的 while(true)。如果缺乏严密的工程设计，非确定性的生成式 AI 很容易陷入无限死循环，或者在两轮迭代内就因为上下文污染而彻底瘫痪。

一个生产级的 Loop 必须由以下六个要素精密构成：

1. 触发（Trigger）

谁来唤醒 Agent？在循环工程中，触发器往往是异步且自动化的。它可以是一个 Git Push 行为、CI 构建失败事件、PR 上的某条 Review 评论、甚至是定时巡检任务。

2. 目标与终止态（Goal / Done Condition）

循环系统需要明确知道什么状态代表“做完了”。
例如，在 Claude Code 中：

• /loop 代表不断迭代执行某项开发，可能需要人类不断微调目标；

• /goal 则代表一个确定性的硬终点（如：所有测试必须通过，且代码覆盖率提升至 80%），达到该硬终点，循环必须立刻自动退出。

3. 上下文卫生（Context Hygiene）

这是长周期循环生存的核心。每一次循环（Iteration）都会产生新的代码差异、编译日志和执行输出。如果把这些历史日志原封不动地全部堆叠在上下文窗口中，模型在第 3 轮之后就会被垃圾信息淹没，注意力严重飘移。

• 解法：循环引擎在进入下一轮循环前，必须对历史状态进行**“去噪、压缩、结构化”**，只保留当前最核心的快照和最后一次失败的致命报错。

4. 行动（Action & Sandbox Tools）

AI 能够调用的外部工具箱（Skills / MCP）。循环工程要求工具执行必须是安全的、幂等的，且能够返回便于程序解析的结构化结果。

5. 观察与验证器（Observation & Verifier）

验证器是循环工程中最大的瓶颈。 AI 在循环里修改了代码，它怎么知道自己做对了？
绝对不能询问模型“你写对了吗”，而是必须通过外部编译器、Linter 静态检查、自动化单元测试或视觉回归测试等硬性验证器。验证器返回的非零退出码（Exit Code）就是驱使循环继续转动、自愈的动力源。

6. 停止与熔断规则（Stop Rules & Budget Control）

为了防止系统因遇到无法解决的逻辑死锁而无限循环、烧光 Token 预算，必须在 Loop 外围设置硬熔断。

• 硬限额：单次 Loop 最大尝试次数（如最大重试 5 次）、Token 消耗上限（如单次任务最大花费 2 美元）。

• 人工挂起（Human-in-the-loop）：当遇到不确定的权限变更，或重试 3 次依然卡在同个报错时，Loop 必须能够将当前状态打包序列化，优雅地挂起并通知人类介入。

四、 优秀的循环具备三大基本属性

在评估一个循环系统是否能安全推向生产时，必须检查它是否满足控制论中的三大原则：

• 可终止性（Terminability）：它必须能在确定的步数内退出，不会因为生成结果微弱的扰动而陷入逻辑震荡。

• 可观测性（Observability）：每一轮循环的输入、输出、耗时、模型决策路径都要能被 Trace（追踪）并持久化，方便在发生故障时进行回放排查。

• 可恢复性（Recoverability）：当工具调用超时、网络波动或模型生成了格式破碎的补丁时，系统能够自动捕获这些异常，回滚文件系统到上一轮健康的 Commit 状态，而不是直接进程奔溃。

总结

AI 开发的下半场，程序员的日常工作形态正在发生剧烈的质变：

以前，我们的产出是具体的业务代码。
后来，我们的产出是精致的提示词（Prompt）。
而现在，我们的产出是循环本身（The Loop）。

在自律智能体大行其道的当下，我们不再手把手教 AI “该怎么写每一行 Java 代码”，而是去思考：如何定义一个无懈可击的验证器、如何保障上下文不产生混乱熵增、如何优雅地把卡住的任务交接回人类手中。

设计一个自律运行、自我纠偏、安全终止的控制系统，这正是软件工程师们数十年来最擅长的领域。循环工程，让 AI 应用的开发，重新回归到了严谨、确定的软件工程学轨道上。