14 张图，一份路线图：从 0 到 Graph Architect 的 Claude Code 实战路径

来源：X 推文 https://x.com/0xCodez/status/2079165300625330317 ——@0xCodez 发布的 17 张图组成的图文教程《Graph Engineering with Claude: 14-Step roadmap from 0 to graph architect (Full Course)》。

本文翻译 + 深度解读，全文基于 17 张原图的 OCR 文字逐句校核，不引入 OCR 之外未声明的素材。

写在前面：为什么是"图"

十年前，软件工程师谈论图数据库，第一反应往往是 Neo4j、Property Graph、Cypher——一种"比关系型更适合某些查询"的数据库技术。十年后，再讲"图"，讲的不是数据库，是整套软件系统应该如何被建模。

@0xCodez 抛出的这条 14 步路线图，把"图"从数据库层拔到了编程范式层。封面那张散落着 Graph、/graph、nodes、edges、schema、memory、routing、MATCH (n)-[r]->(m) 字样的图，配上 ONE 14 STEPS, ONE ROADMAP. 的标题，只说了一件事：

代码应该用图写，而不是用行写。

LINEAR（一条线）把所有事情串起来，等着前面跑完才走下一步，4x time 是基本代价。GRAPH（独立节点扇出、汇聚）让四件独立的事并行执行，跑完再合流——同样的四件事，时间从 4x 压成 1x。

性能不是这里的主角。把"串行等待"改成"并行扇出 + 合流"，改变的是系统被建模的方式；这一步迈过去，后面 13 步才有立足点。

一句话总览：这是一条把 Claude Code 当"图执行引擎"用的进阶路线——先用 6 张方法论图定位领域，再用 14 步把 Agent 的内部结构建模成图（节点是 Subagent / 任务 / 阶段，边是依赖与消息），最后用一张终极组装图把全部原则收拢成可运行系统。全文基于原推 17 张图的 OCR 文字校核，解读与代码示例为作者所加，原图内容不改写。

下面这张封面图，把所有 14 步浓缩在一页里：

[图 1 · 封面] ONE 14 STEPS, ONE ROADMAP.
（OCR 原文作"9 14 STEPS"，明显漏字；按图意订正为 ONE 14 STEPS。）
Graph
/graph
› nodes
Engineering
7 edges
+ schema
14-step roadmap from 0 to
MATCH (n)-[r]->(m)
memory
graph architect
WHERE n. type = 'User'
RETURN n, r, m
routing

nodes / edges / schema / memory / routing——五个词就是 14 步的全部词汇表。后文每一步都会回到这五个词。

1 · 6 大方法论图：一张图看全景

在进入 14 步之前，@0xCodez 给了第二张"全景图"。这张图把整个领域切成 6 块：

[图 2 · 6 大方法论全景图]
(1) Graph Methodology       (2) AI Agent Methodology
Graph                        Planning, Execution, Memory,
Graph Learning               Data Organization
                             Knowledge Extraction
                             Multi-Agent Coordination
                             Foundation Model
                             Learning Paradigm (RL..)
                             Task Input Processing

(3) AI Agents for Graphs     (4) Graphs for AI Agents
Graph Annotation             Agent Planning
Synthesis                    Agent Execution
Graph Understanding          Agent Memory
  Node Classification        Memory Organization
  Link Prediction            Memory Retrieval
  Message Passing            Agent Coordination
                             Communication Topology

(5) Applications             (6) Challenges and Opportunities
Scientific Computing         Benchmarking Evaluation
Embodied AI                  Graph Foundation Models for Agents
Industrial and Automation    Agentic Information Retrieval
Game AI                      Multimodal Agents
Human Society                Model Context Protocol (MCP)
                             Open Agent Network
                             Privacy and Security

把这 6 块写成一句话：

(3) 和 (4) 是这张图最精妙的二分：AI Agents for Graphs（让 Agent 帮你画图、维护图）vs Graphs for AI Agents（让图帮你组织 Agent 的规划/执行/记忆/协同）。

14 步路线图就是 (4) 那一列的工程化落地——把 Agent 的内部结构建模为图，再把这张图跑起来。

2 · 14 步路线图：从 Linear 到 Assembled Graph

每一步给"目标 / 关键动作 / 核心产出"三件套，配 1-2 段解读。所有图编号与原推文一致。

Step 1 · 把 Linear 改成 Graph

[图 3] LINEAR - ONE LINE, EVERYTHING WAITS
       = 4x time
       GRAPH
       INDEPENDENT NODES FAN, ONE MERGES
       A → D (merge)
       REDRAW: THE SAME FOUR JOBS, ONCE THE NON-CARRYING ARROWS ARE CUT

