Loop Engineering：循环不是问题，是解法

2026-06-22

软件工程花了五十年学会一件事：别怕循环。

从 while(true) 到事件循环，从 CI/CD pipeline 到 Agent 的 self-correction，循环一直是系统的核心结构。但我们对它的态度很分裂——一边知道循环是必要的，一边又觉得循环是危险的（死循环、无限递归、反馈震荡）。Loop Engineering 要做的事很简单：把循环从”不得不用的危险结构”变成”可工程化的第一公民”。

第一性原理

拆到最底层，Loop Engineering 只有一个前提：

任何需要适应环境的系统，必须包含循环。

这不是主张，是逻辑必然。一个不循环的系统，它的行为在启动时就完全确定了——给定输入，输出唯一。这种系统处理不了三件事：

环境变了。上游 API 改了返回格式，你的解析器还是老逻辑。
结果不对。第一次输出有错，没机会修正。
目标漂移了。用户要的东西和一开始不一样了，系统还在跑旧目标。

要应对这三件事，系统必须能感知→判断→调整→再执行。这就是循环。没有循环的系统是开环的——信号出去就出去了，不管结果。

但光有循环不够。一个裸的 while(true) 不是工程，是赌博。Loop Engineering 的第一性原理可以拆成三条：

1. 循环必须有终止条件

不是”加个 timeout 就行”——终止条件是循环语义的一部分。一个循环的终止条件定义了它”什么叫做完”：

固定次数循环：做 N 次就停（批量处理）
收敛循环：输出变化小于阈值就停（优化、迭代修正）
条件循环：达到目标状态就停（搜索、规划）
事件循环：收到信号就停（事件驱动）

没有明确终止条件的循环，本质上是在说”我不知道什么时候算完”，这不是工程问题，是需求没想清楚。

2. 循环必须有可观测性

循环体里发生了什么，必须能从外面看到。不是每次都要看，但需要看的时候必须能看。

这包括：

当前在第几轮
每轮的输入输出是什么
收敛指标的变化趋势
资源消耗（时间、token、API 调用次数）

一个不可观测的循环，出了问题只能靠猜。调试循环比调试线性代码难一个数量级，因为状态是随时间变化的。可观测性是调试的前提。

3. 循环必须有护栏

循环可以犯错，但犯错的代价必须有上限。护栏不是”别出错”——那是理想情况。护栏是”出错了，系统不会崩”。

具体形态：

资源上限：最多跑 N 轮、花 $X、用 T 秒
输出约束：每轮输出必须满足 schema，不满足就重试或降级
熔断：连续 N 次失败就停止，别死磕
回退：记住”最后一个好状态”，出了问题能退回去

这三条——终止条件、可观测性、护栏——构成了 Loop Engineering 的第一性。缺了任何一条，循环就从工程结构退化成危险结构。

Loop Engineering 和 Harness 的关系

Harness 这个词来自攀岩：安全带。攀岩者可以自由攀爬，但一旦失手，安全带兜住你。Agent Harness 也是这个意思——Agent 可以自由运行，但运行在受控的框架里。

Loop Engineering 是原理层，Harness 是实现层。

打个比方。Loop Engineering 说”循环需要护栏”。Harness 就是那个护栏。Loop Engineering 说”循环需要可观测性”。Harness 就是那些传感器和仪表盘。

更具体地说：

Harness 是循环的运行时基础设施

一个裸的 Agent 循环长这样：

1
2
3

while not done:
    action = agent.think(observation)
    observation = environment.execute(action)

这个循环缺了 Loop Engineering 要求的一切——没有终止条件保障（done 谁设的？什么时候设？），没有可观测性（中间状态全丢），没有护栏（agent 可以一直跑）。

Harness 给这个循环套上框架：

harness = AgentHarness(
    max_iterations=10,          # 终止条件：最多10轮
    max_cost_usd=0.5,           # 护栏：花费上限
    convergence_fn=check_converged,  # 终止条件：收敛检测
    observers=[logger, metrics],     # 可观测性
    fallback=last_good_state,        # 护栏：回退策略
    circuit_breaker=Breaker(failures=3),  # 护栏：熔断
)

result = harness.run(agent, initial_input)

Harness 不改变循环的逻辑——Agent 还是”想→做→看→想”，但每次循环都在受控环境下执行。

Harness 管的是”怎么跑”，Loop Engineering 管的是”为什么这样跑”

这是关键的区分。

Harness 提供了一堆旋钮：max_iterations、timeout、retry_policy。这些旋钮该拧到多少？这得回到 Loop Engineering 的原理。

比如 max_iterations 该设多少？不是拍脑袋。Loop Engineering 说：看你的收敛预期。如果任务通常 3-5 轮收敛，设 10 是合理的上限（2 倍余量）。如果任务理论上需要 20 轮，设 10 就是在人为制造失败。

再比如 convergence_fn 该怎么写？Loop Engineering 说：收敛是输出变化率趋近于零。但”输出”是什么？是 Agent 的最终回答？是中间的推理步骤？是外部环境的反馈信号？这取决于循环的语义。

Harness 给你工具，Loop Engineering 告诉你怎么用工具。

没有 Harness 的循环是裸奔，没有 Loop Engineering 的 Harness 是乱拧

