大多数人只用了 AI 能力的 % 到 %。真正拉开差距的，往往不是又学会一个提示词技巧。而是开始设计一整套工作如何被完成。

这也是大公司里一类真实岗位的分水岭：一个人负责做一项工作。另一个人负责设计一百项工作怎样同时推进、彼此交接、自动检查，并最终汇总成一个结果。

原文作者 Anatoli Kopadze 回忆。他在丹麦读大学时上过一门课，课程几乎只研究一件事：把流程画成图，再想办法让它尽可能高效。当时听起来很抽象，现在这正是 AI 工程师在讨论的 Graph Engineering。其实，

这篇文章会把它拆开讲清楚：什么是图，怎样识别拖慢程序的假依赖。哪种结构最值得复用，验证器为何必须使用独立上下文，图会在哪里悄悄失败，还有什么时候根本不该用图。

从 Loop 到 Graph。这个概念到底从哪来

一个月前，大家还在谈 Loop。随后 Peter Steinberger 发了一句：

这句话好笑，是因为它说对了一半。

Loop 是让一个 Agent 反复改进同一件事：尝试、检查、调整，接下来再来一轮。Graph 不是更高级的单循环，而是一组互相连接的循环。按理说，多个节点并行工作，一些循环监督或修正另一些循环。不再只有一个 Agent 追着一个指标跑。

工程师很快指出：这其实是一个用了几十年的老概念，只是换了新名字。没错，反而正因为它不新，才更值得认真看。关键程序已经用这类结构跑了很多年，我们现在只是把它应用到了 Agent 上。

图就是一张可执行的 AI 工作计划。它只回答两个问题：

1. 哪些工作需要完成？怎么说呢，
2. 哪项工作必须等待另一项工作的结果？

图里只有两种基本元素。

节点

是一项边界清楚的工作。例如研究竞争对手、写初稿、核查事实。每个节点只有一个输入和一个输出，一项任务即可。

边

表示依赖关系。如果任务 B 必须使用任务 A 的结果，则 A 与 B 之间就有一条边；怎么说呢，B 必须等待 A。只有真正传递了数据，这条边才算存在。

节点负责思考，边负责传递结果。

要让节点真正接入图，还需要一份契约：任务边界、输入格式、输出格式都要明确。如果节点返回自由文本，它只能交给人读；若输出遵循固定结构，下一个节点便能直接消费。不必猜测字段含义，也不需要人为转述。话说回来，

▸ 节点契约任务：研究一个竞争对手的定价，只做这一件事
从输入来看，{ competitor: "name",url: "https://..." } ← 必须显式传入。不能自行假设
输出的观点是，{ price: number,plan: string,source: url,date: "YYYY-MM-DD" }
从约束来看，强制校验 Schema；如果 Agent 返回自由文本，拒绝并重试
原因的观点是，只有明确的输出。后续节点才能在无人介入的情况下直接读取

找出所有假依赖

使用者痛点：你是否经常发现某些步骤可以并行，却被错误地串行化导致整体耗时翻倍？把现在的 AI 工作流从头走一遍，每到一步。只问一句：

If yes → 边是真实依赖，保留顺序；If no → 边是假依赖，可并行执行。

再看例子。“先检查文件 A 的 Bug，再检查文件 B 的 Bug。”虽然看起来像顺序流程，但检查 B 并不会使用 A 的结果，它们本可以并行运行。删掉假边后总耗时只取决于最慢的一项，而不是两者相加。

你现在的流程其实已经是一张图

当你把 Agent 写成“先做 A。再做 B，接下来 C，最终 D”时其实已经画出了一张最基础的图——一条直线，每个节点只有唯一入边和唯一出边。 这种线性图可以运行，却慢且脆弱：C 卡住则 D 永远不会触发。即使 A 与 B 已完成也会被阻塞在上游。

Graph Engineering 的第一步先实用技能，就是重画这条直线：

• 检查每条边；话说回来，删除没有数据传递的假依赖；让互不依赖的任务并行启动。
• A → B → C → D 的关键方法可能降至三到五层，而非四层顺序链。
• A → B 并行后总耗时取决于最慢的一层，而不是所有任务之和。按理说，

