AI 快讯 编译自 aws_ml_blog #MCP#AWS#AI Agent

AWS 发布 MCP 桥接方案:让云端 AI Agent 安全访问本地工具与文件

AWS 博客详解如何构建 MCP bridge,使 Bedrock AgentCore 托管的 AI agent 通过浏览器扩展和 Chrome native messaging 调用本地 MCP 服务器,无需开放端口或 VPN。本文翻译并解读该方案,分析对国内用户的实际意义与替代方案。

编译发布 2026/08/05 原文发布 2026/08/05

一句话看懂

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 安全访问本地数据提供了新思路,国内开发者可借鉴其架构,但需自行适配云服务和合规要求。