面对知识图谱方案选择难题，本文帮你理清四大主流工具的核心差异与适用场景。核心内容：1. 传统向量检索的短板与知识图谱的优势2. 四种方案（gbrain、GraphRAG、LLM Wiki、Graphify）的核心思路与数据来源对比3. 各方案的典型应用场景与选择建议
gbrain、GraphRAG、LLM Wiki、Graphify：4 种知识图谱方案怎么选
「怎么给 Agent 喂知识」是团队落地 AI 时的核心问题。gbrain、GraphRAG、LLM Wiki、Graphify 四个方案各自解决不同的需求，选对工具，事半功倍。
向量检索的短板
传统 RAG 的做法其实挺直接的：把文档切块、向量化，塞进向量库，然后用户提问就去捞 top-k。对简单问答场景，这套流程够用了。但问题在于，它只能找到语义上最相似的内容，理解不了文档之间的关联关系。
举个例子，你问「这个需求跟之前哪个模块有关联」，向量检索直接傻眼。知识图谱则不同，它把实体和关系存成图结构，Agent 可以顺着关系链条一路推理。所以，当我们面临复杂问题，知识图谱的价值就凸显出来了。
四个方案
| 方案 | 核心思路 | 数据来源 | 官方链接 |
|---|---|---|---|
| gbrain | Git + Postgres 做持久化知识图谱 | 人工录入 + Agent 自动更新 | github.com/garrytan/gbrain |
| GraphRAG | 知识图谱 + RAG 检索增强 | 文档自动提取图谱 | microsoft.github.io/graphrag |
| LLM Wiki | LLM 维护的 Markdown 知识库 | 人工维护 + LLM 增量更新 | github.com/nashsu/llm_wiki |
| Graphify | 从代码库自动生成知识图谱 | 代码静态分析 + 语义提取 | graphify.net |
gbrain：Agent 的持久化记忆
gbrain 是 Garry Tan 开源的项目，最初是为 OpenClaw 设计的 Agent 记忆层。它的思路很清晰：用 Postgres 存图结构，Git 做版本控制。Agent 学到新知识后，直接写入图谱，Git 自动记录变更。
1Agent 对话 → 提取实体和关系 → 写入 Postgres → Git commit 记录变更
特点：
- Agent 跨对话不丢上下文
- Git 版本控制天然支持回滚
- 与 OpenClaw 生态集成紧密，脱离 OpenClaw 使用成本较高
成本：
- 需要部署 Postgres
- 图谱初始化需手动完成，历史数据迁移成本较高
适合多 Agent 协作、需要共享记忆的团队。
GraphRAG：文档级全局检索
GraphRAG 是微软的方案。核心流程是先用 LLM 从文档集合里提取实体和关系，构建知识图谱。用户提问时，检索系统会顺着图谱找到关联上下文，再让 LLM 生成最终回答。
123文档集合 → LLM 提取实体/关系 → 构建知识图谱
用户提问 → 图谱检索关联上下文 → LLM 生成回答
文档量大的时候，它的优势就特别明显。普通 RAG 只能做局部匹配，而 GraphRAG 能回答「总结整个语料库的主题」这类全局性问题。
代价：
- 索引时间长，文档量过千页首次索引要几个小时
- 更新图谱需要重新跑提取流程，做不到实时
- 提取实体和关系这一步本身费 token 也费时间
适合有固定文档集合、需要做全局分析的场景，比如企业知识库、法律文档。但文档频繁更新的话，这套方案就不太合适了。
LLM Wiki：极简知识库
这是 Karpathy 提出的思路：用 LLM 当编译器，维护一个 Markdown 知识库。每次对话先检索相关内容，然后根据新信息增量更新回知识库。
123用户提问 → 检索 Wiki 相关页面 → LLM 结合上下文回答
新信息 → LLM 决定更新哪个页面 → 写入 Markdown 文件
这个方案最轻量。纯 Markdown 文件，任何编辑器都能打开，没有数据库依赖。知识沉淀过程完全透明，人随时可以手动编辑。
局限：
- 没有真正的图结构，关系靠 LLM 的语义理解
- 知识库大了检索效率会下降
- 多人同时编辑同一页面时，LLM 可能覆盖别人的修改
个人或小团队够用，追求轻量和可控的场景是首选。
Graphify：代码库知识图谱
Graphify 专门从代码仓库自动生成知识图谱。它先用静态分析提取函数调用、类继承关系，再结合语义分析理解代码意图。
1代码仓库 → 静态分析 → 提取函数/类/模块关系 → 生成知识图谱
它只做代码相关的图谱，不处理业务文档。AI 编程助手顺着图谱理解项目结构，回答准确度提升很明显。
局限：
- 不处理业务文档
- 主流语言（Python、TypeScript、Go）支持没问题，小众语言需要自己写解析器
- 大项目图谱构建时间不短，建议用增量构建
适合大项目需要 AI 辅助开发和代码导航的场景。
对比
| 维度 | gbrain | GraphRAG | LLM Wiki | Graphify |
|---|---|---|---|---|
| 部署难度 | 中（需要 Postgres） | 高（需要 LLM 索引） | 低（纯 Markdown） | 中（需要代码分析） |
| 图谱构建 | 手动 + Agent | 自动从文档提取 | LLM 增量维护 | 自动从代码提取 |
| 检索能力 | Agent 记忆查询 | 全局图谱检索 | 语义检索 | 结构导航 |
| 更新频率 | 实时 | 低（需重建索引） | 实时 | 按需 |
| 可观测性 | Git 版本历史 | 图谱可视化 | 文件 diff | 图谱可视化 |
| 适用规模 | 中小 | 大 | 小 | 中大 |
选型
- 要 Agent 跨对话记忆：gbrain
- 要文档全局检索：GraphRAG
- 要轻量个人知识库：LLM Wiki
- 要代码理解：Graphify
四个方案定位完全不同，不存在谁替代谁的问题。关键是厘清需求——是记忆持久化，还是文档全局检索，或是代码导航——然后对号入座即可。