Loop Engineering 让 Agent 把事做完

我把 Loop Engineering 拆成一套能直接拿去用的 Agent 完成任务模板。

我前阵子一直在折腾 Agent 工作流，心里憋着一股火。Prompt 写得挺像样，工具也接上了，甚至上下文我都喂得很讲究，可结果还是老样子：它会开始做，也会很热情地汇报进展，但一到真正复杂的任务，就开始飘。要么第一轮输出看着对，第二轮就把自己带沟里；要么它知道“该做什么”，却不知道“做到什么程度算结束”。最烦的是，它还特别会装作已经完成了。你让它修一个项目，它给你一堆看起来很像回事的中间产物，最后留下一个半成品，像是把“努力”当成了交付。

我后来才意识到，问题不只是 Prompt，也不只是 Context。Prompt 解决的是“怎么说”，Context Engineering 解决的是“该知道什么”，但真正让长任务落地的，是循环本身：执行、检查、修正、再执行。也就是这篇知乎文章里讲的 Loop Engineering。原文把它和 Prompt Engineering、Context Engineering 放在一条线上讲，我觉得这个拆法挺对味。因为很多人现在卡住的，不是不会让 AI 开始干活，而是不会让它把活干完。

这篇文章的价值，不在于又发明了一个新词，而在于它把一个很烦但很真实的问题说透了：当任务变复杂，Agent 不能只靠一次性指令，而要靠迭代式执行机制。你得让它自己看结果、自己发现偏差、自己修正路径。说白了，Loop Engineering 不是“让 AI 更聪明”，而是“让 AI 更像一个会收尾的干活的人”。

Prompt 只能起跑，不能冲线

但这个阶段的局限性也很明显：适合相对明确的任务（写文案、总结文章、提取要点），一旦任务变复杂，Prompt就不够用了。

这句话我太熟了。Prompt Engineering 最好用的时候，就是任务边界很清楚：写个摘要、改个标题、提炼要点、生成一段代码片段。输入和输出都比较明确，模型只要照着做，通常不会太离谱。但一旦任务开始有状态、有依赖、有中间判断，单次 Prompt 就开始发虚。它没有办法天然知道“这一步做完之后，下一步该怎么接”。

我自己最早踩坑是在做一个文档整理 Agent 的时候。第一轮我给它一个很完整的指令：读取资料、分类、输出结构化结果。结果它每次都能给我一个“像样”的答案，但分类标准总在变，前后不一致，最后你根本没法把它接进后续流程。那时候我还以为是 Prompt 不够细，后来发现不是细不细的问题，是一次性指令本来就不适合这种多阶段任务。

What this actually means is：如果任务需要多步推进，你不能只问“请给我答案”，而要设计“每一步之后怎么判断是否继续”。Prompt 的职责只是启动，真正决定交付质量的是循环控制。

How to apply it：先把任务拆成几类，看看哪些是单轮可完成的，哪些必须多轮收敛。单轮任务继续用 Prompt；多轮任务直接别硬扛，改成循环式流程。你可以先写出三个最基本的问题：现在完成了吗？如果没完成，差在哪？下一轮应该改什么？

• 适合单轮：摘要、改写、信息提取、固定格式生成。
• 适合循环：代码修复、研究归纳、复杂规划、跨文件编辑、长任务执行。

Context Engineering 负责喂对信息，但还不够

当任务复杂之后，AI需要知道的更多。它要看的是项目背景、代码结构、目标指令、历史决策、团队规范……把哪些信息放进模型上下文里，是这个阶段要解决的问题。

这段其实讲的是我最认可的一层：上下文不是越多越好，而是越对越好。很多人一上来就把所有材料塞给模型，结果模型看得很累，输出也很散。Context Engineering 的关键不是“填满窗口”，而是把模型做判断真正需要的信息放进去。项目背景、历史决策、代码结构、团队规范，这些东西不是装饰品，它们决定模型会不会在错误的轨道上越跑越远。

我在做代码审查助手时就吃过这个亏。最开始我只给它 diff，让它评审。结果它的建议很像一个刚进项目的人，语气很认真，判断很自信，但经常忽略仓库里已有的约定。后来我把目录结构、相关模块的历史改动、lint 规则、测试约束一起喂进去，它的建议才开始像“真在这个项目里干过活”。

但这里有个坑：Context Engineering 只能解决“做对”，不能保证“做完”。你给它更好的背景，它更容易判断方向；可如果任务本身需要反复试错，单次上下文再漂亮也没用。模型还是会卡在中途，或者在某个局部最优里停住。

