What Is Graph Engineering? A Field Guide for Builders什么是图工程？一份面向构建者的实战指南

The term went viral on X in 48 hours, with three competing meanings and one fabricated study. Under the noise: a real discipline with benchmark numbers, one gap nobody has claimed.这个术语在 X（前身为 Twitter）上 48 小时内迅速走红，伴随着三种相互竞争的定义和一项虚构的研究。在喧嚣之下，这其实是一门有着基准数据支持的严谨学科，且存在一个尚未被填补的空白。

TL;DR摘要

• “Graph engineering” exploded on X this week with three competing definitions and a viral study that does not exist.本周，“图工程”（Graph engineering）在 X 上爆发，出现了三种相互竞争的定义，以及一项并不存在的病毒式传播研究。

• The discipline underneath is real and measurable: graphs beat vector search on multi-hop and temporal questions, and lose on simple lookups and cost.其背后的学科是真实且可衡量的：在处理多跳问题和时序问题时，图技术优于向量搜索；但在简单的查找任务和成本控制方面，图技术则处于劣势。

• A vault of linked markdown is already 80% of a graph index. I am building the missing 20% in the open.一个由链接构成的 Markdown 知识库已经完成了图索引 80% 的工作。我正在以开源的方式构建那缺失的 20%。

Agents that read flat documents miss chains: who decided X, what replaced it, what broke because of it. Graph-shaped memory is the fix, and it is measurable. LinkedIn cut support resolution time 28% with it, and the best graph systems answer multi-hop questions 10 points better than vector search.阅读扁平化文档的智能体往往会错过逻辑链条：比如谁决定了 X，什么取代了它，以及因为它导致了什么问题。图状记忆是解决这个问题的关键，而且它是可量化的。LinkedIn 利用它将支持问题的解决时间缩短了 28%，最优秀的图系统在回答多跳问题时，表现比向量搜索高出 10 个百分点。

That is the business case. Now the story.这就是商业案例。现在，让我们来讲讲故事。

On July 18, Peter Steinberger posted twelve words on X: “Are we still talking loops or did we shift to graphs yet?” Thousands of likes. Within 48 hours, “graph engineering” had three competing definitions, a wave of copycat posts, and a viral claim about a “$3.1M Stanford and Anthropic study.”7 月 18 日，Peter Steinberger 在 X 上发布了十二个字：“我们还在谈论循环，还是已经转向图了？”获得了数千个赞。48 小时内，“图工程”就有了三种相互竞争的定义、一波跟风帖，以及关于一项“价值 310 万美元的斯坦福与 Anthropic 研究”的病毒式传播声明。

I went looking for that study. It does not exist. Fabricated engagement bait.我去寻找了那项研究。它根本不存在。这纯粹是为了骗取互动的虚构内容。

But I kept digging, because under the noise there is a real discipline with a decade of research, working tools, and benchmark numbers that survived independent evaluation. I spent the weekend reading all of it so you do not have to.但我继续深入挖掘，因为在喧嚣之下，确实存在一门有着十年研究积累、实用工具和经得起独立评估的基准数据的严谨学科。我花了整个周末阅读了所有相关资料，这样你就不必再费力去看了。

By the end of this issue you will understand graphs better than most people posting about them this week.读完本文，你对图的理解将超过本周大多数在网上讨论它的人。

The whole primitive in 60 seconds

60 秒看懂核心概念

Strip every buzzword away and a graph is two things.剥离所有流行语，图其实就是两件事。

Nodes: the things you know about. A person, a project, a decision, an incident.节点：你所了解的事物。比如一个人、一个项目、一个决策或一个事件。

Edges: the connections between them.边：它们之间的连接。

That is the entire primitive. The reason it matters for AI is retrieval. An agent answering a question has to find the right knowledge first, and there are only three ways to find things:这就是全部基础。它对 AI 的意义在于检索。智能体在回答问题时必须先找到正确的知识，而查找事物的方法只有三种：

• Keyword search finds notes containing a word. Fails when the answer uses different words.关键词搜索：查找包含特定词汇的笔记。当答案使用了不同的词汇时，这种方法就会失效。

• Vector search finds notes that are about similar things. Fails when the answer is spread across notes that are individually not similar to the question.向量搜索：查找内容相似的笔记。当答案分散在多份笔记中，而这些笔记单独来看与问题并不相似时，这种方法就会失效。

