一条推文引发的讨论

2026年6月初，OpenClaw创始人Peter Steinberger在社交平台上抛出一句话，大意是：别再做手动为AI编码助手撰写提示词这件事了，应该去设计一个能替你生成提示词的系统。几天之内，Claude Code的负责人Boris Cherny在公开场合呼应，表示自己当前的工作就是编写循环，让循环去调度Claude，自己不再逐条下达指令。紧接着，Google Cloud工程总监Addy Osmani对这套方法进行了系统性拆解，并正式命名为：Loop Engineering，即循环工程。

前脚有人发布了一条推文，后脚两位业界大咖就在公开场合跟进。这当然不是巧合，而是标志着AI编程工具在2026年迈入了一个全新阶段。

什么是循环工程

循环工程是一种面向AI Agent的工作流设计方法。它的目标非常明确——搭建一个完整的执行系统，这个系统能够自动发现任务、分配给AI编码助手去执行、检查产出质量、记录进度，并决定下一步是继续、重试还是停止。整个过程可以在无人值守的状态下持续运转，直到满足预设的退出条件。可以将其视为AI界的永动机。

打个比方，如果提示词工程是在棋盘上走好每一步棋，那么循环工程就是在设计下棋的规则和裁判机制，让AI按照规则自己完成一整盘棋。

尽管Loop Engineering目前主要应用于软件开发领域，但其底层逻辑并不局限于写代码。任何需要反复执行、反复判断的流程，从运维巡检、内容生产、客服分流到数据清洗，都可以用同样的思路来构建。只不过编程领域的工具链率先成熟，实践和讨论也最为密集。

从提示词工程到循环工程，经历了什么

回顾AI辅助编程的发展路径，可以看到三个阶段，每个阶段解决的问题不同，工程师扮演的角色也在随之变化。

第一阶段：提示词工程（Prompt Engineering）

这是最早被广泛讨论的AI协作方式。工程师通过精心设计提示词，设定角色、给出示例、加入链式思考引导，来让模型产出更准确的结果。但这个方式有一个明显的短板——措辞方式会显著影响模型输出，而且影响大得离谱。

问题在于，它有一个结构性的硬伤：提示词是手工制品，高度依赖特定模型版本和上下文长度。模型一更新，或者输入稍有变化，之前调好的提示词就可能悄悄失效。很多团队甚至为提示词编写了回归测试，像测试函数一样测试措辞，然后看着它们在每次模型升级后批量过期。这种现象被称为Prompt Drift，这可不是偶发情况，而是把确定性期望绑定在概率系统上的必然结果。

第二阶段：上下文工程（Context Engineering）

业界很快意识到，与其在措辞上反复打磨，不如把精力放在模型的输入数据上。RAG管线、向量数据库、嵌入策略陆续出现，上下文窗口也从几千Token扩展到百万级别。工程师的工作重心从“怎么说”变成了“让模型看到什么”。

上下文工程解决了信息供给问题，但远不是完美的。一个被充分喂养了上下文的模型，如果第一次就答错了，它不会自己发现，也不会主动验证。整个管线里没有任何机制推动它做二次检查。

第三阶段：循环工程（Loop Engineering）

循环工程补上的正是这个缺口。它不再试图优化单次输入，而是围绕模型搭建一个闭环系统：模型执行操作 → 确定性工具（编译器、测试框架、Lint工具）评估结果 → 评估反馈回传给模型 → 模型修正后再次执行 → 如此反复，直到通过所有预设的验证门禁。

工程师的角色也随之改变。不再是每一轮对话的参与者，而是这个闭环系统的设计者。他们需要定义什么算完成、用什么来验证、失败后怎么处理、何时需要人工介入。

三个阶段之间并非替代关系。好的提示词和充足的上下文依然有用，但它们已经从主要工程挑战变成了循环内部的子模块。真正决定产出质量的，是循环本身的设计。

一个可用的循环需要哪些组件

根据Addy Osmani的拆解，一个能投入实际使用的循环需要五个结构性组件，加上一个贯穿始终的记忆层。

1. 自动化触发（Automations）

