企业官网建设流程全解析

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 的核心是一个五阶段闭环，几乎所有实现都遵循这个模式：

💡关键洞察：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 改前端，另一个改数据库，互不干扰。

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 通过后通知频道」。

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 四大范式演进全景

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 加"缰绳"——定义它能做什么、不能做什么、出错时怎么纠正：

核心理念（Mitchell Hashimoto）：“每次 Agent 犯错，不是告诉它下次做得更好，而是改变系统，让这个错误在结构上更难重复。”

局限：Harness 服务于单次有限任务——人给任务 → Agent 完成 → 系统退场。它不管"下一轮任务什么时候开始"。

4.5 Environment Engineering（环境工程）

核心关注：面向什么反馈

Environment Engineering 是 2026 年新浮现的概念。它关注的是 Agent 所处的"环境"如何塑造其行为——什么样的反馈信号让 Agent 更快学到正确做法。

核心洞察（EurekAgent，2026 年 6 月）：瓶颈正从"设计 Agent 工作流"转向"设计 Agent 所处的环境"——包括权限边界、资源约束、接口设计、人工介入点。

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（基于结果重新思考） → ...（循环直到任务完成）

这个模式有三个重要贡献：

1. 推理可追踪

   ——每一步都有文字记录，出错了知道为什么

2. 动态适应

   ——可以根据观察结果调整策略

3. 工具整合

   ——自然地将工具调用融入推理流程

5.2 ReAct 的四大硬伤

但当任务变长、变复杂时，ReAct 暴露出结构性缺陷：

5.3 Loop Engineering 如何突破

Loop Engineering 不是否定 ReAct，而是给 ReAct 加上了外部结构：

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 模式对比总结

生产环境的混合使用

实际生产系统通常是多模式组合：外层：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（设计自运转系统），人的决策权不断上移，而系统的自主性不断增强。

核心要点回顾：

1. 核心模块

   ：Discover → Plan → Execute → Verify → Iterate，五个环节缺一不可

2. 六大组件

   ：Automations（心跳）、Worktrees（隔离）、Skills（知识沉淀）、Plugins（连接世界）、Sub-agents（角色分离）、Memory（持久状态）

3. 与 ReAct 的关系

   ：Loop Engineering 是给 ReAct 加上了外部结构——规划、验证、记忆、触发，让单 Agent 内循环升级为跨 Agent 跨会话的持续职能系统

4. 5 类 Loop 模式

   ：React Loop、Plan-Execute Loop、Reflection Loop、Goal Long-running Loop、Optimization Self-Harness Loop，根据任务特征灵活选用

5. 根本转变

   ：你的工作不再是写好每一个 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%免费】