Repo Graph

repo-graph

面向 AI 编码助手的结构化图记忆。映射代码库。按结构导航。只读取所需内容。

repo-graph 为大模型提供代码库地图——包含实体、关系和流程——让它们无需先通读所有内容，就能找到正确的文件。

repo-graph 不会把整个代码库塞满大模型的上下文窗口（也不会寄希望于它能猜对），而是构建轻量级图谱，展示现有内容、各部分之间的连接方式以及入口位置。大模型查询图谱，找出所需的最少文件，然后只读取这些文件。

它最适合那些手动完成这件事最困难的场景：大型代码库、横跨多种语言的单体代码库，以及多服务系统，因为功能的实现路径会跨越文件、技术栈和服务边界。对于小型的单语言项目，模型直接读取文件即可——请参阅最适用的场景，了解其真正适合的范围。

一键安装：

或者，在终端中运行一条命令，即可为你使用的所有 Agent 完成配置：uvx mcp-repo-graph install（参阅安装）。

---

升级到 0.5.2

大多数人无需进行任何操作。 uvx 和 pip install mcp-repo-graph 会拉取新的引擎（glia 0.5.1，精确锁定版本）。.glia/graph/ 中缓存的图采用了新格式，因此每个仓库首次启动时会重建一次。之后就恢复正常了。

只有在同一仓库中还运行 glia 自带的 CLI 钩子（glia install-hooks）时才需要操作。也请从 v0.5.1 标签重新安装 CLI。如果 CLI 和服务使用的 glia 版本不同，每次提交时它们都会重建对方的缓存。

如果团队使用 repo-graph 的 pre-commit 钩子提交缓存，情况也一样：下次提交时会以新格式重新添加缓存一次；仍在运行 glia 0.5.0 引擎的服务则会在每次加载时重建缓存，直到升级为止（如果是作为 uv 工具安装的，请运行 uv tool upgrade mcp-repo-graph）。

改进之处：图谱更丰富（挂载的 Go 路由会保留其前缀，前端端点会通过其基础 URL 配对，更多调用可以解析）；read 会显示 WebSocket / gRPC / GraphQL 客户端连接的主机；服务也不会再在长时间运行时逐渐占用更多内存。

⚠️ 升级到 0.5.0

引擎包从 repo-graph-py 更名为 glia-py。 如果通过 uvx 或 pip install mcp-repo-graph 安装，无需进行任何操作。新引擎会自动拉取。

只有在直接导入引擎时才需要操作：

- import repo_graph_py as rg
+ import glia_py as rg

同一版本中还有另外三项变更：

• 返回结果是 Python 对象，而不是 JSON 字符串。 find、resolve、blast_radius、 cross_stack_trace 和 governing_docs 会返回 {"results": [...], "absence": {...}} 字典。 如果你曾对结果调用 json.loads(...)，请移除这一步。
• find_node 和 find_nodes_by_qname 已移除。 两者都由一个 find(query, top_k) 取代。
• 图缓存从 .ai/repo-graph/ 移到了 .glia/graph/。 它会自动重建，因此可以删除旧目录。新目录会忽略自身，且不会出现在 git status 中。

六个 MCP 工具保持不变（orient、find、impact、trace、read、refresh），因此无需修改 Agent 配置。详情请参阅 0.5.0 版本说明。

演示

https://github.com/user-attachments/assets/a1e4171b-b225-40d4-9210-39453e14b76a

https://github.com/user-attachments/assets/fc3191e5-fc35-4bd7-8372-72af55995883

同一个 bug、同一个模型、同一个提示词——唯一的区别是是否安装了 repo-graph。

任务： 修复 Go + Angular 单体仓库中的一个反向比较运算符。

（录制时使用的是较早版本的引擎，它将该仓库映射为 566 个节点 / 620 条边。glia 0.5.1 引擎能从相同代码中提取更多内容：3,466 个节点和 6,869 条边（测量日期为 2026-10-02），因此模型如今获取的图比视频中的更丰富。Token 数量和耗时数据来自录制的运行，并按测量结果保留。）

	不使用 repo-graph	使用 repo-graph