What this actually means is：上下文负责减少误判，循环负责推动收敛。前者让它少走歪路，后者让它别半路停工。两者不是替代关系，是配合关系。

How to apply it：我建议把上下文分成三层来准备。第一层是任务目标，第二层是当前状态，第三层是约束和历史。别把所有资料平铺进去，最好按“决策优先级”组织。模型先看目标，再看状态，最后看约束。这样它在每轮循环里都能快速定位自己现在在哪。

• 目标：最终要交付什么。
• 状态：当前已经完成了什么。
• 约束：不能违反什么规则。

Loop Engineering 的核心不是循环，是收敛

Context Engineering让AI"做对"，Loop Engineering解决的是"做完成"。

这句是整篇文章最值钱的地方。因为“循环”这个词很容易让人理解偏了，觉得就是多跑几轮而已。不是。Loop Engineering 真正关注的不是“多跑”，而是“怎么从不确定状态逐步逼近完成态”。如果没有收敛机制，循环只会变成重复劳动；如果有收敛机制，每一轮都会减少不确定性。

我见过太多 Agent 流程死在“继续执行”这一步。模型每轮都在产出，但没人定义什么叫进步。于是它会在同一个错误方向上越修越远，或者因为局部结果看起来不错，就误以为全局已经完成。这个时候你再给它更长的上下文，也没用。因为问题不是信息不够，而是缺少一个明确的停止条件和校验标准。

What this actually means is：Loop 不是让模型一直干，而是让每一轮都带着检查点。你得规定，输出必须经过验证，验证不过就回滚或修正，验证通过才进入下一步。没有这个机制，所谓“Agent”很容易退化成“自动复读机”。

How to apply it：给每个循环加三个固定动作：执行、检查、修正。执行负责产生结果，检查负责判断结果是否达标，修正负责针对偏差重新尝试。你可以把检查写成规则，也可以写成另一轮模型判断，但一定要有明确标准。别让模型自己宣布自己完成了，这事儿我已经被坑过太多次了。

如果你做的是代码类任务，我建议检查至少包含三项：语法是否正确、测试是否通过、结果是否符合目标。如果你做的是研究类任务，检查至少包含：信息来源是否可靠、结论是否和材料一致、有没有遗漏关键反例。

失败后修改，比一把梭更像真实工作流

Agent处理长任务时，需要反复执行、自行检查成果、失败后修改、试错了积累经验。

这句话听起来很朴素，但它其实点出了长任务最真实的样子。现实里的工作从来不是“一次写对”。你写代码会报错，改文档会漏段落，做方案会被打回，整理数据会发现字段不一致。Agent 如果想真的像一个能干活的系统，就不能只会生成，还得会失败、会修正、会记住问题。

我自己最有感的是做自动化测试修复的时候。第一轮模型经常会给出一个看起来合理的补丁，但跑完测试还是挂。以前我会很烦，觉得它没理解问题。后来我改成让它先看失败日志，再定位失败点，再提出修复方案，最后才动手改代码。效果立刻不一样了。因为它不是在空中猜，而是在错误信息里迭代。

What this actually means is：失败不是流程外的意外，而是流程的一部分。你要把失败当成下一轮输入，而不是当成流程结束。只要失败信息能进入下一轮，Agent 就会越来越接近正确答案。

How to apply it：把失败类型分门别类。比如语法错误、依赖错误、逻辑错误、格式错误、目标偏差。不同失败对应不同修正策略。这样 Agent 不会每次都从头乱试，而是能针对性地调整。

• 语法错：先修最小可运行版本。
• 逻辑错：回看目标和约束。
• 格式错：强化输出模板。
• 目标偏差：重新注入任务定义。

别让 Agent 自己猜完成标准

信息给少了，AI缺少判断依据；信息给错了，它可能在错误的方向上越走越远；信息给多了，它又抓不住重点。

这段话其实也能拿来解释为什么很多 Agent 总是“差一点”。不是它不会做，而是它不知道什么叫“做到位”。完成标准如果不清楚，模型就会自己发明标准，而它发明出来的标准通常不靠谱。它会偏爱看起来完整、语言漂亮、结构工整的结果，但未必真能交付。

我以前写过一个内容生成流程，最开始只要求“输出一篇完整文章”。结果模型每次都能交，但总有一种“已经写完了但没说到点上”的感觉。后来我把完成标准拆成了几个可验证项：是否包含目标主题、是否覆盖核心观点、是否提供可执行步骤、是否引用了指定来源。加上这些后，结果立刻稳定很多。

