作者 | maxlong

MCP協議通過標準化接口實現AI模型與外部工具的無縫連接，而Serverless架構提供彈性計算資源，兩者結合可解決AI代理的動態資源需求。例如，企業內大量AI智能體（如千人規模）的實時調度，可通過Serverless函數動態部署MCP服務器，按需擴展計算能力。這種模式尤其適用于低頻但需快速響應的場景（如臨時視頻處理、數據查詢），避免傳統軟件采購的高昂成本。同時在 Serverless 環境中，每個函數執行都有獨立的執行環境，這種隔離性確保了不同 AI 代理之間的安全性。通過精細的權限控制和資源訪問管理，可以有效防止數據泄露和未經授權的訪問，增強系統的安全性。

一、MCP

1. 簡介

模型上下文協議（Model Context Protocol，簡稱 MCP）是由 Anthropic 推動的一項開放標準，它標準化了應用程序向 LLM 提供上下文的方式。可以將 MCP 視為 AI 應用程序的 USB-C 端口。正如 USB-C 提供了一種將設備連接到各種外圍設備和配件的標準化方式一樣，MCP 提供了一種將 AI 模型連接到不同數據源和工具的標準化方式。

近期，OpenAI 對其 Agent SDK 進行了重大更新，正式支持 MCP 協議。這一舉措使開發者能夠在統一的接口標準下，快速集成多種工具，極大地擴展了 AI 模型的能力。這一變化標志著 MCP 協議在業界的廣泛認可和應用，進一步推動了人工智能技術的發展。

2. 為什么用MCP

MCP可以幫助我們在LLM之上構建Agent或者復雜的工作流，對于一些經常需要與數據和工具集成的場景，MCP協議提供以下功能：

• 基于協議實現的集成數據集或工具可以以插件方式快速連接到LLM。
• 解耦工具和LLM，使得應用可以在多個LLM提供商切換。
• 數據和工具不需要上傳遠端，保護數據隱私。

3. 總體架構

MCP 的核心是客戶端-服務器架構，其中主機應用程序可以連接到多個服務器：

• MCP 主機：希望通過 MCP 訪問數據的程序，例如 Claude Desktop、IDE 或 AI 工具
• MCP 客戶端：與服務器保持 1:1 連接的協議客戶端
• MCP 服務器：輕量級程序，每個程序都通過標準化模型上下文協議公開特定功能
• 本地數據源：MCP 服務器可以安全訪問的您的計算機文件、數據庫和服務
• 遠程服務：MCP 服務器可通過互聯網（例如通過 API）連接到的外部系統

二、MCP Server On Serverless

1. 效果展示

先看看效果，模仿mcp 官方server例子開發一個天氣查詢的mcp server，同時部署到騰訊云云函數。

2. 天氣查詢MCP Server代碼

from mcp.server.fastmcp import FastMCP
import os
import logging
import httpx
import json


# Initialize FastMCP server
mcp = FastMCP("weather", host="0.0.0.0", port=9000)

# Constants
# 天氣API地址 設置對應天氣api接口地址 如騰訊天氣api接口地址https://apis.map.qq.com/ws/weather/v1/
NWS_API_BASE = "api url"
USER_AGENT = "weather-app/1.0"
API_KEY = "api key"

#以下為騰訊天氣api接口偽代碼，需要自行完善
@mcp.tool()
def get_weather(city: str) -> str:
    """
    獲取某個城市的天氣

    Args:
    city: 城市
    """
    
    try:
        # 使用 HTTPS 協議并驗證 SSL
        client = httpx.Client(verify=True)
        
        # 構建請求參數
        params = {
            "key": API_KEY,
            "city": city,
            "output": "json"
        }
        
        # 使用新的天氣API地址
        response = client.get(
            "https://apis.map.qq.com/ws/weather/v1/",
            params=params,
            timeout=10
        )
        
        # 打印響應狀態和內容以便調試
        logging.info(f"Status Code: {response.status_code}")
        logging.info(f"Response: {response.text}")
        
        weather_data = response.json()
        
        if weather_data.get("status") != 0:
            return f"獲取天氣信息失敗: {weather_data.get('message', '未知錯誤')}"
            
        # 獲取實時天氣數據
        data = weather_data.get("result", {})
        observe = data.get("realtime", {})
        infos = data.get("infos", {})
        
        if not observe:
            return "無法獲取天氣信息: 數據為空"
            
        # 返回格式化的天氣信息
        weather_info = f"""
            天氣: {infos.get('weather', '')}
            溫度: {infos.get('temperature', '')}°C
            濕度: {infos.get('humidity', '')}%
            風力: {infos.get('wind_power', '')}級
        """
        return weather_info
        
    except httpx.HTTPError as e:
        error_msg = f"HTTP請求失敗: {str(e)}"
        logging.error(error_msg)
        return error_msg
    except Exception as e:
        error_msg = f"獲取天氣信息失敗: {str(e)}"
        logging.error(error_msg)
        return error_msg
    finally:
        if 'client' in locals():
            client.close()

