每个智能体都需要的四种循环类型

智能体循环需要的是停止条件，而不是更多工具。没有它，循环就会烧掉 token、重复劳动，或者在没人盯着的时候擅自行动。

六月我写过能自己停下来的智能体循环：多个模型互相校验对方的工作、把成本控制住的系统。那篇文章讲的是一种模式：运行不止一个模型，让它们产生分歧，然后在路径上放一个东西去读取这种分歧。这一篇则退后一步，去看我已经构建的那些系统底层的循环类型。

上周，Claude Code 团队发布了”Getting started with loops”，给了我一套之前没有的词汇。他们把循环定义为”重复运行工作周期、直到满足停止条件的智能体”，并按照什么触发它、什么停止它、适合哪类任务，把它们分成四种类型。当我把自己现有的系统对照这套分类法时，一下子就想通了。我看到的不是一堆奇怪的个人自动化脚本，而是一整摞循环模式。

下面就是这套分类法、每种类型做什么，以及我已经上线的系统里哪些落入了每一种。

四种类型

按轮次循环。 你给提示词，智能体干活，你审查，你再给提示词。
按目标循环。 智能体一直跑，直到满足一个明确条件，或者达到轮次上限。
按时间循环。 工作按计划运行，或响应某个事件运行。
主动式循环。 有计划、自主运行。你不在场，智能体照样行动。

每种类型都在用不同方式回答同一个问题：谁来决定什么时候停？

按轮次循环：你已经在用了

你发出的每一条提示词都会启动一个。智能体收集上下文、行动、校验自己的工作，再把结果交还给你。然后你验证，写下一条提示词。你就是停止条件。

这是每个人都在不假思索地运行的循环，对于不属于日常流程的短任务来说，它够用了。

我构建的：多智能体校验循环

我上一篇文章讲了两个落入这一类的系统。

opencode-fusion 是评审团加裁判。三个智能体、三个模型、一个问题。评审团回答，裁判给它们打分，你看到的是一个综合后的答案，而不是三份逐字记录。

opencode-fusion ask \
  --panel "gpt-4o-mini,claude-3-5-haiku-20241022,gemini-2.0-flash-exp" \
  --judge "gpt-4o" \
  "Write a Python function to validate email addresses"

这些模型固定在我构建它时的版本。换成当前最新的就行，模式本身并不在乎。

agmsg bridge 是智能体之间的持久化消息传递。一个小小的桥接程序盯着一个共享的 SQLite 收件箱，在三个各自固定到不同提供商的智能体之间传递消息。它们互相发消息，直到收敛，或者走到分歧为止。

桥接程序本身不决定何时停止。它只负责搬运消息。停止条件写在智能体的指令里：用你的答案回复，或者请求澄清，三轮之后升级给人类。

按轮次循环的改进路径，是把你手动的验证搬进一个 SKILL.md，好让智能体能从头到尾校验自己的工作。定量校验效果最好。“测试通过”是可验证的。“看起来不错”不是。

## Verification Loop

**Stop condition:** Tests pass OR max 3 attempts

1. Run `npm test`
2. If pass: complete
3. If fail AND attempts < 3: fix and retry
4. If fail AND attempts >= 3: escalate

按目标循环：确定性的退出标准

按目标循环一直跑到某个特定条件被满足为止，并以轮次上限作为安全网。你在一开始就定义好”完成”，智能体拿自己的进展去对照它，而不是每一轮都来问你。

在 Claude Code 里，那就是 /goal 命令。大概像这样：

/goal Refactor the auth module to use JWT instead of sessions.
Done when: all tests pass, no linter errors, PR opened.

我构建的：OpenClaw 里的目标跟踪

OpenClaw 内置了 create_goal 和 update_goal：

create_goal({
  objective: "Migrate auth to JWT",
  token_budget: 50000
});

// Later...
update_goal({
  status: "complete",
  note: "Tests pass, PR #47 opened"
});

我用它来处理跨多个会话的多步骤工作：实现功能、写测试、更新文档。成功标准放在最前面，智能体在每一步之后检查，标准满足时目标关闭。token 预算就是成本上限。

按时间循环：计划内的工作

按时间循环按计划运行，或由某个事件触发：一个 webhook、一次文件改动、一次 push。Claude Code 在这里给了你带名字的原语。/loop 按某个间隔在本地重跑一条提示词，比如每五分钟检查一次 PR，直到 CI 变绿。/schedule 把这套流程搬到云端，让它不依赖你的机器就能运行。请注意，在我写这篇文章时 /schedule 还是一个研究预览版，所以预期它会变。

Copilot CLI 有针对同样这套本地计划模式的实验性斜杠命令。/every 或 /loop 在当前会话内计划一条重复运行的提示词、skill 或可编程斜杠命令。给它一个以秒、分钟或小时为单位的间隔。在我测试的那个 build 里，省略间隔会创建一个自我调节的计划：CLI 现在就跑，并在每一遍之后挑选下一次运行的时机。

