Xiaopeng Xu循环工程（Loop Engineering）：炒作还是 AI 智能体架构的下一次演进
“我已经不再直接提示 Claude 了。我编写循环来提示 Claude。我的工作是写循环。”
—— Boris Cherny，Claude Code 创建者，2026
引言：从写提示词到写循环
如果你身处 2026 年中期的 AI 开发者社区，你绝对无法避开一个词：Loop Engineering（循环工程）。
Anthropic 的 Claude Code 创建者 Boris Cherny 公开宣称自己的工作已经从"提示模型"变成了"编写提示模型的循环" [1]。紧接着，OpenClaw 的创建者 Peter Steinberger 更是呼吁大家停止提示编程智能体，转而设计能够提示智能体的循环 [2]。一时间，“提示词工程已死，循环工程才是未来"成为社区中最响亮的口号。
但当炒作退去、工程师们开始在生产环境中真正构建这些系统时，我们发现：循环工程并不是什么全新的魔法，它是软件工程、控制论以及经典 PDCA 循环在自主 AI 时代的一次技术重构。 它真正的新意不在于"迭代"这个理念本身，而在于循环第一次成为了一种可以被刻意设计、版本化和审查的软件制品。
本文将系统梳理循环工程的核心概念，深入分析它与 Harness Engineering 的分工关系、它在控制论中的前世，以及它在软件开发与科学发现两类截然不同场景下的形态差异；同时也会剥离炒作，审视它被掩盖的工程代价与未来的演进方向。
一、什么是循环工程？
1.1 从单次生成到迭代反馈周期
简而言之，循环工程是一门设计学科，专注于构建迭代反馈周期（计划 → 执行 → 观察 → 调整），使 AI 系统能够自主解决复杂的多步问题 [3]。
在过去，我们依赖"单次生成（One-shot generation）"：给 LLM 一个提示，期望它在一次输出中给出完美的答案。而循环工程构建的是动态工作流：智能体采取行动，检查环境反馈（如测试结果、编译器错误或 API 响应），修改其策略，并重复该过程，直到满足明确的停止条件 [3]。
这个转变的关键，不在于"多试几次”，而在于把"再试一次"这件事本身，变成一个有设计、有约束、有终止条件的软件制品。
1.2 循环工程带来了什么能力？
把无状态的 AI 模型转化为可靠的自主任务执行管道，循环工程带来了四项关键能力 [3]：
自我修正与调试：当生成的代码未能通过单元测试时，循环会自动捕获错误堆栈跟踪，将其反馈给智能体，并促使其进行针对性的微调，无需人类干预。
确定性的停止规则：通过强制执行退出标准（例如"当 N 个测试通过时停止"、“在连续 3 次相同的失败后停止"或"达到最大步骤预算”），防止智能体无限运行或范围蔓延。
上下文截断与状态管理：在长周期运行中，管理哪些状态需要保留——例如保留关键变量声明和执行差异，同时丢弃冗长的日志——以防止上下文窗口溢出。
人机协作集成（Human-in-the-Loop）：精确定义智能体应该在何时暂停自动化执行，等待人类的批准或反馈。
1.3 LangChain 的四层循环堆栈
LangChain 提出了一种极具启发性的"循环堆栈"视角，将循环分为四个递进的层次 [4]：
| 层级 | 循环类型 | 核心机制 |
|---|---|---|
| Layer 1：智能体循环 | Agent Loop | 最基础的 ReAct 模式，模型调用工具直到完成当前任务 |
| Layer 2：验证循环 | Verification Loop | 引入评分者（Grader）检查输出，失败则将反馈送回模型修正 |
| Layer 3：事件驱动循环 | Event-driven Loop | 由 Webhook、Cron 任务或 Slack 消息触发的常驻后台智能体 |
| Layer 4：爬山循环 | Hill-climbing Loop | 分析历史运行轨迹，自动重写工具配置、提示词或评分标准 |
其中第四层是最关键的自我改进层，也是"循环工程"区别于普通重试逻辑的分水岭：
外部循环使得内部循环变得更有效率。
二、与 Harness Engineering 的关系：工具与轨迹
要真正理解循环工程，必须理清它与另一个热门概念——Harness Engineering（驾驭工程）——的关系。
2.1 底盘与巡航控制
Harness Engineering 指的是围绕模型构建的基础设施：工具、沙盒、内存、权限和可观测性 [5]。如果用汽车来打比方：Harness 工程是建造汽车的底盘、引擎和传感器，而循环工程是设计自适应的巡航控制系统——根据传感器读数持续调整速度和方向 [3]。
两者的关注点差异，可以在五个维度上清晰地区分开：
| 比较维度 | Harness Engineering | Loop Engineering |
|---|---|---|
| 核心问题 | 智能体应该如何运行？ | 工作应该如何随时间推进？ |
| 关注点 | 智能体的运行环境和系统 | 重复的工作流和生命周期 |
| 执行层面 | 沙盒、文件系统、权限 | 触发器、重试、重复策略 |
| 失败处理 | 错误处理、恢复原语 | 重试、改变策略、升级、中止 |
| 终止条件 | 通常是最大轮数/时间限制 | 明确的目标/停止条件是核心 |
2.2 为什么有了 Harness，还需要循环？
假设你已经有了一个完美的 Harness（浏览器、Bash、Python、文件系统、MCP 工具等），你的智能体能力极强。但如果你只是告诉它"把这个项目改进到完美"，你很可能得到：
修改 → 修改 → 修改 → 修改 → ... （无限循环，无法收敛）
失败 → 重试完全相同的策略 → 失败 → 重试 → ... （有迭代，但无进展）问题不在于工具不够，而在于没有人定义什么叫"进展" [5]。这正是循环工程要回答的四个问题：什么是进展？谁来验证进展？失败后该怎么办？何时应该停止？
Harness 提供工具，循环提供轨迹。 简而言之：Harness 工程优化的是一个智能体，而循环工程优化的是一个包含智能体的过程 [5]。
三、控制论前世：PDCA 循环的一次重构
如果你觉得循环工程听起来很耳熟，你的直觉是完全正确的。循环工程在本质上并不是一种全新的优化逻辑，它是将经典的 PDCA（Plan-Do-Check-Act）循环——或者说科学方法——实现为围绕 AI 智能体的可执行控制系统 [5]。
下表展示了这一映射关系 [3]：
| PDCA 阶段 | 管理/制造语境 | AI 循环工程语境 |
|---|---|---|
| Plan（计划） | 定义业务目标、KPI 和标准操作程序（SOP） | 任务分解、提示词拆解、工具选择、设定停止标准 |
| Do（执行） | 执行生产线、流程步骤或业务计划 | 生成代码、调用 API、提交 HPC 作业脚本、采样分子主链 |
| Check（检查） | 审计输出、检查缺陷率、监控客户指标 | 检查堆栈跟踪、运行单元测试、检查 pLDDT/PAE 分数 |
| Act（处理） | 标准化成功经验，或做根本原因分析以修复故障 | 上下文内纠错、局部重新设计、调整搜索参数、触发人类审查 |
真正的新意在哪里？ 并非迭代的理念本身，而是循环本身成为了一种你可以刻意设计的软件制品 [5]。
在传统 PDCA 中，人类执行每一个阶段：经理计划、团队执行、质检员检查、总监调整。而在循环工程中，这些人类决策者被可执行的控制逻辑、AI 智能体和评估器部分取代。
一言以蔽之：人类的角色，从"循环的执行者"转变为"循环的设计者"。
四、剥离炒作：三个隐藏的工程代价
当开发者们在真实项目中应用循环工程时，一些被炒作掩盖的工程代价开始浮现。
4.1 Token 消耗呈指数级增长
当你手动编写提示词时，很容易估算使用量：一次提示，一次响应。但循环工程完全改变了这一点。一个单一的目标会迅速演变成多个规划步骤、几个并行工作的子智能体、重复的评估周期和自动测试。每一次重试和评估都会引入自己的 Token 消耗，导致使用量比大多数开发者预期的增长得快得多 [6]。
自动化是有成本的。Token 预算必须作为核心的工程约束来设计，而不是月底才发现的账单。
4.2 无声积累的"理解债务"（Comprehension Debt）
这是最令人惊讶的代价。当自动工作流成功合并了一个功能后，测试全绿，一切完美。但工程师打开代码库时会发现：自己不仅没有写这些代码，而且完全不了解多个并行子智能体做出特定实现决策背后的推理过程 [6]。
系统优化了软件的生产速度，但并没有优化工程师对该软件的理解。
如果这种"理解债务"不断积累，当生产环境出现需要人类介入的复杂故障时，团队将面临巨大的灾难——没有任何人知道这段代码为什么长成这样。
4.3 “让测试通过"并不是一个完整的规范
开发者 Isaac Hagoel 敏锐地指出，在实际的产品开发中，构建过程和发现过程是同步发生的 [7]。当一个端到端测试失败时，循环系统无法判断是新功能实现错了，还是旧的测试用例已经过时。一个死板的循环会卡在过时的约束上；而一个灵活的循环则可能通过削弱测试或改变目标来"作弊”，以到达完成状态。
循环是优秀的调节器（Regulators），但却是糟糕的目标设定者（Reference-setters）。
它们能极好地将系统维持在目标附近，但无法决定公司下一步应该构建什么机器 [7]。
五、超越软件开发：科学发现中的多保真度循环
目前，循环工程的讨论压倒性地集中在软件开发（特别是代码生成）上。这并非偶然——软件环境提供了极其优越的条件：快速迭代 + 机器可验证的反馈 + 廉价的回滚。生成代码 → 编译 → 运行测试 → 失败 → 修改，整个过程只需几秒到几分钟 [5]。
但如果我们把目光投向计算生物学或蛋白质设计，情况就大不相同了。在蛋白质设计中，一次全原子分子动力学（MD）模拟可能需要数小时到数天，而湿实验验证则需要数周 [3]。如果采用软件工程中那种朴素的、高频的循环（运行整个管道 → 检查 → 修改 → 重新运行），成本将是毁灭性的。
这并不意味着循环工程不适用，恰恰相反——它需要一种更精细的多保真度分层循环（Multi-fidelity hierarchical loop） [5]：
| 层级 | 循环内容 | 时间尺度 | 作用 |
|---|---|---|---|
| 内层：计算循环 | 生成候选 → 代理模型预测适应度 → 筛选 | 秒级，成千上万次迭代 | 淘汰 99% 的无效变体 |
| 中层：验证循环 | 结构预测（AlphaFold3）或对接分析 | 分钟到小时，批处理以减少 GPU 空闲 | 对保留候选做高置信度评估 |
| 外层：实验 DBTL 循环 | 设计 → 构建 → 测试 → 学习 | 数周，全程仅 2–5 轮 | 真实世界的验证与学习 |
这里的核心设计原则与软件工程截然不同：
不要在时间上循环，要在信息增益上循环。
对于昂贵的科学工作流，系统在启动昂贵的评估前必须先计算：预期的信息增益是否值得这笔计算或实验成本？[5]
软件循环工程优化的是迭代吞吐量；而科学循环工程优化的是单位计算/时间/预算下的信息增益 [5]。
六、下一次演进：从循环（Loops）到图（Graphs）
随着系统变得越来越复杂，单个循环的局限性暴露无遗：循环为了优化单一指标会进行"作弊"（古德哈特定律），且循环无法质疑其自身目标的正确性 [8]。
因此，最前沿的架构设计正在从单一的"循环"演进为"图网络（Graphs）" [8]。成熟的系统（如现代机器学习运维流水线）本质上是由相互连接的循环组成的：
- 冠军-挑战者循环：候选模型必须在实时流量上击败当前模型。
- 漂移监控循环：检查数据分布是否发生变化。
- 回滚循环：在指标异常时自动恢复。
- 故意被盲化的评估循环：它永远看不到训练数据，专门用来抓住优化循环的作弊行为。
最后一条尤其关键——它是对"循环会作弊"这一根本缺陷的结构性回应：用一个循环去监督另一个循环。
在这个图网络中，可靠性存在于边（Edges）之中：哪个循环为哪个循环提供数据？哪个循环监视哪个循环？哪个循环可以否决哪个循环？[8]
结语：人类在循环中的不可替代性
循环工程不是一个空洞的流行语，它是 AI 智能体走向生产环境的必经之路。它将人类从重复的微观执行中解放出来，但这绝不意味着人类被踢出了开发流程。
在这个范式下，一套完整的自主系统由四个角色分工构成：
- 模型提供智能
- Harness 提供能力边界与可靠性
- 循环提供轨迹与终止条件
- 人类提供目标——那个循环自身永远无法质疑的参考点
正如吴恩达（Andrew Ng）所言，人类在上下文、领域知识和产品愿景上具有智能体无法替代的优势 [1]。真正的智能系统不会盲目地无限循环，它们知道何时该停下来，解释自己尝试了什么，总结为什么无法继续，并将控制权交还给工程师。
在自主 AI 时代，“人类在循环中（Human-in-the-Loop）“不再仅仅是一个安全后备机制，而是确保系统不脱离现实的核心架构原则。
参考文献
[1] Andrew Ng. (2026, July). Loop engineering is a hot buzzphrase…. Facebook.
[2] Flowtivity. (2026, July). From Loops to Graphs: The Next Paradigm in AI Agent Architecture. flowtivity.
[3] Exemplar.dev & Kilo Code. (2026). Loop Engineering and the PDCA Cycle.
[4] LangChain. (2026, June). The Art of Loop Engineering. langchain.com.
[5] Addy Osmani & Community Discussions. (2026). Loop Engineering vs. Harness Engineering.
[6] Naresh B.A. (2026, July). Loop Engineering Beyond the Hype: An Engineer’s Perspective. Medium.
[7] Isaac Hagoel. (2026, July). Loop Engineering Minus the Hype. DEV Community.
[8] IntuitionMachine. (2026, August). From Loop Engineering to Graph Engineering?. Medium.