dekko

Name: dekko
Author: aahlijia

本地服务

github.com/aahlijia开发工具63 周前更新

代码仓库

关于 dekko

dekko 是面向 LLM 编码 Agent 的离线、无依赖静态代码地图生成器和索引器。它生成包含符号关系与调用边的机器可读及人类可读地图，并通过命令行、Claude Code 插件和 MCP 服务支持定向查询。

主要功能

01生成 MAP.md 和 map.json 代码地图
02使用 tree-sitter 解析仓库
03构建符号及调用方关系
04汇总目录、热点与入口点
05通过命令行或 Agent 接口查询代码结构

适用场景

01帮助 Agent 熟悉陌生仓库
02查找符号的调用方和被调用方
03无需逐一读取文件即可概览大型文件或目录
04通过 Claude Code 或 Cline 检查代码结构

MCP 相关

提供 MCP 服务，供 Agent 查询生成的代码地图和代码库结构。项目也提供命令行工具和 Claude Code /map 插件。

配置

本地服务的配置在各客户端中通用，复制后粘贴到客户端的 MCP 配置文件即可。

mcp.json · 通用配置

{
  "mcpServers": {
    "aahlijia-dekko": {
      "command": "uvx",
      "args": [
        "dekko"
      ]
    }
  }
}

启动命令uvx dekko

本地服务需要在你的电脑上安装运行环境（如 Node.js 18+）。各客户端的配置文件位置不同，请参考客户端文档。

安装包

pypidekko1.9.0stdio

工具

收录的工具列表 · 更新于 2 周前

参数	类型	必填	说明
kind	string	否	用逗号分隔的符号种类，用于限制搜索范围（function、method、class 等）
root	string	否	包含 map.json 的仓库根目录（默认为服务器当前工作目录）
limit	integer	否	最大命中数（默认值为 15）
query	string	是	要查找代码的自由文本描述
budget	integer	否	输出的 Token 预算（默认值为 800；0 = 不限）
scorer	enum	否	相关性评分器：'lexical'（默认值，BM25，始终可用）、'embedding'（哈希技巧嵌入）或 'both'（通过倒数排名融合合并 lexical 与 embedding 排名）——仅当服务器安装了 dekko[search] 扩展时，'embedding' 和 'both' 才可用lexical \| embedding \| both
include_tests	boolean	否	包含测试路径中的符号（默认值：false）

详细介绍

你是否见过编码 Agent 在仓库中盲目地 grep，打开三个不需要的文件，仅仅为了回答“谁调用了这个函数”就耗费一万五千个 token？dekko 正是为了解决这个问题而存在。

dekko 演示：数秒内映射仓库并查询符号

_{此演示运行于 dekko 自身的仓库（提交 835733c）——克隆该仓库并亲自运行同样的三条命令。}

dekko 是一款快速、离线、无依赖的静态代码地图生成器和面向大模型编码 Agent 的代码库索引器。它使用 tree-sitter 扫描仓库（解析时不消耗模型 token），并生成：

MAP.md —— 易于阅读的地图：逐目录概览、内嵌架构图、关键承载组件／编排器排名，以及每个文件中的所有函数／方法，包括签名、文档行，以及调用者和被调用者。
map.json —— 同一张图的机器可读形式。

基于这张地图，dekko 为 Agent 提供了一种 token 成本低的方式来回答“这个文件包含什么”“谁调用了这个函数”以及“安全地修改它需要了解什么”等问题，而无需通读整个文件。它以 CLI、Claude Code /map 插件 + MCP 服务（Model Context Protocol）的形式提供，也支持 Cline。

结果：token 用量减少 10 到 300 倍。在日常任务（了解代码、梳理大型文件、查找某个符号的调用者）中，相较于纯粹的 Read/Grep 工作流，实测数据来自 7 个真实、未经修改的开源仓库，使用 dekko 0.43.77 测得。最低收益出现在一个适合 grep 的本地小型符号上，约为 2.5 倍。完整分析如下。

