给代码库建了张知识图谱：Token 费用少了三成，接新项目不再抓瞎

写在前面

几天前和一个做开发的朋友闲聊，他提到公司最近在做一套面向青少年的心理辅助 Agent，用于情绪疏导和危机干预，目前卡在知识库搭建上，打算用知识图谱给 AI 做诊断参考。

我以为知识图谱就是 RAG，然后被他上了一课。

回来之后按他的建议找了个开源工具，给自己的项目从头搭了一套本地知识图谱。用下来效果比预期好，于是整理成文章，重点说三件事：RAG 和知识图谱的区别、Graph RAG 是什么，以及搭完之后我自己的 3 个工作流变化。

RAG、知识图谱，到底哪里不一样

RAG 是什么

RAG 全称「检索增强生成」，核心思路是把大模型自身的参数记忆和外部检索内容结合起来，用检索结果辅助生成答案。

举个例子：你问 AI「北京烤鸭属于什么菜系」。正常情况下大模型直接调用训练时的参数作答，但如果训练数据里相关信息不准，回答质量就会打折扣。

用了 RAG 之后，系统先检索外部知识，把内容拼进 prompt：

{北京烤鸭是北京的著名美食。北京烤鸭属于京菜。北京烤鸭的主要食材是鸭肉。}
+ {北京烤鸭属于什么菜系？}

大模型相当于翻到了正确资料，精准找到「京菜」这个答案。

一个完整的 RAG 流程包含以下步骤：

原始资料
切分成 chunk
转成 embedding 向量
存进向量数据库
用户提问
检索相关 chunk
把 chunk 作为上下文交给大模型
大模型生成答案

顺带澄清一个常见误解：向量数据库不等于 RAG，它只是这条链路上的一个组件。这个坑我之前也踩过。

在实际运行中，chunk 是核心单元。一篇 10 页 PDF 会被切成很多块：

chunk 1：第1页第1段
chunk 2：第1页第2段
chunk 3：第2页第1段
...

每个 chunk 转成向量，用户问题也转成向量，再找出语义上最相近的那些 chunk 拼回 prompt 给大模型。

知识图谱：能做推理，不只是检索

知识图谱的思路完全不同。它不是把文档切碎去检索，而是把知识拆成「实体 + 关系」的三元组。

还是北京烤鸭的例子：

(北京烤鸭, 属于菜品类型, 北京菜)
(北京菜, 属于, 中国菜)
(北京烤鸭, 主要食材, 鸭肉)
(北京烤鸭, 烹饪方式, 烤制)
(鸭肉, 来源于, 鸭子)
(鸭子, 属于, 禽类)
(禽类, 属于, 动物)

这张图不只能回答「北京烤鸭属于什么菜」，还能处理 RAG 很难直接回答的推理型问题：「北京烤鸭的主要食材来自哪类动物？」

推理路径：北京烤鸭 → 鸭肉 → 鸭子 → 禽类 → 动物

它能沿关系链做多跳推理，不像 RAG 那样只在语义相似的文本块里找答案。

为什么这两个概念总被混淆

因为它们都叫「知识库」，目的也都是让大模型回答得更准。对 AI 来说，两者都是外部知识源。但路径不同：RAG 靠外部文本证据增强回答，知识图谱靠结构化关系约束推理。

Graph RAG：两者合在一起

Graph RAG 就是用图结构增强 RAG 的检索和推理，让大模型在回答前先理解实体关系，再结合文本证据生成答案。

代价是额外的工程量：既要维护知识图谱保证关系一致，又要搭 RAG，最后还要把接口整合上。企业级项目这么搞合理，个人搭本地知识库我不太推荐，性价比不高。

实操：用 CodeGraph 把代码项目转成本地知识图谱

我用下来最顺手的方式，是把大型代码项目提前索引成本地知识图谱，后续查询直接走图谱，不再每次全量扫文件。工具调用数量降了 94%，token 费用少了 35%。

我用的是开源项目 CodeGraph，完全本地化运行，满足隐私需求。实际上下面三步基本是 AI 帮我操作完的，我就发了一句话：「帮我安装 https://github.com/colbymchenry/codegraph」。

第一步：安装

npm i -g @colbymchenry/codegraph

# 验证安装：
codegraph version
# 输出：1.0.1

第二步：接入 AI 助手

CodeGraph 支持 Claude Code、Cursor、Codex CLI、Hermes Agent 等 8 种主流 AI 编程工具。我用的是 Hermes Agent，一条命令自动完成接入：

codegraph install --target hermes --location global --yes

它会自动在 ~/.hermes/config.yaml 里写入 MCP Server 配置，重启 Hermes 就好。

第三步：初始化项目

cd your-project
codegraph init

我这个做了挺久的检测系统，92 个文件，Python + Vue + YAML 混合，跑了一遍：

◆ Indexed 92 files
● 1,166 nodes, 2,141 edges in 1.3s
└ Done

1.3 秒建完。之后 CodeGraph 会自动监听文件变化，你或 AI 改的任何代码都会增量同步到图谱，不需要手动重建索引。

搭完之后，这 3 个工作习惯变了

一、AI 不再盲目 grep

以前让 AI 理解一个功能的完整流程，要来回 8 到 12 次 tool call，grep 这个、read 那个、再 grep、再 read，token 烧了一堆。说的就是你，Claude。

现在一次 codegraph_explore("how does video extraction work")，直接返回相关符号、调用链和源码位置。token 费用少了 35%，这是实测数据。

二、接新项目不再两天才能上手

以前接一个陌生项目，前两天基本全花在摸清代码结构上。让 AI 帮忙反而更费 token，项目越大这个问题越明显。

现在 codegraph init 一秒建完图，AI 汇总之后直接告诉我入口在哪、数据怎么流转、哪些模块是核心。从两天才能上手，变成几分钟就能开始写代码。

三、测试跑得更准了

之前给一个项目加功能，本地测试没发现问题，上线后中间某个步骤触发 bug，直接黑屏，修了半天。

有了图谱之后，codegraph affected 只跑真正受影响的测试，配合下面这条命令一步搞定：

git diff --name-only HEAD | codegraph affected --stdin

反馈从分钟级缩到秒级，覆盖率问题少了很多。

写在最后

我没有把标题写成「CodeGraph 使用教程」，因为工具本身不是重点，类似的开源方案还有不少，底层思路都是通用的。

这次对我真正有用的，是搞清楚了 RAG 和知识图谱的区别，以及什么场景该用哪个。代码库这种结构化程度高、关系复杂的场景，知识图谱比纯 RAG 好用，这是实际用下来的感受，不是理论推断。

如果你的 AI 助手也经常在项目里「迷路」，反复 grep、重复 read、理解偏差，可以试试先给它建一张地图。