夜雨聆风
01 给「循环工程」泼一盆冷水
:::最近有句话传得很广。Claude Code 的负责人 Boris Cherny 六月在一个大会上说,他自己已经不写提示词了——现在是"另一个 Claude"在写。某个早上,他在管理几百个、有时上千个 agent。
围绕这件事长出来一个说法,叫"循环工程"(loop engineering)。它的故事分三段:2024 年是写好提示词,2025 年是并行跑 agent,2026 年是搭一个替你跑 agent 的循环。你不再敲提示词,而是设计那个替你敲提示词的系统。
前几篇我们聊过怎么搭这种循环。而 Samuel McDonnell(也是写 Dynamic Workflows 那篇的 AI 工程师)这篇,是来泼冷水的——而且我觉得他泼得很准。
他说,这个三段式框架没错,但它把真正决定"你的循环到底能不能产出东西"的那一半,藏起来了:
一个循环，是一个生成器接着一个验证器。生成器从来不是瓶颈。验证器才是。
02 那个没人细说的「验证」框
:::Samuel 把循环分成两种形状,差别就是全部。
开放循环给 agent 一大片探索空间:给个目标和条件,中间随它发挥。它能找到你没指定的路径、做出你没计划的东西——真正新颖的产出就来自这里。但它烧 token 的速度是大多数预算扛不住的,而且一旦评判标准松,它就变成一台"喷废料的机器"。循环越自由,就越取决于那个检查它工作的东西。
封闭循环则把每一步提前钉死:清晰的目标、定义好的步骤、每一步都评估、一个停止条件或者带着运行数据交还给人。agent 照样在循环,但是在你搭好的框里循环,所以能用正常预算跑下来。
他下了个很硬的判断:今天真正能出结果的,是封闭循环。人们把功劳记在"自主性"上,但自主性不是原因——评估闸门才是。是这道闸,挡住了一个自信的错误答案,不让它传进下一轮、再下一轮。
几乎所有讲循环的内容，都会画那张"发现-规划-执行-验证"的图。但几乎没人对那个"验证"框说点具体的。那个框，才是产品。其余的都是管道。
03 内循环成熟了，外循环还半残
:::他还区分了两层循环,我觉得这个分法很实用。
内循环,发生在一个任务内部。弱的 agent:改完文件,说"搞定"。强的 agent:改完文件,写个测试,跑一遍,抓到那个会挂的边界情况,修掉,再跑,确认全绿,才说"搞定"。
工具一模一样。唯一的区别,是模型有没有选择去调用那个验证器。
这个选择，就是一个 demo 和一个真结果之间的区别。
外循环,跨越多次会话。agent 这次失败了,把教训记进一个持久文件,下次的会话读到它,从一开始就做对。SKILL.md、AGENTS.md 就是这种文件的家。上下文窗口一重置,agent 就忘了,但仓库不会忘。
他说内循环已经成熟,大多数 agent 现在都会做;但外循环还只搭了一半——把对的教训、用对的颗粒度、写到对的地方,比听起来难得多,而大量价值现在正摊在这块桌子上没人捡。
两层其实都是验证。而且他补了一句我很认同的话:你没法改进一个你没在测量的循环。先把闸门仪表化,再去扩大循环——否则你只是在更快地生成错误答案。
04 那个 75 万行的移植，和最诚实的一句话
:::最值得细看的,是那个旗舰案例。
做 Bun 的 Jarred Sumner,用 Claude Code 的动态工作流,把这个运行时从 Zig 移植到了 Rust——大约 75 万行 Rust 代码,现有测试套件 99.8% 仍然通过。Anthropic 说从首次提交到合并用了 11 天,Sumner 自己说 6 天。哪个数字都很惊人。
但看它是怎么搭的:一遍专门给每个结构体字段标出正确的 Rust 生命周期;第二遍把每个文件写成行为一致的移植版,几百个 agent 并行,每个文件配两个审查 agent;还有单独一层 agent,存在的唯一目的就是去"反驳"其他 agent 产出的东西;然后一个修复循环驱动编译和测试,直到全绿。
验证不是最后那一步。验证就是整个架构。
然后是 Anthropic 自己写进公告里的那句附注:这个移植还没上生产。
Samuel 说,这是整个发布里最诚实的一句话,也是他要划重点的一句。99.8% 通过一个已有的测试套件,是个跑分结果——它只说明这次移植复现了旧测试早就描述过的行为。而生产,是那些还没人写过测试的行为。这两者之间的鸿沟,正是整个行业反复栽进去的那条沟:
一个跑成绿色的循环，不是一个正确的循环。它只是一个满足了你给它的那个验证器的循环。产出的质量，被那个验证器的质量封顶——一分都高不上去。
05 瓶颈挪位置了
:::Samuel 的结论:被当成"循环工程"在卖的那个技能是真的,只是它瞄错了系统的一半。
设计编排,现在是简单的那半,工具基本替你做了。还难、还得手动、还真正决定结果的,是评估闸门:agent 检查什么、对照什么、一个失败怎么在传播之前被抓住、什么被写下来好让下一轮赢在起跑线。他最后那句话,值得抄下来:
agent 时代的管理，不是招到能干的工人。工人既能干又便宜。它是设计他们在其中运行的约束——和管人，从来是同一件事。别再设计提示词，去设计验证者。
我基本完全认同。但想顺着补一刀,因为这个建议有个它自己没说的边界。
"设计验证者"在你能写出验证者的地方,是金科玉律——代码有测试、编译能过、lint 能跑,验证器是现成的、客观的。可偏偏在大多数人最想要循环的地方——写作、策略、设计、品味——"验证者"恰恰就是那个没法降维成一道自动闸门的人类判断。在那些领域,你以为你在搭循环,其实你只是把"自己看一眼"这件事换了个名字。
外循环那块也藏着同样的递归问题:他说"把对的教训写下来"价值最大,但难的恰恰是判断哪条教训是对的——一条错的教训被持久化下来,会毒化之后每一次运行。验证的问题,在记忆这一层又长了出来。
所以这篇我读完最大的收获不是"去搭循环",而是反过来的:在你给 AI 套上循环之前,先老实问自己一句——这件事,我有没有一个真能信的验证器?没有的话,自动化的不是产出,是更快的错。
◇ ◆ ◇
• 来源：Samuel McDonnell (@samueljmcd) — My Thoughts on Loop Engineering
