AWS 发布 MCP 桥接方案:让云端 AI Agent 安全访问本地工具与文件
AWS 博客详解如何构建 MCP bridge,使 Bedrock AgentCore 托管的 AI agent 通过浏览器扩展和 Chrome native messaging 调用本地 MCP 服务器,无需开放端口或 VPN。本文翻译并解读该方案,分析对国内用户的实际意义与替代方案。
一句话看懂
AWS 提出一种 MCP 桥接方案,让云端 AI Agent 通过浏览器扩展与本地消息通道,安全调用用户电脑上的 MCP 工具,无需开放端口或 VPN。
详细发生了什么
AWS 机器学习博客发布文章,介绍如何构建一个 MCP(Model Context Protocol)桥接层,使部署在 Amazon Bedrock AgentCore 上的 AI Agent 能够访问用户本地机器上的 MCP 服务器。MCP 是 Anthropic 于 2024 年 11 月提出的开放标准,用于统一 AI 模型与外部数据/工具的连接方式。
文章指出,MCP 标准支持 stdio 和 streamable HTTP 两种传输方式,但缺少本地服务器与远程客户端之间的桥接方案。为此,AWS 团队设计了一个四组件架构:AgentCore runtime(云端托管 Agent,作为 MCP 客户端)、浏览器扩展(提供聊天界面并双向转发消息)、MCP Bridge(本地运行的 FastMCP 代理,转换协议格式)、以及本地 MCP 服务器(通过 stdio 通信)。
消息流转过程:用户通过扩展发送消息,扩展通过预签名 WebSocket 连接到 AgentCore runtime;当 Agent 需要调用工具时,发送 MCP JSON-RPC 请求,经 WebSocket 传回扩展,再通过 native messaging 转发给本地桥接进程,桥接解包后通过 stdio 传给 MCP 服务器。响应沿原路返回。
该方案已在内部财务 AI 助手中验证,上线一年内处理超过 41,000 次对话。完整源代码已发布在 GitHub。
中文圈视角
对国内用户而言,这个方案有几点值得关注。首先,AWS Bedrock AgentCore 在国内无法直接使用,需要海外账号和网络环境,但 MCP 桥接的思路本身可以借鉴。国内类似场景(如云端 Agent 需要访问本地 Excel、本地数据库)同样存在,但国内云厂商(阿里云、腾讯云)尚未推出完全对等的托管服务,开发者可能需要自行实现类似桥接。
其次,国内用户常用的 AI 编程工具(如通义灵码、CodeGeeX)和办公助手(如 WPS AI)也在探索本地工具调用,但多采用插件或本地代理方式,与 AWS 的浏览器扩展方案不同。MCP 标准本身是开放的,国内开发者可以基于此方案构建自己的桥接层,但需要注意数据出境合规问题——如果云端 Agent 在海外,本地文件内容会经过云端处理,可能涉及敏感数据。
另外,国内浏览器环境(如 360、QQ 浏览器)对 Chrome 扩展支持不一,native messaging 的兼容性需要测试。总体而言,这个方案对国内技术社区有启发意义,但直接落地需考虑网络和合规因素。
几条值得记住的细节
- 预签名 WebSocket URL 有效期 5 分钟,断线后 2 秒自动重连,用户无感知。
- 浏览器扩展通过 native messaging 启动本地桥接进程,无需开放网络端口。
- 单个 native messaging 消息最大 1 MB(从主机到浏览器),从浏览器到主机最大 64 MiB。
- MCP 服务器新增工具后,Agent 下次请求自动发现,无需修改代码。
- 内部财务 AI 助手上线一年处理超过 41,000 次对话。
一句话总结
这个方案为云端 AI 安全访问本地数据提供了新思路,国内开发者可借鉴其架构,但需自行适配云服务和合规要求。