我们如何构建 MCP 桥接器，让云端 AI 智能体访问本地工具

MCP 协议目前支持两种传输机制：基于标准输入输出的 stdio 传输（适用于同一台机器上的本地进程通信）和基于 HTTP 的流式传输（适用于远程服务器与客户端之间的通信）。然而，当 MCP 服务器位于用户本地、MCP 客户端却运行在云端时，两种机制均无法直接覆盖这一场景。这一缺口对金融分析师群体尤为突出——他们日常依赖本地 Excel 文件和浏览器数据，同时又希望借助集中部署的 AI 智能体来处理这些内容。

为解决上述问题，亚马逊云科技团队设计了一套四层架构。第一层是运行在 AgentCore 云端的 Strands 智能体，充当 MCP 客户端，负责发起工具发现与调用请求；第二层是浏览器扩展，提供聊天界面并作为双向中继，通过 WebSocket 与云端通信，通过原生消息机制与本地桥接进程通信；第三层是运行在用户本地的 FastMCP 代理进程（MCP Bridge），负责在原生消息信封格式与原始 MCP JSON-RPC 之间进行转换；第四层是通过 stdio 与桥接进程通信的本地 MCP 服务器。

消息在各层之间传递时，每经过一跳便剥去一层封装。智能体向浏览器扩展发送包含会话 ID 和 MCP 内容的 JSON 信封；扩展将内层消息转发给桥接进程；桥接进程提取出标准 JSON-RPC 内容后，通过 stdio 发送给本地 MCP 服务器。响应则沿相反路径返回。这种逐层拆包的设计使各组件职责清晰，同时保持了与标准 MCP 协议的兼容性。

WebSocket 连接的安全性通过 SigV4 签名的预签名 URL 来保障。浏览器扩展启动时，会通过后台脚本向本地桥接进程发起预签名请求，由桥接进程使用用户本地的 AWS 凭证生成有效期为 5 分钟的 wss:// 地址。整个过程中，凭证始终留在用户本地，不会进入浏览器或传输到云端。若连接因 URL 过期或网络中断而断开，侧边栏会在 2 秒后自动申请新的预签名 URL 并重新连接，用户在正常使用中几乎感知不到过期窗口的存在。

在工具发现与调用层面，智能体在每次用户消息到来时都会调用 tools/list 接口获取当前可用工具列表，并将每个工具模式封装为 Strands AgentTool 对象。这意味着本地 MCP 服务器新增的工具无需修改任何智能体代码，下一次请求即可自动生效。为支持并发工具调用，每个出站 JSON-RPC 请求都会被分配唯一 ID，并注册到以会话 ID 和请求 ID 为键的 asyncio.Future 对象上，响应到达时精确匹配对应的等待任务，避免多路并发时的混淆。

原生消息机制是整套方案的关键基础设施。Chrome 和 Firefox 均支持扩展通过原生消息与本地长驻进程通信，浏览器会读取存放在系统特定路径下的清单文件，按需启动指定的本地二进制程序。这一机制无需开放任何网络端口，也无需为每条消息弹出用户授权提示，从而在保障安全性的同时提供了流畅的使用体验。完整源代码已在 GitHub 上开放，团队也表示将在后续文章中进一步介绍生产环境加固措施。

要点

• 当 MCP 服务器在本地、客户端在云端时，现有 MCP 协议缺乏原生支持，需要通过自定义桥接架构来填补这一空白
• 四层架构（AgentCore 智能体、浏览器扩展、本地桥接进程、本地 MCP 服务器）通过逐层拆包的方式实现了云端与本地工具的安全互通
• SigV4 预签名 WebSocket URL 确保 AWS 凭证始终留在用户本地，不进入浏览器或云端传输链路
• 工具发现机制支持动态扩展，本地 MCP 服务器新增工具后无需修改智能体代码即可立即生效
• Chrome 原生消息机制无需开放端口或 VPN，是实现浏览器扩展与本地进程安全通信的关键基础