使用的 Token	75,308	29,838
修复耗时	4m 36s	~30s
探索的文件	~15（grep、read、grep、read……）	2（trace 查找 + 处理程序文件）
结果	找到并修复了 bug	找到并修复了 bug

Token 数量减少 2.5 倍，速度提升约 9 倍。修复结果同样正确。

测试运行方式

两次运行采用了相同的条件，以确保比较公平：

• 相同的模型：Claude Opus，100%（不路由到 Haiku）
• 相同的提示词："最近创建的群组显示为已关闭，而旧群组显示为已开启。这恰好反了——新群组应该处于开启状态，以便成员加入。请找出并修复这个错误。"
• 全新上下文：每次运行都从 /clear 开始，没有之前的对话
• 不使用其他工具：两次运行都移除了 CLAUDE.md、插件、钩子和所有其他 MCP 服务——唯一的变量是是否安装了 repo-graph
• 没有提示：提示词描述的是症状，而非位置——Claude 必须自行找到 group_controller.go:57

不使用 repo-graph 时，Claude 会搜索关键词、读取文件、再次搜索、读取更多文件，最终逐步定位到错误。使用 repo-graph 时，Claude 调用 trace("groups")，即可获得确切的处理函数和文件，然后读取并修复它。

浏览 预生成示例，查看 FastAPI、Gin、Hono 和 NestJS 的示例——这些是真实的图输出，无需安装即可查看。

问题所在

处理代码时，大模型的大部分上下文都浪费在了解项目结构上：

• 读取后来发现无关的文件
• 忽略不同语言组件之间的联系
• 不知道某项功能从哪里开始，或会影响哪些部分
• 明明读取 5 个文件就够，却加载了 50 个文件

这既耗费资源、速度又慢，而且代码库越大，问题越严重。

repo-graph 如何解决这个问题

repo-graph 会扫描一次代码库，并构建以下内容的图：

• 实体：模块、包、类、函数、路由、服务、组件
• 关系：导入、调用、处理、定义、包含、跨技术栈 HTTP 调用
• 流程：从入口点到数据层的端到端路径

然后，它会提供 6 个 MCP 工具，让大模型可以：

1. 了解结构——“这个代码库使用了哪些语言？主要功能有哪些？图中有哪些盲区？”
2. 导航——“从路由到数据库，追踪登录流程。”／“UserService 与支付 API 之间的最短路径是什么？”
3. 界定范围——“此错误涉及哪些节点？”／“只给我修复所需的文件。”
4. 评估影响——“更改此函数会造成多大影响？”／“这里有哪些死代码？”

大模型只需几百个 token 就能获得结构化上下文，而不必读取数千行代码。

最适用的场景

当代码库比模型一次能理解的范围更大或结构更复杂时，repo-graph 就能发挥作用。它带来的收益取决于以下三点：

• 规模 — 文件足够多，读取相关文件就会超出上下文预算。
• 复杂度 — 存在规则、间接调用和分层，“直接读代码”不再奏效。
• 跨边界范围 — 答案涉及多个文件、语言或服务，而文本搜索无法将它们关联起来。

特别适用的场景：

• Monorepo — 前端跨语言调用后端。repo-graph 会将 HTTP 调用关联到它所命中的路由及其背后的处理程序，而文本搜索做不到，因为两端没有共用字符串。将 --repo 指向 Monorepo 根目录，单张图谱即可覆盖所有项目。（上面的演示就是这种情况：同一个仓库中包含 Go + Angular。）

  其他工具可以将 fetch/axios 关联到 Express、Fastify 和 Koa 路由。这里的不同之处在于覆盖范围：同样的关联可以在一个图谱中跨越 Go、Python、Java、C#、Rust、PHP、Ruby 等语言，并同等覆盖 gRPC、GraphQL、WebSockets、队列和事件。这种广度并未与其他工具进行基准测试，因此应将其视为设计上的差异，而非经测量验证的优势。

