你打开Claude Code，朝它问了一个关于整个仓库的问题。接下来，它就像刚入职的工程师一样，先grep，再glob，打开一个文件读上800行，关上，再打开另一个……排查大半天，消耗的不只是Token，还有耐心。这个“发现循环”还会漏掉那些跨文件的隐性关联，而这些关联根本不会在文本搜索里跳出来。

代码库上下文工具正为这个而来。它提前把代码索引成可查询的结构——知识图谱、向量索引或虚拟文件系统，再通过MCP暴露给AI代理。代理带着精确问题去查，直接拿回对应代码段，用的Token少了，工具调用少了，第一轮回答的质量却上去了。

我们挑了其中两个开源的代码知识图谱工具，试试它们怎么把代码“看懂”。

正方观点：像CodeGraph这样的工具，把源码解析成符号和关系（调用、导入、继承），让代理能直接走图。一次codegraph_explore就能回答“X怎么工作”；codegraph_impact能在你改一个符号之前，先摸清影响范围。整个索引建在本地SQLite里，毫秒级响应，没有API开销。就连安装也做到了零配置——一行curl，自动识别Claude Code、Cursor、Codex CLI等代理，还为Django、FastAPI等框架做了路由感知。根据项目自己公布的数据，相比裸代理，成本降低了大约16%，工具调用少了58%。

反方观点：纯粹的结构索引，知道谁调了谁，却不知道代码为什么存在。它熟悉调用图，但不理解业务逻辑。一旦需求超出调用关系——比如“这段代码是干什么用的？”——它就答不上来。而且，对动态语言中runtime生成的调用，静态解析会漏掉。

再看一个更轻量的选项：CodeGraphContext（CGC）。它既是MCP server，也是独立的CLI，把本地代码索引到图数据库后，允许你用自然语言向代理提问，或者直接从终端查询。安装就一句pip install，向导式配置，适合想把索引直接接到现有工作流里、又不想改太多配置的团队。但同样，它停留在结构层，不会替你理解代码的设计意图。

我的判断：这些知识图谱工具，解决的是AI代理“在代码库里找东西”的效率问题，不是“理解代码”的问题。如果你的团队经常让AI处理跨文件重构、依赖分析、或者快速理解大型仓库的骨架，那么让代理先建个结构索引，绝对划算。但如果追求对业务逻辑的深层理解，它们还不够——你需要搭配语义搜索或嵌入索引，才能补上另一块拼图。好在它们都是开源的，你可以直接拿回去试试，先让代理告别“盲搜”。