2026 年 6 月初，
，OpenClaw 首创人 Peter Steinberger 在社交平台上写了一句话，
，大意是：别再手动给 AI 编码署理写提醒词了，
，应该去设计一个能替你写提醒词的系统。。。几天之内，
，Claude Code 的认真人 Boris Cherny 在果真场合跟上，
，他现在的日常事情就是写循环（Loop），
，让循环去调理 Claude，
，自己不再逐条下达指令。。。Google Cloud 工程总监 Addy Osmani 随后给这套做法做了系统性的拆解，
，并赋予它一个正式的名字：Loop Engineering，
，即循环工程。。。 循环工程是一种面向 AI Agent 的事情流设计要领。。。它的目的搭建一个完整的执行系统，
，这个系统能够自动发明使命、分配给 AI 署理去执行、检查产出质量、纪录进度，
，并决议下一步是继续、重试照旧阻止。。。整个历程可以在无人值守的状态下一连运转，
，直到知足预设的退出条件，
，我愿称之为 AI 界的永念头。。。 打个例如，
，若是提醒词工程（Prompt Engineering）是在棋盘上走好每一步棋，
，那循环工程就是在设计下棋的规则和裁判机制，
，让 AI 凭证规则自己完成一整盘棋。。。 只管 Loop Engineering 现在主要应用在软件开发领域，
，但它的底层逻辑并不局限于写代码。。。任何需要重复执行、重复判断的流程，
，从运维巡检、内容生产、客服分流、到数据洗濯，
，都可以用同样的思绪来构建。。。只不过编程领域的工具链最先成熟，
，实践和讨论也最麋集。。。 这是最早被普遍讨论的 AI 协作方式。。。工程师通过全心设计提醒词，
，设定角色、给出示例、加入链式思索指导，
，来让模子产出更准确的效果。。。可是这个方式的弱点是语言方式会显著影响模子输出。。。 由于它有一个结构性的问题，
，提醒词是手工制品，
，高度依赖特定模子版本和上下文长度。。。模子一更新，
，或者输入稍有转变，
，之前调好的提醒词就可能悄悄失效。。。许多团队甚至为提醒词写了回归测试，
，像测试函数一样测试语言，
，然后看着它们在每次模子升级后批量逾期。。。这种征象被称为 Prompt Drift（提醒词漂移），
，这可不是偶发情形，
，而是把确定性期望绑定在概率系统上的必定效果。。。 业界很如意识到，
，与其在语言上重复打磨，
，不如把精神放在模子的输入数据上。。。RAG 管线、向量数据库、嵌入战略陆续泛起，
，上下文窗口也从几千 Token 扩展到百万级别。。。工程师的事情重心也从「怎么说」酿成了「让模子看到什么」。。。 上下文工程解决了信息供应问题，
，但也不是完善的，
，一个被充分喂养了上下文的模子，
，若是第一次就答错了，
，它不会自己发明，
，也不会自动验证。。。整个管线里没有任何机制推动它做二次检查。。。 循环工程补上的正是这个弱点。。。它不再试图优化单次输入，
，而是围绕模子搭建一个闭环系统：模子执行操作 → 确定性工具（编译器、测试框架、Lint 工具）评估效果 → 评估反馈回传给模子 → 模子修正后再次执行 → 云云重复，
，直到通过所有预设的验证门禁。。。 工程师的角色也随之改变。。。不再是每一轮对话的加入者，
，而是这个闭环系统的设计者。。。他们要界说什么算完成、用什么来验证、失败后怎么处理、何时需要人工介入。。。 三个阶段之间并非替换关系。。。好的提醒词和富足的上下文依然有用，
，但它们已经从主要工程挑战酿成了循环内部的子模浚块。。。真正决议产出质量的，
，是循环自己的设计。。。 自动化触发是让一个循环区别于一次性剧本的要害。。。它可以是准时使命（好比每 30 分钟扫描一次依赖误差）、事务钩子（好比PR 被合并后自动启动检查）或者一连监听（每小时检查一次 Bug 反馈区）。。。 在 Claude Code 中，
，可以通过/loop设置准时巡检，
，也可以通过 GitHub Actions 实现在关闭终端后继续运行。。。Codex 则提供了一个 Automations 面板，
，可以直接设置项目、提醒词、执行频率和运行情形，
，效果自动归集到分类收件箱中。。。 当多个 AI 署理同时处理统一个代码客栈时，
，文件冲突是第一个会爆发的问题。。。Git Worktree 为每个署理提供自力的事情目录和自力的分支，
，共享统一份客栈历史，
，但相互的修改互不滋扰，
，原理就和两个工程师各自在自力分支上开发完全一致。。。 若是不把项目的约定、构建流程、已知陷阱写下来，
，AI 署理每次启动都会从零最先推导整个项目，
，然后用自信的推测填补所有认知空缺。。。这种征象被称为意图债务（Intent Debt），
，好比AI是不知道「这个客栈不可用 npm」或者「这个测试必需等服务完全启动后才华跑」，
，除非有人明确告诉它。。。 Skills 就是来解决这个问题的。。。SKILL.md写着指令和元数据，
，可选地附带剧本、示例和参考资料。。。Claude Code 和 Codex 都支持这个名堂，
，署理在启动时会自动加载匹配之 Skill，
，省去了每次重新诠释项目配景的本钱。。。 一个只能读写外地文件的署理，
，活动半径很是有限。。。通过 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 直接帮你配好」之间的差别。。。毗连器让循环的执行规模从外地文件系统扩展到了真实的工程情形。。。 写代码的模子在评判自己写的代码时，
，都挺自恋的，
，它们倾向于给出过于宽容的评价。。。它会说服自己谁人界线条件处理得没问题，
，谁人异常捕获已经够了。。。一个自力的验证署理，
，在用差别的指令集，
，甚至差别的模子之后，
，能捉住第一个署理在自我合理化后忽略掉的问题。。。 在 Claude Code 中，
，/goal下令的底层机制就是这个思绪，
，执行使命的AI Agent和判断是否完成的AI Agent是脱离的，
，后者用一个自力的小模子来评估阻止条件。。。Codex 则允许在.codex/agents/目录下用 TOML 文件界说多个署理，
，每个署理可以指定差别的模子和推理强度。。。 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 消耗应该坚持平稳或递减，
，而不是随着迭代次数线性增添。。。 动态模子路由提及来简朴，
，现实操作的时间就会有不小的贫困，
，每个模子提供商都有自己的 API 名堂和密钥系统。。。手动治理多套密钥，
，不但容易泄露，
，并且在差别模子之间切换时还需要改代码或改设置。。。 这正是 AI Gateway 这一类工具要解决的问题。。。ServBay 的 AI Gateway 在外地提供了一个统一的署理端点，
，把 Anthropic、OpenAI、Google、以及外地 Ollama 模子的请谴责部收归到一个入口。。。所有真实的 API 密钥加密存储在外地机械上，
，不会上传到任何云端服务器。。。浚开发者可以按项目签发可自力作废的虚拟密钥，
，用量和破费在一个仪表盘上一目了然。。。 关于循环工程的落地来说，
，这类 Gateway 能让「把 Lint 检查路由给低价模子、把架构决议路由给前沿模子」这件事情得可操作，
，在一个入口上切换模子，
，不必动工具侧的任何设置。。。配合 ServBay 内置的 MCP Server，
，署理可以一边通过 Gateway 按需挪用差别的模子，
，一边通过 MCP 操作外地开发情形中的数据库、Web 服务器和域名设置。。。两个能力叠加之后，
，一个循环就具备了从「读取使命 → 挪用合适模子 → 操作真真相形 → 验证效果」的完整闭环能力。。。 回合制循环（Turn-based）：最基础的形式。。。每次给署理一条指令，
，署理执行后凭证 Skill 中预界说的验收清单自查，
，启动外地服务、在浏览器中现实操作、检查控制台是否有报错、运行性能测试。。。所有检查项通事后才提交效果。。。目的制循环（Goal-based）：适用于多轮迭代才华完成的重大使命。。。通过/goal下令设定一个可量化的目的（好比 Lighthouse 评分抵达 90 分），
，加上最大重试次数。。。署理在后台重复实验、测试、修改，
，直抵达标或触及上限。。。模糊的审美判断被转换成了确定性的数字指标。。。准时制循环（Time-based）：适用于重复性日常事务。。。通过/loop设定巡检距离，
，好比每 5 分钟检查一次 PR 状态、回复代码审查意见、修复 CI 失败。。。那些高频但低创立性的事情被转化为后台守护历程。。。自动循环（Proactive）：自动化水平最高的形态，
，连系事务驱动和多署理协作。。。系统监听到新事务后自动启动处理流程，
，可以同时在多个隔离事情区中天生多套方案，
，再由自力的审查署理择优合并。。。循环工程不但是程序员的事 内容团队可以搭建一个天天准时扫描行业信息源、筛选选题线索、天生初稿摘要的循环。。。运维团队可以让循环一连监控诉警、自动执行预案、在无法自动处理时升级到人工。。。浚客服团队可以用循环做工单分类和起源回复，
，把需要深度相同的对话路由给真人。。。 这些场景的配合特征是：有明确的输入源、可界说的处理规则、可验证的完成标准。。。知足这三个条件的流程，
，都适适用循环工程的方式来组织。。。 循环工程改变了事情方式，
，但并没有把人从流程中移除。。。恰恰相反，
，随着循环的自动化水平提高，
，有三件事反而变得越发突出。。。 验证责任没有转移。。。无人值守的循环同时也是无人值守的犯错。。。即便拆分了天生署理和验证署理，
，完成仍然是一个断言而不是一个证实。。。最终为代码质量认真的照旧工程师自己。。。认知差别会加速拉大。。。循环产出代码的速率越快，
，工程师对代码库的明确就越容易脱节。。。不自动阅读循环天生的代码，
，工程师和自己维护的系统之间会形成越来越大的认知债务（Comprehension Debt）。。。恬静状态是危险状态。。。当循环自己就能跑出效果时，
，人很容易滑入一种不再形成自己判断的模式——通盘接受循环的产出。。。同样是使用循环，
，明确营业的人用它来加速已经想清晰的事情，
，不明确营业的人用它往返避思索。。。循环自己不区分这两种用法，
，但产出质量会如实反映。。。 Boris Cherny 的表达并不是说事情变轻松了，
，而是说关注点纷歧样了。。。设计循环比写提醒词更难，
，由于它要求工程师对「完成」这件事有准确的界说能力，
，对失败模式有预判，
，对本钱有约束意识，
，对何时拉人介入有苏醒的判断。。。 循环工程仍然处于早期阶段，
，工具在快速迭代，
，最佳实践还在成形的历程中。。。但它指向的偏向已经较量明确：AI 辅助编程正在从人驱动每一轮对话走向人设计系统、系统驱动对话。。。 想要实验循环工程的同砚，
，可以可以从一个小的回合制循环最先，
，给现有的 Claude Code 或 Codex 事情流加上一个 Skill 文件和一份验收清单，
，体验一下循环带来的效率转变。。。等对机制有了信心，
，再逐步引入目的制循环和子署理验证。。。