SuperAPI AI 工具集
合作ENAI 行业资讯收藏
Skill 广场codebase-memory

codebase-memory

编程与开发

查看项目

更新于 10-30 16:20

技能介绍

用途

Codebase Memory 是一个代码库知识图谱工具，用于在探索代码库结构、追踪调用者与依赖关系、查找代码结构或死代码，以及对 codebase-memory 进行索引和重建索引时使用。其核心价值在于：图谱工具以约 500 token 返回精确的结构化结果，而 grep 全文搜索约需 8 万 token。

主要能力

内置 15 个 MCP 工具：index_repository、index_status、list_projects、delete_project、search_graph、search_code、trace_path、detect_changes、query_graph、get_graph_schema、get_code_snippet、get_architecture、check_index_coverage、manage_adr、ingest_traces。

常见查询方式：

  • 谁调用了 X：trace_path(direction="inbound")
  • X 调用了什么：trace_path(direction="outbound")
  • 完整调用上下文：trace_path(direction="both")
  • 按名称模式查找：search_graph(name_pattern="...")
  • 死代码：search_graph(max_degree=0, exclude_entry_points=true)
  • 跨服务边：query_graph 配合 Cypher
  • 本地变更影响：detect_changes()
  • 索引是否覆盖源码树：check_index_coverage()
  • 带风险分类的追踪：trace_path(risk_labels=true)
  • 文本搜索：search_code 或 Grep

边类型包括 CALLS、HTTP_CALLS、ASYNC_CALLS、IMPORTS、DEFINES、DEFINES_METHOD、HANDLES、IMPLEMENTS、OVERRIDE、USAGE、FILE_CHANGES_WITH、CONTAINS_FILE、CONTAINS_FOLDER、CONTAINS_PACKAGE。

使用方式

探索流程：list_projects 检查项目是否已索引 → get_graph_schema 了解节点/边类型 → search_graph(label="Function", name_pattern=".Pattern.") 查找代码 → get_code_snippet(qualified_name="project.path.FuncName") 读取源码。

追踪流程：search_graph(name_pattern=".FuncName.") 确认准确名称 → trace_path(function_name="FuncName", direction="both", depth=3) 追踪 → detect_changes() 将 git diff 映射到受影响符号。

索引流程：在项目根目录先写好 .cbmignore，再执行 index_repository(repo_path=<项目根>, mode=moderate, name=<稳定标识>)。读取返回中的 excluded 和 not_indexed_files 确认忽略规则生效，并用节点数与文件数做合理性核对。重建索引是幂等的，大幅结构变更后可再次运行。

CLI 模式（v0.11.0+）支持在终端直接执行单个工具后退出，无需 MCP 客户端，可用于代理会话无法完成的维护操作，例如 list_projects、delete_project、index_repository，并支持 --args-file 和 stdin JSON 批量脚本。

安装：上游为 https://github.com/DeusData/codebase-memory-mcp 。使用 install.ps1 安装（不要带 --ui 参数）。建议默认关闭自动索引与自动监视： codebase-memory-mcp config set auto_index false codebase-memory-mcp config set auto_watch false

仪表盘由 codebase-memory-mcp 进程自身提供，仅绑定回环地址，默认 http://127.0.0.1:9749/ 。--ui 与 --port 是全局持久化配置，不应写入任何一个代理的 MCP 参数，否则某一方关闭会影响所有提供方。

适用场景

适用于 C、C++、C#、Python、TypeScript/JS、Go、PHP、Ruby 等项目的结构查询，以及文件/文档结构分析。适合代码探索、调用链分析、依赖梳理、死代码识别、变更影响评估等场景。

限制与注意事项

  • Papyrus（.psc）没有 tree-sitter 语法，不会进入索引；Papyrus 相关问题应使用 Grep 配合 papyrus-reference 技能，而不要用 search_graph。仅含 Papyrus 的模组索引出 2–50 个节点属正常现象。
  • .cbmignore 匹配区分大小写，需同时写大小写两种形式，否则资源目录会泄漏进图谱。
  • 主要膨胀来源：vendored 依赖、多版本快照、二进制资源、单头文件库，应在首次索引前排除。
  • 不要索引：模组管理器暂存目录、游戏 Data 目录、工具安装树、代理会话转储、大型参考语料，以及 .env 和 .env.* 等敏感文件。
  • 名为 nul 等 Windows 保留设备名的文件会导致索引失败并报“Pipeline failed”。
  • query_graph 有 200 行上限；trace_path 需要准确名称；结果默认每页 10 条，需检查 has_more 并使用 offset。
  • 图谱无自动备份，删除项目立即且不可恢复，建议维护已索引项目的登记表。
  • 项目节点的占用与 token 开销随图谱规模增长，因此索引应作为有意识的操作，而非自动行为。