引言：从提示词工程到循环工程的范式转变

2026 年，AI 编码领域最显著的变化之一，是“提示词工程”正在被“循环工程”（Loop Engineering）取代。Claude Code 负责人 Boris Cherny 公开表示：“我不再手动给 Claude 写提示了，我的工作是编写循环程序。”谷歌云 AI 总监 Addy Osmani 也指出，未来与编码智能体的协作方式，将不再是逐轮对话，而是设计一套能自主发现任务、执行、验证、迭代的系统。

循环工程并非凭空而来。它源于 ReAct（推理+行动）和 Reflexion（带记忆的 ReAct）两种研究范式，并融合了工业界的最佳实践。其核心思想是：将人类从“提示-阅读-再提示”的循环中抽离出来，转而成为系统的设计者。你不再亲手驱动智能体，而是构建一个自动运行的“轨道”，让智能体在其中持续进化。

然而，循环工程并非万能灵药。它烧 Token、需要时间搭建，且对验证器的依赖极高。正如 Boris Cherny 所言：“生成器从来不是瓶颈，验证器才是。”本文将系统性地拆解循环工程的原理、构件、实践步骤与常见陷阱，帮助你判断是否适合引入循环，并搭建一个真正能提升效率的最小系统。

一、循环工程的核心思想与适用场景

1.1 什么是循环工程？

循环工程是指：不再由人类逐轮向编码智能体发送指令，而是设计一套自动化系统（即“循环”），由该系统负责发现任务、分配任务、执行、验证、记录进度并决定下一步。这个循环可以是一个定时任务，也可以是一个持续运行直到满足条件的目标驱动系统。

在循环中，AI 智能体成为系统中的一个模块，而人类则退居到“规则设计者”的角色。这与传统自动化的区别在于：循环具有递归性——它能够根据上一轮的结果调整下一轮的行为，从而实现自我迭代。

1.2 开放循环与闭环

循环工程有两种基本形态：

开放循环：给智能体广泛的探索空间，只设定目标和边界条件。它可能产生新颖的输出，但 Token 消耗大，且对验证器的依赖极高。

闭环：提前定义明确的步骤、评估标准和停止条件。智能体在预设的框架内运行，成本可控，是目前落地的主力形态。

闭环的成功关键不在于自主性，而在于评估门槛。门槛决定了系统何时停止、何时重试、何时上报。没有严格门槛的闭环，本质上只是一个更昂贵的提示词调用。

1.3 四个问题：你是否需要循环工程？

在投入时间搭建循环之前，先问自己四个问题：

这个任务是重复的吗？ 一次性任务用好的提示词更划算。循环的搭建成本需要多次运行来摊薄。

有没有东西能自动判定“干砸了”？ 测试、类型检查、Linter、构建脚本——至少需要一种自动验证手段。没有自动检查，你就得手动审查每一轮输出，循环并未节省时间。

Token 预算扛得住浪费吗？ 循环会反复读取上下文、重试、试探，即使没有产出也在消耗 Token。

你打算 Review 它的产出吗？ 如果不打算，就别建循环。无人审核的循环是失控的起点。

适合循环的典型场景：CI 失败分类、依赖升级、Lint-and-Fix、Issue 转 PR 草稿。不适合的场景：一次性脚本、测试覆盖不足的代码库、Review 才是瓶颈的团队。

二、循环工程的五大核心构件

一个完整的循环由五个构件组成，外加一个记忆载体。这些构件在 Claude Code 和 OpenAI Codex 中均已内置，只是命名略有差异。

2.1 自动化（Automations）——循环的心跳

自动化是让循环“活”起来的关键。它按计划（定时或事件触发）启动任务，运行一轮后停下，等待下一次触发。关键是要写死停止条件，防止无限运行。

Codex：在 Automations 标签页创建任务，指定项目、提示词、频率和运行环境。有发现的运行进入 Triage 收件箱，无发现的自动归档。

Claude Code：通过 /loop 按间隔运行，或使用 /goal 持续运行直到条件满足（例如“test/auth 下所有测试通过”）。每一轮结束后由独立模型检查是否完成，而非执行任务的智能体自评。

2.2 工作树（Worktrees）——并行不打架

多个智能体同时运行时，文件冲突是常见失败原因。Git Worktree 为每个智能体提供独立的工作目录和分支，物理上隔离修改，最后再合并。

Codex：原生支持多线程同时访问同一仓库。

Claude Code：使用 --worktree 标志启动独立会话，或在子智能体上设置 isolation: worktree，任务结束后自动清理。

工作树解决了机械冲突，但人仍是瓶颈——你一天能 Review 多少产出，决定了能跑多少个智能体。

2.3 技能（Skills）——把项目背景写下来

智能体每次启动都是“冷启动”，需要重新解释项目框架、约定和踩过的坑。技能文件（通常是一个包含 SKILL.md 的文件夹）将这些知识固化，智能体每轮直接读取，避免重复解释。

Codex：通过 $skill-name 或 /skills 调用，也可在任务匹配时自动触发。

Claude Code：类似机制，技能文件存放于 .claude/skills/ 目录。

