图工程：一个窗口里跑 1000+ 个 agent 循环，从一句 prompt 开始

这是 @0xCodila 写的五步课，他自己定位为《Loop Engineering》的续篇：先有单个循环，再把一堆循环织成图。作者此前还有一篇更综合的《Loops, graphs, dynamic workflows and routines》，本站 2026-10-20 译过（300 个 agent，一张图，和一个会改写自己的循环）。眼前这篇更早、更聚焦：只讲图怎么画、怎么跑、在哪坏。

全文 11,000 多字符，配六张图。下面按原文的五步翻译，作者自述的表述我尽量保持原样，涉及外部案例的地方另做标注。

一、病根：把图当成了一条线

大多数人搭多步 agent，最后都搭成一条直线：第一步、第二步、第三步，每一步都等上一步跑完才开始。

很少有人去查一件事——其中一半的步骤根本不需要等。它们只是排队，一次一个任务，直到上下文窗口塞满，agent 忘了自己在干什么。

作者给了两句判断：

• 慢不是因为模型弱；
• 慢是因为你在本该画图的地方画了一条线。

二、第 0 章：图工程到底是什么

一个月前，行业里谈的是循环。作者引了 Peter Steinberger 的九字定义：一个循环就是一轮变好的过程——试一下 → 看结果 → 调整 → 再来。这是原子：一个 agent 反复改进一件事。

单个循环有个已知的失效方式。某客服团队把反馈回路绑在一个指标上：工单解决率。这个数字连涨几个月，客户满意度却在掉。机器人学会了快速关单，而不是解决问题。

这就是古德哈特定律（Goodhart’s law）。一个循环只能看见自己的指标，它问不出「目标本身对不对」，也察觉不到自己的度量在漂移。

答案不是更好的循环，而是循环组成的图——一张让各个周期互相监督、互相纠正的网。落到 agent 上就一句话：

别再写一个包办一切、顺着执行的 agent。去设计工作的形状：什么在什么之前，什么同时跑，什么必须等。

节点负责思考，边负责搬运结果。

作者提到 Claude Code 已经直接把这套工具做出来了：dynamic workflows。

三、第 1 步：看见那些并不存在的边

一张图只有两部分：

• 节点：一个工作单元——一个 agent、一个任务、一个输入、一个输出。
• 边：一条依赖——这个节点的输出喂给那个节点的输入。

所有人都犯的错，是把「然后」当成边。作者举的例子：

「把这个文件总结一下，然后告诉我天气。」

天气不读那份总结。这是两个互不相干的任务，被线性脚本无理由地串在了一起，各自白等。

习惯从这里开始养：每遇到一个「然后」，问一句——下一步真的会读上一步的输出吗？

• 会 → 真依赖，顺序保留。
• 不会 → 没有边。这个等待是浪费，让它们并排跑。

如果两个框之间没有数据流动，它们就是独立的。这份独立性是后面所有步骤的本钱。

作者还补了一句：你那个「先做 A、再做 B、再做 C」的 agent 本来就是一张图，只不过是最惨的那张——单链，C 一卡，D 永远不来。

四、第 2 步：搭出第一张图

理论到此为止，下面照着做。

开工前：

• Claude Code 版本 ≥ v2.1.154（用 claude --version 看）。
• 付费计划。Max、Team、Enterprise 上 workflow 默认开启；Pro 需要去 /config 里把 Dynamic workflows 那一行打开。

1. 打开一个你熟悉的仓库。 真项目，结果才有意义。

2. 贴这段 prompt（作者给的例子，实际用的时候把路径换掉）：

Create a workflow to audit every route file under src/routes/
for missing auth checks. Spawn one agent per file, then run an
independent verifier on each finding before reporting.
Analyze a maximum of 20 files to start.

「最多 20 个文件」这句是为了让第一次跑起来便宜。

3. 看 “workflow” 亮起来。 Claude Code 会高亮提示 “Dynamic workflow requested.”，这是图正在被搭起来的信号，不是一次普通对话。

4. 批准计划。 Claude 会写一段 JavaScript 编排脚本，先把阶段列给你看。读完点 “Yes, run it.”

5. 放过这群 agent 去跑。 一个文件一个 agent，并行，你的会话保持空闲。输入 /workflows 可以实时看：范围、扇出、验证、汇总。

6. 读那一份答案。 不是二十个独立对话，而是一份报告——因为中间结果待在脚本的变量里，没有进你的上下文。

一句话，十几个 agent。这就是图。

关于「零 token」的说法

作者专门澄清了这一点：协调脚本是代码，所以 agent 之间传结果不像聊天交接那样反复重花上下文。

但 agent 本身仍然花钱。一次 workflow 的开销明显高于一次普通会话——省的是协调，不是工作。所以先小范围跑，盯住用量，再放大。

把它变成你自己的

跑得好的时候按 s，它存进 ~/.claude/workflows，之后按名字就能重跑。

然后换任务、留形状：把「缺 auth 校验」换成「未处理的 promise」，或者「超过 100 行的函数」。

五、规模天花板：1000 个 agent，16 个同时跑

一次 workflow 最多扇出到 1,000 个 agent，其中最多 16 个并发。

「一个窗口里跑 1000+ 循环」这个说法就是从这儿来的——不是比喻，是功能本身的上限。作者说，规模就是重点：一千个 agent 意味着一件单个上下文永远装不下的活，比如整个代码库一次性审计、一次触及所有文件的迁移、一次跑一千个角度的搜索。

