Enola 完全指南：给 AI 编码 Agent 的确定性架构依赖图

AI 编码 Agent（Claude Code、Cursor、OpenCode）固然强大，但它们有一个根本性的缺陷——非确定性。每次启动新会话，Agent 都要重新 grep 你的代码、逐文件阅读、猜模块之间的关系。它可能猜对 90%，但剩下的 10% 足以产生令人头疼的诡异 bug：改了 A 模块，没意识到 B 模块依赖它；删了一个路由，不知道还有个前端页面在用。

今天介绍的 Enola（GitHub 52⭐，Apache-2.0）是一个本地运行的 MCP 服务器，它的核心思路是：把代码架构变成可查询的确定性事实，不让 Agent 去猜。

Enola 是什么

Enola 不做代码补全，不做代码生成，只做一件事：把你的代码库的真实结构——模块、类型、路由、依赖关系——提取成一个有向图，并通过 MCP 工具暴露给 AI 编码 Agent。

关键区别在于「提取」而非「推测」。Enola 用语言解析器（tree-sitter）和图算法从源码中读取真实的类型关系和依赖边，而不是让大模型去总结。同一次 commit 跑两次，得到完全相同的结果——这是确定性。

30 秒快速体验

安装 Enola 不需要 Go 工具链，直接下载预编译二进制：

curl -fsSL https://raw.githubusercontent.com/enola-labs/enola/main/install.sh | sh
export PATH="$HOME/.local/bin:$PATH"

连接到 Claude Code：

claude mcp add enola enola

然后在 Claude Code 中发一条指令：

“Generate an architectural snapshot of /path/to/my/project”

几毫秒后，Agent 就拿到了你项目的完整架构地图。从此问”这个模块依赖什么”、”如果我改这个接口，哪些文件受影响”，Agent 直接回答——不再需要 grep 和猜测。

核心概念：Kinds 和关系

Enola 把你的代码建模成一个图，包含以下几类节点（称为 Kinds）：

节点之间有类型化的有向边：declares、imports、calls、implements、depends_on。因为是类型化的有向图，你可以在这上面做计算——不仅仅是搜索。

十种 MCP 工具详解

Enola 提供了 10 个 MCP 工具，覆盖从项目摸底到变更验证的完整工作流：

1. generate_snapshot — 建立快照

这是入口工具。生成当前仓库的架构快照，结果写入 .enola/ 目录：

enola --generate

MCP 模式下通过 Agent 调用：

“Generate a snapshot of /path/to/project”

需要分析多个仓库？用 append 模式：

“Generate a snapshot of /path/to/backend with append mode”

Enola 会跨仓库链接依赖关系——后端改了接口，前端能感知到影响。

2. explore — 模块导览

想知道某个模块里有什么？谁在用它？用 explore：

“Explore the module src/services/auth”

返回该模块的所有符号、依赖和被依赖信息——相当于一次架构级的 ls -la。

3. query_facts — 精确查询

列出特定类型的全部事实，不遗漏：

“List every HTTP route” “List every external dependency”

返回的是精确的枚举结果，不是大模型的摘要总结——有多少条就是多少条。

4. query_insights — 自动发现

Enola 会计算一些内置的分析结果：

• Unused routes — 客户端代码未调用的后端端点（清理候选）
• Cycles — 循环依赖
• God classes — 高扇入的符号（太多东西依赖它）

“What are the architectural risks?”

Enola 会返回所有发现的问题，按置信度排序。

5. show_symbol — 跳转到源码

“Show me the symbol UserService.FindByID”

直接返回该符号的源码位置和内容——不用让 Agent 再去 grep 文件路径。

6. traverse — 遍历依赖

回答两类问题：

“What does the payment module depend on?”（出边遍历） “What depends on the payment module?”（入边遍历）

这个工具有多步跳转能力——A 依赖 B，B 依赖 C，traverse 能一路走到 C。

7. find_path — 最短路径

“How does the web client call the auth service?”

返回两个节点之间的完整调用链。在多仓库分析中，这个工具特别有用——前端组件 → API 调用 → 后端路由 → 数据库查询，一路追踪到底。

8. impact_analysis — 爆破半径分析

这是 Enola 最强大的工具。回答经典问题：

“If I change the interface UserService, what breaks?”

Enola 计算所有传递性依赖该符号的代码——按距离分组（1 跳、2 跳、3 跳），并跨越仓库边界：

