图工程是循环工程(loop engineering)的继任者:不再把步骤排成一条线,而是设计"工作的形状"——什么先跑、什么同时跑、什么得等,让 agent 跑宽 10 倍。核心工具是 Claude Code 的动态工作流(dynamic workflows)。

图工程是什么

单循环有一个已知的失败方式:某个支持团队把反馈循环绑在"工单解决率"上,数字连涨几个月,用户满意度却一路走低——机器人学会了快关工单,而不是解决问题。这就是古德哈特定律(Goodhart’s law):循环只能看见自己的指标,没法问目标对不对。

答案不是更好的循环,而是由循环组成的图:一张网络,里面的循环互相盯、互相纠。对 agent 而言,这意味着——不要再写一个把所有事排成一条线的 agent,去设计工作的形状。

核心概念:节点与边

  • 节点(node):一个工作单元——一个 agent、一个任务、一个输入、一个输出。
  • 边(edge):一段依赖——这个节点的输出,喂给那个节点的输入。

所有人都会犯的错,是把"然后"当成一条边。“总结这个文件,然后告诉我天气”——天气根本不读那个总结。每碰到一个"然后"就问:下一步真的会读上一步的输出吗?

  • 会 → 真边,保留顺序。
  • 不会 → 没有边,那个等是白等,让它们并排跑。

两个盒子之间没有数据穿越,它们就是独立的。普通 agent 其实已经是一张图,只是最寒酸的单链:C 一堵,D 永远不会发生。

第 1 步:看见那些不存在的边

(即上面的节点/边判断法——“然后"不等于依赖,挖出隐藏的独立性是整份指南的地基。)

第 2 步:搭起你的第一张图

前置条件:

  • Claude Code v2.1.154+(用 claude --version 查看)
  • 付费套餐:Max/Team/Enterprise 上 workflows 默认开启;Pro 需在 /config 打开 Dynamic workflows。

搭建流程:

  1. 打开一个你熟悉的真实仓库。
  2. 粘贴 Anthropic 提供的 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.——把路径换成自己的,max 20 让首次试跑别花太多。
  3. 看 “workflow” 亮起来:Claude Code 高亮提示 “Dynamic workflow requested.",这就是正在搭图的信号。
  4. 批准计划:Claude 会写一段 JavaScript 编排脚本并先展示各阶段,读一遍,点 “Yes, run it."。
  5. 让舰队开跑:一个文件一个 agent,并行跑。输入 /workflows 看实况:scope(范围)、fan-out(扇出)、verify(验证)、synthesize(合成)。
  6. 读那一个答案:不是二十个分开的对话,而是一份报告——中间结果活在脚本变量里,不占你的上下文。

关于"零 token"的说法

协调脚本是代码,agent 之间传结果不会像对话交接那样重新吃一遍上下文。但 agent 本身还是要花用量的:一次 workflow 的成本明显高于一次普通会话。省的是协调开销,不是干活的开销。先小范围起步,盯用量,再放开。

把它变成你的 & 扩展上限

某次跑得好,按 s,会存到 ~/.claude/workflows,可按名字复跑——改任务、保形状。一次 workflow 最多扇出到 1,000 个 agent,同时干活 16 个;“同时 16 个"只是舰队分波次推进,全程不用盯任何一个。

第 3 步:真正会塌的地方

两种失败最要命:

  • 失败一:图跟自己附和。 当 agent 检查自己的活,它对自己下不去手——模型偏爱自己产出的东西。解法是加一个独立的验证器(verifier)节点:把执行节点那段对话原样塞给它,它就不是在验证,而是换了个字体跟自己附和。一群共享同一上下文的 agent 组成的图,就是穿了马甲的单循环。验证器必须是全新节点、自己的上下文,检查真实信号(“测试真的过了”,不是"agent 说了算”)。
  • 失败二:agent 互相踩脚。 Bun 团队第一次把大型移植任务扇开时工程上失败了——多个 agent 在同一工作区用相同 git 命令互相覆盖。修法是结构性的:禁掉不安全命令,给每组 agent 各自隔离的 worktree。

扇开之前回答三个问题:每个 agent 在哪儿干活?结果怎么合?两个 agent 起冲突时怎么办?

第 4 步:本周可搭的六张图

同一个形状,对准新活儿:

  1. 安全扫描——一个文件一个 agent 找缺失的 auth,验证器确认每条命中。
  2. 带引用的报告——/deep-research:拆成多个角度并行检索,agent 互相反驳后写。
  3. 移植一个模块——一个文件一个文件,测试当闸门,失败回环。
  4. 对抗式 diff 评审——按体量路由:小改动一轮,大改动全量并行审计。
  5. 定时生态扫描——存一次,按名字复跑。
  6. 未知规模的探查——finder 并行跑,每个结果对照已见过的所有结果,循环到连续两轮没新东西。

真实天花板:Bun 的 Zig → Rust 移植

Simon Willison 的报道:Bun 的 Zig → Rust 移植跑的就是这套机器——约 50 个 workflow,峰值 64 个 agent 并行,约 53.5 万行 Zig 变成超一百万行 Rust,11 天,花费约 16.5 万美元用量。规模是真的,代价和所需的人力盯防也是真的。

第 5 步:让图保持诚实的锚点

光靠拓扑买不来真相。图需要锚点(anchors)——那些没法被反驳的节点:

  • 真的跑过的测试——不是"应该过”,是"过了”。
  • 看证据、不凭感觉的验证器。
  • 冻结的规则——agent 永远不许动它们,因为正是这些规则最容易被优化器悄悄削弱。

一张图有多诚实,取决于里面那些拒不挪窝的东西。

什么时候不该用图

  • 任务小或独立:加一个函数、修一个 bug,workflow 是纯粹额外开销——一个 agent 更快更便宜。
  • 你要盯得很紧:想每一步都读了批了再跑下一步,图"不用盯就能跑得很宽"的设计反而对着干。
  • 还没搞清楚在找什么:探索性活儿要能随时掰方向的 agent,不是钉死在计划上的舰队。
  • 各步骤确确实实相互依赖:每一步都读上一步的输出,就是真正的链,并行无处下口,硬套只多协调开销、零加速。

判断诀窍就是第 1 步:连两个之间没有箭头的盒子都找不到,就没什么图可搭。那就是个循环,而循环挺好的。

转变

提问者问问题,架构师画图。线性 agent 只是第一个形状——因为它和我们打字的方式对得上。一旦看见节点和边:活儿独立的地方扇出去,可信度要紧的地方给边把关,冻住握着真相的节点。

原文:公众号「AI领先趋势」图工程:一个 prompt、一个窗口,跑起 1000+ 个 agent 循环(完整 5 步教程)