循环工程：如何构建能够自我优化的 Agent

从手动提示到工程化循环

大多数人仍然手动操作 AI 代理

他们输入一个任务

等待一个响应

自己审查结果

自己纠正错误

然后发送另一个提示

人类仍然在负责循环

下一个阶段看起来不同

你不再一步一步地提示代理

而是围绕它构建一个循环

循环给出指令

检查输出

选择下一步行动

并持续运行，直到结果符合标准

这就是循环工程

这个想法很简单

停止花费时间手动提示代理

开始设计为你提示代理的系统

"你不应该再手动提示编码代理了，你应该设计循环来提示你的代理"

Boris Cherny 在 Anthropic 领导 Claude Code 团队

他通过自己的工作流程描述了同样的转变：

"我不再手动提示 Claude 了，我有正在运行的循环来提示 Claude 并决定做什么。我的工作是编写循环"

为什么大多数人仍然没有构建真正的循环

循环听起来很棒，直到你看到 token 账单

一个普通的代理循环会极其快速地消耗上下文：

• 一个中等规模的编码循环可能消耗 50K-200K tokens
• 一个带有编排器和专家代理的集群可能消耗 500K-2M tokens
• 一个计划每天运行的循环可能每周消耗数百万 tokens

每次重试都要消耗 tokens

每次修正都要消耗 tokens

每个验证步骤都要消耗 tokens

每个子代理都会增加一笔账单

这就是鲜为人知的隐藏限制

循环工程并不难，因为概念难以理解

它之所以难，是因为大多数用户无法承担无限的代理运行

显而易见的回应是：

"你说得轻松，你可是有无限的 OpenAI 访问权限"

这个批评是合理的

这就是为什么拥有大上下文窗口的廉价模型如此重要

为了每天运行有用的循环，你需要：

• 便宜的输入 tokens
• 便宜的输出 tokens
• 大的上下文窗口
• 可靠的工具调用
• 结构化的 JSON 输出
• 高并发
• 足够的上下文来记住之前的步骤

没有这些，循环就只是昂贵的实验

有了它们，循环就能成为处理实际工作的实用系统

旧工作流 vs 新工作流

在过去的两年里，大多数人使用代理的方式是这样的：

你发出提示

代理回应

你检查答案

你发现了一个问题

你再次提示

这可行，但无法规模化

旧工作流：

• 你编写提示
• 代理生成输出
• 你检查输出
• 你修复薄弱部分
• 你手动重复这个过程

新工作流：

• 你定义最终结果
• 循环发现需要什么
• 循环制定计划
• 代理执行工作
• 检查者评估结果
• 循环修正失败
• 系统在目标完成时停止

一个提示给代理一个单一的指令

一个循环给代理一整个工作任务

循环工程到底意味着什么

循环工程意味着围绕 AI 代理构建可重复的反馈循环

目标很直接：

从一个初始尝试到一个经过验证的结果

无需人类控制每一步

基本循环包含五个阶段：

1. 发现
2. 计划
3. 执行
4. 验证
5. 迭代

如果结果通过检查，就交付它

如果结果失败，就把它送回循环

这就是整个概念

你不是在尝试编写一个完美的提示

你是在创建一个系统

一个能不断改进不完美输出，直到它们满足要求的系统

单代理循环

循环通常有两种规模

较小的版本使用一个代理来完成整个周期

它发现需要做什么

计划工作

执行任务

审查结果

并在出现问题时再次尝试

这类似于一个人编辑自己的草稿，直到它准备好为止

单代理循环适用于：

• 聚焦的任务
• 有限的范围
• 清晰的目标
• 内容草稿
• Bug 修复
• 研究总结

一个代理

一个反馈循环

持续的自我改进

集群循环

集群循环在更大的规模上运行

一个编排器接收主要目标

它将目标分解成更小的部分

这些部分被分配给专家代理

每个专家还可以将狭窄的任务委派给更小的子代理

示例：

1目标：构建一个生产力应用
2
3编排器 拥有整个任务
4        ↓              ↓              ↓
5    研究            工程              QA
6    专家            专家              专家
7        ↓              ↓              ↓
8 网络研究员       代码编写者        测试编写者
9                  + 调试者          + Bug 追踪者

这不再是一个代理独自工作

它更接近一个从头到尾运行项目的小型自主团队

开放循环 vs 封闭循环

这是最重要的实际区别

并非所有的循环都以相同的方式工作

开放循环

开放循环是探索性的

你提供一个广泛的目标，让代理自己发现路径

代理可能会发现一些你从未指定但有用的东西

但它也可能变得昂贵和混乱

开放循环可能：

• 探索太多方向
• 浪费大量 tokens
• 高速生成低质量的工作
• 偏离实际目标
• 变得难以控制

开放循环令人兴奋

但它们通常不是最好的起点

封闭循环

封闭循环有清晰的边界

人类首先定义路径

循环仍然独立运行，但它保持在明确的规则之内

一个封闭循环包括：

• 一个清晰的目标
• 定义的阶段
• 每个阶段后的评估
• 一个停止条件
• 系统卡住时的人工交接

这是当今能创造价值的版本

它成本更低

更容易被信任

产生更干净的结果

从封闭循环开始

只有在你检查机制足够强大之后，才能让它们更开放

构建有效循环的 6 个基石

每个循环在概念上都遵循相同的五阶段周期

在实践中，六个基石使这个周期变得有用

1 自动化

自动化是循环的心跳

它启动过程，无需你记住手动启动

示例：

• 每天早上运行
• 每当 PR 打开时运行
• 文件更改后运行
• 出现新工单时运行
• 持续运行直到所有测试通过

如果你仍然自己启动每一个操作，那么这个循环做得还不够

