AI-Wiki

文档概览

这篇文章试图回答的问题不是“怎么把一句 prompt 写得更好”，而是“怎样把 AI 组织成一个能持续自主工作的系统”。其一句话定义非常明确：

Loop Engineering 就是设计一个“自动给 AI 下指令、判断下一步、决定何时停”的循环系统，而不是人类逐句去提示 AI。

文章的主线可以概括为四部分：

先说明人的角色正在从“写 prompt”上移为“设计 loop 控制系统”；
再用四层演进心智模型解释 Prompt Engineering、Context Engineering、Harness Engineering、Loop Engineering 的递进关系；
接着给出 Loop 的标准骨架与 8 个 primitives；
最后用一个“让某分支 CI 变绿”的工作流示例，展示 Loop 如何在真实工程里运转，并补充常见失败模式和适用边界。

关键事实

一句话定义

文中对 Loop Engineering 的定义不是抽象口号，而是非常具体的控制论表述：

人不再逐句提示 AI；
系统会自动给 AI 下指令；
系统会判断下一步该做什么；
系统会决定什么时候停止。

这意味着，Loop 的设计对象不是“某一句输入文本”，而是“一个能持续运行、持续检查、持续收敛的控制回路”。

人的角色转变：从写 prompt 到写 loop

文中引用 Boris Cherny 的原话，大意是：他不再直接提示 Claude，而是有一堆 loop 在跑，是这些 loop 在提示 Claude、决定下一步做什么；他的工作是写这些 loop。

这段话对应的核心判断是：

人的工作重心上移；
从“措辞优化”转向“控制系统设计”；
不再把能力寄托在单次模型输出上，而是寄托在整个系统的闭环结构上。

文章据此给出一个很重要的职业画像：未来更关键的不是 prompt writer，而是 Loop Engineer，即能把目标翻译成可执行循环、可验证阶段目标、可中止条件、可升级机制的人。

四层演进心智模型

文章把 AI 交互与 Agent 设计总结为四层演进，并强调“后一层包住前一层”，不是简单替代关系：

Prompt Engineering（2022-2024）：优化一句话怎么写。
Context Engineering（2025）：策划模型推理时能看到的全部信息，例如检索增强、补充资料、上下文组织等。
Harness Engineering（2026）：为 Agent 的一次运行搭建完整环境，包括工具、约束、反馈管道等。
Loop Engineering（2026）：设计驱动自主工作的迭代循环，让系统持续发现任务、反复执行、验证结果并决定停止。

文中给出的记忆口诀是：

措辞 → 上下文 → 环境（harness）→ 循环（loop）

其隐含意思是，杠杆率一层比一层更高：

Prompt 主要优化单次表达；
Context 优化模型可见信息；
Harness 优化一次运行的执行条件；
Loop 优化整个工作流如何反复运行直到完成。

Harness 与 Loop 的区别

这是文中专门强调的一组关键区分：

Harness Engineering 负责的是 一次 Agent 运行 的环境、工具、约束与反馈；
Loop Engineering 负责的是 何时运行、运行几轮、何时结束。

换句话说：

Harness 解决“这一趟怎么跑”；
Loop 解决“什么时候跑、跑多少趟、什么叫跑完”。

文章还给了更动态的描述：Loop 是在 Harness 之上不断“戳”Agent，让它持续发现工作、派发子 Agent、自我喂料，并根据状态判断是否继续。

Prompt Engineering 与 Loop Engineering 的核心差异

文中的核心判断是：两者最大的差异不只是工作对象不同，而是可靠性来源不同。

Prompt Engineering 更像是在赌“模型这次够不够聪明”；
Loop Engineering 则把可靠性变成一种系统设计属性。

也就是说，Loop 不要求模型每次都完美，而是靠验证、反馈、重试、停止、升级等机制，把一个不稳定的生成器，包成一个最终有机会收敛的工程系统。

文章的立场非常鲜明：与其迷信单次生成足够聪明，不如把系统设计成每一步可检查、出错可纠偏、卡住可升级。

Loop 的标准骨架

