上周写 Gortex 的时候提到了一个观点：代码知识图谱的核心不是"能不能建图"，而是"Agent 查的时候够不够快"。Gortex 用 Go 写了个零依赖方案，7 万个文件 3 分钟索引完，已经很快了。但今天看到 CodeDB 的 benchmark 之后，我被惊到了——预索引状态下，符号查询 0.1ms，全量文本搜索 0.05ms。比 ripgrep 快 1340 倍。
不是 ripgrep 变慢了，是 CodeDB 用了完全不同的思路。
它到底做了什么
CodeDB 的定位很明确：代码上下文引擎，不是编辑器。它帮 Agent "找到并理解"代码——搜索、符号、调用者、依赖、大纲——然后把编辑交还给你的原生工具。codedb_edit 只是个备选方案。
这种克制其实很聪明。Agent 工具链里"编辑"这一步已经有 Claude Code、Cursor、Codex 各自的原生方案了，做得再好也是重复造轮子。但"上下文检索"这一步，大多数 Agent 还在用 grep + read_file 的原始组合，每次把整个文件塞进上下文，token 浪费严重。CodeDB 就是来解决这个瓶颈的。
快的秘密：三层索引
CodeDB 用了三个索引协同工作：
Trigram 索引（v2）——全量文本搜索的加速器。传统 trigram 是字符串匹配，CodeDB 的 v2 版本用了整数 doc ID、批量累积、合并交集的优化，搜索速度比 ripgrep 快 3 个数量级。
倒排词索引——O(1) 的标识符查找。你问 "Store 这个 struct 在哪定义的"，不需要遍历，直接 map lookup。这在大型代码库里是质的差别。
结构化大纲——tree-sitter 解析每个文件，提取函数、struct、import 等符号，带行号。支持 Zig、C/C++、Python、TypeScript/JavaScript、Rust、Go、PHP、Ruby 等 11 种语言的完整解析，另有 Java、Kotlin、Svelte、Vue 等 10+ 种语言的轻量级大纲支持。
三个索引预计算完之后，Agent 的每次查询就变成了内存中的数据结构查找——不需要重新扫描文件，不需要重新解析 AST。这就是 0.1ms 的来源。
21 个 MCP 工具
CodeDB 通过 MCP（JSON-RPC 2.0 over stdio）暴露 21 个工具，覆盖 Agent 日常需要的全部代码理解场景：
| 工具 | 用途 | 亮点 |
|---|---|---|
codedb_tree | 文件树 + 语言 + 符号计数 | 一目了然的仓库结构 |
codedb_outline | 文件内符号大纲 | 函数、struct、import 带行号 |
codedb_symbol | 跨仓库符号定义查找 | O(1) 倒排索引 |
codedb_search | 全量文本搜索 | 支持正则，trigram 加速 |
codedb_word | 精确词查找 | 倒排索引，O(1) |
codedb_callers | 找到所有调用者 | 词索引 ∩ 大纲范围，一次往返 |
codedb_context | 任务级上下文组装 | 传入自然语言任务，一次返回关键词 + 符号定义 + 排名文件 + 代码片段 |
codedb_deps | 依赖图 | 支持 imported_by / depends_on，可 BFS 传递 |
codedb_hot | 最近修改的文件 | 帮你聚焦当前工作区 |
codedb_remote | 远程仓库查询 | 不用 clone，直接查 GitHub 公开仓库 |
codedb_query | 可组合管道 | 链式 find → search → filter → deps → outline → read |
重点说一下 codedb_context。这个工具的设计思路是：Agent 通常需要 3-5 次顺序调用才能拼出"理解一个任务需要的上下文"——先搜索关键词，再查符号定义，再找相关文件，再读代码片段。codedb_context 把这些合成一次调用，传入自然语言任务描述，直接返回结构化的上下文包。这对减少 Agent 的 round-trip 延迟非常有价值。
另一个有意思的是 codedb_remote。它调用 api.wiki.codes 这个公共服务，可以直接查询任何已被索引的公开 GitHub 仓库——不需要本地 clone。Agent 可以在不下载 Next.js 源码的情况下搜索它的代码。这对"我想参考一下这个开源项目怎么做的"这种场景非常实用。
实际 benchmark
官方在 Apple M4 Pro 48GB RAM 上跑的数据（MCP = 预索引热查询，20 次迭代平均）：
| 查询类型 | CodeDB MCP | ripgrep | 加速比 |
|---|---|---|---|
| 符号搜索 | 0.10ms | 6.3ms | 63x |
| 全量文本搜索 | 0.05ms | 5.3ms | 106x（CLI 对比 1340x） |
| 词索引查找 | 0.04ms | 7.2ms | 180x |
| 结构化大纲 | 0.05ms | — | 比 ast-grep 快 62x |
| 文件树 | 0.04ms | — | 比 CLI 快 1253x |
当然这是预索引状态下的数据——首次索引需要时间。但对于 Agent 工作流来说，索引是一次性的，查询是反复的。Agent 每次交互可能查 5-10 次代码，每次都快 1000 倍，累积起来的体验差异是巨大的。
跟 Gortex、Axon、Context+ 比
| CodeDB | Gortex | Axon | Context+ | |
|---|---|---|---|---|
| 语言 | Zig | Go | Python | TypeScript |
| Star | 1.3K | 884 | 720 | 1.9K |
| 语言支持 | 11 完整 + 10+ 轻量 | 257（三档） | ~10 | ~15 |
| MCP 工具数 | 21 | 175 | ~10 | 17 |
| 外部依赖 | 零 | 零 | Neo4j | 零 |
| 查询延迟 | 0.05-0.1ms | ~1ms | ~10ms | ~5ms |
| 核心优势 | 极致速度 | 语言覆盖广 | 图数据库灵活 | RAG 语义搜索 |
| 远程仓库 | ✅ | ❌ | ❌ | ❌ |
| 依赖图 | ✅ | ✅ 多仓库 | ✅ | 基本 |
选型建议：
- 速度优先：CodeDB。零依赖、查询最快、Zig 编译的原生二进制。
- 语言覆盖优先：Gortex。257 种语言、175 个 MCP 工具、多仓库图谱。
- 语义搜索优先：Context+。RAG 方案适合模糊查询（"找处理权限的逻辑"）。
- 快速原型：Axon。Python 生态好改，但大仓库扛不住。
上手
一键安装，自动注册到 Claude Code、Codex、Gemini CLI、Cursor、Windsurf：
curl -fsSL https://codedb.codegraff.com/install.sh | bash或用 npm（MCP 客户端零安装）：
npx -y codedeebee mcp手动启动 MCP 服务：
codedb mcp /path/to/your/projectCLI 也能直接用：
codedb tree . # 文件树 + 符号计数
codedb outline src/main.zig # 文件内符号
codedb find AgentRegistry # 符号定义查找
codedb search "handleAuth" # 全量文本搜索
codedb word Store # 精确词查找
codedb hot # 最近修改的文件HTTP 服务模式（本地 7719 端口）：
codedb serve /path/to/project
# 然后
curl localhost:7719/tree
curl "localhost:7719/symbol?name=Store"
curl "localhost:7719/search?q=handleAuth&max=10"踩坑提醒
Alpha 阶段——API 还在稳定中，snapshot 格式可能变。用在生产环境没问题（作者自己每天在用），但别指望完全向后兼容。
语言覆盖有限——只有 11 种语言有完整 tree-sitter 解析。如果你的项目是 Java/Kotlin 为主，只能拿到轻量级大纲，精确度差一截。Gortex 在这方面更全面。
Zig 0.17.0-dev——编译依赖还在开发版的 Zig。从源码构建需要特定版本的 zigup 工具链，不太友好。建议直接用预编译二进制。
MCP 模式是单例——用 PID 锁保证只有一个实例，1 小时空闲自动退出。如果你的 Agent 重启后发现工具不可用，可能需要手动重启 codedb mcp。
值得关注的点
CodeDB 的 codedb_remote 背后是一个叫 api.wiki.codes 的公共服务，已经索引了大量公开 GitHub 仓库。这意味着 Agent 可以"不开箱即用"地查询外部项目的代码——不需要 clone，不需要配 token。这个能力在"我想参考某个开源项目的实现"场景下非常实用，而且是目前其他代码智能工具都没提供的。
另外，CodeDB 的 codedb_query 可组合管道设计值得关注。它允许 Agent 在一个请求里链式执行 find → search → filter → deps → outline → read，本质上是给 Agent 提供了一个"代码查询 DSL"。这比一个个工具单独调用高效得多，也更符合 Agent 的思维模式——"先找到相关的，再过滤，再深入看"。
项目状态：Alpha，BSD 3-Clause 协议，1.3K Star，活跃开发中。