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 文件和一份验收清单，，，
，体验一下循环带来的效率转变。。。等对机制有了信心，，，
，再逐步引入目的制循环和子署理验证。。。