if __name__ == '__main__':
    logging.basicConfig(level=logging.INFO)
    mcp.run(transport='sse')

特別注意的地方是函數鏡像或者web代碼都需要設置9000的監聽端口，所以代碼要設置server 端口為9000

mcp = FastMCP("weather", host="0.0.0.0", port=9000)

3. 相關依賴

requirements.txt：

httpx
mcp

4. 部署到云函數

Remote MCP Server VS Local MCP Server

(1) 通過鏡像部署云函數

Dockerfile內容：

# 使用官方的 Python 3.13 鏡像作為基礎鏡像
FROM python:3.13.2-slim
# 設置工作目錄
WORKDIR /app
# 復制當前目錄下的所有文件到工作目錄
COPY . /app
# 安裝依賴
RUN pip install --no-cache-dir .
# 暴露端口
EXPOSE 9000
# 運行應用
CMD ["python", "weather.py"]

構建好Docker鏡像，將Docker進行push到tcr鏡像倉庫。

tcr鏡像倉庫詳見： https://cloud.tencent.com/document/product/1141

web鏡像函數： https://cloud.tencent.com/document/product/583/56051

上傳好鏡像之后，可以開始創建云函數，選擇使用容器鏡像，函數類型選擇Web函數：

選擇函數鏡像：

在高級配置中需要設置超時時間為較長時間，比如120s，因為sse服務需要進行長連接，如果時間太短，連接會被快速斷開。

同時需要設置函數支持請求多并發。

【保存】之后就完成了mcp server函數的創建。

最后一步創建函數的URL，使用該URL提供給mcp client進行sse方式的訪問：

同時使用鏡像加速，云函數拉取鏡像會比較快：

最后在cursor mcp中設置好函數的url即可進行mcp tools的使用了。

(2)  通過代碼函數部署

區別于鏡像方式部署，通過代碼部署的云函數拉取代碼的耗時會比鏡像耗時小。

創建函數的方式以下圖例子方式創建即可，其它步驟同鏡像部署：

app.py代碼使用前面的代碼范例即可。

使用云函數的CLI工具能更快速（秒級）的部署MCP Server服務，相對于tke或者CVM部署速度和管理成本極低。

云函數也支持java，go，nodejs，php的代碼。

5. 使用云函數的收益

(1) 云函數相比K8S優勢

騰訊云云函數（SCF, Serverless Cloud Function）和 Kubernetes（K8s）相比，也有一些明顯的優勢，尤其是在特定的應用場景下。以下是騰訊云云函數相對于 Kubernetes 的一些優勢：

① 無服務器架構 (Serverless)

• 無需管理基礎設施：騰訊云云函數是完全托管的計算服務，用戶不需要關注底層服務器、虛擬機、容器集群等基礎設施的管理。與此相比，Kubernetes 需要管理集群中的節點、容器生命周期以及各種資源調度。
• 自動擴展和縮減：云函數會根據實際的事件或請求數量自動擴展和縮減，用戶無需手動配置和調整。Kubernetes 的擴展則需要配置 Horizontal Pod Autoscaling（HPA）或 Vertical Pod Autoscaling（VPA），并且通常還需要設置資源池和負載均衡策略。

② 按需計費

• 按請求和執行時間計費：騰訊云云函數是按請求數和執行時間計費的，用戶只需為實際使用的計算資源付費。相比之下，Kubernetes 中通常需要為整個集群中的節點付費，即使節點沒有承載任何負載也需要支付固定費用，可能導致資源的浪費。
• 零資源消耗：當沒有請求時，云函數不會消耗任何計算資源，而 Kubernetes 需要至少保持最小的節點運行狀態，即使沒有容器或任務需要處理。

③ 簡化的運維和管理

• 自動化運維：騰訊云云函數完全托管，自動管理所有的計算資源和基礎設施，包括計算、存儲和網絡資源，減少了運維負擔。相比之下，Kubernetes 需要用戶自己管理集群、節點、負載均衡、網絡配置等，增加了運維復雜度。
• 無需管理容器或集群：云函數抽象了底層容器或虛擬機的管理，用戶只需關注業務邏輯，而 Kubernetes 則需要開發者管理容器化應用的構建、鏡像推送、容器調度、服務暴露等。