目标：识别"假装线性、其实可并行"的链路。

关键动作：画一张四节点图（假设 A/B/C/D），把"等待箭头"砍掉，让独立节点并行扇出。

核心产出：一张 fan-out / merge 图，每条边必须有"数据/控制依赖"语义。

解读：4x time 说的是结构代价，不是单次执行慢了。Linear 的每一环都背着前面所有环节的完成时间；把"四件事做完才做下四件"改成"四件事并发做完才合流"，省下的是等待本身。这一步是整条路线的总开关，后面出现的 Diamond、pipeline、worktree 都是从这里起步的并发形态。

Step 2 · Anchor node：找到你的枢纽

[图 4] O sales_info
       Anchor node (premium_vehicles)
       O vehicle_condition
       + O vehicle_info (Upstream Dependencies)
       → premium_vehicles (Anchor)
       → premium_analytics
       → premium_car
       → sales_summary_mv (Downstream Dependency)

目标：在你的领域图里找出 1-3 个 Anchor node。

关键动作：把领域对象画成节点，把"被 join 最多"的标为 Anchor。

核心产出：Anchor → Downstream 清单。

解读：Anchor 的地位来自"被穿越的次数"，而不是业务重要性。关系型建模里对应 join 频次最高的表；图建模里它是 fan-out / fan-in 双高的节点。选 Anchor 直接影响 Step 4 的团队拓扑：Anchor 节点由 Main Agent 自己持有，Downstream 节点拆给 Subagent。

怎么找 Anchor：跑一次度数统计，返回最高的前 5 个节点就是候选；可按节点类型过滤（封面图的示例是 WHERE n.type = 'User'）。对应到 Neo4j 的 Cypher：

// 找出图中最常被穿越的 5 个节点
MATCH (n)-[r]-()
WHERE n.type = 'Domain'
RETURN n.name AS anchor, count(r) AS degree
ORDER BY degree DESC
LIMIT 5;

返回的 anchor 列表就是你的 14 步路线的「枢纽」——Main Agent 应该围绕它们展开。

Step 3 · Schema 即黄金：契约工程三件套

[图 5] Mock   ←→  Provider   ←→  Consumer
       Unit Tests   API Client   routes e.g. /locations
       Schema (golden)

目标：图节点必须有"对外接口契约"——Mock / Provider / Consumer 三方共享一个 Schema(golden)。

关键动作：每个 Anchor node 写一份契约测试，Mock 和 Provider 共用一份 golden schema。

