如何利用循环工程构建具备自我提升能力的 AI Agents

大多数 AI Agent 的失败并非因为模型本身不够强大。

它们失败，是因为模型周围的系统不够强大。

提示词含糊不清。

工具调用出错。

Agent 重试了错误的方向。

它忘记了前两步学到的经验。

它重复着同样的错误行为。

它过早地宣告成功。

而没有人构建能够捕捉这些错误的反馈循环。

这才是真正的问题。

如果你想构建能够真正随时间改进的 AI Agent，你需要的不仅仅是更好的提示词、更多的工具或更高的自主性。

你需要的是 循环工程。

循环工程是一门设计 Agent 如何运作的学科，涉及：

• 观察发生了什么
• 评估是否有效
• 更新下一步行动
• 存储有用的反馈
• 智能地重试或升级处理
• 变得更好，而不仅仅是变得更忙

这种转变至关重要。

因为下一代有用的 AI Agent 将不再由它们在一次演示中看起来有多令人印象深刻来定义。

它们将由它们是否能够做到以下几点来定义：

• 从错误中恢复
• 从重复失败中学习
• 无需人类每轮都看护就能提高质量
• 在生产环境中保持可控、可衡量和可靠

这就是本文要探讨的内容。

想要更多像这样的实用 AI 系统吗？ ByteBuilders 分享关于 Claude、AI 工作流、提示词、自动化和实际工程系统的简短、有用的解析。

在此订阅：

https://bytebuilders.beehiiv.com/subscribe

如果你理解了循环工程，你就会停止构建那些只有在一切顺利时才能工作的脆弱 Agent。

你会开始构建那些因为被设计成能够学习而不断改进的系统。

首先，“自我改进”到底意味着什么

很多人听到“自我改进的 Agent”，会想象一个能够神奇地自我重新训练或进化成某种自主且神秘事物的系统。

这不是有用的定义。

一个自我改进的 Agent 通常要简单得多。

它是一个能够利用之前尝试的信号，在下次尝试中做出更好决策的 Agent。

这可以通过以下方式实现：

• 带有更好上下文的重试
• 基于评估的修订
• 对先前失败的记忆
• 工具使用修正
• 输出评分
• 人类反馈循环
• 规则更新
• 存储成功的模式

换句话说：

自我改进通常不是模型进化。而是循环进化。

基础模型可能保持不变。

改进的是模型周围系统的行为。

这是一个更实用、更符合工程思维的框架。

为什么大多数 Agent 不会自行改进

数量惊人的 Agent 实际上并非为改进而设计。

它们被设计为 继续运行。

这不是一回事。

当今许多 Agent 系统基本上是这样的：

1. 读取任务
2. 思考
3. 调用工具
4. 继续运行直到被停止

问题在于，这种结构通常缺乏：

• 明确的成功标准
• 失败分类
• 感知状态的重试
• 对已失败内容的记忆
• 尝试之间的比较
• 输出评估
• 升级规则

因此，Agent 不会改进。

它只是在循环。

这就是原始迭代和智能迭代之间的区别。

循环工程正是创造这种区别的关键。

循环工程是真正的架构层

理解循环工程最简单的方法是：

提示词告诉模型做什么。

循环工程告诉系统在尝试之后如何行动。

这包括诸如此类的问题：

• 工具调用失败后，Agent 应该做什么？
• 何时应该重试，何时应该切换策略？
• 允许尝试多少次？
• 哪些内容应该存储在记忆中？
• 哪些内容应该自动评估？
• 何时应由人类接管？
• 什么才算改进？

这就是为什么循环工程属于架构讨论，而不仅仅是提示词讨论。

自我改进 Agent 的核心循环

大多数有用的自我改进 Agent 遵循一个重复的结构，看起来像这样：

1目标
2  ↓
3计划
4  ↓
5行动
6  ↓
7观察结果
8  ↓
9评估质量
10  ↓
11存储信号
12  ↓
13重试 / 修订 / 升级 / 完成

这是基础。

当每次通过循环都能以有用的方式改变下一个决策时，系统就会改进。

并非每个 Agent 都需要复杂的版本。

但每个可靠的 Agent 都需要某种形式的这个循环。

原始 Agent 与循环工程 Agent 的区别

这就是转变所在。

循环工程 Agent 在模型层面不一定“更聪明”。

它只是在一个更好的系统内运行。

自我改进 Agent 的五个构建模块

如果你希望 Agent 改进，你需要一个具有结构的循环。

以下五个构建模块最为重要。

1. 明确的成功标准

如果系统不知道“好”是什么样子，它就无法朝着它改进。

成功标准可以是：

• 精确的输出格式
• 正确性阈值
• 基于依据的答案要求
• 工具完成信号
• 通过的测试结果
• 人类批准
• 特定任务评分

没有这个，Agent 就没有稳定的优化目标。

1. 评估层

评估层告诉 Agent 它的尝试是否有效。

这可以是：

• 基于规则的检查
• 模式验证
• 单元测试
• LLM 作为评判者的评分
• 检索依据检查
• 业务逻辑验证
• 人工审查

