作者 | maxlong

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

一、MCP

1. 簡介

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

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

2. 為什么用MCP

MCP可以幫助我們在LLM之上構(gòu)建Agent或者復(fù)雜的工作流，對于一些經(jīng)常需要與數(shù)據(jù)和工具集成的場景，MCP協(xié)議提供以下功能：

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

3. 總體架構(gòu)

MCP 的核心是客戶端-服務(wù)器架構(gòu)，其中主機應(yīng)用程序可以連接到多個服務(wù)器：

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

二、MCP Server On Serverless

1. 效果展示

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

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地址 設(shè)置對應(yīng)天氣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 協(xié)議并驗證 SSL
        client = httpx.Client(verify=True)
        
        # 構(gòu)建請求參數(shù)
        params = {
            "key": API_KEY,
            "city": city,
            "output": "json"
        }
        
        # 使用新的天氣API地址
        response = client.get(
            "https://apis.map.qq.com/ws/weather/v1/",
            params=params,
            timeout=10
        )
        
        # 打印響應(yīng)狀態(tài)和內(nèi)容以便調(diào)試
        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', '未知錯誤')}"
            
        # 獲取實時天氣數(shù)據(jù)
        data = weather_data.get("result", {})
        observe = data.get("realtime", {})
        infos = data.get("infos", {})
        
        if not observe:
            return "無法獲取天氣信息: 數(shù)據(jù)為空"
            
        # 返回格式化的天氣信息
        weather_info = f"""
            天氣: {infos.get('weather', '')}
            溫度: {infos.get('temperature', '')}°C
            濕度: {infos.get('humidity', '')}%
            風(fēng)力: {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')

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

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

3. 相關(guān)依賴

requirements.txt：

httpx
mcp

4. 部署到云函數(shù)

Remote MCP Server VS Local MCP Server

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

Dockerfile內(nèi)容：

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

構(gòu)建好Docker鏡像，將Docker進行push到tcr鏡像倉庫。

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

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

上傳好鏡像之后，可以開始創(chuàng)建云函數(shù)，選擇使用容器鏡像，函數(shù)類型選擇Web函數(shù)：

選擇函數(shù)鏡像：

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

同時需要設(shè)置函數(shù)支持請求多并發(fā)。

【保存】之后就完成了mcp server函數(shù)的創(chuàng)建。

最后一步創(chuàng)建函數(shù)的URL，使用該URL提供給mcp client進行sse方式的訪問：

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

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

(2)  通過代碼函數(shù)部署

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

創(chuàng)建函數(shù)的方式以下圖例子方式創(chuàng)建即可，其它步驟同鏡像部署：

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

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

云函數(shù)也支持java，go，nodejs，php的代碼。

5. 使用云函數(shù)的收益

(1) 云函數(shù)相比K8S優(yōu)勢

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

① 無服務(wù)器架構(gòu) (Serverless)

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

② 按需計費

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

③ 簡化的運維和管理

• 自動化運維：騰訊云云函數(shù)完全托管，自動管理所有的計算資源和基礎(chǔ)設(shè)施，包括計算、存儲和網(wǎng)絡(luò)資源，減少了運維負擔(dān)。相比之下，Kubernetes 需要用戶自己管理集群、節(jié)點、負載均衡、網(wǎng)絡(luò)配置等，增加了運維復(fù)雜度。
• 無需管理容器或集群：云函數(shù)抽象了底層容器或虛擬機的管理，用戶只需關(guān)注業(yè)務(wù)邏輯，而 Kubernetes 則需要開發(fā)者管理容器化應(yīng)用的構(gòu)建、鏡像推送、容器調(diào)度、服務(wù)暴露等。

④ 快速部署和啟動

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

⑤ 事件驅(qū)動

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

⑥ 自動彈性伸縮

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

⑦ 低成本和高效能

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

⑧ 開發(fā)和調(diào)試簡化

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

⑨ 簡化的 CI/CD 流程

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

總結(jié)：

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

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

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

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

并且通過CubeGW打通云函數(shù)和用戶VPC網(wǎng)絡(luò)，用戶可以使用MCP來操作VPC內(nèi)資源，比如數(shù)據(jù)庫的操作，內(nèi)部系統(tǒng)的訪問等等。

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

(3) Cube安全容器優(yōu)勢

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

① 更高的安全性和隔離性

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

② 更輕量的資源消耗

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

③ 快速啟動和高效擴展

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

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

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

⑤ 與 AI 和 MCP 的集成優(yōu)勢

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

⑥更好的資源調(diào)度與成本優(yōu)化

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

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

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

總結(jié)：Cube 安全容器 在 AI 代理與 MCP 部署中的優(yōu)勢

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

6. AI On Serverless

將模型上下文協(xié)議（MCP） 與 AI 代理（AI Agent） 部署在無服務(wù)器（Serverless）架構(gòu)上，展現(xiàn)出顯著的優(yōu)勢：

(1) 模型上下文協(xié)議（MCP）與無服務(wù)器架構(gòu)的結(jié)合

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

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

(2) AI 代理與無服務(wù)器架構(gòu)的結(jié)合

AI 代理是能夠自主執(zhí)行任務(wù)的智能實體，需要頻繁訪問外部工具和數(shù)據(jù)源。無服務(wù)器架構(gòu)為 AI 代理提供了以下優(yōu)勢：

• 高可用性：無服務(wù)器平臺通常具備高可用性和容錯性，確保 AI 代理在各種條件下穩(wěn)定運行。
• 快速響應(yīng)：無服務(wù)器函數(shù)的快速啟動時間有助于 AI 代理及時響應(yīng)外部事件和請求。
• 靈活性：無服務(wù)器架構(gòu)支持事件驅(qū)動的執(zhí)行模型，AI 代理可以根據(jù)不同事件觸發(fā)相應(yīng)的功能，提高系統(tǒng)的靈活性。

(3) MCP 和 AI 代理在無服務(wù)器架構(gòu)中的協(xié)同作用

將 MCP 與 AI 代理部署在無服務(wù)器架構(gòu)中，二者相互補充，優(yōu)勢互補：

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

(4) 適用場景

將 MCP 和 AI 代理部署在無服務(wù)器架構(gòu)上，適用于以下場景：

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

(5) 結(jié)論

綜合來看，將 MCP 和 AI 代理部署在無服務(wù)器架構(gòu)上，是一種非常契合的組合，能夠充分發(fā)揮各自的優(yōu)勢。這種架構(gòu)在需要高彈性、動態(tài)擴展和簡化運維的場景中，表現(xiàn)尤為出色。然而，具體的應(yīng)用效果還需根據(jù)實際業(yè)務(wù)需求和技術(shù)環(huán)境進行評估和實施。

7. 應(yīng)用場景

• 訪問數(shù)據(jù)庫的MCP Server訪問內(nèi)部數(shù)據(jù)庫進行數(shù)據(jù)分析
• 通過云API的MCP Server管理資源
• 通過CLS的MCP Server來進行日志的分析
• 通過云監(jiān)控的MCP Server分析系統(tǒng)運行狀態(tài)
• 通過云函數(shù)的MCP Server來調(diào)度云函數(shù)的Job以及各種ai agent服務(wù)
• 基于云函數(shù)執(zhí)行Puppeteer實現(xiàn)爬蟲或者頁面操作任務(wù)