• 多服务 / 多仓库系统 — 将各个服务放在同一目录下，并将 --repo 指向该目录；图谱就能在一次调用中跨服务边界追踪某项功能。

• 大型单体代码库 — 包含数千个文件，仅了解代码结构本身就要付出成本。

• 不熟悉或遗留代码 — 还不清楚各部分之间的关联时。

不太适用的场景：任务明确的小型单语言仓库。模型可以直接读取文件——grep 更高效，而图谱只会增加开销。也别为了减少令牌数而使用它：MCP 层每轮都会产生固定开销，因此处理简单任务时，成本可能更高。只有在它能避免 grep-读取-grep 的循环（如上面的演示）时，才会节省令牌。对于大到无法放入上下文、或相互关联过于复杂的代码，无论是对你还是对模型而言，它可靠带来的价值都是：只需几次调用，就能获得准确、完整且跨边界的答案。（不想使用 MCP 层？跳过它，直接调用引擎。）

不使用 MCP

MCP 服务是无需配置的使用方式，但图谱并不依赖它。引擎以纯 Python wheel 的形式提供——pip install glia-py——因此你可以构建图谱，并通过脚本或自己的工具直接调用相同的答案原语，无需承担每轮 MCP 开销：

import glia_py as rg

g = rg.load_from_gmap(rg.default_gmap_dir("."), ".")   # builds it if there's no cache yet

g.find("checkout")                              # ranked, located nodes for a name
g.blast_radius(["checkout", "Cart.add"], "both")  # many seeds, one walk, one ranking
g.cross_stack_trace("notifications")            # feature path across the stack, mechanism-labelled
g.resolve(open("error.log").read())             # stacktrace / test / diff → the nodes that matter
g.coverage()                                    # where extraction is partial (grep those)

这些调用都会返回纯 Python 数据——查询结果会返回 {"results": [...], "absence": {...}} 字典，coverage() 会返回列表。当 results 为空时，absence 会说明原因，脚本可以据此分支处理，而不必猜测。

图谱不变，答案不变——只是上下文中没有工具架构定义。它使用的正是 MCP 服务封装的同一个 Rust 引擎（glia）；glia-py 是该引擎发布的 wheel。适用于 CI 检查、批量分析，或将图谱接入你自己的 Agent。

支持的语言

语言	检测方式	提取内容
Go	go.mod	包、函数、HTTP 路由（gin/echo/chi/stdlib）、导入
Rust	Cargo.toml	Crate、模块、结构体、trait、函数、路由（Actix/Rocket/Axum）
TypeScript	tsconfig.json / package.json	模块、类、函数、导入关系
React	package.json 中的 react	组件、hooks、上下文提供程序、React Router 路由、fetch/axios 调用、流程
Angular	package.json 中的 @angular/core	组件、服务、守卫、DI 注入、HTTP 调用、功能流程
Vue	package.json 中的 vue	SFC、组合式函数、Vue Router 路由、fetch/axios 调用
Python	pyproject.toml / setup.py / requirements.txt	包、模块、类、函数、路由（Flask/FastAPI/Django）
Java/Kotlin	pom.xml / build.gradle	包、类、路由（Spring/JAX-RS/Ktor/WebFlux/Micronaut）
Scala	build.sbt	包、对象/类/trait、路由（Play/Akka HTTP/http4s）
Clojure	project.clj / deps.edn	命名空间、defn/defprotocol/defrecord、路由（Compojure/Reitit）
C#/.NET	.csproj / .sln	命名空间、类、路由（ASP.NET/Minimal API）
Ruby	Gemfile / .gemspec	文件、类、模块、Rails 路由
PHP	composer.json	命名空间、类、接口、路由（Laravel/Symfony）
Swift	Package.swift / .xcodeproj	文件、类型（class/struct/enum/protocol/actor）、Vapor 路由
C/C++	CMakeLists.txt / Makefile / meson.build	源文件、头文件、类、结构体、枚举、命名空间、包含项
Dart/Flutter	pubspec.yaml	模块、类、组件、go_router/shelf 路由
Elixir/Phoenix	mix.exs	模块、函数、Phoenix 路由器作用域和路由
Solidity	.sol 文件 / foundry.toml / hardhat.config.*	合约、接口、库、事件、继承关系
Terraform	.tf 文件	模块、资源、变量、输出、模块源
SCSS	存在 .scss 文件	文件级臃肿分析

