企业官网建设流程全解析

一个很多人正在经历的场景

如果你经常使用 Cursor、Claude Code 或 Codex，大概率经历过这样的时刻：

你让 Agent 修一个棘手的 Bug。它修改代码，运行测试，测试失败，再改，再测，再失败，再修复。十几分钟过去，日志刷了几百行，Token 烧掉几十美元，最后提交的 PR 里，仍然有一处边界条件没处理对。

你坐在屏幕前，突然意识到：从第 5 轮开始，你每次都在做同一件事——读输出、定位错误、改写 Prompt、重新发起请求。

Agent 负责执行。而你，成了系统里的人肉调度器。

查看输出↓发现问题↓修改 Prompt↓重新运行↓查看输出

这个循环本应是自动化的，但现在，你是里面最脆弱的那一环。

于是问题自然浮现：如果这些决策本身也能被系统化呢？

如果 Agent 不仅能执行任务，还能自己判断下一步该做什么、什么时候验证、什么时候重试、什么时候停止——这正是最近 AI 工程师圈子里开始密集讨论的一个方向：Loop Engineering。

2026 年 6 月，Google 工程师 Addy Osmani 发表文章专门探讨这一思路，引发广泛讨论。几乎同时，Claude Code 负责人 Boris Cherny 也在公开场合说：

“我已经不再直接提示 Claude 了。我在设计 Loop，让 Loop 去提示 Claude，然后决定接下来做什么。”

这句话背后，是 AI Agent 使用方式的一次真实变化。它值得认真地深入研究一番。

Prompt 工程死了吗？不，它变成了一个子模块

先把一个误解挑开：Loop Engineering 不是在说"Prompt 不重要了"。

它在说的是：Prompt 是对话，Loop 是系统。你把 Prompt 当工具拿着用，而 Loop Engineering 是你造一台机器，这台机器知道什么时候该用哪个 Prompt，用完之后该怎么验证，验证失败了该怎么调整，什么时候该停下来告诉你。

近三年的 AI 应用工程，其实走过了四个层次：

第一层：Prompt Engineering
你优化单条指令的措辞、结构、约束格式。杠杆点在"这一轮怎么说"。适合短任务、Q&A、代码片段生成。

第二层：Context Engineering
你优化放进上下文窗口的内容：文档、历史记录、工具定义、示例。杠杆点在"这一轮给模型看什么"。适合有文档依赖、多轮对话、RAG 链路的场景。

第三层：Harness Engineering
你开始关注 Agent 的运行环境本身：工具调用怎么配置、权限边界在哪里、沙箱隔离怎么做、MCP 如何接入、Memory 存在哪里、Sub-Agent 怎么编排。杠杆点在"Agent 能做什么"。

第四层：Loop Engineering你优化的是控制结构本身：什么时候触发、目标怎么定义、怎么验证完成、失败了走哪条路、状态存在哪里。杠杆点在"这个系统如何决定下一步做什么，以及什么时候可以停下来"。

一张图看懂四层关系

前三层没有被废弃，它们是 Loop 的组成部分。一个写得很烂的 Prompt 放进 Loop 里只会更快地产出烂代码。Context 管理不好，Loop 每次迭代都在重新"发现"项目约定，浪费 token 不说，容易走歪。Harness 搭得不扎实，Loop 能调度的能力就是残的。

Loop 是一台把 Prompt Engineering 和 Context Engineering 当燃料的引擎。Harness 是这台引擎的底盘。底盘没有，引擎点火了也跑不起来。

Harness Engineering：Loop 运行的底盘

在进入 Loop 的具体结构之前，有必要把 Harness 单独说清楚——这是很多人在概念上最容易混淆的一层。

如果说 Context Engineering 解决的是"Agent 知道什么"，那么 Harness Engineering 解决的是"Agent 能做什么"。

模型本身不是 Agent。模型是大脑，Harness 是身体。Claude Code 之所以能操作文件系统、执行命令、调用 MCP server、开 worktree，不是因为模型有这些能力，而是因为 Claude Code 给它搭了一套运行环境。这套环境——工具调用、沙箱隔离、权限控制、文件系统访问、Sub-Agent 调度——就是 Harness。

模型 ≠ Agent模型 + Harness = Agent

