别急着神化 Loop Engineering：先弄懂这 8 个问题。

原创 曾经的毛毛 2026-06-22 08:30 江苏

一文说清 Loop Engineering：Agent 系统新范式背后的 8 个问题。

点击上方

蓝字

轻松关注~

相信很多人最近看到过这样的很具传播感的标题：

Prompt Engineering 已死，现在是 Loop Engineering 了。

个人很反感把每一个新概念都包装成“旧时代已死”、“再不学就晚了”。听过太多类似的话：RAG 已死，SaaS 已死，程序员将消失，这些说法要不偷换概念、以偏概全；要不就是忽略了场景、边界这些重要的东西。

本文就来说说这个 Loop Engineering — AI 如何从“一次性任务”的范式，走向真正的”持续、自主、可靠的执行任务“。

1. 为什么会出现 Loop Engineering

2. 概念与边界

3. 区分 Agent Loop 与 Loop Engineering

4. 和 Context/Harness Engineering 的关系

5. 构建块与系统设计

6. 构建 Loop 的工具

7. 适用性判断

8. 风险与能力不足

01

为什么会出现 Loop Engineering

Loop Engineering 出现，不是因为大家喜欢造新词，而是我们使用 Agent 的方式发生了变化。

1. 最开始，我们写 Prompt，完成问答和简单任务

2. Agent 出现，开始做 Context Engineering，给模型更完备的上下文环境

3. 再后来，为了让 Agent 能够更“稳”的执行任务，我们给它包上工具、规则、记忆、沙箱、恢复机制等，做 Harness Engineering；

现在，Agent 已经可以跨多步执行任务，那么问题是否就全部解决了呢？

回顾下我们之前使用 Coding Agent 的过程，假如有一个任务：

“帮我创建一个 AI 驱动的个人知识库系统”

接下来的过程大概率是这样：

这里的问题是：

这里每一轮的 “检查 — 纠偏 — 再运行” 仍然要靠人手动完成，Agent 的自动化价值在这里存在断层，“卡住了”。

这就是 Loop Engineering 出现的背景：我们需要把“人手动推进 Agent” 的过程，变成一个系统自动推进的过程。或者说：

你（人）不再是这个 Loop 的一部分，你负责设计 Loop 本身 — 一个让 AI 能够持续、自主、可靠地完成任务的闭环系统。

很显然，这里隐含了一个现实的背景：

虽然模型确实越来越强，但长任务依然并不可靠， Agent 还远没有到随便给个目标就能稳定完成复杂任务的程度。上下文腐烂、目标漂移、工具误用、错误累积等问题，仍然是常见问题。

所以我们才需要用工程的方法设计驱动 Agent 向目标持续迭代的闭环。

02

概念与边界

那么到底如何定义 Loop Engineering？并没有权威的标准，这里引用 Google 大神 Addy Osmani 在长文《Loop Engineering》中的定义：

Loop Engineering 就是设计一个系统代替“你”来引导 Agent。这里所说的 Loop 可以理解为一个递归目标，你定义它，Agent 会迭代执行直到完成。

或者说，你需要构建一个 Agent 的小型“操作系统”：

能够自主的给一个或者多个 Agent 分配任务、调度它们执行任务、记录与检查任务完成情况、决定下一步行动，直到满足终止条件。

在这个系统中，一个典型的 “Loop” 可以表示为：

Loop Engineering 的意义就是把 Agent 系统的工作范式从单次会话推进到持续运行系统。在这里，Prompt 没有“死”，只是位置变了 — Prompt 从人工逐轮输入变成系统自动调用：每一轮的目标定义、任务模板、Skill、工具说明、验证规则、状态文件和停止条件等。

注意，Loop Engineering 不是构建简单的类似 RPA 的自动化工具。

RPA 是按固定路径执行的确定性流程。Loop Engineering 面对的是路径不确定、需要 Agent 根据验证结果动态决策的任务，在目标、工具、验证器和状态约束下持续试探与修正路径。

【一个最小 Loop 样例】

参考上面的典型架构来设计一个小型 Loop 闭环 — 一个“自动修复软件系统 CI 失败”的 Agent 系统：

这个例子里，最重要的不是核心的修复逻辑，而是这个 Loop 的架构：

• 触发器决定 Agent 什么时候应该开始执行任务

• 执行者负责执行本轮任务（分析原因并修复）

• 验证器则用来测试结果是否达到预期的目标

• 状态/记忆负责让系统不“失忆”（比如这里的重试次数）

• 停止条件负责防止系统进入无限运行，token 爆炸

所以，构建一个 Loop 不是写一个更复杂的 Agent，而是把原来需要人手动完成的几个动作，装配成一个自动推进的闭环系统。

03

区分 Agent Loop 与 Loop Engineering

如果你做过 Agent 开发，很容易联想到一个问题：

