循环工程：每个AI构建者现在最需要的技能

97%的AI构建者都做错了。

他们并非不擅长提示词工程。他们完全在构建错误的东西。

一个提示词给你一个答案。一个循环给你一个系统，它能找到答案、检查它、修复错误，并在完成后通知你——无需你再动手。

以下是构建一个真正有效循环所需的一切。

为什么循环优于提示词

Anthropic公司Claude Code的创建者Boris Cherny直言不讳：

“我不再给Claude写提示词了。我有循环在运行，它们会提示Claude并决定该做什么。我的工作就是写循环。”

一位工程师上个月提交了259个拉取请求。他的AI写了每一个。他从未打开过代码编辑器。

另一个人让一个循环无人值守运行了11天。在任何人注意到之前，它烧掉了47,000美元。

相同的技术。相同的工具。一个区别：刹车。

循环实际上是什么

剥离行话。每个真正的循环都有4个部分。

→ 触发 — 启动循环的条件
→ 处理 — 每次运行时智能体做什么
→ 验证 — 循环如何检查自己的输出
→ 停止条件 — 何时才算真正完成

大多数失败的“自动化“完全缺少第3和第4部分。

一个每5分钟运行一次但没有检查器的脚本不是循环。它是一个带有观点的定时器。

一个在失败时重试200次而不升级的智能体不是持久化。它是卡住了——并且还在为此向你收费。

第一部分：触发

3种类型。其中只有一种能规模化。

固定间隔 — 无论状态如何，按时钟运行。适合每日摘要或每周依赖更新。当没有变化时浪费令牌。

事件驱动 — 当特定事件发生时触发。新的PR打开。测试失败。Webhook到达。最适合只在响应真实事件时才需要工作的情况。

动态间隔 — 智能体根据其发现来决定等待多长时间。没有变化？下次等待更长时间。发生了重要事件？5分钟后再次检查。

# Claude Code
/loop every 30 min: check src/auth for new failures

# 如果发现失败，缩小到5分钟
# 如果最后3次运行没有发现，扩大到2小时

大多数人选择一个固定数字，再也不回来调整。动态版本多花几个令牌来推理节奏。它节省了数百个决定是否运行的时间。

第二部分：处理

范围越小越好。始终如此。

一个试图在一次通过中做所有事情的处理步骤更难验证、更难调试，几乎不可能可靠。4个狭窄的步骤，每个做一件明确的事情，胜过1个做所有事情的超级提示。

这是多智能体架构的真正论据——不是因为更多智能体天生更好，而是因为狭窄的范围使验证变得可行。

一个只收集和引用来源的研究员智能体可以按一个标准检查：每个声明都有来源吗？

一个只根据需求说明编写代码的构建者智能体可以按另一个标准检查：输出匹配规范吗？

将这些合并到一个同时做这两件事的智能体中，验证就变成了一个判断调用而不是清单项。

