Loop Engineering 全面解析
2026 年 6 月，Claude Code 创建者 Boris Cherny 一句话引爆了 AI 工程圈：“我不再 prompt Claude 了。我设计 loop，让 loop 去 prompt Claude。” 几乎同时，Google Cloud AI 总监 Addy Osmani、OpenClaw 创始人 Peter Steinberger 也独立得出了相同结论。一个新的工程范式——Loop Engineering（循环工程）——正式进入主流视野。
一、什么是 Loop Engineering？
Loop Engineering 的核心思想很简单：不再由人一步步给 AI 下指令，而是设计一个能自我运转的循环系统，让它自己发现问题、规划方案、执行任务、验证结果、持续迭代。
传统 AI 编程模式：人 → Prompt → AI → 结果 → 人检查 → 再 Prompt → ...Loop Engineering 模式：人设计 Loop → Loop 自动发现任务 → 规划 → 执行 → 验证 → 迭代 → ...（人仅在关键节点介入）
这不是简单的"自动化脚本"。Loop Engineering 的本质是将人的判断力前移到系统设计阶段——你来定义"什么是完成"、“什么算失败”、“什么时候该停下来”，而 Loop 负责在规则内持续运转。
二、核心模块：Discover → Plan → Execute → Verify → Iterate
Loop Engineering 的核心是一个五阶段闭环，几乎所有实现都遵循这个模式：
| 阶段 | 做什么 | 具体实现 |
|---|---|---|
| Discover（发现） | 扫描待办事项、CI 失败、Issue、历史会话，找出需要做的事 | loop-scan 、/goal、定时 cron、GitHub Actions 触发 |
| Plan（规划） | 生成可验证的 Spec，定义完成标准、停止条件、预算上限 | loop-generate 、ultragoal:goal、Plan Persona |
| Execute（执行） | 在隔离环境中执行任务，写代码、跑构建、做修改 | Worktree 隔离、Developer Sub-agent |
| Verify（验证） | 由独立 Agent（非执行者） 重新检查每项标准，尝试反驳 | loop-verify 、ultragoal:verify、Gate Sub-agent |
| Iterate（迭代） | 验证失败则反馈给执行者重来，通过则将经验写入 Memory | 门控循环直到 VERDICT: PASS，经验持久化 |
💡 关键洞察：Verify 阶段的执行者必须是不同的 Agent（甚至不同的模型）。写代码的 Agent 给自己的作业打分太容易放水——这是 Loop Engineering 最重要的结构性决策。
三、六大核心组件
Google Cloud AI 总监 Addy Osmani 在 2026 年 6 月的长文中提出了 Loop Engineering 的六大组件框架。这六个组件不是并列关系，而是层层叠加、互为支撑：
3.1 Automations（自动化/心跳）
职责：按计划触发任务，让 Loop 真正"循环"起来。
没有 Automation，Loop 就是一次性脚本。Automation 是 Loop 的"心跳"——cron 定时、Webhook 触发、/loop 命令、GitHub Actions，决定了"什么时候开始干活"。
Claude Code 中的实现：- /loop → 定时循环执行任务- /goal → 持续运行直到验证条件满足- hooks → 事件触发（文件变更、会话结束等）- cron → 定时调度（如每天早上扫描待办）
3.2 Worktrees（工作树）
职责：为并行 Agent 创建隔离的 git 工作目录，防止代码冲突。
基于 git worktree 机制，每个 Agent 拿到独立的文件系统 checkout，物理上无法互相踩踏。这让并行 Agent 真正安全——一个 Agent 改前端，另一个改数据库，互不干扰。
| 场景 | 实现方式 |
|---|---|
| Claude Code | --worktree flag |
| Sub-agent | isolation: "worktree" |
| 并发上限 | 受限于人的 review bandwidth（不是工具） |
3.3 Skills（技能包）
职责：将项目知识、规范、历史教训沉淀为可加载的外部文件。
SKILL.md 解决的是"意图债"问题——Agent 每次冷启动都没有项目上下文。Skill 让 Agent 不重新推导，直接在经验基础上运行。效果类似复利增长：每一轮的产出都比上一轮更稳。
Skill 的渐进式加载：1. 元数据（name + description）→ 始终在上下文中2. SKILL.md 主体 → 场景匹配时触发加载3. 脚本/参考资源 → 按需加载
3.4 Plugins & Connectors（插件与连接器）
职责：通过 MCP 协议让 Agent 连接真实工具。
这实现了关键跃迁：从「Agent 告诉你要做什么」到「Loop 自己开 PR、关联工单、CI 通过后通知频道」。
| 连接目标 | 能力 |
|---|---|
| GitHub/GitLab | 自动创建 PR、Review 代码 |
| Linear/Jira | 读写工单、关联任务 |
| Slack/Discord | 通知结果、接收指令 |
| Sentry/Datadog | 感知错误、触发修复 |
| 数据库/API | 查询数据、执行操作 |
3.5 Sub-agents（子代理）
职责：实现执行者与验证者的角色分离。
这是 Loop Engineering 最关键的架构模式——不同的 Agent 承担不同角色：
典型分工： 探索者（Explorer） → 快速扫描代码库，定位问题范围 实现者（Developer） → 在 Worktree 中写代码 验证者（Reviewer） → 以"挑刺"心态重新检查，尝试反驳 门控者（Gate） → 汇总结果，判断是否通过
💡 关键洞察：验证者必须使用与实现者不同的上下文——它不知道代码是怎么写的，只知道要验证的标准是什么。这消除了"自我评分偏差"。
3.6 Memory（记忆）
职责：跨会话持久化状态——记录"做了什么"和"下一步是什么"。
Memory 必须存在磁盘上，而非上下文窗口里。Agent 会忘记，但文件不会。
Memory 的形式： .loops/loop.md → 当前任务的 Spec .loops/state.md → 跨轮次的状态记录 .loops/runs.log → 执行历史 .ultragoal/memory/ → 验证过的经验（带 [VERIFIED] 标签）
四、与其他工程范式的区别与联系
Loop Engineering 不是凭空出现的。它是 AI 工程范式演进链上的最新一环。理解它与前几个范式的关系，才能理解它的真正定位。
4.1 四大范式演进全景
| 范式 | 时间 | 核心问题 | 人的角色 | 控制层级 |
|---|---|---|---|---|
| Prompt Engineering | 2023–2024 | 如何做 ——怎么表达任务让模型输出正确 | “雕琢咒语的人” | 消息级 |
| Context Engineering | 2025 上半年 | 看到什么 ——上下文窗口里塞什么、不塞什么 | “信息架构师” | 会话级 |
| Harness Engineering | 2025 下半年–2026 初 | 如何约束和运行 ——Agent 能做什么、不能做什么 | “驯兽师” | 系统级 |
| Loop Engineering | 2026 年中 | 如何自我运转 ——设计让 Agent 持续工作的循环系统 | “系统建筑师” | 持续职能级 |
4.2 Prompt Engineering（提示词工程）
核心关注：如何做
Prompt Engineering 解决的是单次输入-输出的质量问题：怎么写提示词让模型理解需求、用什么格式约束输出、怎么设计 Few-shot 示例。
局限：一旦任务需要调用工具、跨步骤协作、访问外部知识，单靠 Prompt 撑不住整个系统。
4.3 Context Engineering（上下文工程）
核心关注：看到什么
Andrej Karpathy 的定义：“Context Engineering 是精巧地填充上下文窗口的艺术与科学。”
Context Engineering 管理的是信息的边界：哪些信息应该进入上下文窗口、按什么顺序排列、什么时候该压缩或丢弃。RAG 检索增强、工具描述设计、记忆系统、Sub-agent 隔离，都属于 Context Engineering 的范畴。
局限：只管模型"看到什么"，不管模型出错后怎么办。看到正确的信息≠做出正确的决策。
4.4 Harness Engineering（缰绳工程）
核心关注：如何约束和运行
核心公式：Agent = Model + Harness（Martin Fowler 框架）
Harness Engineering 给 Agent 加"缰绳"——定义它能做什么、不能做什么、出错时怎么纠正：
| Harness 组件 | 作用 |
|---|---|
| 知识库（CLAUDE.md） | 确定性注入系统提示，不依赖模型记忆 |
| Linter / 测试 | 硬约束，Agent 无法绕过 |
| Hooks | 文件写入后触发检查、Stop Hook 运行测试 |
| 循环检测 | 同一文件被重复编辑 3 次以上时介入 |
| 权限控制 | 黑白名单，防止危险操作 |
核心理念（Mitchell Hashimoto）：“每次 Agent 犯错，不是告诉它下次做得更好，而是改变系统，让这个错误在结构上更难重复。”
局限：Harness 服务于单次有限任务——人给任务 → Agent 完成 → 系统退场。它不管"下一轮任务什么时候开始"。
4.5 Environment Engineering（环境工程）
核心关注：面向什么反馈
Environment Engineering 是 2026 年新浮现的概念。它关注的是 Agent 所处的"环境"如何塑造其行为——什么样的反馈信号让 Agent 更快学到正确做法。
核心洞察（EurekAgent，2026 年 6 月）：瓶颈正从"设计 Agent 工作流"转向"设计 Agent 所处的环境"——包括权限边界、资源约束、接口设计、人工介入点。
| 环境维度 | 设计问题 |
|---|---|
| 权限工程 | 什么能做，什么需要审批 |
| 资源工程 | 文件系统、Git 协作机制 |
| 预算工程 | Token 预算、时间上限 |
| 人机协同 | 什么节点需要人介入 |
4.6 Loop Engineering 的独特定位
Loop Engineering 站在上述所有范式之上，解决的是一个更高层面的问题：如何让系统自己决定"什么时候开工、做什么、做到什么程度算完"。
人的决策权不断上移：Prompt Engineering → 控制"怎么说"Context Engineering → 控制"看什么"Harness Engineering → 控制"运行边界"Environment Engineering → 控制"反馈信号"Loop Engineering → 设计"运转系统"，完全脱离日常操作
💡 核心关系：Loop Engineering 不是替代前四个范式，而是包含它们。一个真正能运转的 Loop，内部必然包含好的 Prompt、合理的 Context、可靠的 Harness、有效的 Environment。Loop 是"把前面四者串起来的节奏系统"。
五、从 ReAct 到 Loop Engineering：进化的逻辑
5.1 ReAct 的经典范式：Think → Act → Observe
ReAct（Reasoning + Acting）是 2022 年由 Yao et al. 提出的 Agent 基础模式。它的核心循环非常简洁：
Think（思考下一步做什么） → Act（调用工具/执行操作） → Observe（观察结果） → Think（基于结果重新思考） → ...（循环直到任务完成）
这个模式有三个重要贡献：
-
推理可追踪
——每一步都有文字记录，出错了知道为什么
-
动态适应
——可以根据观察结果调整策略
-
工具整合
——自然地将工具调用融入推理流程
5.2 ReAct 的四大硬伤
但当任务变长、变复杂时，ReAct 暴露出结构性缺陷：
| 失败模式 | 具体表现 | 真实案例 |
|---|---|---|
| 无限循环 | Agent 反复调用同一个验证工具 3 次、10 次、20 次——它不记得之前的失败 | 2025 年 11 月，4 个 LangChain Agent 因此跑了 11 天，花费 $47,000 |
| Token 爆炸 | 每轮重新发送完整历史，成本随步数平方级增长 | 同等输出下 ReAct 的 token 消耗是 Plan-Execute 的 2-4 倍 |
| 中间迷失 | 长循环中早期关键信息被上下文窗口"淹没" | 30-50% 概率在长任务中出现死循环 |
| 自我评分偏差 | Agent 给自己的输出打分时天然放水 | 同一模型做实现者和验证者，漏检率高 |
5.3 Loop Engineering 如何突破
Loop Engineering 不是否定 ReAct，而是给 ReAct 加上了外部结构：
| ReAct 的问题 | Loop Engineering 的解法 |
|---|---|
| 没有规划，走一步看一步 | Plan 阶段 ——先出全局计划再执行 |
| 自己给自己打分 | Verify 阶段 ——独立 Agent 验证，不同模型 |
| 出错不知道什么时候停 | Iterate 阶段 ——门控条件、预算上限、升级规则 |
| 用完就忘，下次从头来 | Memory 组件 ——持久化经验，跨会话复用 |
| 一个人干活，无法并行 | Worktrees + Sub-agents ——并行隔离执行 |
| 不知道什么时候开工 | Automations 组件 ——定时/事件触发 |
ReAct（单 Agent 内循环）： Think → Act → Observe → Think → Act → Observe → ... 特点：同一个人边想边做，记忆力有限Loop Engineering（多 Agent 外循环）： Discover → Plan → Execute(ReAct) → Verify(独立) → Iterate → Memory → 下一轮 Discover 特点：不同人分工，有规划有验证有记忆，持续运转
💡 核心区别：ReAct 是单 Agent 在单次会话内的推理-行动循环；Loop Engineering 是跨 Agent、跨会话的持续职能系统。ReAct 解决的是"当前这一步怎么走"，Loop Engineering 解决的是"这条路怎么一直走下去"。
六、5 类 Loop 模式详解
Loop Engineering 不是一个单一的"万能模式"，而是一套模式家族。根据任务特征，你可以选择不同的 Loop 类型。
6.1 React Loop（边做边看）
最经典的模式：观察→行动→再观察
适用场景：探索性任务、信息检索、调试排错
流程：用户提问 → Agent 思考 → 调用工具 → 观察结果 → 调整策略 → 继续举例：用户问"找出项目中所有未处理的异常" Think: 需要搜索 try-catch 块和 throws 声明 Act: grep "catch" 和 "throws" Observe: 找到 47 个 catch 块，12 个空 catch Think: 需要逐个检查空 catch 块是否有日志 Act: 读取每个空 catch 块上下文 Observe: 3 个确实没有日志 → 标记为待修复
核心特点：不需要预先规划，Agent 根据每一步的反馈动态调整。灵活但容易"短视"。
6.2 Plan and Execute Loop（先计划再分步执行）
先出蓝图，再按图施工
适用场景：多阶段复杂任务、代码重构、报告撰写
流程： Phase 1: 生成计划 输入 → Planner Agent → 分步计划（含依赖关系） Phase 2: 逐步执行 步骤1 → 执行 → 验证 → 步骤2 → 执行 → 验证 → ... Phase 3: 汇总合成 所有步骤结果 → Summarizer → 最终输出举例：重构一个支付模块 Plan: 1. 梳理现有接口和数据流（无依赖） 2. 设计新接口（依赖步骤1） 3. 实现新接口 + 测试（依赖步骤2） 4. 迁移调用方（依赖步骤3） 5. 删除旧代码（依赖步骤4） Execute: 每步在隔离 Worktree 中执行，验证通过才进下一步
核心特点：全局清晰、可预测、适合长任务。但计划可能不准，需要重规划机制。
6.3 Reflection / Evaluation Loop（做完后评估反思）
生成→批判→修改→再批判，直到通过
适用场景：高质量输出（代码审查、正式报告、方案设计）
流程： 生成草稿 → [CRITIQUE] 独立审查 → 通过？→ 输出 ↓ 不通过 基于反馈修改 → 重新审查 → ...举例：生成一份技术方案文档 Generate: Agent A 写出方案初稿 Critique: Agent B（不同模型）审查—— "缺少性能考量""安全部分没有覆盖数据加密""API 设计缺少错误码定义" Revise: Agent A 根据 3 条反馈修改 Critique: Agent B 再审查 → 只剩 1 个小问题 Revise: 修改后 → APPROVED → 输出
核心特点：质量高、能自我纠错。但成本高（LLM 调用次数翻倍），只应用于高风险输出。
关键设计：审查者必须是不同的模型或不同的 Agent，否则就是"自己给自己放水"。Panickssery et al.（2024）实验证明同一模型做批判存在系统性自我偏好。
6.4 Goal Long-running Loop（目标持续存在）
目标不消失，Loop 不停转
适用场景：持续维护任务、长期监控、渐进式改进
流程： 设定长期目标 → 持续扫描 → 发现子任务 → 执行 → 验证 → 写 Memory → 继续扫描 → ...举例：维护一个微服务项目的代码质量 Goal: "保持测试覆盖率 > 80%，每次 CI 失败自动修复" 持续循环： Discover: 定时扫描 CI 日志、覆盖率报告 Plan: 覆盖率降了 → 找出未覆盖的新代码 Execute: 在 Worktree 中写补充测试 Verify: 独立 Agent 跑测试，确认覆盖率回升 Memory: 记录"新增了哪些测试模式，下次可以直接复用" → 回到 Discover，扫描下一个问题
核心特点：没有明确的"完成"状态，Loop 一直运转。这最接近 Boris Cherny 说的"我不再 prompt Claude，我设计 loop"的状态。
关键基础设施：
-
目标持久化在磁盘上（而非上下文窗口）
-
/goal命令或等价机制保证目标不会丢失
-
Stop Hook 阻止会话在目标未完成时退出
6.5 Optimization / Self-Harness Loop（面向失败改进系统）
不是让 Agent 下次做得更好，而是改变系统让它更难犯错
适用场景：系统自我改进、Skill 优化、Harness 规则迭代
流程： 监测失败 → 诊断根因 → 改进系统（不是 Agent）→ 验证改进 → 固化举例：Agent 频繁生成不兼容的 API 版本 失败模式：Agent 3 次在 PR 中引入了不兼容的 API 变更 传统做法：告诉 Agent "下次注意兼容性" ← 没用 Self-Harness 做法： 1. 诊断根因 → Agent 不知道 API 版本兼容性规则 2. 改进系统 → 在 Harness 中增加 PostToolUse Hook： 每次 git commit 后自动运行 API 兼容性检查脚本 不通过 → 阻止 commit，返回具体错误信息 3. 验证 → 下一轮 Agent 自动被 Hook 纠正 4. 固化 → 规则写入 SKILL.md，所有项目复用
核心特点：循环改进的对象是系统本身（Harness、Skill、Memory），而不是 Agent 的"下一次表现"。这体现了 Mitchell Hashimoto 的核心哲学：“每次 Agent 犯错，改变系统让这个错误在结构上更难重复。”
七、五种 Loop 模式对比总结
| Loop 类型 | 核心流程 | 最佳场景 | 关键风险 |
|---|---|---|---|
| React Loop | Think→Act→Observe 循环 | 探索、调试、信息检索 | 循环失控、Token 爆炸 |
| Plan-Execute Loop | 规划→分步执行→汇总 | 重构、报告、多阶段任务 | 计划不准需要重规划 |
| Reflection Loop | 生成→审查→修改→再审查 | 高质量输出、代码审查 | 自我评分偏差、成本高 |
| Goal Long-running Loop | 持续扫描→发现→执行→记忆→循环 | 长期维护、持续改进 | 理解债累积、认知投降 |
| Optimization Self-Harness Loop | 失败→诊断→改进系统→固化 | 系统自我改进 | 过度约束扼杀灵活性 |
生产环境的混合使用
实际生产系统通常是多模式组合：外层：Goal Long-running Loop（持续监控代码质量） └── Discover 阶段：扫描 CI 失败、覆盖率下降 └── Plan-Execute Loop（自动修复单个问题） ├── Step 1-N：React Loop（探索+执行） └── Reflection Loop（验证修复质量） └── Iterate 阶段： ├── 修复成功 → Memory 持久化经验 └── 修复失败 3 次 → 升级给人类 └── Optimization Self-Harness Loop： └── 同类问题反复出现 → 改进 Harness 规则
八、风险与警示
Loop Engineering 的支持者们异常坦诚地指出了三大风险：
8.1 理解债（Comprehension Debt）
Loop 写得越快，你越不了解你的代码
Loop 在后台自动生成代码、自动合并 PR。当代码量快速增长而你几乎没有读过任何一行时，"理解债"就产生了。Memory 文件存在磁盘上是给人看的，不只是给机器攒经验。
对策：定期 Review——不是 Review 每一行代码（那你就回到手动了），而是 Review Loop 的决策日志和变更摘要。
8.2 认知投降（Cognitive Surrender）
Loop 越顺畅，人越停止思考
当 Loop 完美运转，最容易产生的冲动是"让它自己跑吧，我不用管了"。这正是最危险的时刻——你放弃了工程师最核心的能力：对系统有判断力。
对策：设计 Loop 时保留人工介入点。不是所有决策都自动化，关键节点设置"需要人类确认"的门控。
8.3 验证幻觉
“通过验证"≠"真的做对了”
Sub-agent 验证减少了自我评分偏差，但"验证通过"仍然是一个声明，不是数学证明。验证 Agent 可能和被验证的 Agent 共享同样的盲区。
对策：验证手段多样化——不只依赖 LLM-as-Judge，也要用确定性检查（测试通过、类型检查、Lint 无错）。最可靠的验证信号永远是机器可执行的结果。
九、总结
Loop Engineering 代表了 AI 工程范式的第四次跃迁。从 Prompt Engineering（控制怎么说）到 Context Engineering（控制看什么）到 Harness Engineering（控制运行边界）再到 Loop Engineering（设计自运转系统），人的决策权不断上移，而系统的自主性不断增强。
核心要点回顾：
-
核心模块
：Discover → Plan → Execute → Verify → Iterate，五个环节缺一不可
-
六大组件
：Automations（心跳）、Worktrees（隔离）、Skills（知识沉淀）、Plugins（连接世界）、Sub-agents（角色分离）、Memory（持久状态）
-
与 ReAct 的关系
：Loop Engineering 是给 ReAct 加上了外部结构——规划、验证、记忆、触发，让单 Agent 内循环升级为跨 Agent 跨会话的持续职能系统
-
5 类 Loop 模式
：React Loop、Plan-Execute Loop、Reflection Loop、Goal Long-running Loop、Optimization Self-Harness Loop，根据任务特征灵活选用
-
根本转变
：你的工作不再是写好每一个 Prompt，而是设计可靠、可验证、可持续运转的 Agent 工作流
💡 一句话记住 Loop Engineering：Prompt Engineering 回答"怎么问"，Context Engineering 回答"给什么信息"，Harness Engineering 回答"边界在哪"，Loop Engineering 回答——“这一切怎么自己转起来。”
学AI大模型的正确顺序，千万不要搞错了
🤔2026年AI风口已来！各行各业的AI渗透肉眼可见，超多公司要么转型做AI相关产品，要么高薪挖AI技术人才，机遇直接摆在眼前！
有往AI方向发展，或者本身有后端编程基础的朋友，直接冲AI大模型应用开发转岗超合适！
就算暂时不打算转岗，了解大模型、RAG、Prompt、Agent这些热门概念，能上手做简单项目，也绝对是求职加分王🔋
📝给大家整理了超全最新的AI大模型应用开发学习清单和资料，手把手帮你快速入门！👇👇
学习路线:
✅大模型基础认知—大模型核心原理、发展历程、主流模型（GPT、文心一言等）特点解析
✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑
✅开发基础能力—Python进阶、API接口调用、大模型开发框架（LangChain等）实操
✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用
✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代
✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经
以上6大模块，看似清晰好上手，实则每个部分都有扎实的核心内容需要吃透！
我把大模型的学习全流程已经整理📚好了！抓住AI时代风口，轻松解锁职业新可能，希望大家都能把握机遇，实现薪资/职业跃迁～
这份完整版的大模型 AI 学习资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】
汇聚全球AI编程工具，助力开发者即刻编程。
更多推荐
1
0- 0
已为社区贡献58条内容
所有评论(0)