当 Agent 能连续工作、调用工具并修改真实系统后，决定效果的关键不再只是模型聪不聪明，而是循环如何被触发、如何验证、如何记住进度、如何在失败后变得更好。

图 1 从 Prompt 到 Loop：瓶颈逐步从话术移向系统制度

1．为什么 Loop Engineering 会在现在出现

早期的大模型主要是一问一答。提问方式稍微换一下，结果就可能差很多，所以工程师把精力放在角色、示例、格式和思维步骤上。这个阶段，最稀缺的能力是“把话说清楚”。

模型开始承担真实任务后，问题变了。它需要读代码、查文档、调用数据库、运行命令，还要知道项目里的约定。于是 Context Engineering 和 Harness Engineering 分别解决“给什么材料”和“提供什么工作环境”。

当材料和环境逐渐成熟，最后仍然需要人不断盯着屏幕：看结果、补一句、再按一次回车。Loop Engineering 瞄准的正是这一段人工驱动。它把发现任务、安排执行、验证结果、重试或升级写成可持续运行的系统。

图 2 回合制协作依赖人持续操作，循环制协作依赖预先设计的规则

2．Loop Engineering 到底是什么

它不是简单地写一个 while 循环，也不是让 Agent 无限重试。更准确的说法是：把目标、触发、执行、证据、验证、状态、预算和人工升级组合成一个受控闭环，让系统能够在没有人逐步指挥的情况下持续推进任务。

一个好的 Loop 具有三个特征：每一轮都有明确状态，每一次决定都有可检查证据，每一条路径都有停止条件。缺少其中任意一个，循环都可能退化为“反复调用模型”。

图 3 Agent、验证、事件和改进四层循环

3．四层循环：从做事到自我改进

Agent Loop：模型和工具把任务往前推

最内层是经典 Agent 循环：读取当前状态，决定下一步，调用工具，观察结果，再决定下一步。它解决的是“把事情做完”。工具可以是代码执行、搜索、数据库查询、文件编辑，也可以是一个外部业务接口。

Verification Loop：用规则判断是否真的完成

Agent 声称“完成”不等于任务真的完成。验证循环会运行测试、检查 Schema、比对需求、核验引用，失败时把结构化反馈送回执行器。它解决的是“把事情做对”。

Event Loop：让 Agent 嵌入真实业务

定时任务、Webhook、PR 事件、告警和文件到达，都可以成为触发器。Agent 不再是临时打开的聊天窗口，而是系统中的后台组件。它解决的是“在正确时间自动开始”。

Hill-Climbing Loop：从运行记录中改进 Harness

每次运行都会产生 Trace、工具结果、人工反馈和验证分数。外层循环把这些信号沉淀为评测数据，再修改 Prompt、工具描述、路由或验证器。它解决的是“下一批任务比上一批更稳”。

4．一个能跑起来的 Loop，需要哪些部件

图 4 可运行 Loop 的完整骨架

触发器：决定何时开始。可以按时间、事件、条件或人工操作触发。

任务队列：负责去重、优先级、并发与锁，避免同一问题被多个执行器重复处理。

计划器：把目标拆成可执行步骤，并根据任务类型选择工具和模型。

执行器：真正调用工具、修改文件或更新业务状态。

验证器：用确定性测试和语义规则判断是否达标。

状态与记忆：记录已完成步骤、证据、失败原因和下一步。

出口：成功提交、带反馈重试，或在风险和不确定性过高时升级给人。

5．自动化：给循环装上心跳

只有人手动点击“运行”的脚本，仍然是一项工具。自动触发之后，它才成为持续工作的 Loop。常见触发方式包括定时扫描、仓库事件、外部 Webhook、监控阈值和人工审批。

图 5 四类触发器及其适用场景

事件触发通常比高频轮询更省资源。例如 PR 状态变化、告警产生或文件落盘时再运行，比每分钟查询一次更自然。需要定时运行时，也应避免所有任务挤在整点，并考虑任务延迟、重复触发和漏触发。

