这类工具不是骗局，但被营销严重注水。它真正解决的是"agent 在大代码库里靠现场翻找、烧 token"这个痛点——但 Claude Code 的作者本人公开说过，他们早期试过这条"预建索引"路线，最后放弃了，因为自主搜索更好、且没有"索引过期/不可靠"的毛病。
上一轮的结论是"先上 CodeGraph 试试"，这一轮掌握批判证据后要往回收：CodeGraph 是个半年新、一个人维护、49k star 但水分大的项目，最致命的是它在频繁改动的多语言仓里会"静默"把代码关系图搞错却不报警——而 Eosphor 恰好就是"多语言 + 快速迭代"。
若真要选一个，Serena 比 CodeGraph 更扎实（实时读代码不会腐化、社区更健康、还能真动手改代码），但它有自己的内存泄漏坑。最务实的选择可能是：先别急着上重型工具，把 Claude Code 自带能力用足，等真撞到"大型重构"这种硬需求时再针对性地挂 Serena。
用 Claude Code 这类 agent 改大项目的代码时，agent 默认靠"现场摸索"——grep 搜关键字、一个文件一个文件读。没有全局地图，每次都从零探，慢、烧 token。这一整个品类的工具，干的都是同一件事：提前或实时地把代码库的结构（谁调用谁、改这里炸哪里）整理好，让 agent 不用每次重新翻。
分歧只在"怎么整理"。有人提前把代码啃成一张图存起来（CodeGraph 走这条），有人挂上 IDE 那套语言服务器实时回答（Serena 走这条），还有人把代码切块算向量做语义检索（Cursor 内置那套）。这份报告就是把这三条路、和两个最火的开源主角，扒到营销稿底下去看。
先说一个会颠覆印象的事实。CodeGraph 的作者 Colby McHenry，不是什么 AI 大牛或知名开源人物。翻他的 GitHub，这个项目之前，他名下 20 个公开仓库全部不超过 5 颗星——做的是 Shopify 排班应用、部署脚本这类全栈实干活。CodeGraph（49k 星）在他的履历里是个断崖式的异常值，下一个最高的仓库只有 44 星。
项目 2026 年 1 月 18 日建仓，建仓当天 README 顶部就写好了"营销味十足的 hero 区"。这个细节本身说明问题：它从第一天起就是奔着传播去的。技术架构（tree-sitter 解析代码 → 存进本地 SQLite → 文件监听增量更新 → 通过 MCP 协议把 8 个查询工具递给 agent）也是首日就成型，后面主要是加语言、修 bug。
真正的爆发在 5 月下旬——据独立统计，一个 7 天窗口涨了 21,424 颗星，冲上 GitHub 趋势榜第 2。但这里有个耐人寻味的反差：我让 agent 一手核实了 Hacker News，发现这个 49k 星的项目从来没有一个像样的 HN 讨论帖（作者自己发过一条，1 分、2 评论，沉底了）。增长引擎不是技术圈的硬核认可，而是 X 上一个叫 @getcodegraph 的运营号 + 一堆口径高度一致的模板化安利（"58% 更少工具调用、16% 更便宜、100% 本地"）。
6 月 12 日它刚发布 v1.0.0。也就是说，那篇公众号刷屏的时候，这还是个半年新、上一周才迈过 1.0、由一个人维护的项目——一手数据确认：作者一人提交了 432 个 commit，第二名只有 16 个，约 91% 的代码出自他一人之手。这叫"巴士因子等于 1"：哪天他不干了，项目就悬了。
Serena 的气质完全相反。它背后是 Oraios AI——德国慕尼黑的一家 IT 咨询合伙企业，2024 年由两个长期搭档 Dominik Jain 和 Michael Panchenko 创立。这俩人就是 Serena 贡献榜的前两名，是实打实写代码的创始人，其中一位还经常在 Reddit 上以"Serena dev"身份下场答疑。
仓库 2025 年 3 月就建了，比 CodeGraph 早将近一年。但它走得很慢——直到 2026 年 4 月才发 v1.0.0，在那之前 dev 自己在 Reddit 上说"我们连第一个正式版都还没到"。这种慢，换来的是社区深度：现在 25,000 星、170 多位贡献者（对比 CodeGraph 的"一个人"），这是完全不同的健康度。
它被带火，靠的是 2025 年中 Claude Code 用户的口碑裂变。r/ClaudeAI 上一个爆款帖标题就叫《试试 Serena MCP，回头谢我》，原话"几分钟内我就看出这是个 game changer"。商业模式也清楚：核心代码 MIT 免费开源，靠付费的 JetBrains 插件和母公司咨询业务赚钱——所以它没有 CodeGraph 那种"免费工具将来要怎么变现"的悬念。
技术上，Serena 是这个品类里少数能"改代码"而不只是"查代码"的。它挂的是真正的语言服务器（就是 IDE 里"跳转到定义""查找所有引用""重命名"背后那套），所以能做符号级的精确重构，支持 40 多种语言。代价后面会讲——这套东西很吃内存。
| 路线 | 代表 | 原理（说人话） | 强项 | 命门 |
|---|---|---|---|---|
| 预建图谱 | CodeGraph GitNexus |
提前把整个代码库啃成一张"谁调用谁"的关系图，存进本地数据库，agent 查图代替翻文件 | 查调用链、影响半径精确；首查极快；不依赖项目能编译；纯本地 | 靠"名字匹配"不懂类型，动态语言/反射会漏边认错；索引会过期、会腐化 |
| 实时 LSP | Serena | 挂上 IDE 同款语言服务器，agent 实时问"这符号定义在哪/谁引用了它" | 语义最准（懂类型，找的是真调用不是同名字符串）；能安全改代码；永不过期 | 语言服务器必须装好能跑；很吃内存；大项目首次加载慢 |
| 向量 RAG | Cursor 内置 claude-context |
把代码切块、算"语义向量"存起来，用自然语言模糊检索 | 按概念找（"重试逻辑在哪"不用知道确切名字）；超大库压缩上下文 | 召回不精确、会漂移；这条路在写代码场景正在被淘汰（见下） |
这个赛道 2026 年挤满了名字雷同、卖点雷同的项目（光叫"codegraph"的就有好几个互不相干）。星数为一手实时数据（2026-06-15）：
| 工具 | 路线 | 星 | 定位 / 备注 |
|---|---|---|---|
| CodeGraph 主角 | 预建图谱 | 49.1k | 赛道星王。但 solo 维护、pre-1.0 刚过 |
| Aider repo map | 图谱(内置) | 46.2k | 终端结对编程，这条思路最早的代表（2023） |
| GitNexus | 预建图谱 | 42.1k | 另一个图谱黑马，浏览器内跑；非商用许可逼走过团队 |
| Serena 主角 | 实时 LSP | 25.4k | 符号级标准件，唯一主打"能改代码"，170+ 贡献者 |
| ast-grep | AST 基座 | 14.5k | 结构化搜索 CLI，很多工具的底层能力 |
| claude-context | 向量 RAG | 11.8k | Zilliz 出品，是它向量云的引流口 |
| codanna | 混合 | 0.7k | Rust 写，tree-sitter 图 + 向量 + 文档 RAG；刻意只读不编辑 |
| Cursor 内置 / Augment | 商业向量 | 闭源 | 商业产品自带；Augment 估值 $977M，把引擎拆成独立 MCP 卖 |
| Sourcegraph Cody | 商业 | 已退役 | 仓库已 archived，转向新产品 Amp |
注：codanna 维护者亲述了一个有意思的分工哲学——"我们觉得编辑该留在 IDE 里"，所以它刻意只做毫秒级的快速只读查询，把改代码留给 Serena 那种 LSP 工具。这恰好说明这个赛道内部对"工具该管多宽"是有分歧的。
这是悬在整个赛道头顶的剑，而且反方有 Claude Code 创作者本人站台。这一节直接关系"该不该上"的决策。
"Claude Code 早期版本用过 RAG + 本地向量库，但我们很快发现自主搜索通常更好。它还更简单，没有安全、隐私、过期、可靠性那些问题。" —— Boris Cherny，Claude Code 创作者本人 · x.com/bcherny
"Claude Code 把 RAG 数据库换成了一个 Grep 工具……自己构建上下文的 agent，持续跑赢被喂预建上下文的 agent。" —— Harper Foley · x.com/HarperEFoley
知名开发者 Mario Zechner、Armin Ronacher 也有类似批判。还有人专门戳破那些"隐藏的 LSP 设置能让 CC 快 10 倍"的病毒帖是编造的引流诱饵——因为 Claude Code 早就在用快速的 ripgrep 了。
最有价值的横向发现：CodeGraph 作者本人在自己仓库的 issue #235 里回答过这个问题，结论是——它俩互补，不是替代：
"CodeGraph 用 tree-sitter 建确定性知识图谱，做结构/关系查询（调用者、影响、追踪"X 怎么到达 Y"），不需要语言服务器。Serena 是基于 LSP 的工具包，做语义符号查询 + 代码编辑。
粗略权衡：CodeGraph 偏向跨多语言、免 LSP 配置的快速关系查询；Serena 偏向 LSP 级语义操作加编辑。两者甚至可以互补。" —— colbymchenry，CodeGraph 作者 · github issue #235
| 维度 | CodeGraph（图谱） | Serena（LSP） |
|---|---|---|
| 底层 | tree-sitter 名字匹配 → 预建索引 | 真语言服务器，实时 |
| 准确度 | 不懂类型，动态语言会认错 | 懂类型，找的是真调用准 |
| 新鲜度 | 增量同步，会静默腐化 | 永不过期（直接读当前代码） |
| 多语言 | 免配置，一个装好全搞定 | 每种语言要配 LSP，rust 尤其吃内存 |
| 能改代码 | ❌ 纯只读地图 | ✅ 符号级重构 |
| 社区健康 | solo，91% 单人提交巴士因子=1 | 170+ 贡献者健康 |
| 成熟度 | 半年新，刚过 1.0 | 一年多，2026-04 过 1.0 |
把演进史和竞争格局叠起来看，针对本系统的实际情况（多语言 py/rust/ts、快速迭代、中大型仓、目标是给 coding agent 提效提质），有三个交叉洞察。
上一轮讨论中有个反驳："重建成本不是问题"——这个反驳是对的，增量同步确实轻。但这一轮的批判证据揭出一个更深的坑：CodeGraph 的增量同步在频繁改动下会"静默"把调用关系图搞错，却一直报告"健康"。
"增量监听同步会间歇性地静默丢掉调用边……跑久了，最热的文件丢掉进出关系，callers/trace返回 0 或错误结果——而status和sync一直报"健康/最新"。只有全量重建能修。这是一个发生在调用图最有价值的那些符号上的、静默的正确性退化。" —— GitHub issue #773，用户实测自述（用唯一命名的方法验证过，排除了同名歧义）
那些"省 35%、减 70%"是官方在7 个挑选过的仓、每仓只问一个问题、且不走 sub-agent 委派的理想条件下自测的。独立评测给出的现实是：
"在 Gin（约 110 文件）上，原生 grep 本来就便宜，CodeGraph 的优势坍缩到只省 21%。OkHttp 是诚实的反例——只省 2%，token 几乎没动。……建议 300 文件以下的仓直接别上。" —— andrew.ooo 独立评测（目前最冷静的一篇）
而且独立评测点出一个对本场景很关键的硬伤："CodeGraph 只在被直接查询时才有用——如果父 agent 把探索委派给读文件的 sub-agent，图谱根本不会被调用。" 而 sub-agent 探索正是 Claude Code 的常用模式。
我把态度的演化摊开来看，这本身就是"避开营销看实际"的价值：
| 问题 | 真实摘录 |
|---|---|
| 静默丢边腐化 最致命 #773 | 增量同步静默丢调用边，status 还报"健康"，只有全量重建能修 |
| 认错符号 #765 | 1100 文件混合仓实测：Swift 方法被错报成被无关包调用；且工具指令叫 agent"别用 grep 复核" |
| 静默返回空 #841 | forwardRef 组件（所有 shadcn/ui 组件）拿不到调用边，几十个文件在用却报"无调用者"，agent 可能误判可安全删 |
| 反吃上下文 #771 | "我只想定位文件，但工具返回多文件的大段源码，很快撑爆对话上下文"——省 token 的工具默认在吃 token |
| 拖垮整机 #845/#857 | 文件描述符耗尽触发系统级"Too many open files"、甚至重启整机；内存峰值 9.9GB、DB 涨到 9.1GB |
| Windows 拉胯 #208 | NTFS 上扫到约 385 文件永久卡死，至今未解 |
| 问题 | 真实摘录 |
|---|---|
| 语言服务器内存泄漏 最严重 #1556/#1490/#1549 | rust-analyzer 涨到 40–44GB（没开编辑器）；Kotlin 90 个孤儿进程吃 21GB；"进程在父进程关闭后还在、吃光内存、搞崩我电脑" |
| 新版 CC 绕过它 官方 docs 自承 | "近期 Claude Code 和 Opus 的更新导致外部工具调用大幅减少……必须靠 hooks（仍是 alpha）才能掰回最优表现" |
| 改坏代码 #1484/#1529 | replace_symbol_body 静默剥掉 C# 属性；把 Go 类型声明的关键字重复弄坏 |
| 小项目用了没感觉 dev 亲承 | Serena dev 原话："小项目、或限于单文件内编辑的任务，你不会感到太多好处，反而 Serena 可能碍事" |
在一个 381 类 / 36,407 行 / 1017 个测试的 Java 支付服务上跑大型重构：原生 Claude 跑 1 小时花 $23.54，构建失败；Claude+自带 LSP 跑 1 小时 $28.63，放弃，还挂 9 个测试；Claude+Serena：45 分钟、$27.30、构建通过、1017 个测试全绿。结论："Serena 现在是我们配置里绝对的必装项。" —— manomano-tech, Project AEGIS benchmark（作者偏好明显，但有可复现的 prompt 和数字）· medium
这条要客观看：它证明的是"大型、复杂、多文件重构"场景下 Serena 的价值，不是日常小改。和上面 dev 自己说的"小任务碍事"正好两头印证了 Serena 的适用边界。
本报告由 4 路并行 agent 一手采集（GitHub API / Issues、X、Hacker News、Reddit、独立评测博客），刻意排除中文圈互相搬运的营销稿。核心一手源：