核心产出：schema/*.golden.json + 双向契约测试套件。

解读：多数 Graph Engineering 项目栽在"节点没有对外契约"，而不是图本身画错。先定 Schema(golden)，再让 Mock / Provider / Consumer 三方对着同一份契约测试开发，图从"画出来"变成"可验证"。这一步也是 Step 6（CI Pipeline）的前提——没有 golden schema，CI 里根本不知道拿什么当基线。

Step 4 · Subagent 团队即图

[图 6]                  Main Agent (Team Lead)
                         ├── Spawn Team & Spawn Subagent
                         │   ├── Subagent → Work / Communicate / Claim Tasks
                         │   ├── Subagent → Work / Communicate / Claim Tasks
                         │   └── Subagent → Work / Communicate / Claim Tasks
                         ├── Shared Task List
                         └── Teammate (Communicate / Report)

对比：仅 Main Agent + Spawn Subagent（无 Team）

目标：把"一个 Agent 干所有事"拆成 Main Agent（Team Lead）+ 多个 Subagent 的拓扑。

关键动作：

• Main Agent 只做"拆任务 + 收结果 + 路由决策"；
• Subagent 各管一摊，通过 Shared Task List 通信；
• Teammate 之间可横向 Communicate。

核心产出：Subagent 拓扑图（节点 = Subagent，边 = 通信链路）+ Task List 协议。

解读：这里第一次把"团队"画成图：节点是 Subagent，边是消息，Shared Task List 充当消息总线。Main Agent 只保留"拆任务 + 收结果 + 路由"三个动作，其余全部下沉。Step 2 选的 Anchor 节点落在 Main Agent 手里，Downstream 节点对号入座分给各 Subagent。

Step 5 · Data-flow graph：消息、任务与 ECU

[图 7]  Data-flow graph（Msg1-4 / Task1-4）
        Tasks
        Msg1
        Task1   Msg2
        Msg3   Task2
        Msg4   Task3
                  Task4
        Sensors    Actuators
        Architecture model (AADL)
        ECU ECU ECU ECU ECU ECU
        CAN bus

目标：把数据流图（Data-flow graph）作为 Agent 内部任务的"物理视图"。

关键动作：每个 Task 有明确的输入 Msg / 输出 Msg，传感器 / 执行器是图边界节点。

核心产出：AADL（Architecture Analysis & Design Language）风格的架构模型。

解读：图 7 把"嵌入式 ECU / CAN bus"和"AI Agent 内部数据流"画在同一张图里：Task 之间靠 Msg 端口传数据，传感器与执行器是图的边界。无论载体是车还是 Agent，并发系统的底层都是同一张数据流图——差别只在节点是 ECU 还是 agent，边是 CAN 总线还是消息队列。

AADL（Architecture Analysis & Design Language）本来是嵌入式航电系统的建模语言。把它的"数据流 + 端口 + 调度"搬到 Agent 内部，等于给 Agent 装上航空级的形式化骨架——这是 Step 12（Observed Agent）可观测性设计的前置设施。

Step 6 · CI Pipeline：模板化的 Build/Test/Deploy

[图 8]  TEMPLATE "functional_test"
        fetch installer artifact
        ┌──────────────┬──────────────┬──────────────┐
        │ "Smoke" STAGE│"Functional   │ "Deploy"     │
        │              │ Test" STAGE  │ STAGE        │
        │ "Build"      │ "Test"       │ "Build       │
        │ STAGE        │ STAGE        │ Installer"   │
        │              │              │ STAGE        │
        └──────────────┴──────────────┴──────────────┘
        PIPELINE functional_tests_mac (Param: OS='mac')
        PIPELINE functional_tests_win (Param: OS='win')
        PIPELINE functional_tests_linux (Param: OS='linux')
        PIPELINE "Build"
        PIPELINE "UAT"
        Code SCM Repository

目标：把 CI/CD 也建模为图（Template → Pipeline → Stage）。

关键动作：

• 顶层定义 functional_test 模板（Stage 序列）；
• 平台维（mac/win/linux）实例化成 3 条 Pipeline；
• Build / UAT 是跨平台的横向 Pipeline。

核心产出：CI 模板库 + 多平台矩阵。

解读：图 8 把 14 步路线图带到了 DevOps 实战层。Template → Pipeline → Stage 的三层结构本质就是图：节点是 Stage，边是依赖。

Step 7 · Diverse-Lens Verify：Skeptic 投票门

[图 9]  skeptic: correct?
        skeptic: secure?
        skeptic: repro?
        vote: 2/3
        Answer ← Finding
        DIVERSE-LENS VERIFY: A FINDING MUST SURVIVE SKEPTICS BEFORE IT PASSES THE GATE

目标：每个 Finding（事实/结论/代码变更）必须通过至少 2/3 Skeptic 视角（correct? secure? repro?）才放行。

关键动作：定义 Skeptic 池，每个 Finding 强制走 3 个视角投票。

核心产出：Verifier gate 配置 + 投票记录。

解读：单 Agent 的自我审查有固定盲区——它很难看出自己推理链里的洞。Diverse-Lens 用"刻意质疑"补盲：让不同视角的 Skeptic 轮流挑刺，本质是 Anthropic Constitutional AI 思路在工程上的落地。

为什么是 2/3 而不是 3/3 或 1/3：1/3 容忍太多单点错误，3/3 让一次强异议卡死正常流程；2/3 是少数服从多数的最小可行多数。Skeptic 池要刻意保持视角分散：correct? 看逻辑、secure? 看攻击面、repro? 看实证——视角越重叠，这套门越形同虚设。

Step 8 · Fan-out Diamond：扇出 + 汇聚

[图 10] Split
         ├── agent 1 ─┐
         ├── agent 2 ─┤ FAN OUT
         ├── agent 3 ─┘
                ↓
         Barrier（DEPENDENT NODES, CONCURRENT）
         Reduce & Synthesize
         THE DIAMOND: FAN OUT + REDUCE • • SYNTHESIZE

目标：构造 Diamond 形状的并行子图（Split → fan-out → Barrier → Reduce）。

关键动作：

• Split 节点负责任务分片；
• Barrier 节点等所有 fan-out 完成才放行；
• Reduce & Synthesize 把结果合并。

核心产出：Diamond 节点模板（可复用的 fan-out/reduce 子图）。

解读：Diamond 是"并发"的最小统一抽象：Split 分片、fan-out 并行、Barrier 对齐、Reduce 合并。MapReduce 的 Map+Reduce、CUDA 的 Kernel、Actor 模型的 Router，拆开看都是同一个 Diamond。Step 11 会讨论它的变体——当某个阶段不需要等齐全部结果时，Diamond 就退化成 pipeline。

Diamond 的 Python 实现骨架：

import asyncio

async def diamond(parts: list, fan_out_fn, reduce_fn):
    """Step 8 Diamond: Split → fan-out → Barrier → Reduce"""
    # Split + Fan-out：所有 parts 并发跑同一个 fan_out_fn
    tasks = [asyncio.create_task(fan_out_fn(p)) for p in parts]
    # Barrier：gather 等所有任务完成后才返回
    results = await asyncio.gather(*tasks)
    # Reduce & Synthesize
    return await reduce_fn(results)

# 使用例：5 个子任务并发搜索后聚合
results = await diamond(
    parts=["query1", "query2", "query3", "query4", "query5"],
    fan_out_fn=search_agent,
    reduce_fn=synthesize_report,
)

对应到 LangGraph，把 DiamondState 和节点函数补齐，这段就可以直接运行（需要 pip install langgraph）：

from typing import Annotated, TypedDict
import operator
from langgraph.graph import StateGraph

class DiamondState(TypedDict):
    """Split 分片后的查询，以及各路 search 的搜索结果。"""
    queries: list[str]
    results: Annotated[list[str], operator.add]  # 多条入边自动累加

def split_node(state: DiamondState) -> dict:
    return {"queries": ["query1", "query2", "query3"]}

def search_1_node(state: DiamondState) -> dict:
    return {"results": [f"search_1 命中 {state['queries'][0]}"]}

def search_2_node(state: DiamondState) -> dict:
    return {"results": [f"search_2 命中 {state['queries'][1]}"]}

def search_3_node(state: DiamondState) -> dict:
    return {"results": [f"search_3 命中 {state['queries'][2]}"]}

def reduce_node(state: DiamondState) -> dict:
    return {"results": [f"共 {len(state['results'])} 路结果"]}

graph = StateGraph(DiamondState)
graph.add_node("split", split_node)
graph.add_node("search_1", search_1_node)
graph.add_node("search_2", search_2_node)
graph.add_node("search_3", search_3_node)
graph.add_node("reduce", reduce_node)

graph.add_edge("split", "search_1")
graph.add_edge("split", "search_2")
graph.add_edge("split", "search_3")
# LangGraph 在所有入边都完成后才执行 reduce，天然形成 Barrier
graph.add_edge("search_1", "reduce")
graph.add_edge("search_2", "reduce")
graph.add_edge("search_3", "reduce")

graph.set_entry_point("split")
graph.set_finish_point("reduce")

results 用 operator.add 作 reducer，reduce 节点的入边每完成一路就自动累加一条，这正是 Barrier 语义在状态层的一次落地：图结构决定并发，reducer 决定合流时怎么攒数据。

Step 9 · Conditional Edge：路由器分流

[图 11] Router
         ├─ if high → "high + parallel audit (N agents)"
         └─ else    → "Low + one quick pass"
         CONDITIONAL EDGE: THE MODEL CLASSIFIES, THE CODE ROUTES

目标：把"该不该走复杂分支"的决策从代码里抽出来，放到 Router 节点。

关键动作：

• Model（轻量分类器）判断任务复杂度（high / low）；
• Router 根据分类结果分流（high → 多 Agent 审计；low → 快速单 Pass）；
• 关键原则：模型分类，代码路由。

核心产出：Router 决策表 + 复杂度的轻量分类 prompt。

解读：成本控制的开关放在这里：不是所有任务都值得跑完整 14 步。Router 先用轻量模型分个类，高复杂度走"多 Agent + 并行审计"，低复杂度一条快速 pass 就出去。分类器判断错了最多多花一次重试，比每次都跑全流程省得多。Step 13 的 /model 路由就是这个节点的具体实现。

最小实现是把"分类"和"路由"拆成两层，模型只产出 high / low 一个标签，分支逻辑全部留在代码里：

def classify(task: str) -> str:
    """最小分类器，按关键词打标签；生产环境换成模型调用，输出仍是 high/low"""
    return "high" if any(k in task for k in ["migration", "refactor", "audit"]) else "low"

def quick_pass(task: str) -> str:
    return f"快速 pass：{task}"

def audit_pass(task: str) -> str:
    return f"审计 pass：{task}"

complexity = classify(task)                # 模型只分类，不决定下一步
if complexity == "high":
    results = audit_pass(task)             # 代码负责路由：走审计分支
else:
    results = quick_pass(task)             # 低复杂度：一次快速 pass

分类器换成真实模型后，唯一变化是 classify 内部的实现，接口和分支结构原样保留——这层隔离就是"模型分类，代码路由"在代码上的落点。模型说错最多浪费一次重试，路由逻辑始终由代码掌握，不会被带偏。真实系统里，审计分支内部再挂 Step 8 的 Diamond 做多路并行即可。

Step 10 · Worktree：Git 多分支即多工作树

[图 12]  ~/MyProject/main
         Working tree
         main
         GIT Working tree (feature4 / otherbranch)
         HEAD
         index
         objects
         refs
         commondir
         feature4    otherbranch
         README.md   README.md
         ↓           ↓
         worktrees/  worktrees/
         feature4    otherbranch

目标：用 git worktree 把多分支并行开发显式建模为"多棵 Working tree"。

关键动作：

• 同一 .git 目录（objects / refs / HEAD）共享；
• 每个 feature / otherbranch 是独立 Working tree；
• 每个 Worktree 可由独立 Subagent 操作。

核心产出：Worktree 协议 + Subagent ↔ Worktree 绑定表。

解读：Step 10 把版本管理也纳入了图模型。.git 是节点，worktree 是出边，多分支并行是天然的图并行。

怎么落地到自己的项目：

# 在主仓库目录下创建 3 个 worktree
git worktree add ../myproject-featureA featureA
git worktree add ../myproject-featureB featureB
git worktree add ../myproject-hotfix hotfix

# 每个 worktree 交给一个独立 Subagent
# Main Agent 只负责「调度 + 汇总 + 冲突解决」
ls ../myproject-*/
# → 三个独立 Working tree，共享同一个 .git（objects / refs / HEAD）