GitHub Actions 示例
on:
schedule:
- cron: '17 1 * * 1-5'
timezone: 'Asia/Shanghai'
repository_dispatch:
types: [ci_failure]
jobs:
triage-loop:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: python tools/triage_loop.py

6．状态机：让长任务可以暂停、恢复和审计

一次模型调用可以靠上下文记住进度，跨小时、跨机器、跨会话的任务不行。生产 Loop 应把状态写入数据库、任务系统或版本控制文件，并把状态转换规则写清楚。

图 6 Loop 状态机和需要持久化的关键字段

状态机最大的价值不是“看起来专业”，而是让系统知道当前处于哪一步、为什么失败、还能重试多少次，以及下次从哪里继续。没有状态机，很多所谓自治系统只是把复杂性藏进一段不断增长的对话。

Python 状态定义
class LoopState(TypedDict):
task_id: str
status: Literal['PENDING','RUNNING','VERIFYING','RETRY','DONE','ESCALATED']
attempt_count: int
evidence: list[dict]
last_error: str | None
next_action: str | None
budget_left: float

7．验证闭环：最值钱的不是重试，而是反馈

循环失败后，如果只是把完整错误日志重新塞给模型，下一轮很可能再次绕圈。有效反馈应该至少包含三个部分：失败发生在哪里、观察到了什么、允许采用哪些修复方向。

图 7 验证器控制通过、反馈和重试

确定性验证应该优先：单元测试、编译、Lint、Schema、链接检查、权限规则和数据约束，比“请另一个模型看看是否正确”更稳定。主观质量无法完全规则化时，再使用 LLM Grader，并定期用人工样本校准。

8．写查分离：不要让 Maker 给自己打分

生成结果的 Agent 已经在自己的上下文中形成了一套解释，它天然倾向于证明自己的方案合理。让一个干净上下文的 Checker 独立阅读规格、差异和测试结果，更容易发现范围扩大、遗漏边界和“测试为通过而改”的问题。

图 8 Maker 与 Checker 的职责分离

Checker 不一定使用更强的模型。很多检查可以由快速模型或确定性工具完成。真正值得使用高成本第二意见的场景，是安全、架构变更、资金、生产数据库和复杂业务规则。

9．并行化：Worktree 解决文件冲突，编排器解决任务冲突

多个 Agent 同时工作时，最直观的问题是文件互相覆盖。Git Worktree 可以为每个任务提供独立工作目录和分支，共享仓库历史但隔离未提交修改。

图 9 多 Agent 使用独立 Worktree 并行工作

文件隔离只是第一层。两个 Agent 可能同时处理同一工单、调用同一外部接口或争抢同一测试环境，所以还需要任务锁、幂等键、资源租约和最终合并策略。并行度的上限往往不是模型数量，而是验证和人工评审的吞吐。

10．Connector 与 MCP：让 Loop 真正完成业务动作

只会读写本地文件的 Loop，能做的事情有限。连接器把仓库、工单、数据库、监控和消息系统接入，让 Agent 获取事实并执行动作。MCP 提供标准化的 Client–Server 连接方式，服务器可以暴露工具、资源和工作流模板。

图 10 Loop 通过 MCP 和连接器接入外部系统

连接能力越强，权限设计越重要。高风险工具应采用最小权限、参数白名单、预览模式和人工审批；返回结果应结构化，并携带时间、来源和状态，避免 Agent 根据模糊文本猜测下一步。

11．记忆：Agent 会忘，但状态文件不会

Loop 不能把所有记忆都押在上下文窗口里。上下文适合保存当前思考所需的局部信息，持久化存储适合保存跨轮次进度、证据和决策。两者的边界越清晰，系统越容易恢复。

图 11 上下文记忆与持久化状态的差异

建议至少保存任务 ID、当前状态、版本号、尝试次数、最后错误、使用过的证据、产出位置和下一步。对于代码 Loop，仓库中的进度 Markdown、Issue 或 PR 本身就可以成为可审计记忆。

12．改进飞轮：把线上失败变成可重复的评测