/every 5m check PR #47 and tell me when CI is green
/every watch the deploy

对于一次性的延迟工作，/after 只计划一次提示词：

/after 30m check whether the preview deploy is live

那是会话级别的计划。对于需要脱离你的机器或你的终端会话来运行的工作，把 copilot -p 接到 GitHub Actions、cron、一个 webhook 处理器，或者任何本就掌管这套流程的调度器上。

我构建的：Dream Cycle 和自动合并

Dream Cycle 是一个夜间 AI 研究扫描器。每晚凌晨 2:00，它扫描过去七天的 arxiv，翻查 GitHub trending 里的 AI/ML 仓库，用 embedding 按相关性过滤，通过 GitHub Copilot CLI 生成改进提案，把结果提交进 git，再把一份摘要发到 Telegram。

停止条件：研究扫描完毕、提案生成完毕、git 提交成功。

成本：它跑在我当前的 Copilot 套餐上。CLI 调用从每月包含的 AI Credits 里出，这份负载留在其额度之内。如果你运行更重的夜间任务，盯紧你的 credit 用量；计划内循环正是那种会在你没注意时吃掉预算的东西。

自动合并 是内存管理。它在距上次运行至少过了 24 小时、并且已经攒下至少 5 个会话时运行。它读取 MEMORY.md 索引，扫描近期的每日日志找新信号，把它合并进按主题划分的文件，去掉重复，并把索引修剪到其大小上限之下。当前的压缩比约为 9:1，把 107 KB 的每日日志变成 11.6 KB 的主题文件。

两者的机制是一样的：OpenClaw 的 cron 拉起一个隔离会话，会话执行并写出结果，然后在完成时或超时后结束。循环里没有人类。

如果你刚起步，从只读监控开始。让一个计划内循环先观察、汇报一周，再让它写任何东西。

主动式循环：完全自主的工作

主动式循环是没有任何实时人类参与的计划内工作。流程里的每个任务在其目标满足时结束，而流程本身一直跑，直到你把它关掉。智能体不只是汇报。它分诊、修复、开 PR，事后才告诉你。

我还没构建的：issue 分诊加自动修复

计划是这样的：每 6 小时，扫描我所有仓库里的 GitHub issue。把它们分诊成 P0/P1/P2。对于 P0，拉起一个修复智能体去读 issue、提出一个方案，交给一个审查智能体去跑测试、检查风格，只有在通过时才开 PR。对于 P1，评论上复现步骤并索要日志。对于 P2，打上 help wanted 标签。如果冒出一个阻断级的 P0 就通知我。

为什么还没构建：自主的代码改动底下需要有强健的校验循环。我想先让”第二个智能体审查 PR”这个模式上线并挣得信任。之后它才成为分诊循环内部的那道闸门，而不是事后草草补上的东西。

那个顺序正是重点。先铺校验层，再谈自主。

什么时候不该做循环

在构建之前，先问四个问题。

停止条件清晰吗？ 如果你没法用一句话定义”完成”，你需要的是一个更简单的问题，而不是一个循环。

成本有边界吗？ 读取分歧的代价，永远不该超过它抓住的那个 bug。设好 token 预算，先用便宜模型跑前几遍，只在便宜模型谈不拢时才升级到昂贵模型。

人类能验证输出吗？ 如果你的回答是”我不知道怎么审查这个”，那智能体也不会知道。定量校验胜过凭眼睛看的校验。

这真的是重复性工作吗？ 一次性任务不需要循环。直接把活干了就行。

这套分类法给你什么

四种类型共享同一副骨架：一个触发器、一个工作周期、一个停止条件，以及校验。区别在于谁来决定何时停。在按轮次循环里是你。在按目标循环里是智能体，对照明确标准。在按时间循环里是那个计划。在主动式循环里又是智能体，在它自作主张行动之后。

给这件事起个名字，会改变你构建的方式。“我做了个能自我审查的东西”变成”我做了一个按轮次的校验循环，带评审团共识和三轮升级上限”，而第二句话是可复用的。你可以把这个模式提炼进一个 skill 模板，向团队里的人解释其中的取舍，也能看清你自己那摞系统里的缺口。今天我有按轮次和按时间的循环在跑。主动式是下一步，而现在我确切地知道，在安全上线它们之前，还缺哪一层校验。

在你构建这个之前的一点提醒

在你计划任何东西之前先给个警告。按轮次循环会当着你的面出错。按时间循环在凌晨 2 点没人看着时出错，而主动式循环会照着那个错误去行动。从只读开始，把预算收紧，在你亲眼看它错上几回之前，别给任何循环写入权限。

最初发布在 X 上。

本文由 Andrea Griffiths 撰写，AI 辅助翻译为中文。如有翻译问题，欢迎在 mainbranch-zh 仓库提交 PR。