# 糟糕：一个智能体做所有事情
agent.run("研究竞争对手，写分析报告，
           并总结带有引用的发现")

# 更好：限定的交接
researcher.run("找到5个关于竞争对手定价的最新来源。
                每个声明都要引用。输出JSON。")
builder.run(f"为创始人总结这些发现：{research_output}")
verifier.run(f"检查：这个总结中的每个声明是否都能追溯到来源列表？{summary}, {sources}")

第三部分：验证（每个人都跳过的部分）

这是将质量不断累积的循环与仅仅产生活动的循环区分开来的组件。

天真的失败点：产生输出的智能体也判断它是否好。制造错误的相同推理在审查错误时会说它看起来没问题。

一个捏造引用的智能体在审查时不会抓住自己的捏造。同样，一个写了bug的开发者在自己的代码审查中也不会抓住它。

3种实际有效的模式：

独立的验证智能体 — 不同的模型，不同的上下文，明确的指令去寻找失败而不是确认成功。

# .claude/agents/verifier.md
name: verifier
description: 对抗性审查员。在每次代码更改后运行。
developer_instructions: |
  你的工作是找到错误，而不是确认正确。
  假设前一个智能体遗漏了什么。
  输出：PASS 或 FAIL 并附上具体证据。
model: opus

对照真实来源交叉验证 — 对照可验证的来源检查具体声明。代码通过了测试套件吗？引用的统计数据出现在文档中吗？输出匹配模式吗？这是机械式验证，不是判断。

更强的模型验证更弱的模型 — 快速智能体并行生成，一个更强的模型在每次输出到达人类之前检查它。验证器不共享生成器的失败模式。

硬性规则：永远不要让循环因为被验证的东西也说自己成功而宣布成功。

第四部分：停止条件

大多数自建系统有2个状态：运行中和完成。

真正的停止条件有3个。

成功 — 验证通过。循环停止。它应该明确说明，附带什么通过了以及为什么，而不是静默终止。

有界重试 — 验证失败，重试预算未耗尽。循环再次尝试，使用来自验证器的具体修正反馈，而不是从头开始。

# Claude Code
/goal all tests in test/auth pass and lint is clean
# 运行直到条件为TRUE或max_turns被达到
# 每次重试使用前一次尝试的错误输出

升级 — 重试预算耗尽。这是几乎没有人构建的状态，但也是最重要的一个。

在同一个狭窄任务上失败4次是一个信号。这通常意味着任务定义错误，而不是系统需要第5次尝试。

# loop.config — 在你离开之前设置
max_turns: 50
max_budget_usd: 10
scope: [src/]
circuit_breaker: 3   # 相同调用连续3次 = 停止
heartbeat: STATUS.md # 静默而不是更新 = 警报

一个带有升级机制的循环将“这可能会永远运行，你永远不会知道“转化为“这要么完成，要么在有限的循环次数内准确告诉你为什么不能。“

这种转化是整个区别——一个你可以信任无人值守运行的系统和一个你必须照看的系统。

第五部分：记忆（让循环复合增长）

没有记忆的循环在第100次运行时做的质量和第1次一样
有记忆的循环会显著改善——因为每次运行的输出，包括失败和纠正它们的内容，都会反馈到下一次运行的上下文中。

# STATUS.md — 循环先读取这个，最后写入它

## 已完成
- [x] auth: 迁移到tokens v2，测试通过

## 进行中  
- [ ] billing: webhook重构 (PR #214，测试失败)

## 永远不要触碰
- 没有人类参与时不要修改infra/

这就是为什么有文档的上下文工程数字如此鲜明的原因。从没有持久上下文文档的41%错误率到拥有全面文档的3%错误率，并非模型变得更聪明。而是模型可以访问的上下文变得更好。

循环自动累积该上下文，而不是要求人类每次会话重新解释。

一个真实的循环：从开始到结束

以下是应用于一个任务的完整架构：监控竞争对手的内容以发现战略转变。

触发： 每周两次，周一和周四早上7点
处理： 搜索过去3-4天的公开内容
与6周的累积笔记进行比较
标记任何代表真正转变的内容
验证： 这对密切关注该领域的人来说是否有新闻价值？
是否有证据表明这是一种模式而非孤立数据点？
记忆： 将发现（包括空结果）写入STATUS.md
6周后：12个记录的循环，只有在累积数据中才能看到的渐进定位转变
停止： 如果发现重大转变 → 发送警报
如果3个以上循环没有发现 → 扩大搜索范围，标记

一个常规的产品更新无法通过验证器。一个持续3个以上数据点、超过4周的连贯信息转变通过了它。

一个单一的循环向你展示本周发生了什么。12个循环向你展示实际上正在改变什么。

循环实际死亡的4种方式

失控递归 — 两个智能体无限地互相提供工作。修复：步骤上限加资金上限，在第一次运行之前设置。

静默死亡 — 上下文窗口填满，循环停滞，仍然报告“进度“。修复：心跳文件必须每个周期更新，否则警报触发。

原地打转 — 没有可验证的停止条件，所以智能体随意定义“完成“。绿色测试是循环可以达到的条件。“看起来更好“则不是。

理解债务 — 循环编写你从未读过的代码越快，你离自己的项目就越远。修复：必须执行的人类审查步骤，永远不要跳过——不是因为你不信任循环，而是因为你需要保持作为其工程师的身份。

实际的技能转变

现在正在交付生产级智能体系统的人，并不是因为他们拥有别人没有的模型。

前沿模型差距正在缩小。GLM 5.2在最具挑战性的智能体编码基准上位于Claude Opus 4.8的1%以内。开放权重模型现在几乎每月都缩小差距。

不会商品化的是模型周围的架构。触发设计。验证逻辑。停止条件。记忆结构。

任何人都可以切换到这个月基准测试最好的任何模型。

但能审视一个停滞的多智能体系统并正确诊断出问题不在于模型，而在于缺少验证步骤的人要少得多。

这种诊断能力才是可规模化的。

本周使用上述框架构建1个循环。

定义触发。将处理范围限定为1个狭窄任务。构建一个不信任被验证者自己来验证自己的验证器。在第一次运行之前，限制重试次数并编写升级路径。

这就是全部。

不是模型。不是提示词。

而是两者周围的架构。