这就是“它产生了一个答案”和“它产生了一个有用的答案”之间的区别。

1. 反馈记忆

自我改进需要记忆，但不仅仅是原始历史。

Agent 需要 可用的记忆。

良好的反馈记忆包括：

• 上次失败的原因
• 之前的工具错误
• 已知的最佳成功路径
• 应避免的已知错误策略
• 用户偏好或修正
• 先前尝试的压缩摘要

并非所有上下文都应保留。

只有有助于下一个决策的上下文才应保留。

1. 策略修订

评估之后，Agent 必须决定改变什么。

这可能包括：

• 尝试新工具
• 缩小任务范围
• 提出澄清问题
• 检索更多信息
• 从行动切换到解释
• 升级给人类处理

这是系统真正变得具有适应性的地方。

1. 边界和停止条件

一个自我改进的 Agent 仍然需要控制。

否则你得到的不是改进。

而是混乱。

为以下方面设定限制：

• 重试次数
• 成本
• 延迟
• 破坏性操作
• 人类批准阈值
• 任务放弃规则

一个有边界的循环比一个不受约束的循环更有价值。

循环工程在实践中是什么样子

这是一个对许多 Agent 都行之有效的简单模式。

循环 1：尝试

Agent 使用当前上下文尝试任务。

循环 2：评估

运行检查。

示例：

• 模式验证通过了吗？
• 代码通过测试了吗？
• 答案引用了所需来源吗？
• 工具返回了正确的字段吗？

循环 3：诊断

如果失败，分类原因。

示例：

• 缺少上下文
• 错误的工具参数
• 检索失败
• 幻觉假设
• 输出不完整
• 策略冲突

循环 4：适应

改变下一次尝试。

示例：

• 检索更多上下文
• 更窄地重写任务
• 尝试不同的工具
• 添加验证规则
• 向用户询问缺失的细节

循环 5：存储有用信号

只保存有助于未来运行的内容。

然后重复。

这就是操作层面的循环工程。

循环工程 Agent 的实用图表

1用户目标
2   ↓
3任务解释器
4   ↓
5规划器
6   ↓
7工具 / 行动层
8   ↓
9结果
10   ↓
11评估器
12   ├── 通过 → 完成
13   ├── 失败：缺少上下文 → 检索更多
14   ├── 失败：工具使用不当 → 修订行动
15   ├── 失败：低置信度 → 升级
16   └── 失败：可恢复 → 带记忆重试

这就是 Agent 质量从偶然变为系统性的地方。

自我改进信号应该来自哪里

这是最重要的设计问题之一。

如果你将错误的信号输入循环，Agent 可能会朝着错误的方向优化。

改进信号的强来源包括：

确定性信号

• 测试通过或失败
• 模式验证成功或失败
• API 状态是成功或错误
• 输出包含所需字段或不包含
• 策略规则满足或违反

工作流信号

• 重试次数
• 工具延迟
• 发生失败的步骤
• 置信度阈值被跨越
• 升级频率

人类信号

• 赞 / 踩
• 修正后的输出
• 接受与拒绝的草稿
• 手动覆盖模式
• 审查者备注

比较信号

• 版本 A 与版本 B 的输出质量
• 检索变体比较
• 工具路径比较
• 多次运行后的分数改进

最好的自我改进 Agent 通常至少结合这些类别中的两个。

最好的循环改进的是工作流，而不仅仅是响应

这是设计变得更加成熟的地方。

一个弱实现使用循环仅仅是为了重新生成文本。

一个更强的实现使用循环来改进整个工作流。

这意味着 Agent 可以通过改变以下方面来改进：

• 它检索什么
• 它使用什么工具
• 步骤的顺序
• 它记住什么
• 它忽略什么
• 它是否更早地请求澄清
• 它是否更早地停止

这比“再次重写答案”强大得多。

系统在流程层面变得能够自我修正。

支持自我改进的提示词模式

提示词仍然重要。

它只需要支持循环。

以下是一些有用的提示词模式。

提示词 1：评估感知的行动提示

1你正在一个有边界的工作流中执行任务。
2你的目标不仅仅是产生一个答案，而是产生一个能够通过评估的答案。
3如果信息缺失，请询问或检索它。
4如果结果不确定，不要自信地完成。
5如果之前的尝试失败了，除非上下文发生变化，否则避免重复相同的策略。

提示词 2：失败诊断提示

1之前的尝试失败了。
2将可能的失败原因分类到以下类别之一：
3- 缺少上下文
4- 工具使用不当
5- 错误假设
6- 输出不完整
7- 格式或模式失败
8- 策略冲突
9然后提出能提高成功概率的最小下一步改变。

提示词 3：修订提示

1使用下面的评估器反馈来修订下一次尝试。
2如果相同的推理路径已经失败，不要重复。
3倾向于更狭窄、更有依据的解决方案。
4如果需要，在回答之前检索更多上下文。

提示词 4：记忆摘要提示

1将上一次尝试总结成一个简短的内存块，供下一次运行使用。
2只包括：
3- 什么失败了
4- 什么有效
5- 应该避免什么
6- 下一步应该尝试什么
7保持在 120 字以内。