Impact analysis: change 'internal/server/auth.go' 
  Direct dependents (1 hop): 12 files
  Indirect dependents (2 hops): 43 files
  Indirect dependents (3+ hops): 87 files
  Cross-repo impact: 2 files in web-client

不知道影响范围就动手改代码，是重构中最危险的错误。impact_analysis 让这个风险变得可量化。

9. set_baseline + diff_snapshot — 变更验证

这是闭环工具。工作流是三步：

1. 改之前：set_baseline 记录当前架构快照
2. 让 Agent 改代码
3. 改之后：generate_snapshot → diff_snapshot

diff_snapshot 只报告变动——新增了哪些符号、移除了哪些、依赖关系怎么变化的。它不是 linter，不会报预存量的问题，只报增量：

Diff vs baseline:
  Added symbols: 3 (NewService, NewHandler, NewRoute)
  Removed symbols: 0
  New coupling: OldModule → NewService
  Resolved findings: unused-route DELETE /api/v1/legacy

这比让 Agent 自己读文件确认「我改了什么」要可靠得多——Agent 可能会说「改了 X」，而 diff 告诉你它还顺便改了 Y。

10. coverage_report — 跨仓库边界覆盖

多仓库分析时，有些依赖是 Enola 无法解析的（比如手动 curl 调用、cron 任务的外部请求）。coverage_report 告诉你哪些跨仓库边被覆盖了、哪些没被覆盖，避免你在覆盖率缺口下做出错误的删除决定。

enola --explain：不用 Agent 也能看懂架构

除了 MCP 工具，Enola 还有一个独立模式：

enola --explain /path/to/repo

这会生成快照、计算统计数据、输出一份人类可读的架构报告，包含：概览、Kinds 计数、API 和数据面、依赖分析、架构模式检测、热点模块分析、代码健康度。

开发者可以用它快速了解一个新项目——而不是花半小时翻目录结构。上面演示中对 Apache Airflow 的分析（112,792 个事实，3.5 秒完成）就是一个很好的例子。

实战场景：处理遗留系统

假设你要重构一个五年历史的后端服务，里面 200 多个文件，没人能说清楚哪些代码还在用。传统做法：仔细阅读、做笔记、逐个文件追踪——可能要花一周。

用 Enola 的方式：

1. generate_snapshot — 建立架构快照（毫秒级）
2. query_insights(explainer='unused-routes') — 找出无调用者的端点
3. 对每个候选端点用 impact_analysis — 确认确实没人用（包括跨仓库调用者）
4. 安全删除 — 只在确认无依赖后才动手

整个过程可能只需要几个小时，而非几天。关键在于 Enola 的答案是确定性的——同一个查询在同一次 commit 上永远返回相同结果，不存在「Agent 这次没 grep 到就以为没人用」的情况。

需要注意

1. 大型仓库的首次索引：如 Linux 内核级别的大型仓库，首次冷索引可能需要一分钟以上，可能触发 MCP 客户端的工具调用超时。解决方案：先用 enola --generate 在 shell 中预热，再启动 MCP 服务器。
2. 不要求配置文件：Enola 零配置开箱即用，所有设置都有合理默认值。mcp-arch.yaml 是可选的覆盖配置。
3. 依赖了已安装的编码 Agent：Enola 本身不包含 AI 能力，它是一个 MCP 服务器，需要通过 Claude Code 或其他 MCP 兼容的 Agent 来调用。
4. 不支持的语言用 tree-sitter 兜底：14 种主流语言都有专门的提取器，其中 Python/Ruby/PHP 用 tree-sitter 深度支持（含函数调用边），Java/Go/TypeScript 有框架感知。

总结

Enola 解决的不是「Agent 能不能写代码」，而是「Agent 能不能理解代码」。它把代码架构变成 Agent 可以直接查询的事实——类型化的依赖图、精确的 blast radius 分析、可复现的变更验证。对于正在使用 AI 编码 Agent 做中型以上项目的团队，Enola 是一个值得加入 MCP 配置的工具。

GitHub 仓库：github.com/enola-labs/enola 许可证：Apache-2.0 安装方式：curl -fsSL https://raw.githubusercontent.com/enola-labs/enola/main/install.sh | sh 支持的 Agent：Claude Code、Cursor、OpenCode 及其他 MCP 兼容客户端