ReAct 这类智能体范式（还有反思模式、plan-then-execute模式等），不就是 Loop Engineering 吗？它们也有明显的“Loop”特征。比如我们熟知的 ReAct：

这当然也是一个 Loop，但它是最基础的 Agent Loop；但还不是完整意义上的 Loop Engineering。

• ReAct 解决的是 Agent 在一次任务中的思考行动范式。

• Loop Engineering 解决的是，如何把这样的 Agent loop 放进一个更高层次的工程系统里，让它可以被触发、被验证、并在必要时停止。

前者是 Agent 的内部运行机制，后者是围绕这个机制建立的工程治理结构。

一个更简单的判断标准是：

这个 Loop 的控制权在哪，谁来决定“继续”还是“结束”。

• 谁触发下一轮？

Agent loop 中，下一轮通常由模型在一次运行中自己推进 — 根据目标任务、历史消息、工具调用结果、子任务完成情况等。

Loop Engineering 中，下一轮可以由外部调度器、CI 失败、PR 事件、定时任务、状态机或验证器触发。

• 谁判断完成？

Agent loop 中，常常是模型自己判断“我完成了”，或者达到最大轮数、最大 token、工具调用次数上限。

Loop Engineering 中，应该是外部的验证器 / inspector / 人类的 review gate 判断它是否真的完成。

总的来说，ReAct 这样的 Agent Loop 的控制中心仍然是模型本身；而 Loop Engineering 的控制权则外移到系统层。

04

和Context/Harness Engineering 的关系

理解 Loop Engineering，最好不要孤立地看。这几年 AI 工程里的几个概念，其实是在一层一层往外扩展。

最早我们关注的是 Prompt Engineering：这一轮到底怎么问模型。

后来大家开始讨论 Context Engineering：这一轮模型应该看到什么信息，比如目标任务、代码片段、项目文档、历史消息、Skill说明等。

接着是 Harness Engineering：把 Agent 运行在一套脚手架里，包括工具、权限、沙箱、状态、日志、错误恢复和人工审批等。

现在到了 Loop Engineering，关注的问题又升级了一层：关心整个 Agent系统如何持续、自主的推进任务。

了解这个背景，其实很容易对比 Context/Harness/Loop Engineering：

• Context Engineering

  解决的是：让 Agent 知道些什么。

  主要工作：RAG 管道、记忆检索、SKILL.md、历史消息、Spec文档等。

• Harness Engineering

  解决的是：让 Agent 在什么环境里稳定的工作。

  主要工作：AGENTS.md/rules、MCP 连接器、Hooks、Worktrees、沙箱、自动化评估用例等。

• Loop Engineering

  解决的是：Agent 什么时候开始，如何判断要不要继续，什么时候停下，什么时候交还给人。

  主要工作：定时/自动触发任务、/goal 目标、终止条件、进度记录、subagent编排调度等。

Context 是 Agent 每一轮的“看到的信息”。

Harness 是 Agent 每一轮的“运行脚手架”。

Loop 是把一轮轮 Agent 执行串起来的“持续推进机制”。

三者没有替代关系，而是协作关系。Loop Engineering 把 Context与Harness Engineering 组织进一个更持续、更长距离、更自动化的闭环 Agent 系统里。

05

构建块与系统设计

Addy Osmani 在《Loop Engineering》中认为，通常一个 Loop 大体需要五个要素，再加上一个“记住事情的地方”，才能让这个 Loop 持续可靠运行。

我们用上面的自动修复测试失败的例子来说明这六个要素：

• Automations：负责触发 Loop 运行，比如定时、事件钩子、自动循环、直接设定目标（goal）等。

  在例子中，CI 失败就是这个 Loop 系统的触发信号。没有触发器，Loop 就只能是人手动执行的一次 Agent 任务。

• Worktrees：负责隔离 Agent 的工作环境。

  在例子中，Agent 生成的补丁不会直接改主工作区，而是先应用到独立的 Git worktree 里。这样多个 Agent 可以并行进行，互不污染。

• Skills：负责提供项目的额外领域知识或固化标准流程。

  在例子中，Agent 修测试前，需要知道项目怎么构建、如何测试、有哪些约束、测试验证的标准动作流程等 — 这些通常应该写进 Skill。

• Plugins / Connectors：负责连接真实的外部系统。

  在例子中，Loop 需要读取 CI 日志、访问代码仓库、打开 PR、通知团队等。这些动作都依赖 MCP 工具，把 Agent 接入 Git 等系统。

• Sub-agents：负责分工与并行，比如一个编码一个检查。

  在例子中，一个 Agent 可以负责分析失败原因和生成补丁，另一个 Agent 负责 review 补丁、检验是否真的修复 — 不让“干活”的人给自己评分。

• State / Memory：负责状态与记忆，特别是已完成事项、下一步计划等。

  在例子中，系统需要记录这次 CI 失败详情、已经尝试过的修复、测试结果、失败原因、重试次数、下一步该交给谁等，这些可用于失败后恢复。

