图 1：本文关注 Agent 控制图和反馈治理图。知识图谱与 GraphRAG 也使用图，但解决的是不同问题。
第一次阅读可以先看哪里
-
只想弄清概念：读第 1-4 节。 -
正在设计多 Agent 工作流：读第 5-9 节。 -
想马上动手：直接读第 10 节并下载实验包。 -
正在做框架选型：读第 11-12 节。 -
准备评审现有系统：保存第 13-14 节的画布和检查表。
1. Graph Engineering 到底是什么
截至 2026-07-24，还没有一个行业标准组织为 Graph Engineering 给出正式定义。社区中的说法也并不完全相同。
Carlos E. Perez 更强调“循环之间的治理”：一个改进循环可能追逐局部指标，另一个审计循环负责发现它正在优化错误目标，还需要目标所有者和现实锚点解决冲突。
Machina 把概念落到了工作流设计：节点、依赖边、共享状态、Diamond Pattern、验证器、人工闸门、轮次上限和写入权。
codila 则重点讨论动态工作流、真假依赖、独立 verifier、并行 worker 的工作区隔离，以及什么时候根本不该使用 Graph。
把三种视角与现有框架放在一起，我在本文中采用下面这个工作定义：
Graph Engineering 是把一项 Agent 工作设计成可执行图的工程实践：明确节点职责、真实依赖、共享状态、路由规则、验证锚点、资源边界、人工权限和运行记录。
这个定义里有三个关键词。
第一，可执行。 一张画在白板上的流程图不算完成。它至少要能回答哪些节点已经满足依赖、哪个节点可以运行、失败后走哪条路径。
第二，工程。 重点不在节点数量，而在契约、测试、预算、故障恢复和可观测性。
第三，Agent 工作。 节点不必都是 Agent。普通函数、静态分析、数据库查询、测试命令和人工审批往往比再加一个 Agent 更可靠。
所以，Graph Engineering 不是：
-
看到复杂任务就拆成十个角色； -
给多个 Prompt 画几条箭头； -
让一个模型同时充当作者、裁判和批准人； -
用“多 Agent”替代测试、权限和业务规则； -
证明某个框架一定优于另一个框架。
它更像是在问：哪些决定应该继续交给模型推理，哪些决定应该固化为代码和结构？
2. 先分清四种 Graph
“Graph + AI”至少有四个常见语境。
这四类图可以组合。
例如，一个研究 Agent 可以在控制图的某个节点里调用 GraphRAG；GraphRAG 又从知识图谱取回资料；控制图之外还有审计循环检查引用和事实。但组合不等于概念相同。
如果文章不先做这层消歧，读者会遇到一个很实际的问题：搜索“Graph Engineering”时找到的资料，一半在讲知识图谱，一半在讲多 Agent 编排，最后把完全不同的设计原则混在一起。
本文后面出现的 Graph，默认指 Agent 工作图。
3. 一张可用工作图的六个部件
LangGraph 的官方 Graph API 文档把核心抽象为 State + Nodes + Edges：节点读取状态并返回更新，边决定下一步执行谁。这个基础模型很重要，但要把实验图带进真实工作，还需要补上权限和证据。
我会用六个部件检查一张工作图：
这里最容易被忽略的是 Anchor。
如果三个 Agent 都基于同一份错误资料，它们可以非常一致地给出错误结论。再增加一个“评审 Agent”，不一定能产生新证据。现实锚点必须触碰系统外部：
-
软件任务中的测试、类型检查、运行日志和真实页面； -
研究任务中的原始文档、固定版本、可复现实验和冲突来源； -
金融任务中的交易记录、公开报表、时间锚点和风险限制； -
业务任务中的规则版本、人工签字和真实结果指标。
Agent 共识不是 Anchor。
4. Graph 并不替代 Loop
图 2：复杂度不是从 Prompt 一步跳到 Graph。Graph 往往把多个实现、验证和恢复 Loop 放进显式依赖与统一预算中。
一个典型 Agent Loop 是：
它的优势是简单、灵活、上下文连续。对一个范围明确的 bug、一次代码解释或一篇短文修订，一个 Agent Loop 通常更合适。
Graph 解决的是另一个层级的问题：
所以更准确的关系是：
可以用下面的升级顺序判断复杂度：
这里没有“越往右越先进”。每升一级，都会增加状态管理、协调、成本和调试负担。
5. Edge：先删除假边，再谈并行
Graph 最有价值、也最容易被随便画出来的部分是 Edge。
一种常见做法是把原来的清单直接连成直线：
但“先后发生”不等于“存在依赖”。
判断一条边是否真实，可以问：
下游节点具体消费了上游节点的哪个输出？如果删掉上游结果，下游是否仍能得到相同输入并独立运行？
在这个例子里，论文搜索不需要等待官方文档搜索，X 搜索也不需要等待论文。三者都只依赖同一个研究计划，应该并行：
反过来，“合并”必须等待三个结果，因为它确实消费三份输出。这才是真边。
把边写成状态合同
实验包中的一个节点长这样：
这四个字段分别说明：
dependsOn
：调度层面必须先成功的节点； inputKeys
：当前节点实际读取的状态； outputKey
：当前节点唯一负责写入的状态； handler
：执行者，可以替换为 Agent、函数或外部服务。
Graph Lab 会检查：
-
依赖节点必须存在； -
图中不能有循环依赖； -
每条依赖边的上游输出必须出现在下游 inputKeys中； -
每个状态 key 只能有一个 writer； -
节点不能读取初始状态和直接依赖之外的 key。
第三条只是“假边候选”检查，不能证明语义一定正确，但它会迫使设计者说清楚这条边到底搬运了什么。
状态比聊天记录更重要
当多个 Agent 全部依赖同一个长会话时，会产生几个问题：
-
任何节点都能意外修改其他节点依赖的事实； -
验证器会继承作者的推理轨迹和偏见； -
重跑一个节点时，很难恢复它当时看到的输入； -
失败后无法判断是模型、输入还是路由出了问题。
比“共享所有上下文”更稳妥的方式是：
LangGraph 的文档专门提醒了重执行与幂等性：节点在中断或重试后可能从头运行，所以数据库写入、外部请求和文件修改需要幂等 key、upsert 或读取后再写等保护。
这也是 Graph Engineering 与“画流程图”的差别：边不只是箭头，它是一份数据和副作用合同。
6. Diamond Pattern：并行不是重点，独立验证才是
图 3：Plan 拆出三个真正独立的 worker，Verifier 使用新上下文核对结果，合并节点只接收已通过的证据，不可逆动作停在 Human Gate。该模式参考了 Machina 的社区教程，并按本文案例重新设计。
Diamond Pattern 是理解 Graph Engineering 最直观的结构：
它至少包含五个角色：
Plan
：定义问题、拆分维度和完成标准； Worker
：在隔离上下文中处理互不依赖的子任务； Verifier
：按固定 rubric 检查输出，而不是继续写作； Merge
：只合并满足合同的结果； Human Gate
：决定是否执行高影响动作。
什么叫“独立 Verifier”
给同一个 Agent 补一句“请仔细检查”不够。一个有意义的 verifier 至少要独立三个方面：
必要时还要分离权限。验证节点可以判定 pass / fail，但不能自己把失败改成通过；实现节点可以修改候选文件，但不能写入发布分支。
Anthropic 在动态工作流的工程说明中，也把独立上下文用于减轻目标漂移和自我偏好，并给出了 fan-out-and-synthesize、adversarial verification、generate-and-filter 等模式。这里值得借鉴的是结构，不是盲目扩大并发规模。
验证失败后不要整图重跑
图的另一个价值是定向恢复：
如果任何失败都回到起点，Graph 只是把一个大循环画得更复杂，并没有改善恢复能力。
7. 静态图、动态图和混合图怎么选
Graph 并不要求所有边都提前写死，也不意味着应该让模型决定所有路由。
OpenAI Agents SDK 的官方文档把编排分成两类：
- LLM 编排
：模型根据当前任务规划、调用 specialist 或 handoff； - 代码编排
：程序决定顺序、并行、条件和循环，速度、成本与性能更可预测。
两者可以混合。
我更推荐混合模式：
Claude Code 的 Dynamic Workflows 是动态图的一个当前例子：Claude 可以根据任务生成 JavaScript 编排脚本，组合分类、并行、对抗验证、筛选和循环等模式。官方同时明确提醒，这类工作流会比普通会话消耗更多 usage，应从范围明确的任务开始。
OpenAI Symphony 则展示了另一层图：项目管理器充当控制面，issue 状态和依赖形成 DAG，每个 issue 对应隔离 workspace 和 Agent，结果最终交给人审查。它更接近长时间运行的工程调度参考，不是用来替代普通 Codex 会话的通用图 SDK。OpenAI 明确表示不计划把 Symphony 作为独立产品维护，应把它视为规范和参考实现。
8. 控制面：让图在错误时停下来
图 4：执行图周围还需要状态合同、预算、隔离、人工闸门、现实锚点和 Trace。缺少这些控制，节点越多，错误通常传播得越快。
一张图“能跑”与“值得托付”之间，差的是控制面。
8.1 给资源设硬上限
至少记录并限制：
maxConcurrency
：同时运行多少节点； maxNodes / maxRounds
：一次运行最多执行多少工作单元； maxDuration
：总墙钟时间； nodeTimeout
：单节点最长时间； -
Token 或费用预算； -
重试次数、退避策略和允许重试的错误类型。
不要把停止条件写成“直到结果足够好”。要把“足够好”变成可计算或可人工判断的合同。
8.2 并行写入必须隔离
多个 Agent 同时修改同一文件，很快会把并行收益变成冲突处理。
常见办法包括：
-
一个节点只拥有一个输出 key 或一组明确文件； -
每个 coding worker 使用独立 worktree / workspace； -
合并由专门节点完成； -
合并前运行测试和 diff 检查； -
冲突不是“自动选一个”，而是明确失败状态。
Symphony 的参考设计为每个 issue 创建隔离 workspace；Anthropic 的动态工作流案例也建议大规模修改时使用独立工作区。具体工具可以变化，原则不变：并行执行必须有写入所有权。
8.3 不可逆边由代码掌权
以下动作不应只靠 Prompt 中的一句“执行前请确认”：
-
merge 到保护分支； -
部署生产环境； -
对外发布内容或发送消息； -
删除、覆盖或迁移关键数据； -
创建付费资源或执行支付； -
修改访问权限和安全策略。
正确做法是让图停在 awaiting_approval，保存当前状态和证据，由外部批准事件恢复。
8.4 Trace 要能回答“为什么走到这里”
至少为每次运行记录：
只记录最终答案，不叫可观测性。Graph 的优势之一就是能把失败定位到具体节点、边或状态版本。
Trace 也不能变成新的泄密入口。生产实现应默认：
-
不记录 API Key、Cookie、访问令牌和完整认证头； -
对用户数据、内部文档和模型输入做字段级脱敏； -
区分调试日志与长期审计记录； -
为 Trace 设置访问权限、留存期限和删除机制； -
记录证据引用或内容哈希，而不是无差别复制全部原文。
9. 元案例：用 Graph 调研 Graph Engineering
这篇文章本身就可以被设计成一张工作图。
图 5：官方资料、研究论文和社区信号并行进入 Evidence Ledger，再由独立核验节点处理冲突。X 用于发现术语和案例，不直接证明产品能力。
9.1 输入不是“帮我搜一下”
图的入口是一份研究合同：
如果没有这份合同，三个 worker 只会更快地产出三份方向不同的摘要。
9.2 三个 worker 的职责不同
每个节点输出同样的最小证据结构：
9.3 Verifier 检查的是 Claim，不是文风
核验节点逐条询问：
-
来源是否直接支持这句话？ -
这是官方事实、研究结果、社区观察还是作者判断？ -
日期、版本和任务范围是否保留？ -
有没有更强来源与它冲突？ -
读者会不会据此做出高成本或高风险决定？
例如，“多 Agent 更强”会被收窄为：
多 Agent 可以通过并行、上下文隔离和多路径探索改善某些任务，但收益依赖任务结构与额外计算。2026 年一项预算对照研究在多跳推理任务中发现，同等思考 Token 预算下，单 Agent 通常持平或更好。
这句话没有否定 Graph，也没有替 Graph 做超出证据的宣传。
10. 实操：45-60 分钟跑通 Graph Lab
实验包的目的不是模拟一个“聪明 Agent”，而是把模型拿掉后，单独观察 Graph 的工程机制。
它使用 Node.js 18+，没有第三方依赖，也不需要 API Key。内置 handler 返回确定性样例数据，因此每个人都能复现调度、验证、失败和闸门。
10.1 解压并运行
PowerShell：
macOS / Linux：
第一次运行不会发布，它会停在人工闸门：
这不是失败，而是设计目标。打开 trace.json，可以看到：
official_sources
、 research_papers、community_signals同批执行；verify
在三者完成后开始； synthesize
只在 verification 通过后运行； publish_gate
状态为 blocked；finalState
保留文章 brief，但没有 release decision。
显式批准：
预期结果：
10.2 先读 workflow.json
控制项如下：
读者应该能回答：
-
为什么三个 research 节点可以并行？ -
为什么 verifier 必须等待三个节点？ -
为什么 synthesis 同时依赖 evidence 和 verification？ -
为什么 gate 不能由 synthesis 自动绕过？ -
哪个状态 key 由哪个节点写入？
答不出来时先不要接真实模型。框架不能替你补全依赖语义。
10.3 做四个小实验
实验一：制造一条假边。
让 community_signals 依赖 official_sources，但不把 officialEvidence 加入 inputKeys。重新运行后，校验器会拒绝这条“只表示顺序、没有消费结果”的依赖。
实验二：让验证失败。
把 verify.config.minEvidence 从 6 改成 7。图会停在 verifier，后面的 synthesis 和 gate 被标记为 skipped。这说明验证失败不会默默进入发布链。
实验三：压缩总时间预算。
把 maxDurationMs 改成 50。三个 research 节点包含不同延迟，运行会以明确的 budget error 停止，并在 trace 中保留已经完成的部分。
实验四：降低并发。
把 maxConcurrency 从 3 改成 1，再次比较 metrics.durationMs 和 peakConcurrency。结果会更慢，但逻辑输出保持一致。这能把“并行速度收益”与“答案质量收益”分开。
最后运行完整测试：
预期输出：
测试覆盖正常路径、缺失节点、循环、重复 writer、验证失败、节点超时、全局预算和人工闸门。
10.4 把确定性节点替换成真实 Agent
一次只替换一个 handler：
每次替换后都保留三件事：
-
输入输出合同不变； -
失败类型和预算仍由 runner 控制； -
不可逆边继续由代码和人拥有。
实验包没有实现循环边，因为它先教学 DAG。真实系统需要 retry 时，应把允许重试的错误、最大轮次、退避和升级路径都写出来，而不是简单增加一条回到自己的箭头。
11. 主流工具怎样映射到这套模型
Graph Engineering 不是要求所有人选同一个框架。先看你缺的是 SDK、持久化运行时，还是项目级调度。
一个实用判断是：
先选运行问题，再选框架。不要反过来为了使用框架制造一张图。
12. 什么时候不该使用 Graph
Graph 的成本不仅是 Token。还包括状态 schema、调度、日志、失败恢复、权限和维护人员的认知负担。
以下情况优先保留单 Agent：
2026 年论文《Single-Agent LLMs Outperform Multi-Agent Systems on Multi-Hop Reasoning Under Equal Thinking Token Budgets》提供了一个重要反例：在其测试的多跳推理任务和模型中，控制思考 Token 预算后，单 Agent 通常与多 Agent 持平或更好；当单 Agent 的有效上下文被严重干扰时，多 Agent 才更有竞争力。
这项研究不能证明“多 Agent 无用”，但它提醒我们：
如果 Graph 只是增加了更多调用和更长推理，却没有利用真实并行、上下文隔离、独立验证或权限边界，那么提升可能来自额外计算，而不是拓扑本身。
因此，建立 Graph 前先保存单 Agent 基线：
Graph 版本至少应该在其中一个重要指标上获得可重复收益，同时没有让安全边界变差。
13. 可复制的 Graph 设计画布
在选框架或写代码前，先填写这份画布：
评审一张图时的十个问题
-
每个节点是否只有一个主要职责？ -
每条边是否写明了真正消费的上游输出？ -
没有依赖的任务是否仍被错误地串行执行？ -
每个状态 key 是否只有一个明确 writer？ -
verifier 是否独立于产出节点？ -
验证是否触碰测试、来源或真实业务信号？ -
失败后能否只重跑必要节点？ -
并发、轮次、Token、时间和费用是否有硬上限？ -
不可逆动作是否停在代码控制的人工闸门？ -
Trace 是否足以解释这次运行为什么成功或失败？
有三项答不出来时，不要急着增加节点。先修图的合同。
14. 最常见的七种失败
14.1 角色很多，边仍然是假的
“研究员 → 分析师 → 写作者”看起来专业，但如果三者只重复阅读同一段对话，没有结构化输出合同，它只是把一次调用拆成三次。
14.2 Verifier 与作者共享偏见
同一个上下文、同一套来源、同一个目标，只换一个“Reviewer”角色名，独立性几乎没有增加。
14.3 所有 Agent 都能写所有文件
并发没有所有权，就会产生冲突、覆盖和难以解释的最终 diff。优先采用 worktree、目录所有权或单 writer。
14.4 所有路由都交给 LLM
探索分支可以动态，生产发布边不应该动态。模型可以建议执行发布，但代码必须检查权限和批准状态。
14.5 只检查 Agent 是否同意
多个节点都给 pass，不代表结果接触过现实。测试、日志、来源和业务数据不能省。
14.6 Retry 没有边界
“失败后重试”不是恢复策略。需要区分瞬时错误、输入错误、规则冲突和能力不足，并为每类错误设置次数与升级路径。
14.7 用 Graph 证明 Graph
如果只展示成功案例、不给单 Agent 基线、不记录额外预算，就无法判断收益来自图结构还是更多计算。
15. 收藏清单
准备把一个 Agent Loop 升级为 Graph 时，按这个顺序：
结语：Graph 的价值是暴露决定
Graph Engineering 最值得保留的，不是“从 Loop 升级到 Graph”这句口号，而是一种更严格的提问方式：
一个 Agent Loop 可以把这些决定藏在上下文和模型推理里；一张好的工作图会把关键决定搬到结构、代码、测试和人工权限中。
但 Graph 不是默认答案。
当一个 Agent 能以更少成本稳定完成任务时，保留一个 Agent。当任务出现真实并行、上下文隔离、独立验证、不同权限和长期恢复需求时，再引入 Graph。
真正成熟的 Graph Engineering，不是把图画得越来越大，而是知道哪些节点应该是 Agent，哪些应该是普通代码，哪些边必须停下来等人。
参考资料
官方资料与项目
-
OpenAI Agents SDK：Agent orchestration -
OpenAI：An open-source spec for Codex orchestration, Symphony -
OpenAI Symphony GitHub repository -
Anthropic：Introducing dynamic workflows in Claude Code -
Anthropic：A harness for every task -
Anthropic：How we built our multi-agent research system -
Anthropic：Building effective agents -
LangGraph：Graph API overview -
Google ADK：Template agent workflows and graph alternatives -
Microsoft AutoGen：GraphFlow（实验性）
研究论文
-
Single-Agent LLMs Outperform Multi-Agent Systems on Multi-Hop Reasoning Under Equal Thinking Token Budgets -
From Agent Loops to Structured Graphs: A Scheduler-Theoretic Framework for LLM Agent Execution -
Graphs Meet AI Agents: Taxonomy, Progress, and Future Opportunities -
LLMs+Graphs: Toward Graph-Native, Synergistic AI Systems
社区讨论与教程
-
Carlos E. Perez：From Loop Engineering to Graph Engineering? -
Machina：How to master graph engineering -
codila：Graph Engineering dynamic workflows -
AI Builder Club：Graph Engineering Guide -
AI Builder Club：Graph Engineering vs Loop Engineering
订阅智宅客
AI / 技术 / 数字生活方式，新文章第一时间送到邮箱。