技能是解决“意图成本”的关键。没有技能，循环每个周期都要从零推导项目；有了技能，知识可以复利增长。

2.4 连接器（Connectors）——连上真实工具链

只能访问文件系统的循环能力有限。基于 MCP 协议构建的连接器，让智能体能够读取 Issue 追踪系统、查询数据库、调用 Staging API、在 Slack 发送消息等。

Codex 和 Claude Code：均支持 MCP 标准，为一个工具编写的连接器通常可在另一个中直接使用。

插件（Plugins）：将技能和连接器打包，方便团队成员一键安装。

连接器让循环从“说”变成“做”——自动开 PR、关联工单、跑 CI、通知频道。

2.5 子智能体（Sub-agents）——写和验分开

这是循环中最有用的结构设计。写代码的模型评估自己时过于宽容，而另一个带不同指令（甚至不同模型）的智能体，能发现第一个智能体忽略的问题。

Codex：在 .codex/agents/ 目录下通过 TOML 文件定义子智能体，可配置名称、指令、模型和推理强度。

Claude Code：在 .claude/agents/ 中定义，支持多角色分工（探索、实现、验证）。

子智能体是 /goal 命令的底层逻辑：由独立模型判断任务是否完成，而非执行者自评。在无人值守的循环中，一个你信得过的验证者，是你能放心走开的唯一理由。

2.6 记忆（Memory）——模型会忘，仓库不会

记忆是第六个构件，也是最容易被忽视的。它可以是 Markdown 文件、Linear 看板、或任何独立于单次对话之外的载体，记录已完成的工作和下一步计划。

模型在两次运行之间会遗忘所有上下文，因此记忆必须存储在磁盘上，而不是上下文窗口中。一个典型的状态文件示例如下：

markdown
Loop State · ci-triage
上次运行
2026-06-09 03:30 UTC · 7 个失败已分类，3 个草拟修复，4 个上报
进行中
claude/fix-auth-token-refresh — 本地测试通过，等 CI
今日完成
claude/bump-axios-1.7.4 → 已合并（CI 绿，依赖 loop 已验证）
上报给人
src/billing/refund.ts — 测试三种崩法，根因不明
经验教训
2026-06-08: 这台 Windows runner 上 PowerShell 撞 TLS 1.2 问题，改用 bash。

三、构建一个最小的循环：14 步路线图

3.1 第一阶段：判断是否要做（5 步）

确认任务是重复的——一次性任务用提示词更划算。

确认有自动判定“干砸了”的手段——测试、类型检查、Linter，至少一个。

确认 Token 预算扛得住浪费——循环不产出也烧钱。

确认 Agent 能跑自己写的代码——有日志、能复现、看得到哪里崩了。

确认你真打算 Review 产出——不打算，就别建。

3.2 第二阶段：搭一个最小能跑的 Loop（8 步）

先让一次手动运行稳定下来——顺序别跳。

把项目背景沉淀成一个 Skill——省得每轮从零解释。

加一个状态文件——记下做完了什么、下一步干啥。

设一道硬闸门——测试/构建过不了就自动拒。

配一个 Automation——按节奏触发，用 /goal 设停止条件。

多个 Agent 并行就上 Worktree——别让它们改同一个文件打架。

接上 Connectors——让循环能开 PR、更新 Ticket、发 Slack。

拆出 Sub-agents——写代码的和验收的分开。

3.3 第三阶段：上线后守住（1 步）

盯住每个被接受的改动的成本，定期复审权限、读 Diff、别让循环碰架构。如果接受率低于 50%，循环就在亏本。

四、验证器：循环的真正瓶颈

循环工程中，最容易忽视也最重要的部分是验证器。正如 Boris Cherny 所说：“生成器从来不是瓶颈，验证器才是。”

4.1 为什么验证器是关键？

在循环中，智能体负责生成输出，但输出的质量完全取决于验证器的严格程度。一个宽松的验证器会让错误答案传播到下一轮迭代，而一个严格的验证器则能在问题扩散前将其捕获。

以 Anthropic 公布的 Bun 项目代码迁移为例：Jarred Sumner 使用 Claude Code 将 75 万行 Zig 代码迁移到 Rust，数百个智能体并行工作，每个文件有两个审阅智能体，另有一个单独的智能体层专门驳斥其他智能体的输出。最终测试通过率达 99.8%，但 Anthropic 在公告中明确警告：“该端口尚未投入生产。”

这揭示了一个关键事实：测试通过不等于生产就绪。现有测试只覆盖已知行为，而生产环境充满了未写测试的行为。验证器的质量决定了循环输出的上限。

4.2 设计有效的验证器

一个好的验证器应具备以下特征：

可量化：输出明确的通过/失败信号，而非模糊的“看起来不错”。

独立：由与生成器不同的模型或流程执行，避免自我辩护。

渐进式：从简单的语法检查到复杂的业务逻辑验证，分层进行。

可追溯：记录验证失败的根因，供后续循环改进。

