摘要

Loop engineering 是 2026 年 6 月前后在 AI 开发者社区，尤其是 AI 辅助编码圈里快速流行起来的一个新说法。它不是又一个提示词技巧，而是一个更高层级的工作方式转变：开发者不再亲自逐一输入提示，而是设计一个自治的循环系统，让代理（agent）根据高层目标自动迭代、执行、验证和自我修正，直到完成任务。

如果说 prompt engineering 的核心问题是“我该怎样问 AI”，context engineering 的核心问题是“我该给 AI 什么背景”，那么 loop engineering 的核心问题就是：

我该如何设计一个系统，让 AI 在目标、上下文、工具、反馈、约束和退出条件之间反复运转，并且越跑越接近可交付结果？

这件事在编程领域最先爆发，并不偶然。编程天然有文件系统、版本控制、测试、lint、构建、CI、日志、issue、PR、review 等可机器读取的反馈面。AI 不再只是“生成代码”，而是可以在一个工程环境里走完“理解代码库 -> 制定计划 -> 修改文件 -> 运行测试 -> 读取错误 -> 修复 -> 提交变更”的闭环。

为什么不是 Prompt Engineering 了

早期 AI 编程的主流姿势是提示词驱动。你告诉模型“帮我写一个函数”“帮我解释这段报错”“帮我重构这个文件”，模型返回一段答案。开发者把答案复制到编辑器里，手动运行测试，再把错误贴回去。这个流程本质上仍是人类在操作循环，AI 只是循环中的一个函数调用。

Agentic coding 工具改变了这个边界。以 Claude Code 为例，官方文档把它描述为一个能读取代码库、编辑文件、运行命令并接入开发工具的 agentic coding tool。它可以处理跨文件修改、运行测试、创建提交和 PR，还能通过 MCP、项目指令、skills、hooks、多个 agent 和定时任务接入更完整的工程环境。换句话说，AI 已经从“回答者”变成了“循环执行者”。

学术界也开始用更清晰的系统语言描述这件事。2026 年 4 月的技术报告《Dive into Claude Code》指出，Claude Code 这类系统的核心其实是一个简单 while-loop：调用模型、运行工具、再重复；真正复杂的部分在 loop 周围，包括权限系统、上下文压缩、扩展机制、子代理、会话存储等工程设施。这个判断非常关键：模型能力当然重要，但决定它能不能稳定工作的，往往是 loop 外围的工程设计。

所以，prompt engineering 没有消失，但它降级成了 loop engineering 的一个组件。一个成熟的 loop 里仍然需要好提示词，只是提示词不再单独承担全部责任。它要和状态管理、工具权限、测试反馈、上下文裁剪、失败恢复、成本控制共同工作。

Loop Engineering 的定义

我会把 loop engineering 定义为：

围绕 AI agent 的反复执行过程，设计目标、状态、上下文、工具、反馈、约束、评估和退出机制，使代理能根据高层目标自动迭代、执行、验证和自我修正，直到完成任务，并把过程控制在工程上可接受的范围内。

它关心的不是单次输出是否漂亮，而是整个循环是否可靠：

  • 目标是否足够明确，能被 agent 拆成可执行步骤。
  • 上下文是否足够完整，又不会把无关信息塞满窗口。
  • 工具是否够用，并且有权限边界。
  • 反馈是否机器可读，比如测试失败、lint 报错、截图差异、构建日志、review 结论。
  • 状态是否可追踪，比如计划、todo、diff、会话记录、已验证项。
  • 退出条件是否清楚，比如测试通过、PR 创建、人工验收通过、成本达到上限、连续失败次数过多。
  • 失败后是否能恢复，比如回滚、换模型、缩小任务、重新规划、请求人工决策。

一个没有退出条件的 loop 只是自动化赌博；一个没有验证器的 loop 只是更快地产生幻觉；一个没有版本控制的 loop 只是更高效地制造不可解释的改动。

一个最小 Loop 长什么样

最小的 AI 编程 loop 可以写成这样：

1
2
3
4
5
6
7
8
9

输入目标
  -> 读取项目上下文
  -> 生成计划
  -> 执行一个小步骤
  -> 运行验证命令
  -> 读取结果
  -> 如果失败，诊断并修复
  -> 如果通过，记录证据并进入下一步
  -> 如果全部完成，输出总结并等待人工 review

这看起来简单，但每一步都可以被工程化。