对应到 Claude Code：

• ~/acme 是主 worktree，由 Main Agent 直接持有；
• ~/acmedash/api/migration 是 feature worktree（参见 Step 14 图 16），交给 Subagent 处理 fetch() 迁移；
• 三个 worktree 共享 commondir，避免每个分支重复 clone 几百 MB 仓库历史。

Step 11 · Barrier vs Pipeline：并发两态

[图 13] parallel()
         ├── agent A
         ├── agent B (slow) ← BARRIER（everyone waits for the slowest）
         └── agent C
         stage 2 starts

pipeline()（NO BARRIER）
         A: s1 → A: s2 - done（fast items finish early）
         B: s1 (slow) → B: s2（idle gaps）
         DEFAULT TO PIPELINE. USE A BARRIER ONLY WHEN A STAGE NEEDS EVERY PRIOR RESULT AT ONCE

目标：明确两种并发范式——parallel()（强 Barrier）vs pipeline()（无 Barrier）。

关键动作：

• 默认用 pipeline：每个 item 独立流完，快的不等慢的；
• 仅当某 Stage 必须聚合所有前置结果时才用 parallel + Barrier。

核心产出：并发模式选择矩阵。

解读：parallel() + Barrier 听起来总没错，默认用它却会把快任务拖慢到慢任务的节奏。图 13 给的是相反的顺序：默认 pipeline，只有当某个 Stage 必须一次性拿到全部前置结果时才用 Barrier。这条纪律和 Step 8 的 Diamond 互为表里——Diamond 只在汇聚点强 Barrier，链路其余部分保持流水。

