用 AI 编程 Agent 时，很多人还停在「写一句 prompt → 看结果 → 再写一句」的节奏里。Loop Engineering（循环工程）要改的，是人在这个环里的位置：你不再当实时操作员，而是先把目标、规则、检查和记忆设计成一套可循环的系统，再让 Agent 自己跑完。
这个说法在 2026 年中开始在 AI Agent 圈——尤其是 AI 编程 Agent——里流行起来。Addy Osmani 给过一句很直白的定义：
Loop engineering is replacing yourself as the person who prompts the agent. You design the system that does it instead.
（循环工程的本质，是用“设计系统”取代“自己去 prompt Agent”。）
什么是 Loop Engineering
过去，你是 Agent 的操作员：一问一答地写 prompt，结果对了再推进下一步。Loop Engineering 把你推到系统设计师的位置——提前定好目标、规则、检查机制和记忆方式，让 Agent 自己循环执行，直到满足完成条件。
工作单元也从「这一次对话里的一句指令」变成「一整条可重复运行的循环」。人仍然要对结果负责，但不再需要守在每一轮输入框前。
它解决了什么问题
传统用 AI 写代码的流程通常是：
- 你写一个 prompt
- Agent 执行
- 你检查结果
- 你再写下一个 prompt
- 重复……
人始终卡在环里当实时操作员。任务一长，节奏就被打断：Agent 等你下指令，你又得反复读 diff、补上下文、重述目标。
Loop Engineering 换了一条路径：你一次性设计好循环系统，之后 Agent 可以自主发现工作、执行、验证、迭代。设计得当的话，它甚至可以在你不在场时继续跑——前提是目标可验证、状态可恢复、触发条件清楚。
和 Prompt Engineering 差在哪里
两者并不互相取代。Prompt Engineering 仍然决定「这一步怎么说清楚」；Loop Engineering 决定「整条流水线怎么自己转起来」。差别可以概括成：
| 维度 | Prompt Engineering | Loop Engineering |
|---|---|---|
| 人的角色 | 实时写指令的操作员 | 设计循环系统的架构师 |
| 工作单元 | 单次 prompt | 一个完整的「循环」 |
| 控制方式 | 人逐轮输入 | 系统自动组装并触发 prompt |
| 适用场景 | 一次性任务、短对话 | 长任务、持续迭代、自动化工作流 |
| 核心能力 | 写好一句指令 | 设计目标、验证、记忆与触发机制 |
一句话对照：Prompt Engineering 更像教一个人怎么做某件事；Loop Engineering 更像设计一条流水线，让工人（Agent）按流程反复做，直到产品合格。
一个完整 Loop 通常包含哪些要素
实践里，一条可用的循环很少只靠「再跑一遍」三个字。常见会落到下面这些零件上。
Goal（目标 / 停止条件）
完成标准必须清晰、可验证。例如：「所有测试通过 + lint 干净 + 功能符合规格」。没有可检查的停止条件，循环就会空转，或者由 Agent 自己宣布「做完了」。
Automations / Schedule / Hooks（自动化与触发）
循环需要自己能启动。常见触发包括定时任务、新 issue、CI 失败、webhook 等。人不必每次手动开聊，系统在事件发生时把循环拉起来。
Spine / Memory（记忆与状态）
模型每次对话都会「失忆」。进度要落到磁盘上——markdown、Linear、progress 文件等——下一轮才能读到「做到哪了、还剩什么、上次失败在哪」。
Worktrees（隔离）
多个 Agent 并行时，需要工作区隔离，避免改同一棵树互相踩脚。
Skills（项目知识沉淀）
用 SKILL.md 写下项目约定、构建方式、注意事项，让 Agent 每次自动读取。这相当于把反复口述的上下文固化成可复用模块。
Sub-agents（子 Agent）
拆分角色：一个负责实现，另一个负责审查或验证，减轻「自己给自己打高分」的问题。实现与验收不要绑在同一个提示里硬扛。
Plugins / Connectors（工具连接）
通过 MCP 等方式真正操作环境：开 PR、更新工单、跑测试等。循环若只能「说说建议」而不能改状态，就很难闭环。
这七块不必一次上齐，但缺哪一块，长任务就容易在对应环节断掉：没 Goal 不知道何时停，没 Memory 每轮重讲，没验证就容易自嗨，没连接器就停在口头方案。
底层仍然是提示词在控制
Loop Engineering 并没有跳出「用自然语言指令驱动模型」这条路。底层依然是通过 prompt 控制大模型；变的是写 prompt 的方式——从实时、逐轮对话，变成预先设计好一整套可复用、可循环的 prompt 系统。
落到零件上也能对上：
- Goal 本质上是一段写得很清楚的停止条件 prompt。
- Skills 是可复用的提示词模板库。
- 验证子 Agent 通常也是另一套更严的审查 prompt。
- 循环逻辑本身（例如
/goal、/loop、定时任务）会反复把「当前状态 + 原始目标 + 记忆」重新组装成新的 prompt 再喂给模型。
更准确的说法是：
Loop Engineering = 把人从「实时写 prompt」中解放出来，变成「设计 prompt 的系统架构」。
提示词仍然是真正控制模型行为的接口，只是被工程化、模块化、自动化了。
主要用在哪些场景
目前最热的是 AI Coding Agent，例如 Claude Code、Codex、OpenCode 一类工具上的长任务：
- 让 Agent 自己消化 backlog、修 bug、写测试
- 定时做代码审查、分析 CI 失败
- 从 0 到 1 搭功能：写代码 → 跑测试 → 修改 → 再测，直到达标
同一套思路也适合业务自动化、内容生产、SEO 优化等需要「持续迭代直到达标」的场景——共性是：目标可检查、过程可记忆、触发可自动化。
落地时要注意什么
- Token 成本会明显上升：长时间循环叠加多子 Agent，账单和延迟都会涨。
- 验证仍然重要：Agent 容易「自欺欺人」，实现与审查拆开、停止条件可机器检查，比多喊几句「请认真验证」更靠谱。
- 过度依赖会欠债：会出现「理解债务」（comprehension debt）和「意图债务」（intent debt）——代码或流程在转，但人和团队对系统真实意图的把握在变薄。
- 仍处在早期阶段：工具能力还在快速补齐，
/goal、/loop等命令已开始标准化，具体产品能力会继续变。
人的价值也在跟着挪位置：从「会写好一句 prompt」，进一步变成「会设计整条循环的 prompt 体系，以及配套的验证机制和记忆方式」。会写指令仍然有用；会搭循环，才扛得住长任务和人不在场的自动化。