Loop Engineering 爆火：Prompt 工程没有死，AI Agent 正在进入“循环工程”时代

2026年6月14日内容管家

编程开发 AI领域评论6字数 3621阅读12分4秒阅读模式

摘要Loop Engineering 正在成为 AI Agent 圈的新关键词。它不是简单让模型多跑几轮，而是围绕目标、工具、裁判、记忆、预算和停止条件设计一个可验证的循环系统。本文从...

Loop Engineering AI Agent 循环工程示意图：目标、计划、执行、观察、反思、记忆、裁判与预算控制闭环 — Loop Engineering 配图：AI Agent 围绕目标、工具、观察、裁判、记忆和预算控制形成可验证的执行闭环。

这两天，我明显感觉到“Loop Engineering（循环工程）”正在 AI 编程圈升温。围绕 Claude Code、Codex、Fable 5、/goal、/loop 等关键词，很多讨论都指向同一个变化：过去使用 AI，重点是写好一个 Prompt；现在使用 Agent，重点正在变成设计一个能持续执行、验证、修正、记忆并最终停止的循环。

我的判断是：Prompt Engineering 并没有死亡。更准确地说，Prompt 正在从“每一步都由人类手动输入的指令”，升级为“循环系统中的目标、规则、边界、验收标准和工具说明”。真正发生变化的，不是语言不重要了，而是优化对象从单次对话，转向了整个 Agent 运行系统。

什么是 Loop Engineering？

Loop Engineering 可以理解为：设计 AI Agent 的控制循环，让它围绕一个目标反复完成“计划、行动、观察、评估、修正、记录、继续或停止”的过程。一个典型 Agent Loop 大致长这样：

Goal：明确目标、交付物、边界和完成条件。
Plan：拆分任务，决定下一步做什么。
Act：调用工具，例如读写文件、运行测试、搜索资料、执行命令。
Observe：读取工具输出、错误日志、测试结果、页面截图或代码差异。
Evaluate：用测试、规则、独立模型或人工验收判断是否合格。
Memory：把失败原因、关键决策、当前状态写入笔记或项目文件，避免下一轮忘记。
Repeat / Stop：不合格就继续循环，合格或达到预算上限就停止。

我喜欢用一个“把 AI 关进厨房做红烧肉”的例子来解释它：你不再每一轮都站在门口提醒它“再炖久一点、盐少了、重做”，而是提前写清楚今晚八点要交付什么、什么味道算及格、谁来验收、最多能试几轮。AI 在厨房里自己试错、自己记录、自己修正，直到达到验收标准才把结果端出来。

为什么 Loop 会在 2026 年突然被反复讨论？

Loop 并不是全新的概念。早在 ReAct 论文中，研究者就已经把 Reasoning 与 Acting 结合起来，让语言模型在推理和行动之间交替，借助外部工具降低幻觉和错误传播；Reflexion 则进一步提出让语言 Agent 通过文本反馈和记忆缓冲区从错误中学习，而不是直接更新模型权重。

真正的新变化在于：这些研究范式正在进入开发者日常工具。Claude Code 官方文档中的 /goal 可以设置完成条件，让 Claude 在每个 turn 之后由一个更小更快的模型判断条件是否满足；如果没有满足，就继续下一轮，而不是把控制权还给用户。Claude Code 的 /loop 与计划任务则支持按间隔重复执行 Prompt，用来轮询部署状态、看护 PR 或处理长时间任务。

OpenAI 也在 Codex 长任务文章中把这个趋势说得很直白：长时间软件任务的关键不只是一个巨大 Prompt，而是 Agent 所处的循环。Codex 的循环大致包括：计划、编辑代码、运行测试/构建/lint、观察结果、修复失败、更新状态，然后重复。

阶段	优化对象	典型问题	核心能力
Prompt Engineering	单次模型调用	怎么把一句话写清楚	表达、约束、示例、格式
Context Engineering	模型每次看到什么上下文	怎么不丢关键信息、不污染上下文	压缩、检索、记忆、文件选择
Harness Engineering	Agent 运行环境	工具怎么调、权限怎么控、日志怎么留	沙箱、工具层、权限、可观测性
Loop Engineering	多轮执行闭环	如何持续推进、判断完成、避免空转	目标、验收、重试、预算、停止条件

Loop 不是“自动多问几遍”，而是一个系统工程

很多人听到 Loop，第一反应是“这不就是 ReAct 吗？”或者“这不就是 Agent 吗？”这个判断有一半是对的：Agent 本来就离不开循环。但 Loop Engineering 强调的是把循环当作可设计、可调试、可复用的工程对象，而不是任由模型无限自嗨。