为什么选择 dekko？

大多数 Agent 工作流会通过读取整个文件或在代码仓库中搜索来收集上下文——这既耗费资源，也会丢失结构信息（谁调用了什么、函数的扇入和扇出情况如何）。dekko 则会将代码仓库解析一次，生成调用图，并基于它回答有针对性的问题。在 7 个真实、未经修改的开源代码仓库（Go、TypeScript、Java、Rust、Python/C++，最多包含 14k 个文件和 172k 个符号）中，以 dekko 0.43.77 进行测量后发现，对于相同任务（了解代码仓库概况、梳理大型文件、追踪符号的调用方），dekko 的结构化查询比等效的 Read/Grep 工作流使用的令牌少 10 倍至 300 倍。

任务	示例代码仓库（规模）	dekko	Read/Grep	节省
了解代码仓库概况（`summary`）	awesome-go（10 个文件）	359 tok	~16,328 tok	~45 倍
了解代码仓库概况（`summary`）	claude-buddy（57 个文件）	~349 tok	~113,514 tok（每个源文件）	~325 倍
梳理大型文件	claude-code `REPL.tsx`（5,005 行）	~1,154 tok	~223,963 tok	~194 倍
梳理大型文件	cline `SdkController.ts`（84 KB）	1,803 tok	~21,023 tok	~11.7 倍
梳理目录	zed `crates/git_ui/src`（32 个文件）	~35,778 tok	~418,520 tok	~11.7 倍
查找符号的调用方	claude-code `errorMessage`	~602 tok	~18,521 tok（323 次以上 grep 命中）	~31 倍
查找符号的调用方	zed `MultiWorkspace.new`（22 处，8 个文件）	~809 tok	~381,446 tok（读取调用方文件）	~471 倍
外部 API 用法	claude-code `chalk`	~798 tok	~8,099 tok	~10 倍
打包上下文（`workset`）	awesome-go `ToHTML`	263 tok	4,104 tok	~16 倍

dekko 每次查询的成本大致保持不变，而 Read/Grep 的成本会随文件和代码仓库规模增长，因此规模越大，二者的差距就越明显。按实际耗时衡量，dekko 也很快：冷缓存下，为 dekko 自身约 4,300 个符号的代码库建立映射，在所有核心上约需 5 秒；编辑后增量重建映射远低于 1 秒，针对生成的映射进行查询则会立即返回。这种优势并非适用于所有情况——对于小型、自包含的文件，以及已经很适合使用 grep 搜索的本地符号，收益很小（测得的最低值约为 2.5 倍）。完整的任务细分、方法、最初的 2026-08 研究，以及该研究提出的正确性注意事项和相应解决方案，请参阅 benchmarks/real-world-repos/。

与 ctags/gtags 等标签索引工具相比，dekko 能解析实际的调用边（而不只是定义）、按承载作用对文件排序，并能直接通过 MCP 或命令行与 Agent 通信——无需编辑器插件。

安装

uv tool install dekko      # or: pip install dekko / pipx install dekko
dekko --claude-install     # add the /map command + MCP server to Claude Code, then restart

其他选项（dekko[all] 可支持另外 43 种语言，dekko[search] 可支持嵌入搜索）、从本地克隆安装以及卸载说明，请参阅 docs/install.md。

快速开始

cd my-project
dekko map                  # writes .dekko/MAP.md + .dekko/map.json
dekko summary               # ~40-line digest: dirs, hotspots, entry points

默认情况下，.dekko/ 会被 Git 忽略；映射会按需重新生成，因此你很少需要手动再次运行 dekko map。如果你的代码仓库包含默认 Tier-1 集合（Python、C、C++、JS/TS、Go、Java、Kotlin、Rust）以外的语言，dekko map 会按文件提示；安装 dekko[all] 可支持另外 43 种语言（参见安装），然后重新运行。关于每种语言的解析支持情况，请参阅列表。