Claude Code 是一个 Harness，OpenAI Codex 是一个 Harness，你用 LangGraph 自己搭的 orchestration 框架也是一个 Harness。你在 MCP 里注册了 GitHub、Linear、Slack，这些工具接口也是 Harness 的一部分。

所以本文后面要讲的五个构建块，严格区分的话，Worktrees、Skills、Sub-agents、Connectors 都更偏 Harness——它们是 Loop 能调度的能力边界。而 Automations、Goal 定义、Verifier 逻辑、Retry 策略、Termination 条件，才是真正的 Loop。

没有 Harness，Loop 无事可调度；没有 Loop，Harness 只是一堆静态能力在那里等着被人手动触发。

为什么很多人能把 Claude Code 用起来、但 Agent 一旦离开人工值守就跑偏？往往不是 Prompt 写得不好，也不是 Loop 设计得不对，是 Harness 有缺口：工具权限没有收紧、沙箱边界没有定义、Sub-Agent 没有独立隔离，导致外循环稍微自动化一点，就开始产生不可控的副作用。

Harness 是 Loop 工程的地基。这一层没打牢，楼盖得越高，越容易塌。

循环的内部：ReAct 模式与 Agent 的天然迭代性

要真正理解 Loop Engineering，得先往下一层，看 Agent 本身是怎么工作的。

每一次 AI Agent 的"思考-行动"，内部都在跑一个叫ReAct的模式（Princeton + Google 提出，Reason + Act 的组合）：

Reason（推理当前状态和目标） ↓Act（调用工具、写代码、执行命令） ↓Observe（读取执行结果：stdout、stderr、测试输出） ↓Reason（根据新观察重新推理） ↓...

这个内循环已经在 Claude Code、Cursor 这类工具里自动运行。每次你发出一条指令，Agent 可能在背后已经跑了七八个 ReAct 循环——写代码、运行测试、读错误、修代码、再运行。

Loop Engineering 是在这个内循环之上，再加一层外循环。

内循环处理的是"怎么完成这一个任务"，外循环处理的是"发现哪些任务需要做、把它们分配出去、汇总结果、推进下一轮"。你不再坐在内循环里手动驱动每一步，你设计外循环的规则，然后让它自己跑。

上图展示了一个完整的 Loop 的数据流：绿色节点是状态持久化，橙色是质量关卡，每次外循环都依赖 Memory 文件来知道"上次做到哪了"。

五个构建块：一个 Loop 怎么拼出来的

Addy Osmani 的文章指出，一个可运行的 Loop 需要五个构建块，加上第六件事——状态记忆。

这五个块，在 Claude Code 和 OpenAI Codex 里都已经以不同的名字原生支持了。这说明 Loop Engineering 不是一个需要你从头搭积木的方向，而是这个行业目前工具层的默认走向。

构建块一：Automations（心跳）

Automation 是把 Loop 变成真正 Loop 而不是"你手动跑了一次"的关键。它是定时触发机制，也是 Loop 的心跳。

它解决的问题很直接：没有 Automation，你还是在驱动这件事。每次你得去想"该让 Agent 做什么了"，你就还是系统里的那个人肉调度器。

Claude Code 的/loop命令可以接受一个 cron 表达式，把一段 prompt 变成定时任务：

# 每个工作日早上 9 点，读取昨天的 CI 失败和未关闭 Issue，写进 TODO.md/loop "读取昨天的 CI 失败报告和未关闭的 issue，分析优先级， 把可以快速修复的写入 TODO.md" --schedule "0 9 * * 1-5"

但更值得关注的是/goal命令，它代表了另一种控制模式：

# 运行直到所有测试通过且 lint 干净，每轮结束由独立模型判断是否完成/goal "test/auth 目录下所有测试通过，lint 无报错"

这里有一个很重要的区分：/loop是频率驱动的——到了时间就跑，不管有没有工作要做。/goal是目标驱动的——达成条件才停，每轮结束后由一个独立的小模型来判断终止条件是否成立。

判断"是否完成"的模型，和"写代码"的模型，是两个不同的模型。这就是后面要讲的 Maker-Checker 分离，它在/goal里已经内置了。