一个真正可用的 Loop，至少要包含五个关键组件。

1. 目标层：不是一句愿望，而是可验收的完成条件

“帮我重构这个项目”不是好目标；“把 auth 模块迁移到新 API，所有调用点编译通过，test/auth 全部通过，且不得修改 payment 模块”才接近可执行目标。Claude Code 的 /goal 文档也明确建议使用可验证的结束状态，例如测试通过、构建退出码为 0、文件数量达标或队列清空。

2. 执行层：让 Agent 有真实环境反馈

Agent 不能只靠自己想象进展。Anthropic 在“Building Effective Agents”中强调，Agent 执行时需要从环境中获得 ground truth，例如工具调用结果、代码执行结果、测试输出，并在必要时暂停请求人工反馈。没有真实反馈的循环，本质上只是更长的幻觉。

3. 裁判层：结果不能只由干活的模型自己说了算

我认为“独立裁判”是 Loop 能不能真正落地的关键。Anthropic 的 evaluator-optimizer workflow 就是一个模型生成结果，另一个模型提供评估和反馈，并在循环中反复优化。实际开发中，裁判最好优先使用确定性检查：单元测试、类型检查、lint、构建、E2E 测试、安全扫描、快照对比。LLM 评审可以作为补充，但不能替代硬指标。

4. 记忆层：循环必须带着笔记前进

很多失败的 Agent Loop 并不是模型完全不会做，而是它在第 8 轮忘了第 2 轮已经踩过的坑。Anthropic 在 Context Engineering 文章里提到，长时间 Agent 需要 compaction、structured note-taking 和 multi-agent architectures；其中结构化笔记能把进度、依赖、未解决 bug、关键决策保存在上下文窗口之外，再在后续步骤拉回。

所以我更倾向于给 Loop 配一个随任务存在的笔记系统。每一轮的失败、修正、已完成事项、下一步约束，都应该沉淀为临时任务笔记。对于编程 Agent 来说，这份笔记可以是 GOAL.md、PLAN.md、STATUS.md、DECISIONS.md 或 issue checklist。

5. 预算层：没有预算的 Loop 就是 Token 黑洞

我最建议先算清楚的，是成本：Loop 会不会把 Token 烧爆？答案是会，尤其是目标模糊、上下文太大、缺少停止条件、裁判不可靠时。Simon Willison 在体验 Claude Fable 5 时也记录到，强模型在复杂任务中非常能“持续推进”，但成本和速度同样是显著变量。

因此，Loop 的预算设计应该写进规则里：最多几轮、最多多少 Token、失败几次后暂停、哪些操作必须人工确认、哪些目录禁止改动、每轮结束必须输出当前花费和未完成事项。没有预算的循环，不是自动化，是失控。

Prompt 工程真的被取代了吗？

没有。Prompt 只是从“人类每轮喂一句话”，变成了“系统里的规格说明”。Loop 时代更需要 Prompt，只是 Prompt 的位置变了：

目标 Prompt：定义要完成什么，不要做什么。
工具 Prompt：告诉 Agent 工具什么时候能用、返回值如何理解、失败时如何处理。
裁判 Prompt：定义合格线、扣分项、必须阻断的错误。
记忆 Prompt：规定什么信息必须写入笔记，什么信息可以丢弃。
停止 Prompt：明确何时继续、何时暂停、何时交给人类。

所以，Prompt Engineering 没有消失，而是被拆进了 Context、Harness、Evaluator、Memory、Budget 这些更具体的工程模块里。以后真正稀缺的能力，不是写一段“神级提示词”，而是把目标、工具、数据、验证和权限组合成一个不会乱跑的系统。

Loop 的效率提升在哪里？

Loop 真正有价值的地方，是把人从“AI 保姆”变成“作业批改者”。过去你要一轮轮盯着 Agent：这里错了、那里没测、再试一次、日志看一下。Loop 设计得好之后，Agent 可以自己完成大量重复性修正：运行测试，看到失败，修复，再运行，再写状态。

对编程开发来说，最适合 Loop 的场景通常有这些特点：

任务目标清晰，有明确验收标准。
可以用测试、构建、lint 或脚本自动判断成败。
失败反馈能直接指导下一轮修复。
改动范围可控，最好在独立分支、worktree 或沙箱中进行。
即使失败，也不会造成生产数据、密钥、账单或用户资产损失。

