Loop Engineering深度评测：8个关键问题全解析

2026-06-23阅读 0热度 0

Loop

最近AI工程领域又冒出一个新词——Loop Engineering。看起来像是又一轮概念炒作，但背后反映的痛点确实很真实：Agent还没法稳定跑完长任务，人还得一次次手动推进。那么，到底什么是Loop Engineering？它跟Prompt Engineering、Context Engineering这些老概念是什么关系？这篇文章用8个问题，把这事彻底说清楚。

相信很多人最近见过这种标题：Prompt Engineering已死，现在是Loop Engineering了。 这类说法很容易让人反感——每出一个新东西，就有人喊“XX已死”。但抛开这些噱头，我们得认真看看Loop Engineering到底在解决什么问题。本文就来梳理AI如何从“一次性任务”的范式，走向真正的“持续、自主、可靠执行任务”。

先列出8个核心问题：

为什么会出现Loop Engineering
概念与边界
区分Agent Loop与Loop Engineering
和Context/Harness Engineering的关系
构建块与系统设计
构建Loop的工具
适用性判断
风险与能力不足

01 为什么会出现Loop Engineering

Loop Engineering的出现，不是大家闲得慌造概念，而是Agent的使用方式确实走到了一个新阶段。

最初，我们写Prompt，完成问答和简单任务。
Agent出现后，开始做Context Engineering，给模型更完备的上下文环境。
再后来，为了让Agent跑得更稳，又给它套上工具、规则、记忆、沙箱、恢复机制等，这就是Harness Engineering。

现在，Agent已经能跨多步执行任务了，但问题真的解决了吗？

回想一下我们用Coding Agent的过程。比如任务：“帮我创建一个AI驱动的个人知识库系统”。接下来的过程大概率是：你给目标 → Agent写代码 → 你检查 → 发现不对 → 你补充说明 → Agent再改 → 你再检查……每一轮的“检查—纠偏—再运行”仍然要靠人手动完成。Agent的自动化价值在这里出现了断层，卡住了。

这就是Loop Engineering出现的背景：我们需要把“人手动推进Agent”的过程，变成一个系统自动推进的过程。换句话说：你（人）不再是这个Loop的一部分，你负责设计Loop本身——一个让AI能够持续、自主、可靠地完成任务的闭环系统。

这里面隐含了一个现实：模型确实越来越强，但长任务依然并不可靠。上下文腐烂、目标漂移、工具误用、错误累积等问题仍然常见。所以我们需要用工程的方法，设计一个能驱动Agent向目标持续迭代的闭环。

02 概念与边界

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

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

或者说，你需要构建一个Agent的小型“操作系统”：能够自主地给一个或多个Agent分配任务、调度它们执行、记录与检查任务完成情况、决定下一步行动，直到满足终止条件。

一个典型的Loop可以表示为：

Loop Engineering的意义，就是把Agent系统的工作范式从单次会话推进到持续运行系统。在这里，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 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大体需要五个要素，再加上一个“记住事情的地方”，才能持续可靠运行。

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

Automations：负责触发Loop运行，比如定时、事件钩子、自动循环、直接设定目标（goal）等。在例子中，CI失败就是触发信号。
Worktrees：负责隔离Agent的工作环境。在例子中，Agent生成的补丁不会直接改主工作区，而是先应用到独立的Git worktree里，这样多个Agent可以并行，互不污染。
Skills：负责提供项目的额外领域知识或固化标准流程。在例子中，Agent修测试前需要知道项目怎么构建、如何测试、有哪些约束等，这些写进Skill。
Plugins / Connectors：负责连接真实的外部系统。在例子中，需要读取CI日志、访问代码仓库、打开PR、通知团队等，依赖MCP工具接入Git等系统。
Sub-agents：负责分工与并行，比如一个编码一个检查。在例子中，一个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？真正适合的任务有几个特点：

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

用这五个问题来判断：

这件事是否会稳定重复出现？
完成与否是否能被测试、规则、评分器或独立的检验工具判定？
任务失败的成本是否可控？
任务推进中需要的上下文能否被写进skill、状态文件、知识文件？
你是否愿意为Loop的结果持续review、迭代和治理？

如果四个以上答案是肯定的，Loop往往值得做。否则，你可能需要考虑更可控的Workflow、半自动化+人工辅助的流程，而不是无人值守的Loop。

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

定期巡检任务：定期检查CI、PR、bug、监控、工单。
事件驱动型任务：由webhook、告警、用户反馈等变化触发。
目标易收敛的任务：如围绕测试通过的软件开发任务。
优化搜索任务：围绕某个指标不断试验与逼近，保留更优解。

08 风险与能力不足

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

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

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

Loop无法替你定规任务完成标准
你必须给AI清晰的、可衡量的目标与终止标准。如果自己都说不清什么算成功（比如“让文章更有深度”），只会越Loop越混乱。
Loop无法替你确保环境的安全
Loop过程中需要连接大量工具，它们仍然需要你治理——越权访问、提示注入、违规写操作都是需要小心的安全风险。
Loop无法替你承担操作的责任
Loop可以帮你自动提交PR、生成补丁、发送邮件、甚至修改数据库，但这些操作的责任仍然需要人类承担。
Loop无法替你自动控制成本
持续迭代推进的Agent系统中，有很多地方会让token爆炸：更长的运行链、更多的并行subagent、反复的重试等。
Loop可能带来更多的认知债务
Loop会替你持续产出，但如果团队只会看测试结果，而不去理解任务结果（比如代码设计），就会不断累积认知负债。
Loop无法消灭人工瓶颈
worktree可以减少文件冲突，subagent可以提高并发，但最终能合并多少PR、能上线多少改动，仍然取决于人的review。

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