What this actually means is：完成标准要显式化，而且最好是可检查的。不要只写“请认真完成”，这种话对模型没有约束力。你得告诉它，什么算完成，什么算未完成，什么情况要继续循环。

How to apply it：每个 Agent 任务都配一个 checklist。这个 checklist 不需要长，但必须具体。比如“包含 3 个步骤”“引用 2 个来源”“输出可直接复制的模板”“测试通过后再结束”。只要标准能被检查，循环就有了方向。

我特别建议把“完成”和“满意”分开。模型可能觉得自己已经很努力了，但你的标准不是努力，是交付。别心软，交付标准要硬一点，不然流程会一直拖。

把循环写成流程，不要写成愿望

如果只看概念，Loop Engineering 很容易被讲成一句很空的话：让 AI 反复做、反复改、直到完成。可真正落地时，你需要的是流程，而不是愿望。流程意味着每一步都有输入、输出、判断、转移条件。没有这些，循环只是一个漂亮的口号。

我现在更愿意把它理解成四个固定件：目标、状态、动作、判定。目标决定方向，状态告诉你现在在哪，动作负责推进，判定决定要不要继续。只要这四个件齐了，Agent 才能从“会做”变成“做完”。

这也是我觉得这篇知乎文章有用的地方。它没有把 Loop Engineering 说成什么神秘能力，而是把它放回工程问题里：怎么组织一套能反复执行、能自我修正、能最终收敛的机制。说白了，这就是把“聪明”变成“可交付”。

How to apply it：你可以先从一个最小闭环开始，不要一上来就搞复杂架构。先做一个“生成-检查-修正”的三段式流程，跑通之后再加记忆、加工具、加多轮分支。很多人失败不是因为想得不够大，而是因为一开始就把系统做得太花，最后谁也不知道哪里出了问题。

你可以直接拿去用的模板

下面这个模板我建议你直接复制，然后按自己的任务改。它的重点不是文风，而是结构：目标、上下文、执行、检查、修正、停止条件，全都放进去。你可以把它用在代码 Agent、研究 Agent、写作 Agent，甚至是内部自动化流程里。

# Loop Engineering Agent Template

## 任务目标
你要完成的最终结果是：
- [写清楚最终交付物]

## 当前上下文
你现在已知的信息包括：
- 项目背景：
- 当前状态：
- 相关文件/资料：
- 约束条件：
- 历史决策：

## 执行规则
1. 先阅读任务目标和上下文。
2. 制定当前轮次的最小可执行计划。
3. 执行计划，输出结果。
4. 自检结果是否满足完成标准。
5. 如果未满足，说明失败原因并修正。
6. 重复 3-5，直到满足停止条件。

## 完成标准
只有同时满足以下条件，才算完成：
- [条件 1]
- [条件 2]
- [条件 3]

## 失败分类与修正策略
- 如果是格式错误：修正输出结构。
- 如果是逻辑错误：回到目标和约束重新判断。
- 如果是信息不足：请求补充上下文或暂停执行。
- 如果是测试失败：根据失败日志定位问题并重试。

## 每轮输出格式
### 当前轮次
- 轮次编号：
- 当前动作：
- 产出结果：
- 自检结论：
- 是否继续：是 / 否
- 下一步计划：

## 停止条件
满足以下任一条件时停止：
- 所有完成标准通过。
- 连续 [N] 轮没有实质进展。
- 缺少关键上下文，无法继续。
- 出现不可恢复错误。

## 最终输出
请输出：
1. 最终结果
2. 完成情况说明
3. 仍然存在的风险或未解决问题

我建议你在这个模板外面再加一层“检查器”。如果是代码任务，就让检查器跑测试；如果是写作任务，就让检查器查结构和事实；如果是研究任务，就让检查器核对引用和结论。这样循环才不会只停留在“模型自评”。

另外，别忘了给循环设置上限。无限循环听起来很优雅，实际上就是浪费 token 和时间。你应该明确告诉系统：最多跑几轮，没收敛就停下来，转人工或转更强的工具。这个边界非常重要，不然系统会把“坚持”误解成“死磕”。

如果你想看原文，可以从这里开始：知乎文章《全网爆火的Loop到底是什么？》。我这篇是基于原文思路做的工程化拆解，很多表达和模板是我自己整理的，方便你直接拿去改进自己的 Agent 流程。

我再补一个相关参考：OpenAI Agents 文档、Anthropic Research，还有 LangChain。它们都在不同层面说明了一件事：长任务不是靠一次回答完成的，而是靠可控的循环推进。