④ 快速部署和啟動

• 快速響應時間：騰訊云云函數是事件驅動的，可以在幾毫秒內響應并啟動，特別適合短時間、瞬時計算的任務。Kubernetes 的容器雖然也支持快速啟動，但仍然需要更多的時間來調度和運行，尤其是涉及到節點的資源分配和容器的啟動。
• 簡化的部署流程：云函數支持從代碼直接部署，不需要預先構建和管理鏡像，而 Kubernetes 通常要求將應用打包為容器鏡像，推送到容器注冊表并進行部署。

⑤ 事件驅動

• 無縫與事件源集成：騰訊云云函數能夠直接與騰訊云其他服務（如對象存儲 COS、消息隊列 CKafka、數據庫等）進行事件驅動的集成，支持自動觸發，簡化了應用架構的設計。Kubernetes 雖然也能與事件源進行集成，但通常需要額外的配置和工具（如通過消息隊列或觸發器調度 Pod）。
• 自動觸發：騰訊云云函數可以輕松響應云端各種事件，如文件上傳、數據庫變更、HTTP 請求等，而 Kubernetes 通常需要設置外部系統來觸發容器啟動或服務處理。

⑥ 自動彈性伸縮

• 無限擴展：騰訊云云函數能夠根據請求自動擴展，支持從零到上千個實例的快速擴展，用戶無需擔心如何管理資源的擴展和縮減。Kubernetes 需要手動配置集群的資源池，并根據需要調整節點或Pod數量。
• 零延遲擴展：云函數可以非常迅速地應對突發流量，Kubernetes 可能需要一定的時間來擴展節點并啟動新容器，特別是在大規模應用中，可能會受到集群資源的限制。

⑦ 低成本和高效能

• 精細的資源使用：由于按執行時間和請求數計費，云函數的資源利用率非常高，能夠確保不浪費資源。在 Kubernetes 中，雖然容器也可以相對輕量化，但資源消耗依賴于集群中配置的節點大小和容器數量。
• 無閑置成本：Kubernetes 集群中即使沒有請求，節點也可能保持活動，用戶仍然需要為空閑的資源支付費用。而云函數在沒有請求時完全不消耗資源，從而降低了成本。

⑧ 開發和調試簡化

• 簡單的開發流程：開發者只需要關注代碼的實現，上傳到騰訊云云函數即可，開發和部署非常快速。而 Kubernetes 通常要求開發者將應用容器化，構建鏡像、推送到容器注冊表，并配置復雜的部署管道。
• 內置集成調試工具：騰訊云云函數提供了調試和日志功能，能夠方便地查看函數執行過程中的詳細日志，幫助開發者快速定位問題。而 Kubernetes 的調試通常涉及到容器日志、Pod 狀態和容器的網絡配置，調試可能更為復雜。

⑨ 簡化的 CI/CD 流程

• 無縫與 CI/CD 集成：騰訊云云函數可以直接與 CI/CD 工具集成（例如騰訊云開發工具、GitHub 等），實現自動化的代碼部署。Kubernetes 則需要手動配置持續集成和持續交付流程，并且通常需要更多的工具和管理。
• 快速更新：云函數支持快速更新和版本管理，開發者可以輕松更新代碼并部署。Kubernetes 則需要通過滾動更新或藍綠部署等方式來更新容器中的應用，管理相對更復雜。

總結：

騰訊云云函數 的優勢在于完全托管的無服務器架構、按需計費、快速啟動和事件驅動架構，使得它非常適合用于輕量級、事件驅動的應用場景，尤其是那些短時間、瞬時任務和彈性伸縮需求較高的場景。與此相比，Kubernetes 更適合需要大規模、高度可配置、容器化管理的長時間運行的應用，尤其是在復雜的微服務架構中，Kubernetes 提供了更高的控制權和靈活性，但也增加了更多的管理復雜度。

如果你需要快速部署、低成本、簡單運維的應用，云函數可能是更好的選擇；如果你需要更復雜的應用架構、容器編排和集群管理，Kubernetes 則可能更適合。

(2) 基于Cube底座的云函數

云函數是基于Cube安全容器來打造的Serverless服務，Cube 提供了高并發，高密度部署的運行環境，使Serverless場景下的安全容器的交付更加迅速，并在有限空間內提供高性能、低開銷的解決方案。