自动化触发是让一个循环区别于一次性脚本的关键。它可以是定时任务（比如每30分钟扫描一次依赖漏洞）、事件钩子（比如PR被合并后自动启动检查）或者持续监听（每小时检查一次Bug反馈区）。

在Claude Code中，可以通过/loop设置定时巡检，也可以通过GitHub Actions实现在关闭终端后继续运行。Codex则提供了一个Automations面板，可以直接配置项目、提示词、执行频率和运行环境，结果自动归集到分类收件箱中。

没有触发机制的循环不是循环，只是一个需要手动启动的脚本。

2. 工作树隔离（Worktrees）

当多个AI编码助手同时处理同一个代码仓库时，文件冲突是第一个会爆发的问题。Git Worktree为每个助手提供独立的工作目录和独立的分支，共享同一份仓库历史，但彼此的修改互不干扰，原理就和两个工程师各自在独立分支上开发完全一致。

Codex内置了Worktree支持，每个线程自动分配隔离环境。Claude Code则通过--worktree标志或在子助手配置中设置isolation: worktree来实现同样的效果。

3. 技能文件（Skills）

如果不把项目的约定、构建流程、已知陷阱写下来，AI编码助手每次启动都会从零开始推导整个项目，然后用自信的猜测填补所有认知空白。这种现象被称为意图债务。比如AI是不知道“这个仓库不能用npm”或者“这个测试必须等服务完全启动后才能跑”，除非有人明确告诉它。

Skills就是来解决这个问题的。SKILL.md写着指令和元数据，可选地附带脚本、示例和参考资料。Claude Code和Codex都支持这个格式，助手在启动时会自动加载匹配的Skill，省去了每次重新解释项目背景的成本。

写一次，每次循环都能复用。项目经验不再随着对话窗口关闭而消失，AI自己就能把踩坑记录沉淀进系统。

4. 插件与连接器（Plugins & Connectors）

一个只能读写本地文件的助手，活动半径非常有限。通过MCP（Model Context Protocol）协议，助手可以接入外部系统，读取工单、查询数据库、调用CI管线、向Slack频道发送通知。

MCP已经成为AI助手与外部工具通信的行业标准，由Linux基金会统一治理，截至2026年3月，其SDK每月被下载超过9700万次，公开的MCP服务器数量已突破1万。

在本地开发场景中，MCP的价值体现得尤为直接。以部分内建MCP Server的工具为例，它们开放了数十个工具接口，涵盖服务启停、建站配域名和SSL、端口查询、日志读取、数据库创建与查询、各种开发语言的版本切换等操作。接入之后，Claude Code、Cursor、Codex这类编码助手可以直接调用本地开发环境中的服务，而不需要工程师手动配置或者反复解释环境状态。AI Agent说出“帮我建一个带MySQL和HTTPS的站点”，对应的MCP Server就能在几十秒内把数据库、域名、证书全部配好。

这就是“AI告诉你应该怎么配置”和“AI直接帮你配好”之间的差距。连接器让循环的执行范围从本地文件系统扩展到了真实的工程环境。

5. 子助手（Sub-agents）

循环中最有价值的架构决策，是把生成工作的助手和检查工作的AI分开。

写代码的模型在评判自己写的代码时，都挺自恋的，它们倾向于给出过于宽容的评价。它会说服自己那个边界条件处理得没问题，那个异常捕获已经够了。一个独立的验证助手，用不同的指令集，甚至不同的模型，往往能抓住第一个助手在自我合理化后忽略掉的问题。

在Claude Code中，/goal命令的底层机制就是这个思路，执行任务的AI Agent和判定是否完成的AI Agent是分开的，后者用一个独立的小模型来评估停止条件。Codex则允许在.codex/agents/目录下用TOML文件定义多个助手，每个助手可以指定不同的模型和推理强度。

子助手会消耗额外的Token，但在无人值守的循环中，一个独立的验证者是工程师敢于离开屏幕的前提。

6. 状态持久化（State）

AI编码助手在对话结束后会遗忘一切。但循环不能遗忘。它需要知道上一轮做了什么、哪些任务已完成、哪些还在排队、哪些尝试过但失败了。