• Graph traversal starts at one node and walks the connections. It is the only method that can follow a chain of reasoning.图遍历：从一个节点出发，沿着连接路径行走。这是唯一能够追踪推理链条的方法。

The question that breaks vector search

让向量搜索失效的问题

Here is a synthetic example, the kind of question every real knowledge base gets asked:这是一个合成示例，也是每个真实知识库都会遇到的那种问题：

“Why did we drop Redis for the job queue?”“我们为什么放弃 Redis 来处理作业队列？”

Vector search embeds the question and pulls the ten chunks most similar to it. You get ten notes that mention Redis. None of them explains the decision, because the decision lives in the structure: a decision record, the thing it replaced, and the incident that triggered it. Three separate notes. Similarity search has no concept of “these three belong to one causal chain.”向量搜索会将问题向量化，并提取出最相似的十个片段。你会得到十份提到 Redis 的笔记。但没有一份笔记能解释这个决策，因为决策本身存在于结构中：一份决策记录、它所取代的事物，以及触发该决策的事件。这是三份独立的笔记。相似度搜索无法理解“这三者属于同一个因果链”的概念。

Graph traversal walks it:图遍历则可以将其串联起来：

hop 1:  [[Job queue]] --decided_by--> [[ADR-007 Postgres queue]]
hop 2:  [[ADR-007]]  --supersedes--> [[ADR-003 Redis queue]]
hop 3:  [[ADR-003]]  --caused-->     [[Incident 2026-03-11]]

Three notes, about 1,000 tokens, causal chain intact.三份笔记，约 1,000 个 Token，因果链完整。

Each step is a hop. Questions needing more than one hop are multi-hop questions, and they are where flat retrieval consistently breaks. “Who decided X and what broke because of it” is a two-hop question. Most interesting questions about any real body of knowledge are multi-hop.每一步都是一个“跳”（hop）。需要超过一步才能回答的问题被称为多跳问题，这也是扁平化检索经常失效的地方。“谁决定了 X 以及因为它导致了什么问题”就是一个两跳问题。关于任何真实知识体系，大多数有趣的问题都是多跳问题。

One sentence to keep: vector search finds things that sound like your question. Graphs find things that are connected to your answer.记住一句话：向量搜索找到的是听起来像你问题的内容。图找到的是与你答案相关联的内容。

One bit versus meaning

比特与意义

Now the detail that decides whether a graph is useful or just pretty.现在是决定图是有用还是仅仅看起来美观的细节部分。

An untyped edge says “these two notes are related.” One bit of information. A typed edge says how: supersedes, depends_on, decided_by, caused.无类型边只能表示“这两份笔记相关”。这只包含一个比特的信息。而有类型边则说明了它们如何相关：取代（supersedes）、依赖于（depends_on）、由……决定（decided_by）、导致（caused）。

Run the Redis example without types. The traversal becomes “the queue is related to a decision, which is related to another decision, which is related to an incident.” Did ADR-007 replace ADR-003, or the other way around? Did the incident cause the decision or the decision cause the incident? The chain survives. The meaning is gone, and the agent has to re-read every note and guess.如果不使用类型，运行 Redis 的例子，遍历过程就变成了“队列与一个决策相关，该决策与另一个决策相关，后者又与一个事件相关”。是 ADR-007 取代了 ADR-003，还是反过来？是事件导致了决策，还是决策导致了事件？链条虽然存在，但意义丢失了，智能体必须重新阅读每一份笔记并进行猜测。

Typed edges turn a pile of links into something you can reason over. Hold onto that. It is the center of everything that follows.有类型边将一堆链接变成了你可以进行推理的对象。记住这一点，这是后续一切内容的核心。

Where the term actually came from

这个术语究竟从何而来

Know the history, so nobody can bluff you with it.了解历史，这样就没人能用它来糊弄你。

“Graph engineering” sits on a treadmill of terms. Each one described a real shift. Each one got turned into content slop within weeks:“图工程”处于术语的跑步机上。每一个术语都描述了一个真实的转变，但每一项都在几周内变成了内容垃圾：

• 2023: prompt engineering. Craft the words you send the model.2023 年：提示词工程（Prompt engineering）。精心设计你发送给模型的词汇。

