Enola — deterministic codebase architecture graph

Enola — deterministic codebase architecture graph

Enola 是一个本地 MCP server，用解析器和图算法从代码仓库中抽取确定性的架构图：modules、symbols、routes、storage、dependencies、services 以及 typed relations。它让 AI coding agent 在修改代码前先拥有可查询的结构事实，而不是每次靠 grep 和语言模型猜仓库形状。

为什么对用户重要

用户关注的 agentic coding、context engineering 和 repository exploration 都有同一个瓶颈：agent 经常不是不会写 patch，而是不知道该看哪里、哪些模块相互依赖、修改的 blast radius 是什么。Enola 的价值在于把这部分“应该确定”的结构从 LLM 推理中拿出来，变成可重复计算的上下文工具。

机制 / 一阶原理

Enola 的核心是结构事实优先于语言摘要：

1. 对仓库运行 snapshot，解析多种语言和框架，生成 architecture graph。
2. 节点代表 module、symbol、route、storage、dependency、service 等 kind。
3. 边代表 declares、imports、calls、implements、depends_on 等 typed relations。
4. MCP 工具向 agent 暴露 query_facts、traverse、find_path、impact_analysis、show_symbol 等操作。
5. Agent 的探索从“读一堆文件并猜”变成“先查询结构，再有目的地读源码”。

这与 Context-Engineering 的一阶原则一致：把隐性、重复、易错的上下文获取变成可维护基础设施。

和已有 wiki 概念的关系

• Repository-Exploration：Enola 提供结构化探索工具，可作为 SWE-Explore 类任务前置上下文。
• Context-Engineering：它是代码仓库上下文的确定性 provider，而非自然语言长文档。
• Harness-Engineering：在 coding harness 中，Enola 可成为 agent 可调用工具层的一部分。
• Agentic-Coding：让 agent 把智能用于设计/修改，而不是重复恢复仓库地图。

对 Hermes / llm-wiki 的可执行启发

1. 对大代码库任务，先生成结构 snapshot，再让 agent 做 patch；这比直接“全局搜索 + 猜”更可控。
2. Hermes 的代码技能可以区分三类上下文：确定性结构图、人工维护的 spec/wiki、实时工具输出。不要把三者混成一个长 prompt。
3. llm-wiki 自身也可以借鉴：将 wiki graph 中页面、来源、概念、写入记录做成可查询结构层，减少纯文本搜索误差。
4. 对 refactor 任务，要求 agent 先给出 impact path / reverse dependency 证据，再写代码。

失败模式与边界

Enola 不是语义理解替代品：结构图告诉你“谁调用谁”，不必然告诉你业务意图、历史决策或隐性约束。解析器也可能落后于新框架、动态语言元编程或运行时配置。最稳妥的用法是把它作为 repository exploration 的第一层，再结合测试、spec、wiki 和人工判断。

写入记录

• 2026-07-03 09:00 CST：新增 Enola source 页，分析确定性仓库结构图、MCP 工具层和对 repository exploration 的启发。