Step 12 · Observed Agent：可观测性解剖

[图 14]  Anatomy of an Observed Agent
         ┌─────────────────────────────────────┐
         │ Thought    Action                   │
         │ Prompt and memory ingestion         │
         │ Plan generation and scratchpad      │
         │ Feedback Loop                       │
         │                                     │
         │ Alignment    Reflection   Execution │
         │ Controls: guardrails and fallback   │
         │ Reflection logs (self-critiques)    │
         │ Tool execution traces (inputs/out)  │
         └─────────────────────────────────────┘

目标：把 Agent 内部画成可观测的"解剖图"——三大子系统（Alignment / Reflection / Execution）+ 两类日志（self-critique / tool traces）。

关键动作：

• Alignment（对齐）：guardrails + fallback 控制；
• Reflection（反思）：self-critique 日志；
• Execution（执行）：tool 输入输出 traces。

核心产出：Observed Agent schema + 三类日志存储。

解读：Step 12 把 Agent 从"黑盒"摊成可观测的解剖图：Alignment（guardrails + fallback）、Reflection（self-critique 日志）、Execution（工具输入输出 trace）三大子系统各留一条记录通道。图 14 一张图覆盖了整套运行时需要落盘的日志种类，直接指导 Step 5 的 Data-flow graph 该在哪埋探针。

