别再手写提示词了！一文读懂 AI 编程新范式：Loop Engineering（循环工程）
2026年6月，AI 开发者圈子被一句话彻底点燃：“你不该再给编程 Agent 写提示词了，你应该设计一套循环机制（Loops），让这些循环去提示你的 Agent。”
这句由 OpenClaw 创始人 Peter Steinberger 发出的“每月提醒”，迅速引发了百万级浏览与全网热议。紧接着，Claude Code 的创建者 Boris Cherny 也公开表示，自己已经不再手动输入提示词，而是让大量循环在后台运行。这标志着 AI 交互正在经历一次重大的抽象层级跃迁——从 Prompt Engineering（提示词工程）正式迈入 Loop Engineering（循环工程）时代。
Chrome 团队的 Addy Osmani 就发了一篇推文，昭示着 Loop Engineering 的到来
究竟什么是 Loop Engineering？它为什么能取代传统的对话式编程？本文将带你全面拆解这一最新范式。
一、什么是Loop Engineering
简单来说，Loop Engineering 就是用你设计的系统来替代你自己去手动 prompt Agent。
过去两年，我们与 AI 协作的方式是“一问一答”：你输入一段话，读返回的内容，再输入下一段话。人是控制者，Agent 是执行者。但这种方式受限于人类的思维带宽，一旦任务变长、变复杂，就需要人一轮轮往前推。
Loop Engineering 的核心思想是：**人类退出持续提示的位置，转去设计一个能够持续调度、约束和验证 AI 的“循环系统”。**在这个系统中，AI 像流水线一样自主运转，自动发现工作、分配任务、检查结果并决定下一步。开发者的角色也从单纯的“问话者”升级为了“系统架构师”。
图片来源：什么是 Loop Engineering？
二、四代AI范式的演进关系
要真正理解 Loop Engineering，我们需要将其放在 AI 工程的演进脉络中来看。这四者是叠加关系，而非替代关系：
- Prompt Engineering（提示词工程）：解决的是“怎么问”。关注单次调用的指令质量，让人类逐轮驾驶模型。
- Context Engineering（上下文工程）：解决的是“给它看什么”。通过 RAG 或记忆库把正确的项目背景、代码结构送进上下文窗口。
- Harness Engineering（环境工程）：解决的是“在哪里安全运行”。为 Agent 提供工具、权限、沙箱环境和接管机制。
- Loop Engineering（循环工程）：解决的是“如何持续推进与反馈闭环”。设计递归和迭代处理循环，让 Agent 具备自我观察、自我规划、自我纠错的能力。
三、核心架构：5 + 1构建模块
真正的Loop绝不是简单的机械重复Cron Job，而是一套带有反馈闭环的工程系统。一个完整的 Loop 通常需要以下五个核心组件加上一个记忆层：
- skills项目知识外置：Agent每次session都是冷启动，skill文件将约定、构建步骤和踩坑记录写进磁盘，避免Agent反复从头解释项目。解决的是项目规则，如何让AI理解项目。
- Connectors连接真实世界：只会读文件的 Loop 很小。通过 MCP 等连接器，Loop 可以查 Issue、读 CI 日志、发 Slack、调 API，甚至直接开 PR。解决的是如何实际在做。
- Sub agents，maker与checker分离：不要让同一个模型写完代码又宣布“没问题”，它几乎一定会偏袒自己。拆分为探索/实现 Agent 和审查 Agent，是保证无人值守结果可信的前提。解决的是模型交叉检查。
- State/ Memory 持久化状态：模型跨 Session 会失忆，进度、试过的方案必须落在外部（Markdown、Linear 看板等）。Loop 能接力，靠的是 State（有点类似langgraph定义的stategraph，靠状态在节点中传递上下文），而不是聊天记录。解决的是隔离协作。
- Automations自动触发：按计划自动跑一轮分拣Triage，读取失败的CI和新开的Issue，把值得处理的事项分发给独立的Sub-agent。解决的是怎么被触发的问题。
- Memory记忆：无论是 Markdown 文件还是 Git 历史，它为 Loop 提供了跨会话的连续性。解决的是Loop的记忆。
四、关键挑战：验证子Loop的缺失
听起来 Loop 已经能“发现工作 -> 写代码 -> 审代码 -> 开 PR”完美闭环了，但仔细想一个问题：它怎么知道“做完了”？
对于后端或 CLI 工具，lint 干净、单测全绿就可以停止。但对于 App 或 Web UI，“命令 exit 0”不等于“产品没问题”。界面对不对、真机能不能跑，都不在源码里。于是多数 Coding Loop 实际停在“代码可合并”，验产品这一步依然是人挨个点屏幕。
要实现真正的 AI 研发闭环，就必须补齐验证子 Loop（Verification Sub-loop）。它需要：
- Connector：连得上真机/浏览器，验完自动把截图或结果送回 Coding Agent。
- Sub-agents：点的和判的不是同一个 Agent，不能自己说自己过了。
- State：验过什么、哪一步挂了，写进文件。
五、成本和边界
Addy并没有把Loop Engineering讲成一个万能方案。相反，他特别提醒了两件事：成本，以及边界。
成本不低
loop一旦跑起来，就不是简单的一问一答了。它会反复读上下文、反复试错、反复验证，必要时还会同时调用多个Agent并行处理。如果任务本身不值得重复执行，或者没有稳定反馈，loop可能还没帮你省时间，就先把成本烧掉了。AI能推进流程，但不能替你负责
AI说“完成了”，不代表真的没问题；AI说“测试通过了”，也不等于业务逻辑就一定正确。一个没有人盯着的loop，也会在没有人盯着的情况下持续犯错。所以loop真正替代的不是人，而是重复劳动。真正该留在人手里的，仍然是判断、验收和刹车。
六、落地建议与避坑指南
如果你准备着手构建自己的第一个 Loop，请记住以下几条实战教训：
- 从小开始，逐步迭代：不要指望第一天就搭建出复杂的全家桶架构。第一版可以极简：一个定时器 + 一个 Skill + 一个保存状态的 Markdown 文件。跑通后再加入 Checker 机制与外部 Connector。
- 内置硬停止条件：为了防止失控，严肃的 Loop 必须有明确的边界：最大迭代次数、无进展检测（跑了但没变化时停止）、以及 Token 预算上限。
- 让沉默成为敌人：Loop 通常在后台静默运行。必须在关键步骤失败时加入通知机制（Webhook 推送至飞书/Slack），并在 Memory 层输出可被快速检索的格式化日志。
- 警惕 Token 成本与理解力负债：无限循环极易导致字符膨胀，瞬间烧干预算。此外，循环跑得越快，如果不人工审查产出代码，开发者对自己项目的理解就会越来越浅。