Loop Engineering：为 Coding Agent 设计可控的反馈循环｜李彦卿

先说边界

Loop Engineering 是一个正在形成中的词。截至 2026 年 6 月，它还不是已经定型的行业标准。

本文讨论的范围也更窄：coding agent / 软件工程场景。后面的五个问题、控制面、能力层和 Loop Card，都是我为了落地实践采用的分析框架，不是通用规范。

我对它的工作定义是：

Loop Engineering 是围绕 Coding Agent 设计跨多轮运行的反馈控制结构：任务如何触发，状态如何持久化，结果如何验证，以及系统何时继续、重试、停止或转交给人。

它不是让 Agent 无边界自跑。更准确地说，它追求的是受控自动化。

为什么会出现这个问题

很多 AI 编程流程看起来已经自动化了，其实真正的调度器还是人。

常见流程是：

人写需求。
Agent 改代码。
人跑测试。
测试失败后，人把错误贴回去。
Agent 再改一轮。
人判断能不能结束。

这个流程当然也是循环，但循环主要存在人的脑子里。

人负责记住上下文、判断风险、挑验证命令、区分代码问题和环境问题，还要决定什么时候停止。规模一大，这套方式就会漏。

Loop Engineering 要做的，是把这些隐性的人工判断沉淀成系统能读取、执行和审查的结构。

它和 Prompt、Context、Harness 的关系

这些概念有重叠，不是互斥分类。下面只是便于讨论的工程分工。

概念：Prompt Engineering；关注点：当前调用中的指令、示例和输出约束；典型问题：这一轮怎么表达任务
概念：Context Engineering；关注点：当前调用实际提供给模型的信息集合；典型问题：哪些文件、历史、规则、错误进入上下文
概念：Harness Engineering；关注点：Agent 执行、观察和保存状态的运行机制；典型问题：工具、权限、沙箱、测试、状态、恢复怎么组织
概念：Loop Engineering；关注点：跨步骤、跨尝试、跨运行的控制策略；典型问题：何时触发、如何验证、怎样转移状态、何时停止

Prompt 和工具描述通常也是 context 的一部分。Harness 也可能承担状态、验证、重试和恢复。Loop 往往是由 harness 或 orchestrator 实现出来的控制策略。

所以不能简单说“Prompt 是一句话，Loop 是系统”。更准确的区别是：Prompt 更关注当前调用，Loop 更关注多轮工作如何推进和收敛。

一个最小 Loop 要回答什么

我习惯用五个问题检查一个 Loop：

问题：目标；含义：本轮要解决什么，什么叫完成
问题：上下文；含义：哪些事实必须读取，哪些信息不能猜
问题：行动；含义：Agent 可以做什么，哪些操作禁止
问题：证据；含义：改完看什么：测试、日志、截图、代码差异还是运行产物
问题：决策；含义：成功、重试、换路线、停止还是转人工

但真正的闭环还需要显式控制流：

触发

-> 读取外部状态与上下文

-> 执行动作

-> 收集证据

-> 判定结果

-> 成功 / 重试 / 换路线 / 转人工 / 停止

-> 持久化状态

这里要区分三件事：

Evidence / 证据：系统看到了什么，比如测试输出、日志、截图、代码差异。
Oracle / 判定器：这些证据是否满足成功标准。
Decision / 状态转移：下一步是继续、停止、重试、缩小范围，还是转交给人。

没有判定器，日志和截图只是一堆材料。没有状态转移，循环就只是重复执行。

四个控制面

一个可用的 Loop 至少还要补四个控制面。

1. 外部状态

Agent 不能只依赖当前对话历史。跨会话、跨上下文窗口、跨任务恢复时，需要有外部状态记录：

当前任务版本。
已尝试方案。
已排除原因。
代码 revision。
证据位置。
未解决风险。

否则下一轮很容易重复尝试，或者把已经排除的方案再做一遍。

2. 预算

预算不是财务概念而已，也是工程边界：

最多尝试几轮。
每轮最长运行多久。
最多调用多少工具。
什么时候判定“无进展”。

没有预算的 Agent 循环，容易从自动化变成自动试错。

3. 权限与副作用

Loop 必须区分：

只读分析。
本地改代码。
开 PR。
改配置。
部署。
访问生产数据。
修改密钥、账单或供应商策略。

越靠近外部副作用，越需要人工确认和审计。

4. 失败分类

失败之后不能只有“再试一次”。

失败类型：确定性代码失败；默认动作：把诊断证据反馈给修复循环
失败类型：临时基础设施失败；默认动作：有限重试并退避
失败类型：Flaky check；默认动作：隔离检查，不让 Agent 修改业务代码迎合噪音
失败类型：Oracle 不明确；默认动作：停止并人工判断
失败类型：权限或策略冲突；默认动作：禁止重试，直接升级
失败类型：连续无进展；默认动作：缩小范围或结束本轮

很多危险不是 Agent 不会改，而是它在错误层面持续改。

Gate 和 Eval 不是一回事

Loop Engineering 里经常会混用 check、gate、eval。它们最好分开。

Check / Gate：判断这一次运行能不能通过，比如单测、契约测试、导入回归、浏览器验证。
Eval：比较某个模型、Prompt、工具或 Harness 版本，在一组任务和多次 trial 上的总体表现。