落到运行时，一个 step 的 trace 长这样——三类记录各占一块，彼此用 agent_id + step 对齐：

{
  "agent_id": "search_1",
  "step": 4,
  "reflection": {"score": 0.6, "note": "结果未覆盖用户提到的 latest branch"},
  "tool_calls": [
    {"tool": "bash", "input": "grep -rn \"fetch(\" src/api/", "output": "12 matches", "latency_ms": 140}
  ],
  "guardrail": "passed"
}

Alignment 决定这条 trace 能否继续（guardrail 拦截就停），Reflection 给下一轮自己看，Execution 给排查的人看。三类记录合起来，才是 Step 5 里 Agent 内部那条数据流真正流过的痕迹。

Step 13 · Claude Code v2.0.51：模型路由

[图 15] Claude Code v2.0.51
         /release-notes for more
         What's new
         Added Opus 4.5! https://www.anthropic.com/news/claude-opus-4-5
         Introducing Claude Code for Desktop: https://claude.com/downloa

         /model 选择器：
         1. Default (recommended) → Opus 4.5
         2. Sonnet 4.5
         3. Sonnet (1M context) → Sonnet 4.5 with 1M context（Uses rate limits faster）
         4. Haiku 4.5（Fastest for quick answers）

目标：用 Claude Code 的 /model 路由不同任务到不同模型。

关键动作：

• 复杂任务 → Opus 4.5（最强）；
• 长上下文 → Sonnet 4.5 1M；
• 快速问答 → Haiku 4.5。

核心产出：模型路由矩阵（任务类型 → 模型选择）。

解读：Step 13 是 Step 9（Conditional Edge Router）的具体实现。Claude Code v2.0.51 的 /model 选择器就是 Router 节点。

Step 14 · Opus 4.8 ultracode：动态工作流

[图 16] Claude Code Opus 4.8
         ~/acme
         ~/acmedash/api/migration
         Dynamic workflow requested
         ultracode
         Create a workflow that migrates every internal fetch()
         call to the new HttpClient wrapper, updating tests as you go.
         auto mode on (shift+tab to cycle)

目标：在 Opus 4.8 上用 ultracode 跑"动态工作流"——一句话需求自动生成完整迁移流程。

关键动作：

• 输入自然语言目标（“把所有 fetch() 迁到 HttpClient wrapper，同步更新测试”）；
• Opus 4.8 自动构造 Graph（识别文件、生成迁移、跑测试、验证 diff）；
• auto mode 持续执行直到闭环。

核心产出：动态工作流 prompt 模板 + 自动闭环验证。

解读：到 Step 14，前面 13 步被装进一次 Agent 调用：输入一句话目标，Opus 4.8 自己构造 Graph——识别文件、生成迁移、跑测试、验证 diff，auto mode 下持续执行到闭环。这是图 17（终极组装图）的运行时版本：一个真正把"图即代码"跑起来的实例。

3 · 终极组装图：把 14 步缝合成一个 Graph

[图 17 · 终极组装图]
                    ┌──────────────────┐
                    │     SCOPE        │
                    │  Scope agent     │
                    └────────┬─────────┘
                             ↓
                    ┌──────────────────┐
                    │    FAN OUT       │
        ┌───────────┼───────────┬──────┴──────────┬───────────┐
        ↓           ↓           ↓                  ↓           ↓
   ┌─────────┐ ┌─────────┐ ┌─────────┐       ┌─────────┐ ┌─────────┐
   │ search 1│ │ search 2│ │ search 3│       │ search 4│ │ search 5│
   │  cheap  │ │  cheap  │ │  cheap  │       │  cheap  │ │  cheap  │
   │  tier   │ │  tier   │ │  tier   │       │  tier   │ │  tier   │
   └────┬────┘ └────┬────┘ └────┬────┘       └────┬────┘ └────┬────┘
        ↓           ↓           ↓                  ↓           ↓
   ┌─────────┐ ┌─────────┐ ┌─────────┐       ┌─────────┐ ┌─────────┐
   │  code   │ │  code   │ │  code   │       │  code   │ │  code   │
   │  8 tok  │ │  8 tok  │ │  8 tok  │       │  8 tok  │ │  8 tok  │
   └─────────┘ └─────────┘ └─────────┘       └─────────┘ └─────────┘
        ↓           ↓           ↓                  ↓           ↓
        └───────────┴─────┬─────┴──────────────────┴───────────┘
                          ↓
                 ┌──────────────────┐
                 │     REDUCE       │
                 │  Reduce agent    │
                 └────────┬─────────┘
                          ↓
                 ┌──────────────────┐
                 │     VERIFY       │
                 │  verifier gate   │
                 │  - 2x skeptic    │
                 └────────┬─────────┘
                          ↓
                 ┌──────────────────┐
                 │   SYNTHESIZE     │
                 │  Top model       │
                 │  (cited report)  │
                 └──────────────────┘