验证器不仅用于内循环（单任务自检），也用于外循环（跨会话经验沉淀）。外循环的验证器记录“上周犯过的错误”，让后续会话从一开始就避免重蹈覆辙。目前外循环仍有较大优化空间，是循环工程的价值洼地。

五、循环工程的成本、风险与安全

5.1 Token 成本

循环不是免费的。它会反复读取上下文、重试、试探，即使没有产出也在消耗 Token。建议：

仅对直接创收、长期闲置或每周重复的任务搭建循环。

严守评估关卡与终止条件——缺失质量管控和停止规则的循环，只会加速成本损耗。

5.2 三种翻车模式

假装干完了（Ralph Wiggum 循环）：智能体提前发“完成”信号，活干一半就退。原因只有一个：缺少硬闸门。

理解债务：循环越快交付你没写过的代码，“仓库里有什么”和“你理解什么”的差距就越大。总有一天，你得 Debug 一个团队里没人读过的系统。

认知投降：你慢慢不再自己判断，循环返回啥就收啥。即使有了循环，也要读 Diff、抽查闸门、不让循环碰架构。

5.3 安全红线

无人值守的循环，就是无人值守的攻击面：

生成代码未审就上线：闸门里得加 SAST、依赖审计、密钥扫描。

Skill 是注入入口：社区 17022 个 Skill 里有 520 个会泄露凭证，自动安装前先读源码。

凭证泄露进日志：生产循环关掉 Verbose 日志。

权限蔓延：今天加一个写权限，明天再加一个，每 30 天复审一次。

六、业务落地场景与收益工程

循环工程不仅适用于代码，也适用于销售、内容运营、招聘等重复性业务流程。一套完整业务循环同样包含五大模块：触发器、信号与上下文、执行动作、评估关卡、终止条件。

6.1 销售业务

盘活停滞订单：自动识别长期沉寂的客户订单，批量跟进唤醒。

极速跟进潜客：新咨询线索进入后，自动完成匹配度打分、分配对接人、生成首次沟通文案。

6.2 内容运营

系统自动挖掘选题、参考历史内容产出文稿、完成审核、全平台发布；同步统计传播数据，复盘优质内容逻辑，迭代到下一轮创作。

6.3 招聘工作

岗位发布后，AI 自动筛选简历、评估匹配度、生成沟通话术、主动对接候选人，全程跟踪面试反馈并优化策略。

6.4 收益工程的核心

循环工程的价值在于复利效应：每一轮运行都会积累经验、迭代优化，长期持续创造收益。当销售、招聘、运维等核心业务都完成循环搭建后，企业便能进入自动化运转状态。

七、总结与展望

循环工程是 AI 协作范式的自然演进。它从提示词工程中生长出来，但将重心从“写提示”转移到了“设计验证器”。正如 Addy Osmani 所说：“这件事不会让你的工作变简单，它只是把发力点挪了个位置。”

未来，随着工具链的成熟（如 Claude Code 的动态工作流、Codex 的自动化调度），编排部分将越来越简单，而验证器的设计将始终是循环工程的核心竞争力。那些能够设计出严谨评估门槛的团队，将在 AI 时代获得持续的杠杆效应。

最后，记住两条铁律：

模型会忘，但仓库不会——把知识写在磁盘上。

生成器不是瓶颈，验证器才是——把精力花在闸门上。

如果你想进一步了解循环工程在智能体协作中的应用，可以参考 AI Agent 与多智能体 和 工作流设计 的相关内容。对于验证器的具体实现，评估与测试 主题提供了更深入的讨论。

FAQ

问题：循环工程和传统自动化（如 CI/CD）有什么区别？ 传统自动化是固定的、线性的流程，每一步由人类预先定义。循环工程则具有递归性：智能体可以根据上一轮的结果调整行为，并且包含独立的验证器来判断是否重试或停止。CI/CD 是循环中的一个组件（闸门），但循环本身是一个更高级的编排系统。

问题：我的项目测试覆盖不足，还能用循环工程吗？ 不建议。循环依赖自动验证器来保证质量，测试覆盖不足意味着没有可靠的闸门。在这种情况下，循环生成的代码可能包含大量未检测的缺陷，反而增加人工审查负担。建议先提升测试覆盖率，再引入循环。

问题：子智能体是否会大幅增加 Token 消耗？ 是的。每个子智能体都需要独立的模型调用和工具操作，Token 消耗会显著增加。建议仅在需要“第二意见”的关键环节使用，例如安全审查、复杂逻辑验证。对于简单任务，一个智能体加一个轻量验证器可能更经济。

问题：如何防止循环陷入无限重试？ 设置明确的停止条件，例如“最多重试 3 次”或“连续两次迭代无改进则停止”。使用 /goal 命令时，确保条件是可验证的（如“所有测试通过”），而非模糊的“看起来不错”。同时，在状态文件中记录重试次数，超过阈值后自动上报给人。

问题：循环工程是否只适用于编码？ 不。循环工程的五大构件（触发器、上下文、执行、验证、终止）可以抽象到任何重复性业务流程，如销售跟进、内容创作、招聘筛选等。关键在于找到可自动验证的评估点。