企业官网建设流程全解析

先给读者一个结论：如果你经常在远程 AI 客户端（比如部署在云服务器上的 Agent、公司内网的 AI 应用）里调用本地 MCP 服务，又不想把 MCP 服务直接裸露到公网，那么类似 Forth MCP 这类“桥接/代理”方案就非常值得试一试。本文会拆解 MCP 的基本概念、这类工具要解决的核心问题、一个可落地的部署流程，以及过程中的高频坑和最佳实践。

在写正文之前，我先把一句话说明白：MCP（Model Context Protocol）是一个让 AI 应用与外部工具、数据源对接的开放协议。而“Forth MCP”这类项目解决的是：远程 AI 客户端如何安全、稳定地访问你本地机器上的 MCP Server。理解了这个目标，后面的配置就不会乱。

1. MCP 到底是什么，为什么需要桥接

很多刚开始接触 MCP 的朋友，会把 MCP 和 API 网关、RPC 框架搞混。其实 MCP 的出现背景很直接：AI 模型自身不具备调用外部工具的能力，但通过 MCP，AI 应用可以按照统一协议去发现工具、调用工具、读取工具返回的结果。

1.1 MCP 协议的核心角色

在 MCP 架构里，通常有三个角色：

假设你写了一个 MCP Server，它提供了读取本地文件的工具。如果你的 AI 应用与这个 Server 运行在同一台机器或同一个局域网内，直接通过stdio或 HTTP 端口连接即可。

但现实场景往往更复杂：你的 AI 客户端运行在云端，而数据源、内部系统、自动化工具却放在本地开发机或公司内网。直接让云端 AI 客户端通过公网 IP 去连本地 MCP Server，会带来两个问题：

• 本地机器没有固定公网地址，端口映射配置繁琐。
• 直接把 MCP 端口暴露到公网，存在严重的安全风险，任何人都可能调用你的工具。

1.2 Forth MCP 这类工具解决什么问题

Forth MCP 的核心思路，是在“远端 AI 客户端”和“本地 MCP Server”之间加一层代理或隧道机制。它让远程客户端只面对一个可靠、可控的接入点，而真正的 MCP Server 仍然停留在本地网络内。

你可以把 Forth MCP 理解成一个“信使”：

远程 AI 客户端 <-> Forth MCP 代理 <-> 本地 MCP Server

客户端通过代理暴露出来的统一地址发起请求，代理负责把请求转发给本地的 MCP Server，再把结果返回。这样既不需要把 MCP Server 直接暴露到公网，又可以让远程 AI 客户端享受本地工具的完整能力。

1.3 适合使用这类方案的场景

• 本地有数据库查询工具、文件管理工具，希望云端 Agent 也能调用。
• 公司内网有一台 Windows 机器，上面跑着 WinAppDriver 或 UI 自动化工具，需要通过 MCP 暴露给远程 AI 编程助手。
• 你正在调试 Figma MCP、Playwright MCP 等工具，但云端 Codex、Cursor 等客户端无法直连本地环境。
• 团队里多人共享一个 MCP 工具，但工具实际运行在某位成员的开发机上。

反过来，如果你的 MCP Server 和 AI 客户端本来就在同一台机器上，就没有必要引入桥接层，直接用标准 MCP 连接方式即可。

2. 环境准备与版本说明

由于 Forth MCP 本身是一个社区项目，不同版本的安装方式可能略有差异。这里我给出通用的环境准备思路，你只要把版本替换成自己实际使用的版本即可。

2.1 基础运行环境

为了保证 MCP 客户端、代理、Server 三层都能正常工作，建议先确认以下环境：

• 操作系统：Windows 10/11、macOS 12+、Ubuntu 20.04+ 均可。
• 运行时：Node.js 18+ 或 Python 3.9+，取决于你使用的 MCP SDK 版本。
• 包管理器：npm、pnpm 或 pip。
• 网络要求：本地机器能访问互联网；远程客户端能访问代理服务器地址。
• IDE / 工具：VS Code 或任意文本编辑器；建议安装 REST Client 或 curl 用于调试。