ONE GRAPH, EVERY PRINCIPLE: FAN-OUT ON A CHEAP TIER,
FREE REDUCE EDGE, A VERIFIER GATE, ONE TOP-TIER SYNTHESIS

阅读顺序：

1. SCOPE：Scope agent 先界定搜索边界；
2. FAN OUT：5 个 cheap-tier 节点并行搜索（cheap tier 是 Step 8 的 Diamond 扇出）；
3. REDUCE：Reduce agent 把 5 路结果聚合（Step 8 的 Barrier + Reduce）；
4. VERIFY：verifier gate + 2 个 skeptic（Step 7 的 Diverse-Lens Verify）；
5. SYNTHESIZE：top-tier 模型生成 cited report（Step 14 的 Opus 4.8 终态）。

@0xCodez 给了这张图最后一行字幕：

ONE GRAPH, EVERY PRINCIPLE: FAN-OUT ON A CHEAP TIER, FREE REDUCE EDGE, A VERIFIER GATE, ONE TOP-TIER SYNTHESIZE.

一句话翻译：一张图覆盖所有原则——用便宜层级扇出，免费汇聚边，验证器把关，最强模型做合成。

4 · 推主核心方法论 5 条

把 14 步压缩成 5 条可立即上手的工程原则：

1. 图即编程语言（Step 1）——LINEAR 等 4x time，GRAPH 等独立节点。代码层面优先用图取代链。
2. 依赖即图（Step 2）——Anchor node 是被最多次穿越的节点，是 fan-out / fan-in 双高的枢纽。
3. 契约即黄金（Step 3）——Mock / Provider / Consumer 三方共享 Schema(golden)，图节点必须可验证。
4. 团队即图（Step 4-7）——Subagent / Agent Team / Data-flow graph / Fan-out / Conditional Edge / Observed Agent 都是同一件事的不同视角：Agent 协作本质是有向图。
5. 验证即多元视角（Step 7）——Skeptic 投票 2/3 通过，多视角质疑是 Agent 工程的标配质量门。

5 · 写在最后：图即编程语言

10 年前学图数据库，重点是"怎么用 Cypher 查图"。现在学 Graph Engineering，重点是"怎么把系统本身画成图"。

@0xCodez 的 14 步路线图，本质是 Claude Code 时代的一次范式声明：

不要让你的代码"等着前面跑完"。把你的代码画成图，让独立节点并行扇出，让汇聚点强 Barrier，让验证器多视角质疑，让最强模型做终态合成。

成本账

图不是免费的。把 Linear 改成 Graph，会付出三类成本：

• 调度成本——fan-out 节点越多，Reduce 阶段越重；5 路搜索是 sweet spot，超过 10 路 Reduce 边际收益骤降。
• 可观测性成本——图越大 trace 越多，每条边的延迟、错误率、重试次数都要可观测；Step 12（Observed Agent）就是为这条成本准备的可观测骨架。
• 纪律成本——图结构一旦散乱，重构代价远高于一段线性代码；Step 3（Schema 即黄金）和 Step 11（默认 Pipeline 而非 Barrier）是防止散乱的纪律。

可观测性

14 步图里，有且只有两个强 Barrier：Step 8（fan-out 汇聚点）和 Step 11 的 parallel()（强制等齐）。其余地方都是异步消息或 condition edge。这意味着 trace 系统必须能区分「慢在哪一步」和「卡在哪个 Barrier」——LangSmith / Langfuse 这类工具的 Span Tree 就是为此而生。

失败模式

图架构最常见的失败是级联回退：一个 fan-out 节点失败 → Barrier 等不到 → 整个 Reduce 拿到半成品 → 强 Skeptic 投票拒绝 → 全部重试 → 雪崩。

三条救命绳：