• Mid-2025: context engineering. Curate everything in the window.2025 年中期：上下文工程（Context engineering）。精心策划窗口中的所有内容。

• June 2026: loop engineering. Design the agent’s act-observe-retry cycle.2026 年 6 月：循环工程（Loop engineering）。设计智能体的“行动-观察-重试”循环。

• July 2026: graph engineering. Design what happens between and across loops.2026 年 7 月：图工程（Graph engineering）。设计循环之间及跨循环发生的事情。

The receipts: a quiet blog post by Josh Simmons on July 4 is the earliest documented use I found. Steinberger's July 18 post lit the fuse (he was mocking the treadmill; the treadmill did not care). Carlos Perez published one of the first serious essays about ten hours later. The backlash started the same day.证据：Josh Simmons 在 7 月 4 日发布的一篇安静的博文是我发现的最早记录。Steinberger 7 月 18 日的帖子点燃了导火索（他在嘲讽这种“术语跑步机”；但跑步机本身并不在乎）。Carlos Perez 在大约十小时后发表了第一篇严肃的文章。反弹也随之在同一天开始。

Within 48 hours the term meant three different things:48 小时内，这个术语有了三种不同的含义：

• Orchestration graphs: design multi-agent systems as explicit graphs instead of loops. Typed nodes, typed transitions, checkpoints. This is LangGraph and Temporal territory.编排图（Orchestration graphs）：将多智能体系统设计为显式图，而非循环。包括类型化节点、类型化转换、检查点。这是 LangGraph 和 Temporal 的领域。

• Graphs of loops: networks of self-improvement cycles watching each other. The most abstract meaning, and the least actionable today.循环图（Graphs of loops）：相互观察的自我完善循环网络。这是最抽象的含义，也是目前最难落地的含义。

• Graph-structured knowledge and memory: the agent’s knowledge stored as typed nodes and edges it can traverse.图结构知识与记忆（Graph-structured knowledge and memory）：智能体的知识以类型化节点和边的形式存储，可供其遍历。

Only the third one has a decade of research, working tools, and real money behind it. Serious people were building it before the name existed, under different words: Foundation Capital called it “context graphs” in December 2025 and put a trillion-dollar label on it. Gartner predicts over half of enterprise agent systems will use graph-based context by 2028. SAP shipped a knowledge graph as its agent context layer.只有第三种含义拥有十年的研究、成熟的工具和真金白银的支持。在名字出现之前，严肃的从业者就已经在用不同的词汇构建它了：Foundation Capital 在 2025 年 12 月称之为“上下文图”（context graphs），并给它贴上了万亿美元的标签。Gartner 预测，到 2028 年，超过一半的企业智能体系统将使用基于图的上下文。SAP 已经发布了作为其智能体上下文层的知识图谱。

The term is new. The substance is not.术语是新的，但内涵并非如此。

How GraphRAG actually works

GraphRAG 实际上是如何工作的

The umbrella name for graph-based retrieval is GraphRAG. Four systems matter, and each teaches one lesson.基于图的检索统称为 GraphRAG。有四个系统值得关注，每一个都传达了一个教训。

Microsoft GraphRAG (2024) is the reference architecture:Microsoft GraphRAG (2024) 是参考架构：

1. An LLM reads every chunk and extracts entities plus relationships.LLM 读取每个片段并提取实体及关系。

2. Community detection clusters related entities into neighborhoods.社区检测将相关实体聚类成邻域。

3. An LLM writes a summary report for every community.LLM 为每个社区撰写总结报告。

4. At query time, broad questions map-reduce over the reports; specific questions expand from a matched entity.在查询时，广泛的问题会对报告进行 Map-Reduce 处理；具体问题则从匹配的实体进行扩展。

It works. It is also brutal on cost: an LLM call per chunk at index time. One widely cited estimate put it at around $33,000 to index a single large enterprise dataset. Lesson one: the naive version is too expensive, and its free-text edges do not compose.它确实有效，但成本极其高昂：索引时每个片段都需要一次 LLM 调用。一项广泛引用的估算显示，索引单一大型企业数据集的成本约为 33,000 美元。教训一：朴素版本成本太高，且其自由文本边无法组合。