“读取项目上下文”不是把整个仓库塞给模型，而是读取 README、AGENTS.md、架构文档、相关文件、测试入口和近期 diff。“生成计划”不是写一份空泛列表，而是明确哪些文件要读、哪些行为要改、哪些验证命令能证明完成。“执行一个小步骤”意味着每次改动有边界，便于 review 和回滚。“运行验证命令”要优先使用项目已有测试，而不是让模型自称“逻辑正确”。“记录证据”则让人类接手时知道它到底验证了什么，没验证什么。

这就是 loop engineering 和“让 AI 自己一直跑”的区别：前者是在设计可控系统，后者只是把人工焦虑外包给模型。

2026 年为什么突然流行

Loop engineering 的流行，是几个趋势叠加后的结果。

第一，coding agent 的产品能力到了临界点。Claude Code、Codex、Cursor、Copilot、OpenCode 等工具都在从“补全和聊天”走向“多步任务执行”。当工具可以读文件、改文件、跑命令、接 CI、开 PR、使用浏览器和外部系统时，开发者自然开始思考：怎么让它们不只是响应，而是持续工作？

第二，开发者已经体验到“提示词驱动”的上限。Vibe coding 让原型开发变快，但也暴露出问题：上下文漂移、错误堆积、重复返工、测试缺失、代码质量不稳定。社区开始意识到，下一阶段的关键不是写出更玄学的 prompt，而是把 prompt 放进一个带验证和约束的工作流。

第三，社区出现了更激进的循环实践。Geoffrey Huntley 的 Ralph/Ralph Wiggum loop 就是典型例子：把 AI 的输出和错误不断反馈回自身，反复运行，直到软件接近正确结果。媒体报道里提到，他曾让 Claude 在一个 bash loop 中长时间运行来生成项目。这个案例有夸张、戏剧化的一面，但它确实抓住了 2026 年开发者讨论的核心问题：当 agent 可以连续运行很久时，真正稀缺的能力变成了如何设计循环、约束循环、审计循环。

第四，研究系统也开始把 loop、memory、skill 作为 agent harness 的基础部件。比如 GEMS 把 Agent Loop、Agent Memory、Agent Skill 作为多模态生成系统的三大组件；PARNESS 则强调不同研究场景需要不同形状的 workflow loop，而不是固定的线性管道。这说明“循环”不只是编码工具的 UI 现象，而是 agent 系统架构正在形成的共同抽象。

Loop 的七个部件

一个实用的工程 loop 通常有七个部件。

1. 目标：让 AI 知道什么叫完成

目标不是一句“优化这个项目”。好的目标应该包含结果、边界和验收方式。

差的目标：

1

帮我重构登录模块。

更好的目标：

1

重构登录模块，保持现有 API 行为不变；移除重复的 token 校验逻辑；新增或更新测试覆盖成功登录、密码错误、token 过期三种情况；最后运行 npm test -- auth 并总结改动风险。

loop 能否可靠，很大程度取决于目标能否被验证。如果目标无法验证，AI 就只能用语言说服你。

2. 状态：让循环知道自己在哪里

状态包括当前计划、已完成步骤、失败记录、已读文件、关键决策、未验证风险。没有状态，loop 会反复探索同一片区域，或者在上下文压缩后忘记为什么做某个改动。

Agentic coding manifest 的研究也说明，CLAUDE.md 这类配置文件正在成为 agent 获取项目身份、操作规则和技术上下文的重要载体。它们把“每次都要手动解释”的内容变成持久状态，是 loop engineering 的地基之一。

3. 上下文：让模型看见必要事实

上下文不是越多越好。好的上下文应该分层：

  • 项目级：架构、命令、编码规范、禁止事项。
  • 任务级：需求、相关 issue、验收标准。
  • 文件级：当前要修改的代码、测试、接口定义。
  • 历史级：之前失败过什么、为什么放弃某条路线。

上下文工程和 loop engineering 在这里交汇。前者解决“给模型什么信息”，后者解决“在循环的哪个阶段给、给多少、何时更新、何时压缩”。

4. 工具：让 AI 能行动

没有工具的模型只能建议，有工具的 agent 才能执行。编程 loop 常见工具包括：

  • 文件读写。
  • 代码搜索。
  • shell 命令。
  • 测试和构建。
  • git diff、commit、branch、PR。
  • 浏览器或截图工具。
  • issue、文档、日志、监控、数据库只读查询。

但工具不是越开放越好。能删除文件、推送代码、改数据库、访问生产凭证的工具，都必须有权限边界和人工确认。loop engineering 的重要工作之一，就是给 agent 配一套“足够完成任务，但不至于毁掉环境”的工具箱。

5. 反馈：让循环有客观信号

反馈是 loop 的燃料。没有反馈，agent 只是在自言自语。