版本需要根据你的项目实际情况调整。例如，如果你用的是@modelcontextprotocol/sdk，需要注意 SDK 在 1.x 版本后调整了不少 API 名称；如果你的项目还停留在 0.x，请先查看更新日志。

2.2 需要一个可用的本地 MCP Server

在测试 Forth MCP 之前，你需要先有一个能正常工作的 MCP Server。这里我们用一个最简单的“echo 工具”作为示例。

假设项目目录结构如下：

forth-mcp-demo/ ├── local-server/ │ ├── package.json │ └── index.js ├── forth-proxy/ │ ├── package.json │ └── proxy.js └── README.md

local-server放本地 MCP Server，forth-proxy放桥接代理。这样分开管理，逻辑更清楚。

2.3 安装依赖

在local-server目录下，初始化 npm 项目并安装 MCP SDK：

cd local-server npm init -y npm install @modelcontextprotocol/sdk

如果你使用的是 Python，则推荐：

pip install mcp

但下面为了演示 Node.js 流程，我以 npm 安装为主。你完全可以用 Python 实现同样的逻辑，MCP 协议本身是语言无关的。

3. 核心原理：远程 AI 客户端如何访问本地 MCP Server

在配置之前，建议先建立一个整体认知：MCP 的传输层分为stdio和HTTP/SSE两种模式。

• stdio：MCP Server 由客户端作为子进程启动，通信走标准输入输出。这种方式适合本地调用，无需网络端口。
• HTTP/SSE：MCP Server 作为独立的 HTTP 服务运行，客户端通过网络请求访问。只有这种方式适合远程连接。

Forth MCP 代理要解决的，就是把本地的stdio或本地 HTTP 端口，转换成一个远程可访问的、包含认证和转发能力的统一入口。

3.1 普通 MCP Server 的启动方式

一个最简单的 MCP Server 示例local-server/index.js：

// 文件路径：local-server/index.js import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js"; import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js"; const server = new McpServer({ name: "echo-demo", version: "1.0.0" }); server.tool("echo", { message: { type: "string" } }, async (args) => { return { content: [ { type: "text", text: `echo: ${args.message}` } ] }; }); const transport = new StdioServerTransport(); await server.connect(transport); console.error("Local MCP Server started via stdio");

这个 Server 依靠stdio传输，如果你想让它被远程访问，还需要做一层封装。

3.2 远程客户端连接本地 Server 的两种思路

第一种思路：直接把 MCP Server 改成 HTTP 模式，监听一个本地端口，然后通过端口转发工具暴露出去。

// 文件路径：local-server/http-server.js import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js"; import { SSEServerTransport } from "@modelcontextprotocol/sdk/server/sse.js"; import express from "express"; const app = express(); const server = new McpServer({ name: "echo-demo-http", version: "1.0.0" }); server.tool("echo", { message: { type: "string" } }, async (args) => { return { content: [ { type: "text", text: `echo: ${args.message}` } ] }; }); let transport; app.get("/sse", async (req, res) => { transport = new SSEServerTransport("/messages", res); await server.connect(transport); }); app.post("/messages", async (req, res) => { if (transport) { await transport.handlePostMessage(req, res); } }); app.listen(3001, () => { console.error("Local MCP HTTP Server listening on 3001"); });

但这里存在一个问题：如果这个服务只监听127.0.0.1，远程客户端连不上；如果监听0.0.0.0，又等于把工具暴露到局域网甚至公网，非常危险。

第二种思路：让本地 MCP Server 保持只监听127.0.0.1，再通过 Forth MCP 这类代理层对外提供接入能力。代理层负责认证、转发、日志和流量控制。这就是本文推荐的方案。

3.3 Forth MCP 的工作流程

从流程上看，Forth MCP 启动后通常会做三件事：

1. 启动一个 Agent 服务，监听一个本地或远程可访问的端口。
2. 根据配置，寻找指定目录下的 MCP 配置文件（例如.mcp.json），或者直接连接已启动的 MCP Server。
3. 当远程 AI 客户端发起 MCP 请求时，Agent 将请求转发给对应的本地 MCP Server，并将结果原路返回。

