Graph Engineering 深度学习文档
基于 Ajay 的 X 传播内容，结合 Anthropic 官方 Loop Engineering / Dynamic Workflows / Claude Code 文档、LangGraph，以及 2026 年 Graph Engineering 与结构化调度相关研究，对原始观点做事实核验、概念澄清和工程化重构。
Agentic Coding
System Intelligence
Graph Engineering
Loop Engineering
Harness Engineering
Verification
01
先记住 7 个核心结论
一句话：Graph Engineering 的真正价值，不是“多开几个 Agent”，而是把原本隐藏在一个大模型上下文里的任务依赖、并发关系、状态、验证门、失败恢复、预算和权限显式化，让概率型智能运行在可检查的工程骨架上。
- “Prompting 已结束”是错误理解。Prompt 仍存在于节点内部，只是不再承担整个系统架构的职责。
- Loop 没有被 Graph 淘汰。Loop 管“一个执行单元如何持续做到完成”；Graph 管“多个执行单元如何协作”。
- Graph 不等于 Multi-Agent。Node 可以是 Agent，也可以是普通函数、测试、审批、数据库写入或队列任务。
- Graph 不等于 Knowledge Graph。当前语境主要讨论的是 Agentic Execution / Workflow Graph。
- 可靠性不来自 Agent 数量。真正的可靠性主要来自 Contract、State、Verifier、Test、Permission、Retry 与 Observability。
- Graph 的性能优势来自调度。删除假依赖、并行独立工作、减少 Barrier，才能降低墙钟时间。
- 成熟系统通常是混合架构。确定性代码负责控制面，LLM 负责高不确定语义工作，验证系统负责证据闭环。
02
原文主张与事实边界
Ajay 传播内容真正值得保留的部分
这条内容的核心方向是：Agent 系统正在从“一个强 Prompt + 一个长上下文 + 一个 Agent 自己想办法”向“显式任务图 + 多执行单元 + 独立验证 + 状态管理”演进。这个技术方向是成立的，而且与 Anthropic 的 Dynamic Workflows、并行 Subagents、Loop Engineering，以及 2026 年 Graph Engineering 研究形成呼应。
| 传播说法 | 判断 | 更准确的学习结论 |
|---|---|---|
| “90% Anthropic 工程师已经从 loops 转向 graphs” | 缺少可靠一手证据 | 不要学习数字，学习“显式编排”这一架构迁移。 |
| “No more prompting” | 夸张 | 节点内部仍需要 Prompt / Context；只是控制权上移到 Harness / Loop / Graph。 |
| Graph Engineering 是替代 Loop Engineering 的新范式 | 错误二分 | Loop 与 Graph 是不同维度：循环负责持续执行，图负责组织执行关系。 |
| Graph 是值得学习的架构方向 | 成立 | 官方产品能力与研究都在强化并行、显式状态、验证、调度和协同。 |
反思：社交媒体最容易把“架构能力上移”讲成“旧技术死亡”。真正的工程演进通常是叠加：Prompt → Context → Harness → Loop → Graph，每一层仍然存在，只是职责重新分配。
03
时间线本身就能说明：Graph 不是 Loop 的替代品
2026-04
结构化 Graph 调度研究出现。研究开始从 scheduler / DAG / explicit dependency 的角度重新描述 Agent 执行。2026-05-28
Anthropic 发布 Opus 4.8 与 Dynamic Workflows。Claude Code 可规划大型任务、运行大量并行 subagents，并在返回前验证结果。2026-06-30
Anthropic 官方仍正式发布 Loop Engineering 指南。把 loop 定义为 Agent 重复工作直到满足停止条件，并介绍 turn / goal / time / proactive loops。2026-08-21
《Graph Engineering in the Era of LLM Agents》发布。把 Prompt / Context 视为 Model Intelligence，把 Harness / Loop 视为 Individual Intelligence，再把 Graph 提升为 System Intelligence 的组织结构。关键推论：如果 Anthropic 在 Dynamic Workflows 之后仍正式教授 Loop Engineering，那么更合理的模型就是“Graph 作为上层编排，Loop 作为节点内部或局部控制结构”，而不是谁淘汰谁。
04
五层工程栈：每一层到底在控制什么
Graph Engineering · 整个工作 / 系统级协调
└─ Loop Engineering · 一个执行单元如何持续直到完成
└─ Harness Engineering · 模型周围有哪些工具、状态、权限、检查
└─ Context Engineering · 当前这一步给模型看什么
└─ Prompt Engineering · 当前这次调用如何表达任务
| 层 | 主要问题 | 工作单位 | 典型失败 |
|---|---|---|---|
| Prompt | 怎么说 | 一次模型调用 | 指令含糊、输出格式不稳定 |
| Context | 给模型看什么 | 当前上下文窗口 | 信息缺失、污染、Lost in the Middle |
| Harness | 模型如何行动 | 一次 agent pass | 工具设计差、权限过大、无验证 |
| Loop | 什么时候继续/停止 | 完整自主执行过程 | 早停、死循环、无预算、假完成 |
| Graph | 谁先做、谁并行、谁验证谁 | 整个任务系统 | 假依赖、状态冲突、失败扩散、同步过多 |
调试原则
先判断“坏掉的是哪一个工作单位”。资料不对修 Context；工具执行危险修 Harness；Agent 不停或太早停修 Loop；多个步骤互相等待、覆盖、重复、传播错误，才是 Graph 问题。不要遇到任何失败都回去改 Prompt。
05
三种 Graph 不要混淆
| 类型 | Node | Edge | 用途 |
|---|---|---|---|
| Execution / Workflow Graph | 任务、Agent、函数、审批、测试 | 依赖、路由、同步、条件 | 组织“工作如何发生” |
| Knowledge / Memory Graph | 实体、事件、文档、决策 | 关系、时间关系、因果/依赖 | 组织“系统知道什么” |
| Reasoning / Thought Graph | 候选思路、推理状态 | 扩展、合并、评价 | 组织“模型如何搜索解空间” |
本学习文档重点：Execution / Workflow Graph。知识图谱和 GraphRAG 很重要，但它们不是这条传播内容里的主问题。
06
Graph Engineering 的工程定义
一个生产级 Agent Graph 至少包含 6 个一等公民
- Node：有边界的工作单元。可以是 Agent，也可以是确定性函数。
- State：系统当前事实快照，不应该只存在聊天历史里。
- Edge / Transition：定义数据如何流、控制如何转移、何时等待。
- Scheduler：哪些节点现在 ready，哪些可以并发，哪些必须等待。
- Gate：是否允许结果继续向下游传播。
- Recovery Policy：失败后重试、回退、重新规划、人工升级还是终止。
Goal
├─ Planner / Decomposer
├─ Explicit State Store
├─ Scheduler
│ ├─ ready-set
│ ├─ parallelism
│ └─ barriers / routing
├─ Worker Nodes
│ ├─ deterministic functions
│ └─ LLM / subagents
├─ Verification Gates
└─ Recovery / Human Escalation
07
Edge 的正确理解：不只是“数据流”
更准确的说法：“下一步是否真正依赖上一步”是极好的删边检查，但生产系统的 Edge 也可能承载控制、安全、资源或同步约束。
| Edge 类型 | 为什么存在 | 例子 |
|---|---|---|
| Data Dependency | B 消费 A 的输出 | Research → Writer |
| Control Dependency | 业务规则要求顺序 | Create Order → Charge |
| Safety Dependency | 动作前必须过门 | Draft SQL → Human Approval → Execute |
| Resource Dependency | 共享资源不能并发修改 | 两个迁移任务争用同一数据库 schema |
| Conditional Transition | 根据状态选择路径 | risk=high → security verifier |
| Barrier / Join | 必须等一组上游完成 | 多个 reviewer → synthesis |
Fake-Edge Test 的生产版
对每一条边问：如果删掉这条边，数据正确性、业务顺序、安全约束、资源一致性或同步语义会不会被破坏？如果答案全部是否定的，这条边大概率只是“我们习惯按这个顺序做”，可以删除或并行。
08
三平面架构：Control / Intelligence / Evidence
Control Plane · 确定性控制面
├─ scheduler / routing / state machine
├─ retry / timeout / budget / permissions
└─ checkpoint / idempotency / concurrency control
Intelligence Plane · 概率型智能面
├─ planning / classification / synthesis
├─ coding / research / semantic judgment
└─ dynamic decomposition
Evidence Plane · 证据面
├─ tests / type checks / schema validation
├─ verifier agents / adversarial checks
└─ logs / traces / human approval
设计原则：能由 Control Plane 确定的事情，不要交给 LLM 猜；能由 Evidence Plane 自动证明的事情，不要只让 LLM “感觉已经完成”。
09
六种必须掌握的 Graph 拓扑
| 拓扑 | 形状 | 适用场景 | 主要风险 |
|---|---|---|---|
| Linear | A → B → C | 真实强依赖流程 | 无意义串行、单点阻塞 |
| Fan-out | A → {B,C,D} | 多文件、多数据源、多视角 | 限流、成本瞬时上升 |
| Fan-in / Barrier | {B,C,D} → E | 汇总、决策、最终生成 | 被最慢节点拖住 |
| Diamond | Split → Parallel → Merge | Research / Audit / Code Review | 重复结果、冲突合并 |
| Router | A → if → B/C/D | 风险分级、任务分类、模型路由 | 路由判断错造成路径错误 |
| Cycle | A → B → A | 自修复、迭代优化、开放式探索 | 不收敛、成本失控 |
推荐演进顺序
先从 Linear → 删除假边 → Fan-out/Fan-in → Router → Verifier Gate 做起。只有当任务规模确实无法预先确定时，再引入 Cycle 或动态自规划 Graph。
10
Loop 与 Graph：不是二选一
| 维度 | Loop | Graph |
|---|---|---|
| 核心问题 | 这个工作单元什么时候算完成？ | 哪些工作单元现在应该运行？ |
| 主要结构 | 反馈回边 + stop condition | 节点 + 边 + state + scheduler |
| 常见边界 | 单 Agent / 单目标 | 跨任务 / 跨 Agent / 跨系统 |
| 主要风险 | 死循环、假完成 | 状态冲突、错误传播、图过度复杂 |
| 关系 | 可以运行在节点内部 | 可以协调多个内部含 Loop 的节点 |
“一个 Loop 是一节点自环 Graph”可以作为心智模型，但不要当成严格运行时等价。真实系统里两者的 scheduler、state、checkpoint 和 recovery 语义可能完全不同。
11
调度器视角：理解 Graph Engineering 最关键的升级
把 Agent 执行重新看成经典调度问题
单 Agent Loop 往往像“同一时刻只有一个 ready work unit 的调度器”；显式 Graph 则维护一个 ready set，同时启动所有依赖已经满足的节点。
Ready(v) =
node[v].status == READY
AND all required predecessors are satisfied
AND resource locks are available
AND safety gates allow execution
Scheduler:
ready_set = { v | Ready(v) }
run independent nodes in parallel
persist state transition
verify outputs
unlock downstream nodes
这带来三个工程收益
- 可解释：为什么节点此刻能运行，可以由显式条件回答。
- 可重放：计划、状态和结果分开保存，可以复现失败路径。
- 可约束：重试次数、恢复层级、资源上限可以写成系统规则，而不是自然语言期望。
12
Verification Engineering：Graph 真正提高可靠性的地方
验证优先级
- Deterministic：Schema、单测、集成测试、lint、type check、静态规则。
- Independent Semantic Verifier：让独立 Agent 寻找反例、漏洞、证据缺口，而不是复述主 Agent。
- Human Gate：生产发布、资金、删除、权限、敏感数据等高风险副作用。
Verifier 应该是“证明任务”，不是“意见任务”
不要问：“你觉得这个结果好吗？” 应该问：“运行测试；找一个能使结论失败的反例；检查每条结论是否有来源；检查变更是否越过权限边界；如果失败，返回具体失败证据。”
Graph 的关键价值：把验证从 Prompt 末尾的一句话，升级为真正能阻断状态迁移的 Gate。
13
Claude Code 中如何映射 Graph Engineering
| Graph 概念 | Claude Code / Agent SDK 能力 | 用途 |
|---|---|---|
| Node | Subagent / Agent | 独立上下文、专用 Prompt、工具和模型 |
| Parallel Work | Parallel agents / Dynamic Workflows | 并行扫描、迁移、研究、实现 |
| Isolation | Worktree isolation | 并行改代码避免互踩 |
| Gate | PreToolUse / Stop / SubagentStop 等 hooks | 阻止危险动作、阻止未完成节点结束 |
| Evidence | PostToolUse / logs / test suite | 记录工具执行和结果 |
| Cost Tiering | Subagent model selection | 探索类任务使用不同模型档位 |
重要：Subagent 的独立 Context 本身就是 Graph 化拆分的重要收益：搜索结果、日志和局部文件不会持续污染主 Agent 的上下文。
14
LangGraph：把 Graph 变成可运行的 State Machine
最重要的不是 API，而是状态边界
State 是共享事实；Nodes 读取当前 State、执行逻辑并返回局部更新；Edges 决定下一个节点。Node 可以包含 LLM，也可以只是普通代码。
from typing import TypedDict
from langgraph.graph import StateGraph, START, END
class ReviewState(TypedDict):
diff: str
scope: dict
correctness: dict
security: dict
performance: dict
merged: dict
verified: bool
g = StateGraph(ReviewState)
# scope 完成后 fan-out
g.add_edge(START, "scope")
g.add_edge("scope", "correctness")
g.add_edge("scope", "security")
g.add_edge("scope", "performance")
# 三个 reviewer 全完成再 merge
g.add_edge(
["correctness", "security", "performance"],
"merge"
)
g.add_edge("merge", "verify")
g.add_edge("verify", END)
判断标准：如果系统仍把所有信息塞在一个
messages 数组里，没有明确字段、ownership、checkpoint、error state 和 reducer，那么只是“画成图的聊天程序”。15
实战：把“Review 一个 PR”改造成可验证 Graph
PR Review Graph
├─ 01 Scope：读取 diff / 识别受影响模块
├─ 02 Fan-out
│ ├─ Correctness Reviewer
│ ├─ Security Reviewer
│ └─ Performance Reviewer
├─ 03 Deterministic Checks
│ ├─ tests
│ ├─ lint / typecheck
│ └─ dependency / secret scan
├─ 04 Merge：去重 + 冲突合并
├─ 05 Evidence Gate
│ ├─ 高危问题必须带 file/line/evidence
│ └─ 无法复现的问题降级为 suggestion
└─ 06 Final Summary / Human Merge Decision
为什么这比一个“大 Reviewer Prompt”更稳
- 多个视角使用独立 Context，降低同一路径导致的相关性错误。
- 测试和静态检查不浪费模型判断预算。
- 高风险问题必须有证据才能通过 Gate，减少“看起来像问题”的幻觉。
- 某个 Reviewer 超时可以局部降级，不必让整次审查失败。
- 可以记录每个 Node 的 latency、token、失败率，为后续优化提供数据。
16
成本与性能：Graph Topology 也是经济模型
Critical Path决定理想墙钟时间
Barrier Count决定被慢节点拖住几次
Retry × Model Tier决定 token 成本放大倍数
串行近似：
Latency ≈ t1 + t2 + ... + tn
DAG 近似：
Latency ≈ max(每条依赖路径的 Σ node_time)
+ scheduling / join overhead
总成本近似：
Cost ≈ Σ(node model cost)
+ verifier cost
+ retry cost
+ orchestration overhead
三个常见优化
- 删除假边：通常是最便宜、收益最大的并行化。
- 减少 Barrier：只有真正需要全量结果时才等待最慢 Worker。
- Model Tiering：分类/抽取/格式化先用代码或便宜模型，复杂综合和裁决再用强模型。
17
最常见的 10 个误区
- 把 Graph 理解成“Agent 越多越先进”。
- 把所有 Node 都做成 LLM。本可用代码完成的工作不要模型化。
- 只有消息，没有显式 State。
- 所有步骤都顺序连接。最后只是一个画成图的脚本。
- 并行写同一工作区。缺少 worktree / 锁 / ownership。
- Verifier 与 Builder 用同一上下文、同一目标。相关性错误仍然很高。
- Cycle 没有 max turns / budget / progress metric。
- LLM 自己判断“测试通过了”。应该真的执行测试。
- Graph 生成后任意自我改写。无法审计、无法复现。
- 为了 Graph 而 Graph。单一、短、强依赖任务用简单 Loop/Workflow 更好。
18
7 天学习路径：从会用 Agent 到会设计 Graph
Day 1 · State
只学 State Contract。把一个真实任务从“聊天历史”重构成 Typed State：输入、阶段结果、错误、证据、预算、完成状态。Day 2 · Edges
画出真实依赖图。对每条边执行生产版 Fake-Edge Test，删除纯习惯顺序。Day 3 · Parallelism
实现 Fan-out / Fan-in。记录串行与并行的 latency / token / failure 差异。Day 4 · Gates
加入测试、Schema 和 Verifier。确保失败结果无法自动进入下游。Day 5 · Recovery
加入 timeout / retry / fallback / escalation。要求节点失败不会让整张图失控。Day 6 · Framework
用 LangGraph 或已有 Agent Runtime 实现同一套 Graph。重点比较 state、checkpoint、conditional edge、并行语义。Day 7 · Production
做一个真实 PR Review / Research / Migration Graph。必须带 trace、成本、失败注入和人工 Gate。完成标准：不是“能画出 Graph”，而是你能解释每个 Node 为什么存在、每条 Edge 为什么不能删、失败后去哪、如何证明完成、花了多少钱。
19
Graph Engineering 能力检查表
| 能力 | 入门 | 可生产化 |
|---|---|---|
| Task Decomposition | 能拆步骤 | 能拆成有清晰输入输出和 ownership 的节点 |
| State Design | 共享 messages | Typed State + checkpoint + reducer + error state |
| Dependency | 按自然语言顺序连边 | 区分 data/control/safety/resource dependency |
| Parallelism | 会并发调用 | 会算 critical path、barrier、限流和写冲突 |
| Verification | 让模型“再检查一下” | 测试优先 + 独立 verifier + evidence gate |
| Recovery | 失败就重试 | retry → fallback → replan → human escalation |
| Security | Agent 全权限 | 按 Node 最小权限 + 高危动作 Gate |
| Observability | 看最终结果 | Node trace / latency / token / retry / failure attribution |
| Economics | 全用最强模型 | 确定性代码 + model tiering + budget policy |
| Architecture Judgment | 什么都做 Graph | 知道什么时候一个简单 Loop 就够了 |
20
资料索引与推荐阅读顺序
A. 用户提供的传播入口
B. Anthropic 官方
C. Graph / 调度研究
推荐顺序：先读 Anthropic Loop + Dynamic Workflows → 再读 LangGraph Graph API → 再读结构化调度论文 → 最后读 Graph Engineering 的 System Intelligence 总体框架。这样最不容易被“新名词替代旧名词”的叙事带偏。
页面格式严格遵循《html_UI 设计规范.md》：240px 固定侧边栏、900px 内容区、白底/米白背景、蓝紫单一强调色、Card / Callout / Chip / Hierarchy / Timeline / 对比表格 / IntersectionObserver。