Gate 解决“这次能不能过”。Eval 解决“这个系统版本是否整体更好”。

所以，trace 只能提供改进假设。Prompt、模型、工具或 harness 的修改，应该经过离线 eval 和回归验证后再进入主流程。

Loop Engineering 的能力层

下面不是严格线性的成熟度模型，而是一组通常会逐步补齐的能力层。

M0：人工闭环

人提出目标，Agent 改代码，人选择检查命令，人判断结果。

不少团队仍主要依赖这种方式。它能工作，但很吃人的经验和注意力。

M1：规则契约化

把隐性规则写出来。

例如：

哪些路径是核心链路。
哪些文件改动必须跑哪些检查。
哪些操作必须人工确认。
哪些失败不能继续重试。
哪些证据必须保存。

这一步不需要先造平台。先有一张清楚的 Loop Card 就够。

M2：验证可重复

把检查变成可重复执行的 gate。

不要只写“确保不破坏核心功能”，而是准备固定样本、固定命令、明确成功条件和失败证据。

目标不是完全消除不稳定，而是让判定器尽量确定；对不稳定检查，要能识别、隔离和处理。

M3：人工触发的受控循环

这时可以允许 Agent 在边界内多跑几轮。

但必须有最大轮数、无进展判断、失败分类、外部状态和人工升级规则。

如果两轮之后仍然是同一类失败，就不要继续猜。可能是环境、oracle、权限或模型能力问题。

M4：事件驱动循环

CI、任务系统、监控或定时器可以自动触发诊断、分析或草拟 PR。

这一层的关键不是“加一个 cron”，而是处理真实运行问题：

重复事件和幂等性。
并发运行和工作区隔离。
取消、超时和死信处理。
副作用审计。
凭据与权限边界。

我不建议一上来就自动合并或自动部署。更稳的是影子模式：系统只分析或提出修改，人和门禁决定是否进入主线。

M5：Trace 提供假设，Eval 负责门禁

最有复利的是改进循环。

重复失败不应该只修一次，而要聚类成样本，反过来改工具、规则、Prompt、模型策略或测试。

但 trace 不是直接改生产策略的理由。它只提供假设。真正进入主流程之前，要通过 eval、回归集和对照验证。

示例：把核心路径保护变成受控循环

在一个已有核心链路和回归资产的项目中，Loop Engineering 的低风险起点之一，是核心路径保护。

假设某条导入链路是核心能力。它不能只靠一句“不要破坏”。更稳的做法是：

相关代码变更触发检查。
用固定样本验证接口契约和持久化结果。
保存失败证据。
写入外部状态。
根据判定结果决定通过、重试、缩小范围或转人工。

注意，这条 gate 本身不是完整 Loop。它是 Loop 里的验证门禁。完整 Loop 还需要触发、状态、决策和升级路径。

这就是现实价值：把“我记得这个很重要”，变成“系统每次都会检查这个，并知道下一步怎么处理”。

不要把它理解成什么

Loop Engineering 不是：

更长的 Prompt。
更复杂的工作流平台。
让 Agent 无人值守改生产。
把所有测试每次都跑一遍。
失败后无限自动重试。
用代码掩盖模型能力边界。

它更像一套控制系统。

让 AI 工作有触发、有状态、有证据、有判定器、有预算、有退出条件。

一个最小实践模板

如果今天就想开始，不要先造平台。先拿一条最重要的核心路径，写出一张最小 Loop Card。

下面是示例值，不是通用推荐：

loop: core-path-preservation

trigger:

change_surface:

- path: apps/extension/**

- path: apps/api/**/import*

state_store:

path: artifacts/loop-runs/{run_id}/state.json

goal:

preserve_core_capability: true

success_criteria:

- historical fixture imports successfully

- persisted result matches compatibility contract

- failure evidence is saved when check fails

checks:

- name: import-contract

command: pnpm test:import-contract

timeout_minutes: 5

pass_condition: exit_code == 0

- name: smoke-core-path

command: pnpm regression:smoke

timeout_minutes: 10

pass_condition: exit_code == 0

evidence:

save_to: artifacts/loop-runs/{run_id}/

include:

- command output

- fixture id and hash

- code diff summary

- failure class

decision_policy:

on_success: mark_passed

on_code_failure: retry_with_evidence

on_flaky_check: isolate_and_escalate

on_unclear_oracle: escalate_to_human

budget:

max_attempts: 2

max_runtime_minutes: 20

stop_conditions:

- same_failure_twice

- permission_required

- production_side_effect_detected

human_approval:

required_for:

- changing tests

- changing production config

- changing provider or model policy

side_effect_policy:

allow:

- local code edits

- local test execution

forbid:

- production config mutation

- credential mutation

- silent fallback that hides failure

这张卡仍然很小，但它已经把 Loop Engineering 从口号落到了工程结构：触发、状态、验证、证据、决策、预算和停止条件都能被系统读取。

最后

Prompt Engineering 提高单轮交互的可控性。

Loop Engineering 提高多轮工作的可重复性和可审查性。

真正重要的不是让 Agent 跑得更远，而是让系统知道：

凭什么开始。
凭什么继续。
凭什么算完成。
凭什么停下来找人。

概念来源

Addy Osmani, Loop Engineering
LangChain, The Art of Loop Engineering