用文字描述就是：

步骤 1：远程 AI 客户端向 Forth MCP 的接入地址发起请求。 步骤 2：Forth MCP 校验请求身份和权限。 步骤 3：Forth MCP 将请求转换为本地 MCP Client 调用。 步骤 4：本地 MCP Client 与本地 MCP Server 通过 stdio 或 HTTP 通信。 步骤 5：返回结果给 Forth MCP，再由 Forth MCP 返回给远程客户端。

这个设计的好处是，本地 MCP Server 不需要关心远程客户端的身份，也不需要考虑公网安全策略，它只信任 Forth MCP 这个“中间人”。

4. 完整实战：搭建一个可供远程 AI 客户端访问的 MCP 服务

下面我们用一个可运行的示例，走一遍从本地 MCP Server 到远程可访问的完整流程。为了安全和普适性，我会尽量给出可复制的代码，但大家要根据自己的 SDK 版本调整 API 名称。

4.1 创建项目结构

先创建目录结构：

mkdir forth-mcp-demo cd forth-mcp-demo mkdir local-server mkdir forth-proxy

4.2 编写本地 MCP Server

在local-server目录下，初始化项目并安装依赖：

cd local-server npm init -y npm install @modelcontextprotocol/sdk express

然后编写index.js，提供一个简单的echo工具：

// 文件路径：local-server/index.js const { McpServer } = require("@modelcontextprotocol/sdk/server/mcp.js"); const { StdioServerTransport } = require("@modelcontextprotocol/sdk/server/stdio.js"); const server = new McpServer({ name: "local-echo-server", version: "0.1.0" }); server.tool( "echo", { message: { type: "string", description: "要回显的消息" } }, async ({ message }) => { return { content: [ { type: "text", text: `[local echo] ${message}` } ] }; } ); async function main() { const transport = new StdioServerTransport(); await server.connect(transport); console.error("Local MCP Server is running via stdio"); } main().catch((error) => { console.error(error); process.exit(1); });

注意：这里用的是 CommonJS 的require，如果你的package.json中没有设置"type": "module"，那么.js文件默认按 CommonJS 解析。上面的写法可以直接运行。

验证本地 Server 是否正常：

node index.js

启动后，程序不会打印输出到标准输出，而是等待 stdio 输入。只要没有报错，就说明 Server 已经准备好了。

4.3 编写 Forth 代理核心逻辑

说明：这里并不是从官方文档照搬 Forth MCP 的源码，而是给你一个可用的代理实现思路。如果你使用的是 Forth MCP 官方包，可以直接用它的 CLI 命令，原理是一致的。

在forth-proxy目录下初始化项目：

cd ../forth-proxy npm init -y npm install express cors

编写proxy.js，实现以下功能：

• 提供 HTTP 接口，接收远程客户端发来的 JSON 请求。
• 通过环境变量读取本地 MCP Server 的启动命令。
• 使用child_process.spawn启动本地 MCP Server 的子进程。
• 将客户端请求写入子进程的 stdin，从 stdout 读取结果并返回。

这是一个简化版本，旨在展示“代理转发”的核心思想：

