# The complete Graph Engineering playbook for Claude Code
**作者**: Gyomei
**日期**: 2026-07-23T08:53:02.000Z
**来源**: [https://x.com/Gyome1_/status/2080214593301774344](https://x.com/Gyome1_/status/2080214593301774344)
---
Most people are still using Claude Code like a very expensive intern.
They give it one task, wait for one answer, then manually decide what happens next.
But the teams getting the most leverage from AI are building something closer to a small distributed system.
*(视频内容)*
One agent scopes the problem.
Five cheaper agents search in parallel.
A deterministic script removes duplicates.
Three skeptical agents try to break the findings.
One top-tier model makes the final judgment.
That is graph engineering.
## Before you keep reading:
Bookmark this guide so you can return to the graph patterns when you start building your own Claude workflows.
> And follow @Gyome1_ - I break down Claude Code, AI agents, and the systems that turn one model into a reliable engineering workflow.
I spent weeks dissecting real agent architectures, workflow diagrams, and production patterns to rebuild Graph Engineering into one practical playbook.
Instead of writing a longer prompt, you design the path information takes through the system:
linear → fan-out → reduce → verify → synthesize
Each agent becomes a node with a bounded job. Each edge carries structured data. Routers decide which branch runs. Verifiers reject weak outputs. Loops continue until the graph stops finding anything new.
The important shift is that Claude Code no longer has to behave like one intelligence working through a giant checklist.
It can generate the orchestration code, spawn a fleet of specialized subagents, route their outputs through different models, and assemble the final result only after the evidence survives verification.
The basic patterns are not new. Software engineers have used DAGs, pipelines, barriers, MapReduce, and distributed workers for decades.
What changed is what now sits inside each node.
A node can search a repository, audit a migration, challenge an architectural decision, inspect test failures, or synthesize fifty independent findings into one cited report.
This guide breaks the entire system down from the simplest linear agent to diamond graphs, router nodes, adversarial verifier panels, converging loops, model tiering, and dynamic workflows generated directly inside Claude Code.
By the end, you will be able to look at a large task and stop asking:
"What prompt should I write?"
## 1. GRAPH ENGINEERING STARTS WITH THE BILL
Graph engineering is often presented as a way to run more agents.
That framing misses the expensive part.
You can launch twenty Claude agents against the same repository and receive twenty overlapping reports, repeated context, conflicting conclusions, and a much larger API bill.
A useful graph controls where computation happens, which model handles each decision, and how uncertain findings move through the workflow.
Imagine asking Claude Code to prepare a production migration:
> Inspect the repository, find every dependency, propose the migration, identify risks, verify the plan, and write the final brief.
Inside one prompt, this becomes a long opaque process. Claude searches the codebase, stores findings in context, designs the migration, reviews its own plan, and produces the final report.
When the report fails, the source of the failure is difficult to locate. Claude may have missed a file, misunderstood a dependency, lost an earlier detail, or accepted a weak assumption during verification.
Every stage may also run on the same expensive model, even when parts of the task involve simple extraction or sorting.
Graph engineering opens that workflow and gives every decision a visible place.
The inspection branches run at the same time because they use the same scoped task and do not depend on each other’s output.
Their findings meet at a reduce stage, where duplicates disappear and evidence is compressed into a smaller dataset.
A router then reads the severity. Routine changes move through a lightweight review. High-risk findings receive deeper analysis from several independent reviewers before reaching the final model.
The result is a workflow where latency, model cost, context size, and verification depth are controlled through the graph’s structure.
## A node should make one decision
A useful node has a bounded responsibility.
> Find every call to the deprecated API.
> Classify each migration risk as low, medium, or high.
> Test the rollback plan for failure cases.
Each node needs a clear input, a defined output, and a limited decision surface.
A node that searches the repository, estimates business impact, designs the fix, and writes the recommendation still contains several hidden stages. Debugging remains difficult because the intermediate reasoning is buried inside one model call.
Smaller boundaries reveal where evidence entered the system and where its meaning changed.
## An edge should carry evidence
An edge represents data required by the next node.
The scanner can return a predictable object:
```
{
"file": "src/auth/session.ts",
"lines": [84, 119],
"dependency": "legacySessionClient",
"confidence": 0.94,
"evidence": "Both call sites depend on the deprecated refresh method."
}
```
The risk classifier now receives the same fields for every finding. It can reject incomplete results, group related files, and route uncertain evidence into another review.
Schemas reduce interpretation drift between nodes. Free-form paragraphs force every downstream agent to reconstruct the previous agent’s meaning. Over several stages, small ambiguities can alter the final conclusion.
Structured output keeps the evidence stable while it moves through the graph.
## Some nodes are ordinary code
Suppose eight search agents return eighty findings.
The workflow needs to combine arrays, discard empty responses, remove duplicates, and sort the remaining items.
These operations have deterministic answers:
```
const uniqueFindings = [
...new Map(
results
.flatMap(batch => batch ?? [])
.map(item => [`${item.file}:${item.lines.join("-")}`, item])
).values()
];
```
A JavaScript transform handles this instantly and produces the same output on every run. Sending the same task to another model adds token cost and creates another place where evidence can disappear.
Model nodes belong around search, classification, comparison, review, and synthesis. Code can handle validation, deduplication, sorting, explicit routing rules, and other predictable transformations.
This division becomes the foundation of the graph.
Every model call should correspond to a decision that genuinely requires judgment.
## 2. THE DIAMOND: HOW REAL AGENT GRAPHS MOVE WORK
Most serious agent graphs eventually take the same shape.
A task begins with one shared scope, splits across several independent workers, waits for their outputs, compresses the evidence, and passes the result into a final decision.
That shape is the diamond.
The left side is fan-out.
The middle point where all branches meet is the barrier.
The right side is fan-in.
This pattern appears everywhere once a task becomes too large for one context window.
A repository audit can split by subsystem. A market report can split by source. A research task can split by hypothesis. A migration review can split across API usage, database changes, deployment risk, and test coverage.
Each worker receives the same scope with a narrower assignment.
The graph then waits until enough useful evidence has returned.
## Fan-out should create independent work
A branch belongs in the fan-out when it can begin from the shared input and produce a useful result without reading the output of another branch.
For a security audit, the split might look like this:
Claude Code can launch these calls concurrently with a barrier primitive such as parallel()
```
const findings = await parallel(
checks.map(check => async () => {
return agent({
task: check.task,
context: auditScope,
schema: FINDING_SCHEMA
});
})
);
```
The orchestration stays in ordinary JavaScript. Each branch receives a bounded task and returns a validated object.
The result arrives as a collection of outputs that can be filtered, inspected, and passed into the next stage.
A large fan-out still needs a reason behind every branch.
Splitting one vague assignment into twelve nearly identical agents often produces repeated findings with slightly different wording. Useful parallelism comes from distinct sources, perspectives, code regions, or hypotheses.
## The barrier creates a decision point
A barrier pauses the next stage until the required branches have completed.
That pause matters because some decisions depend on the full set.
A ranking node cannot identify the most important vulnerability while half of the repository is still being inspected. A synthesis model cannot write a complete migration plan while the deployment review is still running.
At the barrier, the graph has a chance to inspect the state of the run:
```
const completed = findings.filter(Boolean);
if (completed.length < MIN_REQUIRED_RESULTS) {
throw new Error("Insufficient audit coverage");
}
```
This is where partial failures become visible.
A worker may time out, return malformed data, or produce no findings. Filtering null values keeps the run moving, but production workflows usually need a clearer policy:
- how many successful branches are required;
- which branches are mandatory;
- whether a failed node should retry;
- whether the final result should be marked incomplete.
The barrier is therefore part of the reliability model, not just a synchronization mechanism.
## Reduce before you synthesize
After fan-out, the graph may hold dozens of overlapping findings.
Sending all of them directly into a top-tier model creates a large context, repeats the same evidence, and makes important details harder to distinguish.
The reduce stage prepares the evidence.
Some reduction can happen in code:
```
const unique = deduplicateByKey(
completed.flatMap(result => result.findings),
finding => `${finding.file}:${finding.line}:${finding.type}`
);
```
The next layer may require judgment:
```
const curated = await agent({
task: `
Group related findings.
Preserve all file and line references.
Rank each group by operational impact.
Return the strongest evidence for every conclusion.
`,
input: unique,
schema: CURATED_FINDINGS_SCHEMA
});
```
Reduction controls what reaches the final model.
A good reducer removes repetition while preserving evidence. An aggressive reducer may compress several distinct risks into one vague summary and erase the details needed for verification.
The safest pattern keeps a link between every reduced claim and its source items.
```
{
"risk": "Session refresh may fail after migration",
"severity": "high",
"sourceFindingIds": ["AUTH-04", "API-11", "TEST-07"],
"evidence": [
"Three services call the deprecated refresh method",
"No fallback path exists",
"Integration coverage is missing"
]
}
```
Now the synthesis node receives a smaller dataset without losing traceability.
## 3. RELIABILITY IS PART OF THE GRAPH
A graph can finish quickly and still produce a bad answer.
Once several agents begin searching, classifying, and reviewing the same task, the main problem becomes control.
The system needs rules for deciding which findings deserve deeper work, which outputs should be rejected, and when the workflow has searched enough.
## Route by risk
A router node reads structured output and chooses the next branch.
The classification can come from a model, while the branch itself stays explicit in code.
```
const route =
finding.severity === "high"
? runFullAudit(finding)
: runQuickReview(finding);
```
This keeps expensive review concentrated around findings with meaningful impact.
A useful router relies on fields the graph can inspect: severity, confidence, affected systems, financial exposure, or the presence of missing evidence.
## Add independent verification
One agent reviewing its own conclusion carries the same assumptions into both stages.
A stronger graph sends important findings to several reviewers with different assignments.
The reviewers should not receive instructions to improve the original answer. Their task is to search for reasons it may be incomplete or wrong.
The graph can require agreement before a finding moves forward:
```
const accepted = votes.filter(vote => vote.approve).length >= 2;
```
## Isolate agents that change code
Parallel coding agents can interfere with each other when they edit the same working directory.
One agent may overwrite a file while another is still reading it. Tests may run against a mixture of unrelated changes.
Git worktrees give each branch its own copy of the repository.
```
main repository
│
├→ worktree/auth-fix
├→ worktree/db-migration
└→ worktree/test-repair
```
Each agent can modify files and run tests inside its own environment. A later node compares the patches, checks conflicts, and selects what should be merged.
This turns isolation into part of the graph rather than a manual cleanup step.
## Let discovery converge
Some tasks cannot be completed in one pass.
A repository audit may uncover a dependency that points toward another package. That package may reveal another call site. The graph needs a controlled way to continue searching without repeating everything it has already seen.
```
const seen = new Set();
let dryRounds = 0;
while (dryRounds < 2) {
const findings = await discoverNext([...seen]);
const fresh = findings.filter(item => !seen.has(item.id));
fresh.forEach(item => seen.add(item.id));
dryRounds = fresh.length === 0 ? dryRounds + 1 : 0;
}
```
The important detail is deduplicating against every previously seen item.
Deduplicating only against confirmed findings allows rejected or uncertain items to return on the next pass and consume the same work again.
The loop stops after several dry rounds, a fixed budget, or a maximum number of iterations. Production graphs usually need all three.
## Match the model to the node
Every node does not need the strongest available model.
Extraction, basic classification, and narrow searches can often run on a faster tier. Architecture review, adversarial verification, and final synthesis may justify a stronger model.
Model tiering becomes another property of the graph.
The budget is determined by how many nodes run, how often loops repeat, how much context crosses each edge, and which model handles each stage.
A graph with twenty cheap search calls can still cost more than one strong call. The architecture needs a token budget before it needs another branch.
## Know when to stop drawing
Small tasks rarely need routers, voting panels, worktrees, and convergence loops.
Graph overhead includes orchestration code, schemas, retries, logging, intermediate storage, and more failure states to debug.
A linear workflow is usually sufficient when one model can hold the relevant context, the task has few independent branches, and the cost of a wrong answer is low.
Graph engineering becomes useful as the task gains parallel work, expensive decisions, large evidence sets, or meaningful verification requirements.
The complete workflow may eventually look like this:
The value comes from making the movement of work visible.
Every node has a limited responsibility. Every edge carries structured evidence. Every branch has a reason to exist. Every loop has a stopping condition.
At that point, Claude Code is no longer working through one long instruction.
It is executing an engineered system.
## 相关链接
- [Gyomei](https://x.com/Gyome1_)
- [@Gyome1_](https://x.com/Gyome1_)
- [23K](https://x.com/Gyome1_/status/2080214593301774344/analytics)
- [@Gyome1_](https://x.com/@Gyome1_)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [4:53 PM · Jul 23, 2026](https://x.com/Gyome1_/status/2080214593301774344)
- [23.6K Views](https://x.com/Gyome1_/status/2080214593301774344/analytics)
- [View quotes](https://x.com/Gyome1_/status/2080214593301774344/quotes)
---
*导出时间: 2026/7/24 09:37:55*
---
## 中文翻译
# Claude Code 图形工程完整指南
**作者**: Gyomei
**日期**: 2026-07-23T08:53:02.000Z
**来源**: [https://x.com/Gyome1_/status/2080214593301774344](https://x.com/Gyome1_/status/2080214593301774344)
---
大多数人仍在像对待一名非常昂贵的实习生那样使用 Claude Code。
他们给它一个任务，等待一个答案，然后手动决定下一步做什么。
但是，那些从 AI 中获得最大杠杆效应的团队正在构建某种更接近小型分布式系统。
*(视频内容)*
一个代理界定问题范围。
五个更便宜的代理并行搜索。
一个确定性脚本去除重复项。
三个持怀疑态度的代理试图推翻发现。
一个顶级模型做出最终判断。
这就是图形工程。
## 在继续阅读之前：
请收藏这份指南，以便在你开始构建自己的 Claude 工作流时能够参考这些图形模式。
> 并关注 @Gyome1_ —— 我会拆解 Claude Code、AI 代理，以及将单个模型转化为可靠工程工作流的系统。
我花了几周时间剖析真实的代理架构、工作流图和生产模式，将图形工程重构为一份实用的指南。
你不再需要编写更长的提示词，而是设计信息在系统中流动的路径：
线性 → 扩散 → 归约 → 验证 → 综合
每个代理都成为一个具有明确职责的节点。每条边承载结构化数据。路由器决定运行哪个分支。验证器拒绝薄弱的输出。循环持续进行，直到图形不再发现任何新内容。
重要的转变在于，Claude Code 不再需要表现得像是一个处理巨大清单单一智能体。
它可以生成编排代码，生成一组专门的子代理，将其输出路由通过不同的模型，并仅在证据通过验证后组装最终结果。
基本模式并不新鲜。软件工程师使用 DAG（有向无环图）、流水线、屏障、MapReduce 和分布式工作器已经有几十年了。
发生变化的是每个节点内部的内容。
一个节点可以搜索代码库、审计迁移、挑战架构决策、检查测试失败，或者将五十个独立的发现综合成一份有引用的报告。
本指南将整个系统从最简单的线性代理分解为菱形图、路由节点、对抗性验证面板、收敛循环、模型分层以及直接在 Claude Code 内部生成的动态工作流。
阅读结束后，面对一个大型任务，你将不再问自己：
“我该写什么提示词？”
## 1. 图形工程始于账单
图形工程通常被呈现为运行更多代理的一种方式。
这种框架忽略了昂贵的那部分。
你可以针对同一个仓库启动二十个 Claude 代理，并收到二十份重叠的报告、重复的上下文、相互冲突的结论，以及一张大得多的 API 账单。
一个有用的图形控制计算发生的位置、哪个模型处理每个决策，以及不确定的发现如何在工作流中流转。
想象一下让 Claude Code 准备一次生产迁移：
> 检查仓库，找到每个依赖项，提议迁移，识别风险，验证计划，并撰写最终简报。
在一个提示词内部，这变成了一个漫长且不透明的过程。Claude 搜索代码库，将发现存储在上下文中，设计迁移方案，审查自己的计划，并生成最终报告。
当报告失败时，很难定位失败源。Claude 可能漏掉了一个文件、误解了一个依赖项、丢失了一个早期的细节，或者在验证期间接受了一个薄弱的假设。
每个阶段也可能在同一个昂贵的模型上运行，即使任务的部分内容涉及简单的提取或排序。
图形工程打开了这个工作流，赋予每个决策一个可见的位置。
检查分支同时运行，因为它们使用相同的界定任务且不依赖于彼此的输出。
它们的发现会在归约阶段汇合，重复项消失，证据被压缩成更小的数据集。
然后，路由器读取严重性。常规更改通过轻量级审查。高风险发现在到达最终模型之前，会接受几个独立审查员的更深入分析。
结果是一个通过图形结构控制延迟、模型成本、上下文大小和验证深度的工作流。
## 一个节点应该只做一个决策
一个有用的节点具有明确的职责。
> 找到对弃用 API 的每一次调用。
> 将每个迁移风险分类为低、中或高。
> 针对失败情况测试回滚计划。
每个节点都需要清晰的输入、定义的输出和有限的决策界面。
一个搜索仓库、评估业务影响、设计修复方案并撰写建议的节点仍然包含几个隐藏阶段。调试仍然很困难，因为中间推理被埋没在单个模型调用中。
更小的边界能揭示证据是在哪里进入系统的，以及它的含义是在哪里改变的。
## 一条边应该承载证据
一条边代表下一个节点所需的数据。
扫描器可以返回一个可预测的对象：
```
{
"file": "src/auth/session.ts",
"lines": [84, 119],
"dependency": "legacySessionClient",
"confidence": 0.94,
"evidence": "Both call sites depend on the deprecated refresh method."
}
```
风险分类器现在接收到每个发现的相同字段。它可以拒绝不完整的结果，对相关文件进行分组，并将不确定的证据路由到另一个审查流程。
模式减少了节点之间的解释偏差。自由形式的段落迫使每个下游代理重建前一个代理的含义。经过几个阶段，小的歧义可能会改变最终的结论。
结构化输出在证据通过图形时保持其稳定。
## 有些节点只是普通代码
假设八个搜索代理返回了八十个发现。
工作流需要合并数组、丢弃空响应、去除重复项并对其余项目进行排序。
这些操作具有确定性答案：
```
const uniqueFindings = [
...new Map(
results
.flatMap(batch => batch ?? [])
.map(item => [`${item.file}:${item.lines.join("-")}`, item])
).values()
];
```
一个 JavaScript 转换可以立即处理此问题，并在每次运行时产生相同的输出。将相同的任务发送给另一个模型会增加 Token 成本，并创建另一个证据可能消失的地方。
模型节点适用于搜索、分类、比较、审查和综合。代码可以处理验证、去重、排序、显式路由规则和其他可预测的转换。
这种划分成为了图形的基础。
每个模型调用都应对应一个真正需要判断的决策。
## 2. 菱形：真实的代理图如何移动工作
大多数严肃的代理图最终都会采用相同的形状。
一个任务始于一个共享的范围，分流到几个独立的工作器，等待它们的输出，压缩证据，并将结果传递给最终决策。
这种形状就是菱形。
左侧是扩散。
所有分支汇合的中间点是屏障。
右侧是归约。
一旦任务变得太大而无法放入单个上下文窗口，这种模式就无处不在。
仓库审计可以按子系统拆分。市场报告可以按来源拆分。研究任务可以按假设拆分。迁移审查可以拆分为 API 使用、数据库更改、部署风险和测试覆盖率。
每个工作器接收相同的范围，但分配的任务更窄。
然后，图形会等待直到返回了足够有用的证据。
## 扩散应该创建独立的工作
当一个分支可以从共享输入开始并在不读取另一个分支输出的情况下产生有用结果时，它就属于扩散。
对于安全审计，拆分可能如下所示：
Claude Code 可以使用诸如 parallel() 之类的屏障原语并发启动这些调用
```
const findings = await parallel(
checks.map(check => async () => {
return agent({
task: check.task,
context: auditScope,
schema: FINDING_SCHEMA
});
})
);
```
编排保留在普通的 JavaScript 中。每个分支接收一个界定任务并返回一个验证过的对象。
结果作为输出集合到达，这些输出可以被过滤、检查并传递到下一个阶段。
大的扩散仍然需要在每个分支背后都有理由。
将一个模糊的分配拆分为十二个几乎相同的代理，通常会产生措辞略有不同的重复发现。有用的并行性来自不同的来源、视角、代码区域或假设。
## 屏障创建了一个决策点
屏障会暂停下一阶段，直到所需的分支完成为止。
这种暂停很重要，因为某些决策依赖于完整的数据集。
当仓库的一半仍在检查中时，排名节点无法识别最重要的漏洞。当部署审查仍在运行时，综合模型无法编写完整的迁移计划。
在屏障处，图形有机会检查运行状态：
```
const completed = findings.filter(Boolean);
if (completed.length < MIN_REQUIRED_RESULTS) {
throw new Error("Insufficient audit coverage");
}
```
这正是部分失败变得可见的地方。
工作器可能会超时、返回格式错误的数据或没有产生任何发现。过滤 null 值可以使运行继续进行，但生产工作流通常需要更清晰的策略：
- 需要多少个成功的分支；
- 哪些分支是强制性的；
- 失败的节点是否应该重试；
- 最终结果是否应标记为不完整。
因此，屏障是可靠性模型的一部分，而不仅仅是一种同步机制。
## 综合前先归约
在扩散之后，图形可能包含几十个重叠的发现。
将所有这些直接发送给顶级模型会创建一个巨大的上下文，重复相同的证据，并使重要细节更难区分。
归约阶段准备证据。
一些归约可以在代码中发生：
```
const unique = deduplicateByKey(
completed.flatMap(result => result.findings),
finding => `${finding.file}:${finding.line}:${finding.type}`
);
```
下一层可能需要判断：
```
const curated = await agent({
task: `
Group related findings.
Preserve all file and line references.
Rank each group by operational impact.
Return the strongest evidence for every conclusion.
`,
input: unique,
schema: CURATED_FINDINGS_SCHEMA
});
```
归约控制着什么能到达最终模型。
一个好的归约器在去除重复的同时保留证据。一个激进的归约器可能会将几个不同的风险压缩成一个模糊的摘要，并抹去验证所需的细节。
最安全的模式是在每个归约后的声明及其源项目之间保持链接。
```
{
"risk": "Session refresh may fail after migration",
"severity": "high",
"sourceFindingIds": ["AUTH-04", "API-11", "TEST-07"],
"evidence": [
"Three services call the deprecated refresh method",
"No fallback path exists",
"Integration coverage is missing"
]
}
```
现在，综合节点接收到一个较小的数据集，而不会丢失可追溯性。
## 3. 可靠性是图形的一部分
一个图形可以快速完成但仍然产生错误的答案。
一旦几个代理开始搜索、分类和审查相同的任务，主要问题就变成了控制。
系统需要规则来决定哪些发现值得更深入的工作，哪些输出应该被拒绝，以及工作流何时已经搜索了足够的内容。
## 按风险路由
路由节点读取结构化输出并选择下一个分支。
分类可以来自模型，而分支本身在代码中保持显式。
```
const route =
finding.severity === "high"
? runFullAudit(finding)
: runQuickReview(finding);
```
这使得昂贵的审查集中在具有有意义影响的发现上。
有用的路由器依赖于图形可以检查的字段：严重性、置信度、受影响的系统、财务风险敞口或缺少证据的存在。
## 添加独立验证
一个代理审查自己的结论会将相同的假设带入两个阶段。
一个更强的图形将重要的发现发送给几个具有不同分配的审查员。
审查员不应收到改进原始答案的指令。他们的任务是寻找它可能不完整或错误的原因。
图形可以要求在发现向前推进之前达成一致：
```
const accepted = votes.filter(vote => vote.approve).length >= 2;
```
## 隔离更改代码的代理
并行编码代理在编辑同一个工作目录时可能会相互干扰。
一个代理可能会覆盖一个文件，而另一个代理仍在读取它。测试可能会针对混合的无关更改运行。
Git worktree 为每个分支提供自己的仓库副本。
```
main repository
│
├→ worktree/auth-fix
├→ worktree/db-migration
└→ worktree/test-repair
```
每个代理都可以在自己的环境中修改文件并运行测试。随后的节点比较补丁、检查冲突并选择应合并的内容。
这将隔离变成图形的一部分，而不是一个手动清理步骤。
## 让发现收敛
某些任务无法在一次通过中完成。
仓库审计可能会发现一个指向另一个包的依赖项。该包可能会揭示另一个调用点。图形需要一种受控的方式来继续搜索，而不重复它已经看过的所有内容。
```
const seen = new Set();
let dryRounds = 0;
while (dryRounds < 2) {
const findings = await discoverNext([...seen]);
const fresh = findings.filter(item => !seen.has(item.id));
fresh.forEach(item => seen.add(item.id));
dryRounds = fresh.length === 0 ? dryRounds + 1 : 0;
}
```
重要的细节是针对每个以前见过的项目进行去重。
仅针对已确认的发现进行去重，允许被拒绝或不确定的项目在下一轮返回并消耗相同的工作。
循环在几次空轮次、固定预算或最大迭代次数后停止。生产图形通常需要这三者。
## 将模型与节点匹配
并非每个节点都需要可用的最强模型。
提取、基本分类和窄搜索通常可以在更快的层级上运行。架构审查、对抗性验证和最终综合可能证明使用更强的模型是合理的。
模型分层成为图形的另一个属性。
预算由运行多少个节点、循环重复的频率、有多少上下文穿过每条边以及哪个模型处理每个阶段决定。
具有二十个廉价搜索调用的图形可能仍然比一个强调用花费更多。架构在需要另一个分支之前需要一个 Token 预算。
## 知道何时停止绘制
小任务很少需要路由器、投票面板、worktree 和收敛循环。
图形开销包括编排代码、模式、重试、日志记录、中间存储和更多需要调试的失败状态。
当一个模型可以容纳相关的上下文、任务几乎没有独立分支且错误答案的成本很低时，线性工作流通常就足够了。
随着任务获得并行工作、昂贵的决策、大型证据集或有意义的验证要求，图形工程变得有用。
完整的工作流最终可能如下所示：
价值来自于使工作的移动可见。
每个节点都有有限的职责。每条边都承载结构化证据。每个分支都有存在的理由。每个循环都有停止条件。
在那时，Claude Code 不再是在处理一条长长的指令。
它正在执行一个工程化的系统。
## 相关链接
- [Gyomei](https://x.com/Gyome1_)
- [@Gyome1_](https://x.com/Gyome1_)
- [23K](https://x.com/Gyome1_/status/2080214593301774344/analytics)
- [@Gyome1_](https://x.com/@Gyome1_)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [4:53 PM · Jul 23, 2026](https://x.com/Gyome1_/status/2080214593301774344)
- [23.6K Views](https://x.com/Gyome1_/status/2080214593301774344/analytics)
- [View quotes](https://x.com/Gyome1_/status/2080214593301774344/quotes)
---
*导出时间: 2026/7/24 09:37:55*