OpenAI Codex 的 Automations tab 逻辑类似：你配置触发频率、调用的 Skill、运行环境，结果进 Triage inbox；没有发现任何工作的运行会自动归档，不打扰你。

构建块二：Worktrees（并发隔离）

当你跑超过一个 Agent 的时候，文件冲突立刻成为最大的麻烦。两个 Agent 同时写同一个文件，和两个工程师同时 commit 同一行代码，是完全一样的头疼。

Git worktree 在 Loop Engineering 里变成了核心基础设施。一个 worktree 是一个独立的工作目录，有自己的分支，共享同一个 repo 的历史。一个 Agent 的修改，在物理上无法触碰另一个 Agent 的 checkout。

Claude Code 的配置方式：

# .claude/agents/feature-agent.md---name: feature-builderisolation: worktree # 这个 sub-agent 自动获得独立的 worktreemodel: claude-sonnet # 每个 sub-agent 可以指定不同的模型---

这里有一个重要的工程认知要矫正：Worktree 解决了工具层的冲突，但解决不了你的审查瓶颈。

十个 Agent 并行产出了十条 PR，你没有时间逐条审查，就会在压力下随手合并——这比没有 Agent 更危险。你能同时跑多少个 Agent，上限不是工具的并发限制，是你自己的审查带宽。

构建块三：Skills（知识固化）

这是 Loop Engineering 里最容易被低估、但工程收益最高的一块。

每次 Agent 开始一个新对话，它对你的项目一无所知——你的命名规范、构建命令、"我们不这么做是因为上次那个事故"这些隐性知识，都需要重新告诉它。没有 Skills 的 Loop 每次都在从零推导整个项目，token 在重复消耗，判断在反复偏差。

Skill 的格式是一个包含SKILL.md的目录：

# auth-module SKILL## 这个模块的职责处理用户认证，包括 JWT 签发、刷新、撤销。## 约定- 不允许直接修改 user 表，必须通过 UserService- 测试必须包含 token 过期的边界情况- 绝对不要 log JWT payload，只 log token ID## 已知陷阱2025-11 的那次事故：直接修改 refreshToken 表导致了级联失效。现在所有 session 操作必须走 SessionManager，不能绕过。

这里有一个概念叫Intent Debt（意图债务）：Agent 每次从冷启动开始，会用它认为合理的猜测来填补你意图里的每一个空白。一个你没有明确说的命名规范，它会选一个。一个你没有说的错误处理方式，它会发明一个。这些猜测累积起来，就是你花时间去纠正的 intent debt。

Skill 是在系统外部把意图写下来的方式，一次书写，每次运行都不再产生同样的债务。知识开始跨 Loop 复利。

构建块四：Sub-agents（Maker-Checker 分离）

这是整个 Loop Engineering 里最值得单独讨论的结构性设计。

写代码的 Agent，不能用来评价它自己写的代码。原因和人一样：它在写代码的过程中已经对某种方案建立了路径依赖，它的"检查"更接近于自我确认，而不是批判性验证。

Loop 必须把这两个角色拆分：

# .codex/agents/security-reviewer.tomlname = "security-reviewer"description = "审查代码的安全性，重点关注输入验证、权限边界、敏感数据处理"model = "o3" # 强模型，高推理reasoning_effort = "high"instructions = """你是一个对安全性持怀疑态度的审查者。你的工作不是找到代码"基本没问题"的理由，而是找到代码"为什么可能有问题"。运行测试套件，检查 diff 与 CONVENTIONS.md 的一致性，对任何你无法通过测试证明是正确的部分，标记为 UNVERIFIED。""" ``````plaintext # .claude/agents/maker.md---name: feature-implementermodel: claude-sonnet # 快，适合实现isolation: worktree---实现功能，确保所有现有测试通过，输出清晰的修改说明。

两个 Agent，两套指令，两种立场。Maker 负责实现，Checker 负责证伪。

/goal命令在底层做的就是这件事：一个模型写代码，一个独立的小模型每轮结束后检查终止条件是否成立。Maker 和 Checker 的分离，被内置进了/goal的停止机制里。

Maker-Checker 分离不只是为了代码质量，它是 Loop 在无人值守时能自信说"完成"的唯一基础。一个自己判断自己完工的 Agent，其"完成"只是一个说法，不是证明。

