如果给现在的 AI 编程工具排名最尴尬的瞬间大概是这样模型已经能写出像模像样的代码了但它看不到你本地数据库里的表结构它能调用各种工具了但工具大多跑在云端根本碰不到你电脑里的文件。明明 AI 的能力在指数级增长可一旦涉及本地数据就立刻变成了巧妇难为无米之炊。这个问题的根源在 MCP 的架构约束里。MCPModel Context Protocol服务端往往部署在贴近数据的那台机器上而 AI 客户端却越来越多地运行在云端。于是一个非常现实的需求出现了远程 AI 客户端如何安全地调用本地 MCP 服务器上的工具。Forth MCP 就是针对这个需求出现的工具。从项目定位看它的目标非常明确——give any remote AI client access to your local MCP servers也就是给任何远程 AI 客户端一个访问本地 MCP 服务器的入口。这篇文章不打算只复述一个项目而是想把整个工程问题讲透MCP 的架构约束到底是什么Forth MCP 这类工具解决的是哪一层问题以及即使不依赖它你也能用 SSH 隧道、内网穿透等通用手段实现同一条链路。读完你至少能判断自己该不该引入这类工具以及接入时真正容易踩的坑在哪里。1. MCP 的架构约束为什么服务器总在本地客户端却可能在云端MCP 的设计目标很清晰标准化 AI 应用与外部工具、数据源的连接方式。在 MCP 出现之前每个 Agent 想接入一个新工具几乎都要写一遍专用的集成代码。接入数据库要写驱动接入浏览器要写自动化脚本接入内部系统要写 API 封装。整个工具生态是碎片化的。MCP 出现后连接方式被抽象成了一个统一协议AI 客户端负责发现和调用工具MCP 服务器负责把具体能力包装成标准接口。但这里有一个很容易被忽略的架构细节MCP 最早的传输方式并不是 HTTP而是 stdio。也就是说AI 客户端在本地直接启动一个 MCP 服务器子进程通过标准输入输出和它通信。这个设计在本地场景下非常好用不用开端口不用处理网络权限不用纠结认证拉起进程就能用。MCP 最早要解决的恰恰是给本地 AI 编程工具接上本地文件系统和终端能力这个问题stdio 在当时的场景里是最优解。问题恰恰出在这个本地优先的设计上。当 AI 客户端跑在云端时stdio 完全不成立。云端进程不可能直接启动你电脑上的子进程也不可能访问你本地磁盘里的文件。后来 MCP 协议也做了演进新版本 SDK 加入了基于 HTTP 的传输方式服务端可以把能力暴露成标准的 HTTP 接口。但这只是解决了传输层能不能走 HTTP的问题并没有解决你的本地 MCP Server 如何被远程客户端找到的问题。你的机器没有公网 IP端口在防火墙后面服务也没有域名。本地 MCP Server 与远程 AI 客户端之间仍然隔着一条天然的网络边界。这条边界就是 Forth MCP 这类工具存在的理由。2. MCP 核心概念三种角色、两种传输与本地场景要理解 Forth MCP 的价值先要把 MCP 的几个基础概念拆开。很多人第一次配置 MCP 时会把 Host 和 Client 混为一谈结果在配置界面里完全找不到方向。MCP 协议里有三个角色可以做一个简单的类比Host 是用户直接使用的 AI 应用相当于一个调度中心Client 是 Host 内部负责建立具体连接的组件相当于连接器Server 是能力提供方相当于工具供应商。一个 Host 可以启动多个 Client每个 Client 连接一个 Server。每个 Server 内部可以暴露多个 Tool每个 Tool 就是一个可以被 AI 调用的函数。这三个角色的关系可以这样理解角色类比职责典型例子Host调度中心管理会话、决定何时调用工具Claude、Cursor、Codex、自研 AgentClient连接器与某个 Server 建立连接每个 Host 内部的 MCP Client 组件Server工具供应商提供可调用的工具能力文件系统、数据库、浏览器操作服务MCP 的传输方式也经历过明显变化。早期的实现以 stdio 为主适合本地进程通信后来引入了基于 HTTP 的 Streamable HTTP 传输用服务端事件流的方式支持远程请求。对开发者来说选择哪种传输方式取决于部署位置本地调试用 stdio 最快远程访问则必须走 HTTP。本地 MCP Server 的典型场景包括读取本地文件系统的工具、连接开发数据库的查询工具、控制本地浏览器的自动化工具、读取 IDE 上下文的辅助工具。这些工具的共同特点都是需要访问本机资源。在本地运行时它们的数据不出机器安全边界非常清晰。一旦引入远程访问这个安全边界就不再天然成立而是需要额外的机制来保证。3. Forth MCP 的定位给远程 AI 客户端一个访问本地 MCP 的入口从项目标题来判断Forth MCP 做的事情非常聚焦让任何远程 AI 客户端都能访问本地的 MCP 服务器。这个表述里有三个关键词值得逐字拆解。第一个关键词是任何。它说明这个工具试图做到协议层兼容而不是绑定某一家模型厂商、某个 IDE 或某个特定 Agent 框架。当前 AI 工具市场非常分裂有云端助手、有本地 IDE、有命令行 Agent每个工具的 MCP 接入方式都不完全一样。如果有一个通用通道能让这些客户端统一访问本地 MCP那么本地工具能力就变成了一种可复用的网络服务。第二个关键词是远程。它明确说明访问方与被访问方不在同一台机器上。远程访问要解决的核心问题包括如何穿过 NAT 和防火墙、如何保持长连接稳定、如何防止未授权访问。这不只是把端口映射出去那么简单。第三个关键词是本地。它强调 MCP Server 仍然运行在本地而不是被部署到云端。这个设计的直接好处是数据不用出域MCP Server 读取数据库、操作文件系统时所有数据仍然停留在本地机器上。远程 AI 客户端通过工具调用拿到的只是结果而不是完整的本地数据权限。从技术架构上推断Forth MCP 比较合理的实现方式是在本地启动一个网关进程它通过 stdio 或本地 HTTP 与 MCP Server 通信再通过一条经过认证和加密的通道把能力暴露给远程 AI 客户端。远程客户端看到的是一个标准的 MCP 输入输出而真正的工具执行仍然发生在本地。这个本地执行、远程调用的模型本质上是在 MCP 之上又叠加了一层远程访问能力。需要说明的是Forth MCP 仍是一个发展阶段的项目具体安装方式、配置参数和命令行用法请以项目仓库 README 为准。下文要讲的通用方案不依赖这个项目也可以落地而且这恰恰是理解它价值的最快方式先自己把链路搭一遍你就知道它帮你省掉了哪部分工作。4. Agent Skill 与 MCP两个高频概念的区别与互补最近在很多技术讨论里有一个问题反复出现Agent Skill 和 MCP 到底有什么区别这个困惑很正常因为主流的 Agent 平台都在推自己的技能框架文档里又把 MCP 和工具调用放在一起讲很容易让开发者觉得两者是同类东西。Skill 的本质是提示词 示例的打包。它告诉 Agent 面对某个场景时应该怎么做比如当用户要求生成图表时调用这个 Python 脚本并按这个 JSON 格式解析结果。Skill 更像是一份给 Agent 看的操作手册优点是灵活、编写成本低缺点是没有统一的运行时标准不同平台之间的 Skill 不能直接互通。MCP 的本质是协议 运行时。它定义了客户端和服务端之间如何发现工具、如何发起调用、如何返回结果并且提供了统一的数据格式。Server 负责真正执行Client 只按协议调用。它比 Skill 更重但换来的是跨平台兼容性和可复用的能力部署。用一个类比来说Skill 像是给新人准备的 SOP 文档告诉它遇到什么情况按什么步骤处理MCP 像是公司内部统一制定的 RPC 接口规范所有的服务都按这个规范接入调用方不需要关心服务内部怎么实现。Skill 解决怎么做的问题MCP 解决怎么稳定连接和调用的问题。这两个概念不能互相替代实际项目里通常互补使用Agent 通过 Skill 决定在什么场景下选择哪个工具再通过 MCP 以标准方式调用这个工具的具体能力。Forth MCP 所在的位置是 MCP 这一层它把本地工具被远程调用变成网络服务而具体的技能编排仍然由 AI 客户端自己完成。5. 环境准备与最小 MCP Server 示例在打通远程访问之前先准备一个能跑的最小 MCP Server。这里我们用社区里很常见的 FastMCP 封装来做演示它的 API 比较简洁适合快速搭建工具服务。依赖安装和示例代码如下。环境准备清单一台可以作为部署环境的本地机器操作系统不限Linux / macOS / Windows。Python 3.9 及以上版本pip 可用。一台有公网 IP 的中继服务器用于后面的 SSH 隧道或内网穿透方案。一个远程 AI 客户端比如你正在用的云端编程助手或自建的 Agent 程序。安装依赖pip install fastmcp然后创建最小 MCP Server 文件。这个服务只暴露一个查询磁盘占用的工具用来验证链路是否通畅。# 文件路径mcp_local_server.py from fastmcp import FastMCP mcp FastMCP(local-utils) mcp.tool() def query_disk_usage(path: str /) - str: 查询磁盘占用情况用于演示本地工具能力。 Args: path: 要查询的目录路径。 Returns: 包含 total/used/free 的磁盘信息字符串。 import shutil usage shutil.disk_usage(path) return ftotal{usage.total}, used{usage.used}, free{usage.free} if __name__ __main__: mcp.run()启动这个服务python mcp_local_server.py这里有一个需要特别注意的版本差异FastMCP 的mcp.run()默认可能使用 stdio 传输模式这种模式只适合本地进程调用。如果要把这个服务放到网络上供远程客户端访问需要根据你安装的 FastMCP 版本文档把传输模式调整为基于 HTTP 的 Streamable HTTP 模式。不同版本的参数名称和执行细节有差异请以你实际安装版本的官方文档为准。后面的隧道方案都是假设本地 MCP Server 已经变成 HTTP 服务并监听在某个端口上。如果你用curl在本地能访问到这个 HTTP 服务说明 MCP Server 已经具备被远程访问的传输基础。下面的工作就是打通网络链路。6. 通用方案一SSH 反向隧道打通远程访问如果你想在十分钟内验证远程 AI 客户端访问本地 MCP Server这条路最简单可靠的工具是 SSH 反向隧道。它不依赖任何第三方穿透服务只需要一台有公网 IP 的中继服务器。原理并不复杂本地机器主动向中继服务器建立一条 SSH 连接同时让中继服务器监听某个端口所有到达这个端口的请求都会通过加密的 SSH 隧道转发到本地 MCP Server 的端口。相当于从公网打了一条穿回你内网的加密管道。假设中继服务器的 IP 是 203.0.113.10文档示例地址本地 MCP Server 监听在 8765 端口执行下面的命令ssh -R 8900:localhost:8765 root203.0.113.10 -N命令参数说明-R 8900:localhost:8765在中继服务器上开放 8900 端口所有到达该端口的请求转发到本机的 8765 端口。-N只做端口转发不执行远程命令。中继服务器的 SSH 配置里需要允许 GatewayPorts否则远程客户端无法通过服务器公网 IP 访问监听的端口。隧道建立后远程 AI 客户端的 MCP Server 地址可以配置成类似下面的格式{ mcpServers: { local-utils-remote: { url: http://203.0.113.10:8900/mcp } } }这里有两个关键点。第一URL 中的路径必须和 MCP Server 暴露的真实路径一致不同 SDK 的默认路径存在差异以实际服务输出为准。第二SSH 隧道本身提供了链路加密但 MCP Server 如果没有认证任何人都可以调用你的工具。因此长期使用前至少要在接入层增加令牌认证或者用防火墙限制来源 IP。SSH 隧道方案的优势是零额外依赖、免费、稳定缺点是配置比较原始。连接断开后不会自动重连多个 MCP Server 需要多条隧道管理成本会上升。如果只是验证概念这个方案足够用如果要长期跑在团队协作环境里可以考虑下一节的内网穿透方案。7. 通用方案二内网穿透工具的工程化落地把本地 MCP Server 暴露到公网如果不想维护自己的公网服务器可以先用 cloudflared 的 Quick Tunnel。它只需要一行命令就能把本地端口映射成一个临时的公网 HTTPS 地址。cloudflared tunnel --url http://localhost:8765启动后终端会输出一个https://xxx.trycloudflare.com形式的地址。这个地址自带 HTTPS不需要额外域名把远程 AI 客户端的 MCP Server 地址配置成这个 HTTPS 地址即可。它的最大优点是零配置、上手快缺点是临时隧道地址不稳定重启后地址会变化不适合长期生产使用。如果需要固定地址和更细粒度的访问控制可以考虑自建 frp 方案。frp 分为服务端和客户端两个部分服务端 frps 运行在有公网 IP 的机器上客户端 frpc 运行在本地机器上两者通过配置的 token 做认证。服务端配置示例# 文件路径frps.toml bindPort 7000 auth.token 请换成你自己的强密码客户端配置示例# 文件路径frpc.toml serverAddr 203.0.113.10 serverPort 7000 auth.token 请换成你自己的强密码 [[proxies]] name mcp-local-utils type tcp localIP 127.0.0.1 localPort 8765 remotePort 8900启动命令./frps -c frps.toml ./frpc -c frpc.tomlfrp 的方案自托管、控制力强能支持 TCP、HTTP 等多种协议适合长期运行。但也要注意它的安全性完全取决于你的配置token 强度、服务端防火墙、端口暴露范围都直接影响风险等级。建议服务端只对必要的来源 IP 开放并定期更换认证 token。不管是 SSH 隧道还是 frp本质上都只是在传输层打通了网络。真正让远程 AI 客户端能识别并调用 MCP 工具前提是 MCP Server 的传输方式与远程客户端兼容。如果本地 MCP Server 只支持 stdio无论隧道建得多好远程客户端也接不上。所以远程可访问的 MCP Server 必须使用 HTTP 类传输这句话值得在接入前反复确认。8. 安全边界暴露本地 MCP 前必须守住的红线把本地 MCP Server 暴露给远程 AI 客户端这件事本身就伴随风险。和普通 HTTP 接口不同MCP Server 暴露的是工具调用能力调用结果可能直接影响本地系统。一个只读的文件查询工具和一个可以执行任意命令的工具风险等级完全不是一回事。首先是最小权限原则。MCP Server 里的每个工具都应该尽量只做一件事只能访问它必需的数据范围。比如数据库工具只暴露只读查询不要暴露删除和更新文件操作工具限制可访问的目录不要让 Agent 拥有遍历整个文件系统的能力。工具内部也应该有路径校验防止通过../之类的穿越手段访问白名单之外的目录。其次是认证与授权隔离。凡是能远程访问的 MCP Server接入层必须做认证。最简单的做法是在网关层配置一个静态令牌远程客户端每次请求都携带该令牌。更严格的做法是为不同客户端分配独立凭据同时记录每个凭据的调用记录。这样即使某个凭据泄露也能快速定位并单独撤销。然后是审计日志。MCP Server 每次收到工具调用都应该记录调用时间、来源、参数和返回结果摘要。审计日志不是为了当时解决问题而是为了将来出问题时能最快还原现场。这个机制的成本很低收益却非常大尤其是当多个远程客户端共享同一个 MCP Server 时。链路加密同样不能省略。SSH 隧道和 cloudflared 默认自带加密自建 frp 时要确认传输层是加密的。MCP 请求参数中可能携带敏感信息比如数据库查询条件、文件路径、内部报错内容明文传输到公网上是不可接受的。最后有些 MCP Server 根本不适合暴露到远程。直接控制鼠标键盘、直接操作浏览器登录态、直接持有云平台密钥的工具建议只保留在本地交互场景使用。这类工具一旦被远程滥用影响范围远超数据泄露可能是对本地系统的直接控制。Forth MCP 这类工具如果实现得好应该把一部分安全能力做成内置功能上层认证、可暴露的 Server 清单管理、调用日志等。这其实是它相对通用内网穿透工具更有价值的地方通用隧道只解决网络能通而 MCP 专用通道还要解决调用是否安全可控。9. 常见