跨语言提取器（适用于所有语言）：

• 跨栈 HTTP：将前端 fetch/axios 调用关联到其访问的后端路由及其处理程序
• WebSockets：处理程序和客户端（gorilla、浏览器、Python、Java、C#），按路径配对
• gRPC：从 .proto 提取服务、方法和消息类型，以及客户端存根和服务端实现
• GraphQL：解析器及调用它们的操作
• 队列：消费者和生产者（Celery、Dramatiq、BullMQ、Sidekiq、Oban、NATS），包含解析常量后的主题
• 事件：发射器和处理程序
• Cron 作业：计划任务入口点
• 页面导航：前端路由及其之间的链接（NAVIGATES_TO）
• 数据源：数据库 / 缓存 / 队列 / Blob / 搜索 / 邮件客户端，以及哪些代码会访问它们
• 数据实体：共享架构及读写这些架构的代码
• CLI 入口点：Python click、JS commander/yargs、Go cobra、Rust clap、Java picocli、C# System.CommandLine 和 Spectre
• 契约：将 OpenAPI / AsyncAPI / Pact 操作关联到实现它们的路由
• 依赖注入：将构造函数注入关联到被注入的对象
• 配置键：键的定义位置及所有读取该键的位置
• 基础设施：Terraform 和 Kubernetes 资源
• 文档：将文档章节关联到其约束的符号（read 显示为 governed by 的内容）
• 测试：各项测试覆盖的代码

一个仓库可以匹配多种语言（例如，Go 后端 + Angular 前端 + SCSS）。每种语言都会将其节点和边加入同一个统一图中。

安装

一条命令

uvx mcp-repo-graph install

此命令会检测你已安装的 AI 编码 Agent（Claude Code、Claude Desktop、 Cursor、Windsurf、VS Code、Codex、Gemini CLI、opencode、Kiro），写入各自的 MCP 配置，并在其指令文件中添加一段简短的用法说明，让 Agent 在搜索代码前先使用图谱。对于支持此功能的 Agent，它还会授予自动允许权限，这样调用 repo-graph 工具时就不会每次都弹出提示。

可以安全地重复运行；uvx mcp-repo-graph uninstall 会还原所有更改 （配置、指令、权限），同时保留你的图谱数据。

uvx mcp-repo-graph install --agents all          # every supported agent, not just detected
uvx mcp-repo-graph install --scope user          # your global config, not this project
uvx mcp-repo-graph install --dry-run             # show what it would write, change nothing
uvx mcp-repo-graph install --yes                 # no prompt (scripts and CI)
uvx mcp-repo-graph install --print-config cursor # print one agent's config, write nothing

手动配置各客户端

如果你更愿意自行配置，包名就是运行命令。 uvx mcp-repo-graph 开箱即用。无需预先运行 pip install，也无需在 PATH 中保留任何内容。VS Code、Cursor 和 MCP 注册表底层使用的也是同一条命令。

**要求：**Python 3.11+；如果使用 uvx 方式，还需要 uv。 Rust 引擎提供适用于 Linux（x86_64、aarch64）、 macOS（Intel + Apple Silicon）和 Windows（x86_64）的预编译 wheel，无需安装 Rust 工具链。

Claude Code

claude mcp add repo-graph -- uvx mcp-repo-graph --repo .

（--repo . 会将图谱指向当前项目；使用绝对路径可固定其位置。）

VS Code

一条命令即可将服务添加到用户配置中：

