AI Jason · 8:30 · 发布 2026-06-30 · 478次观看(截至抓取) · 观看原视频
主旨
用一个纯程序化(无 LLM)的 codebase memory MCP 把代码库抽成函数/类的关系图谱,让编码 agent 靠图谱定位依赖而非逐个 grep+读文件,从而看清改动影响面并把 token 消耗砍掉近一半。
核心论点
- 代码库本身就是一张图,agent 却把它读成扁平文本——每个 import、每次函数调用都是一条边,丢掉这层结构就得靠盲搜。(→ 详解1)
- 该工具用 C/C++ 纯程序化建图,不走 LLM 管线,所以快(Linux 内核 3 分钟、常规库几秒)且不会像 LLM 生成的知识图那样很快过期。(→ 详解2)
- 默认工作流的真实成本是 context 爆炸:grep 出一堆文件→逐个读→每次读都把整个大文件灌进上下文窗口。(→ 详解3)
- 图谱可跨文件、跨 repo 建立,把散落各处的函数/类/消息连成一张大图,解决多 repo 依赖难题。(→ 详解4)
- agent 拿到的是一组图查询工具(get architecture / search graph / trace path / query),快速拿全貌而不加载成千行代码。(→ 详解5)
- 真正的设计突破是 pre-tool-use hook:即便 agent 忘了用图搜、只发了普通 grep,hook 也会把图谱信息塞进 grep 结果,不依赖 agent 主动调 MCP。(→ 详解6)
- 实测 token 对半降:同一问题用图谱 11k、不用 38k;追问改动影响时 33k vs 64k。(→ 详解7)
知识点详解
1. 代码库是图,不是扁平文本 00:17
作者的出发点:你让编码 agent 在大代码库里改点东西,它会 grep 出一墙匹配、逐个打开二十个文件,还是漏掉一半可能被牵连的地方。
根因是 agent 把代码当成一段扁平文本在读。可代码库天然是有结构的——每个 import、每次函数调用都是一条边,是一张现成的依赖图。把这层结构丢掉,就只剩下字符串盲搜。
作者的思路是把代码库变成 agent 能沿着走的地图,这样每次 PR 审查都能看清改动的影响面,顺带省下大量 token。
2. C/C++ 纯程序化建图,不走 LLM 01:05
工具叫 codebase memory MCP。作者也承认这类”代码库索引/检索”MCP 过去几个月出了一大堆,但没一个做得特别好:要么用 LLM 管线生成知识图、很快就过期,要么塞不进编码 agent 的实际工作流。
这个项目的差异点在实现:主体用 C/C++ 写,号称是给编码 agent 用的最快、最省的代码情报引擎。Linux 内核这种巨型项目 3 分钟能索引完,常规中小库几秒出图。
关键是整个建图不涉及大语言模型、纯程序化,所以既快又不会像 LLM 生成的图那样漂移过期。这条是它区别于同类的核心卖点。
3. 默认工作流的成本是 context 爆炸 01:44
它要解决的是老问题:在大代码库(尤其 monorepo)里问 agent”某函数在哪些地方被用”,默认工具链会从一次 grep 开始,返回一堆文件。
然后 agent 顺着这些文件一个个读来拼全貌。但每读一个文件,就把一整个大代码文件灌进上下文窗口,很容易就撑爆——这正是 上下文腐化 的触发方式。
Claude Code 虽有 subagent 帮忙隔离这类搜索任务的上下文,但作者说那样很慢。代码库越大问题越严重,生产环境往往不止一个 repo,跨 repo 理清依赖一直是难事。
4. 跨文件、跨 repo 的关系图谱 02:12
工具的做法:从代码里抽出根函数、消息、类,建成一张关系图,让 agent 不用加载成千行代码就能快速理解某个文件是干什么的。
这种关系能跨文件建。三个文件里的所有函数/类/消息都抽出来,连成一张跨文件图;同一流程套到所有文件上,就长成一张覆盖整个代码库、甚至跨 repo 的大图。
因为全程没有 LLM 参与、纯程序化,这个过程非常快。agent 最终拿到的,是一套能更快看清全貌的工具,而不是一堆待读的原始文件。
5. 给 agent 的一组图查询工具 02:50
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
作者认为这个项目比同类有用得多的关键,是用了 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
作者用同一个 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 一开始就少加载文件,从源头压低上下文用量,两者互补而非冲突。
- 复现: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 注入的工具设计范式。
自检问题
- 为什么默认的”grep + 逐个读文件”工作流会烧掉大量 token? 答案:因为每读一个文件就把整个大代码文件灌进上下文窗口,很容易撑爆,这也是 Context Rot 的触发方式。见详解3。01:44
- 这个工具凭什么比过去一堆同类”代码库索引”MCP 更快、更不易过期? 答案:主体用 C/C++、纯程序化建图,不走 LLM 管线,所以既快(内核 3 分钟)又不会像 LLM 生成的知识图那样漂移过期。见详解2。01:05
- 作者认为本项目最关键的设计突破是什么?为什么重要? 答案:pre-tool-use hook——即便 agent 忘了调图搜、只发普通 grep,hook 也会把图谱信息塞进 grep 结果,不赌 agent 主动调专用 MCP 工具。见详解6。03:59
- 用/不用图谱,token 消耗差多少?这个数字该怎么看待? 答案:同一问题 11k vs 38k,追问影响面时 33k vs 64k(翻倍);但属作者单机演示、非独立复现,当方向性证据看。见详解7。07:28
- 这套图谱能力和 Context Rot 的既有对策是什么关系? 答案:互补。Context Rot 既有对策治标于消费端(主动清理/拆会话),本片从源头减少文件加载,压低上下文用量,叠加使用。见关联节。
💬 热门评论 top-15 主 + 5 回(抓取 2026-07-07)
[6] @rodericksasu6976:我建过类似的东西，但我不是纯粹用图。 [7] @JaspervanHarten-i3y:这和 Graphify 有什么不同？请解释一下 :) 👍 14 ↪ @DarkIce-v1p:Graphify 没有 MCP，你必须手动运行命令，这效率不高。 👍 2 ↪ @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 已略
英文原文
[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
↪ @Khaled_fate:git nexus
[2] @blahblahlesslab:I think Graphify may help here a lot... ? Just guessing, but my Ai "harness" agrees with my guess. :) 👍 4
[3] @gllucis:was waiting for something like this for over 2 years now.. yes, before MCP - it's the concept 👍 1
[4] @after1001:"it's like providing a GPS map to your agent" = written by LLM.
[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
↪ @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
[6] @rodericksasu6976:I have built something similar but I don't purely use a graph.
[7] @JaspervanHarten-i3y:How is this different from graphify for example? Please explain :) 👍 14
↪ @DarkIce-v1p:Graphify doesn't have a mcp and you have to manually run commands and thats not efficient. 👍 2
↪ @sanathkumaru6358:this works😅 👍 1
[8] @oohlala5394:Thanks
[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.
[10] @abduldoesmusic:change your name to AI Json! 👍 6
↪ @AIJasonZ(UP):lol 👍 1
[11] @YourAI_agent:Codegraph mcp is also same
[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
[13] @romainbey:Great tool
[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.
[15] @Alexrmacleod:wont cursor just integrate this into their agent app soon if this is really that good.