---
title: '给编码 agent 一张代码库地图:codebase memory MCP'
video_id: iWRmtPdFbGw
url: https://youtu.be/iWRmtPdFbGw
title_en: "I was giving my coding agent context the wrong way..."
channel: AI Jason
published: 2026-06-30
duration: "8:30"
topics: [MCP 与工具调用, Agent 工程, Claude Code 定制扩展]
noted: 2026-07-05
value: A
views: '478'
---


[![封面](https://i.ytimg.com/vi/iWRmtPdFbGw/maxresdefault.jpg)](https://youtu.be/iWRmtPdFbGw)

> AI Jason · 8:30 · 发布 2026-06-30 · 478次观看(截至抓取) · [观看原视频](https://youtu.be/iWRmtPdFbGw)

## 主旨

用一个纯程序化(无 LLM)的 codebase memory MCP 把代码库抽成函数/类的关系图谱,让编码 agent 靠图谱定位依赖而非逐个 grep+读文件,从而看清改动影响面并把 token 消耗砍掉近一半。

## 核心论点

1. **代码库本身就是一张图,agent 却把它读成扁平文本**——每个 import、每次函数调用都是一条边,丢掉这层结构就得靠盲搜。([[#1-代码库是图不是扁平文本-0017|→ 详解1]])
2. **该工具用 C/C++ 纯程序化建图,不走 LLM 管线**,所以快(Linux 内核 3 分钟、常规库几秒)且不会像 LLM 生成的知识图那样很快过期。([[#2-cc-纯程序化建图不走-llm-0105|→ 详解2]])
3. **默认工作流的真实成本是 context 爆炸**:grep 出一堆文件→逐个读→每次读都把整个大文件灌进上下文窗口。([[#3-默认工作流的成本是-context-爆炸-0144|→ 详解3]])
4. **图谱可跨文件、跨 repo 建立**,把散落各处的函数/类/消息连成一张大图,解决多 repo 依赖难题。([[#4-跨文件跨-repo-的关系图谱-0212|→ 详解4]])
5. **agent 拿到的是一组图查询工具**(get architecture / search graph / trace path / query),快速拿全貌而不加载成千行代码。([[#5-给-agent-的一组图查询工具-0250|→ 详解5]])
6. **真正的设计突破是 pre-tool-use hook**:即便 agent 忘了用图搜、只发了普通 grep,hook 也会把图谱信息塞进 grep 结果,不依赖 agent 主动调 MCP。([[#6-pre-tool-use-hook-才是设计突破-0359|→ 详解6]])
7. **实测 token 对半降**:同一问题用图谱 11k、不用 38k;追问改动影响时 33k vs 64k。([[#7-token-对半降的实测-0728|→ 详解7]])

## 知识点详解

### 1. 代码库是图,不是扁平文本 [00:17](https://youtu.be/iWRmtPdFbGw?t=17)

作者的出发点:你让编码 agent 在大代码库里改点东西,它会 grep 出一墙匹配、逐个打开二十个文件,还是漏掉一半可能被牵连的地方。

根因是 agent 把代码当成一段扁平文本在读。可代码库天然是有结构的——每个 import、每次函数调用都是一条边,是一张现成的依赖图。把这层结构丢掉,就只剩下字符串盲搜。

作者的思路是把代码库变成 agent 能沿着走的地图,这样每次 PR 审查都能看清改动的影响面,顺带省下大量 token。

### 2. C/C++ 纯程序化建图,不走 LLM [01:05](https://youtu.be/iWRmtPdFbGw?t=65)

工具叫 codebase memory MCP。作者也承认这类"代码库索引/检索"MCP 过去几个月出了一大堆,但没一个做得特别好:要么用 LLM 管线生成知识图、很快就过期,要么塞不进编码 agent 的实际工作流。

这个项目的差异点在实现:主体用 C/C++ 写,号称是给编码 agent 用的最快、最省的代码情报引擎。Linux 内核这种巨型项目 3 分钟能索引完,常规中小库几秒出图。

关键是整个建图**不涉及大语言模型、纯程序化**,所以既快又不会像 LLM 生成的图那样漂移过期。这条是它区别于同类的核心卖点。

### 3. 默认工作流的成本是 context 爆炸 [01:44](https://youtu.be/iWRmtPdFbGw?t=104)

它要解决的是老问题:在大代码库(尤其 monorepo)里问 agent"某函数在哪些地方被用",默认工具链会从一次 grep 开始,返回一堆文件。

然后 agent 顺着这些文件一个个读来拼全貌。但每读一个文件,就把一整个大代码文件灌进上下文窗口,很容易就撑爆——这正是 [[Context Rot|上下文腐化]] 的触发方式。

Claude Code 虽有 subagent 帮忙隔离这类搜索任务的上下文,但作者说那样很慢。代码库越大问题越严重,生产环境往往不止一个 repo,跨 repo 理清依赖一直是难事。

### 4. 跨文件、跨 repo 的关系图谱 [02:12](https://youtu.be/iWRmtPdFbGw?t=132)

工具的做法:从代码里抽出根函数、消息、类,建成一张关系图,让 agent 不用加载成千行代码就能快速理解某个文件是干什么的。

这种关系能跨文件建。三个文件里的所有函数/类/消息都抽出来,连成一张跨文件图;同一流程套到所有文件上,就长成一张覆盖整个代码库、甚至跨 repo 的大图。

因为全程没有 LLM 参与、纯程序化,这个过程非常快。agent 最终拿到的,是一套能更快看清全貌的工具,而不是一堆待读的原始文件。

### 5. 给 agent 的一组图查询工具 [02:50](https://youtu.be/iWRmtPdFbGw?t=170)

agent 拿到的是几个具体工具。get architecture 返回代码库架构总览,让 agent 一眼看懂整体结构;要改某个函数时,用 search graph 定位到这个函数的节点。

再用 trace path 把调用链铺开,搞清这个函数在哪被用、会牵连到什么。还能直接对图跑 query,拿到平时很难查的信息——比如"所有调用 handle order 的文件里,哪些还没有测试覆盖"。

此外能取某函数的代码片段,以及在 PR 审查时 detect change,直观看到本次改动对架构的冲击。作者用 Superdesign 的 canvas lock 举例:一个藏在多层委托之下、grep "lock" 根本找不到的隐藏保护,图谱能 trace 出完整流程,并回答"改它会 break 什么"。

### 6. pre-tool-use hook 才是设计突破 [03:59](https://youtu.be/iWRmtPdFbGw?t=239)

作者认为这个项目比同类有用得多的关键,是用了 hook。过去很多项目失败,是因为 agent 会犯迷糊:给了它专门的图搜/记忆搜工具,它却不知道何时该用图搜、何时用普通 grep,而各家(Claude Code、Codex)又都在拼命优化自己的 grep。

这个项目承认了这一点,改用 pre-tool-use hook。就算 agent 忘了调图搜、只发普通 grep,grep 照常返回;但与此同时,hook 会捕获这次调用,把图谱里的丰富信息作为 grep 结果的一部分一并塞回去。

于是它不再依赖 agent 每次都主动调那个特殊 MCP 工具。作者说这是比多数 MCP 都更好的设计范式,并建议做 MCP 的人都去用 Claude Code / Codex 的 hook 这么干——这是本片对"怎么设计好 MCP"最有迁移价值的一条。

### 7. token 对半降的实测 [07:28](https://youtu.be/iWRmtPdFbGw?t=448)

作者用同一个 prompt 开两个会话对比:一个用 codebase memory MCP,一个明确"不要用"。第一个问题(trace 某流程),用图谱的 message 部分约 11,000 token,不用的约 38,000。

追问"改这个 lock 会 break 什么",用图谱跑了 1 分钟、成功识别全部 13 处调用点,累计约 33,000 token;不用的那个是 64,000,整整翻倍。

数字是作者单机演示、非独立复现,但方向与机制一致:省的是"逐个读大文件灌上下文"那部分。安装有基础版和带图形界面(`--UI`)两种命令;作者已把这个 MCP 并进他的 set-up-codebase-harness skill,开源可自取。

## 可执行步骤

- [ ] 在大代码库/monorepo 里装一个代码库图谱类 MCP,让 agent 用"图查询"替代"grep + 逐个读文件"。
- [ ] 优先选纯程序化(非 LLM 生成)的建图方案,避免知识图很快过期。
- [ ] 用它的 trace / query 能力在 PR 审查前先问"改这个函数会 break 什么",把影响面显式列出来再动手。
- [ ] 如果你自己做 MCP:用 pre-tool-use hook 把增强信息注入 agent 本来就会调的原生工具(如 grep),别指望 agent 主动记得调你的专用工具。
- [ ] 改动前后对比 `/context` 占用,验证图谱方案是否真的压住了上下文膨胀。

## 关联

- 印证:[[Context Rot]]——本片给出的"grep→逐个读大文件→灌爆上下文窗口"正是 Context Rot 的一种触发路径。既有笔记的对策集中在"主动清理/拆会话"(治标于消费端),本片提供的是消费端之前的一层:用关系图谱让 agent 一开始就少加载文件,从源头压低上下文用量,两者互补而非冲突。
- 复现:[[2026-07-09-AI创业热议速评：从婴儿App到一人团队|AI创业热议速评：从婴儿App到一人团队]] 提到用 Blast Radius 判断改动是否值得自动化,是本片"改动波及范围"定义在创业决策场景下的具体应用。

## 术语

- codebase memory MCP(代码库记忆 MCP:把代码库抽成关系图供编码 agent 查询的工具,本片主角)
- blast radius(影响面/爆炸半径:一处改动可能波及、可能弄坏的所有位置)
- trace path(链路追踪:沿调用图铺开某函数的上下游调用链)
- pre-tool-use hook(工具调用前钩子:在 agent 执行某工具前拦截并增强其输入/结果的机制)
- monorepo(单体仓库:多个项目/模块共处一个代码仓)

## 金句

> Your code base is already a map. Every import, every function call is an edge. Your agent just throw that structure away and reads it as a flat text.
> → 一句话点出问题本质:结构是现成的,是 agent 把它读丢了。这也是所有"代码库索引"工具的共同起点。

> It didn't really rely on agent to always call the special MCP tool.
> → 本片最值得迁移的设计观:好 MCP 不赌 agent 的自觉,而是挂在它必然会走的路径上。

## 立场与利益

作者 AI Jason 与内容有直接利益关系:他把这个 MCP 并进了自己维护的 set-up-codebase-harness skill(属于他的 AI Builder Club / loop engineer 体系),视频末尾引导去搜"GitHub AI Builder Club skill"并进其 repo,description 附有链接。因此"这个工具最好"的整体判断带推广色彩。

但可与推广剥离、站得住的部分:代码库=图这个前提,grep 逐读灌爆上下文的机制,以及 pre-tool-use hook 注入增强信息这一设计范式——都是不依赖买他任何东西即成立的通用工程主张。token 数字是单机演示、非独立复现,当作方向性证据而非精确基准。

## 价值定位

- 适合谁:在中大型代码库(尤其 monorepo/多 repo)里重度使用 Claude Code / Codex 类编码 agent、且明显感到"改一处不知道会牵连哪里"或 token 烧得快的人。
- 解决什么:想让 agent 在改动前看清影响面、并压低上下文膨胀,本片给了"用关系图谱替代 grep+逐读"这条具体路径。
- 认知 vs 实操:偏认知框架 + 一个可试的工具指路。真正的高价值可迁移点不是这个具体 MCP,而是第 6 节的 pre-tool-use hook 增强范式——对任何做 MCP/工具集成的人都适用。
- 与 [[Context Rot]] 重叠:都在谈上下文膨胀,但本片独有"在消费端之前用代码库图谱从源头减少文件加载"这一层,以及 hook 注入的工具设计范式。

## 自检问题

1. 为什么默认的"grep + 逐个读文件"工作流会烧掉大量 token?
   **答案**:因为每读一个文件就把整个大代码文件灌进上下文窗口,很容易撑爆,这也是 Context Rot 的触发方式。见详解3。[01:44](https://youtu.be/iWRmtPdFbGw?t=104)
2. 这个工具凭什么比过去一堆同类"代码库索引"MCP 更快、更不易过期?
   **答案**:主体用 C/C++、纯程序化建图,不走 LLM 管线,所以既快(内核 3 分钟)又不会像 LLM 生成的知识图那样漂移过期。见详解2。[01:05](https://youtu.be/iWRmtPdFbGw?t=65)
3. 作者认为本项目最关键的设计突破是什么?为什么重要?
   **答案**:pre-tool-use hook——即便 agent 忘了调图搜、只发普通 grep,hook 也会把图谱信息塞进 grep 结果,不赌 agent 主动调专用 MCP 工具。见详解6。[03:59](https://youtu.be/iWRmtPdFbGw?t=239)
4. 用/不用图谱,token 消耗差多少?这个数字该怎么看待?
   **答案**:同一问题 11k vs 38k,追问影响面时 33k vs 64k(翻倍);但属作者单机演示、非独立复现,当方向性证据看。见详解7。[07:28](https://youtu.be/iWRmtPdFbGw?t=448)
5. 这套图谱能力和 [[Context Rot]] 的既有对策是什么关系?
   **答案**:互补。Context Rot 既有对策治标于消费端(主动清理/拆会话),本片从源头减少文件加载,压低上下文用量,叠加使用。见关联节。

> [!quote] 💬 热门评论 top-15 主 + 5 回(抓取 2026-07-07)
> 
> [6] **@rodericksasu6976**:我建过类似的东西，但我不是纯粹用图。
> [7] **@JaspervanHarten-i3y**:这和 Graphify 有什么不同？请解释一下 :) 👍 14
> &nbsp;&nbsp;↪ **@DarkIce-v1p**:Graphify 没有 MCP，你必须手动运行命令，这效率不高。 👍 2
> &nbsp;&nbsp;↪ **@sanathkumaru6358**:这居然有效😅 👍 1
> [9] **@HumanoAI**:CallGraph 应该消耗更少的字符来描述脚本或函数及其输入/输出期望；并且有跳过机制以避免加载整个文件或函数。
> [11] **@YourAI_agent**:Codegraph mcp 也是一样的
> [12] **@steveharmancambridge**:Jason 视频很棒。有一点我没看到的是这个 MCP 如何保持其记忆更新。它是否依赖手动索引步骤来随着代码变化更新其记忆/图？谢谢
> [14] **@seanolivas9148**:如果你能让它通过同行评审，我就安装。我想相信你，但到目前为止，所有这些都导致更多 token 而不是更少。
> ——其他 8 条:感谢/夸赞([2]@blahblahlesslab、[3]@gllucis、[4]@after1001、[5]@anhngocle738、[8]@oohlala5394、[10]@abduldoesmusic、[13]@romainbey、[15]@Alexrmacleod);1 条 spam 已略
> <details><summary>英文原文</summary>[1] @AIJasonZ(UP):- My Github repo Skill for setup Codebase harness: https://github.com/AI-Builder-Club/skills - Join AI Builder Club for step-by-step walk through: https://www.aibuilderclub.com/lp/loop-engineer - Try Superdesign: http://superdesign.dev/ - Follow me on twitter: https://twitter.com/jasonzhou1993<br>&nbsp;&nbsp;↪ @Khaled_fate:git nexus<br>[2] @blahblahlesslab:I think Graphify may help here a lot... ? Just guessing, but my Ai "harness" agrees with my guess. :) 👍 4<br>[3] @gllucis:was waiting for something like this for over 2 years now.. yes, before MCP - it's the concept 👍 1<br>[4] @after1001:"it's like providing a GPS map to your agent" = written by LLM.<br>[5] @anhngocle738:Your slides are incredible! I'm guessing they were created using AI, but the quality is absolutely top-notch. Would you mind sharing a video tutorial on how you made them? 👍 7<br>&nbsp;&nbsp;↪ @AIJasonZ(UP):yep it is a skill I’ve been using for myself hah; I will try to share a version (maybe make a video tutorial too!) 👍 10<br>[6] @rodericksasu6976:I have built something similar but I don't purely use a graph.<br>[7] @JaspervanHarten-i3y:How is this different from graphify for example? Please explain :) 👍 14<br>&nbsp;&nbsp;↪ @DarkIce-v1p:Graphify doesn't have a mcp and you have to manually run commands and thats not efficient. 👍 2<br>&nbsp;&nbsp;↪ @sanathkumaru6358:this works😅 👍 1<br>[8] @oohlala5394:Thanks<br>[9] @HumanoAI:CallGraph must consume less characters in describing a script or function and its in/out expectations; and have a skip mechanism to avoid loading entire files or functions.<br>[10] @abduldoesmusic:change your name to AI Json! 👍 6<br>&nbsp;&nbsp;↪ @AIJasonZ(UP):lol 👍 1<br>[11] @YourAI_agent:Codegraph mcp is also same<br>[12] @steveharmancambridge:Great video Jason.  One thing I didn't see was how this MCP keeps its memory updated.    Does it rely on a manual indexing step to keep its memory / graph up to date as code changes over time?  Thanks<br>[13] @romainbey:Great tool<br>[14] @seanolivas9148:If you get this peer reviewed I will install. I want to believe you but so far all of these caused more tokens not less thus far.<br>[15] @Alexrmacleod:wont cursor just integrate this into their agent app soon if this is really that good.</details>