架構
模型上下文協議 (MCP) 遵循客戶端-主機-服務器架構，其中每個 主機可以運行多個客戶端實例。這種架構使用戶能夠跨應用程序集成 AI 功能，同時保持明確的安全邊界並隔離關注點。MCP 基於 JSON-RPC 構建，提供專注於 客戶端和服務器之間上下文交換和採樣協調的有狀態會話協議。
核心組件
graph LR
subgraph "應用程序主機進程"
H[主機]
C1[客戶端 1]
C2[客戶端 2]
C3[客戶端 3]
H --> C1
H --> C2
H --> C3
end
subgraph "本地機器"
S1[服務器 1<br>文件和Git]
S2[服務器 2<br>數據庫]
R1[("本地<br>資源 A")]
R2[("本地<br>資源 B")]
C1 --> S1
C2 --> S2
S1 <--> R1
S2 <--> R2
end
subgraph "互聯網"
S3[服務器 3<br>外部 API]
R3[("遠程<br>資源 C")]
C3 --> S3
S3 <--> R3
end
主機
主機進程充當容器和協調器：
- 創建和管理多個客戶端實例
- 控制客戶端連接權限和生命週期
- 執行安全策略和同意要求
- 處理用戶授權決策
- 協調 AI/LLM 集成和採樣
- 管理跨客戶端的上下文聚合
客戶端
每個客戶端由主機創建並維護隔離的服務器連接：
- 為每個服務器建立一個有狀態會話
- 處理協議協商和能力交換
- 雙向路由協議消息
- 管理訂閱和通知
- 維護服務器之間的安全邊界
主機應用程序創建和管理多個客戶端，每個客戶端與特定服務器具有 1:1 關係。
服務器
服務器提供專業的上下文和能力：
- 通過 MCP 原語公開資源、工具和提示
- 獨立運行，職責集中
- 通過客戶端接口請求採樣
- 必須尊重安全約束
- 可以是本地進程或遠程服務
設計原則
MCP 基於幾個關鍵設計原則，這些原則指導其架構和實現：
服務器應該非常容易構建
- 主機應用程序處理複雜的編排責任
- 服務器專注於具體、明確定義的功能
- 簡單接口最小化實現開銷
- 明確分離使代碼可維護
服務器應該高度可組合
- 每個服務器獨立提供集中功能
- 多個服務器可以無縫組合
- 共享協議實現互操作性
- 模塊化設計支持可擴展性
服務器不應能夠讀取整個對話，也不應"看到"其他服務器
- 服務器只接收必要的上下文信息
- 完整對話歷史保留在主機
- 每個服務器連接保持隔離
- 跨服務器交互由主機控制
- 主機進程執行安全邊界
功能可以逐步添加到服務器和客戶端
- 核心協議提供最小所需功能
- 可以根據需要協商額外能力
- 服務器和客戶端獨立發展
- 協議設計為未來可擴展
- 保持向後兼容性
消息類型
MCP 定義了基於 JSON-RPC 2.0 的三種核心消息類型：
- 請求：雙向消息，帶有方法和參數，期望響應
- 響應：成功結果或與特定請求 ID 匹配的錯誤
- 通知：不需要響應的單向消息
每種消息類型遵循 JSON-RPC 2.0 規範的結構和傳遞語義。
能力協商
模型上下文協議使用基於能力的協商系統，客戶端和服務器在初始化期間明確聲明其支持的功能。能力決定了會話期間可用的協議功能和原語。
- 服務器聲明資源訂閱、工具支持和提示模板等能力
- 客戶端聲明採樣支持和通知處理等能力
- 雙方必須在整個會話中尊重已聲明的能力
- 可以通過協議擴展協商額外能力
sequenceDiagram
participant Host
participant Client
participant Server
Host->>+Client: 初始化客戶端
Client->>+Server: 使用能力初始化會話
Server-->>Client: 響應支持的能力
Note over Host,Server: 具有協商功能的活動會話
loop 客戶端請求
Host->>Client: 用戶或模型發起的操作
Client->>Server: 請求(工具/資源)
Server-->>Client: 響應
Client-->>Host: 更新UI或響應模型
end
loop 服務器請求
Server->>Client: 請求(採樣)
Client->>Host: 轉發到AI
Host-->>Client: AI響應
Client-->>Server: 響應
end
loop 通知
Server--)Client: 資源更新
Client--)Server: 狀態變化
end
Host->>Client: 終止
Client->>-Server: 結束會話
deactivate Server
每種能力都會在會話期間解鎖特定的協議功能。例如：
這種能力協商確保客戶端和服務器對支持的功能有清晰的理解，同時保持協議可擴展性。