2 工作树

当多个代理同时编辑代码时，工作树变得很重要

没有隔离，代理就会冲突

两个代理可能修改同一个文件

一个代理可能覆盖另一个代理的工作

工作树为每个代理提供一个独立的工作空间和分支

这让多个代理可以并行工作

而不会把仓库弄得一团糟

3 技能

技能存储关于项目的可复用知识

不要再在每次运行时解释相同的上下文

把重要信息写一次

让未来的每个循环都能复用

有用的技能文件可以包含：

• 产品愿景
• 架构
• 项目规则
• 构建指令
• 测试指令
• 代理绝对不能执行的操作

没有技能，每个循环都从冷启动开始

有了技能，每次运行都从之前工作中积累的知识开始

4 插件和连接器

一个只能读取本地文件的循环价值有限

连接器允许它与你的实际工作所在的工具进行交互

示例：

• GitHub
• Slack
• Linear
• Jira
• Gmail
• Google Drive
• 数据库
• Staging API

这就是以下两者之间的区别：

"这里有一个可能的修复方案"

和：

"我已经打开了 PR 并将其关联到工单"

"然后我监控了 CI 并发布了最终更新"

5 子代理

制造者和检查者不应该总是同一个代理

一个编写了代码的代理在审查时可能过于宽容

一个起草了文章的代理可能两次忽略相同的薄弱部分

使用独立的代理进行：

• 探索
• 实施
• 审查
• 测试
• 事实核查
• 最终总结

当审查者独立时，质量会提高

创造者不应该是唯一检查工作的人

6 记忆

记忆允许循环跨越多次运行继续执行

模型会忘记

仓库不会

笔记不会

项目日志不会

记忆可以存储在：

• Markdown 文件
• 项目日志
• Linear 工单
• GitHub Issues
• Obsidian 库
• 数据库
• Claude Projects

一个长期运行的循环必须记住已经尝试过什么

什么有效

什么失败了

以及什么还需要完成

没有持久记忆，循环每次都会从零开始

循环的真实例子

这些工作流程使得概念变得具体

编码循环

1读取 VISION.md + ARCHITECTURE.md
2↓
3计划下一个更改
4↓
5编辑代码
6↓
7运行测试
8↓
9如果测试失败 → 检查错误 → 修复 → 再次测试
10↓
11如果测试通过 → 总结更改
12↓
13停止

人类不需要驱动每个阶段

代理自己编写、测试、修正和验证工作

研究循环

1定义研究问题
2↓
3查找相关来源
4↓
5总结证据
6↓
7对照来源验证每个声明
8↓
9比较矛盾的信息
10↓
11创建最终的综合报告
12↓
13达到置信度阈值时停止

这比要求一个快速总结产生的结果要强大得多

内容循环

1定义主题 + 受众 + 目标
2↓
3创建初稿
4↓
5发送给评论代理
6↓
7根据评论重写
8↓
9对照成功标准评分
10↓
11如果通过 → 发布
12↓
13如果失败 → 再次重写

这个循环将一个想法转化为一个可重复的内容系统

销售外展循环

1定义理想客户画像
2↓
3查找符合画像的潜在客户
4↓
5用公司数据丰富每个潜在客户的信息
6↓
7根据标准进行资格筛选
8↓
9个性化消息
10↓
11进行质量审查
12↓
13发送或升级给人工处理

每个例子都使用相同的骨架：

目标

行动

检查

修复

重复直到工作完成

提示工程师 vs 循环工程师

这是 2026 年即将出现的新技能差距

提示工程师

提示工程师专注于更好的指令

他们改进措辞

他们产生更强的单一响应

但在代理完成后，人类仍然需要审查所有内容

人类仍然是反馈循环

循环工程师

循环工程师构建反馈系统本身

他们决定：

• 什么启动循环
• 代理接收什么上下文
• 它可以访问哪些工具
• 什么算成功
• 谁验证结果
• 过程何时必须停止
• 最终输出存储在哪里

提示工程师说：

"给我写一个函数"

循环工程师说：

"编写这个函数"

"测试它并修复它，直到所有测试通过"

"然后总结更改"

工具可能完全相同

但思维方式完全不同

最具杠杆效应的 AI 构建者正在超越更好的指令

他们正在创建能够发现和计划

执行和验证

然后在正确时刻停止的系统

简短总结

循环工程是从手动提示到自动化反馈循环的转变

转变：

• 旧方式：一次给代理一个任务
• 新方式：构建一个管理完整周期的循环

你构建的 6 个东西：

• 自动化：自动启动循环
• 工作树：让代理并行工作而不会出现文件冲突
• 技能：在每次运行中复用项目知识
• 插件和连接器：让循环访问真实工具
• 子代理：将制造者与审查者分开
• 记忆：在运行之间保留知识

2 种规模：

• 单代理循环：一个代理不断改进自己的工作
• 集群循环：编排器协调专家和子代理

2 种类型：

• 开放循环：灵活、探索性强且昂贵
• 封闭循环：有边界、可靠且成本可控

5 个阶段：

1. 发现
2. 计划
3. 执行
4. 验证
5. 迭代

真正的成本问题：

• 循环消耗 tokens 很快
• 廉价的长上下文模型使它们变得实用
• 没有便宜的 tokens，大多数用户永远无法超越实验阶段

思维模式的转变：

• 提示工程师请求 AI 输出
• 循环工程师构建交付已验证结果的系统

这才是真正的关键

停止寻找一个完美的提示

构建一个循环，让不完美的输出不断变得更好

一个可靠的循环将胜过完美的提示

如果你读到这里了

关注 @elune0x 并收藏本文

当你准备好构建自己的循环时，随时回来参考