可以看到，一个 Loop 并不只是简单的“让 Agent 多跑几轮”。你需要仔细考虑与设计这些基本要素，才能把原来“人发现问题 — 让 Agent 修 — 人检查 — 再写 Prompt”的手动循环，变成一个能自动触发、自动尝试、自动验证、自动记录，并在必要时交还给人的工程闭环。

06

构建 Loop 的工具

这些要素并不需要我们自己准备 — 类似 Claude Code、Codex 这样的自动化编码/通用 Agent 工具都已经具备绝大部分能力，大多以各种插件、Skill、Slash命令等形式存在。

下面是简单的总结：

比如可以设计一个“每周替我从 GitHub 挑选 AI 项目选题”的 Loop：

这个例子里：

• Automations 负责每周一早上自动触发

• Connectors 负责读取 GitHub 趋势项目、Star 增长数据和项目 README

• Skills 负责定义什么样的 AI 项目值得写，比如是否有工程创新、是否适合企业场景、是否有明显传播点

• Sub-agent 负责给候选项目评分，判断它是“值得深挖”“暂时观察”还是“不适合写”

• State 是inbox.md，记录候选项目、推荐理由、评分和后续处理状态

• Stop condition 是“本轮项目筛选与评分完成”。

这就把“每周手动刷 GitHub、判断项目值不值得写、再整理选题”的过程，变成了一个自动运行的 Loop。

需要注意的是：

Claude Code 和 Codex 提供的是 Loop 的一些基础设施（尚未足够完善）。真正决定 Loop 是否可靠的，仍然是你如何定义筛选标准、评分规则、状态记录和停止条件等。

07

适用性判断

那么怎样的任务适合做成 Loop？

真正适合 Loop 的任务，需要有几个特点：

它会重复发生；目标可以被清楚描述；完成标准可以被独立验证；失败成本可以被控制；上下文可以被持久化；人类愿意持续 review 和治理结果。

这些特点可以用这些问题来判断：

第一，这件事是否会稳定重复出现？

第二，完成与否是否能被测试、规则、评分器或独立的检验工具判定？

第三，任务失败的成本是否可控？

第四，任务推进中需要的上下文能否被写进 skill、状态文件、知识文件？

第五，你是否愿意为 Loop 的结果持续 review、迭代和治理？

如果这五个问题里有四个以上的答案是肯定的，Loop 往往值得做。

否则，你可能需要考虑更加可控的 Workflow、半自动化+人工辅助的流程，而不是无人值守的 Loop。

从简单到复杂，常见的 Loop 系统有：

• 定期巡检任务：比如定期检查 CI、PR、bug、监控、工单。

• 事件驱动型任务：由 webhook、告警、用户反馈等变化触发。

• 目标易收敛的任务：如围绕测试通过（测试驱动）的软件开发任务。

• 优化搜索任务：围绕某个指标不断试验与逼近、保留更优解。

08

风险与能力不足

同很多 AI 技术与工程范式一样，Loop 也不是万能的。在尝试它之前，你需要充分了解它的不足与风险。

一个自我推进的 Agent 系统最大的风险是：

高度自主的 Loop 过程带来更高的错误叠加与成本失控风险 — Loop 在放大能力的同时也会放大错误。

1. Loop 无法替你定规任务完成标准
   你必须给 AI 清晰的、可衡量的目标与终止标准。如果你自己都说不清什么算成功（比如“让文章更有深度”），只会越 “Loop” 越混乱。

2. Loop 无法替你确保环境的完全
   Loop 过程中需要连接大量工具，它们仍然需要你治理 — 越权访问、提示注入、违规写操作都是需要小心的安全风险。

3. Loop 无法替你承担操作的责任
   Loop 可以帮你自动提交 PR、生成补丁、发送邮件、甚至修改数据库，但这些操作的责任仍然需要人类承担。

4. Loop 无法替你自动控制成本
   持续迭代推进的 Agent 系统中，有很多会让 token 爆炸的地方：更长的运行链、更多的并行 subagent、反复的重试等。

5. Loop 可能带来更多的认知债务

   Loop 会替你持续产出，但你的团队如果只会看测试结果，而不去理解任务结果（比如代码设计），就会不断累积认知负债。

6. Loop 无法消灭人工瓶颈

   worktree 可以减少文件的冲突，subagent 可以提高并发，但最终能合并多少PR、能上线多少改动，仍然取决于人的 review。

总的来说，Loop Engineering 代表了 Agent 系统走向“自主持续闭环”的新工程范式。但它并不适合所有场景。是否要做 Loop，关键不在概念新不新，而在任务是否重复、目标是否清晰、结果能否验证、风险是否可控。根据自身的实际情况，多一点判断，才是更务实的做法。

END

喜欢就关注哦

动动小手点个赞

点在看最好看

公众号私信，申请加入本号交流群