别再 prompt AI 了，开始给它们设计循环吧

上个月，Peter Steinberger 发了一条推文，收获八百万浏览量：

"你不应该再 prompt 编程 agent 了。你应该设计循环，让循环来 prompt 你的 agent。"

差不多同一时间，Boris Cherny（Claude Code 的作者）在 Acquired Unplugged 播客里说了差不多的话：

"我不再 prompt Claude 了。我有循环在跑。是循环在 prompt Claude。"

然后互联网发挥了它一贯的作用：人人都在争，没人真正看到代码，话题越聊越玄乎。

我自己跑实际循环已经好几个月了。不是因为我多前沿——纯粹是手动处理那些琐碎工作实在太烦人了，就自动化了。结果发现：loop 这个思路根本不是什么高级玩家的专属技巧。只要你不再把 AI agent 当成高级的复制粘贴工具，而是当作能监控、判断、自动执行的系统，它就是很自然演化出来的东西。

三种"循环"，没人说得清楚

这个话题容易吵起来是有原因的：大家说"loop"的时候，指的可能是三件完全不同的事，区别还挺大的。

第一种：自主任务循环——本质上就是"一直跑到完"。比如 Geoffrey Huntley 的 Ralph 脚本，或者 Codex 和 Claude Code 现在原生带的 /goal 命令。这就是"设好就别管了"的模式。

第二种：定时或事件驱动的循环——在你不在电脑前的时候跑任务。Peter Steinberger 在 OpenClaw 里的 HEARTEBEAT.md 就是典型例子：一个检查清单，agent 每 30 分钟重新审视一遍。Codex 的自动化功能和 Claude Code 的定时 routine 都属于这类。

第三种：编排扩散模式——动态工作流，多个 agent 并发运行。Claude Code 的 map/reduce 风格操作属于这里。这更像是 Actor 模型，而不是什么简单循环。

我的理解？Steinberger 和 Cherny 说的是第二种，外面包着第一种的壳。我跑的循环也是这样：外面是定时触发，里面有些跑的是实验式的内部循环。这种组合才是真正有杠杆的地方。

PR 保姆：我的 Loop 设计入门

其实我早就在每个 Pull Request 加上 AI 代码审查了。Claude 先审一遍，然后 Codex 自带的审查，再加一个自定义 GitHub Action——这个 Action 我控制模型能看到什么，把完整的对话上下文和 patch diff 都拉进来。

但实际工作流程很蠢：提交 PR，等审查回来，然后把评论复制粘贴给 agent。有时候还贴截图。全是手动、重复、磨人的活儿。

有一天我问 agent："你能不能自己用 gh 客户端查审查状态？"它说可以。然后我就问："你能不能一直查着，有结果了告诉我？"

就这么一个问题，彻底改变了工作流。现在 agent 会监控审查状态的变化，拉取新上下文，分析反馈，然后实际去做处理工作。循环的终点是一个分拣决策：接受这个反馈、反驳它、或者升级给我。

这个模式可以推广：监控外部系统的状态变化，触发时唤醒，拉取新上下文，分析，行动，然后分拣。一旦你看到这个形状，你会发现到处都能用。Codex 团队自己就出了一个 babysit-pr skill，Claude Code 的文档现在也把 PR 保姆列为 /loop 命令的头牌用例。

内部循环：让 Agent 跑自己的实验

还有一种循环模式，我花了更久才体会到它的价值：实验循环。Andrej Karpathy 的 autoresearch 概念让我开始想这个——跑很多轮迭代，测量结果，保留有效的。我把它用在一个慢速 Python 路径上，一小时跑了 49 个实验，把 p95 延迟从 339ms 压到 34ms，花了大概 24 美元。

同样的模式可以对付更难的问题：调试生产环境里的 agent 行为。出了问题——Braintrust 里的异常 trace、Slack 里的用户反馈、或者我自己碰到的——我就起一个 worktree，把 trace 贴进去，然后调用测试循环。

这个循环有个特别的地方：它强制了一种模型天然会抵抗的纪律。让模型自己来，它会把"永远不做 X、Y、Z"硬编码到 system prompt 里，在你看过的这一个 trace 上过拟合。Skill 的参考资料里有研究说明为什么这招不行，而循环的契约要求一个假设加一个测试矩阵。

我需要三个 case：原来的失败 case、一个应该走同一条路的相邻正向 case、和一个应该走不同路线的反例。三四个 probe 并发跑在本地 dev 上，复原 trace 里的精确用户上下文。每次运行按工具调用、延迟、输入 token 变化和正确性打分。模型没法靠背答案蒙混——它必须真正理解。

建了循环之后，什么变了

最大的转变不是技术上的——是观念上的。你 prompt agent 的时候，你还是在驾驶。你是油门、导航、质检员。循环把这个关系翻转了。你变成了系统的架构师，系统自己跑。

这不意味着目标是完全自治。所有重要的事我还是要过手的。循环处理繁琐、监控、重复劳动。我处理真正需要判断的事。

第二个转变是：循环逼着你把成功标准说清楚。一个好用的循环有清晰的退出条件、清晰的分叉点、清晰的升级路径。你没法不定义什么叫"完成"就去建循环。这种纪律会渗透到其他事情上。

第三个：循环是可以组合的。PR 保姆和实验循环并肩工作。定时检查触发 on-call 响应。你开始积累一套协同工作的行为库，而不是一堆一次性的 prompt。

实用的起点

如果你想试试循环，从你已经自动化得很烂的东西开始。你大概有个 GitHub Action 定时跑什么，或者一个 Claude Code session 你手动重跑，或者一个涉及在工具之间复制粘贴输出的审查流程。

挑最烦的那个。问自己：我在等的到底是什么状态变化？触发的时候 agent 需要什么上下文？它需要做什么决定？

然后建这个循环。不需要多优雅。能用就行，能让你夺回自己的时间就行。

我跑的所有循环背后的完整配置、skills 和 CI 工作流都在一个公开的 snapshot 仓库里：camwest/agent-skills。它不是一个打磨好的产品——是一套随我学习演化的活系统。这才是重点。循环不是终点，是一种实践。

关于 AI agent 的话题讨论已经被玄学淹没了。 concrete 版本在这里：别再 prompt 了，开始建循环，看看让机器处理监控、你来处理意义的时候，会发生什么。