LazyGraphRAG (Microsoft’s own correction) flips the design: build only a cheap structural graph at index time, and do the expensive thinking at query time. Indexing cost drops to about 0.1% of the original. Answer quality stays comparable.LazyGraphRAG（微软自己的修正版）颠覆了设计：在索引时只构建廉价的结构图，而在查询时进行昂贵的思考。索引成本降至最初的 0.1% 左右，回答质量保持相当。

Lesson two, and remember this one: you do not need to pre-compute the graph’s meaning. A cheap structural graph plus smart traversal at query time gets most of the value.教训二，请记住这一点：你不需要预先计算图的意义。廉价的结构图加上查询时的智能遍历就能获得大部分价值。

HippoRAG 2 (2025) is the benchmark king. It fuses graph structure with embeddings and ranks results by spreading importance along edges from wherever the query touched the graph. It spends about 1,000 tokens per query, wins on multi-hop, and, critically, does not get worse at simple questions to get better at hard ones. Most graph systems do. Lesson three: the winning retrieval is hybrid, never graph-only.HippoRAG 2 (2025) 是基准测试之王。它将图结构与嵌入融合，通过从查询触及的图节点向外传播重要性来对结果进行排名。它每次查询消耗约 1,000 个 Token，在多跳问题上胜出，且关键在于，它不会为了提高复杂问题的表现而牺牲简单问题的准确性。大多数图系统都会这样。教训三：获胜的检索方式是混合式的，绝非单纯的图检索。

The 2026 trend line across the whole field: lazy indexing, agentic traversal (the agent decides which hops to take, live), small controlled edge vocabularies, and honest routing. Use the graph only for questions that need it.整个领域 2026 年的趋势线：懒惰索引（Lazy indexing）、智能体遍历（智能体实时决定采取哪些跳跃）、受控的小型边词汇表，以及诚实的路由。只在需要的问题上使用图。

Memory that knows what time it is

具备时间意识的记忆

GraphRAG answers questions about a corpus. Agent memory is harder: knowledge that changes while the agent uses it. You change jobs. A decision gets reversed. A fact true in March is false in July.GraphRAG 回答关于语料库的问题。智能体记忆则更难：知识会在智能体使用它的过程中发生变化。你换了工作，一个决策被推翻，三月份是真的事实在七月份可能就是假的。

This is where graphs do something vector stores structurally cannot.这就是图能够做到向量存储在结构上无法做到的事情的地方。

Graphiti, the open-source engine behind Zep, tracks two timelines per edge: when the fact was true in the world, and when the system learned it. When new information contradicts an old edge, the old edge is not deleted. Its validity interval is closed, and the new edge takes over.Graphiti 是 Zep 背后的开源引擎，它为每条边追踪两条时间线：事实在现实中成立的时间，以及系统学习到它的时间。当新信息与旧边矛盾时，旧边不会被删除。它的有效期区间会被关闭，新边取而代之。

The agent can now answer both “where does she work?” and “where did she work in 2024?” from the same graph. Facts get superseded, not overwritten. A vector store can only overwrite or duplicate; it has no native concept of “this was true until May.”智能体现在可以从同一个图中回答“她在哪里工作？”和“她在 2024 年在哪里工作？”。事实是被取代，而不是被覆盖。向量存储只能覆盖或复制；它没有原生的“这在五月之前是真的”的概念。

Any long-lived knowledge base has this shape. Decisions supersede decisions. Claims go stale. A system that cannot represent “X replaced Y on this date” slowly fills with contradictions, and an agent reading it will confidently cite the stale half.任何长寿的知识库都有这种形态。决策取代决策，声明变得过时。一个无法表示“X 在某日期取代了 Y”的系统会慢慢充满矛盾，而阅读它的智能体会自信地引用过时的那一半。

Notice the vocabulary this needs: supersedes, contradicts, valid_from, valid_until. Typed edges again.注意这里需要的词汇：取代（supersedes）、矛盾（contradicts）、有效期开始（valid_from）、有效期结束（valid_until）。再次强调：类型化边。

The scoreboard, honestly

诚实的记分牌

Half the numbers in this field are vendor-reported on their own benchmarks. Here is what independent evaluation actually shows, as of mid-2026:该领域一半的数据是厂商在自己的基准测试中报告的。以下是截至 2026 年中期，独立评估实际显示的结果：

Graphs win three things, by wide margins:图在三方面以巨大优势胜出：