code --add-mcp '{"name":"repo-graph","command":"uvx","args":["mcp-repo-graph","--repo","${workspaceFolder}"]}'

也可以点击 MCP gallery 条目上的 Install， 或手动将其添加到 .vscode/mcp.json（见下文）。

Cursor / 任意 MCP 客户端 — 手动配置

将以下内容添加到客户端的 MCP 配置（.mcp.json、.cursor/mcp.json、 .vscode/mcp.json 或 ~/.claude.json）中：

{
  "mcpServers": {
    "repo-graph": {
      "command": "uvx",
      "args": ["mcp-repo-graph", "--repo", "/path/to/your/project"]
    }
  }
}

更喜欢持久安装？运行 pip install mcp-repo-graph（或 uv tool install mcp-repo-graph），即可在 PATH 中添加 mcp-repo-graph / repo-graph 命令；然后在上面的配置中使用 "command": "mcp-repo-graph"。

**--repo 也接受 git URL。**无需先克隆，即可指向任意公开仓库——它会浅克隆并为其构建映射（需要 git）：

uvx mcp-repo-graph --repo https://github.com/org/repo

快速开始

1. 初始化目标仓库（可选）

uvx --from mcp-repo-graph repo-graph-init --repo /path/to/your/project
# or, if installed:  repo-graph-init --repo /path/to/your/project

此命令会生成图谱、写入 .mcp.json 和 CLAUDE.md 指令，并让你的 AI 助手能够使用 repo-graph。如果你使用了上面的一行命令，可以跳过这一步——服务会在首次连接时构建图谱。

2. 使用

AI 助手现在可以使用全部 6 个工具。它可以回答的问题示例：

• “这个代码库是做什么的？” → orient 工具
• “追踪结账流程” → trace 工具
• “如果我更改 UserService，会有什么影响？” → impact 工具
• “哪些节点与这个 bug 有关？” / “这是一个堆栈跟踪——我该从哪里查起？” → find 工具
• “显示该函数的源代码” → read 工具
• “以较低成本提供完整的图谱上下文” → orient full=true
• “大型重构后重新构建” → refresh 工具

3. 保持最新（自动）

图谱会自动保持最新。服务运行期间，它会监视仓库，并在你保存文件后不久执行增量重建，因此编辑后立即提出结构相关问题，无需手动运行 refresh，得到的结果也会反映更改。此外，图谱会在冷启动时自动修复——如果缓存的 .gmap 已过时、格式过旧或缺失，引擎就会重新构建并写回，因此助手连接时图谱始终是最新的。

监视器默认启用。设置 REPO_GRAPH_WATCH=0 可将其禁用（冷启动刷新仍会执行）。它需要 watchdog 包，该包已作为依赖项提供。

想预先构建并提交缓存，让队友和 CI 也能使用？自动添加 pre-commit 钩子：

uvx mcp-repo-graph install --agents none --git-hook

此操作会安装带标记边界的 pre-commit 钩子，在每次提交时刷新图谱，并暂存 .glia/graph/。再次运行 uvx mcp-repo-graph uninstall 即可将其移除。

**提示：**图谱目录会忽略自身（.glia/graph/.gitignore），因此除非钩子使用 git add -f 将其暂存，否则它不会出现在 git status 中。跳过钩子也没关系，监视器和冷启动刷新会在本地保持图谱最新。

MCP 工具参考

repo-graph 提供 6 个工具——每个工具对应一个自然动词，由 Rust 引擎原语提供支持。

