Enola：把架构回归变成 agent 和 CI 都能读的本地检查
AI coding agent 最容易漏掉的不是语法错误，而是“这次改动把结构推歪了”。一个 helper 多 import 了一层，一个服务绕过了原本的边界，一个小修补把调用半径扩大到不该碰的包。编译和测试可能都绿，但代码库的形状已经变了。靠 code review 人肉看这些关系，成本很高；靠模型自己记住所有依赖，也不现实。
今天看的是 enola-labs/enola。它做的是 architecture intelligence：先从本地代码里抽取事实，构成 repository graph，再比较变更前后的结构差异。重点不是把整个老项目的问题一次性倒出来，而是回答一个更具体的问题：这次变更新增了哪些 coupling、layer violation、cycle、scope spillover 或其他结构信号，哪些规则应该让构建失败。
按 GitHub repository API、README、LICENSE、Languages API、Commits API、Tags API 和 Releases API 在 2026-08-27 06:45 Asia/Shanghai 能核验的公开信息，enola-labs/enola 当前有 191 stars、15 forks。仓库主语言显示为 C，Languages API 里还包含 Go、Go Template、C++ 和 Shell。许可证是 Apache-2.0。仓库创建于 2026-02-10 13:18:28 UTC，最近公开 push 是 2026-08-26 18:15:39 UTC，默认分支是 main。最新 release 是 v0.4.8，发布时间是 2026-08-25 09:06:28 UTC。最近一次公开提交是 5163e43，提交时间 2026-08-26 18:15:36 UTC，主题是让 repository-scoped fact 不再被当成变更触碰过的文件。
项目概览
| 属性 | 详情 |
|---|---|
| 仓库 | enola-labs/enola |
| 定位 | 本地代码结构分析、架构回归检查、agent/CI 架构反馈 |
| Stars | 191 |
| Forks | 15 |
| 主要语言 | C |
| 其他语言 | Go、Go Template、C++、Shell |
| 许可证 | Apache-2.0 |
| 创建时间 | 2026-02-10 13:18:28 UTC |
| 最新 push | 2026-08-26 18:15:39 UTC |
| 默认分支 | main |
| 最新 Release | v0.4.8 |
| 关键词 | architecture regression、code graph、CI gate、MCP、agent workflow |
它解决的是“变更造成了什么结构影响”
很多 code analysis 工具会把结果做成一张大地图：依赖图、复杂度热点、调用关系、文件关系。地图本身有价值，但在日常开发里，reviewer 更想知道的是这次 diff 改坏了什么。Enola 的 README 把这个点说得很清楚：它比较 change before 和 after，输出围绕本次变更，而不是把已有技术债全部压到当前 PR 头上。
这个方向适合 agent workflow。Agent 在动手前可以读取 repository graph，理解目标区域的依赖关系；改完后再跑一次检查，把新增 coupling、layer violation、cycle、hotspot、unused route、messaging coverage 等信号交回给 agent 或 CI。这样 agent 不需要凭上下文窗口猜整个系统，它拿到的是从源码解析出的结构事实。
Enola 的另一个取舍是本地运行。README 里强调它不用模型、embedding、上传、账号或 license check 来完成基础分析。对企业代码库和私有仓库来说，这一点比“更智能的总结”更重要：架构检查如果要进 pre-commit、agent hook 或 CI，就应该像 linter 一样稳定、可重复、可审计。
不默认失败，是一个务实设计
我比较喜欢 Enola 的一个细节：它默认报告所有发现，但不默认让构建失败。原因很实际。并不是所有结构信号在所有语言和团队里都同等严重。Go 的 import cycle 已经会被编译器挡住；Rails 或大型前端项目里某些运行时关系又不能简单按静态图判死刑。如果一个工具一上来就替团队宣布“这就是错”，很容易被关掉。
Enola 把 policy 留给项目自己声明。比如你可以只让 layer violation 失败，或把 intent、cycle、constraints 一起设成 gate；也可以用 confidence floor 控制启发式检查。这样它更像一个可以逐步收紧的结构仪表，而不是突然闯进 CI 的强制规则。
这对 agent 尤其有用。Agent 最需要的是明确反馈：这次变更新增了哪条边，违反了哪层边界，影响范围有没有超出目标目录。是否失败可以由项目策略决定，但报告必须具体到足以修复。如果只是给一个“架构风险较高”的自然语言判断，agent 很难稳定地改回去。
MCP 和 hook 让它更像开发循环的一部分
README 里给了两条集成路径。一条是普通 CLI：enola --explain 看当前仓库结构，enola baseline pin 固定变更前结构，enola check 比较变更结果，CI 里再用 --fail-on 指定哪些发现要失败。另一条是面向 agent 的：enola install --hooks 会把说明写入已经存在的 agent 配置文件，并通过 hook 在 session 前后提供结构反馈。
它也提供 MCP 接入方式。Claude Code、Copilot、Cursor、Codex 或其他 MCP client 可以把 enola 当成本地 server，让 agent 在编辑前拿到 graph，在编辑后拿到 verdict。这个能力不花哨，但非常贴合真实问题：agent 的短板不是不会改文件，而是经常不知道某个改动跨过了系统里隐藏的边界。
如果你维护的是多服务仓库、分层后端、插件系统、或业务规则散在多个 package 的 monorepo，Enola 的价值会更明显。它不是替代测试，而是补上测试通常不覆盖的结构变化。测试回答功能是否还过；Enola 回答这次改动是否把结构变复杂、变宽、变绕。
最近维护信号
这个项目虽然不大，但维护信号不错。GitHub API 显示最近 push 在 2026-08-26 18:15:39 UTC，距离这次写作不到一天。最新 release v0.4.8 发布于 2026-08-25 09:06:28 UTC。最近几个提交围绕 repository-scoped fact、reviewer routing 和文档语言收紧，说明作者还在打磨核心模型和开发体验。
README 也不是只有概念图。它给了只读试跑、baseline/check、CI action、agent hook、MCP 配置、Rails wrapper、policy 示例和失败语义。一个架构分析工具如果只展示漂亮的图，很容易停留在 demo；Enola 更关心 verdict 怎么进入开发循环，这一点更接近可用工具。
需要注意的是，GitHub 主语言显示为 C，但 Languages API 里 Go 也占了相当比例。对读者来说，这意味着不要只看 repository language badge 判断技术栈；真正评估前还是应该看安装脚本、release artifact、docs 和源码结构。
适合谁
第一类是已经被 agent 改代码速度推着走的团队。Agent 能快速生成 diff，但 review 压力会转移到“它有没有碰到不该碰的边界”。Enola 能把一部分结构 review 变成可重复检查，让 reviewer 聚焦业务语义。
第二类是 monorepo 或多模块后端。只靠 grep 很难判断一个 import 是合理依赖还是层级反穿。把 layer intent 写下来，再让工具比较变更前后，可以减少“这次只是临时绕一下”的长期成本。
第三类是想把 CI gate 慢慢收紧的项目。你可以先只报告，不失败；等团队认可某些规则之后，再把它们加入 --fail-on。这比一次性引入一堆强规则更容易落地。
Caveats
第一，项目还很年轻。仓库创建于 2026-02-10，当前 191 stars，release 到 v0.4.8。对生产 CI 来说，应该先在只报告模式跑一段时间，观察误报、耗时和团队接受度。
第二，架构规则需要项目自己表达。Enola 可以抽取 graph，但 layer order、intent、target scope 这些东西仍然要团队写清楚。没有策略时，它更像结构观察器；有策略后，才会变成 gate。
第三，静态结构检查不能替代测试、类型系统和 review。它能看见新增依赖、边界穿透、复杂度异常和影响范围，但它不知道业务语义是否正确。最好的用法是把它放在 agent hook、local check 和 CI 之间，成为 review 输入的一部分。
总结
enola-labs/enola 有意思的地方，是把架构问题从“reviewer 凭经验感觉哪里不对”变成了“这次变更新增了哪些结构事实”。它本地解析源码，生成 repository graph，比较 before/after，再把 verdict 交给 agent、CLI 或 CI。
它不适合被当成万能质量门禁，也不应该第一天就把所有启发式检查设成失败。但如果你的团队已经开始让 agent 写更多代码，或者 monorepo 的边界越来越难靠人脑维护，Enola 值得试一次。它补的不是测试覆盖率，而是结构反馈回路。