CodeGraph，我的三个助手共用一个索引文件，这才是它真正值钱的地方- 大数跨境

首页

CodeGraph，我的三个助手共用一个索引文件，这才是它真正值钱的地方

AI驱动数字化转型

2026-10-31

导读：外面有人把这件事说得更直白：省不省钱不取决于你装没装，取决于你的编排有没有真的走图。还有个团队的实测结论是反的，ManoMano 的 Project AEGIS 拿重工具跑快速探索，结果比朴素方式贵

今天下午，我的代码仓库根目录上多了一个文件夹，叫 .codegraph，里头只有一个 SQLite 文件，19.45MB。

它不是备份，也不是日志。它把这个仓库拆成一张图存了下来：329 个源文件，6786 个符号，16151 条关系。函数、方法、类、常量、导入是节点，谁调用谁、谁引用谁、谁继承谁是边。

我这边有三个助手在同一个仓库上干活。从今天起，它们读的是这同一个文件。

文章想说清三件事：这张图是怎么算出来的，为什么它必须落成一个文件而不是一个服务，以及这笔账到底省在哪儿。

PART 01

三个助手以前各自理解这个仓库

我搭的三个助手，活分得比较清楚。一个负责判断和写，一个负责跑杂活和调度，还有一个专管代码。跑杂活的那个叫 Hermes。

以前它们各自理解这个仓库。谁要改一个跨文件的接口，得自己翻一遍，翻出来的结论只活在它自己的上下文里。另一个要用，要么重新翻一遍，要么由我把结论转述给它。

转述这一步是有损的。我说“这个方法有 61 个调用者”，它听到的是一句话，不是一个可以继续往下问的结构。它接着问“那 61 个里哪几个在测试里”，我还得再翻一遍，再把答案转述一次。两次转述之后，最初那个判断已经薄得只剩一个数字。

三个助手，同一个仓库，三份彼此不通的理解。这是多体协作里最贵的一笔开销，而且它不出现在任何账单上。

PART 02

这张图是算出来的，不是想出来的

三体共用能成立，前提是这张图本身不依赖任何活着的东西。它的生产链条很短，一步接一步，中间不停。

tree-sitter 把源码解析成抽象语法树。从语法树里抽出节点和边，节点是函数、方法、类、变量、常量、导入，边是调用、引用、继承、导入。抽完存进本地 SQLite，再挂一层全文检索。

我这儿的实际分布是：函数 2212 个，变量 1973 个，导入 1596 条，方法 546 个，类 94 个，常量 37 个，加起来 6786 个节点，16151 条边，落成 19.45MB。

这个体积换成图片，大概两三张手机照片。换成代码，它装下了这个仓库的全部结构关系。

有三个数字是零：零模型调用，零网络请求，零 API key。整个建索引的过程没有一次推理，它只是把代码里的关系按语法算出来，算完就完。这一点决定了它后面能被几个助手同时读，因为一个不依赖模型的东西，也就不依赖哪个模型先启动。

这条技术路线不新。Aider 在 2023 年就用 tree-sitter 抽符号，再用 PageRank 排一遍序，把结果压进 1024 个 token 的预算里，让模型一眼看到仓库骨架。那是排好序的目录，只能看，不能问。Cursor 走另一条，切块、算向量、存进云端向量库，用相似度找代码。Claude Code 选了最省事的一边，干脆不索引，让模型自己 grep。

四种做法四种脾气。排目录的轻，但只能看不能问。向量库能问“哪些代码像这个”，却答不了“谁在调用它”，因为相似不是连接，那里没有边可以走。不索引的最灵活，代价是每一轮都要重新找。

图是第四种。它不排目录，也不算相似度，只干一件事：把“谁连着谁”抄下来。

PART 03

为什么它必须是一个文件，不是一个服务

它和另外两条路线最深的差别，不在查得多准，在它凭什么存在。

语言服务器那条线，Serena 是代表。能力比静态图精准，能做跨文件重命名，能追类型继承和类型收窄，但它要求每种语言装一个语言服务器，每次查询都去问一遍那个活着的服务。服务不在，能力就不在。放到多体协作里就麻烦了：三个助手都得连上同一个服务，或者各起一个，而各起一个就又变成三份状态，共用从一开始就散了。