只修一次线上故障，系统不会真正变好。更稳的做法是保留 Trace，补充人工或模型反馈，把失败样本加入评测集，再根据评测结果修改 Harness。新版本必须通过旧样本和新增失败样本，才能灰度发布。

图 12 从 Trace 到 Harness 改进的学习飞轮

Trace 不只是最后答案，还应包含模型调用、工具调用、Guardrail、路由和 Handoff。这样才能区分“答案错了”“工具选错了”“工具返回异常”“验证器误判了”，并把修改落到真正的问题位置。

13．成本、权限与止损：Loop 的边界必须写进系统

图 13 Loop 的五类控制边界

循环会放大效率，也会放大错误。一个错误 Prompt 在单轮里可能只浪费一次调用，进入自动循环后可能反复修改、反复通知、反复消耗资源。

最大步数和最大总成本

单步超时与指数退避

工具最小权限与高风险审批

幂等键、版本号和分布式锁

连续失败、证据不足或冲突时立即升级人工

受控循环伪代码

while state.status not in {'DONE', 'ESCALATED'}:
if state.attempt_count >= MAX_STEPS or state.budget_left <= 0:
state.status = 'ESCALATED'
break
candidate = executor.run(state)
verdict = verifier.check(candidate, state)
if verdict.passed:
state.status = 'DONE'
else:
state.last_error = verdict.feedback
state.attempt_count += 1
state.status = 'RETRY'
state_store.save(state)

14．评测指标：不要只看“最后成功没成功”

任务成功率是核心结果，但它无法解释系统为什么变好或变差。Loop 评测应同时覆盖结果、路径、成本、时延和风险。

图 14 Loop 的核心评测指标

开发阶段先看 Trace，快速定位工具、路由和 Handoff 问题；规则稳定后，再建立可重复数据集和批量 Eval。对于多路径 Agent，不应强制要求每次走同一条路线，而应验证关键约束、最终状态和证据质量。

15．一套生产级 Loop 参考架构

图 15 生产级 Loop 的触发层、控制面、执行面和治理层

控制面维护任务、状态、预算、权限和审批；执行面运行 Planner、Worker、工具和 Verifier；治理层收集 Trace、指标、评测样本和 Harness 版本。模型供应商可以替换，循环的业务状态和验证标准不应绑定到某一个模型。

高风险业务还应增加预演环境、只读模式、双人审批、回滚快照和操作审计。自动化并不意味着完全移除人，而是把人的判断放在真正需要经验和责任的节点。

16．从 0 到 1：别一开始就做“全自动公司”

图 16 Loop Engineering 四周落地路线

最小 Loop 只需要一个重复场景、一个清晰目标、一种触发方式、一个执行器、一组确定性验证和一个状态文件。先证明它能稳定完成一件小事，再逐步增加并行、连接器、Checker 和学习飞轮。

17．面试怎么回答 Loop Engineering

可以按“定义—结构—可靠性—落地”四段回答：

定义：Loop Engineering 是把 Agent 的触发、执行、验证、状态、预算和改进机制工程化，使任务不再依赖人逐轮输入 Prompt。

结构：内层是模型调用工具的 Agent Loop，外面包验证 Loop，再由定时或事件驱动，运行 Trace 继续进入评测和 Harness 改进飞轮。

可靠性：用状态机、确定性验证、Maker–Checker 分离、最大重试、幂等、最小权限和人工升级防止无限循环与错误放大。

落地：从单任务最小闭环开始，先加测试和状态，再接任务队列、MCP、可观测和回归评测。

图 17 Loop 上线前检查清单

写在最后

Loop Engineering 不是让人退出工作，而是把人的判断从“每一步操作”提升到“设计目标、规则和边界”。真正优秀的 Loop，不是转得最快，而是能稳定完成、能解释过程、能在错误时止损，并能把每次失败沉淀成下一次的能力。

Prompt 是一次指令，Harness 是工作环境，Loop 是持续运行的制度。模型决定上限，循环决定能不能稳定接近这个上限。