最好的反馈是自动化、可重复、低歧义的：

  • 单元测试、集成测试、端到端测试。
  • 类型检查、lint、格式化检查。
  • 构建结果。
  • benchmark。
  • 安全扫描。
  • 页面截图对比。
  • 日志中的异常栈。
  • 人类 review 评论。

“测试失败 -> 读取错误 -> 修改 -> 再测试”是最经典的编程 loop。未来更强的 loop 会把产品指标、用户行为、性能数据、安全策略也接进来。但这会带来更高的风险，因为反馈信号越接近真实世界，错误行动的成本越高。

6. 约束：让 AI 不要乱跑

约束包括技术约束、行为约束和资源约束。

技术约束：保持兼容、不引入新依赖、不修改公共 API、不跨模块改动。

行为约束：先读再改、先计划再执行、不碰敏感文件、不要自动提交、不要删除数据。

资源约束：最多运行多少轮、最多消耗多少 token、最多改多少文件、连续失败几次就停。

很多失败的 AI 编程体验，不是模型不聪明，而是 loop 没有约束。agent 为了修一个小 bug，顺手重构半个项目；为了解一个测试失败，引入新框架；为了消除类型错误，把测试删了。这些都不是“智能不足”，而是控制面不足。

7. 退出：让循环知道何时停止

退出条件是 loop engineering 里最容易被忽视、但最重要的部分。

常见退出条件包括：

  • 所有验收测试通过。
  • 指定构建命令通过。
  • diff 范围符合预期。
  • PR 已创建并附带风险说明。
  • 人工确认通过。
  • 连续 N 次同类失败。
  • 触达成本或时间上限。
  • 发现需求矛盾，必须请求人类决策。

退出条件不是失败主义，而是工程成熟度。一个会停下来的 agent，比一个永远“继续尝试”的 agent 更值得信任。

从“人写提示词”到“人设计循环”

开发者角色正在变化。

过去，开发者像是在和模型聊天：提出问题、判断答案、复制代码、继续追问。

现在，开发者更像是在设计一个小型生产系统：定义任务入口，准备上下文，配置权限，指定验证器，观察运行日志，处理异常路径，最后 review 产物。

这并不意味着开发者不需要懂代码。恰恰相反，loop engineering 对工程判断的要求更高。因为 agent 可以更快地产生更多改动，开发者必须更清楚什么是好架构、什么是可接受风险、什么验证足以证明完成、什么情况下必须停机。

一个不懂工程的人也许能用 AI 做出 demo，但要让 AI 长期在真实代码库里可靠工作，必须有人设计 loop。

三种典型 Loop

1. 修 bug loop

适合错误可复现的场景。

1
2
3
4
5
6
7

输入错误现象和复现命令
-> agent 读取错误栈和相关代码
-> 提出 2-3 个可能原因
-> 选择最小修改
-> 运行复现命令
-> 如果失败，读取新错误并继续
-> 如果通过，补测试并总结根因

关键点是“复现命令”。没有复现命令，bug loop 很容易变成猜谜。

2. 功能开发 loop

适合边界清楚的小功能。

1

需求 -> 验收标准 -> 计划 -> 小步实现 -> 测试 -> review diff -> 下一步

关键点是把功能拆小。一次让 agent 做完整支付系统、权限系统、后台管理和 UI，很容易得到表面完整但内部松散的代码。更好的做法是让 loop 一次只推进一个可验证切片。

3. 重构 loop

适合已有测试较强的代码库。

1

锁定行为 -> 建立测试基线 -> 小步重构 -> 每步运行测试 -> 比较 diff -> 记录不变性

重构 loop 的第一原则是行为不变。没有测试基线时，不应该让 agent 大规模重构。否则它可能把“看起来更干净”误认为“确实更正确”。

如何搭建自己的 Loop Engineering 实践

可以从很小的地方开始，不需要一上来就做复杂 agent 平台。

第一步，在项目根目录写清楚 agent 规则。比如 AGENTS.md、CLAUDE.md 或工具对应的 rules 文件。内容包括项目结构、常用命令、编码规范、测试命令、禁止事项、提交规则。

第二步，把常见任务模板化。比如：

1
2
3
4
5

请先阅读相关代码并给出计划，不要修改文件。
计划通过后，每次只完成一个步骤。
每次修改后运行对应测试。
如果连续两次失败，停止并总结原因。
最后给出 diff 摘要、验证命令和未覆盖风险。

第三步，为 loop 准备强反馈。没有测试就先补测试；没有 lint 就先接 lint；前端任务要接截图；性能任务要有 benchmark；文档任务要有链接检查或构建检查。

