摘要Sonde 把仓库索引成符号级代码图一次调用回答谁调用了它、改了会坏什么。官方基准显示上下文 token 降到三分之一、延迟快 147 倍但它对行为性查询召回为 0且不支持 Java。本文讲清它的真实边界以及 Java 栈的可行替代。让 Claude Code 改一个陌生仓库里的函数它会先派 Explore 子代理用 grep、glob、Read 把仓库扫一遍。这个过程的成本比想象中高。扫一遍不是为了分析是为了发现——先搞清楚东西在哪才轮到读那些真正相关的代码。发现阶段烧掉的 token一分钱都没花在解决问题上。有没有办法跳过发现最近 Show HN 上一个叫 Sonde 的开源项目给了一种思路把仓库预先索引成一张符号级的代码图让 Agent 直接查图一次调用拿到答案不再循环搜索。它的基准数据很漂亮。但把官方基准文件读一遍会发现漂亮数据背后有一条很清楚的分界线。一次调用替代八次搜索Sonde 做的事不复杂把仓库索引成符号级关系图存进本地 SQLite然后通过 MCP 暴露三个工具。工具回答什么find_symbols按名字找符号query_graph谁调用了它、谁实现了它、谁引用了它get_impact_radius改了它什么会坏、哪些测试相关三个工具覆盖的是同一类问题结构性查询。官方基准用的是 Hono v4.6.3346 个文件、9,348 个符号、50,517 条边对照组是标准的 Agentic 搜索循环指标SondeAgentic 搜索平均 recallk0.8331.000成功率0.8330.500平均干扰项0.000.00平均工具调用1.08.0平均上下文 token1,2633,621平均延迟262 ms38,602 ms来源Sonde 仓库BENCHMARK-LARGE.md生成于 2026-08-24数字怎么读这张表有三个地方容易看错而看错之后得到的结论会是反的。召回不是 1.00是 0.833。README 的表格里写着 “Recall on structural tasks 1.00”限定在结构性任务这一档。六个任务的平均召回是 0.833因为语义类任务是 0.00。六项任务里 Agentic 搜索才是全部 1.00。真正比的是成功率不是召回。Agentic 搜索的成功率只有 0.500因为它有一半任务超了 token 预算。基准方法论明确规定超预算的对照运行保留其召回、显式标注超支但因为没守住预算而判失败。Sonde 这边因为打包器按构造截断到预算内永远不可能超。所以 0.833 对 0.500 是一场在预算约束下的胜利——如果你的场景没有预算约束这个优势会缩水。别比输入 token比上下文 token。对照组输入 token 高达 78,548但这数字基本是噪声官方探针显示其中约 79k 是 Claude Code 缓存的 harness prompt真实任务输入只有 4 个 token。所以可比较的是上下文 token工具返回字节数1,263 对 3,621约三分之一。还有一条方法论值得单独提任务不是随机抽的是对抗性选取的。官方原话是均匀采样会在 Agentic 搜索本来就擅长的任务上显示持平从而引出错误结论。这话说得坦白——选任务的方式已经决定了结果的方向。顺带说一句这三条纠正不只适用于 Sonde。召回数字被限定在某个子集上、对照组被额外加上预算约束、token 口径里混进固定开销——这三招在任何一份 AI 工具基准里都可能出现。看基准先看方法论小节总表是最后才看的。赢在哪输在哪分界线很清楚就画在结构性三个字上。赢的四类传递影响改 A 会不会波及 C、宽接口的实现清单、完整性核对“我是不是漏了什么”、测试选择。这四类官方基准里 Sonde 召回全是 1.00其中传递影响类收益最大——4,000 token 对 9,756 token。输的一类行为性查询。典型问法是重试退避是在哪儿决定的官方召回 0.00。这不是没做是做了没成——项目建了本地语义检索试了两个 embedding 模型、四种文档配置都没胜过词法加结构检索所以没接进find_symbols。能力因此不予声称。还有个容易被省三倍这个结论盖过去的细节不是每个任务都省。六项任务里有三项 Sonde 的上下文反而更多198 对 131、337 对 332、1,077 对 945。省下来的全都集中在大任务上——传递影响省 5,756 token测试选择省 5,805 token。小任务上它不占便宜。一个能推广到 Java 的结论Sonde 最有价值的数据不在那张总表里在语言精度的实测里。先说精度基线。在 small fixture 上tree-sitter 默认路径的 Oracle 精度是precision 0.571、recall 0.889。README 解释了三个结构性原因歧义的成员调用会发出所有候选边至多一个对其余按构造计为误报构造函数调用 Sonde 建模而 Oracle 不建模成员级 IMPLEMENTS 是 Sonde 独有的能力但 tsc 只在类型级报告所以每条都被计为误报。第三条尤其关键——它正是接口方法影响分析能用的原因精度代价被披露而不是被抹掉。然后是最有说服力的一条TypeScript 的--resolve是可选开启的。在 Hono fixture 上默认索引 3.58 秒开启后 13.70 秒差别在于callers_of Hono.route从零个图结果变成八个编译器调用者。也就是说不开编译器解析谁调用了 Hono.route这个问题图里根本答不出来。Python 上这个差距更刺眼默认的 tree-sitter 层在 56 文件的真实项目上62.81% 未能解析在 pydantic 上 57.39%远超项目自己定的 30% 上限开启--resolve内置 pyright后降到 27.00% 与 17.42%。Swift 是纯启发式解析376 文件应用上 74.84% 命中、25.16% 未解析。把这三条摆在一起可以提炼出一条跨语言的判据tree-sitter 快但符号关系是猜的编译器慢但边是准的。默认配置下猜错的比例可能高到让谁调用了它直接返回空。这条判据对 Java 完全成立——而 Sonde 恰恰不支持 Java它只有 TypeScript、Python、Swift 三个适配器。Java 栈怎么落地Java 侧的可行方案分两条路线判断标准就是上面那条走不走编译器。路线一走编译器Eclipse JDT LSjava-lsp-mcp-server的做法是把 JDT Language Server 包装成 MCP 服务链路是 Claude Code → MCP → 该服务 → LSP → Eclipse JDT LS → 你的项目。它暴露九个工具跳转到定义、查找引用、获取实现、悬停信息、调用层级入向与出向、工作区符号搜索、编译诊断、重命名预览只预览不落盘、状态查询。前置条件是 Java 21 和 Node 18项目根目录会自动向上查找pom.xml或build.gradle。因为底层是 JDT 编译器符号解析是编译器级的不存在上面那种猜的问题。代价是重要起一个语言服务进程索引大型仓库的时间以分钟计。这里有个细节值得单独拎出来该仓库要求把一份CLAUDE.md拷进项目根目录理由是不给这份指令Claude 就算有这些工具也会默认用 grep/glob 而不是它们。装上了不等于用上了。路线二走 tree-sitter快但要打折CodeGraphMIT19 语言本地 SQLite文件监听自动同步、CodeGraphContext25 个工具明确列出 java 解析器、Codebase Memory MCPtree-sitter 加混合 LSP 类型解析覆盖 158 种语言都属于这一类。启动快、跨语言、依赖轻。CodeGraph 作者自述的基准是六个真实代码库上平均减少 92% 的工具调用、探索快 71%VS Code 代码库上扩展主机如何与主进程通信从 52 次调用降到 3 次某个 Java 代码库上单次调用完成、零文件读取。但作者自己标注了这是自报的单次查询基准应视为最佳情况同时诚实说明小项目上收益有限——二十个文件的仓库grep 本来就足够便宜。怎么选参照 Sonde 的 Hono 数据就够了如果问题形态是谁调用了它“改了会坏什么”必须走编译器路线因为纯 tree-sitter 在这个问题上可能返回空如果只是大范围粗筛、跨语言快速定位tree-sitter 的性价比更高。顺带一个跟 AI 无关但很实用的用法来自 CodeGraphgitdiff--name-only HEAD|codegraph affected--stdin--quiet沿导入依赖做传递追踪找出这次改动真正可能影响的测试文件。丢进 CI 或 git hook只跑该跑的测试。至于怎么选我的判断依据不是仓库行数是你问的问题有多依赖精确的调用关系。同样是十万行代码一个只做增删改查的后台服务和一个满是回调、代理与抽象层次的框架答案完全不同前者粗筛就够后者必须上编译器否则谁调用了它返回空你还得回头 grep。另一个信号是重复度——如果同一类结构性问题你一天要问好几次索引的前期成本才摊得回来只问一次直接搜更便宜。几个容易踩的坑没有重命名推断。Sonde 官方写明重命名文件会改变所有基于路径的稳定 key持有旧 key 的查询和上下文会静默停止解析不会跟随重命名。这条对任何基于路径建索引的工具都成立。Java 侧走 JDT 的方案基于全限定名情况会好一些但依赖路径的缓存同样会失效。测试边不等于覆盖率。Sonde 明确写了TESTS边只表示结构性关联从不证明覆盖率。跑这几个测试和这几个测试覆盖了这次改动不是一回事。解析失败的文件照样进图。Hono 索引里有 8 个解析失败。tree-sitter 恢复出来的部分仍然贡献内容parse_state会标为partial或failed。图是尽力而为的产物不是全知的。图会过期。索引是快照代码改了就得更新。Sonde 用sonde updateCodeGraph 靠文件监听。对 Java 这种编译型项目改动往往牵动整个模块重新解析增量索引的滞后比解释型语言更明显。地图不是理解回到开头那件事。Agent 找代码慢不是因为模型慢是因为它把大部分时间花在确认东西在哪。结构化索引解决的是发现不是理解。所以别把它当成让 AI 更聪明的开关。它是让 AI 少走弯路的路标。Sonde 自己划的分界线值得记住结构性问题归图行为性问题归搜索循环——后者它自己测出来是 0.00而且诚实地说了。真正该做的不是二选一是先判断眼前这个问题属于哪一类。主要来源Sonde 仓库 README、BENCHMARK.md、BENCHMARK-LARGE.md与ORACLE.mdGitHub大仓库基准原文java-lsp-mcp-server 仓库文档CodeGraph 与 Codebase Memory MCP 官方说明其中 CodeGraph 的基准为作者自述、单次查询。