状态可以是一个Markdown文件、一个Linear看板、一条GitHub Issue的评论区，任何存在于对话窗口之外的持久化存储都可以。状态层是整个循环的骨架，没有它，每次运行都是一次全新的、毫无上下文的冷启动。

一个完整循环的实际运作方式

以一个真实场景为例：某个团队的代码仓库每天都有新的CI失败、新的Issue和新的提交。如果用循环工程的思路来处理，整个流程大致如下。

一个定时自动化任务在每天早上启动，调用一个分类Skill，读取昨天的CI失败日志、未处理的Issue和最近的提交记录，把需要处理的事项写入一个状态文件。

对于每一个需要处理的事项，系统在隔离的Worktree中启动一个子助手来起草修复方案，同时启动另一个子助手对修复方案进行独立审查，对照项目Skill中记录的编码规范和现有测试用例。

审查通过后，连接器自动创建PR、关联对应的Issue，等CI跑绿后在Slack频道发送通知。审查未通过的修复方案会被退回重试，超过最大重试次数的任务则升级到人工处理队列。

状态文件在每一步都会更新，记录哪些修复已合并、哪些正在重试、哪些等待人工介入。第二天早上，新一轮循环启动时，会从状态文件中读取上一轮的进度，接着往下走。

这个流程只需要设计一次。之后每天的执行不需要任何人手动输入提示词。

循环跑起来了，问题也出现了

大多数关于循环工程的讨论，到架构设计这一步就结束了。但在真正落地的时候，Token消耗才是决定一个循环能不能上生产环境的硬门槛。

每一轮迭代都在消耗Token，而一个没有迭代上限的循环，就像一辆没有油量表的车。根据FinOps Foundation 2026年的调查数据（覆盖1192家企业，代表超过830亿美元的年度技术支出），98%的企业已经在主动管理AI相关成本，两年前这个比例只有31%。涨得这么快，说明不少团队是被账单教训过之后才开始重视的。

据传，某个团队配置了一个夜间无人值守的循环，让AI编码助手自动修复失败的测试用例。助手遇到了一个Flaky Test，这种测试本身就是间歇性失败的，并不存在真正的代码缺陷。但AI判断不了这个情况，它连续尝试了十几种修复方案，每一轮都把完整的测试输出和diff历史重新读了一遍。第二天早上，构建确实绿了，提交看起来也合理，但Token也是噌噌地涨。一个工程师花五分钟扫一眼就能判断出来的问题，AI却判断不了。

问题其实不出在循环工程上，而在于这个循环上线时就缺了预算上限、最大迭代次数和人工升级通道，就像一条CI管线如果没有超时设置，迟早会出事。

三个被验证有效的成本控制策略：

提示缓存（Prompt Caching）：把系统提示词、工具定义、不变的代码库上下文设计为可缓存的部分，让它们在每轮迭代中命中缓存，而不是作为新输入重新计费。

动态模型路由（Dynamic Model Routing）：确定性高、判断复杂度低的任务（Lint检查、格式校验、简单工具调用）交给小型低价模型，只在需要复杂推理的决策节点才调用前沿模型。不同模型之间的价格差距可以达到千倍量级。

状态压缩（State Compaction）：对循环的运行历史做摘要和压缩，而不是让模型每一轮都重新消化完整的原始日志。每轮迭代的Token消耗应该保持平稳或递减，而不是随着迭代次数线性增长。

本地AI Gateway在成本控制中的作用

动态模型路由说起来简单，实际操作的时候就会有不小的麻烦。每个模型提供商都有自己的API格式和密钥体系。手动管理多套密钥，不仅容易泄露，而且在不同模型之间切换时还需要改代码或改配置。

这正是AI Gateway这一类工具要解决的问题。部分本地AI Gateway在本地提供了一个统一的助手端点，把Anthropic、OpenAI、Google以及本地Ollama模型的请求全部收归到一个入口。所有真实的API密钥加密存储在本地机器上，不会上传到任何云端服务器。开发者可以按项目签发可独立撤销的虚拟密钥，用量和花费在一个仪表盘上一目了然。