并且通過CubeGW打通云函數和用戶VPC網絡，用戶可以使用MCP來操作VPC內資源，比如數據庫的操作，內部系統的訪問等等。

使用基于Cube底座的云函數，具備強隔離的安全性，靈活的規格可以支撐0.1C64M的MCP Server實例，啟動速度在100ms以內（不包括mcp server啟動時間）。

(3) Cube安全容器優勢

Cube 安全容器在 AI 代理（AI Agent）和 MCP（模型上下文協議）方面，相較于傳統的 Kubernetes (K8s) 和虛擬機 (VM)，具有以下優勢：

① 更高的安全性和隔離性

• Cube使用安全容器技術，提供比傳統容器更強的隔離性。每個容器都運行在獨立的安全環境中，能夠有效防止容器之間的攻擊或數據泄漏，特別是在多租戶環境中。對于 AI 代理和 MCP 服務器，這種強隔離能夠確保不同代理或工具之間的操作不會互相影響，減少了潛在的安全風險。
• 相比之下，Kubernetes 和傳統的虛擬機通常需要額外的配置來實現類似的隔離效果。Kubernetes 在多租戶場景下的容器隔離依賴于操作系統的安全性，而虛擬機雖然提供更強的隔離，但由于資源消耗較大，可能無法高效處理大量小規模的容器化任務。

② 更輕量的資源消耗

• Cube安全容器比傳統虛擬機輕量，具有虛擬機的隔離性，但啟動時間和資源消耗接近容器。這使得它特別適合用于那些需要高度并發和快速響應的 AI 代理和 MCP 服務器場景，例如短期的推理請求、實時數據處理等。相對于虛擬機，Cube 容器能更高效地利用計算資源，減少開銷。
• 在 Kubernetes 和 虛擬機 中，虛擬機的資源消耗較高，啟動時間較長，尤其是在多實例部署的場景下，K8s 集群的擴展可能會受到資源瓶頸的限制。而 Cube 的輕量級特性使得在這些場景中更具優勢，尤其是對于需要彈性擴展的應用。

③ 快速啟動和高效擴展

• Cube 安全容器 提供接近容器的啟動速度，但又具有虛擬機級別的隔離性，非常適合動態擴展的需求，例如 AI 代理需要快速啟動多個實例來處理突發流量或大規模請求。在 Serverless 架構中，這種快速擴展的能力尤為重要，可以減少冷啟動延遲，提高響應速度。
• 與傳統的 Kubernetes 或 虛擬機 相比，Cube 容器的啟動時間遠遠快于虛擬機，能夠在高負載和高并發場景中提供更好的性能表現。

④ 容器與虛擬化的完美平衡

• Cube 安全容器 提供了容器的輕量級特性和虛擬機的隔離性，彌補了傳統容器的不足。AI 代理和 MCP 服務器通常需要頻繁與外部工具和數據源交互，容器化方式能夠提高服務部署和管理的效率，Cube 的虛擬化特性進一步確保了在復雜場景下的高安全性和穩定性。
• 虛擬機 雖然提供更強的隔離，但其資源開銷較大，啟動速度較慢，通常不適合用來處理高頻、短時任務。而 Kubernetes 本身并不提供虛擬化隔離，它依賴于容器和節點來提供服務，這會在某些高安全要求的場景中帶來風險，尤其是當多個用戶或服務共享同一 Kubernetes 集群時。

⑤ 與 AI 和 MCP 的集成優勢

• AI 代理和 MCP 服務器 需要快速處理大量數據并進行實時推理，尤其是在 AI 推理請求和數據交互密集的場景中。Cube 安全容器 能夠為這些任務提供快速響應和動態擴展，同時保留虛擬機級別的安全隔離特性，從而提供更好的服務質量。
• Kubernetes 在大規模分布式部署和容器管理方面的優勢毋庸置疑，但對于需要更高隔離性和快速響應的場景，Cube 安全容器 提供了更好的選擇。特別是在處理敏感數據或需要高安全性和資源隔離的任務時，Cube 提供了容器和虛擬機的最佳平衡。

⑥更好的資源調度與成本優化

• Cube 安全容器 能夠高效地調度資源并優化成本，它在提供虛擬機隔離的同時，減少了虛擬機帶來的資源消耗和成本。對于需要頻繁擴展和收縮的 AI 代理和 MCP 服務器場景，Cube 容器提供了較傳統虛擬機或 Kubernetes 更加高效的解決方案，減少了因過度預分配資源而產生的浪費。
• 傳統的 Kubernetes 需要配置和管理節點，并且節點上常常有較多的資源冗余，造成資源浪費。而 Cube 容器 能夠在提供虛擬機級別的隔離的同時，減少這些冗余。

