机制篇：透明代理接管，无缝统一你的项目上下文

Mantra: The MCP Hub

上一篇我们画了个大饼，说要把 Mantra 做成一个全方位的本地 MCP Hub。愿景挺美好，但真要把这东西跑起来，大家最担心的可能就是迁移成本：

"我现在用的 Cursor 已经配了十几个 MCP Server 了，难道要我一个个手动挪过去吗？" "Mantra 会不会改乱我的项目配置文件？万一想换回来怎么办？"

作为开发者，我们最讨厌的就是工具带来的"迁移负担"。所以，Mantra 搞了一套 透明代理接管 (Transparent Takeover) 机制。

这一篇，我们就来拆解 Mantra 是怎么通过 发现 -> 导入 -> 重定向 这三步，实现所谓的"无感"升级。

I. 第一步：全域扫描 (Discovery)

要处理碎片化，首先得摸清底数。

Mantra 跑着一个配置扫描模块 (Scanner)。当你把项目目录扔进 Mantra 时，它会自个儿去扫一遍。

Mantra Scanner Concept 图1: Mantra 扫描器正在全域搜寻配置"方言"

1. 识别配置方言

现在的 MCP 配置环境简直是个大杂烩，每个工具都有自己的想法：

Gemini CLI 把配置存在标准 JSON 里，路径通常是 ~/.gemini/settings.json。
Cursor 偏爱带注释的 JSON (JSONC)，配置可能埋在全局存储里，也可能在项目根目录。
Claude Code 也有自己那一套 .claude.json 结构。

Mantra 的 Scanner 能听懂这些"方言"。它不仅能自动找到 ~/.claude.json 这些文件，还能把里面的 mcpServers 块给抠出来，转化成 Mantra 内部的标准模型（基于 Rust 后端的 McpRegistry 数据结构）。

2. 多级 Scope 定位

Scanner 会按照优先级层级进行递归扫描：

Global: 用户的家目录配置。
Workspace: 识别到的多项目工作区。
Project: 当前激活的项目目录（如 .cursor/mcp.json）。

通过扫描，Mantra 能够绘制出一张完整的"配置地图"，识别出哪些服务是全局共享的，哪些是特定项目私有的。

II. 第二步：冲突解决与语义去重 (Import)

扫描完成后，下一步是将这些配置"合并"入库。这里最核心的技术挑战是：去重。

如果你的 Cursor 里配了一个 postgres 服务，Gemini CLI 里也配了一个同名的 postgres，Mantra 会如何处理？

Mantra 并不简单地通过名称判断，而是通过 Command + Args 的语义指纹。只要执行的命令和核心参数一致，Hub 就会将其识别为同一个服务实例。

在这个阶段，你会看到 Mantra 的 UI 弹出一个清晰的确认清单：

✅ 识别到 3 个全局服务（Postgres, Slack, Filesystem）
⚠️ 识别到 1 个项目冲突：Cursor 和 Gemini 对 Postgres 的参数配置不一致，请选择以谁为准？

Mantra 冲突解决向导 图2: Mantra 正在帮你理清这一团乱麻

一旦你确认，这些分散的配置就会被正式迁移到 Mantra 的加密存储中，从此由 Hub 统一负责生命周期管理。

III. 第三步：重定向 —— 透明代理的实现 (Redirect)

这一步是整个流程里最"讨巧"的地方，也是实现"无感"升级的核心。

在传统的迁移中，你可能需要手动修改每个工具的配置。但在 Mantra 的接管流程中，我们玩了个"重定向"的小把戏。

以 Cursor 为例。当你点击"确认接管"后，Mantra 会在后台悄悄干活：

自动备份：先把原有的 .cursor/mcp.json 备份好，万一你想吃回头草也有路可退。
透明代理重写：改写 JSON。原本指向真实 Server 的命令，会被换成 Mantra 的本地代理指令：

json

// 接管后的 .cursor/mcp.json 片段
"mcpServers": {
  "postgres": {
    "command": "mantra-proxy",
    "args": ["--hub", "ws://localhost:3000/mcp/postgres"]
  }
}

工作原理

对 Cursor 来说，它压根不知道发生了什么，依然觉得自己启动了一个普通的本地进程（mantra-proxy）。但这个代理进程其实是个"传声筒"：它只负责把所有的流量通过隧道转发给 Mantra 主进程。

这时候，Mantra Hub 扮演了中间人的角色：

Cursor 照样干活，习惯一点没变。
Postgres Server 还是在本地跑着。
Mantra 坐在中间，接管了进程保活，顺便把原本没法做的审计日志给补上了。

Mantra 流量重定向架构 图3: Mantra 透明接管流量示意图

这就是 透明代理接管：你的 IDE 没变，习惯没变，但底层的连接架构已经完成了从"游击队"到"正规军"的升级。

IV. 想走随时能走：一键还原 (The Eject Button)

我们明白，开发者对"接管"这种词天生反感。如果哪天你觉得这个 Hub 累赘了，或者单纯想回到原来的方式，怎么办？

Mantra 准备了一个 Eject（还原） 按钮。

Mantra Eject Button 图4: 想走随时能走，一键还原你的开发环境

因为接管的时候留了备份，只要你一点还原，Mantra 就会瞬间：

停掉所有代理进程。
把 .cursor/mcp.json 这些配置文件还原回去。
重新启用你原来的启动命令。

你的环境会像没发生过任何事一样恢复原状。 这种"退路"是我们设计这套机制的前提——只有让你能放心离开，你才会愿意尝试。

V. 结语：让 Hub 隐于无形

一个好的工具，应该是当你用它的时候，感觉不到它的存在。

通过 发现 -> 导入 -> 重定向 这三步走，Mantra 把散落在各处的配置收纳到了全局的 MCP Hub。你不再需要去折腾每个工具的配置项，只要在 Hub 里看一眼就行。

到这一步，流量已经接管成功了。那么，既然流量都在我们手心里了，是不是能玩点更高级的？

下一篇，我们会聊聊 "细粒度治理"：怎么限制 AI 只能读特定的表？怎么给不同的助手分发不同的权限？

敬请期待：《Mantra MCP 系列 (3)：超越开启与禁用，设计细粒度的 AI 治理体系》。

机制篇：透明代理接管，无缝统一你的项目上下文 ​

I. 第一步：全域扫描 (Discovery) ​

1. 识别配置方言 ​

2. 多级 Scope 定位 ​

II. 第二步：冲突解决与语义去重 (Import) ​

III. 第三步：重定向 —— 透明代理的实现 (Redirect) ​

工作原理 ​

IV. 想走随时能走：一键还原 (The Eject Button) ​

V. 结语：让 Hub 隐于无形 ​