这些不是魔法提示词。

它们是旨在强化循环行为的提示词。

一个简单的 Python 风格循环架构

下面是一个简化的例子，展示了循环工程在代码中可能的样子：

1MAX_ATTEMPTS = 4
2
3memory = []
4
5for attempt in range(MAX_ATTEMPTS):
6    context = build_context(task=task, memory=memory)
7    plan = agent.plan(context)
8    result = agent.act(plan)
9
10    evaluation = evaluator.check(task=task, result=result)
11
12    if evaluation.passed:
13        return {
14            "status": "success",
15            "result": result,
16            "attempt": attempt + 1,
17        }
18
19    failure_summary = agent.summarize_failure(
20        result=result,
21        evaluation=evaluation,
22    )
23
24    memory.append({
25        "attempt": attempt + 1,
26        "failure": failure_summary,
27        "suggested_fix": evaluation.next_step,
28    })
29
30    if evaluation.requires_human:
31        return {
32            "status": "escalated",
33            "reason": evaluation.reason,
34            "attempt": attempt + 1,
35            "memory": memory,
36        }
37
38return {
39    "status": "failed",
40    "reason": "max_attempts_reached",
41    "memory": memory,
42}

这有意保持简单。

重要的不是代码本身。

而是其结构：

• 尝试
• 评估
• 存储信号
• 适应
• 重试或升级

这是需要内化的模式。

循环工程最重要的应用场景

这种方法在那些第一次尝试不能保证成功的工作流中尤其有价值。

编码 Agent

非常适合循环，因为系统可以：

• 运行测试
• 检查失败
• 修订代码
• 比较输出
• 仅在验证通过时停止

支持 Agent

很有用，因为系统可以：

• 检索策略上下文
• 起草回复
• 检查依据
• 如果风险高则请求批准

研究 Agent

很有帮助，因为系统可以：

• 收集多个来源
• 识别差距
• 再次搜索
• 仅在证据充分时进行综合

文档提取 Agent

很有用，因为系统可以：

• 解析文件
• 验证模式
• 重试模糊字段
• 升级低置信度案例

运营工作流 Agent

很有价值，因为系统可以：

• 调用 API
• 检查结果
• 从部分失败中恢复
• 将异常路由给人类处理

在所有这些案例中，循环质量比一次性生成质量更重要。

循环工程中的常见错误

错误 1：将重试视为改进

更多的尝试并不自动意味着更好的学习。

如果系统重复相同的行为，它并没有改进。

它只是在循环。

错误 2：存储太多记忆

并非所有过去的上下文都有帮助。

过多的记忆会污染下一次尝试。

存储压缩的、可操作的教训——而不是原始的记录堆。

错误 3：跳过评估

没有检查，Agent 就无法知道自己是否变好了。

这是最常见的结构性失败。

错误 4：没有停止条件

一个不受约束的 Agent 并不高级。

它很昂贵。

错误 5：忽略人类反馈

如果人类不断纠正同一件事，而循环从未使用那个信号，那么系统并没有真正改进。

错误 6：对所有任务使用一个巨大的循环

不同的任务需要不同的循环。

一个支持 Agent 和一个编码 Agent 不应共享相同的重试逻辑或评估规则。

我推荐的实际构建顺序

如果你从头开始构建，请使用此顺序。

步骤 1：明确定义成功

一个好的结果是什么样的？

步骤 2：定义失败类别

这个 Agent 通常为什么失败？

步骤 3：首先构建评估器

系统将如何知道它成功或失败了？

步骤 4：设计记忆规则

哪些内容应该在尝试之间持续存在？

步骤 5：定义重试策略

第一次尝试和第二次尝试之间有什么变化？

步骤 6：添加升级逻辑

人类何时应该介入？

步骤 7：记录所有重要内容

你无法改进你没有观察到的东西。

步骤 8：仅在循环工作正常后进行优化

在核心循环稳定之前，不要过度复杂化系统。

这个顺序能让团队专注于行为而非炒作。

在称一个 Agent 为“自我改进”之前的简单清单

将此作为现实检查。

• Agent 知道成功是什么样子吗？
• 它评估每次尝试吗？
• 它从失败中存储有用的教训吗？
• 它根据反馈改变策略吗？
• 它避免盲目重复相同的失败路径吗？
• 它知道何时停止吗？
• 它知道何时升级给人类处理吗？
• 你能衡量它是否真的在变好吗？

如果大部分都缺失，那么系统可能不是自我改进的。

它只是迭代的。

最后的思考

AI Agent 的未来不仅仅是更好的提示词、更多的工具或更长的链条。

而是更好的循环。

这就是循环工程使之成为可能的原因。

它将 Agent 从一个一次性生成器转变为一个能够：

• 观察
• 评估
• 适应
• 记忆
• 智能地重试
• 在真实条件下改进的系统

这就是生产环境中 AI 自我改进的实际样子。

不是神秘。

不是魔法。

只是更好的系统设计。

如果你想要更强的 Agent，不要只问如何让它们行动。

要问如何让它们 从接下来发生的事情中学习。

那才是真正的杠杆所在。