工具	参数	描述
orient	seed （可选）、full、budget	在仓库上进行的首次调用：节点/边数量、检测到的类型、入口点，以及一条盲区提示，指出哪些语言/边的关联不足（因此你可以有针对性地使用 grep）。seed=<node> → 范围限定的映射；full=true → 整个仓库的稠密映射
find	query、expand、kind、top_k、budget	将任意文本转化为按相关性排序的节点——符号/关键词，或粘贴的堆栈跟踪/失败测试 ID/diff（解析为其涉及的代码）。expand=true 会扩展到周边邻域。每行都带有 path:line
impact	nodes （逗号分隔）、direction、depth、live_only、top_k、budget	影响范围：某项更改会影响什么（forward），或依赖于什么/被什么使用（backward），结果是按相关性排序并附带位置的闭包——每行都包含边的 via 原因，以及当引擎发现其不可达（可能已死）时标注的 ⊘。传入多个节点可查看整个 diff 的影响范围
trace	from_node、to_node （可选）、depth、budget	一个参数：从头到尾追踪某个跨栈功能，每一跳都标注其机制（调用 / HTTP / 队列 / 事件），并标记跨服务跳转。两个参数：查找两个节点间的最短路径
read	node （逗号分隔）、context_lines、budget	节点的精确源码，按图谱中的行范围从文件切取，并附带 context: 页脚（HTTP 方法、跨栈调用方或客户端的拨号目标、覆盖该节点的测试、相关规范文档）。用逗号分隔可批量读取一组按相关性排序的节点
refresh	repo_path （可选）、full	重建图谱（默认增量更新——只重新解析已更改的文件）。repo_path 可将目标改为其他路径或 Git URL；full=true 会强制进行干净的重新解析。常规编辑会由文件监视器自动检测

大多数工具还接受 budget（最大字符数），以便结果能放入小模型的上下文窗口。

随着引擎增加了能直接生成答案的原语——find、blast_radius、cross_stack_trace、resolve、coverage——这 6 个工具由早期的 13 个精简而来；这些原语可通过一次调用返回完整、按相关性排序、附带位置并经过实时筛选的结果。工具越少 = 每轮固定开销越低，Agent 越不容易困惑。

当它不知道时，它会告诉你

大多数工具遇到空查询时只返回空结果，让助手只能猜测这究竟意味着“没有这样的边”，还是“我没能看到它”。从 0.5.0 起，空结果会以结构化的缺失信息形式返回：缺失的原因、该原因属于事实还是启发式判断，以及对于导致空结果的机制，哪些提取结果不完整。

  No answer (no_edges, FACT): no carry edge touches `backend::server::server` in this graph;
  `backend::server::server` is a container: structural IMPORTS/CONTAINS/DEFINES are not carry
  edges, so seed a symbol inside it
    looked over: CALLS
    blind spots (grep to confirm):
      ⚠ CALLS (*): calls through reflection, dynamic dispatch, or higher-order indirection are
        not resolved — verify: grep the callee name
    searched 26 nodes

orient 会提前显示同样的盲区，让模型知道何时应使用 grep，而不是相信缺失的信息。

我们的测量结果。 在 FastAPI、Gin、Hono 和 NestJS 中测试了 14 个符号，每个案例都是图谱中确实没有边、但实际存在调用方的情况。使用相同的 Agent 和任务，唯一的区别是空答案是否解释了自身。结构化的缺失信息在相同任务中的成本降低了约 3 倍，28 组配对测试全部如此，轮数相同：得知答案为空的原因后，Agent 就不会再重复查询。它没有改变正确性。Sonnet 5 在全部 56 次运行中都回答“删除不安全”；因此，如果你希望这能阻止 Agent 删除仍在使用的代码，我们没有证据支持这一点，而且有一些证据表明，在谨慎的模型上并非如此。测试框架和原始结果见 bench/absence/。测试仅使用一个模型，n=14，且测试框架由我们自行编写：请将其视为趋势性结果。

0.5.0 还新增了可通过一次调用分析整个 diff 的 impact（未解析的名称会被报告，而非丢弃）、在 trace 中按相关性排序的不同跨栈路径，以及感知角色的标签，避免将已声明的组件或服务一概归为“类”。

工作原理

mcp-repo-graph 是一个轻量级 Python MCP 服务，封装了 Rust 引擎 glia。