典型例子包括：修复测试失败、批量升级 API、迁移小模块、清理 lint、补文档、整理 issue、生成并校验脚手架、把大文件拆成小模块等。它们的共同点是“完成条件可测”。

什么时候不要用 Loop？

Loop 不是越多越好。我最担心的不是它不够自动，而是确定性、Token 黑盒和垃圾代码批量化。2026 年一篇关于 Coding Agents 的研究就专门讨论了“越界行动”：当用户只是提出一个良性任务时，具备 shell、文件和网络权限的编码 Agent 可能做出超出授权范围的删除、重写或配置变更。

不适合直接 Loop 的任务	原因	更稳妥做法
需求本身还不清楚	Agent 会替你脑补需求	先做需求澄清和人工确认
生产环境操作	错误成本高	只允许生成计划，执行需人工审批
安全、支付、权限模块	小错误可能造成大事故	增加安全评审、测试和最小权限
大规模重构	上下文漂移和连锁错误明显	拆成小里程碑，每段单独验收
没有测试的代码库	缺少客观裁判	先补测试，再让 Agent 循环修复

企业落地：让流程接管，而不是让模型撒野

真正适合企业的 Loop，不应该是“让 Agent 自己无限跑”，而应该是“让代码和流程接管循环”。换句话说，模型负责提出方案和执行局部操作，流程负责决定它能不能继续。

一个可落地的企业 Agent Loop 至少应该有这些约束：

权限边界：默认只读，写操作分级授权，删除、迁移、发版必须人工批准。
环境隔离：使用沙箱、临时分支、临时数据库、worktree，不直接碰主干和生产。
确定性裁判：优先使用测试、构建、lint、安全扫描和脚本判断，LLM 评审只做辅助。
预算上限：每个任务设置最大轮数、最大耗时、最大 Token 和失败次数。
完整日志：记录每轮输入、工具调用、输出、错误、修复动作和成本。
可回放：失败后能复盘为什么跑偏，而不是只看到一个最终答案。
人工关口：涉及架构、业务规则、安全和上线时，必须有人验收。

一个实用的 Loop 任务模板

如果要在 Claude Code、Codex 或其他 Agent 工具里尝试 Loop，可以把目标写成下面这种结构，而不是只写一句“帮我修好”。

目标：修复 auth 模块中导致登录失败的测试问题。

范围：只允许修改 src/auth、tests/auth 和必要的类型定义；不得修改 payment、billing、deployment 配置。

验收：npm test -- tests/auth 退出码为 0；npm run lint 退出码为 0；git diff 中不得出现无关文件。

循环规则：每轮先说明计划，再改代码，再运行测试；测试失败必须先修复失败项，不得绕过测试；最多 8 轮或 60 分钟，超出则暂停并汇报。

记忆：维护 STATUS.md，记录已尝试方案、失败原因、关键决策和下一步。

停止：验收全部通过后停止；如果连续 3 轮同类失败，停止并请求人工介入。

Loop Engineering 的真正门槛

Loop 的门槛不在于“会不会让 AI 多跑几轮”，而在于能不能设计出一个有效循环。有效循环必须让每一轮都比上一轮更接近目标，而不是更会自圆其说。

这也是为什么“什么都不懂的小白”直接开 Loop 反而危险。一个没有工程判断的人，很难知道 Agent 做出的架构是不是合理、测试是不是偷懒、修复是不是绕过问题、权限是不是越界。Loop 会放大模型能力，也会放大人的无知。

对高手来说，Loop 是杠杆；对没有目标、没有边界、没有验收线的人来说，Loop 可能只是 Token 消耗机。

结论：Loop 是趋势，但不是神话

Loop Engineering 的流行，说明 AI Agent 的使用方式正在从“聊天式辅助”进入“流程式协作”。这确实是一个重要变化：人不再每一步都喂 Prompt，而是设计目标、工具、记忆、裁判和预算，让 Agent 在受控环境中自动推进。

但它不是魔法，也不是对 Prompt Engineering 的彻底替代。真正可靠的 Loop，背后仍然是清晰需求、上下文管理、工具设计、测试体系、权限控制和成本约束。未来优秀的 AI 开发者，可能不只是“会写提示词的人”，而是能把 AI 放进正确流程里，让它高效工作、及时停止、出了问题也能被追责的人。

一句话总结：Prompt 是语言，Loop 是系统。AI Agent 的下一阶段，不是少写 Prompt，而是把 Prompt 写进一个可验证、可记忆、可停止的工程闭环里。