• Multi-hop reasoning: 53.4% vs 42.9% for vector RAG on GraphRAG-Bench; HippoRAG 2 beats a strong embedding model by 9.5 F1 points on 2WikiMultiHopQA.多跳推理：在 GraphRAG-Bench 上为 53.4% 对比向量 RAG 的 42.9%；HippoRAG 2 在 2WikiMultiHopQA 上比强大的嵌入模型高出 9.5 个 F1 分。

• Temporal reasoning: the graph variant of Mem0 scores 58.1 where OpenAI’s memory scores 21.7. The most lopsided numbers in the field.时序推理：Mem0 的图变体得分为 58.1，而 OpenAI 的记忆得分仅为 21.7。这是该领域最悬殊的数据。

• Corpus-wide synthesis: 64.4% vs 51.3%.全语料库合成：64.4% 对比 51.3%。

Graphs lose two things:图在两方面处于劣势：

• Simple fact lookup: 60.9% for plain vector RAG vs 60.1% for the best graph method. The graph adds redundant context and wins nothing.简单事实查找：普通向量 RAG 为 60.9%，而最佳图方法为 60.1%。图增加了冗余上下文，却没有任何优势。

• Cost: Microsoft GraphRAG’s global search burned 331,375 tokens per query in the benchmark. Vector RAG: 880. (HippoRAG 2: 1,008. Efficiency is possible.)成本：Microsoft GraphRAG 的全局搜索在基准测试中每次查询消耗 331,375 个 Token。向量 RAG 为 880。（HippoRAG 2 为 1,008。效率是可以实现的。）

Two warnings worth the whole section. LightRAG posted huge wins on its own benchmark, then collapsed to 6.6 average F1 (versus 59.8 for HippoRAG 2) under independent evaluation. Never trust a system evaluated only by its authors. And in Mem0’s own paper, the graph variant lost to the non-graph variant on multi-hop questions. Graphs are a tool, not a religion.有两个警告值得整个章节的篇幅。LightRAG 在自己的基准测试中发布了巨大的胜利，但在独立评估中崩溃至 6.6 的平均 F1（相比之下 HippoRAG 2 为 59.8）。永远不要相信只由作者评估的系统。在 Mem0 自己的论文中，图变体在多跳问题上输给了非图变体。图是一种工具，而不是一种宗教。

The practitioner consensus: route by question type. Vector for lookups, graph for chains.从业者的共识：按问题类型路由。查找用向量，链条用图。

The math that kills graph projects

扼杀图项目的数学逻辑

If graphs win benchmarks, why does not everyone run one? Because of one number almost nobody says out loud.如果图在基准测试中获胜，为什么不是每个人都在运行它？因为有一个几乎没人会大声说出来的数字。

Entity resolution is deciding that “Dr. John Smith,” “J. Smith,” and “John” are one node, and that “Mercury the planet” and “Mercury the element” are two. Extraction pipelines get this wrong constantly, and the errors compound multiplicatively over hops.实体解析（Entity resolution）是指判定“John Smith 博士”、“J. Smith”和“John”是同一个节点，以及“行星水星”和“元素汞”是两个不同的节点。提取管道不断出错，且这些错误会随着跳数成倍增加。

At 95% per-hop accuracy, a 5-hop chain is 77% trustworthy. At 85%, it is 44%.在每跳 95% 的准确率下，5 跳链条的置信度为 77%。在 85% 的准确率下，则仅为 44%。

Your impressive multi-hop traversal is a coin flip.你那令人印象深刻的多跳遍历其实就是掷硬币。

Sit with that, because it flips the whole build order. The expensive part of graph engineering is not graph algorithms. It is deciding what is the same thing. And there is one place where that problem is already solved: human-curated wikilinks. When someone writes [[ADR-007]] in a note, entity resolution is done, by construction. No fuzzy merging, no compounding error.好好琢磨一下，因为它颠覆了整个构建顺序。图工程昂贵的部分不是图算法，而是判定什么是同一个事物。有一个地方这个问题已经解决了：人工策划的维基链接（wikilinks）。当有人在笔记中写下 [[ADR-007]] 时，实体解析在编写时就完成了。没有模糊合并，没有复合错误。

Extraction pipelines spend most of their engineering budget trying to recover what a wikilink gives you for free.提取管道花费了大部分工程预算，试图恢复维基链接免费提供给你的东西。

