你还在手写 Prompt？聪明的人早就用上了循环工程，AI 的自动驾驶时代来了

一条推文引发的讨论

2026 年 6 月初，OpenClaw 创始人 Peter Steinberger 在社交平台上写了一句话，大意是：别再手动给 AI 编码代理写提示词了，应该去设计一个能替你写提示词的系统。几天之内，Claude Code 的负责人 Boris Cherny 在公开场合跟上，他现在的日常工作就是写循环（Loop），让循环去调度 Claude，自己不再逐条下达指令。Google Cloud 工程总监 Addy Osmani 随后给这套做法做了系统性的拆解，并赋予它一个正式的名字：Loop Engineering，即循环工程。

三个人，三家公司，同一周，同一个结论。这当然不是巧合，而是标志着 AI 编程工具在2026年新阶段的到来。

什么是循环工程

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

打个比方，如果提示词工程（Prompt Engineering）是在棋盘上走好每一步棋，那循环工程就是在设计下棋的规则和裁判机制，让 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 代理每次启动都会从零开始推导整个项目，然后用自信的猜测填补所有认知空白。这种现象被称为意图债务（Intent Debt），比如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 的价值体现得尤为直接。以 ServBay 为例，它内置了 MCP Server，开放了 39 个工具接口，涵盖服务启停、建站配域名和 SSL、端口查询、日志读取、数据库创建与查询、各种开发语言的版本切换等操作。接入之后，Claude Code、Cursor、Codex 这类编码代理可以直接调用本地开发环境中的服务，而不需要工程师手动配置或者反复解释环境状态。AI Agent说出「帮我建一个带 MySQL 和 HTTPS 的站点」，ServBay 的 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 这一类工具要解决的问题。ServBay 的 AI Gateway 在本地提供了一个统一的代理端点，把 Anthropic、OpenAI、Google、以及本地 Ollama 模型的请求全部收归到一个入口。所有真实的 API 密钥加密存储在本地机器上，不会上传到任何云端服务器。开发者可以按项目签发可独立撤销的虚拟密钥，用量和花费在一个仪表盘上一目了然。

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

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

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

• 回合制循环（Turn-based）：最基础的形式。每次给代理一条指令，代理执行后按照 Skill 中预定义的验收清单自查，启动本地服务、在浏览器中实际操作、检查控制台是否有报错、运行性能测试。所有检查项通过后才提交结果。
• 目标制循环（Goal-based）：适用于多轮迭代才能完成的复杂任务。通过/goal命令设定一个可量化的目标（比如 Lighthouse 评分达到 90 分），加上最大重试次数。代理在后台反复尝试、测试、修改，直到达标或触及上限。模糊的审美判断被转换成了确定性的数字指标。
• 定时制循环（Time-based）：适用于重复性日常事务。通过/loop设定巡检间隔，比如每 5 分钟检查一次 PR 状态、回复代码审查意见、修复 CI 失败。那些高频但低创造性的工作被转化为后台守护进程。
• 主动循环（Proactive）：自动化程度最高的形态，结合事件驱动和多代理协作。系统监听到新事件后自动启动处理流程，可以同时在多个隔离工作区中生成多套方案，再由独立的审查代理择优合并。

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

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

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

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

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

• 验证责任没有转移。无人值守的循环同时也是无人值守的犯错。即便拆分了生成代理和验证代理，完成仍然是一个断言而不是一个证明。最终为代码质量负责的还是工程师本人。
• 认知差距会加速拉大。循环产出代码的速度越快，工程师对代码库的理解就越容易脱节。不主动阅读循环生成的代码，工程师和自己维护的系统之间会形成越来越大的认知债务（Comprehension Debt）。
• 舒适状态是危险状态。当循环自己就能跑出结果时，人很容易滑入一种不再形成自己判断的模式——全盘接受循环的产出。同样是使用循环，理解业务的人用它来加速已经想清楚的工作，不理解业务的人用它来回避思考。循环本身不区分这两种用法，但产出质量会如实反映。

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

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

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

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