GitHub 上的 Graph Engineering：概念很热，代码写到哪了

GitHub 上的 Graph Engineering：概念很热，代码写到哪了

2026 年 7 月最后一周，Graph Engineering 这个词突然出现在各种技术号里。我没跟着概念走——去 GitHub 搜了一圈，想看看代码到底写到什么程度了。

一、先搞清楚这词到底在说什么

Graph Engineering 不是又一个框架名。它是一套设计模式——用图的拓扑结构来组织 Agent 的工作。

三个要素：

• 节点

  ：一个 Agent 完成一个任务。每个节点有明确的输入、输出和职责边界。

• 边

  ：数据从 A 流到 B。不是"逻辑上的先后"，是数据真的在流动。没有数据依赖的两个节点，不该有边——它们是并行的。

• 拓扑

  ：图长什么样。线性链、并行扇出、钻石模式（拆分→并行→独立验证→合并）——形状跟着任务本身走。

这三个东西合在一起，回答的是同一个问题：一群 Agent 怎么协作。

它是怎么演化过来的

演化路径很清晰，三个阶段：

Prompt Engineering        Loop Engineering        Graph Engineering
 调教一个Agent说什么  →   调教一个Agent怎么迭代  →  调教一群Agent怎么协作
 "你是个好程序员"         "多次尝试，取最好的"       "你管正确性，你管性能，你合并"

这三个阶段不是替代关系。用的是 Graph 还是 Loop，取决于任务本身能不能被拆开——Google DeepMind × MIT 的论文测了 180 种配置，结论很简单：拆得开的工作，团队胜率 80% 以上；拆不开的串行工作，换什么配置都输。

这也许是 Graph Engineering 值得关注的核心原因。不是因为图比循环高级——是因为很多工作本身是图状的。组织一群 Agent 的方式，应该跟任务本身的结构对齐。

二、在 GitHub 上能搜到什么

在 GitHub 上搜 "graph engineering"，拉出来 15 个直接相关的仓库。加上 awesome-graph-engineering 收录的项目，能凑出一个还不错的样本。

先说整体水位：最高 370 star，没有万星项目。 生态还很早期，但已经能看出三条方向性的共识。

三、第一个共识：Graph Engineering 不光指知识图谱

搜 "graph engineering"，你会同时看到两类项目：做知识图谱的（本体、实体抽取、知识融合），和做 Agent 任务编排的（DAG、并行扇出、独立验证）。

graph-engineering（⭐250）在 README 第一段就把话说清楚了——它把 Graph Engineering 拆成两个半边：知识图谱（Agent 记住了什么）和任务图（Agent 怎么工作）。

这个项目把东南大学汪鹏教授的《知识图谱》研究生课程（⭐4.4K，2019 年教到现在）翻译成了英文，提炼出一个 9 阶段流水线，同时做成了 Claude Code Skill——装到 Claude Code 里，能用你自己的项目当示例走一遍教学。

领域建模 → 知识表示 → 本体设计 → 实体抽取 → 关系抽取
   → 事件抽取 → 质量门控 → 知识融合 → LLM 服务化

这 9 步有一个跟直觉相反的原则：先建模，再抽取——不是上来就扒数据，先定义好要什么结构，再往里面填。

GraphARC（⭐13）在 LangGraph 上盖了一层治理。Planner 提出子图草案，一个确定性 checker 审核通过后才执行。每个节点声明自己能写哪些字段，越权直接抛异常。项目 README 里有一句挺实在：

"Graph engineering: when one agent loop stops being enough, coordination becomes the engineering."

（当一个 Agent 循环不够用的时候，协调本身就是工程。）

四、第二个共识：怎么编排比用什么编排重要

框架之间的差异没有想的那么大。deer-workflow 用 TypeScript、GraphARC 用 Python/LangGraph、Kigi-CLI 用 Rust——但它们在争的不是语言，是图的边到底代表什么。

graph-engineering 的 README 列了四条规则：

• 删除假边。

   两个节点之间画箭头，必须代表数据真的从 A 流到了 B。如果"总结文件"和"查天气"之间没有数据依赖——它们是并行的，不应该有边。

• 钻石模式。

   拆分 → 并行多路 → 独立验证上下文 → 一个 Owner 合并。Worker 之间互不可见，验证者独立于执行者。

• 停止规则。

   Google DeepMind × MIT 的论文——测了 180 种 Agent 团队配置。结论：拆得开的工作，团队胜率 80% 以上；拆不开的串行工作，换什么配置都输。图的形状要跟着任务本身走。