向量库那条线，索引在云上，没连上就等于没有。而且它给的是“相似的块”，不是“连接的关系”，本来就是两种东西。

图索引这条路的落地形态最土，就是一个文件。

土在哪儿，我列一下这边的事实。这个命令行工具只装在 Hermes 的运行环境里，就是它目录下的那个 codegraph.cmd。索引文件却落在代码仓库根目录的 .codegraph 下面。一个在 C 盘，一个在 D 盘，两样东西根本不在同一处。

它不是一个跑着的服务。没有端口，没有进程状态，没有谁必须先启动，也没有谁挂了要重连。它就是一坨文件，谁都能读，拷到别的机器上照样能用。

所以三个助手不需要各自建一份索引，也不需要互相转述结构判断。

这里得把“共用”说准一点，不然容易想成共享上下文。它们不共享上下文，共享的是数据源。谁要问结构，谁就调一次命令行，命令行去读那同一个文件。三个不同的脑子，读的是同一份底稿。

共享一份结构判断，比共享一份结论要结实得多。结论是死的，图是可以继续往下问的。

PART 04

到底省在哪儿

省在哪儿这件事得分开算，不然容易算成宣传单。

重复理解这笔，是图自己挣的。还是那个问题：register 这个方法谁在调用，改签名会碰坏什么。

grep 全仓跑一遍，236 行命中，22363 个字符，散在 75 个文件里。但这 236 行只是“哪一行出现过这个词”，不告诉你哪个是真调用，哪个是定义，哪个是测试里的桩，哪个是注释里提了一句。要判断谁真的在调，得把这 75 个文件读一遍，651902 个字符。

图这边一次调用，1.8 秒，22475 个字符，直接给出结论：register 在 atomicbase.py 有 61 个调用者，分布在 agentruntime.py、两个 verify 脚本、task-state 等 47 个文件里，另有 13 个测试文件覆盖这条链路。

651902 对 22475，差 29 倍。

共用加的是另一层，它不体现为“少问几次”。三个助手谁要问结构，谁就自己去问，问出来的是同一份。以前它们各翻各的，翻完各记各的；现在翻的是同一张图，结论天生同源。

转述衰减这笔不容易看见。以前一个助手想问已经有人问过的事，只有两条路：重翻一遍，或者听我转述。重翻太贵，651902 个字符，于是大家都选转述。转述拿到的是一句话，不是结构，往下问第三层就断了。现在重问一次只要 22475 个字符，转述这条链自己就断了。

一致性风险这笔最隐蔽。三个人看同一个仓库，最怕的不是看得慢，是看出三个版本。一个说 61 个调用者，另一个说 40 个，第三个说要回去查一下，然后我花半小时判断谁对。共用一份索引之后，这种分叉在物理上就不可能发生，因为只有一份数据可读，没有第二份可以分叉。

共用不等于免费。三个助手各自去问，输出 token 还是各付各的。而且单点问题上，图比 grep 贵得多：我问 IterationBudget 定义在哪、谁在读，grep 一遍 8 行 616 个字符，两个文件，一步定位；同一个问题丢给图，回来 28973 个字符，命中 63 个符号跨 5 个文件。贵 47 倍。

这不是它坏了，是我问错了。一个点位问题，grep 本来就是最利的刀，拿图去问等于用吊车搬一只杯子。

所以这笔账得记两笔：图省的是翻的趟数，共用省的是每人一份。混成一个百分比，就说不清哪笔是谁挣的。

问题里带“谁”和“影响”，图划算。问“这个常量在哪”“这个函数叫什么”，grep 划算，且快得多。中间那条线不好一刀切，有个粗暴判据：你要的东西是不是单点。单点走 grep，成片走图。

PART 05

我在门口立的几条规矩

能力接进来之后，我在入口加了三道限制，都不是技术限制，是判断限制。