对于循环工程的落地来说，这类Gateway能让“把Lint检查路由给低价模型、把架构决策路由给前沿模型”这件事变得可操作，在一个入口上切换模型，不用动工具侧的任何配置。配合内建的MCP Server，助手可以一边通过Gateway按需调用不同的模型，一边通过MCP操作本地开发环境中的数据库、Web服务器和域名配置。两个能力叠加之后，一个循环就具备了从“读取任务 → 调用合适模型 → 操作真实环境 → 验证结果”的完整闭环能力。

四种循环模式，自动化程度逐级递增

ClaudeDevs官方归纳了四种循环模式，适用于不同的场景和信任程度。

回合制循环（Turn-based）：最基础的形式。每次给助手一条指令，助手执行后按照Skill中预定义的验收清单自查，启动本地服务、在浏览器中实际操作、检查控制台是否有报错、运行性能测试。所有检查项通过后才提交结果。

目标制循环（Goal-based）：适用于多轮迭代才能完成的复杂任务。通过/goal命令设定一个可量化的目标（比如Lighthouse评分达到90分），加上最大重试次数。助手在后台反复尝试、测试、修改，直到达标或触及上限。模糊的审美判断被转换成了确定性的数字指标。

定时制循环（Time-based）：适用于重复性日常事务。通过/loop设定巡检间隔，比如每5分钟检查一次PR状态、回复代码审查意见、修复CI失败。那些高频但低创造性的工作被转化为后台守护进程。

主动循环（Proactive）：自动化程度最高的形态，结合事件驱动和多助手协作。系统监听到新事件后自动启动处理流程，可以同时在多个隔离工作区中生成多套方案，再由独立的审查助手择优合并。

循环工程不只是程序员的事

虽然循环工程目前的工具链主要聚焦在开发领域，但它的设计思路可以迁移到任何包含重复性判断的工作流中。

内容团队可以搭建一个每天定时扫描行业信息源、筛选选题线索、生成初稿摘要的循环。运维团队可以让循环持续监控告警、自动执行预案、在无法自动处理时升级到人工。客服团队可以用循环做工单分类和初步回复，把需要深度沟通的对话路由给真人。

这些场景的共同特征是：有明确的输入源、可定义的处理规则、可验证的完成标准。满足这三个条件的流程，都适合用循环工程的方式来组织。

循环跑得越快，人的角色越不能缺席

循环工程改变了工作方式，但并没有把人从流程中移除。恰恰相反，随着循环的自动化程度提高，有三件事反而变得更加突出。

验证责任没有转移。无人值守的循环同时也是无人值守的犯错。即便拆分了生成助手和验证助手，完成仍然是一个断言而不是一个证明。最终为代码质量负责的还是工程师本人。

认知差距会加速拉大。循环产出代码的速度越快，工程师对代码库的理解就越容易脱节。不主动阅读循环生成的代码，工程师和自己维护的系统之间会形成越来越大的认知债务。

舒适状态是危险状态。当循环自己就能跑出结果时，人很容易滑入一种不再形成自己判断的模式——全盘接受循环的产出。同样是使用循环，理解业务的人用它来加速已经想清楚的工作，不理解业务的人用它来回避思考。循环本身不区分这两种用法，但产出质量会如实反映。

Boris Cherny的表达并不是说工作变轻松了，而是说关注点不一样了。设计循环比写提示词更难，因为它要求工程师对“完成”这件事有精确的定义能力，对失败模式有预判，对成本有约束意识，对何时拉人介入有清醒的判断。

写在最后

循环工程仍然处于早期阶段，工具在快速迭代，最佳实践还在成形的过程中。但它指向的方向已经比较明确：AI辅助编程正在从人驱动每一轮对话走向人设计系统、系统驱动对话。

想要尝试循环工程的同学，可以从一个小的回合制循环开始，给现有的Claude Code或Codex工作流加上一个Skill文件和一份验收清单，体验一下循环带来的效率变化。等对机制有了信心，再逐步引入目标制循环和子助手验证。

搭好循环，但别忘了自己为什么要坐在这里。工具在变，工程师的判断力不会过期。