// 文件路径：forth-proxy/proxy.js const express = require("express"); const cors = require("cors"); const { spawn } = require("child_process"); const app = express(); app.use(cors()); app.use(express.json()); app.post("/mcp", (req, res) => { const { method, params } = req.body || {}; // 1. 启动本地 MCP Server 子进程 const child = spawn("node", ["./local-server/index.js"], { cwd: process.env.LOCAL_SERVER_DIR || "./local-server", stdio: ["pipe", "pipe", "pipe"] }); let output = ""; let errorOutput = ""; child.stdout.on("data", (data) => { output += data.toString(); }); child.stderr.on("data", (data) => { errorOutput += data.toString(); }); // 2. 构造 MCP 初始化请求 const initRequest = { jsonrpc: "2.0", id: req.body.id || 1, method: "initialize", params: { protocolVersion: "2024-11-05", capabilities: {}, clientInfo: { name: "forth-proxy", version: "1.0.0" } } }; child.stdin.write(JSON.stringify(initRequest) + "\n"); // 3. 等待一段时间后再发送真实请求 // 实际项目中需要更完善的初始化握手和缓冲处理 setTimeout(() => { const toolRequest = { jsonrpc: "2.0", id: (req.body.id || 1) + 1, method: "tools/call", params: { name: "echo", arguments: { message: params?.message || "hello" } } }; child.stdin.write(JSON.stringify(toolRequest) + "\n"); }, 500); // 4. 收集结果并返回 setTimeout(() => { child.kill(); res.json({ jsonrpc: "2.0", result: { content: [ { type: "text", text: output.trim() || `错误信息: ${errorOutput}` } ] } }); }, 2000); }); app.listen(process.env.PORT || 3000, () => { console.error(`Forth proxy listening on ${process.env.PORT || 3000}`); });

这个示例比较粗糙，但它演示了代理的基本工作方式：代理不需要自己实现复杂的 MCP 语义，只需要把请求转发给本地 MCP 子进程。实际生产环境里，应该使用正式的 MCP Client SDK 来管理连接和协议生命周期。

4.4 使用官方 MCP Client 改进代理

更规范的写法是，在代理进程里同时扮演 MCP Client 角色。这样你不需要手动解析 JSON-RPC。

安装@modelcontextprotocol/sdk：

npm install @modelcontextprotocol/sdk

改进后的proxy-client.js：

// 文件路径：forth-proxy/proxy-client.js const express = require("express"); const cors = require("cors"); const { Client } = require("@modelcontextprotocol/sdk/client/index.js"); const { StdioClientTransport } = require("@modelcontextprotocol/sdk/client/stdio.js"); const app = express(); app.use(cors()); app.use(express.json()); async function callLocalMCP(inputMessage) { const transport = new StdioClientTransport({ command: "node", args: ["./local-server/index.js"], cwd: process.env.LOCAL_SERVER_DIR || "./local-server" }); const client = new Client({ name: "forth-proxy-client", version: "1.0.0" }); await client.connect(transport); const result = await client.request( { method: "tools/call", params: { name: "echo", arguments: { message: inputMessage } } }, { timeout: 10000 } ); await client.close(); return result; } app.post("/mcp", async (req, res) => { try { const message = req.body?.params?.message || "hello"; const result = await callLocalMCP(message); res.json(result); } catch (error) { res.status(500).json({ error: error.message }); } }); app.listen(process.env.PORT || 3000, () => { console.error(`Forth proxy with MCP client listening on ${process.env.PORT || 3000}`); });

这里我们没有直接操作 JSON-RPC，而是用了官方 SDK 的 Client 和 StdioClientTransport。tools/call请求会通过子进程发送给本地 MCP Server，返回值再通过 HTTP 返回给远程调用方。

4.5 配置远程 AI 客户端

现在你的代理已经监听在3000端口。假设你打算让云端 AI 客户端通过这个代理来访问本地工具，需要让代理服务器地址能被远程客户端访问。

如果代理运行在本地开发机，但远程客户端在云上，你有几种选择：

• 将代理部署到一台公网服务器上，并通过安全方式访问本地 MCP Server。
• 使用内网穿透或云厂商的安全隧道（注意：必须正规、合法，且经过授权）。
• 在团队内网部署，远程客户端与代理处于同一内网。

注意：无论使用哪种方式，都必须加上身份验证，不能直接把/mcp接口暴露给所有人。

为了简单测试，你可以先在本机用 curl 验证代理：

curl -X POST http://127.0.0.1:3000/mcp \ -H "Content-Type: application/json" \ -d '{"method":"tools/call","params":{"message":"hello from remote"}}'

预期返回一个包含[local echo] hello from remote的 JSON 结构。

4.6 添加简单的 Token 鉴权

