tokensave
为AI编码Agent预建语义知识图谱，大幅减少Token消耗与工具调用次数
加载项目详情…
本应用为开源项目，仅供学习研究，请遵守其开源协议。
微信扫码咨询客服
POMOAI — 让开源 AI 即刻运行
为AI编码Agent预建语义知识图谱，大幅减少Token消耗与工具调用次数
加载项目详情…
本应用为开源项目，仅供学习研究，请遵守其开源协议。
图1：TokenSave 项目 Logo
想象一下：你对 Claude Code 说一句"帮我实现用户认证模块"，它转身就启动了三个子 Agent，每个 Agent 各自发出数百次文件扫描请求——有的翻遍所有 Rust 文件找 auth，有的遍历 TypeScript 目录定位 login 相关代码，还有的逐个打开测试文件搜索相关用例。
这不是虚构场景，这是当前 AI 编程智能体在处理真实项目时的常态。以一个拥有 10 万行代码的中型仓库为例，单次复杂任务的上下文探索可能涉及数千次文件读取，Token 消耗轻松破百万。更要命的是，这些扫描绝大多数是重复劳动——同一个 UserService 结构体可能被不同的子 Agent 读取了十几遍。
TokenSave 正是为解决这个痛点而生。 它不是又一个 AI 聊天界面，而是一套为 AI 编码智能体服务的代码理解基础设施——在本地为代码库建立预索引的语义知识图谱，让 Agent 查询时获得即时、结构化的答案，大幅减少无谓的 Token 消耗和工具调用次数。
TokenSave 由开发者 aovestdipaperino 创建，最新版本为 7.0.2，托管于 GitHub，采用 MIT 许可证开源。项目仓库目前拥有约 317 颗 Stars（分析时数据）、24 个 Forks、12 个活跃 Issue，是近年来增长最快的代码智能工具之一。
作者的核心洞察是：AI 编码智能体的瓶颈不在于模型能力，而在于代码理解效率。 当前的 Agent 范式本质上是"盲人摸象"——每次执行任务时，Agent 需要通过大量 glob/grep/read 调用实时探索代码库，这种模式在小型项目上尚可接受，但面对大型 monorepo 时就成了性能和成本的双重噩梦。
TokenSave 的解决方案是预先计算、一次索引、多次复用：在项目初始化时完成全量语义解析，将代码结构（符号、关系、调用链）存入本地 libSQL 图数据库，Agent 运行时直接查询图谱，绕过重复的文件扫描。
TokenSave 提供了超过 40 种 MCP 工具，覆盖代码搜索、结构分析、影响评估等多个维度。以下是几类核心工具的功能解析：
| 工具名称 | 功能描述 |
|---|---|
tokensave_search | 按名称或关键词查找代码符号 |
tokensave_node | 获取特定符号的详细信息（定义位置、类型、文档注释） |
tokensave_files | 列出已索引的项目文件，支持过滤 |
传统上，AI Agent 需要发出数十次 glob + grep 组合才能找到目标符号，TokenSave 将这个过程压缩为一次图查询。
| 工具名称 | 功能描述 |
|---|---|
tokensave_callers | 查找某函数的全部调用者 |
tokensave_callees | 查找某函数调用的全部子函数 |
tokensave_impact | 计算符号的影响半径——"如果修改 X，哪些文件会受影响" |
tokensave_recursion | 检测递归调用链 |
这类工具对于大型重构任务尤为关键。举例来说，当开发者需要重构一个被广泛调用的核心函数时，tokensave_impact 能直接给出受影响文件的完整列表，而无需 Agent 手动追踪每一个调用点。
| 工具名称 | 功能描述 |
|---|---|
tokensave_complexity | 按复合复杂度评分排序函数 |
tokensave_god_class | 找出成员数量最多的"上帝类" |
tokensave_doc_coverage | 查找缺少文档注释的公开符号 |
tokensave_coupling | 按扇入/扇出耦合度排序文件 |
tokensave_rank | 按关系数量对符号排序 |
tokensave_largest | 按规模（最长类、最长方法）排序 |
TokenSave 采用增量索引策略：tokensave sync 仅处理自上次同步以来变更的文件，而非全量重建。对于大型项目，这意味着每次 git pull 后的增量更新可以在秒级完成，保持图谱始终与代码库同步。此外，tokensave_affected 工具可以根据源码变更，自动定位受影响的测试文件，帮助 Agent 精准运行测试套件。
TokenSave 的技术栈选择非常明确：Rust + tree-sitter + libSQL。这套组合在代码智能场景下几乎是性能最优解。
项目使用 tree-sitter（v0.26）作为代码解析器。tree-sitter 是一个增量解析库，能够快速将源代码解析为具体语法树（CST），并支持增量更新——当单个文件发生变化时，只需重新解析该文件，而非整个代码库。这对大型 monorepo 的实时索引至关重要。
TokenSave 支持的语言数量是其核心竞争力之一。基础层（Lite）默认支持 11 种主流语言：
Rust, Go, Java, Scala, TypeScript/JavaScript, Python, C, C++, Kotlin, C#, Swift
中等层（Medium）扩展支持：Dart, Pascal, PHP, Ruby, Bash, Protobuf, PowerShell, Nix, VB.NET 等。
完整层（Full）则涵盖 ActionScript, Lua, Zig, Objective-C, Perl, Batch, Fortran, COBOL, GLSL/WGSL/HLSL、Markdown、SQL、R、Julia、Haskell、OCaml、Clojure、Erlang、Elixir、F#、F*、Quint、Toml、Lean 等 30 余种语言，总计支持语言超过 40 种。
所有语法树由 tokensave-large-treesitters（版本 0.5.0）仓库提供，通过 Git submodule 方式引入。
代码知识图谱存储在 libSQL（SQLite 的 fork，支持嵌入式部署）中。schema 设计围绕"符号节点"和"关系边"展开：节点存储符号名称、类型、定义行号、文档注释；边存储调用关系、继承关系、导入关系。libSQL 的选择兼顾了查询性能和零运维复杂度——无需额外部署数据库服务，直接本地文件存储，100% 离线可用。
项目还引入了 ort（ONNX Runtime Rust 绑定，v2.0.0-rc.12）和 ndarray，暗示未来可能引入 ML 模型进行代码嵌入（embedding）计算，实现更高级的语义搜索能力，而不仅限于精确的符号匹配。
命令行解析使用 clap（v4.6，支持 derive 宏），异步运行时采用 tokio（v1，全特性开启），保证了工具的响应速度和并发处理能力。日志系统基于 tracing，支持环境变量过滤。
tokensave/
├── src/
│ ├── main.rs # CLI 入口 + Spinner 动画
│ └── lib.rs # 核心库（TokenSave 结构体）
├── codegraph/ # 图数据库 schema + 查询逻辑
├── tests/ # 集成测试套件
├── benchmarks/ # 性能基准测试（Criterion）
├── docs/ # 架构文档、MCP 集成指南
├── examples/ # 使用示例
├── vendor/ # 第三方依赖 vendoring
└── Cargo.toml # 工作空间配置
main.rs 中的 Spinner 实现是一个值得关注的工程细节——它在后台线程以约 80ms 间隔重绘动画帧，同时支持跨线程消息更新，既保证了用户体验的流畅性，又避免了阻塞主线程。
TokenSave 的安装极为简洁，支持两种主流方式：
macOS 用户（Homebrew）：
brew install aovestdipaperino/tap/tokensave
跨平台用户（Cargo）：
cargo install tokensave
安装后，通过 tokensave claude-install 自动配置 Claude Code 的 MCP 连接，无需手动编辑 JSON 配置。初始化项目只需三步：
cd /path/to/your/project
tokensave init # 创建 .tokensave/ 目录并建立索引
tokensave sync # 增量同步（后续变更使用）
tokensave status # 查看索引统计
对于 Claude Desktop 用户，需手动在 claude_desktop_config.json 中注册 MCP 服务器。
尽管 TokenSave 解决了 AI 编码 Agent 的核心痛点，它也存在以下局限：
1. 预索引延迟问题：首次 tokensave init 需要解析整个代码库，对于超大型仓库（50 万行以上），可能需要数分钟甚至更长的初始化时间。在这段时间内，Agent 无法使用图谱能力。
2. 多语言语法树质量参差不齐：tree-sitter 各语言的 grammar 由社区维护，并非所有语言都能做到精确的符号解析。特别是较新版本的语言或小众语言，可能出现符号遗漏或错误归类。
3. 非 Rust 项目的增量同步效率：虽然 tokensave sync 支持增量更新，但其底层仍依赖 tree-sitter 解析，增量效率高度依赖文件系统变更检测的准确性，在某些边界场景（如部分重命名、内部 Git 操作）下可能遗漏变更。
4. ML 能力尚在演进：ORT 和 ndarray 的引入说明作者有意发展 ML 驱动的代码理解，但截至当前版本（7.0.2），这类高级能力尚未公开可用，未来走向待观察。
TokenSave 的出现代表了 AI 编程工具链的一次分层思考。在它之前，AI 编码工具大多聚焦于"如何让 AI 更好地生成代码"；TokenSave 则关注"如何让 AI 更高效地理解代码"——这是两个不同维度的问题。
从增长曲线看，TokenSave 的 Stars 在过去数月保持稳健上升，月均增长率位居同类工具前列。其背后反映的是：随着 Claude Code、Codex、Cursor 等工具的普及，越来越多的开发者开始意识到，AI 编程的瓶颈不在于 LLM 的生成质量，而在于上下文获取效率。谁能更快、更准地让 AI 理解一个陌生的代码库，谁就掌握了这个赛道的核心壁垒。
此外，TokenSave 拥抱 MCP（Model Context Protocol）协议，意味着它不仅仅是 Claude Code 的专属工具——理论上任何支持 MCP 的 AI 客户端（Codex、Cursor、Gemini 等）都可以接入，这为其生态扩展留下了想象空间。
总结：TokenSave 是 AI 编码智能体生态中不可或缺的底层基础设施。它用 Rust 实现高性能，用 tree-sitter 实现多语言语法解析，用 libSQL 实现本地图数据库，三者结合构成了一个"预计算、免运维、零依赖"的代码理解引擎。对于正在使用或计划使用 AI 编程工具的开发者而言，TokenSave 值得优先体验。