实际收益示例：

• 相同工作量。从五分钟降到十五秒，
• The model isn’t bottleneck – linear chain you drew is.

最值得记住的结构：菱形

You don’t need to memorize a hundred topologies. In mature Agent systems you’ll repeatedly see same pattern:

• Fan out：拆分任务并行执行，以获得广度。怎么说呢，
• Reduce：# 用普通代码去重、过滤和压缩。
• Synsize：# 最终 Agent 合成答案。

The structure is often called a “diamond”. Claude’s Research feature uses a similar flow: a Lead Agent plans research angles。multiple Workers gar material in parallel,findings are verified,and finally a synsis node writes report.

// 行业市场扫描菱形结构示例
const angles =;// FAN OUT：每个角度单独调研
const raw = await parallel(
angles.map => agent({
再看task，`研究：${a}。每项结论必须带来源 URL 和日期。`,schema: Finding,model: "cheap"。// 普通节点用便宜模型
}))
);// REDUCE：去重 & 合并
const findings = dedupeBySource.filter);// VERIFY：独立上下文审查
const survivors = await parallel(
findings.map => agent({
至于task。"尝试推翻这项发现，返回 keep | drop，并说明原因。",input: f,freshContext: true,model: "strong"。// 判断节点使用强模型
}))
).n => v.verdict === "keep"));// SYNTHESIZE：最终报告
return agent({
从task来看。"写成一份报告，按置信度排序并附上来源。",input: survivors。model: "strong"
});

This template works for market scans,code reviews。research reports – just replace angles and prompts.

独立检查器才是整张图的关键

Pain point: 模型经常放过自己的错误，同一个模型检验自己的产出往往过于宽容。需要独立验证节点且使用全新上下文 .

• The verifier’s job is to *kill* claim if possible.
• If it sees Worker’s full conversation it will just nod along.
• The verifier should receive only result。not production history.
• A successful verification requires passing multiple independent skeptics before result proceeds.

▸ 验证节点输入：
Worker 的单条发现，仅限发现本身，不包含 Worker 对话。- 检查结论是否经得起核查
- 检查来源是否最新且真实
- 若多数审查者通过则保留；否则丢弃

If Worker and Verifier share context y become a self‑scoring loop – cheaper but no more reliable.

图会在哪里悄悄坏掉

上下文坍塌

You can launch thousands of nodes in parallel,but if you shove all raw outputs into one final node you’ll blow past LLM’s context window.

// 分层 Fan‑in 示例
const batches = chunk;// N 为每批大小
const summaries = await parallel(
batches.map => agent)
);按理说，return agent;// 最终节点只读取 ~N 条摘要，而不是数千条原始输出

虚假的独立性

The prompts may look independent。yet y might write to same file or hit a rate‑limited API. That hidden resource contention creates an implicit dependency.

// 隔离 Worker 示例
await parallel => agent({
task这方面，`重构 ${f}`,worktree:true // 每个 Worker 拥有独立工作区
})));// 若两个节点写同一文件，则应建立显式依赖而非并行

节点静默失败

A linear chain fails loudly – you see which step stopped. In a graph with hundreds of nodes one silent failure can go unnoticed unless you guard against it.

// Fan‑in 守卫示例
const results = ).filter;if {
flag，老实说，}
// 永远不要基于残缺输入生成报告

你真的需要图吗？说起来，

• 任务很小或彼此孤立。 加上协同成本反而更贵，一个 Agent 完成更快、更便宜。
• 需要逐步批准。 每一步都要人工审批，会抵消并行带来的收益。
• 探索阶段尚未确定目标。话说回来， 灵活单 Agent 更适合随时调整方向。而不是预先锁定大量并行子任务。
• 步骤严格依赖且不可拆分。 强制绘制为图只会增加复杂度，不提高速度。
• 找不到假边。 如果任意两项工作都有真实数据流动。那么没有可并行化空间，只能保持 Loop 模式。

---