1. 解析 — 各语言的 tree-sitter 解析器提取原始节点和未解析的引用
2. 提取 — 跨领域提取器进一步处理 HTTP 路由、数据源、CLI 入口点、gRPC 服务和队列消费者
3. 解析引用 — 图构建器解析仓库内部引用；跨图解析器则关联不同技术栈（前端 HTTP 调用 → 后端路由等）
4. 存储 — 合并后的图以零拷贝分片 .gmap（rkyv + mmap）及清单文件的形式存放在 .glia/graph/ 中
5. 提供服务 — MCP 服务将图加载到内存中，并提供 6 个工具

Rust 引擎位于独立的 glia 仓库中；mcp-repo-graph 是面向 MCP 的轻量级封装。

布局检测

repo-graph 会自动查找项目 — go.mod、package.json、pyproject.toml、Cargo.toml、 pom.xml、build.gradle、composer.json、pubspec.yaml、mix.exs、Package.swift、 CMakeLists.txt 等。将 --repo 指向单体仓库根目录，其中的所有项目都会纳入同一张图。

它也会自动剪枝：node_modules、vendor、.venv、site-packages、构建输出目录 （dist、target、.next、.nuxt、.angular、coverage）和带哈希的打包目录会折叠为单个区域锚点，而不是逐个解析文件；同时也会遵循 .gitignore。

注意： 早期版本的文档提到过使用 skip: / roots: 键的 config.yaml 备用配置。 这是 Python 时代的功能，Rust 引擎不会读取它 — 如果你有这个文件，它会被忽略。如果自动检测未能识别你的布局，请 提交 issue，并说明仓库的结构； 这比使用没人能看到的配置文件更有帮助。

图数据格式

生成的文件位于目标仓库中的 .glia/graph/：

• repo-<id>.gmap：图本身，以零拷贝 rkyv 格式分片存储（加载时使用 mmap）
• manifest.json：格式版本、仓库标签、根目录和解析错误，确保热加载与重新生成的结果一致
• parse_cache.bin：按文件内容哈希的解析缓存，因此增量重建只会重新解析已编辑的文件
• .gitignore：该目录会忽略自身，因此不会出现在 git status 中

整个目录都会重新生成：删除该目录后，下次调用时会重新构建。

该引擎包含 36 种边类别。最常见的有：CALLS、IMPORTS、 CONTAINS、DEFINES、USES、HANDLED_BY、HTTP_CALLS、IMPLEMENTS、INHERITS_FROM、 INJECTS、ACCESSES_DATA、TESTS、DOCUMENTS、NAVIGATES_TO，以及通道类边 （GRPC_CALLS、QUEUE_FLOWS、WS_CONNECTS、EVENT_FLOWS、GRAPHQL_CALLS、RPC_CALLS）。 共有 49 种节点类型。这两份列表都由引擎提供，因此 orient 始终会报告你当前版本实际支持的集合。

隐私政策

repo-graph 在你的设备上运行，旨在确保代码留在本地。完整内容请见：PRIVACY.md。

• 遥测 / 分析： 无。不会跟踪、检查更新或向外发送数据。
• 数据收集与共享： 无。你的源代码和图数据绝不会发送给 repo-graph、其作者或任何第三方。
• 本地处理与存储： 扫描和图构建都在本地进行；图会缓存在项目的 .glia/graph/ 目录中，并保留在你的设备上。
• 网络访问 — 仅限以下两种情况，且均由用户主动发起：
  1. 安装 — uvx/pip 会从 PyPI 下载软件包及其预构建引擎 wheel。
  2. Git URL 目标 — 如果你将 Git URL 传给 --repo，repo-graph 会对你指定的 URL 执行 git clone；不会向 repo-graph 或其作者发送任何内容。使用本地 --repo 路径（默认行为）时，不会进行任何网络调用。
• 数据保留： 本地缓存会一直保留，直到你将其删除 — 完全由你掌控。
• 联系方式： GitHub issues

许可证

MIT

支持

如果 repo-graph 为你节省了时间，欢迎请我喝杯咖啡。

buymeacoffee.com/polycrisis