图工程实战手册：从删假边到智能体舰队

你已经会搭 loop 了：一个 agent 反复尝试、检查、修正，直到任务完成。但很快你会撞到天花板——loop 只能让一个工作单元变好，不能决定有哪些单元、什么顺序、哪些本可并行。这时就要把多个 loop 连成一张网：这就是图工程（Graph Engineering）。

@angeldot_ 把图工程拆成 14 步、四个模块：先看见已有的图（01–04），再移动舰队（05–08），然后信任输出（09–11），最后别被图毁掉（12–14）。这门课就按这 14 步走，并把 @AnatoliKopadze、@Gyome1_、@Promixyz、@0xCodila 四篇实战长文的独有细节融进来——相同的概念（diamond、router、对抗验证、fake edge）只讲一次。

开场先看 @Gyome1_ 的完整案例（1 个 agent 定范围 → 5 个便宜 agent 并行搜 → 确定性脚本去重 → 3 个 skeptical agent 找茬 → 1 个顶级模型终审），这就是图工程：

▶

视频在原帖中播放（X 站内视频无法直接下载嵌入），点此去原帖观看。

图只有两个原子，定义必须抠准（综合 @AnatoliKopadze 与 @angeldot_）：

两个省钱的关键认知：

• 边是免费的（@angeldot_）：人们为 token 付的大量费用其实花在了边上，而边应该是免费的——合并、去重用 flatMap / Set 写代码，而不是再起一个 agent。智能体用于判断，而非管道工程。@Gyome1_ 的判据更直接：能不用 judge / decide / assess / summarize 描述的变换，就是代码；每个 model call 必须对应真正需要判断的决策。
• 不是每个 node 都需要 LLM：去重、排序、合并走普通代码，又快又便宜又稳定。

大多数人画的第一张图都是假图：箭头画满了，但数据根本没流动。@AnatoliKopadze 的 fake-edge 测试专治这个：

1. 把工作流逐步走一遍；
2. 每一步都问：这一步真的需要上一步的结果吗？
3. 说不出跨越这条箭头的变量名，就没有边——删掉，并行跑。

实测效果：一个 40 步的线性流，通常只有 3–5 个真实依赖，延迟从各步之和降为最慢的一层——原文的例子是从 5 分钟降到 15 秒。

@0xCodila 给了同样的习惯，叫 "and then" 测试：每遇到 "and then" 就问下一步是否真读上一步输出。"总结文件 and then 告诉我天气"——天气不读总结，这是两条被线性脚本无故串行的独立任务。

三篇实战长文（@AnatoliKopadze、@angeldot_、@Gyome1_）不约而同只推荐一个拓扑，叫 diamond（钻石）：

fan out（并行采集广度）→ reduce（纯代码压缩，零 token）→ synthesize（最后一个 agent 写答案）

生产级实例就是 Claude 的 research 功能：lead 规划角度 → workers 并行采集 → findings 检查 → 一份报告。

@Gyome1_ 把钻石画得更工程化：split → fan-out → barrier → reduce → synthesize，其中 barrier（屏障）是可靠性设计：定义 MIN_REQUIRED_RESULTS（最少需要几个分支成功）、哪些分支必须成功、失败重试策略。fan-out 只并行"不读彼此输出"的分支。

• reduce 先于 synthesize：先用代码去重，再让 agent 分组排序——保留 sourceFindingIds 溯源链，激进压缩会抹掉验证所需的细节；
• 运行时路由（@angeldot_ 步骤 08）：模型做分类、代码做分支。让模型决定这是什么，让代码决定如何处理它。@Gyome1_ 的 router 按风险分流：severity 高走 full audit，低走 quick review；
• 反规则：图买的是宽度，不是更好的判断力。"哪里是切割点"才是决定账单的唯一问题。

@AnatoliKopadze 说得很绝对：verifier 是图工程里全部的技巧。因为模型给自己判卷，会放过大多数自己的错误。

三条铁律（综合三篇文章）：

1. worker 和 verifier 绝不能共享 context——"共享一个上下文的 agent 图只是穿着戏服的单个 loop"（@AnatoliKopadze）；@0xCodila 的真实失败案例：把执行者的对话原样丢给 verifier，等于换个字体自己同意自己；
2. 三路并行检查：正确吗？新鲜吗？来源真实吗？——多数存活才通过；
3. 对抗验证（@Gyome1_ / @angeldot_）：reviewer 的任务不是"改进答案"，而是找理由推翻结论。"没有发现可以在没被试图杀死前流向答案"。可以要求 2 票同意才放行。@angeldot_ 列了三种验证器模式：adversarial（对抗）、多视角、评审团。

@AnatoliKopadze 总结了图的三种崩法，每种都有修复：

收敛循环三保险（@Gyome1_）：seen Set 去重（连被拒的 findings 也要去重，否则每轮重现）、dryRounds < 2 停止、再加固定 budget 和最大迭代数。@angeldot_ 补充了 dedupe 陷阱：去重要针对"见过的所有"，而不是"已确认的"——否则被拒的发现每轮重现，循环永不干（loop until dry）。

模型分级（model tiering，@Gyome1_ / @angeldot_）：抽取、分类用便宜层，终审、仲裁用强模型。先定 token budget 再加分支。无聊节点跑贵模型，是最常见的浪费。

何时不用图（@AnatoliKopadze + @0xCodila，5 条）：任务小而孤立；想每步都人工审批；探索性工作（还不知道找什么）；步骤真串行（每步都读上一步输出）；fake-edge 测试找不到两条无边的工作。"买的是广度，不是判断力。"判断法只有一句：找不到两个无箭头相连的框，就没有图可建，loop 就够了。

① 可复制的第一个图（@0xCodila，Claude Code v2.1.154+，付费计划开 Dynamic workflows）

把下面这段直接粘贴给 Claude Code：

复制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.

Claude 会写 JS 编排脚本、先展示 phases 等你批准；/workflows 可实时看进度；按 s 存到 ~/.claude/workflows 复用。注意 @0xCodila 对 "zero tokens" 的纠偏：协调脚本是代码，agent 间传参走脚本变量不重复花上下文——但 agent 本身仍花 usage，workflow 比普通会话贵得多，省的是协调成本。单次 workflow 可 fan out 到 1000 个 agent（同时 16 个在跑）。首次运行建议加 CAP（如最多 20 个文件）控制账单。

② 5 个可粘贴的 graph spec（@AnatoliKopadze）

③ 真实案例：Bun 团队的 $165,000 账单（@0xCodila / @AnatoliKopadze）

Zig-to-Rust 移植：约 53.5 万行 Zig 译成 100 万+ 行 Rust，11 天，约 50 个 workflows，峰值 64 个 agent 并行，花费约 $165,000 usage，需人类全程设计监控。这事还引发过"AI 写的代码能否被安全 review"的公开批评——规模化的另一面是责任。

④ 上线前 10 问（@angeldot_ checklist）

1. 删了假边吗？
2. 工作真可分吗？
3. 节点有合约吗？
4. 在为 flatMap 付 agent 钱吗？
5. 有多余 barrier 吗？
6. 有未经验证的发现吗？
7. 两个 verifier 问了同样问题吗？
8. 循环有轮数上限吗？
9. 多节点写同一文件吗？
10. 重复节点跑在贵模型上吗？

@Promixyz 的终局抽象（步骤 14）：让 Claude 自己设计图——给它目标，让它分解、识别独立任务、生成编排、起 workers、验证、终审合成；图随任务结束而消失。