1. Step 9 的 Conditional Edge——把高失败率任务路由到「重试预算耗尽则降级」分支，不让单点拖垮整张图。
2. Step 7 的 2/3 Skeptic——验证门而不是终点，少数派失败不阻塞流程。
3. Step 11 的 pipeline()——默认异步流而非强同步 Barrier，是抗雪崩的第一道防线。

从 17 张图能带走的是这套顺序：14 步排好节奏，5 条原则随时自查，1 张终极组装图兜底。成本记在前面，失败模式记在动手前，剩下的就是按 14 步往下走——至少不会在第一步把四条线等成 4x。

6 · 读者判断：谁该去看原推，谁读本文就够

读本文就够的：

• 想快速掌握"Graph Engineering" 14 步框架，并把它映射到 Claude Code / Subagent / LangGraph 上的人
• 已经在跑 Agent 任务、想给 Agent 团队加上"并行 + 验证 + 路由"结构的人
• 想为"Agent 为什么要按图建模"找一个完整论证的人

应该去看原推的：

• 想看 17 张原图细节的——本文的代码块是文字还原，丢掉了原图的配色、版式和排版层次
• 想核对本文订正处（图 1 的 “9 14 STEPS”）或自己再跑一遍 OCR 的
• 想跟随 @0xCodez 后续更新（路线图的后续版本）的

只读本文还不够的：

• Anthropic Boris Cherny 的 Graph Engineering 系列——@0xCodez 路线图的方法论源头（见附录 B）
• Claude Code 官方文档与 /model 路由的实际行为——Step 13 引用的版本号会随发布变化

7 · 常见问题（FAQ）

Q1：这套 14 步路线图和 LangGraph 是什么关系？ LangGraph 是落地运行框架之一：它的 StateGraph 天然支持"多入边 Barrier"“条件边"“节点化”，Step 8 / Step 9 的抽象可以直接映射（正文 Step 8 附了对应代码）。路线图本身与具体框架无关，Claude Code 的 Subagent、git worktree 是另一类落点。

Q2：一定要用图数据库吗？Neo4j 在 14 步里占多大比重？ 只有 Step 2 的 Anchor 查找用到 Cypher，而且只是为了度量节点的穿越频次。14 步的"图"主要是建模意义上的（节点 / 边 / 依赖），数据库只是其中一种载体。不熟 Neo4j 也可以先按 Step 1 用白板或现有代码结构把其余步骤走完。

Q3：Step 8 说"5 路搜索是 sweet spot，超过 10 路 Reduce 边际收益骤降”，依据是什么？ 这是正文"成本账"里的工程判断，不是可复现的 benchmark 结论：fan-out 规模越大，Reduce 要聚合、对齐、去重的输入越多，多路结果的增量价值递减，同时 Barrier 等待的方差变大。属于经验性指导线。

Q4：Step 13 / Step 14 的版本号（Claude Code v2.0.51）和模型名（Opus 4.5 / Opus 4.8 ultracode）现在还对吗？ 它们来自原推 17 张图的 OCR，是对 @0xCodez 成稿时点的忠实还原。Claude Code 与 Anthropic 模型更新频繁，动手前以官方 release notes 为准（附录 B 已列 Claude Opus 4.5 发布说明链接）。

Q5：能直接照抄这套路线图到自己的项目吗？ 建议先按顺序做 Step 1-3 的"诊断 + 契约"：画出真实依赖、选出 Anchor、给关键节点补契约测试。跳过这三步直接上 Step 4 的 Subagent 拓扑，容易把并行复杂度堆在没有验证基线的代码上。

附录 A · OCR 校对与原图出处

OCR 校对工具：macOS Vision.framework（VNRecognizeTextRequest，recognitionLevel=.accurate），单脚本批量跑全部 17 张图。 HTML 备份：/Users/damon/.openclaw/workspace/state/reverse-write/x-0xcodez-2079165300625330317/tweet.html OCR 全文：/Users/damon/.openclaw/workspace/state/reverse-write/x-0xcodez-2079165300625330317/ocr_all.txt 17 张原图：/Users/damon/.openclaw/workspace/state/reverse-write/x-0xcodez-2079165300625330317/images/

附录 B · 引用与延伸阅读

• 原推文：https://x.com/0xCodez/status/2079165300625330317
• Anthropic Claude Code：https://claude.com/download
• Claude Opus 4.5 发布说明：https://www.anthropic.com/news/claude-opus-4-5
• 关联阅读：Anthropic Boris Cherny「Graph Engineering」系列（@0xCodez 路线图的方法论源头）

版权：本文为翻译 + 深度解读，原图与推文版权归 @0xCodez 所有。