# Graph Engineering explained: what it is, when to use it and when not to
**作者**: Anatoli Kopadze
**日期**: 2026-07-18T00:34:54.000Z
**来源**: [https://x.com/AnatoliKopadze/status/2080668775796314331](https://x.com/AnatoliKopadze/status/2080668775796314331)
---
Most people are using AI at 5 to 10% of what it can actually do. There is a faster way, and it is bigger than it looks. Learn it, and you can optimize enormous processes, not just personal tasks.
This is the skill behind real roles at large companies. The difference between doing one job, and designing how a hundred of them get done.
I got lucky with it early. When I studied at one of the best universities in Denmark, we had a whole course on one thing: how to lay a process out as a diagram and make it as efficient as possible.
Back then it felt abstract. Now it is the exact thing the top AI engineers are arguing about on your timeline.
By the end of this article you will understand Graph Engineering better than almost anyone you follow: what a graph actually is, the one test that instantly makes your AI faster, the single pattern that pays for itself, where these things quietly break, when a graph is the wrong tool, and how to build a real one yourself in a couple of minutes.
Before we get into it, follow me on X and join my Telegram channel I just created where I post more AI content every day. Both are free.
X - https://x.com/AnatoliKopadze
Telegram - https://t.me/kopadzemp
> **Peter Steinberger @steipete**: [原文链接](https://x.com/steipete/status/2078277297791189132)
>
> Are we still talking loops or did we shift to graphs yet?
## 1 - Where this even came from.
A month ago the whole field was talking about loops. Then Peter Steinberger posted the line above, and a corner of the internet that had just finished learning loops declared them old news overnight.
The joke landed because it was half true. If you have read my Loops article, you already have the foundation. A loop is one agent improving one thing on repeat: try, check, adjust, go again. That was the skill of last month.
What everyone moved to is not a better loop. It is a graph of loops, a network where cycles watch and correct each other instead of one agent chasing one number alone.
And engineers pushed back on the hype within hours, pointing out this is a decades-old idea wearing a new name. They are right, and that is the good news. A pattern that has run critical systems for thirty years is exactly what you want to trust with your work.
## 2 - What a graph actually is.
A graph is just a plan for your AI work, drawn out so you can see it. It answers two questions: which jobs need to happen, and which job has to wait for which.
There are only two parts, and getting them straight fixes most of the confusion.
A box is called a node. It's one job: one agent doing one task, with one thing going in and one thing coming out. Researching a competitor. Writing a draft. Checking a claim.
An arrow is called an edge. It just means one job needs what another job produced, so it has to wait for it. And the arrow only counts when something real actually passes along it.
Nodes do the thinking. Edges carry the results. That is the entire vocabulary. Once you have it, you never need a definition again.
The thing that makes a node actually usable in a graph is a contract: one bounded job, a defined input, a defined output. A node whose output is a wall of free text is a node only a human can read. A node with a fixed output shape is one the next node can consume without guessing, which is the whole point.
```
▸ NODE CONTRACT
JOB: research one competitor's pricing (one job, nothing else)
IN: { competitor: "name", url: "https://..." } ← 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 - The test that finds the fake edges.
Look at the AI workflow you run today and walk it step by step. At each step, ask one thing: does this step actually need the result of the one before it?
If yes, the edge is real. Keep the order. If no, there is no edge, and the wait is wasted. Those two jobs can run at the same time.
Take a simple one: "review file A for bugs, then review file B for bugs." It reads like a sequence, but the check on file B never looks at what file A returned. They only run one after another because that is the order you typed them in. Run them side by side and the whole thing finishes in the time of the slower single file, not the two added together.
You will find two or three of these fake edges in almost any workflow you draw. Every one of them is time you are throwing away for free.
## 4 - Your current setup is already a graph.
When you write an agent as "do A, then B, then C, then D," you have technically already drawn a graph. It is just the saddest possible one: a single straight chain where every node has one arrow in and one arrow out.
It runs correctly. It also runs slowly and breaks easily, because a chain has no redundancy. If C stalls, D never happens, and A's work is trapped upstream with nowhere to go.
The first real skill of graph engineering is redrawing that chain. Take your linear workflow, and for each arrow, ask the fake-edge question. Cut the arrows that carry no data, and the line collapses into something wider: a few independent jobs that can all run at once, feeding one job that needs them all.
The reason this matters is not cosmetic. A linear workflow with 40 steps has 40 points of sequential failure and the latency of all 40 added together. The same 40 jobs drawn as a graph have only as many real dependencies as actually exist, usually three to five, and finish at the speed of your slowest layer, not the sum of everything. That is the difference between a job that takes five minutes and one that takes fifteen seconds, running the exact same work.
The model was never the bottleneck. The line you drew was.
## 5 - The one pattern that pays: the diamond.
You do not need a hundred shapes. Watch any serious agent system work and the same picture keeps appearing. The work splits, several workers dig side by side, something checks what they found, and everything merges back into one answer.
That picture is called the diamond, and it is close to the only pattern you need this year. Its formal name is worth memorizing: fan out, reduce, synthesize.
Fan out to gather breadth, reduce with plain code to compress it, synthesize with a final agent to write the answer.
The research feature inside Claude runs exactly this in production. One lead plans the angles, workers gather in parallel, findings get checked, and only then does one report reach you. Once you can see the diamond, you stop asking "how do I make my agent do more steps" and start asking "where is the split, where is the merge." That second question is the one that scales.
Here is what the diamond actually looks like under the hood. When you say "workflow," Claude writes a short script like this itself and runs the coordination as code, which is why passing results between agents costs zero extra context.
```
// 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" });
```
Read it once and the whole craft is visible: the fan-out where work is independent, the reduce done in free code, the verify on a fresh context, cheap models on the boring nodes and the strong one where judgment lives and a single synthesize at the end. Same skeleton behind a market scan, a code review, or a research report. Swap the angles and the prompts.
## 6 - The checker is the whole trick.
Now the part almost everyone skips, and it is what separates a real graph from an expensive toy.
Every serious test of AI self-review says the same thing: models miss most of their own mistakes. A model grading its own work is far too easy on itself.
So you never let the agent that did the work check the work.
You put a separate node on the edge. Its only job is to try to kill the finding before it moves on. If it survives, it passes. If not, it dies right there.
Here is the catch nobody names: that checker needs a clean context.
Give it the same chat the worker had and it is not checking anything, it is nodding along to itself in a different font. A graph of agents sharing one context is just a single loop in a costume, and it breaks the same way, only later and pricier.
So make the verifier fresh. Own context. Checking a real signal, not "did the agent say it is done" but "does the test actually pass."
Then split the checking three ways. Is it correct? Is it current? Is the source even real? Three different lenses catch what ten identical ones miss.
```
▸ 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
```
The rule to remember: a worker and its verifier must never share a context. The moment they do, you are back to one loop grading its own homework, just with a bigger bill.
## 7 - Where graphs actually break.
1. Context collapse.
Fan out a thousand nodes, then try to feed all thousand outputs into one final step, and you blow past the context window before synthesis even starts.
The fix: layer your fan-in. Batch the results, summarize each batch, then combine the summaries, never the raw pile.
```
// 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.
Two nodes look independent because their prompts never mention each other, but they both write to the same file or hit the same rate-limited API. That is a hidden edge.
When Bun's team first fanned a big job across many agents, they shared one workspace and overwrote each other.
The fix: give every worker its own isolated space, and audit for shared resources, not just shared data.
```
// 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.
In a chain, one failure stops everything, annoying but obvious. In a graph, one dead node among two hundred can slip into a report that looks complete.
The fix: every merge step counts its inputs against the number it expected, and flags the gap instead of quietly running on half the data.
```
// 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 complete
```
## 8 - Do you even need one?
As tradition goes for my articles, let's honestly figure out who this could even be useful for.
A graph buys breadth. It does not buy better judgment.
It is a tool for width, for independent work done at once. When the work is not wide, the line was never the problem.
Skip the graph when:
- The task is small or isolated. Adding one function, fixing one bug. The coordination is pure overhead, and a single agent is faster and cheaper.
- You want to approve every step. A graph's whole point is running wide without you, so a tight leash works against it.
- You do not know yet what you are looking for. Exploratory work wants one agent you can steer, not a fleet locked into a plan.
- The steps genuinely depend on each other. Forcing a graph onto truly sequential work just adds cost for zero speedup.
- The tell is the fake-edge test. If you cannot find two jobs with no edge between them, there is no graph to build. It is a loop, and a loop is fine.
## 9 - The part nobody wants to hear: anchors.
There is a deeper trap here, and it is the real lesson of this whole shift.
Imagine you build the full graph. Paired checkers, audit nodes, meta-nodes tuning the other nodes. Every node watches another node, and every one of them reads a report.
The audit checks the numbers against the finance numbers, which came from the same system in the first place.
Everything is consistent. Nothing is verified.
This graph fails exactly like the single loop did, just later, more expensively, and with far more green lights on the way down.
Topology alone does not buy truth. The graph needs anchors: nodes that cannot be argued with.
Tests that actually ran, not "should pass," did pass. Revenue that landed in the bank. Customers who actually stayed.
And some rules must be frozen, the ones an optimizer would be tempted to weaken, kept off-limits precisely because they are the ones it would bend to win.
The graph is only as honest as the things inside it that refuse to move.
Judge it on numbers that cannot argue back and it stays grounded. Let it grade its own reports and it will be confidently wrong.
## 10 - Build one yourself in Claude Code.
Enough theory. If you have decided this is for you, or you just want to try it, let's build one. You can build a real graph in a couple of minutes, because Claude Code shipped the tooling to do it directly, called dynamic workflows.
It comes down to one word: "workflow."
Put it in your prompt and Claude stops working through a single line of steps. Instead it writes a short orchestration script, then spawns a coordinated fleet of sub-agents to run it.
The important part is that the coordination is code, not a conversation. Passing results between agents does not re-spend your context the way a chat handoff does, which is what lets one run scale to a whole fleet without drowning the session.
Open a real repository you know, and paste this:
```
▸ 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)
```
Run it, and here is what happens.
First, Claude signals that it is building a workflow instead of answering in a normal chat, and shows you the plan before doing anything. You read it and approve.
Then the fleet runs. One agent per file, all at the same time, while your own session stays free the whole way through.
And what lands at the end is not twenty separate chats to dig through. It is one report. The in-between results lived inside the script, never in your context, so the only thing you actually see is the final answer.
That is a graph. A dozen agents from a single sentence. When a run comes out good, save it, and it turns into one command you can re-run by name forever.
Notice the "20 files" cap in that prompt. It keeps your first run cheap, and it hints at the thing every demo leaves out: the bill.
## 11 - Ready graphs you can paste right away.
Every one of these is the same diamond aimed at a different job. Open Claude Code in a real folder, swap the bracketed parts for your own, and paste. The word "workflow" is what tells Claude to build a coordinated fleet instead of a single line of steps. Keep yourself as the last yes before anything ships.
A decision-grade research desk. Replaces a week of googling or an expensive analyst invoice. Your question splits into angles, researchers dig at once, a skeptic attacks every finding, and only the survivors reach the report.
```
▸ 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)
```
An SEO content machine. Writes one ranking-ready draft per run, and never publishes without you.
```
▸ 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)
```
A go-to-market kit. The full launch pack in one run, with you approving every piece.
```
▸ 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)
```
A refactor sweep across a whole repo. Breadth no single context could hold.
```
▸ 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)
```
A discovery loop of unknown size. For jobs where you do not know how big the work is until you are in it, like a bug sweep where finding one bug reveals three more.
```
▸ 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)
Run one scoped, watch what it costs, then widen. When a run is good, save it, and every one of these becomes a single command you launch by name.
```
## 12 - The cost and the supervision.
A graph costs more than a normal chat. A lot more. The coordination is what gets cheaper, not the work itself. The agents still burn tokens, and a fleet of them burns a pile.
The clearest example is public. An engineer used this exact setup to rewrite the Bun runtime, translating around 535,000 lines of one language into over a million lines of another in about eleven days. By hand that is close to a year of work.
It ran about 50 workflows, with up to 64 agents going at once.
It also cost roughly $165,000 in usage, needed a human designing and watching the whole thing, and got real criticism over whether that much AI-written code can even be reviewed safely.
That is the honest shape of it. A graph can fan out to a thousand agents and chew through a job no single context could hold. It can also quietly spend your money in the background if you point it at the wrong task or skip the anchors.
So the heavy version is for teams with the budget, the caps, and the monitoring to run it. If that is not you yet, you are not missing anything. Start small, watch what a run costs, and go wider only once one has earned it.
## 13 - What this actually means for you.
That is the whole picture. You now know what a graph is, where it shines, where it breaks, and who it is actually for.
You know the strength: breadth, independent work done at once. And the weakness: it buys width, not judgment, and it will spend your money if you point it at the wrong job.
So the move is not to graph everything. It is to know when the work is wide enough to need one, and when a simple loop was the answer all along.
My take: learn the fake-edge test tonight. Draw your current workflow, find the edges that carry no data, and delete them. That one move makes you faster than most people before you touch a single new tool.
Most will keep queueing steps in a line. The few who learn to draw the graph will run a fleet.
If you want to stay up to date with everything happening in AI, follow me on X and Telegram:
X - https://x.com/AnatoliKopadze
Telegram - https://t.me/kopadzemp
## 相关链接
- [Anatoli Kopadze](https://x.com/AnatoliKopadze)
- [@AnatoliKopadze](https://x.com/AnatoliKopadze)
- [131K](https://x.com/AnatoliKopadze/status/2080668775796314331/analytics)
- [https://x.com/AnatoliKopadze](https://x.com/AnatoliKopadze)
- [https://t.me/kopadzemp](https://t.me/kopadzemp)
- [Jul 18](https://x.com/steipete/status/2078277297791189132)
- [https://x.com/AnatoliKopadze](https://x.com/AnatoliKopadze)
- [https://t.me/kopadzemp](https://t.me/kopadzemp)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [10:57 PM · Jul 24, 2026](https://x.com/AnatoliKopadze/status/2080668775796314331)
- [131.6K Views](https://x.com/AnatoliKopadze/status/2080668775796314331/analytics)
- [View quotes](https://x.com/AnatoliKopadze/status/2080668775796314331/quotes)
---
*导出时间: 2026/7/25 11:34:36*
---
## 中文翻译
# 图工程详解：它是什么、何时使用、何时不该用
**作者**: Anatoli Kopadze
**日期**: 2026-07-18T00:34:54.000Z
**来源**: [https://x.com/AnatoliKopadze/status/2080668775796314331](https://x.com/AnatoliKopadze/status/2080668775796314331)
---
大多数人只使用了 AI 实际能力的 5% 到 10%。有一种更快的途径，而且它比看起来要宏大得多。学会它，你就能优化巨大的流程，而不仅仅是个人任务。
这是大公司真实职位背后的技能。这不仅是做一份工作的区别，而是设计如何让一百份工作被完成的区别。
我很早就幸运地接触到了它。当我在丹麦最好的大学之一求学时，我们有一门课程只讲一件事：如何将流程绘制成图表并使其尽可能高效。
那时它感觉很抽象。现在，这正是顶级 AI 工程师在你的时间线上争论的东西。
读完这篇文章，你对图工程的理解将超过你关注的几乎所有人：图究竟是什么、能瞬间让你的 AI 变快的那一个测试、那个能自我回本的模式、这些东西在何处悄悄崩溃、何时图是错误的工具，以及如何在几分钟内亲手构建一个真正的图。
在开始之前，请在 X 上关注我并加入我刚刚创建的 Telegram 频道，我每天会在那里发布更多 AI 内容。两者都是免费的。
X - https://x.com/AnatoliKopadze
Telegram - https://t.me/kopadzemp
> **Peter Steinberger @steipete**: [原文链接](https://x.com/steipete/status/2078277297791189132)
>
> 我们还在谈论循环，还是已经转向图了？
## 1 - 这一切源自何处。
一个月前，整个领域都在谈论循环。然后 Peter Steinberger 发布了上面那句话，互联网的一个刚刚学完循环的角落一夜之间就宣布它们是旧闻了。
这个玩笑之所以能落地，是因为它半真半假。如果你读过我关于循环的文章，你就已经有了基础。循环就是一个智能体重复改进一件事：尝试、检查、调整、再来一遍。那是上个月的技能。
大家转向的并不是一个更好的循环。它是一个由循环组成的图，一个循环之间相互监督和纠正的网络，而不是一个智能体独自追逐一个数字。
工程师们在几小时内就反击了这种炒作，指出这是一个披着新名字的几十年前的老想法。他们是对的，但这正是好消息。一个已经运行关键系统三十年的模式，正是你想要信任来处理你工作的东西。
## 2 - 图究竟是什么。
图只是你的 AI 工作计划，画出来让你能看到它。它回答了两个问题：哪些工作需要发生，以及哪个工作必须等待哪个工作。
只有两个部分，把它们弄清楚就能解决大部分困惑。
一个方框称为节点。它就是一项工作：一个智能体执行一项任务，有一个输入和一个输出。研究一个竞争对手。写一份草稿。检查一项声明。
一个箭头称为边。它仅仅意味着一项工作需要另一项工作产出的东西，所以它必须等待。只有当真实的东西沿着它传递时，这个箭头才算数。
节点负责思考。边负责传输结果。这就是全部词汇。一旦你掌握了它，你就再也不需要定义了。
使节点在图中真正可用的东西是一个契约：一个有界的工作，一个定义的输入，一个定义的输出。一个输出是一大段自由文本的节点，只有人类才能阅读。一个具有固定输出形状的节点，是下一个节点无需猜测就能消费的节点，这才是重点。
```
▸ NODE CONTRACT
JOB: research one competitor's pricing (one job, nothing else)
IN: { competitor: "name", url: "https://..." } ← 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 返回了什么。它们一个接一个运行只是因为你是按这个顺序输入的。让它们并排运行，整个过程只需完成较慢的那个单个文件所需的时间，而不是两者相加的时间。
在你绘制的几乎任何工作流中，你都会发现两三个这样的虚假边。每一个都是你白白扔掉的时间。
## 4 - 你当前的设置已经是一个图了。
当你把一个智能体写成“做 A，然后 B，然后 C，然后 D”时，你在技术上已经画了一个图。这只是最可悲的一种：一条单一直线链，每个节点有一个箭头进来，有一个箭头出去。
它运行正确。但它也运行缓慢且容易崩溃，因为链没有冗余。如果 C 停滞了，D 永远不会发生，A 的工作被堵在上游无处可去。
图工程的第一个真正技能是重画那条链。拿出你的线性工作流，对于每个箭头，问一下虚假边的问题。切断那些不传输数据的箭头，这条线就会坍缩成更宽的东西：几个可以同时运行的独立工作，供一个需要它们所有结果的工作使用。
这很重要的原因不是为了美观。一个有 40 个步骤的线性工作流有 40 个顺序失败的点，以及所有 40 个步骤加起来的延迟。同样的 40 个工作画成一个图，只有实际存在的那么多的真实依赖关系，通常是三到五个，并且以你最慢的一层的速度完成，而不是所有事情的总和。这就是一个耗时五分钟的工作和一个耗时十五秒的工作之间的区别，运行的是完全相同的工作。
模型从来不是瓶颈。你画的线才是。
## 5 - 唯一值得的模式：菱形。
你不需要一百种形状。观察任何严肃的智能体系统工作，同样的画面会不断出现。工作分叉，几个工人在旁边并行挖掘，某样东西检查他们发现的东西，然后所有东西合并回一个答案。
这个画面称为菱形，它是今年你几乎唯一需要的模式。它的正式名称值得记住：分叉、归约、合成。
分叉以收集广度，用普通代码归约以压缩它，用一个最终的智能体合成以写出答案。
Claude 里面的研究功能在生产环境中运行的就是这个。一个负责人计划角度，工人并行收集，发现结果被检查，然后只有一份报告会到达你那里。一旦你能看到菱形，你就会停止问“我如何让我的智能体做更多步骤”，并开始问“分叉在哪里，合并在哪里”。第二个问题才是那个能扩展的问题。
以下是菱形在底层实际的样子。当你说“工作流”时，Claude 会自己编写像这样的一个短脚本，并以代码的形式运行协调，这就是为什么在智能体之间传递结果不需要花费额外的上下文。
```
// 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 自我审查的严肃测试都说同样的事情：模型会遗漏它们自己的大部分错误。一个给自己工作打分的模型对自己太宽容了。
所以你永远不要让做工作的智能体去检查工作。
你在边上放一个单独的节点。它唯一的任务是在发现继续之前尝试摧毁它。如果它存活下来，它就通过。如果没有，它就当场死亡。
有个没人说出来的陷阱：那个检查器需要一个干净的上下文。
给它工人同样的聊天记录，它就不是在检查任何东西，它只是用不同的字体对自己点头。一个共享一个上下文的智能体图只是一个穿上戏服的单一循环，它以同样的方式崩溃，只是更晚且更昂贵。
所以让验证器保持全新。拥有自己的上下文。检查一个真实的信号，而不是“智能体说它完成了吗”，而是“测试真的通过了吗”。
然后把检查分成三部分。它正确吗？它是最新的吗？来源甚至是真的吗？三种不同的镜头能捕捉到十个相同的镜头错过的东西。
```
▸ 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
```
要记住的规则：工人和它的验证器绝不能共享上下文。一旦它们共享，你就回到了一个循环给自己作业打分的状态，只是账单更大了。
## 7 - 图在哪些地方真的会崩溃。
1. 上下文崩溃。
分叉一千个节点，然后尝试将所有一千个输出输入到最后的步骤中，你会在合成甚至开始之前就超出上下文窗口。
修复方法：分层你的汇入。将结果分批，总结每批，然后合并总结，永远不要那堆原始的东西。
```
// 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. 虚假独立性。
两个节点看起来独立，因为它们的提示词从未提及彼此，但它们都写入同一个文件或击中同一个限速的 API。这是一个隐藏的边。
当 Bun 的团队第一次将一项大工作分散给许多智能体时，它们共享一个工作区并互相覆盖。
修复方法：给每个工人自己的隔离空间，并审计共享资源，不仅仅是共享数据。
```
// 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. 静默节点故障。
在一条链中，一个故障会停止一切，很烦人但很明显。在一个图中，两百个节点中一个死掉的节点可能会溜进一份看起来完整的报告中。
修复方法：每个合并步骤都将其输入数量与预期数量进行核对，并标记缺口，而不是悄悄地在一半的数据上运行。
```
// 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 complete
```
## 8 - 你真的需要一个吗？
按照我文章的传统，让我们诚实地弄清楚这对谁甚至可能有用。
图买来的是广度。它买不来更好的判断。
它是一个用于宽度、用于同时完成独立工作的工具。当工作不宽的时候，那条线从来就不是问题。
在这些情况下跳过图：
- 任务很小或孤立。添加一个函数，修复一个 bug。协调纯粹是开销，单个智能体更快更便宜。
- 你想批准每一步。图的全部意义是在没有你的情况下宽幅运行，所以紧紧束缚与它背道而驰。
- 你还不知道你在找什么。探索性工作需要一个你可以引导的智能体，而不是锁定在计划中的一支舰队。
- 步骤确实相互依赖。将图强加于真正顺序的工作上只会增加成本而零提速。
- 信号是虚假边测试。如果你找不到两个它们之间没有边的工作，就没有图可以构建。它是一个循环，而循环是没问题的。
## 9 - 没人想听的部分：锚点。
这里有一个更深的陷阱，这是整个转变的真正教训。
想象你构建了完整的图。成对的检查器，审计节点，调整其他节点的元节点。每个节点监视另一个节点，它们每个人都在读一份报告。
审计将数字与财务数字核对，而这些数字最初来自同一个系统。
一切都是一致的。没有任何东西被验证。
这个图就像单一循环一样失败，只是更晚，更昂贵，并且在沿途有更多的绿灯。
仅靠拓扑结构买不来真理。图需要锚点：无法被争论的节点。
实际运行的测试，不是“应该通过”，而是真的通过了。落入银行的收入。真正留住的客户。
有些规则必须被冻结，那些优化器会试图削弱的规则，正是因为它们是它会为了获胜而弯曲的规则，所以要被禁止触碰。
图的诚实度取决于其中那些拒绝移动的东西。
用无法回嘴的数字来判断它，它就能脚踏实地。让它给自己报告打分，它会自信地犯错。
## 10 - 在 Claude Code 中亲手构建一个。
理论够多了。如果你已经决定这适合你，或者你只是想试试，让我们构建一个。你可以在几分钟内构建一个真正的图，因为 Claude Code 发布了直接执行此操作的工具，称为动态工作流。
这归结为一个词：“工作流”。
把它放在你的提示词中，Claude 就会停止通过单一的步骤行工作。相反，它编写一个简短的协调脚本，然后生成一个协调的子智能体舰队来运行它。
重要的是协调是代码，而不是对话。在智能体之间传递结果不会像聊天移交那样重新花费你的上下文，这就是让一次运行扩展到整个舰队而不会淹没会话的原因。
打开一个你知道的真实仓库，粘贴这个：
```
▸ 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 发出信号它正在构建工作流而不是在正常聊天中回答，并在做任何事情之前向你展示计划。你阅读并批准。
然后舰队运行。每个文件一个智能体，同时进行，而你自己的会话在整个过程中保持空闲。
最后落地的不是二十个单独的聊天供你挖掘。它是一份报告。中间的结果存在于脚本内部，从来不在你的上下文中，所以你唯一实际看到的是最终答案。
这就是一个图。用一句话，十几个智能体。当一次运行出来很好时，保存它，它就变成一个你可以永远按名称重新运行的命令。
注意那个提示词中的“20 个文件”上限。它让你的第一次运行保持便宜，它暗示了每个演示都遗漏的东西：账单。
## 11 - 你可以立即粘贴的现成图。
这些每一个都是针对不同工作的同样的菱形。在一个真实的文件夹中打开 Claude Code，将括号中的部分换成你自己的，然后粘贴。单词“工作流”是告诉 Claude 构建一个协调的舰队而不是单一步骤行的东西。在任何东西发布之前，你自己保持最后的“是”。
一个决策级研究台。取代一周的谷歌搜索或昂贵的分析师发票。你的问题分叉成角度，研究人员一次挖掘，怀疑论者攻击每个发现，只有幸存者到达报告。
```
▸ 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)
```
一个 SEO 内容机器。每次运行写一份排名就绪的草稿，并且没有你绝不发布。
```
▸ 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)
```
一个上市套件。一次运行的完整发布包，由你批准每一部分。
```
▸ 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)
```
一个跨整个仓库的重构扫描。没有任何单一上下文能容纳的广度。
```
▸ 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)
```
一个大小未知的发现循环。对于你不知道工作有多大直到你深入其中的工作，比如一个 bug 清扫，发现一个 bug 揭示了更多三个。
```
▸ 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)
Run one scoped, watch what it costs, then widen. When a run is good, save it, and every one of these becomes a single command you launch by name.
```
## 12 - 成本和监督。
图比正常聊天花费更多。多得多。变便宜的是协调，而不是工作本身。智能体仍然在烧掉 token，一支舰队会烧掉一堆。
最清楚的例子是公开的。一位工程师使用这个确切的设置重写了 Bun 运行时，在大约十一天内将一种语言的约 535,000 行代码翻译成另一种语言的超过一百万行代码。如果是人工，这接近一年的工作。
它运行了大约 50 个工作流，一次最多有 64 个智能体在运行。
它还花费了大约 165,000 美元的使用费，需要一个人设计和监视整个过程，并受到了关于那么多 AI 编写的代码是否甚至可以安全审查的真实批评。
这就是它的诚实形状。一个图可以分叉到一千个智能体，并吞噬掉没有任何单一上下文能容纳的工作。如果你把它指向错误的任务或跳过锚点，它也可以在背景中悄悄花掉你的钱。
所以重型版本是针对有预算、有上限和有监控来运行它的团队的。如果那还不是你，你没有错过任何东西。从小处开始，观察一次运行花费什么，并且只有在一个已经赢得权利后才变得更宽。
## 13 - 这对你到底意味着什么。
这就是全貌。你现在知道图是什么，它在哪里闪光，它在哪里崩溃，以及它实际上是为谁准备的。
你知道它的优势：广度，独立工作一次完成。以及它的弱点：它买来的是宽度，而不是判断，如果你把它指向错误的工作，它会花掉你的钱。
所以这一步不是把所有东西都变成图。而是知道工作什么时候足够宽需要图，以及什么时候一个简单的循环一直都是答案。
我的看法：今晚学习虚假边测试。画出你当前的工作流，找出那些不传输数据的边，然后删除它们。仅此一举就让你在触摸任何新工具之前比大多数人更快。
大多数人将继续在线条中排队步骤。少数学会画图的人将运行一支舰队。
如果你想跟上 AI 发生的一切，请在 X 和 Telegram 上关注我：
X - https://x.com/AnatoliKopadze
Telegram - https://t.me/kopadzemp
## 相关链接
- [Anatoli Kopadze](https://x.com/AnatoliKopadze)
- [@AnatoliKopadze](https://x.com/AnatoliKopadze)
- [131K](https://x.com/AnatoliKopadze/status/2080668775796314331/analytics)
- [https://x.com/AnatoliKopadze](https://x.com/AnatoliKopadze)
- [https://t.me/kopadzemp](https://t.me/kopadzemp)
- [Jul 18](https://x.com/steipete/status/2078277297791189132)
- [https://x.com/AnatoliKopadze](https://x.com/AnatoliKopadze)
- [https://t.me/kopadzemp](https://t.me/kopadzemp)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [10:57 PM · Jul 24, 2026](https://x.com/AnatoliKopadze/status/2080668775796314331)
- [131.6K Views](https://x.com/AnatoliKopadze/status/2080668775796314331/analytics)
- [View quotes](https://x.com/AnatoliKopadze/status/2080668775796314331/quotes)
---
*导出时间: 2026/7/25 11:34:36*