如果給現(xiàn)在的 AI 編程工具排名最尷尬的瞬間大概是這樣模型已經(jīng)能寫出像模像樣的代碼了但它看不到你本地數(shù)據(jù)庫里的表結構它能調用各種工具了但工具大多跑在云端根本碰不到你電腦里的文件。明明 AI 的能力在指數(shù)級增長可一旦涉及本地數(shù)據(jù)就立刻變成了巧婦難為無米之炊。這個問題的根源在 MCP 的架構約束里。MCPModel Context Protocol服務端往往部署在貼近數(shù)據(jù)的那臺機器上而 AI 客戶端卻越來越多地運行在云端。于是一個非常現(xiàn)實的需求出現(xiàn)了遠程 AI 客戶端如何安全地調用本地 MCP 服務器上的工具。Forth MCP 就是針對這個需求出現(xiàn)的工具。從項目定位看它的目標非常明確——give any remote AI client access to your local MCP servers也就是給任何遠程 AI 客戶端一個訪問本地 MCP 服務器的入口。這篇文章不打算只復述一個項目而是想把整個工程問題講透MCP 的架構約束到底是什么Forth MCP 這類工具解決的是哪一層問題以及即使不依賴它你也能用 SSH 隧道、內網(wǎng)穿透等通用手段實現(xiàn)同一條鏈路。讀完你至少能判斷自己該不該引入這類工具以及接入時真正容易踩的坑在哪里。1. MCP 的架構約束為什么服務器總在本地客戶端卻可能在云端MCP 的設計目標很清晰標準化 AI 應用與外部工具、數(shù)據(jù)源的連接方式。在 MCP 出現(xiàn)之前每個 Agent 想接入一個新工具幾乎都要寫一遍專用的集成代碼。接入數(shù)據(jù)庫要寫驅動接入瀏覽器要寫自動化腳本接入內部系統(tǒng)要寫 API 封裝。整個工具生態(tài)是碎片化的。MCP 出現(xiàn)后連接方式被抽象成了一個統(tǒng)一協(xié)議AI 客戶端負責發(fā)現(xiàn)和調用工具MCP 服務器負責把具體能力包裝成標準接口。但這里有一個很容易被忽略的架構細節(jié)MCP 最早的傳輸方式并不是 HTTP而是 stdio。也就是說AI 客戶端在本地直接啟動一個 MCP 服務器子進程通過標準輸入輸出和它通信。這個設計在本地場景下非常好用不用開端口不用處理網(wǎng)絡權限不用糾結認證拉起進程就能用。MCP 最早要解決的恰恰是給本地 AI 編程工具接上本地文件系統(tǒng)和終端能力這個問題stdio 在當時的場景里是最優(yōu)解。問題恰恰出在這個本地優(yōu)先的設計上。當 AI 客戶端跑在云端時stdio 完全不成立。云端進程不可能直接啟動你電腦上的子進程也不可能訪問你本地磁盤里的文件。后來 MCP 協(xié)議也做了演進新版本 SDK 加入了基于 HTTP 的傳輸方式服務端可以把能力暴露成標準的 HTTP 接口。但這只是解決了傳輸層能不能走 HTTP的問題并沒有解決你的本地 MCP Server 如何被遠程客戶端找到的問題。你的機器沒有公網(wǎng) IP端口在防火墻后面服務也沒有域名。本地 MCP Server 與遠程 AI 客戶端之間仍然隔著一條天然的網(wǎng)絡邊界。這條邊界就是 Forth MCP 這類工具存在的理由。2. MCP 核心概念三種角色、兩種傳輸與本地場景要理解 Forth MCP 的價值先要把 MCP 的幾個基礎概念拆開。很多人第一次配置 MCP 時會把 Host 和 Client 混為一談結果在配置界面里完全找不到方向。MCP 協(xié)議里有三個角色可以做一個簡單的類比Host 是用戶直接使用的 AI 應用相當于一個調度中心Client 是 Host 內部負責建立具體連接的組件相當于連接器Server 是能力提供方相當于工具供應商。一個 Host 可以啟動多個 Client每個 Client 連接一個 Server。每個 Server 內部可以暴露多個 Tool每個 Tool 就是一個可以被 AI 調用的函數(shù)。這三個角色的關系可以這樣理解角色類比職責典型例子Host調度中心管理會話、決定何時調用工具Claude、Cursor、Codex、自研 AgentClient連接器與某個 Server 建立連接每個 Host 內部的 MCP Client 組件Server工具供應商提供可調用的工具能力文件系統(tǒng)、數(shù)據(jù)庫、瀏覽器操作服務MCP 的傳輸方式也經(jīng)歷過明顯變化。早期的實現(xiàn)以 stdio 為主適合本地進程通信后來引入了基于 HTTP 的 Streamable HTTP 傳輸用服務端事件流的方式支持遠程請求。對開發(fā)者來說選擇哪種傳輸方式取決于部署位置本地調試用 stdio 最快遠程訪問則必須走 HTTP。本地 MCP Server 的典型場景包括讀取本地文件系統(tǒng)的工具、連接開發(fā)數(shù)據(jù)庫的查詢工具、控制本地瀏覽器的自動化工具、讀取 IDE 上下文的輔助工具。這些工具的共同特點都是需要訪問本機資源。在本地運行時它們的數(shù)據(jù)不出機器安全邊界非常清晰。一旦引入遠程訪問這個安全邊界就不再天然成立而是需要額外的機制來保證。3. Forth MCP 的定位給遠程 AI 客戶端一個訪問本地 MCP 的入口從項目標題來判斷Forth MCP 做的事情非常聚焦讓任何遠程 AI 客戶端都能訪問本地的 MCP 服務器。這個表述里有三個關鍵詞值得逐字拆解。第一個關鍵詞是任何。它說明這個工具試圖做到協(xié)議層兼容而不是綁定某一家模型廠商、某個 IDE 或某個特定 Agent 框架。當前 AI 工具市場非常分裂有云端助手、有本地 IDE、有命令行 Agent每個工具的 MCP 接入方式都不完全一樣。如果有一個通用通道能讓這些客戶端統(tǒng)一訪問本地 MCP那么本地工具能力就變成了一種可復用的網(wǎng)絡服務。第二個關鍵詞是遠程。它明確說明訪問方與被訪問方不在同一臺機器上。遠程訪問要解決的核心問題包括如何穿過 NAT 和防火墻、如何保持長連接穩(wěn)定、如何防止未授權訪問。這不只是把端口映射出去那么簡單。第三個關鍵詞是本地。它強調 MCP Server 仍然運行在本地而不是被部署到云端。這個設計的直接好處是數(shù)據(jù)不用出域MCP Server 讀取數(shù)據(jù)庫、操作文件系統(tǒng)時所有數(shù)據(jù)仍然停留在本地機器上。遠程 AI 客戶端通過工具調用拿到的只是結果而不是完整的本地數(shù)據(jù)權限。從技術架構上推斷Forth MCP 比較合理的實現(xiàn)方式是在本地啟動一個網(wǎng)關進程它通過 stdio 或本地 HTTP 與 MCP Server 通信再通過一條經(jīng)過認證和加密的通道把能力暴露給遠程 AI 客戶端。遠程客戶端看到的是一個標準的 MCP 輸入輸出而真正的工具執(zhí)行仍然發(fā)生在本地。這個本地執(zhí)行、遠程調用的模型本質上是在 MCP 之上又疊加了一層遠程訪問能力。需要說明的是Forth MCP 仍是一個發(fā)展階段的項目具體安裝方式、配置參數(shù)和命令行用法請以項目倉庫 README 為準。下文要講的通用方案不依賴這個項目也可以落地而且這恰恰是理解它價值的最快方式先自己把鏈路搭一遍你就知道它幫你省掉了哪部分工作。4. Agent Skill 與 MCP兩個高頻概念的區(qū)別與互補最近在很多技術討論里有一個問題反復出現(xiàn)Agent Skill 和 MCP 到底有什么區(qū)別這個困惑很正常因為主流的 Agent 平臺都在推自己的技能框架文檔里又把 MCP 和工具調用放在一起講很容易讓開發(fā)者覺得兩者是同類東西。Skill 的本質是提示詞 示例的打包。它告訴 Agent 面對某個場景時應該怎么做比如當用戶要求生成圖表時調用這個 Python 腳本并按這個 JSON 格式解析結果。Skill 更像是一份給 Agent 看的操作手冊優(yōu)點是靈活、編寫成本低缺點是沒有統(tǒng)一的運行時標準不同平臺之間的 Skill 不能直接互通。MCP 的本質是協(xié)議 運行時。它定義了客戶端和服務端之間如何發(fā)現(xiàn)工具、如何發(fā)起調用、如何返回結果并且提供了統(tǒng)一的數(shù)據(jù)格式。Server 負責真正執(zhí)行Client 只按協(xié)議調用。它比 Skill 更重但換來的是跨平臺兼容性和可復用的能力部署。用一個類比來說Skill 像是給新人準備的 SOP 文檔告訴它遇到什么情況按什么步驟處理MCP 像是公司內部統(tǒng)一制定的 RPC 接口規(guī)范所有的服務都按這個規(guī)范接入調用方不需要關心服務內部怎么實現(xiàn)。Skill 解決怎么做的問題MCP 解決怎么穩(wěn)定連接和調用的問題。這兩個概念不能互相替代實際項目里通?；パa使用Agent 通過 Skill 決定在什么場景下選擇哪個工具再通過 MCP 以標準方式調用這個工具的具體能力。Forth MCP 所在的位置是 MCP 這一層它把本地工具被遠程調用變成網(wǎng)絡服務而具體的技能編排仍然由 AI 客戶端自己完成。5. 環(huán)境準備與最小 MCP Server 示例在打通遠程訪問之前先準備一個能跑的最小 MCP Server。這里我們用社區(qū)里很常見的 FastMCP 封裝來做演示它的 API 比較簡潔適合快速搭建工具服務。依賴安裝和示例代碼如下。環(huán)境準備清單一臺可以作為部署環(huán)境的本地機器操作系統(tǒng)不限Linux / macOS / Windows。Python 3.9 及以上版本pip 可用。一臺有公網(wǎng) IP 的中繼服務器用于后面的 SSH 隧道或內網(wǎng)穿透方案。一個遠程 AI 客戶端比如你正在用的云端編程助手或自建的 Agent 程序。安裝依賴pip install fastmcp然后創(chuàng)建最小 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 傳輸模式這種模式只適合本地進程調用。如果要把這個服務放到網(wǎng)絡上供遠程客戶端訪問需要根據(jù)你安裝的 FastMCP 版本文檔把傳輸模式調整為基于 HTTP 的 Streamable HTTP 模式。不同版本的參數(shù)名稱和執(zhí)行細節(jié)有差異請以你實際安裝版本的官方文檔為準。后面的隧道方案都是假設本地 MCP Server 已經(jīng)變成 HTTP 服務并監(jiān)聽在某個端口上。如果你用curl在本地能訪問到這個 HTTP 服務說明 MCP Server 已經(jīng)具備被遠程訪問的傳輸基礎。下面的工作就是打通網(wǎng)絡鏈路。6. 通用方案一SSH 反向隧道打通遠程訪問如果你想在十分鐘內驗證遠程 AI 客戶端訪問本地 MCP Server這條路最簡單可靠的工具是 SSH 反向隧道。它不依賴任何第三方穿透服務只需要一臺有公網(wǎng) IP 的中繼服務器。原理并不復雜本地機器主動向中繼服務器建立一條 SSH 連接同時讓中繼服務器監(jiān)聽某個端口所有到達這個端口的請求都會通過加密的 SSH 隧道轉發(fā)到本地 MCP Server 的端口。相當于從公網(wǎng)打了一條穿回你內網(wǎng)的加密管道。假設中繼服務器的 IP 是 203.0.113.10文檔示例地址本地 MCP Server 監(jiān)聽在 8765 端口執(zhí)行下面的命令ssh -R 8900:localhost:8765 root203.0.113.10 -N命令參數(shù)說明-R 8900:localhost:8765在中繼服務器上開放 8900 端口所有到達該端口的請求轉發(fā)到本機的 8765 端口。-N只做端口轉發(fā)不執(zhí)行遠程命令。中繼服務器的 SSH 配置里需要允許 GatewayPorts否則遠程客戶端無法通過服務器公網(wǎng) IP 訪問監(jiān)聽的端口。隧道建立后遠程 AI 客戶端的 MCP Server 地址可以配置成類似下面的格式{ mcpServers: { local-utils-remote: { url: http://203.0.113.10:8900/mcp } } }這里有兩個關鍵點。第一URL 中的路徑必須和 MCP Server 暴露的真實路徑一致不同 SDK 的默認路徑存在差異以實際服務輸出為準。第二SSH 隧道本身提供了鏈路加密但 MCP Server 如果沒有認證任何人都可以調用你的工具。因此長期使用前至少要在接入層增加令牌認證或者用防火墻限制來源 IP。SSH 隧道方案的優(yōu)勢是零額外依賴、免費、穩(wěn)定缺點是配置比較原始。連接斷開后不會自動重連多個 MCP Server 需要多條隧道管理成本會上升。如果只是驗證概念這個方案足夠用如果要長期跑在團隊協(xié)作環(huán)境里可以考慮下一節(jié)的內網(wǎng)穿透方案。7. 通用方案二內網(wǎng)穿透工具的工程化落地把本地 MCP Server 暴露到公網(wǎng)如果不想維護自己的公網(wǎng)服務器可以先用 cloudflared 的 Quick Tunnel。它只需要一行命令就能把本地端口映射成一個臨時的公網(wǎng) HTTPS 地址。cloudflared tunnel --url http://localhost:8765啟動后終端會輸出一個https://xxx.trycloudflare.com形式的地址。這個地址自帶 HTTPS不需要額外域名把遠程 AI 客戶端的 MCP Server 地址配置成這個 HTTPS 地址即可。它的最大優(yōu)點是零配置、上手快缺點是臨時隧道地址不穩(wěn)定重啟后地址會變化不適合長期生產(chǎn)使用。如果需要固定地址和更細粒度的訪問控制可以考慮自建 frp 方案。frp 分為服務端和客戶端兩個部分服務端 frps 運行在有公網(wǎng) 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 等多種協(xié)議適合長期運行。但也要注意它的安全性完全取決于你的配置token 強度、服務端防火墻、端口暴露范圍都直接影響風險等級。建議服務端只對必要的來源 IP 開放并定期更換認證 token。不管是 SSH 隧道還是 frp本質上都只是在傳輸層打通了網(wǎng)絡。真正讓遠程 AI 客戶端能識別并調用 MCP 工具前提是 MCP Server 的傳輸方式與遠程客戶端兼容。如果本地 MCP Server 只支持 stdio無論隧道建得多好遠程客戶端也接不上。所以遠程可訪問的 MCP Server 必須使用 HTTP 類傳輸這句話值得在接入前反復確認。8. 安全邊界暴露本地 MCP 前必須守住的紅線把本地 MCP Server 暴露給遠程 AI 客戶端這件事本身就伴隨風險。和普通 HTTP 接口不同MCP Server 暴露的是工具調用能力調用結果可能直接影響本地系統(tǒng)。一個只讀的文件查詢工具和一個可以執(zhí)行任意命令的工具風險等級完全不是一回事。首先是最小權限原則。MCP Server 里的每個工具都應該盡量只做一件事只能訪問它必需的數(shù)據(jù)范圍。比如數(shù)據(jù)庫工具只暴露只讀查詢不要暴露刪除和更新文件操作工具限制可訪問的目錄不要讓 Agent 擁有遍歷整個文件系統(tǒng)的能力。工具內部也應該有路徑校驗防止通過../之類的穿越手段訪問白名單之外的目錄。其次是認證與授權隔離。凡是能遠程訪問的 MCP Server接入層必須做認證。最簡單的做法是在網(wǎng)關層配置一個靜態(tài)令牌遠程客戶端每次請求都攜帶該令牌。更嚴格的做法是為不同客戶端分配獨立憑據(jù)同時記錄每個憑據(jù)的調用記錄。這樣即使某個憑據(jù)泄露也能快速定位并單獨撤銷。然后是審計日志。MCP Server 每次收到工具調用都應該記錄調用時間、來源、參數(shù)和返回結果摘要。審計日志不是為了當時解決問題而是為了將來出問題時能最快還原現(xiàn)場。這個機制的成本很低收益卻非常大尤其是當多個遠程客戶端共享同一個 MCP Server 時。鏈路加密同樣不能省略。SSH 隧道和 cloudflared 默認自帶加密自建 frp 時要確認傳輸層是加密的。MCP 請求參數(shù)中可能攜帶敏感信息比如數(shù)據(jù)庫查詢條件、文件路徑、內部報錯內容明文傳輸?shù)焦W(wǎng)上是不可接受的。最后有些 MCP Server 根本不適合暴露到遠程。直接控制鼠標鍵盤、直接操作瀏覽器登錄態(tài)、直接持有云平臺密鑰的工具建議只保留在本地交互場景使用。這類工具一旦被遠程濫用影響范圍遠超數(shù)據(jù)泄露可能是對本地系統(tǒng)的直接控制。Forth MCP 這類工具如果實現(xiàn)得好應該把一部分安全能力做成內置功能上層認證、可暴露的 Server 清單管理、調用日志等。這其實是它相對通用內網(wǎng)穿透工具更有價值的地方通用隧道只解決網(wǎng)絡能通而 MCP 專用通道還要解決調用是否安全可控。9. 常見 遠程AI訪問本地MCP服務器：架構約束與解決方案
如果給現(xiàn)在的 AI 編程工具排名最尷尬的瞬間大概是這樣模型已經(jīng)能寫出像模像樣的代碼了但它看不到你本地數(shù)據(jù)庫里的表結構它能調用各種工具了但工具大多跑在云端根本碰不到你電腦里的文件。明明 AI 的能力在指數(shù)級增長可一旦涉及本地數(shù)據(jù)就立刻變成了巧婦難為無米之炊。這個問題的根源在 MCP 的架構約束里。MCPModel Context Protocol服務端往往部署在貼近數(shù)據(jù)的那臺機器上而 AI 客戶端卻越來越多地運行在云端。于是一個非常現(xiàn)實的需求出現(xiàn)了遠程 AI 客戶端如何安全地調用本地 MCP 服務器上的工具。Forth MCP 就是針對這個需求出現(xiàn)的工具。從項目定位看它的目標非常明確——give any remote AI client access to your local MCP servers也就是給任何遠程 AI 客戶端一個訪問本地 MCP 服務器的入口。這篇文章不打算只復述一個項目而是想把整個工程問題講透MCP 的架構約束到底是什么Forth MCP 這類工具解決的是哪一層問題以及即使不依賴它你也能用 SSH 隧道、內網(wǎng)穿透等通用手段實現(xiàn)同一條鏈路。讀完你至少能判斷自己該不該引入這類工具以及接入時真正容易踩的坑在哪里。1. MCP 的架構約束為什么服務器總在本地客戶端卻可能在云端MCP 的設計目標很清晰標準化 AI 應用與外部工具、數(shù)據(jù)源的連接方式。在 MCP 出現(xiàn)之前每個 Agent 想接入一個新工具幾乎都要寫一遍專用的集成代碼。接入數(shù)據(jù)庫要寫驅動接入瀏覽器要寫自動化腳本接入內部系統(tǒng)要寫 API 封裝。整個工具生態(tài)是碎片化的。MCP 出現(xiàn)后連接方式被抽象成了一個統(tǒng)一協(xié)議AI 客戶端負責發(fā)現(xiàn)和調用工具MCP 服務器負責把具體能力包裝成標準接口。但這里有一個很容易被忽略的架構細節(jié)MCP 最早的傳輸方式并不是 HTTP而是 stdio。也就是說AI 客戶端在本地直接啟動一個 MCP 服務器子進程通過標準輸入輸出和它通信。這個設計在本地場景下非常好用不用開端口不用處理網(wǎng)絡權限不用糾結認證拉起進程就能用。MCP 最早要解決的恰恰是給本地 AI 編程工具接上本地文件系統(tǒng)和終端能力這個問題stdio 在當時的場景里是最優(yōu)解。問題恰恰出在這個本地優(yōu)先的設計上。當 AI 客戶端跑在云端時stdio 完全不成立。云端進程不可能直接啟動你電腦上的子進程也不可能訪問你本地磁盤里的文件。后來 MCP 協(xié)議也做了演進新版本 SDK 加入了基于 HTTP 的傳輸方式服務端可以把能力暴露成標準的 HTTP 接口。但這只是解決了傳輸層能不能走 HTTP的問題并沒有解決你的本地 MCP Server 如何被遠程客戶端找到的問題。你的機器沒有公網(wǎng) IP端口在防火墻后面服務也沒有域名。本地 MCP Server 與遠程 AI 客戶端之間仍然隔著一條天然的網(wǎng)絡邊界。這條邊界就是 Forth MCP 這類工具存在的理由。2. MCP 核心概念三種角色、兩種傳輸與本地場景要理解 Forth MCP 的價值先要把 MCP 的幾個基礎概念拆開。很多人第一次配置 MCP 時會把 Host 和 Client 混為一談結果在配置界面里完全找不到方向。MCP 協(xié)議里有三個角色可以做一個簡單的類比Host 是用戶直接使用的 AI 應用相當于一個調度中心Client 是 Host 內部負責建立具體連接的組件相當于連接器Server 是能力提供方相當于工具供應商。一個 Host 可以啟動多個 Client每個 Client 連接一個 Server。每個 Server 內部可以暴露多個 Tool每個 Tool 就是一個可以被 AI 調用的函數(shù)。這三個角色的關系可以這樣理解角色類比職責典型例子Host調度中心管理會話、決定何時調用工具Claude、Cursor、Codex、自研 AgentClient連接器與某個 Server 建立連接每個 Host 內部的 MCP Client 組件Server工具供應商提供可調用的工具能力文件系統(tǒng)、數(shù)據(jù)庫、瀏覽器操作服務MCP 的傳輸方式也經(jīng)歷過明顯變化。早期的實現(xiàn)以 stdio 為主適合本地進程通信后來引入了基于 HTTP 的 Streamable HTTP 傳輸用服務端事件流的方式支持遠程請求。對開發(fā)者來說選擇哪種傳輸方式取決于部署位置本地調試用 stdio 最快遠程訪問則必須走 HTTP。本地 MCP Server 的典型場景包括讀取本地文件系統(tǒng)的工具、連接開發(fā)數(shù)據(jù)庫的查詢工具、控制本地瀏覽器的自動化工具、讀取 IDE 上下文的輔助工具。這些工具的共同特點都是需要訪問本機資源。在本地運行時它們的數(shù)據(jù)不出機器安全邊界非常清晰。一旦引入遠程訪問這個安全邊界就不再天然成立而是需要額外的機制來保證。3. Forth MCP 的定位給遠程 AI 客戶端一個訪問本地 MCP 的入口從項目標題來判斷Forth MCP 做的事情非常聚焦讓任何遠程 AI 客戶端都能訪問本地的 MCP 服務器。這個表述里有三個關鍵詞值得逐字拆解。第一個關鍵詞是任何。它說明這個工具試圖做到協(xié)議層兼容而不是綁定某一家模型廠商、某個 IDE 或某個特定 Agent 框架。當前 AI 工具市場非常分裂有云端助手、有本地 IDE、有命令行 Agent每個工具的 MCP 接入方式都不完全一樣。如果有一個通用通道能讓這些客戶端統(tǒng)一訪問本地 MCP那么本地工具能力就變成了一種可復用的網(wǎng)絡服務。第二個關鍵詞是遠程。它明確說明訪問方與被訪問方不在同一臺機器上。遠程訪問要解決的核心問題包括如何穿過 NAT 和防火墻、如何保持長連接穩(wěn)定、如何防止未授權訪問。這不只是把端口映射出去那么簡單。第三個關鍵詞是本地。它強調 MCP Server 仍然運行在本地而不是被部署到云端。這個設計的直接好處是數(shù)據(jù)不用出域MCP Server 讀取數(shù)據(jù)庫、操作文件系統(tǒng)時所有數(shù)據(jù)仍然停留在本地機器上。遠程 AI 客戶端通過工具調用拿到的只是結果而不是完整的本地數(shù)據(jù)權限。從技術架構上推斷Forth MCP 比較合理的實現(xiàn)方式是在本地啟動一個網(wǎng)關進程它通過 stdio 或本地 HTTP 與 MCP Server 通信再通過一條經(jīng)過認證和加密的通道把能力暴露給遠程 AI 客戶端。遠程客戶端看到的是一個標準的 MCP 輸入輸出而真正的工具執(zhí)行仍然發(fā)生在本地。這個本地執(zhí)行、遠程調用的模型本質上是在 MCP 之上又疊加了一層遠程訪問能力。需要說明的是Forth MCP 仍是一個發(fā)展階段的項目具體安裝方式、配置參數(shù)和命令行用法請以項目倉庫 README 為準。下文要講的通用方案不依賴這個項目也可以落地而且這恰恰是理解它價值的最快方式先自己把鏈路搭一遍你就知道它幫你省掉了哪部分工作。4. Agent Skill 與 MCP兩個高頻概念的區(qū)別與互補最近在很多技術討論里有一個問題反復出現(xiàn)Agent Skill 和 MCP 到底有什么區(qū)別這個困惑很正常因為主流的 Agent 平臺都在推自己的技能框架文檔里又把 MCP 和工具調用放在一起講很容易讓開發(fā)者覺得兩者是同類東西。Skill 的本質是提示詞 示例的打包。它告訴 Agent 面對某個場景時應該怎么做比如當用戶要求生成圖表時調用這個 Python 腳本并按這個 JSON 格式解析結果。Skill 更像是一份給 Agent 看的操作手冊優(yōu)點是靈活、編寫成本低缺點是沒有統(tǒng)一的運行時標準不同平臺之間的 Skill 不能直接互通。MCP 的本質是協(xié)議 運行時。它定義了客戶端和服務端之間如何發(fā)現(xiàn)工具、如何發(fā)起調用、如何返回結果并且提供了統(tǒng)一的數(shù)據(jù)格式。Server 負責真正執(zhí)行Client 只按協(xié)議調用。它比 Skill 更重但換來的是跨平臺兼容性和可復用的能力部署。用一個類比來說Skill 像是給新人準備的 SOP 文檔告訴它遇到什么情況按什么步驟處理MCP 像是公司內部統(tǒng)一制定的 RPC 接口規(guī)范所有的服務都按這個規(guī)范接入調用方不需要關心服務內部怎么實現(xiàn)。Skill 解決怎么做的問題MCP 解決怎么穩(wěn)定連接和調用的問題。這兩個概念不能互相替代實際項目里通?；パa使用Agent 通過 Skill 決定在什么場景下選擇哪個工具再通過 MCP 以標準方式調用這個工具的具體能力。Forth MCP 所在的位置是 MCP 這一層它把本地工具被遠程調用變成網(wǎng)絡服務而具體的技能編排仍然由 AI 客戶端自己完成。5. 環(huán)境準備與最小 MCP Server 示例在打通遠程訪問之前先準備一個能跑的最小 MCP Server。這里我們用社區(qū)里很常見的 FastMCP 封裝來做演示它的 API 比較簡潔適合快速搭建工具服務。依賴安裝和示例代碼如下。環(huán)境準備清單一臺可以作為部署環(huán)境的本地機器操作系統(tǒng)不限Linux / macOS / Windows。Python 3.9 及以上版本pip 可用。一臺有公網(wǎng) IP 的中繼服務器用于后面的 SSH 隧道或內網(wǎng)穿透方案。一個遠程 AI 客戶端比如你正在用的云端編程助手或自建的 Agent 程序。安裝依賴pip install fastmcp然后創(chuàng)建最小 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 傳輸模式這種模式只適合本地進程調用。如果要把這個服務放到網(wǎng)絡上供遠程客戶端訪問需要根據(jù)你安裝的 FastMCP 版本文檔把傳輸模式調整為基于 HTTP 的 Streamable HTTP 模式。不同版本的參數(shù)名稱和執(zhí)行細節(jié)有差異請以你實際安裝版本的官方文檔為準。后面的隧道方案都是假設本地 MCP Server 已經(jīng)變成 HTTP 服務并監(jiān)聽在某個端口上。如果你用curl在本地能訪問到這個 HTTP 服務說明 MCP Server 已經(jīng)具備被遠程訪問的傳輸基礎。下面的工作就是打通網(wǎng)絡鏈路。6. 通用方案一SSH 反向隧道打通遠程訪問如果你想在十分鐘內驗證遠程 AI 客戶端訪問本地 MCP Server這條路最簡單可靠的工具是 SSH 反向隧道。它不依賴任何第三方穿透服務只需要一臺有公網(wǎng) IP 的中繼服務器。原理并不復雜本地機器主動向中繼服務器建立一條 SSH 連接同時讓中繼服務器監(jiān)聽某個端口所有到達這個端口的請求都會通過加密的 SSH 隧道轉發(fā)到本地 MCP Server 的端口。相當于從公網(wǎng)打了一條穿回你內網(wǎng)的加密管道。假設中繼服務器的 IP 是 203.0.113.10文檔示例地址本地 MCP Server 監(jiān)聽在 8765 端口執(zhí)行下面的命令ssh -R 8900:localhost:8765 root203.0.113.10 -N命令參數(shù)說明-R 8900:localhost:8765在中繼服務器上開放 8900 端口所有到達該端口的請求轉發(fā)到本機的 8765 端口。-N只做端口轉發(fā)不執(zhí)行遠程命令。中繼服務器的 SSH 配置里需要允許 GatewayPorts否則遠程客戶端無法通過服務器公網(wǎng) IP 訪問監(jiān)聽的端口。隧道建立后遠程 AI 客戶端的 MCP Server 地址可以配置成類似下面的格式{ mcpServers: { local-utils-remote: { url: http://203.0.113.10:8900/mcp } } }這里有兩個關鍵點。第一URL 中的路徑必須和 MCP Server 暴露的真實路徑一致不同 SDK 的默認路徑存在差異以實際服務輸出為準。第二SSH 隧道本身提供了鏈路加密但 MCP Server 如果沒有認證任何人都可以調用你的工具。因此長期使用前至少要在接入層增加令牌認證或者用防火墻限制來源 IP。SSH 隧道方案的優(yōu)勢是零額外依賴、免費、穩(wěn)定缺點是配置比較原始。連接斷開后不會自動重連多個 MCP Server 需要多條隧道管理成本會上升。如果只是驗證概念這個方案足夠用如果要長期跑在團隊協(xié)作環(huán)境里可以考慮下一節(jié)的內網(wǎng)穿透方案。7. 通用方案二內網(wǎng)穿透工具的工程化落地把本地 MCP Server 暴露到公網(wǎng)如果不想維護自己的公網(wǎng)服務器可以先用 cloudflared 的 Quick Tunnel。它只需要一行命令就能把本地端口映射成一個臨時的公網(wǎng) HTTPS 地址。cloudflared tunnel --url http://localhost:8765啟動后終端會輸出一個https://xxx.trycloudflare.com形式的地址。這個地址自帶 HTTPS不需要額外域名把遠程 AI 客戶端的 MCP Server 地址配置成這個 HTTPS 地址即可。它的最大優(yōu)點是零配置、上手快缺點是臨時隧道地址不穩(wěn)定重啟后地址會變化不適合長期生產(chǎn)使用。如果需要固定地址和更細粒度的訪問控制可以考慮自建 frp 方案。frp 分為服務端和客戶端兩個部分服務端 frps 運行在有公網(wǎng) 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 等多種協(xié)議適合長期運行。但也要注意它的安全性完全取決于你的配置token 強度、服務端防火墻、端口暴露范圍都直接影響風險等級。建議服務端只對必要的來源 IP 開放并定期更換認證 token。不管是 SSH 隧道還是 frp本質上都只是在傳輸層打通了網(wǎng)絡。真正讓遠程 AI 客戶端能識別并調用 MCP 工具前提是 MCP Server 的傳輸方式與遠程客戶端兼容。如果本地 MCP Server 只支持 stdio無論隧道建得多好遠程客戶端也接不上。所以遠程可訪問的 MCP Server 必須使用 HTTP 類傳輸這句話值得在接入前反復確認。8. 安全邊界暴露本地 MCP 前必須守住的紅線把本地 MCP Server 暴露給遠程 AI 客戶端這件事本身就伴隨風險。和普通 HTTP 接口不同MCP Server 暴露的是工具調用能力調用結果可能直接影響本地系統(tǒng)。一個只讀的文件查詢工具和一個可以執(zhí)行任意命令的工具風險等級完全不是一回事。首先是最小權限原則。MCP Server 里的每個工具都應該盡量只做一件事只能訪問它必需的數(shù)據(jù)范圍。比如數(shù)據(jù)庫工具只暴露只讀查詢不要暴露刪除和更新文件操作工具限制可訪問的目錄不要讓 Agent 擁有遍歷整個文件系統(tǒng)的能力。工具內部也應該有路徑校驗防止通過../之類的穿越手段訪問白名單之外的目錄。其次是認證與授權隔離。凡是能遠程訪問的 MCP Server接入層必須做認證。最簡單的做法是在網(wǎng)關層配置一個靜態(tài)令牌遠程客戶端每次請求都攜帶該令牌。更嚴格的做法是為不同客戶端分配獨立憑據(jù)同時記錄每個憑據(jù)的調用記錄。這樣即使某個憑據(jù)泄露也能快速定位并單獨撤銷。然后是審計日志。MCP Server 每次收到工具調用都應該記錄調用時間、來源、參數(shù)和返回結果摘要。審計日志不是為了當時解決問題而是為了將來出問題時能最快還原現(xiàn)場。這個機制的成本很低收益卻非常大尤其是當多個遠程客戶端共享同一個 MCP Server 時。鏈路加密同樣不能省略。SSH 隧道和 cloudflared 默認自帶加密自建 frp 時要確認傳輸層是加密的。MCP 請求參數(shù)中可能攜帶敏感信息比如數(shù)據(jù)庫查詢條件、文件路徑、內部報錯內容明文傳輸?shù)焦W(wǎng)上是不可接受的。最后有些 MCP Server 根本不適合暴露到遠程。直接控制鼠標鍵盤、直接操作瀏覽器登錄態(tài)、直接持有云平臺密鑰的工具建議只保留在本地交互場景使用。這類工具一旦被遠程濫用影響范圍遠超數(shù)據(jù)泄露可能是對本地系統(tǒng)的直接控制。Forth MCP 這類工具如果實現(xiàn)得好應該把一部分安全能力做成內置功能上層認證、可暴露的 Server 清單管理、調用日志等。這其實是它相對通用內網(wǎng)穿透工具更有價值的地方通用隧道只解決網(wǎng)絡能通而 MCP 專用通道還要解決調用是否安全可控。9. 常見