在用双模型工作流开发了一段时间之后，有个问题越来越明显：三个 AI 客户端各自是孤岛。
VPS 上的 Claude 能读 VPS 的文件，Windows 上的 Claude Code 能读本地文件，Antigravity 有自己的工具集——但它们之间没有任何连接。全局者做完决策、工作者做完实现，结果还是要靠我手动把内容复制粘贴到另一个窗口。
想解决这个问题，但又不想改任何 AI 客户端本身的配置。于是想到了 MCP。
思路：共享工具箱
MCP（Model Context Protocol）允许 AI 客户端连接外部工具服务器。既然每个 AI 都可以连 MCP Server，那只要做一个所有人都能连的 Server，问题就解决了。
这就是 MCP-Bridge 的核心思路——一个跑在 Windows 本机的 FastMCP 服务，暴露一套文件读写、消息传递、互相调用的工具。三个 AI 客户端各自连上来，工具共享，孤岛消失。
网络部分用 Cloudflare Tunnel 解决：VPS 在远端连不到 Windows 本机，tunnel 把本机的 18800 端口映射到公网域名，VPS 那边通过 HTTPS 访问。
一个有意思的问题
接入三个客户端的时候，Antigravity 卡了一下。
Claude Code 支持 HTTP 类型的 MCP Server，直接填 URL 就行。但 Antigravity 的 MCP 客户端只认 stdio——也就是说，它只会启动一个本地进程、通过标准输入输出通信，不支持直接连 HTTP。
解法是 mcp-proxy：在本机跑一个 stdio 进程，它负责把 Antigravity 的 stdio 请求转发到 localhost:18800。Antigravity 以为自己在和一个本地进程说话，实际上请求已经透明转发到了 Bridge。
这种”协议不匹配→中间加一层”的解法很常见，但第一次遇到还是挺有意思的。
三层协作
Bridge 最终实现了三层跨 AI 协作：
文件共享：三个 AI 读写同一个共享目录，互相可见对方写的内容。最简单，但够用。
异步消息：做了一个简单的消息总线，支持发消息、读消息、回复消息。AI A 发一条给 AI B，AI B 下次拿工具的时候能读到。有点像一个极简版的邮件系统。
程序调用：最有意思的一层。一个 AI 可以通过 Bridge 调用另一个 AI 的命令行，拿到输出结果。比如 VPS Claude 需要验证某个 Windows 本地行为，可以直接让 Bridge 在 Windows 上启动 Antigravity 跑一个问题、同步返回答案。
实际上，这个项目的 README 里有一句话描述得很准：164 passed + 3 skipped——整个工具集的测试覆盖是完整的，安全规则（文件路径白名单、二进制拒绝、调用命令白名单）也都在测试里跑通了。
顺带一提：A2A
做完这个之后，看到了 Google 发起的 A2A 协议（Agent2Agent，23k+ stars，Linux Foundation 项目）。
对比下来，MCP 和 A2A 其实是两个层次：MCP 解决的是 AI 使用工具的问题，A2A 解决的是 AI 之间互相委托任务的问题。我做的 Bridge 在 MCP 这一层——共享工具箱，人在中间做路由。A2A 想把”人做路由”这步也自动化掉，让 AI 直接协商分工。
两个方向都有价值，方向不同。MCP Bridge 更轻量，现阶段自用够了。
一点感想
做这个项目的直接收获是三个 AI 确实能协作了，但更有意思的是过程里对 MCP 协议本身的理解加深了不少——transport 层的设计、多客户端共享 state 的考量、安全边界的划定，这些在真正用起来之前都只是文档里的概念。
项目已开源在 GitHub，MIT 协议。如果你也在用多个 AI 工具、想打通工具层，可以参考一下架构思路。