一个很多人正在经历的场景如果你经常使用 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你优化单条指令的措辞、结构、约束格式。杠杆点在这一轮怎么说。适合短任务、QA、代码片段生成。第二层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 EngineeringLoop 运行的底盘在进入 Loop 的具体结构之前有必要把 Harness 单独说清楚——这是很多人在概念上最容易混淆的一层。如果说 Context Engineering 解决的是Agent 知道什么那么 Harness Engineering 解决的是Agent 能做什么。模型本身不是 Agent。模型是大脑Harness 是身体。Claude Code 之所以能操作文件系统、执行命令、调用 MCP server、开 worktree不是因为模型有这些能力而是因为 Claude Code 给它搭了一套运行环境。这套环境——工具调用、沙箱隔离、权限控制、文件系统访问、Sub-Agent 调度——就是 Harness。模型 ≠ Agent模型 Harness AgentClaude Code 是一个 HarnessOpenAI Codex 是一个 Harness你用 LangGraph 自己搭的 orchestration 框架也是一个 Harness。你在 MCP 里注册了 GitHub、Linear、Slack这些工具接口也是 Harness 的一部分。所以本文后面要讲的五个构建块严格区分的话Worktrees、Skills、Sub-agents、Connectors 都更偏 Harness——它们是 Loop 能调度的能力边界。而 Automations、Goal 定义、Verifier 逻辑、Retry 策略、Termination 条件才是真正的 Loop。没有 HarnessLoop 无事可调度没有 LoopHarness 只是一堆静态能力在那里等着被人手动触发。为什么很多人能把 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-agentsMaker-Checker 分离这是整个 Loop Engineering 里最值得单独讨论的结构性设计。写代码的 Agent不能用来评价它自己写的代码。原因和人一样它在写代码的过程中已经对某种方案建立了路径依赖它的检查更接近于自我确认而不是批判性验证。Loop 必须把这两个角色拆分# .codex/agents/security-reviewer.tomlname security-reviewerdescription 审查代码的安全性重点关注输入验证、权限边界、敏感数据处理model o3 # 强模型高推理reasoning_effort highinstructions 你是一个对安全性持怀疑态度的审查者。你的工作不是找到代码基本没问题的理由而是找到代码为什么可能有问题。运行测试套件检查 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 基于 MCPModel 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.mdLoop 的状态文件## 待处理- [ ] test/auth/login.spec.ts 的 flaky test来自 CI run #4821- [ ] billing 模块的 deprecation warning低优先级## 进行中- [ ] 修复 rate-limit middleware 的 bypass 漏洞Sub-Agent 第 2 轮## 已完成- [x] 升级 axios 到 1.7.4PR #312已合并- [x] 修复 user-avatar 上传的 CORS 问题PR #309已合并明天早上 Automation 触发时Loop 读这个文件知道从哪里继续哪些任务不需要重新发现哪些已经放弃了。这个文件听起来太平凡了但它是所有长时间运行 Agent 都依赖的核心技巧Agent 会忘记但 repo 不会忘记。一个完整 Loop 运行起来什么样把五个构建块和状态记忆组合起来是这个形状用代码表达核心片段# 启动每日 triage loopClaude 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。一个判断框架任务特征推荐方式理由短任务一轮可以完成直接 Prompt上 Loop 的开销大于收益有明确的测试或验证标准Loop /goal能定义终止条件才能跑 Loop需要跨天、跨 session 持续进行Loop Memory单次 session 撑不住多个同类任务可以并行Loop Worktrees并发隔离的收益明显最终判断你必须亲自来Human-in-the-Loop法律/安全/业务判断不能外包给验证 Agent你还没真正理解这个模块先直接 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%免费】