在真实环境中，代理必须校验请求来源。这里演示一个最基础的 Bearer Token 校验：

// 在 proxy-client.js 中加入中间件 app.use((req, res, next) => { const authHeader = req.headers.authorization || ""; const token = authHeader.replace("Bearer ", ""); if (token !== process.env.ACCESS_TOKEN) { return res.status(401).json({ error: "unauthorized" }); } next(); });

启动时设置环境变量：

ACCESS_TOKEN=your-secret-token PORT=3000 node proxy-client.js

这样远程 AI 客户端在请求时，需要在 Header 中带上Authorization: Bearer your-secret-token。

5. 常见问题与排查思路

在实际搭这套方案时，我遇到过不少坑。下面整理几个高频问题，按“现象 -> 原因 -> 解决方案”的顺序展开。

5.1 本地 MCP Server 启动成功，但代理请求超时

如果你的代理是用spawn手动实现的，最容易出问题的是 MCP 协议必须经过initialize、initialized、tools/list等握手步骤，直接写tools/call会被 Server 拒绝。这也是为什么我更推荐用官方 SDK Client，它已经封装好了握手逻辑。

5.2 远程 AI 客户端连接时提示“工具注册不上”

这个问题在 Figma MCP、Playwright MCP 等社区工具上特别常见。现象是远程客户端能访问代理，但找不到任何工具。

排查顺序：

1. 先确认本地 MCP Server 是否真正暴露了工具。
2. 用tools/list请求手动查询工具列表。
3. 检查代理返回的响应格式是否符合客户端预期。

可能的原因有：

• 本地 MCP Server 没有正确注册工具，可能因为参数 schema 写错。
• 代理层只做了tools/call转发，没有处理tools/list。
• 客户端要求 MCP Server 返回 capabilities，但代理没有透传。

如果是用官方 SDK Client，可以通过client.listTools()来验证：

const tools = await client.listTools(); console.log(tools);

确保工具列表非空后，再检查远程客户端配置。

5.3 代理服务可以访问，但只能本机访问

如果app.listen(3000)默认监听的是所有网卡，那本机外也能访问。但如果你显式写了app.listen(3000, "127.0.0.1")，则只有本机可以请求。

有些云服务器有防火墙或安全组，即使代理监听0.0.0.0，外网依然无法访问。需要检查：

• 云厂商安全组是否放行对应端口。
• 本地防火墙是否阻止了入站连接。
• 代理进程是否使用了 Docker 且端口映射是否正确。

再次强调：不要为了省事直接把端口放行到公网，除非你加了强认证，并且明确知道自己在做什么。

5.4 提示 JSON-RPC 方法不存在

如果远程客户端或代理代码里使用了tools/call，但本地 MCP Server 返回“Method not found”，通常是因为 SDK 版本差异。

MCP 协议仍在演进中，不同版本的 SDK 对方法名、参数结构、协议版本的兼容策略不同。建议：

• 统一本地 MCP Server、代理 SDK、远程客户端的 MCP 协议版本。
• 查看各组件日志中的实际请求方法名。
• 尝试使用默认协议版本，避免手动指定不兼容的版本。

6. 最佳实践与工程建议

把上面的流程跑通之后，接下来要考虑的是稳定性和安全性。下面几条建议都来自实际项目中的教训。

6.1 本地 MCP Server 与代理分层

不要把代理逻辑和 MCP Server 逻辑全写在一个进程里。按目录拆开：

forth-mcp-demo/ ├── local-server/ # 本地 MCP 工具实现 ├── forth-proxy/ # 统一接入层、认证、日志 └── shared/ # 共享的类型定义和配置

这样本地工具可以独立升级，代理层可以单独加限流、审计，不影响业务工具。

6.2 使用环境变量管理敏感配置

不要把 Token、API Key、路径写在代码里。使用.env文件或环境变量注入：

PORT=3000 ACCESS_TOKEN=your-secret-token LOCAL_SERVER_DIR=/data/forth-mcp/local-server MCP_PROTOCOL_VERSION=2024-11-05