问题短于 6 个字符不跑。前面那个 47 倍就是理由。
返回超过 6000 字符就截断，全文落盘，对话里只留前面一段加一个文件路径。这条是被逼出来的。图检索返回的是稠密材料，一次给你几万字原文，看着很爽，可它会长久占着上下文。厂商自己的基准里有个数字很能说明问题：七个仓库平均下来，用完之后的上下文残留是 +82%。意思是省下的调用轮次，一部分又还回去了。
第三条最要紧：索引不存在的时候，直接报“没有索引，请先建”，绝不悄悄退回 grep。

这条听着像洁癖，其实是防自欺。一旦静默兜底，你会以为自己在走图，实际还在翻文件，账算得漂漂亮亮，路子一步没变。这条对三体共用还多一层意思：如果某一个助手偷偷退回了 grep，它拿到的判断就不再和另外两个同源，共用就成了假象。

外面有人把这件事说得更直白：省不省钱不取决于你装没装，取决于你的编排有没有真的走图。还有个团队的实测结论是反的，ManoMano 的 Project AEGIS 拿重工具跑快速探索，结果比朴素方式贵 4 倍、慢 60%。

工具本身不产生收益，位置对才产生收益。

PART 06

它答不了什么

短板得摆出来，不然就成了替厂商写软文。

概念搜索它做不了。你问“找一下校验逻辑在哪”，它不会命中那些没写“校验”两个字的代码。它不碰向量，也不碰模型摘要，换来的确定性和零成本，代价就是不懂语义相似。
引用解析的深度不如活的语言服务器。别名、继承、类型收窄这些，活的服务能算准，静态图只能算到它看得见的那一层。
小项目不划算。一百多个文件的仓库，grep 本来就够便宜，再加一层索引是给自己找事。

工程上还有几个坑。默认的数据库绑定装不上时会退回 WASM，慢 5 到 10 倍；索引写入期间读会撞上数据库锁，这是三个助手高频共用时唯一需要提前验证的风险；.gitignore 是它判断范围的唯一依据，你把 vendor 或者 dist 提交进仓库，它照样老实索引进去，白白撑大。

还有一件必须说清楚：厂商的基准有好几套口径。我查到的是七个真实项目平均，便宜 16%、工具调用少 58%、token 少 47%、快 22%，其中 VS Code 那个一万文件的库，工具调用少 81%、token 少 64%。另外一些页面写的是 92% 和 71%，还有 94% 和 77%。这些数字来自不同版本、不同基数、不同时间点，当方向看可以，当承诺看会失望，而且都是厂商自测，没有第三方复现。

这类数字我现在的用法是：只用来判断“值不值得试”，不用来写“能省多少”。

陈旧是静态索引最容易被质疑的一点，代码天天改，这张图什么时候过期。

它靠操作系统的文件变更事件做增量同步，改哪个文件就重算哪个文件，不用整仓重扫。这一点对三体共用尤其要紧，几个助手改代码的时间不一样，要是谁都得等一次全量重建，共用就成了负担。厂商在 1.5.0 把解析引擎换成 Rust 之后，单文件解析从 24.4 毫秒降到 6.9 毫秒，Linux 内核那种 7 万文件、200 万符号、640 万关系的仓库，全量从 26 分钟压到 12 分钟以内。这个量级的意思是，重建一次不再是“要不要等”的问题，而是“顺手做掉”的问题。

那 20MB 里没有一个字的答案。它只是把谁连着谁抄了下来，抄得足够全，全到可以问。

三个助手读同一份。省下来最要紧的不是 token，是我们不用各自猜一遍，我也不用坐在中间，把一个人的判断翻译给另一个人听。

同一份底稿，读出来不会是三个版本。

【声明】内容源于网络

AI驱动数字化转型

专注AI，促进智造行业数据衍生，服务智能制造企业的数字化、智能化，聚焦大模型私域部署、大模型微调、数据清洗、AI模型训练、私域知识库及agent技术延展等。行业智能，落地为先。

内容 1114

粉丝 1

AI驱动数字化转型专注AI，促进智造行业数据衍生，服务智能制造企业的数字化、智能化，聚焦大模型私域部署、大模型微调、数据清洗、AI模型训练、私域知识库及agent技术延展等。行业智能，落地为先。

总阅读14.7k

粉丝1

内容1.1k