Loop Engineering
2026 年 AI 开发圈最热的工作流范式——从”逐条提示 AI”转变为”设计自动循环让 Agent 自驱动完成任务”
简介
Loop Engineering（循环工程）是一种 AI 工作流设计范式，核心思想是：开发者不再逐条提示 AI，而是设计一套包含触发器、目标、验证机制和预算控制的自动循环系统，让 Agent 在其中自主驱动完成任务。
这个概念起源于 2026 年 6 月 Peter Steinberger 的一条推文（获得 650 万次浏览），随后 Anthropic Claude Code 负责人 Boris Cherny 公开表示自己的工作方式正是如此，Google 工程师 Addy Osmani 将其整理成文章并正式命名为 Loop Engineering。与传统的”一问一答”式 AI 使用方式相比，Loop Engineering 代表了从”人驱动 AI”到”系统驱动 AI”的范式转变——开发者的角色从”提示者”变为”系统设计者”。
Loop Engineering 与定时脚本的本质区别在于：脚本跑固定逻辑（条件A→动作B），而 Loop 里跑的是 Agent，每次根据当前状态自己判断下一步。“脚本是死的，Agent 是活的。“这个区别在 2025 年底模型能力跨过门槛后才真正变得可行。
关键信息
- 类型：概念 / 工作流范式
- 领域：AI 编程 / Agent 工程 / 开发者工作流
- 起源时间：2026 年 6 月
- 提出者：Peter Steinberger（推文发起）、Boris Cherny（实践背书）、Addy Osmani（命名整理）
- 相关概念：Agentic Workflow、Agent Harness、上下文工程、Claude Code、ReAct
核心特性
六大核心模块
一个完整的 Loop 由六个模块组成，缺一不可：
| 模块 | 功能 | 设计要点 |
|---|---|---|
| 触发器（Trigger） | 启动循环的信号 | 条件要精确，避免不必要触发 |
| 目标设定（Goal） | 决定努力方向和停止条件 | 好目标的唯一标准：可以被验证 |
| 工具调用（Tools） | Agent 的”手脚” | 先给最小必要集，跑稳再扩展 |
| 记忆与上下文（Memory） | Agent “记得”什么 | 用文件存储，不靠 Agent 自己记 |
| 验证机制（Evaluator） | 判断这轮做得对不对 | 执行者和验证者必须分开 |
| 预算控制（Budget） | 限制花费和运行时间 | 最基本的保险，防止死循环烧钱 |
三角色结构
一个能正常运转的 Loop 本质上只有三个角色：
- Generator（执行者）：干活的 Agent，读代码、写代码、调接口、跑命令
- Evaluator（评判者）：打分的角色，可以是另一个 Agent 或确定性程序（如跑测试）
- Loop 本身：连接两者的逻辑——产出→评判→没过传回→过了结束
三个典型应用场景
- CI 自动修复（入门推荐）：目标最清晰（CI 是否通过是完全客观标准），Generator 读报错→定位→修改→提交，Evaluator 就是 CI 本身
- PR 自动审查：目标较软性，Evaluator 需要具体 rubric（是否覆盖安全/性能/代码规范问题）
- 复杂任务自动重构：最接近”真正自主工作”，也最容易出问题——任务越复杂，对上下文管理和预算控制要求越高
另一视角：Loop 是产品经理工作流的代码化
除了”开发者工作流”这个技术叙事，Loop Engineering 还有一个更深的解读：它第一次把产品经理这份工作抽象成了一段能自己运行的代码。Loop 的五个零件与 PM 每天在用的管理工具一一对应：
| Loop 零件 | PM 对应物 | 本质 |
|---|---|---|
| 验收门禁 / 停止条件 | Definition of Done（完成的定义） | 把”干完了”翻译成机器可判定真假的标准 |
| 独立验证器 | 同行评审 / code review / QA 与开发分家 | 自己不能判自己的卷子 |
| 状态文件 | 需求文档 / 会议纪要 / 看板 | Agent 会忘，文档不会 |
| 止损上限 | WIP 限制 / 排期 / 预算 | 不设刹车必然失控 |
| 升级机制 | 向上汇报 / 升级路径 | 哪条线以下自己定，以上必须找人 |
这个视角下，“工程师花了四次范式跃迁（Prompt→Context→Harness→Loop），才退到 PM 一开始就站着的位置”。每一次范式演进都把人往后推一步——离具体执行更远、离规则设计更近，而这条路的终点站站着的角色，就是产品经理。这也和学术界的 ReAct（2022 年姚顺雨提出）、管理学的 PDCA 循环相互印证，Loop 是被两个方向同时验证过的老配方。
权责挑战
Loop 真正的难点从来不是工程，而是管理。当 PM 拥有一支”归自己直接指挥”的 Agent 团队后，那套带团队的老难题会原封不动搬过来，且被放大：
- 责任集中：Agent 没有独立人格，它办砸的每件事最后都记在设计循环、按启动键的人头上。权力更大了，能甩出去的锅却更少了。
- “装懂”问题：Agent 不会像新人那样愣一下、来问你，而是把没搞明白的事办得措辞笃定、看起来权威，然后自信地交上错误结果。你唯一的依靠是提前设好的、铁面无私的验收门禁——把”怀疑”做成制度。
- 管理短板被放大：DoD 写不清→按秒计费的空转；不设硬止损→账单教你做人；不读交付物→积累 理解力债务；照单全收→滑向 认知投降。
- 该盯的指标：不是烧了多少 token、开了多少 PR，唯一有用的指标是”每个被采纳的改动平均花了多少成本”。被采纳率低于一半，这个 Loop 就在亏钱。
哪些活不该交给 Loop：判断密集、对错不清、依赖人拍板的事（架构、鉴权、支付逻辑、产品方向）别让循环碰；Loop 擅长的是对错清晰、机器可验证的活（自动修 lint、依赖更新 PR、CI 失败分类、复现偶发测试）。建 Loop 前用四问筛一遍：重复发生吗？有机器可验收的标准吗？token 预算扛得住吗？工具够称职吗？四个全过才值得建，且顺序是”先手动跑通→固化成技能→包进循环→最后上定时”。
永远外包不出去的部分
Loop 能把一个决定周围所有步骤跑得飞快，唯独跑不了那个决定本身——“这个用户到底想要什么、两个都对的方案该选哪个、这件事现在值不值得做”。它能替你执行，替不了你判断。Karpathy 的名言点破了内核：“你可以把思考外包出去，但你没法把理解外包出去。“热词会从 prompt 换到 context、harness、loop，但底下那个没动的东西是”人对意图的定义和对结果的判断”，那才是比任何循环都活得久的手艺。
不同素材中的观点
-
2026-06-22-loop-engineering-woshipm：从 Boris Cherny 的实践出发，系统拆解了 Loop Engineering 的六模块框架和三角色结构。核心洞察是”目标设定是整个 Loop 里最重要的一块，没有之一”——好目标的唯一标准是可验证性。同时指出三个新手常踩的坑：目标模糊、没有退出条件、不做上下文管理。文章将 Loop Engineering 定位为 2026 年 AI 开发圈最热的话题之一，本质是开发者的角色转变。
-
2026-07-01-loop-engineering-pm-codification（人人都是产品经理，@发疯的超）：从产品经理视角重新解读 Loop，提出”loop engineering 本质上是头一回把 PM 这份工作抽象成一段能自己运行的代码”。核心论点：这波热点真正被重新定价的岗位是 PM 而非提示词工程师，且是利好——“把模糊目标拆成可验收标准”这项被低估的软技能，一夜之间从可有可无变成整个系统能否跑起来的承重墙。文章还系统梳理了 Loop 带来的权责挑战（责任集中、Agent”装懂”、管理短板被放大）和”外包不出去的判断”，引用 Addy Osmani”两人搭一模一样的 loop 能跑出相反结果”和 Karpathy”能外包思考、不能外包理解”两句冷水。
-
2026-07-05-juejin-context-engineering-harness：把 Loop 放到 Prompt → Context → Harness 的生产链路里，强调 Loop 不是独立热词，而是 Harness闭环工程 的关键校验与重试层。奶茶店 Node.js 示例中，模型输出 JSON 后先
JSON.parse，解析失败就进入“需开启 Loop 循环重生成”的分支；这说明 Loop 的最小落点可以非常朴素：先让输出可被机器验收，再把失败信息反馈给模型重试。文章还把 Loop 与安全围栏、MCP 技能并列，说明企业线上 AI 系统要校验的不只是格式，还包括成本、合规、业务目标和工具调用边界。 -
2026-07-06-blocktempo-fable-5-self-improving-agent：把 Loop Engineering 放进 Fable 5 自我改进代理系统的更大架构中：/goal 与 Outcomes 都是“目标驱动循环”的实现，真正有效的共同点是由独立评分者判断是否达标，未达标则继续迭代，达标才退出。文章进一步强调 Loop 不能只靠自我批评，验证者子代理应与执行者隔离；循环的产出还要写回 STATE.md 和 Skill，形成“执行→验证→蒸馏→记忆→下一轮更好”的复利路径。它也补充了三种动态工作流模式：fan-out-and-synthesize、adversarial verification、loop-until-done。
-
2026-07-07-blocktempo-fable-loop-library-25-workflows：把 Loop Engineering 从开发者/代码场景扩展成一套 AI Ops 工作流库。每个 Loop 都必须有排程、每轮只改一件事、固定检查、状态文件 和停止点；每个 Loop 还要按绿色/黄色/红色做 Loop 工作流风险分级，决定能否无人值守、是否只草拟、哪些动作必须由人收尾。文章提供 25 个横跨营销、产品、商业运营、研究决策的循环样本，并用 难题升级队列 说明模型路由的经济性：例行轮次用便宜模型，只有记录了失败证据的问题才升级给 Fable 5。
-
2026-07-08-abmedia-claude-code-four-loop-types：从 Anthropic Claude Code 团队工程师 Delba de Oliveira 的《Getting started with loops》出发，把 Loop 的“触发器”进一步拆成四种可操作模式：turn-based（每个手动 prompt 都是一轮上下文收集、行动、验证、汇报）、goal-based（用
/goal明确定义成功条件与最大回合数，由评估者模型判断是否继续）、time-based（用/loop或/schedule做周期巡检）、proactive（由事件流触发，结合 schedule、goal、dynamic workflows、多 agent 和 auto mode）。这篇素材的价值是把 Loop Engineering 从六模块抽象框架落到 Claude Code 命令层的路由选择：不同触发方式对应不同验证、预算和人工介入边界。详见 Claude Code 四类 Loop。
实用信息
快速上手步骤
- 选一个目标清晰的场景开始：CI 自动修复是最佳入门场景，因为”CI 是否通过”是完全客观的标准
- 先设计目标和验证机制：在写任何代码之前，先明确”什么算完成”以及”谁来判断”
- 从最小工具集开始：不要一开始就给 Agent 所有权限，先让它能读文件和跑测试就够了
- 设好预算上限：最大重试次数（如 5 次）+ 最大花费 + 最大运行时间
设计 Checklist
- 触发条件是否足够精确？（避免不必要触发）
- 目标是否可验证？（有明确的通过/不通过标准）
- Generator 和 Evaluator 是否分开？（避免自产自销）
- 是否有预算控制？（防死循环烧钱）
- 上下文是否通过文件管理？（不靠 Agent 自己记）
常见误区
- “做好”不是目标：目标必须可验证，“让所有单元测试通过”才是
- Loop ≠ 定时脚本：脚本跑固定逻辑，Loop 里的 Agent 每次自主判断
- 不做预算控制会烧钱：Agent 陷入死循环时会一直跑下去直到账单让你清醒