同时在.gitignore中忽略.env文件。

6.3 为代理增加访问日志和请求审计

远程 AI 客户端调用本地工具时，应当记录：

• 调用时间、客户端 IP。
• 调用的工具名称。
• 请求参数摘要。
• 返回状态和耗时。

这样一旦出现安全问题，或者某个工具被误调用，能快速追溯。日志不要记录完整敏感参数，尤其是数据库连接串、密码、Token 等。

6.4 不要让代理处于“无状态”状态

如果你用spawn每次请求都启动一个新的本地 MCP Server 子进程，会导致资源浪费和大量握手开销。更合理的方式是：

• 启动常驻的本地 MCP Server（HTTP 模式）。
• 代理进程通过 MCP Client SDK 连接这个 Server，连接后复用。
• 为每个远程会话维护独立的 Client 实例，避免串数据。

但这会提升实现复杂度。如果只是小范围使用，每次启动子进程也可以，但一定要限制并发数量，并设置超时。

6.5 网络传输安全

远程客户端和代理之间的通信，强烈建议使用 HTTPS。如果你是自建服务，可以通过 Nginx 或 Caddy 终结 TLS；如果使用云厂商的负载均衡，开启 HTTPS 证书也很方便。

代理本身应只监听内网地址或 localhost，外层由 Nginx 反向代理。示例 Nginx 配置片段：

server { listen 443 ssl; server_name mcp.example.com; ssl_certificate /etc/nginx/cert.pem; ssl_certificate_key /etc/nginx/key.pem; location /mcp { proxy_pass http://127.0.0.1:3000; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header Authorization $http_authorization; } }

6.6 权限边界设计

不要把所有的本地工具一股脑透传出去。建议在代理层维护一个“允许调用名单”，只有名单内的工具才能被远程调用。

const ALLOWED_TOOLS = process.env.ALLOWED_TOOLS ? process.env.ALLOWED_TOOLS.split(",") : ["echo"]; app.post("/mcp", async (req, res) => { const toolName = req.body?.params?.name; if (toolName && !ALLOWED_TOOLS.includes(toolName)) { return res.status(403).json({ error: `tool ${toolName} is not allowed` }); } // 继续处理 });

这样即使本地 MCP Server 暴露了数据库删除工具，也不会被远程 AI 客户端随意调用。

6.7 监控与告警

如果你的代理服务于生产环境，建议增加：

• 健康检查接口/healthz，返回当前代理进程和本地 MCP Server 的连接状态。
• 请求成功率、延迟指标，接入 Prometheus 或简单的定时 curl 告警。
• 日志轮转，避免代理日志占用过多磁盘。

7. 总结与下一步学习路线

通过本文，你应该已经掌握了几个关键点：

• MCP 协议中 Host、Client、Server 三者的关系。
• 本地 MCP Server 为什么不能被远程 AI 客户端直接访问。
• Forth MCP 这类桥接/代理方案的工作原理。
• 使用 Node.js 实现一个带 Token 鉴权的 MCP 代理的完整过程。
• 常见连接失败、工具注册不上、超时等问题的排查方法。

如果你打算深入学习，可以继续沿着这几个方向延伸：

• 阅读 MCP 协议文档中的initialize、tools/list、resources/list、prompts/list等核心方法。
• 学习如何将本地 MCP Server 从 stdio 切换到 HTTP/SSE 模式。
• 研究云厂商的托管 MCP 网关，以及它们与自建代理的异同。
• 尝试为你的代理加入 WebSocket 支持，让 AI 客户端能进行流式交互。

在实际项目中，请优先关注安全边界：远程访问本地工具能力虽然方便，但也意味着攻击面扩大。每次修改代理配置时，都应遵循最小权限原则，先在测试环境验证，再逐步放开访问范围。

如果你已经实际运行过一个本地 MCP Server，不妨现在就把它接到代理层试点一下，从最简单的echo工具开始，逐步替换成真正有价值的生产工具。只有亲手跑通一遍，才会对这些协议细节有更深的体会。