第四步，缩小权限。默认不要给 agent 无限制 shell、生产凭证、删除权限和自动 push 权限。先让它能读、能改、能测，再逐步开放更多能力。

第五步，要求它留下证据。每次完成任务，不只要“我做完了”，还要说明改了哪些文件、运行了什么命令、结果是什么、还有什么没验证。

第六步，定期复盘 loop 本身。哪些提示重复出现？哪些错误反复发生？哪些测试缺失导致 agent 误判？这些复盘结果应该进入项目规则、测试套件或自动化脚本，而不是永远靠人记住。

好 Loop 和坏 Loop 的区别

坏 loop 的典型特征：

  • 目标很大，但没有验收标准。
  • 每轮都让模型重新猜上下文。
  • 没有测试，只有模型自评。
  • 工具权限过大。
  • 修改范围不受控。
  • 失败后继续扩大改动。
  • 没有成本、轮次和时间上限。
  • 最后只给结论，不给证据。

好 loop 的典型特征：

  • 目标小而清楚。
  • 上下文从项目规则和相关文件中加载。
  • 每步都有可运行验证。
  • diff 可以被人类快速 review。
  • 失败会收敛，而不是发散。
  • 重要操作需要人工确认。
  • 结束时有验证证据和剩余风险。
  • 循环经验会沉淀到规则、测试或脚本里。

这也是为什么 loop engineering 不等于“开自动模式”。自动模式只是执行策略；loop engineering 是系统设计。

风险：AI 代码更快，也可能更快变坏

Loop engineering 的最大诱惑，是让人觉得“只要循环足够久，结果总会变好”。这只在反馈信号正确、目标稳定、工具可靠、搜索空间可控时成立。

如果反馈信号错误，loop 会优化错误目标。比如测试本身写错了，agent 会努力让错误测试通过。

如果目标模糊，loop 会不断补洞，最后做出一个谁都没真正要的系统。

如果上下文污染，loop 会把过时决策当成事实。

如果权限过大，loop 的一次误判可能造成不可逆损失。

如果成本不可见，loop 会把“省人工时间”变成“烧 token、烧 CI、烧 review 时间”。

所以成熟的 loop engineering 必须包含审计意识。你不是在雇一个永不疲倦的初级工程师，而是在运行一个会修改真实系统的自动化过程。自动化越强，证据链、权限边界和回滚能力越重要。

Loop Engineering 与未来的软件团队

未来的软件团队可能会形成新的分工。

产品或技术负责人定义目标和验收标准。

工程师设计 loop、维护规则、补齐测试、审查关键 diff。

Agent 执行大量重复但可验证的工作：迁移 API、补测试、修 lint、更新文档、跑基准、处理小 bug、生成 PR 草稿。

CI/CD 不再只是“代码提交后的检查”，而会变成 agent loop 的实时反馈器。

代码库里的文档、测试和规则，也不再只是给人看的材料，而是给 agent 读取和执行的操作系统。

这会带来一个反直觉结论：AI 越强，软件工程的基本功越重要。模块边界、测试质量、命令一致性、文档准确性、权限设计、日志可读性，这些过去看起来“啰嗦”的工程资产，会直接决定 agent 的生产力上限。

一份实用检查清单

在让 AI agent 开始一个 loop 前，可以问自己：

  1. 目标是否能用一句话说明完成状态？
  2. 是否有明确的不做范围？
  3. agent 需要读哪些项目规则和相关文件？
  4. 哪个命令能验证它做对了？
  5. 如果没有验证命令，是否应该先补测试？
  6. 它最多可以改多少文件？
  7. 哪些文件或命令禁止触碰？
  8. 连续失败几次必须停？
  9. 完成后需要输出哪些证据？
  10. 人类 review 的关注点是什么？

如果这些问题答不上来，就先不要开长 loop。先把任务缩小，把验证补上，把权限收紧。

结语

Loop engineering 的本质，是把 AI 编程从“会话技巧”升级为“系统工程”。

Prompt engineering 关注单次交互，context engineering 关注信息供给，loop engineering 关注一个自治过程如何在真实工程环境中持续接近目标。它不是让开发者退场，而是把开发者推到更高层的控制面：设计目标、约束、反馈和退出条件。

2026 年的 AI 编程社区之所以开始讨论 loop engineering，是因为大家已经越过了“AI 能不能写代码”的阶段，进入了“AI 如何在真实项目里长期可靠地工作”的阶段。

真正的分水岭不在于谁会写更漂亮的提示词，而在于谁能设计更可靠的循环。

参考资料