⑦ 容器化與虛擬化的一體化管理

Cube 安全容器 提供了統一的容器化與虛擬化管理體驗，簡化了基礎設施的管理和運維。相比于 Kubernetes 需要通過多個組件來管理容器和虛擬機，Cube 可以提供一體化的解決方案，降低管理復雜度，尤其適合多租戶的 AI 和 MCP 部署。

總結：Cube 安全容器 在 AI 代理與 MCP 部署中的優勢

Cube 安全容器 是一種高效、輕量、安全的容器化技術，特別適合 AI 代理和 MCP 服務器的動態擴展與快速響應需求。它在提供容器的靈活性和虛擬機的隔離性方面找到了完美的平衡，能夠在多租戶、高安全性需求的場景中提供顯著優勢。相比于傳統的 Kubernetes 和 虛擬機，Cube 更適合處理那些需要快速擴展、低延遲、強隔離的任務，特別是在 Serverless 架構下，能夠為 AI 和 MCP 提供更高效、可靠和安全的運行環境。

6. AI On Serverless

將模型上下文協議（MCP） 與 AI 代理（AI Agent） 部署在無服務器（Serverless）架構上，展現出顯著的優勢：

(1) 模型上下文協議（MCP）與無服務器架構的結合

MCP 旨在為大型語言模型（LLM）提供標準化的接口，使其能夠連接和交互外部數據源和工具。在無服務器架構中，MCP 服務器可以作為輕量級的執行單元，動態處理 AI 代理的請求。這種結合帶來了以下好處：

• 彈性擴展：無服務器平臺根據需求自動分配資源，確保 MCP 服務器在高負載時能夠擴展，滿足大量并發請求的處理需求。
• 按需計費：用戶僅為實際使用的計算資源付費，避免了資源閑置帶來的成本浪費。
• 簡化運維：無服務器架構由云服務商管理基礎設施，開發者專注于業務邏輯的實現，減少了運維復雜度。

(2) AI 代理與無服務器架構的結合

AI 代理是能夠自主執行任務的智能實體，需要頻繁訪問外部工具和數據源。無服務器架構為 AI 代理提供了以下優勢：

• 高可用性：無服務器平臺通常具備高可用性和容錯性，確保 AI 代理在各種條件下穩定運行。
• 快速響應：無服務器函數的快速啟動時間有助于 AI 代理及時響應外部事件和請求。
• 靈活性：無服務器架構支持事件驅動的執行模型，AI 代理可以根據不同事件觸發相應的功能，提高系統的靈活性。

(3) MCP 和 AI 代理在無服務器架構中的協同作用

將 MCP 與 AI 代理部署在無服務器架構中，二者相互補充，優勢互補：

• 標準化通信：MCP 提供統一的通信協議，使 AI 代理能夠高效地與各種數據源和工具交互。
• 動態資源分配：無服務器平臺根據實際需求動態分配資源，確保 MCP 服務器和 AI 代理在高負載時獲得足夠的計算能力。
• 簡化開發流程：開發者可以專注于業務邏輯的實現，無需關心基礎設施的管理，提高了開發效率。

(4) 適用場景

將 MCP 和 AI 代理部署在無服務器架構上，適用于以下場景：

• 動態生成 AI 代理：隨著業務需求變化，動態生成和部署大量 AI 代理，利用無服務器架構的彈性滿足計算資源的波動需求。
• 工具和數據源集成：需要將 AI 代理與多種工具和數據源集成的場景，MCP 提供了標準化的集成方式，簡化了開發和維護工作。

(5) 結論

綜合來看，將 MCP 和 AI 代理部署在無服務器架構上，是一種非常契合的組合，能夠充分發揮各自的優勢。這種架構在需要高彈性、動態擴展和簡化運維的場景中，表現尤為出色。然而，具體的應用效果還需根據實際業務需求和技術環境進行評估和實施。

7. 應用場景

• 訪問數據庫的MCP Server訪問內部數據庫進行數據分析
• 通過云API的MCP Server管理資源
• 通過CLS的MCP Server來進行日志的分析
• 通過云監控的MCP Server分析系統運行狀態
• 通過云函數的MCP Server來調度云函數的Job以及各種ai agent服務
• 基于云函數執行Puppeteer實現爬蟲或者頁面操作任務