• 人机门控。

   审批按钮放在错误代价最高的节点。

deer-workflow（⭐370，字节跳动 DeerFlow 3.0 的先导项目）是这四条规则的代码实现。它做的一件事值得注意：控制流写在 TypeScript 里，Agent 只做每个节点内的语义工作。

// TypeScript 定义控制流，Agent 做语义工作
 const workflow = createWorkflow("deep-research")
   .phase("discover", async (ctx) => { /* Agent 发现研究方向 */ })
   .phase("investigate", async (ctx) => {
     await Promise.all(ctx.topics.map(t => ctx.agent.investigate(t)))
   })
   .phase("verify", async (ctx) => { /* 独立验证 */ })
   .phase("synthesize", async (ctx) => { /* Owner 合并 */ })

Codex 是默认运行时，Claude Code 已内置支持，Agent 接口厂商中立。今天用 Codex 写的编排，明天切 Claude Code——控制流跟语义执行已经解耦了。

五、生态现状：四层结构

搜到的项目大致分四层：

框架/运行时

项目

Stars

语言

定位

方法论/Skill

项目

Stars

说明

知识库/数据集

• awesome-graph-engineering（⭐13）：477 资源、225 论文、CC0 数据集、交互式 Atlas

应用层

• Gold-Band（⭐28）：桌面 App

• graphrag-engineering-pdfs（⭐28）：本体 + GraphRAG

• rashomon-debate（⭐3）：多角色辩论验证 Graph > Loop

• delivery-graph（⭐12）：交付场景

几个观察：

deer-workflow 的 npm 包已经能 bun install 直接用——大厂把内部编排框架开源成标准基础设施，这个信号比概念文章有分量。

最高 370 star，没有 killer app。生态在用脚手架搭地基。但框架层和方法论层在同时演化，互相引用对方术语——方向是确定的。

六、现在能跑起来的四个场景

深度研究。 deer-workflow 的 Deep Research：发现方向 → 并行调研 → 独立验证 → 合成 HTML 报告。四条路径并行，验证者跟调研者互不可见。

知识库构建。 走 9 阶段流水线——定义本体、抽取实体和关系、质量校验、知识融合——接 GraphRAG。装 graph-engineering skill，教学模式下用你自己的项目当示例。

代码审查。 拆分 → 多审查者并行 → 独立验证 → 一个 Owner 决策。每个审查者只看一个维度（正确性、安全性、性能），各自独立，最后合并。

博客/报告写作。 deer-workflow 的 Blog Writer 示例：规划大纲 → 各章节并行起草 → 统一审查 → 输出。快的不单是生成速度——哪个章节需要改，只重跑那一节。

七、三个项目的作者说的是同一件事

graph-engineering（方法论项目）：

"Prompt engineers steered the model's words. Loop engineers steered its iterations. Graph engineers steer its topology."

（Prompt 工程师调教模型说什么。Loop 工程师调教它怎么迭代。Graph 工程师调教它的拓扑结构。）

GraphARC（框架项目）：

"Graph engineering: when one agent loop stops being enough, coordination becomes the engineering."

（当一个 Agent 循环不够用的时候，协调本身就是工程。）

deer-workflow（大厂开源）没写漂亮话，但用代码表了态：TypeScript 控制流 + 可替换 Agent 运行时——组织架构的事，不该交给模型的 prompt 去管。

三句话指向同一个方向：从调教一个 Agent，上移到组织一群 Agent。 不是换框架。是换思路。

Andrew Ng 在 7 月的访谈里说：我们不缺能干的 Agent，缺的是让一群 Agent 不互相踩脚的机制。

Graph Engineering 不是又一个框架。框架会过时。它是设计模式——不管底层跑的是 LangGraph、deer-workflow 还是自己拼的东西，结构模式的思考方式可以复用。

从哪儿开始

5 分钟：awesome-graph-engineering 的交互式 Atlas，一张图了解全貌。

30 分钟：在 Claude Code 里装 graph-engineering skill，教学模式走一遍。

直接写代码：

bun install –global @deerwork-ai/deer-workflow
 deer-workflow create "描述你想做的事" > workflow.ts
 deer-workflow run ./workflow.ts

已有 LangGraph 项目：pip install grapharc，加盖治理层。

数据截至 2026 年 8 月 1 日。主要参考：awesome-graph-engineering、graph-engineering、deer-workflow、GraphARC。