16 并发的限制只意味着队伍分波推进，一千个照样啃完，不需要你逐个盯着。

他的建议：先 20 个起步，看清一次运行的行为和成本，再放开。

六、第 3 步：真正会坏的地方

图搭出来了，接下来是真实场景里翻车的两种方式。

失败一：图在跟自己达成一致

agent 检查自己的工作时会放水——模型偏爱自己的输出。

所以要在边上放一个验证器：一个独立的节点，确认结论后才允许它往下流。但这里有个几乎没人点破的前提：验证器需要干净的上下文。

如果你把它塞进执行者那条对话里，它干的不叫验证，叫「用另一种字体跟自己达成一致」。作者的原话是：一群共享同一上下文的 agent，就是一个穿了马甲的循环——它照样失效，只是更晚、更贵，而且一路绿灯。

所以验证器必须是最新的节点：自己的上下文，检查的是真信号——不是「agent 说自己做完了」，而是「测试到底过没过」。

失败二：agent 互相踩

这不是假设。Bun 团队第一次把大规模的移植分给很多 agent 时，运行层面直接失败：agent 在同一个工作区里用共享的 git 命令，互相覆盖了对方的改动。

修法在结构上，不在提示词上：禁掉不安全的命令，给每一组独立的 worktree。

这就是并行真正的教训——两个 agent 写同一个文件会打架。扇出之前先回答三个问题：

• 每个 agent 在哪里干活？
• 结果怎么合并？
• 两个结论冲突时听谁的？

没有这份计划的图不但扩不了规模，坏得还更快。

七、第 4 步：本周可以搭的六种图

方法固定为四拍：找到真依赖 → 扇出 → 在独立上下文里验证 → 隔离工作区。下面六种是同一个形状换了任务，改任务那一行就行。

图	做什么	关键点
安全巡检	一个文件一个 agent 找缺失的鉴权，验证器逐条确认	就是第 2 步搭的那个
带引用的调研	用 /deep-research，问题拆角度、并行搜、写之前互相反驳	官方自带
移植一个模块	逐个文件推进，测试当闸门，失败的循环回去	测试是硬信号
对抗式 diff 审查	按改动大小分流：小的单趟过，大的全并行审	成本可控
定时的生态扫描	存一次，之后按名字重跑	靠 s 存盘
规模未知的发现任务	多个 finder 并行，每个结果与已见过的全部比对，连续两轮无新发现才停	停止条件要写死

八、天花板长什么样：Bun 移植的真实账

作者把上限摊开给读者看，数据来自 Simon Willison 的记录（原文）：

项	数字
工作流数量	约 50 个
并发峰值	64 个 agent
代码规模	约 535,000 行 Zig → 100 万行以上 Rust（约 53.5 万行）
耗时	11 天
用量成本	约 165,000 美元（约 16.5 万）

此外有两个不那么好看的注脚：需要人设计并全程盯着；也引来了公开质疑——这么多 AI 写的代码，能不能被安全地审阅。

作者的结论很直白：规模是真的，价格和监管也是真的。

九、第 5 步：让图不自欺的锚点

光有拓扑结构买不到真相。

一群 agent 互相确认、谁都没碰过真实世界里的东西，失败方式和单个循环一模一样——只是零件更多。

图需要锚点：那些没法被商量的节点。

• 真的跑过的测试——不是「应该能过」，是过了。
• 对证据做验证，而不是对感觉做验证。
• 冻结的规则——永远不许 agent 自己调，因为优化器最先动手的就是这些。

一句话：一张图的可信度，等于它里面那些拒绝移动的东西。

十、什么时候不该画图

大多数任务不是图。用不上还硬画，只是烧钱并且在多开几条失败路径。

这四种情况跳过图：

• 任务小或孤立。 加一个函数、修一个 bug，workflow 纯属开销，单个 agent 更快更便宜。
• 需要紧盯着。 你想每一步都读过、批准了才放下一步，而图的意义恰恰是「不用你盯」。
• 你还不知道自己在找什么。 探索性的活需要一个能被你随时拨方向的 agent，不是一支在你理解问题之前就锁死计划的队伍。
• 步骤之间真的互相依赖。 每一步都读上一步的输出，那就是真正的链，并行没有着力点。给串行任务硬套图，只增加协调成本，没有加速。

判断方法就是第 1 步：如果你找不出两个之间没有箭头的框，那就没有图可画。 它是循环，而循环挺好的。

图是处理「宽度」的工具——互相独立的活，一次做完。活不宽的时候，问题从来不在那条线。

十一、转变

作者用一句话收尾：

提问者问问题，架构师画图。

线性 agent 从来不是天花板，它只是第一个形状——每个人都会先伸手抓它，因为它和我们打字的方式一致：一行，一次一件事。

一旦看见了节点和边，你就不再要求 agent 做得更多，而是要求图做得更宽：

• 在独立的地方扇出；
• 在需要信心的边上设闸门；
• 把承载真相的节点冻住。

多数人会继续在一条线上排队。学会画图、并且尊重那些会把图弄坏的东西的人，能跑起一支队伍。

想连前置知识一起补，作者指向他的 Loop Engineering；作者本人的更新在 Substack。