上图展示了一次完整的 Maker-Checker 协作流程：Orchestrator 从 State Memory 中读取任务，Maker 负责实现，Checker 独立验证，结果再写回 State Memory 供下次循环使用。

构建块五：Plugins & Connectors（连接真实世界）

一个只能看文件系统的 Loop 是个玩具。

Connectors 基于 MCP（Model Context Protocol）协议构建，让 Agent 能够读写你的 Issue tracker、查询数据库、调用 staging API、向 Slack 发送消息、创建 GitHub PR。Claude Code 和 OpenAI Codex 都支持 MCP，这意味着你给一个工具写的 Connector 大概率在另一个工具里也能直接用。

这是 “Agent 告诉你它会做什么” 和 “Loop 直接把事做完” 之间的本质差距：

没有 Connectors 的 Agent："这个 bug 可以通过修改 auth.service.ts 的第 47 行来修复。建议提交一个 PR 并关联 Issue #234。"有 Connectors 的 Loop：[打开 worktree] → [修改 auth.service.ts] → [运行测试通过]→ [通过 GitHub MCP 提交 PR #318]→ [通过 Linear MCP 关联 Issue #234 并更新状态]→ [通过 Slack MCP 在 #engineering 频道发送通知]

第六件事：Memory（状态记忆）

这是最容易被忽视但最不能省的部分。

模型不记得上一次对话的任何内容。你昨天告诉 Agent 什么，今天是白板。但 Loop 是跨越多次运行的长任务，它必须知道"上次做到哪了"“哪些任务已经成功”“哪些失败了三次需要人工介入”。

这个记忆不能存在上下文窗口里，只能存在磁盘上：

# TODO.md（Loop 的状态文件）## 待处理- [ ] test/auth/login.spec.ts 的 flaky test（来自 CI run #4821）- [ ] billing 模块的 deprecation warning（低优先级）## 进行中- [ ] 修复 rate-limit middleware 的 bypass 漏洞（Sub-Agent 第 2 轮）## 已完成- [x] 升级 axios 到 1.7.4（PR #312，已合并）- [x] 修复 user-avatar 上传的 CORS 问题（PR #309，已合并）

明天早上 Automation 触发时，Loop 读这个文件，知道从哪里继续，哪些任务不需要重新发现，哪些已经放弃了。

这个文件听起来太平凡了，但它是所有长时间运行 Agent 都依赖的核心技巧：Agent 会忘记，但 repo 不会忘记。

一个完整 Loop 运行起来什么样

把五个构建块和状态记忆组合起来，是这个形状：

用代码表达核心片段：

# 启动每日 triage loop（Claude Code）/loop " 1. 读取 CI 报告（最近 24 小时失败的 run） 2. 扫描未关闭的 issue，找出被标记 'quick-win' 的条目 3. 调用 $triage-skill，分析优先级 4. 将高优先级任务写入 TODO.md，低优先级追加到 BACKLOG.md 5. 对 TODO.md 里优先级最高的 3 条，各启动一个 feature worktree" --schedule "0 9 * * 1-5"# 对每个 worktree 内的任务，运行到完成（目标驱动）/goal "test/auth 目录下所有测试通过，eslint 无报错， CONVENTIONS.md 里的命名规范完全符合" --max-turns 15

注意这里有两层：/loop在外层负责发现和调度工作，/goal在内层负责把每个具体任务跑完。这两个层次分别对应"找到什么要做"和"把它做完"，职责清晰。

看一眼你实际做了什么：你设计了一次。之后没有手动提示任何步骤。这就是 Loop Engineering 的全部意思。

三个风险，而且 Loop 越好风险越大

这里不能只说好的部分。Loop Engineering 把三个问题放大了，不是缩小了。

风险一：Token 成本的非线性累积

每次迭代都要把之前的上下文带进来，加上 Skill 文件、工具定义、历史操作记录，再乘以 Maker + Checker 两个 Sub-Agent 各自的调用，成本累积很快。

一个跑 10 次迭代的 Loop，如果每轮上下文是 20K tokens，双 Agent 架构下，单次任务很可能消耗 400K–600K tokens。这和我们之前分析 Agent 成本爆炸的底层机制一致：上下文是 O(n) 累积的，工具调用再叠加，账单很快就不好看了。

几个实际有效的控制原则：

Triage 用小模型：扫描 CI 报告、分类 issue，用便宜模型做一遍就够，不需要 Checker 参与。

只有"值得二次确认"的任务才启动双 Agent：改了一行配置文件不需要 Verifier，改了核心安全逻辑才需要。

设置硬性迭代上限：/goal加上--max-turns 15，超过就 escalate 给人工，不要无限烧钱。

按状态触发：Automation 先判断"有没有新工作"，没有就直接归档，不继续执行。

风险二：Comprehension Debt（代码理解债）

这是 Loop Engineering 最隐蔽，也最危险的副作用。

Loop 越流畅，代码合并越快，你对自己仓库里代码的实际理解就跑得越慢。以前你至少要亲手读一遍 Agent 的输出才能发下一条 prompt，现在这个动作可以被自动化绕过。

代码理解债的具体风险：你通过了 Checker 的验证，但你不知道这个修复为什么有效；下次类似问题出现，你完全依赖 Loop 而不是自己的判断；出了线上故障，你的 debug 能力比没用 AI 之前还弱，因为你不再熟悉自己的代码。

一个实践可以对抗：给自己设一个"理解配额"——每次 Loop 合并了超过 5 个 PR，强制自己逐个 review 一遍，不是为了发现问题，是为了理解发生了什么。Loop 为你做了工，你的理解不能欠债。

Comprehension Debt 是 Loop Engineering 时代新的技术债：Loop 流速越快，你对自己代码库的实际掌握就跑得越慢。这种债不会出现在 Sonarqube 的报告里，但它会在最糟糕的时机向你收账。

风险三：认知交出（Cognitive Surrender）

这是最难用技术手段防范的风险。

Loop 跑得越自动，越流畅，越容易产生一种舒适感：它在工作，我不需要有意见。你开始接受 Loop 返回的任何结果，不再问"这个方案是对的吗"，只问"CI 绿了吗"。

两个工程师可以构建完全相同的 Loop，得到完全相反的结果：一个用它来更快地完成他深刻理解的工作，另一个用它来回避理解工作本身。Loop 不知道区别，只有你知道。

设计 Loop 是解药，前提是你带着工程判断去设计它，而不是用它来逃避判断。

工程选型：什么时候用 Loop，什么时候还是直接 Prompt

不是所有任务都适合放进 Loop。一个判断框架：

关于运行时选型，有一个分层值得借鉴：Claude Code 和 OpenAI Codex 是终端 Harness Loop，适合单个工程师或小团队，有人在附近，loop 跑在本机或 CI 里。LangChain LangSmith Sandboxes + Durable Execution 是平台 Runtime Loop，适合生产环境、多租户场景、需要在你关掉笔记本后继续跑几十分钟的任务——microVM 隔离、checkpoint 断点续传、真正的持久化 cron，是 terminal/loop无法提供的。

这不是两个选一个，这是两个层次：在 Claude Code 里设计的 Loop 逻辑，在 LangSmith 的生产环境里运行。

写在最后

Loop Engineering 目前还很早。Token 成本的不确定性、验证的局限性、失控时的修复成本，都是真实存在的工程约束，不是夸张。

但这不是一个你可以选择不理解的方向。Claude Code 和 OpenAI Codex 已经把五个构建块直接内置了——Automations、Worktrees、Skills、Sub-agents、Connectors，名字不同，功能一样。两个主流工具在同一个月都把这些能力推出来，不是巧合，是这个行业对 Agent 使用范式的判断。

如果你现在在用 AI 编程工具，你已经在跑内循环（ReAct）。Loop Engineering 是你自己决定要不要同时负责外循环的设计。

设计外循环，不等于把自己从循环里移除。它的意思是：你不再是人肉调度器，你是系统架构师。

架构决策不会因为你不做而消失，只会在你不在的时候被工具随机填上。

Loop Engineering 的核心不是让 AI 代替你工作，而是让你把"什么时候做什么、做完了怎么证明"这件事，从临时决策变成有设计的系统。Prompt 是对话，Loop 是工程。

学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%免费】