The gap nobody has claimed

那个无人认领的空白

I maintain obsidian-second-brain, an open-source Claude Code skill that runs an Obsidian vault as an AI-first second brain (45 commands, MIT, starred by 3,400+ developers). I have written before about what a working second brain has to do that Karpathy’s LLM Wiki pattern does not. So the question I actually cared about all weekend: who has built graph engineering on plain markdown?我维护着 obsidian-second-brain，这是一个开源的 Claude Code 技能，它将 Obsidian 库作为 AI 优先的第二大脑运行（45 个命令，MIT 协议，被 3,400 多名开发者加星）。我之前写过关于一个有效的第二大脑必须做什么，而 Karpathy 的 LLM Wiki 模式不需要做的事情。所以整个周末我真正关心的问题是：谁在纯 Markdown 上构建了图工程？

The answer surprised me. The space is five months old, moving fast, and every single player is missing exactly one leg of the tripod: typed edges in the files, graph rules and validation, agent retrieval.答案让我感到惊讶。这个领域仅有五个月历史，发展迅速，但每一个参与者都缺少三脚架的一条腿：文件中的类型化边、图规则与验证、智能体检索。

• Basic Memory (3.5k stars) has typed relations in markdown and a real agent API. But the types are freeform strings: no vocabulary, no rules, no validation.Basic Memory (3.5k 星) 在 Markdown 中有类型化关系和一个真实的智能体 API。但这些类型是自由形式的字符串：没有词汇表，没有规则，没有验证。

• Breadcrumbs, the veteran Obsidian plugin, has real graph engineering: typed links, automatic inverses, transitive rules. Built entirely for human navigation. No AI surface at all.Breadcrumbs，资深的 Obsidian 插件，拥有真正的图工程：类型化链接、自动反向、传递规则。完全为人类导航而构建。完全没有 AI 界面。

• Penfield is the only team articulating the full vision, and they route your graph into their cloud for $10 to 20 a month. Your markdown is an import source, not the store.Penfield 是唯一一个阐述了完整愿景的团队，但他们将你的图路由到他们的云端，每月收费 10 到 20 美元。你的 Markdown 只是一个导入源，而不是存储库。

• Others (Rowboat at 13.1k stars, obra’s knowledge-graph, IWE) ship agent-facing graph tools over vaults with explicitly untyped edges.其他人（Rowboat 13.1k 星，obra 的 knowledge-graph，IWE）在具有显式无类型边的库上发布面向智能体的图工具。

And two things, as of this weekend, exist nowhere:截至本周末，有两样东西在任何地方都不存在：

1. A linter for typed edges. Nothing validates a vault’s graph: unknown types, dangling targets, missing inverses, contradiction cycles. Zero tools.类型化边的 Linter（代码检查器）。没有任何工具验证库的图：未知类型、悬空目标、缺失反向、矛盾循环。零工具。

2. An eval proving typing works. Nobody has published evidence that typed links measurably improve agent answers over plain links. Zero hits.证明类型化有效的评估。没有人发表过证据表明类型化链接在智能体回答方面明显优于普通链接。零记录。

A well-kept vault is already 80% of a GraphRAG index. Entity resolution: solved by wikilinks. Indexing cost: zero, the graph is built at write time. The missing 20% is exactly those two lists above. 一个维护良好的库已经是 GraphRAG 索引的 80%。实体解析：通过维基链接解决。索引成本：零，图是在写入时构建的。缺失的 20% 正是上述两个列表。

What I am doing about it

我对此采取的行动

I am building the missing 20% into obsidian-second-brain, in the open, starting this week:我正在将缺失的 20% 构建到 obsidian-second-brain 中，从本周开始，以公开方式进行：

1. A small typed-edge vocabulary (10 to 20 verbs: supersedes, depends_on, decided_by, caused) written as plain inline fields, so notes stay human-readable and Obsidian-native.一个小型类型化边词汇表（10 到 20 个动词：取代、依赖于、由……决定、导致），写成简单的内联字段，以便笔记保持人类可读和 Obsidian 原生。

2. The linter. The thing that exists nowhere, and the cheapest to ship.Linter。这是目前任何地方都不存在，且最容易发布的东西。

3. The eval: same vault, same questions, typed versus untyped retrieval, published numbers.评估：相同的库，相同的问题，类型化与非类型化检索，发布数据。

