一条推文引发的讨论
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 文件和一份验收清单，体验一下循环带来的效率变化。等对机制有了信心，再逐步引入目标制循环和子代理验证。
搭好循环，但别忘了自己为什么要坐在这里。工具在变，工程师的判断力不会过期。
98策略提示：文章来自网络，不代表本站观点。
