本文目录13 个章节
绝大多数人用 AI，其实只发挥出了它 5% 到 10% 的真正威力。还有一条跑得更快、潜力更大的路。学会这一招，你处理的就不再是个人零碎小事，而是能直接重构整条庞大的业务流程。
这是大厂高端工程岗位背后的真本事：不再是单打独斗做一项任务，而是设计出一套能让上百项任务协同运转的工程机制。
我很早就幸运地踩中了这个点。当年在丹麦顶尖大学念书时，有一门课只教一件事：怎么把复杂流程画成图，并把运行效率榨到极致。
那会儿觉得这东西挺抽象。可到了今天，这恰恰是各路顶级 AI 工程师每天在社交媒体上争论得最凶的话题。
读完这篇文章，你对图工程（Graph Engineering）的理解会比你关注的大多数人更通透： 搞懂图的真正含义、学会在秒级提升 AI 速度的测试法、掌握投产比最高的架构模式、认清那些隐蔽的坑点与不适用场景，并在几分钟内上手搭建一套真实运行的图流程。
我们还在聊 Loops（循环）吗，还是已经全面转向 Graphs（图）了？
1 - 这个概念究竟从何而来
恰好一个月前，全网都在疯跑 Loops。随后 Peter Steinberger 发了上面那条推文，圈子里刚学会 Loops 的人一夜之间就觉得它成了旧新闻。
这句调侃能火是因为它说中了一半事实。看过我 Loops 那篇文章的朋友基础都在。所谓 Loop，就是单个 Agent 反复优化一件事：尝试、检查、微调、再来。这是上个月的核心玩法。
所有人转投的并不是更厉害的单体 Loop，而是由多个 Loop 组成的图架构网络（Graph of Loops）：让多个循环相互盯防纠错，不再靠单打独斗追指标。
资深工程师们几小时内就出来打脸，指出这不过是换了个新名字的几十年前老概念。他们没说错，但这反而是好事：一个在核心系统中稳定跑了 30 年的架构模式，恰恰是你最能放心托付业务的基石。
2 - 图究竟是什么
图就是一张画出来的 AI 任务规划图。它只解决两个问题：哪些活要干，哪些活必须等谁干完才能干。
图只有两个基本件，把它们搞明白，绝大多数概念混淆就迎刃而解了。
方框叫节点（Node）。它代表一项独立工作：一个 Agent 跑一个任务，有明确输入和明确输出。比如调研竞品、撰写草稿、核验结论。
箭头叫边（Edge）。它代表依赖关系：意味着下一道工序必须拿上一道工序出的结果，所以必须等。只有当真实数据从上面流过时，这条边才算数。
节点负责思考计算，边负责传输结果。 这就是全部的术语。记下这两点，你以后再也不用看那些死板的定义。
Nodes & Edges
┌───────────────────────────┐ ┌─────────┐ EDGE ┌─────────┐
│ NODE │ │ │ ↓ │ │
│ • one agent │ │ Node A │ ───────────────> │ Node B │
│ • one job │ │ │ │ │
│ • one input │ └─────────┘ └─────────┘
│ • one output │ one node's output
└───────────────────────────┘ feeds the next node's input要让一个节点在图里真正管用，核心在于契约（Contract）： 工作边界清晰、输入固定、输出明确。如果节点吐出一堆自由文本，那就只有人类能看；只有规范了固定的 Schema 输出，下游节点才能免猜无缝读取，这才是自动化图工程的精髓。
▸ NODE CONTRACT
JOB: research one competitor's pricing (one job, nothing else)
IN: { competitor: "name", url: "https://localhost/target" } ← passed in, never assumed
OUT: { price: number, plan: string, source: url, date: "YYYY-MM-DD" }
SCHEMA: enforced. if the agent returns free text, it's rejected and retried
WHY: a defined output is what lets the next node read this one
without a human in the middle. that is what makes it wire-able.3 - 揪出虚假边的测试法
拿你手头正在跑的 AI 工作流逐步排查。每到一个节点就问一句：这一步真的非得拿上一步算出的结果不可吗？
如果是，这条边就是真的，保留顺序；如果不是，根本就没有边，等待纯属浪费时间，这两个活完全可以同时跑。
看个最常见的例子：“先审查文件 A 的 Bug，再审查文件 B 的 Bug”。听着像顺序流，但检查文件 B 根本不用看文件 A 查出了什么。它们串行跑只因为你按顺序写了代码。把它们改成并行跑，总耗时就取决于较慢的那单文件，而不是两个累加。
随便画个工作流，你都能找出 2 到 3 条这种假边。每一条假边，都是你白白扔掉的时间。
The Fake Edge Test
┌────────────────────────┐ \ / ┌────────────────────────┐
│ review file A for bugs │ \ / │ review file B for bugs │
│ │ ───────X──────> │ │
│ │ / \ │ │
└────────────────────────┘ / \ └────────────────────────┘
file B never reads file A's result.
no data crosses = no edge = run them at once.4 - 你现有的流程其实已经是一张图了
当你把 Agent 逻辑写成“先做 A，再做 B，接着做 C，最后做 D”时，技术上你已经画出了一张图。只不过这是效率最低的一种：一条道走到黑的单向链条，每个节点都是一进一出。
它确实能跑通，但也跑得慢且极易卡死，因为单向链条没有任何冗余。一旦节点 C 卡住，节点 D 就永远触发不了，节点 A 出来的成果也会烂在上游。
图工程的第一门硬功，就是重构这条链条。拿出现有的流程，对着每条箭头做虚假边测试。斩断不传数据的箭头，直线就会展开成更宽的网：几个独立任务并发齐跑，最后把结果汇总给一个需要它们的节点。
这种重构可不是为了好看。 一个 40 步的线性流程，意味着 40 个单点故障源和 40 步串行延迟叠加。同样的 40 个任务用图拉开，真实的依赖层级通常只有 3 到 5 层，整体完成耗时取决于最慢的那一层，而不是全部相加。在做完全相同工作量的情况下，这就是 5 分钟和 15 秒的巨大差距。
模型的推理速度从来不是瓶颈，你画的那条直线才是。
5 - 投产比最高的唯一模式：菱形模式
你根本不需要记上百种拓扑图形。观察任何高水平的 Agent 系统，出现的都是同一种图形：任务发散拆开、多个 Worker 并行探索、校验节点把关、最后合并回一个结果。
这个图形就叫菱形模式（The Diamond Pattern），它是你今年最需要的核心拓扑。它的规范三步架构值得死记硬背：Fan out（扇出并发）、Reduce（代码归集）、Synthesize（最终合成）。
用 Fan out 收集广度，用纯代码控制的 Reduce 做无损压缩，最后让总结 Agent 执行 Synthesize 吐出报告。
THE DIAMOND: fan out ──> reduce ──> synthesize.
┌───────────────┐
│ split the job │
└───────┬───────┘
┌──────────────┬───────────┼───────────┬──────────────┐
▼ ▼ ▼ ▼ ▼
┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐
│ worker 1 │ │ worker 2 │ │ worker 3 │ │ worker 4 │ │ worker 5 │
└────┬─────┘ └────┬─────┘ └────┬─────┘ └────┬─────┘ └────┬─────┘
└──────────────┼────────────┼────────────┼──────────────┘
▼ ▼ ▼
┌───────────────┐
│ checker │
└───────┬───────┘
▼
┌─────────────────────────┐
│ merge into one answer │
└─────────────────────────┘Claude 内置的 Research 功能在生产环境跑的就是这套逻辑。一个主导节点拆角度，Worker 节点并行找资料，独立验证节点把关，最后合成报告送到你面前。一旦你看懂了菱形模式，你就不再问“怎么让 Agent 做更多步骤”，而是问“哪里该拆并发，哪里该做合并”——后者才是实现扩展性的硬道理。
下面是菱形模式在代码底层的具体写法。当你在提示词里写 "workflow" 时，Claude 会自动生成下面这段编排脚本并作为代码运行，这也是 Agent 之间传数据不叠上下文 Token 的关键。
// a market-scan graph — the diamond, written by Claude when you say "workflow"
const angles = [
"pricing vs the top 3 competitors",
"what buyers complain about in reviews",
"the feature gaps in the category",
"where the market moves in the next 12 months",
];
// FAN OUT — one researcher per angle, all at the same time
const raw = await parallel(
angles.map(a => () => agent({
task: `research: ${a}. every claim needs a source url + date.`,
schema: Finding, // validated output, not free text
model: "cheap", // boring node → cheap model
}))
);
// REDUCE — plain code, no model, no tokens
const findings = dedupeBySource(raw.flat().filter(Boolean));
// VERIFY — a FRESH skeptic per finding, tries to kill it
const survivors = await parallel(
findings.map(f => () => agent({
task: "try to disprove this. return keep | drop + why.",
input: f,
freshContext: true, // never reuse the researcher's chat
model: "strong", // judgment node → strong model
}))
).then(v => findings.filter((_, i) => v[i].verdict === "keep"));
// SYNTHESIZE — one agent writes the answer from what survived
return agent({ task: "one report, ranked by confidence, sources attached.",
input: survivors, model: "strong" });6 - 真正的精髓在校验节点
下面是绝大多数人直接漏掉的部分，而这恰恰是工业级图工程和昂贵玩具的分水岭。
所有针对 AI 自我审查的严谨测试都表明：模型很难发现自己犯的错误。 让生成内容的模型去检查自己的干活成果，它对自己总是过分宽容。
所以，绝对不要让干活的 Agent 去核验自己的输出。
你得在数据边上安插一个独立的验证节点（Verifier Node）。它的唯一任务就是想方设法挑刺、打杀前置节点的结论。能扛住挑刺的才放行，扛不住的当场干掉。
这里有个没人明说的硬坑：验证节点必须拥有完全干净的独立上下文（Clean Context）。
要是把 Worker 节点的历史对话打包喂给验证节点，它根本做不到客观，只会换个字体自我附和。共享上下文的所谓“Agent 图”，本质上只是穿了马甲的单体循环，不仅继承了单体循环的所有缺陷，账单还更贵。
所以必须给验证节点全新的上下文。让它盯紧客观信号——不要看“Agent 是不是宣称做完了”，要看“单测是不是真的跑通了”。
接着把校验拆成 3 个维度：结论对不对？信息新不新？来源是不是真的？ 3 个互补的独立视角，能揪出 10 个同质化审查漏掉的问题。
▸ VERIFIER NODE
INPUT: one finding from a worker (the finding only, never the worker's chat)
CONTEXT: fresh and empty. it has not seen the work it is judging
CHECKS: three skeptics run in parallel, each with a different question
1. is it correct? → does the claim actually hold up
2. is it current? → is the source recent, not something stale
3. is the source real? → does the link resolve to the claim it's cited for
PASS: keep the finding only if a majority of skeptics let it live
FAIL: drop it before it ever reaches the final answer必须恪守的核心铁律：Worker 节点和它的 Verifier 节点绝不能共享上下文。 一旦共享，你就回到了让 Agent 自己改作业的老路，只是账单变大了而已。
7 - 图工程容易在哪些地方炸掉
陷阱 1：上下文崩塌（Context Collapse）。 并发开了上千个节点，要是企图把这上千份原始输出一股脑塞给最终的 Synthesize 节点，合成还没开始，上下文窗口就先爆了。
解法：分层归集（Layered Fan-in）。 对并发输出做分批处理，先生成批次摘要，再针对摘要做二级合并，绝不直接处理未经压缩的原始文本堆。
// layered fan-in — never pour 1,000 raw outputs into one step
const batches = chunk(results, 40); // groups of 40
const summaries = await parallel(
batches.map(b => () => agent({ task: "summarize this batch", input: b }))
);
return agent({ task: "write the answer from the summaries", input: summaries });
// the final step reads ~25 summaries, not 1,000 raw outputs陷阱 2：隐蔽并发冲突（False Independence）。 两个节点在提示词里互相没提过、表面独立，但如果它们同时写入同一个本地文件，或者并发踩爆了同一个 API 的限流，就构成了隐藏的依赖冲突。
Bun 团队早期尝试把大型重构任务并发分给多个 Agent 时，就因为共享了同一个工作区，导致文件被互相覆盖。
解法：资源隔离（Isolated Workspaces）。 为每个并发 Worker 提供独立的隔离运行环境（比如 Git Worktree），全面审计共享资源风险，不光看数据共享。
// isolate the workers — no shared file, no shared workspace
await parallel(files.map(f => () => agent({
task: `refactor ${f}`,
worktree: true, // each agent works in its own git worktree
})));
// they can't overwrite each other, then the results merge cleanly
// rule: any two nodes writing the same file need an edge, not parallelism陷阱 3：静默节点失效（Silent Node Failure）。 在单向链条里，一个节点报错整个流程立刻挂掉，虽然讨厌但很明显；而在包含几百个节点的图里，个别死锁节点很容易混过去，导致最后吐出一份看似完整实则残缺的报告。
解法：输入校验熔断（Fan-in Guard）。 每个归集节点处理前，必须校验实际收到的输入数量和预期总数是否对得上，发现缺包立刻熔断报警，绝不静默拿残缺数据继续推导。
// fan-in guard — catch the node that quietly died
const results = (await parallel(jobs)).filter(Boolean); // dropped nodes = null
if (results.length < jobs.length) {
flag(`WARNING: ${jobs.length - results.length} of ${jobs.length} nodes returned nothing`);
}
// never synthesize on a partial set and call the report complete8 - 你真的需要图架构吗
照我的惯例，咱们老老实实评估一下这东西到底适合谁。
图架构买到的是处理广度和并发速度，它买不到更好的模型判断力。
它是用来扩展任务并行度的工具。如果待处理的工作本身没有可拆分的横向宽度，单向链条就根本不是性能瓶颈。
在这些场景下直接放弃图架构： 任务微小且孤立（比如加个函数、修个 Bug）；你需要人工逐步审批；处于摸索阶段目标不明确；步骤之间存在无法解耦的真实顺序依赖。
检验标准的试金石还是虚假边测试： 如果你在流程里找不出任意两个没有依赖关系的独立任务，那就说明你根本不需要图结构。普通的 Loop（循环）就足够好。
9 - 没人愿意听的真话：客观锚点
这里隐藏着一个更深的坑，也是这次架构演进中最深刻的一课。
假设你搭了一套极其复杂的图架构：包含对等校验节点、审计节点、调优元节点。每个节点都在盯着上游，且所有人都在读格式化的文本报告。
审计节点拿着财务数据去对账，可财务数据本身也是同一套生成系统吐出来的。
整个系统在逻辑上完美自洽，但在事实上未经任何真实验证。
这种图架构崩溃起来和单个 Loop 一模一样——无非是崩溃发生得更晚、成本更贵，而且在滑向崩溃的整条路上依然一路闪着绿灯。
Anchors
(O)─────────(O)──────────(O)─────────(O)
│ \ / │ \ / │ / │
│ \ / │ \ / │ / │
(O)──(O)─(O)─(O)─(O)──(O)─(O)──────(O)─(O)
│ │ │
⚓ ⚓ ⚓
tests that ran revenue that landed frozen rules
topology doesn't buy truth. anchors do.光靠拓扑结构的复杂性买不到真实。图工程必须引入客观锚点（Anchors）：那些无法被 Agent 辩驳的确定性检验节点。
比如真正运行通过的单测集（而不是 Agent 口头推断的“应该能过”）、银行账户里实打实的进账、真实留存下来的用户。
有些核心业务底线必须冻结，不能给 Agent 留出为了凑优化指标而擅自放宽标准的余地。
系统的可靠上限，完全取决于它内部那些拒绝妥协的客观锚点。
拿无法反驳的硬数据去评估，系统才能务实接地；让它评估自己生成的文本报告，它只会极其自信地犯错。
10 - 在 Claude Code 里手搭一个图
理论讲够了。如果你想动手试试，咱们直接搭一个。在 Claude Code 里搭一个真实的图只需要几分钟，因为它内置了动态工作流（Dynamic Workflows）工具。
核心触发词只有一个："workflow"。
只要在提示词里加上这个词，Claude 就不会再单线程一步步干活。它会写一段简短的编排脚本，然后拉起一组协同作战的子 Agent 节点并发跑。
关键在于编排层完全是代码，而不是对话。Agent 之间传递数据不会像对话交接那样重复烧上下文 Token，这才让单次运行能扩展到集群规模而不爆会话。
打开你熟悉的代码库，直接粘贴下面这段图规格（GRAPH SPEC）：
▸ GRAPH SPEC
GOAL: audit every route file under src/routes/ for missing auth checks
FAN OUT: one agent per file, all running in parallel
VERIFY: an independent checker on each finding, with fresh context
CAP: 20 files on this first run
ON FAIL: flag any file that doesn't return, never skip it silently
REPORT: one merged list of the routes missing auth
(start the prompt with the word "workflow" so Claude builds the graph)运行之后，系统会自动按如下逻辑流转：
首先，Claude 会提示它正在构建工作流，而不是在普通对话框里回答，并在动手前把整体编排计划展示给你审批。
审批通过后， Agent 集群开始并发运行：每个路由文件分配一个独立的 Worker Agent，主会话过程始终保持顺畅。
最后送到你眼前的不是 20 个散乱的对话框，而是一份汇总好的审计报告。中间过程数据全在脚本内部消化，完全不挤占主会话上下文。
这就是图工程实战：一句话拉起十几个 Agent 并发干活。跑得顺的工作流直接保存下来，以后就能变成按名字随时调用的自定义命令。
Run a dynamic workflow in Claude Code
> PROMPT (copy-paste)
┌─────────────────────────────────────────────────────────────┐
│ Run as a dynamic workflow. │ ← this is the
│ Break the job into the right number of parallel sub-agents. │ workflow
│ Spawn them. │ request
│ They work independently. │
│ You collect, verify, and merge everything │
│ into a single final answer. │
└─────────────────────────────────────────────────────────────┘
> WHAT HAPPENS NEXT
┌──────────┐ breaks the ┌─────────────────────────────────┐ results ┌──────────┐ ┌──────────┐
│ Main │ job down │ sub-agents run in parallel │collected │ Main │ │ Final │
│ Agent │────────────>│[Sub-agent 1] [Sub-agent 2] ... │─────────>│ Agent │─────>│ Answer │
└──────────┘ └─────────────────────────────────┘ │(verify+ │ └────┬─────┘
▲ │ merge) │ │
│ └──────────┘ │
└────────────────────────── single, complete answer ────────────────────────────────────┘11 - 开箱即用的图规格模板
下面这些模板都是针对不同工程场景的菱形模式。在项目目录里把方括号里的参数换成你自己的就能直接贴进去跑。切记把好最后关口，未经你确认不要自动发布。
模板 1：决策级研究工作台（Decision-Grade Research Desk）。 省去一周谷歌搜索或高昂的咨询账单。把问题拆成多个视角，研究节点并发检索，质疑节点打杀风险，最后只把存活的结论合成报告。
▸ GRAPH SPEC
GOAL: decision-grade research on [your question]
FAN OUT: split into 5 distinct angles, one researcher per angle, in parallel
RULE: every finding needs a source link and a date
VERIFY: a skeptic attacks each finding and tries to disprove it, drop what fails
MERGE: survivors into one report ranked by confidence
SAVE: research-report.md, then show me the top findings
HUMAN GATE: change nothing after that without asking me
(start the prompt with the word "workflow" so Claude builds the graph)模板 2：SEO 内容生成管线（SEO Content Pipeline）。 并发调研竞品覆盖面和真实痛点，合成为高质量初稿，未经人工批准绝不自动发布。
▸ GRAPH SPEC
GOAL: one ranking-ready draft for [topic]
PARALLEL JOBS (run at once):
1. what the current top-ranking pages cover
2. the real questions people ask about this topic
3. what those top pages skip
MERGE: the three into an outline, then write a full draft
VERIFY: a fact-checker that flags every claim without a source
SAVE: drafts/ with the flagged claims listed at the top
HUMAN GATE: never publish anything
(start the prompt with the word "workflow" so Claude builds the graph)模板 3：GTM 市场发布包（Go-To-Market Kit）。 并发分析受众画像、渠道和竞品定位，一次运行吐出整套产品发布素材包。
▸ GRAPH SPEC
GOAL: full launch kit for [product], aimed at [audience]
PARALLEL JOBS (research, run at once):
1. profile the buyer and the exact words they use
2. map where these buyers spend time online
3. collect how competitors pitch them
MERGE: a one-page positioning doc
HUMAN GATE: pause and show me the positioning doc before writing
PARALLEL JOBS (writing, from that doc):
1. landing page copy
2. a week of launch posts
3. a set of outreach messages
VERIFY: a checker compares every asset to the positioning doc, flags anything off
SAVE: launch-kit/, change nothing after that without asking me
(start the prompt with the word "workflow" so Claude builds the graph)模板 4：全仓代码重构扫掠（Repository Refactor Sweep）。 突破单上下文容量限制，并发扫描大行数函数并独立验证重构方案。
▸ GRAPH SPEC
GOAL: find every function over 100 lines and propose a refactor for each
FAN OUT: one agent per file, in parallel
VERIFY: an independent checker on each proposed refactor, fresh context
DEDUPE: proposals against everything already seen
CAP: 50 files on this first run
REPORT: how many files came back, so nothing fails silently
(start the prompt with the word "workflow" so Claude builds the graph)模板 5：动态问题探索循环（Dynamic Discovery Loop）。 适用于非确定性范围的任务（比如扫漏洞），支持并发搜索、独立验证与收敛中断机制。
▸ GRAPH SPEC
GOAL: hunt this repo for [security issues / broken error handling / dead code]
FAN OUT: run finders in parallel
DEDUPE: check each new find against everything already seen
VERIFY: an independent checker on the survivors
LOOP: keep going until two rounds in a row find nothing new, then stop
CAP: a hard limit on total agents so it can't run away
REPORT: final list ranked by severity
(start the prompt with the word "workflow" so Claude builds the graph)12 - 成本开销与人类监督
图架构的运行成本比普通对话贵得多。代码编排降低的是管理开销，而不是计算本身。集群里的每个 Agent 节点都在实打实地烧 Token。
最典型的公开案例：有工程师用这套架构在 11 天里重构了 Bun 运行时库，把 535,000 行代码重写成了超 1,000,000 行新代码，把原本需要一年的工程大幅压缩。
整个过程跑了约 50 次动态工作流，最高同时开启 64 个并发 Worker Agent。
但这同时也消耗了约 165,000 美元的 API 账单，全程需要资深工程师进行架构设计和把关，而且如此海量的 AI 生成代码能否被安全审计也引发了很大争议。
这就是图工程最真实的面貌：它既能拉起上千个 Agent 并发攻克超大型工程，也可能因为缺乏客观锚点或选错任务而偷偷在后台把你的钱烧光。
所以，重型图架构属于有预算、有限额、有监控的团队。 如果你还没到这个阶段，完全不用焦虑。从小型并行任务做起，盯紧单次运行成本，证明了投产比再扩大规模。
13 - 这对你意味着什么
这就是图工程的全貌：包含它的原理、优势场景、核心坑点和适用人群。
它的优势在于横向扩展任务处理的广度和并发度；局限在于它提高不了单点推理品质，缺乏约束时还会烧暴预算。
正确的做法绝不是把一切流程都强行图化， 而是认清什么任务需要横向并发，什么时候简单的单体 Loop 才是最优解。
今晚就能用的实践建议：掌握虚假边测试。 把你现有的 AI 工作流画出来，找出那些不传数据的冗余箭头并删掉它们。光是这一步重构，就能在不引入任何新工具的前提下大幅提升你的处理速度。
大多数人还会按部就班地写单向串行流程；而少数学会画图的人，已经开始驾驭 Agent 集群了。
REFERENCES