裸奔的危险显而易见。但乱拧旋钮同样危险——max_iterations=100 配上一个永远不会收敛的 Agent，结果就是烧钱。timeout=5s 配上一个需要 10 秒才能完成的任务，结果就是永远失败。

好的工程实践是两者配合：Loop Engineering 确定循环的语义和参数，Harness 提供运行时保障。

工程实践中的应用场景

1. Agent 自修正循环

这是目前最常见的场景。Agent 执行任务→检查结果→发现不对→修正→再执行。

用户: "帮我从日志里提取超时请求"
→ Agent 生成正则
→ 跑测试集，准确率 60%
→ 反馈失败 case，Agent 修正正则
→ 跑测试集，准确率 95%
→ 通过，返回结果

Loop Engineering 的约束：

终止条件：准确率 ≥ 95% 或最多重试 3 次
可观测性：每轮的准确率、修正了什么、花了多少 token
护栏：每轮正则必须通过 ReDoS 检查，连续 2 轮准确率下降就熔断

Harness 实现：Agent 框架（LangGraph、OpenClaw Skills）里的 retry + validation loop。

2. CI/CD Pipeline

CI/CD 本质是个大循环：代码变更→构建→测试→部署→监控→发现异常→回滚→修代码→再变更。

1
2
3

commit → build → test → deploy → monitor
  ↑                                 │
  └──── rollback/alert ─────────────┘

Loop Engineering 的约束：

终止条件：部署成功且监控指标平稳 30 分钟
可观测性：每个阶段的耗时、通过率、监控指标趋势
护栏：自动化测试覆盖率阈值、部署灰度比例、自动回滚触发条件

Harness 实现：CI/CD 平台（GitHub Actions、Jenkins、Zadig）本身就是 Harness。它们提供了超时、重试、审批门禁、灰度发布等机制。

3. 数据质量循环

数据管道里的循环：摄入→校验→发现问题→清洗→重新校验。

raw_data → validate → 发现脏数据比例 15%
         → 生成清洗规则 → 清洗
         → 重新校验 → 脏数据比例 2%
         → 通过

Loop Engineering 的约束：

终止条件：脏数据比例 < 阈值（如 5%）
可观测性：每轮的脏数据比例、清洗规则列表、数据分布变化
护栏：清洗不能丢超过 10% 的数据，关键字段不能为空

这个场景有意思的地方在于，清洗规则本身可以由 LLM 根据脏数据样本动态生成——这就是 LLM 生成正则的场景，和前面的文章接上了。

4. 产品迭代循环

产品层面的循环：发布→收集用户反馈→分析→调整→再发布。

这不是代码层面的循环，但 Loop Engineering 的原则同样适用：

终止条件：核心指标（留存率、NPS）达标
可观测性：用户行为数据、反馈分类、A/B 测试结果
护栏：不发布影响核心流程的变更、灰度放量、一键回滚

产品经理说的”小步快跑、快速迭代”，本质就是 Loop Engineering 的口头版。但口头版缺了工程约束——没有终止条件就变成”永远在迭代”，没有护栏就变成”每次迭代都可能翻车”。

5. 多 Agent 协作循环

多个 Agent 协作时，循环结构更复杂。不是单个 Agent 的自修正，而是 Agent 之间的协商和收敛。

Agent A: 提出方案
Agent B: 审查方案，提出问题
Agent A: 修改方案
Agent C: 验证方案可行性
→ 方案通过 or 继续修改

Loop Engineering 的约束：

终止条件：所有 Agent 投票通过，或讨论超过 N 轮强制决策
可观测性：每轮讨论记录、各 Agent 立场变化、共识度指标
护栏：单个 Agent 不能阻塞超过 2 轮、最终决策权必须明确归属

从裸循环到工程化循环

一个实用的迁移路径：

第一步：给裸循环加上日志。 先不管别的，至少知道每轮发生了什么。这是可观测性的零成本起步。

第二步：加上硬上限。 max_iterations、timeout。不需要精细，先防住死循环和超时。这是护栏的最小实现。

第三步：定义收敛条件。 从硬上限过渡到语义终止——“什么时候算做完”比”最多做多长时间”重要得多。

第四步：套 Harness。 用框架替代手写的循环控制逻辑。不是所有循环都需要框架，但重复出现的模式值得被抽象。

第五步：参数调优。 基于历史数据调整 Harness 参数。max_iterations 设多少合适？收敛阈值多紧？这些参数应该从实践中来，不是拍脑袋。

说到底

循环不可怕，裸循环才可怕。Loop Engineering 做的事是把”循环”从代码层面的 while 提升到工程层面的可规划、可观测、可控制的结构。Harness 是这件事的具体实现——安全带、仪表盘、保险丝。

不是所有循环都需要被工程化。写个脚本处理一次性的数据，裸循环就裸循环，无所谓。但当循环成为系统的核心结构——Agent 自修正、CI/CD、数据管道、产品迭代——它就值得被认真对待。

认真对待的方式不是”加更多代码”，是搞清楚三件事：什么时候停、出了什么问题、出了问题怎么办。这三件事想清楚了，循环就是解法。想不清楚，循环就是问题。