Update (July 21): the typed-edge vocabulary and the linter shipped in the repo the day after this post went out. The eval is the piece still open.更新（7 月 21 日）：类型化边词汇表和 Linter 在本文发布后的第二天就在仓库中发布了。评估是目前唯一尚未完成的部分。

The 2026 consensus from every serious system points the same way: small typed core, cheap indexing, hybrid retrieval, temporal supersession. All four of those are implementable on markdown files you own. That is the version of graph engineering that survives after the hype cycle moves on.来自每个严肃系统的 2026 年共识都指向同一个方向：小型类型化核心、廉价索引、混合检索、时序取代。这四点都可以在你拥有的 Markdown 文件上实现。这就是在炒作周期过后依然能存活的图工程版本。

If you want to watch it get built (and get the benchmark numbers when the eval lands), subscribe. This is the kind of thing I ship here every two weeks.如果你想观察它的构建过程（并在评估落地时获得基准数据），请订阅。这就是我每两周在这里发布的那种内容。

Turns out the term everyone laughed at pointed at something real. The people laughing and the people building are not the same people.事实证明，每个人都嘲笑的术语指向了真实存在的东西。嘲笑的人和构建的人并不是同一群人。

Frequently asked questions

常见问题解答

What is graph engineering? Graph engineering is designing AI systems around explicit graphs: knowledge stored as nodes (entities) and typed edges (relationships) that an agent can traverse, instead of flat documents searched by similarity. The term went viral in July 2026, but the underlying discipline (knowledge graphs, GraphRAG, graph-based agent memory) predates the name by years.什么是图工程？图工程是围绕显式图设计 AI 系统：知识以节点（实体）和类型化边（关系）的形式存储，供智能体遍历，而不是由相似度搜索的扁平文档。该术语在 2026 年 7 月走红，但其背后的学科（知识图谱、GraphRAG、基于图的智能体记忆）早在几年前就已存在。

Is graph engineering the same as GraphRAG? GraphRAG is one part of it: retrieval-augmented generation where the retrieval step uses a graph. Graph engineering also covers agent memory graphs (like Zep’s Graphiti) and multi-agent orchestration graphs (like LangGraph).图工程与 GraphRAG 是一回事吗？GraphRAG 是其中的一部分：即检索步骤使用图的检索增强生成。图工程还涵盖智能体记忆图（如 Zep 的 Graphiti）和多智能体编排图（如 LangGraph）。

Is GraphRAG better than vector RAG? It depends on the question type. Independent benchmarks show graphs win multi-hop reasoning (53.4% vs 42.9%), temporal reasoning, and corpus-wide synthesis, and lose on simple fact lookups and cost. The practitioner consensus is to route by question type.GraphRAG 比向量 RAG 更好吗？这取决于问题类型。独立基准测试显示，图在多跳推理（53.4% 对 42.9%）、时序推理和全语料库合成方面胜出，但在简单事实查找和成本方面处于劣势。从业者的共识是按问题类型进行路由。

What is a typed edge in a knowledge graph? An untyped edge only says two things are related. A typed edge names the relationship: supersedes, depends_on, decided_by, caused. Types are what let an agent reason over the graph instead of guessing what each link means.知识图谱中的类型化边是什么？无类型边只说明两个事物相关。类型化边命名了关系：取代、依赖于、由……决定、导致。类型让智能体能够对图进行推理，而不是猜测每个链接的含义。

Can I build a knowledge graph in Obsidian? Yes. Every note is a node and every wikilink is an edge, which solves entity resolution by construction. What Obsidian lacks out of the box is typed edges, graph validation, and an AI retrieval layer, which is the gap this article describes.我能在 Obsidian 中构建知识图谱吗？是的。每个笔记都是一个节点，每个维基链接都是一条边，这从结构上解决了实体解析问题。Obsidian 开箱即用所缺乏的是类型化边、图验证和 AI 检索层，这正是本文所描述的空白。

Why do knowledge graph projects fail in production? Entity resolution errors compound multiplicatively over hops: at 85% per-hop accuracy, a 5-hop chain is only 44% trustworthy. Stale graphs and indexing cost are the other two killers.为什么知识图谱项目在生产中失败？实体解析错误会随着跳数成倍增加：在每跳 85% 的准确率下，5 跳链条的置信度仅为 44%。过时的图和索引成本是另外两个杀手。

