2026 年 6 月Claude Code 创建者 Boris Cherny 一句话引爆了 AI 工程圈“我不再 prompt Claude 了。我设计 loop让 loop 去 prompt Claude。”几乎同时Google Cloud AI 总监 Addy Osmani、OpenClaw 创始人 Peter Steinberger 也独立得出了相同结论。一个新的工程范式——Loop Engineering循环工程——正式进入主流视野。一、什么是 Loop EngineeringLoop Engineering 的核心思想很简单不再由人一步步给 AI 下指令而是设计一个能自我运转的循环系统让它自己发现问题、规划方案、执行任务、验证结果、持续迭代。传统 AI 编程模式人 → Prompt → AI → 结果 → 人检查 → 再 Prompt → ...Loop Engineering 模式人设计 Loop → Loop 自动发现任务 → 规划 → 执行 → 验证 → 迭代 → ...人仅在关键节点介入这不是简单的自动化脚本。Loop Engineering 的本质是将人的判断力前移到系统设计阶段——你来定义什么是完成、“什么算失败”、“什么时候该停下来”而 Loop 负责在规则内持续运转。二、核心模块Discover → Plan → Execute → Verify → IterateLoop Engineering 的核心是一个五阶段闭环几乎所有实现都遵循这个模式阶段做什么具体实现Discover发现扫描待办事项、CI 失败、Issue、历史会话找出需要做的事loop-scan、/goal、定时 cron、GitHub Actions 触发Plan规划生成可验证的 Spec定义完成标准、停止条件、预算上限loop-generate、ultragoal:goal、Plan PersonaExecute执行在隔离环境中执行任务写代码、跑构建、做修改Worktree 隔离、Developer Sub-agentVerify验证由独立 Agent非执行者重新检查每项标准尝试反驳loop-verify、ultragoal:verify、Gate Sub-agentIterate迭代验证失败则反馈给执行者重来通过则将经验写入 Memory门控循环直到VERDICT: PASS经验持久化关键洞察Verify 阶段的执行者必须是不同的 Agent甚至不同的模型。写代码的 Agent 给自己的作业打分太容易放水——这是 Loop Engineering 最重要的结构性决策。三、六大核心组件Google Cloud AI 总监Addy Osmani在 2026 年 6 月的长文中提出了 Loop Engineering 的六大组件框架。这六个组件不是并列关系而是层层叠加、互为支撑3.1 Automations自动化/心跳职责按计划触发任务让 Loop 真正循环起来。没有 AutomationLoop 就是一次性脚本。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--worktreeflagSub-agentisolation: 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 Engineering2023–2024如何做——怎么表达任务让模型输出正确“雕琢咒语的人”消息级Context Engineering2025 上半年看到什么——上下文窗口里塞什么、不塞什么“信息架构师”会话级Harness Engineering2025 下半年–2026 初如何约束和运行——Agent 能做什么、不能做什么“驯兽师”系统级Loop Engineering2026 年中如何自我运转——设计让 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 HarnessMartin 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 更快学到正确做法。核心洞察EurekAgent2026 年 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 → ObserveReActReasoning 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,000Token 爆炸每轮重新发送完整历史成本随步数平方级增长同等输出下 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 LoopThink→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-NReact Loop探索执行 └── Reflection Loop验证修复质量 └── Iterate 阶段 ├── 修复成功 → Memory 持久化经验 └── 修复失败 3 次 → 升级给人类 └── Optimization Self-Harness Loop └── 同类问题反复出现 → 改进 Harness 规则八、风险与警示Loop Engineering 的支持者们异常坦诚地指出了三大风险8.1 理解债Comprehension DebtLoop 写得越快你越不了解你的代码Loop 在后台自动生成代码、自动合并 PR。当代码量快速增长而你几乎没有读过任何一行时理解债就产生了。Memory 文件存在磁盘上是给人看的不只是给机器攒经验。对策定期 Review——不是 Review 每一行代码那你就回到手动了而是 Review Loop 的决策日志和变更摘要。8.2 认知投降Cognitive SurrenderLoop 越顺畅人越停止思考当 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 EngineeringPrompt 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%免费】
