每天早晨，用三行读完全球 AI 动态浏览品牌目录

METAL LAB

AWS 公开云端智能体连接本地MCP工具的架构

AWS公开了基于WebSocket和原生消息传递的MCP桥接架构，使运行在Amazon Bedrock AgentCore上的AI智能体能够访问用户PC本地的Excel文件及本地MCP服务器。在内部实际应用案例中，该方案上线一年内已处理超过4.1万次对话。

METAL AI

为何需要这一桥接方案

MCP（Model Context Protocol）是Anthropic于2024年11月公开的开源标准，用于统一AI模型连接外部数据和工具的方式。MCP遵循客户端-服务器架构，支持两种传输方式——用于同一台机器上本地进程间通信的stdio，以及用于远程服务器与客户端间HTTP通信的Streamable HTTP。然而，当MCP服务器位于本地、而MCP客户端位于远程云端时，这两种方式都无法直接支持。

这一空白在财务分析师或金融经理等主要使用Excel和本地文件的职业群体中尤为突出。AWS内部已将这一模式应用于财务AI助手，上线一年内已处理超过4.1万次对话，并将该内部实现简化后，重新构建为公开的参考架构。

MCP桥接演示扩展程序汇总本地Excel工作簿的画面
图片：AWS ML Blog

架构：四个组件

整体架构由AgentCore运行时、浏览器扩展程序、MCP桥接器、MCP服务器四部分组成。AgentCore运行时在云端托管Strands智能体，充当MCP客户端角色，发送工具发现和调用请求。浏览器扩展程序既提供聊天界面，又负责在AgentCore运行时（WebSocket）与MCP桥接器（原生消息传递）之间进行双向中继。

MCP桥接器是运行在用户本地机器上的FastMCP代理，由浏览器通过注册原生消息传递主机来创建。它负责在原生消息传递的信封格式与MCP JSON-RPC之间进行转换，并由于与MCP服务器位于同一台机器上，因此使用stdio传输。MCP服务器由桥接器在启动时以子进程方式创建，并一直保持运行直至桥接器终止。

从智能体到MCP服务器的端到端消息流架构图
图片：AWS ML Blog

消息从智能体出发，经过每一跳时会被逐层剥去封装层。智能体通过WebSocket向扩展程序发送形如{"type": "mcpbridge", "content": ..., "session_id": "..."}的JSON信封，扩展程序再通过原生消息传递将其转发给桥接器。桥接器剥去信封后，将纯JSON-RPC消息通过stdio发送给MCP服务器。响应则沿相反路径原样返回。

核心工作原理

WebSocket连接与凭证保护：浏览器扩展程序启动时向本地桥接器发送预签名请求，桥接器使用用户本地的AWS凭证和Bedrock AgentCore SDK生成经SigV4签名的wss:// URL。该URL仅限用于所部署的运行时ARN，并在5分钟后失效。凭证不会离开用户设备，也不会传递给浏览器。连接断开时，侧边面板会在2秒后自动请求新的URL并重新连接，因此失效窗口不会暴露给用户。

工具发现与MCP初始化：智能体在每次用户消息时都会调用tools/list以获取工具模式数组。每个模式都会被包装为Strands AgentTool，其stream()方法通过桥接器发送tools/call请求。在MCP服务器上添加工具后，无需修改智能体代码，从下一次请求起即可自动使用。在工具发现之前，智能体会先执行标准的MCP初始化握手，只有在initialize请求与服务器响应，以及notifications/initialized通知交换完成后，tools/list和tools/call请求才会被接受。

MCP桥接器内部结构：桥接器运行两个并发循环。主循环从浏览器读取消息，剥去信封后将JSON-RPC内容放入输入队列。FastMCP代理从该队列中取出消息并转发至MCP服务器子进程的stdin，同时将服务器stdout的响应存入输出队列。第二个后台循环读取输出队列，将每个响应封装后发送回浏览器。这种双循环设计使得即便某个工具处理较慢，也不会阻塞后续请求的接收。

MCP桥接器内部架构图——I/O队列与FastMCP代理结构
图片：AWS ML Blog

实际部署方法

部署所需时间估计约为15分钟。所需前提条件如下：

  • AWS：已启用Bedrock模型访问权限的AWS账户（代码使用Claude Opus 4.7）、针对AgentCore、CloudFormation、IAM角色创建、S3的IAM权限、已配置的AWS CLI凭证、已完成CDK引导
  • 软件：Python 3.10及以上、Node.js 20及以上、支持Manifest V3侧边面板的Google Chrome、Git
  • 安装包：AgentCore CLI（npm install -g @aws/agentcore）、AWS CDK（npm install -g aws-cdk）

部署顺序为：克隆GitHub仓库（aws-samples/sample-mcp-bridge-agentcore）→安装Python依赖（./scripts/setup.sh）→通过agentcore create、agentcore deploy创建并部署智能体→在bridge/bridge_config.json中填入运行时ARN和区域→加载Chrome扩展程序→通过./manifests/install.sh <extension-id>注册原生消息传递桥接器。

添加新的MCP服务器只需在mcp.json中新增一行即可完成，其余连接工作由桥接器自动处理。

费用：AgentCore运行时按调用次数计费，无闲置成本；Bedrock模型使用则按Claude标准的按token计价收费。桥接器、扩展程序、MCP服务器均在本地运行，不产生额外费用。具体单价未在原始资料中说明。

安全考量与局限性

当前示例实现中采用了三项安全措施：Chrome仅允许原生消息传递清单中allowed_origins所指定的扩展程序ID建立连接的来源限制；5分钟后失效的SigV4签名预签名URL；以及扩展程序、桥接器、MCP服务器各自在独立的操作系统进程中运行、不共享内存的进程隔离。

AWS建议在生产环境中采取额外措施，包括：通过Amazon Cognito等方式实现JWT握手认证层以阻止未授权使用；利用Ed25519对MCP消息载荷进行签名；通过MCP服务器可访问目录的允许列表限制文件系统访问范围；以及为每次工具调用记录名称、参数、时间戳和结果状态的本地审计日志。该架构的核心暴露点在于桥接器本身，它接受云端智能体的指令，并以用户的文件系统权限在本地执行操作。

当前示例的原生消息大小限制为：原生消息传递主机→浏览器方向最大1 MB，浏览器→原生消息传递主机方向最大64 MiB。对于生产部署，AWS建议使用PyInstaller将桥接器打包为独立可执行二进制文件，使其无需Python环境即可运行。

相关文章