Key takeaways

关键要点

• Vector search finds things that sound like your question. Graphs find things that are connected to your answer.向量搜索找到的是听起来像你问题的内容。图找到的是与你答案相关联的内容。

• “Graph engineering” was born on X on July 18, 2026 with three competing meanings. Only graph-structured knowledge and memory has benchmarks and production evidence behind it.“图工程”诞生于 2026 年 7 月 18 日的 X，带有三种竞争含义。只有图结构知识和记忆背后有基准测试和生产证据支持。

• Graphs win multi-hop, temporal, and synthesis questions by wide margins, and lose simple lookups and cost. Route by question type.图在多跳、时序和合成问题上以巨大优势胜出，在简单查找和成本上处于劣势。请按问题类型路由。

• An untyped link carries one bit. A typed edge (supersedes, depends_on, caused) is what turns a pile of links into something an agent can reason over.无类型链接仅携带一个比特信息。类型化边（取代、依赖于、导致）是将一堆链接转化为智能体可推理对象的基础。

• Entity resolution, not graph algorithms, is where graph projects die: at 85% per-hop accuracy, a 5-hop traversal is 44% trustworthy. Human-curated wikilinks solve it by construction.实体解析而非图算法是图项目的死穴：在 85% 的每跳准确率下，5 跳遍历的置信度仅为 44%。人工策划的维基链接从结构上解决了这个问题。

• Typed edges plus graph rules plus agent retrieval on plain markdown exists nowhere as one local-first package. The linter and the typed-vs-untyped eval have never been shipped by anyone.类型化边 + 图规则 + 纯 Markdown 上的智能体检索，目前还没有作为一个本地优先的包存在。Linter 和类型化与非类型化评估从未被任何人发布过。

Further reading

延伸阅读

• HippoRAG 2 (arXiv 2502.14802) - the benchmark-king paper; also the independent evaluation where LightRAG collapsed.HippoRAG 2 (arXiv 2502.14802) - 基准测试之王论文；也是 LightRAG 崩溃的独立评估来源。

• Zep: temporal knowledge graphs for agent memory (arXiv 2501.13956) - the bi-temporal model behind “facts expire, not die.”Zep：用于智能体记忆的时序知识图谱 (arXiv 2501.13956) - “事实过期而非死亡”背后的双时态模型。

• GraphRAG-Bench (arXiv 2506.05690) - the honest scoreboard: where graphs win and lose by task type.GraphRAG-Bench (arXiv 2506.05690) - 诚实的记分牌：图在何处按任务类型胜出或失败。

• We are entering the graph engineering phase - the July 4 post that quietly coined the term before the meme wave.我们正在进入图工程阶段 - 7 月 4 日的帖子，在模因浪潮之前悄悄创造了这个术语。

• I rebuilt Karpathy’s LLM Wiki. Here’s what’s missing. - my earlier piece on what a working second brain needs beyond the static wiki pattern.我重建了 Karpathy 的 LLM Wiki。这是缺失的部分。 - 我之前关于一个有效的第二大脑在静态维基模式之外需要什么的文章。

About the author

关于作者

Eugeniu Ghelbur is an AI Automation Engineer and the creator of obsidian-second-brain, an open-source Claude Code skill starred by over 3,400 developers on GitHub. He builds production AI systems for marketing and sales workflows, and his personal research covers AI agent memory, AI-first knowledge management, and second brains that maintain themselves. He writes The AI Operator (theaioperator.io), a weekly systems newsletter where every post documents a working build, including this one. The fastest way to reach him is e.ghelbur@gmail.com, and his open-source work lives at github.com/eugeniughelbur.Eugeniu Ghelbur 是一名 AI 自动化工程师，也是 obsidian-second-brain 的创建者，这是一个在 GitHub 上被超过 3,400 名开发者加星的开源 Claude Code 技能。他为营销和销售工作流构建生产级 AI 系统，他的个人研究涵盖 AI 智能体记忆、AI 优先的知识管理以及自我维护的第二大脑。他撰写《The AI Operator》(theaioperator.io)，这是一份每周系统简报，每篇文章都记录了一个可工作的构建，包括这一篇。联系他的最快方式是 e.ghelbur@gmail.com，他的开源工作位于 github.com/eugeniughelbur。