文章把 Loop 的通用骨架概括为一套接近伪代码的流程，其结构对应 ReAct 风格的“推理 → 决策 → 行动 → 观察 → 验证”闭环。核心步骤如下：

初始化状态 state = init_state(goal)；
在 MAX_STEPS 限制内循环；
模型基于状态进行推理；
模型选择下一步行动；
通过真实工具执行行动；
用结果更新状态；
对状态做上下文压缩；
若验证通过，则成功退出；
若检测到无进展，则升级给人。

将其还原成中文结构，就是：

推理；
决策；
工具执行；
状态更新；
上下文压缩；
验证通过则退出；
无进展则升级。

这也是文中希望读者背下来的 Loop 标准骨架。

8 个 Primitives

文章把搭建 Loop 系统所需的核心组件总结为 8 个 primitives，也就是最小工作清单。

1. 循环控制结构

最基础的是明确的循环框架，例如 for step in range(MAX_STEPS)。文中特别强调，必须配一个 MAX_STEPS 硬上限，不能让 Agent 无限转圈。

这里的重点不是“有循环”就够，而是：

循环轮次必须可数；
系统必须有强制刹车机制；
不能把停止完全寄托在模型自觉上。

2. 验证机制

这是文章明确标注为最重要的 primitive。

文中的观点很强：验证机制本质上就是奖励信号，也是可靠性的主要来源。其优先级顺序是：

第一选择：确定性验证，例如编译器、单元测试等 Agent 骗不过去的机制；
退而求其次：LLM-as-judge；
原则：每一步都验证，防止错误滚雪球式累积。

这部分有几个不可丢的细节：

文章明确反对只在最后验收；
强调每一步都要验证，是为了尽早发现偏离；
LLM 评审不是首选，只是当缺乏确定性标准时的次优方案；
真正可信的是外部、机械式、不可讨价还价的反馈信号。

3. 停止条件

文中要求停止逻辑必须有互相独立的多个出口，至少包括：

验证通过；
达到步数硬上限；
预算耗尽；
触发无进展检测。

其中“无进展检测”的定义也给得比较清楚：连续几步都在犯同样的错，就不能再让它无限重试。

这个设计体现了一个工程原则：停止条件不是单一阈值，而是一组彼此独立、相互补位的保险丝。

4. 上下文管理

文章把上下文管理视为对抗“上下文溢出”和“上下文腐烂”的关键手段。具体做法包括：

不断把旧步骤压缩成摘要；
丢弃过时的工具输出；
控制进入下一轮推理的状态体积与相关性。

这里的重点不只是节省 token，而是防止系统被过期、冗余、无关的信息拖偏。

5. 工具与真实环境反馈

文中明确提出：反馈的可信度，等于工具接触真实环境的程度。

因此文章主张：

让 Agent 直接操作终端；
让 Agent 接触版本控制；
尽量使用真实世界会产生客观结果的工具链，而不是纯文本自述。

换言之，Loop 要靠真实世界反馈闭环，而不是靠模型“感觉自己做完了”。

6. Human-in-the-Loop

文中没有把人视为系统缺陷的补丁，而是把人纳入正式 primitive。主要作用有两类：

对危险操作设置人工门控；
一旦发现 Agent 卡住，就升级交回给人。

这里尤其强调了危险操作的边界，例如删除文件这类可能破坏意图的动作，不能默认放给 Agent 自主完成。

7. 自动化触发与并行

文章认为，Loop 的价值不只在单条任务线，还在于可以让系统“自己发现工作并自己跑起来”。对应做法包括：

用 cron 定时发现工作；
用 git worktree 让多个 Agent 并行运行且互不打架；
目标是实现“你睡觉时 Agent 在跑”。

这说明 Loop 不只是一个 while 循环，更是一种自动调度与并行执行的工程组织方式。

8. 记忆 / 状态持久化

文章举的例子是 Reflexion 模式：把失败教训写成文字保留下来，不必重新训练模型，也能让 Agent 在后续任务里“学到东西”。

这意味着记忆层的价值在于：

把经验外化为状态；
把失败模式变成下次循环的输入；

Loop Engineering 8大组件与实战指南 摘要