MCP 协议流与会话治理机制¶

模型上下文协议（MCP, Model Context Protocol）是连接大模型大脑与本地/外部系统的标准化桥梁。在工业级智能体落地中，理解 MCP 不能停留在“工具调用”层面，而必须将其视为三层网络拓扑下的标准 RPC 治理框架：宿主应用（Host Runtime）、MCP 客户端（MCP Client）与 MCP 服务端（MCP Server）。

1. 三层拓扑架构与边界划分¶

模型本身不具备直接连接操作系统的物理能力，它仅扮演意图生成器。一切副作用的执行与数据流转均受控于 Host 运行时的隔离层：

+------------------------------------------------------------------------+
| 宿主应用运行时 (Host Runtime - 审计安全、会话隔离、人工确认拦截器)      |
|                                                                        |
|   +------------------------------------+                               |
|   | 智能体决策层 (Agent Loop / LLM)     |                               |
|   +-----------------+------------------+                               |
|                     | 生成工具调用意图                                  |
|                     v                                                  |
|   +-----------------+------------------+                               |
|   | MCP 客户端 (MCP Client)            |                               |
|   +-----------------+------------------+                               |
|                     | 建立 transport (JSON-RPC 2.0 over stdio/SSE)     |
|                     v                                                  |
+---------------------+--------------------------------------------------+
                      |
                      | 跨物理/进程边界
                      v
+---------------------+--------------------------------------------------+
| MCP 服务端运行时 (MCP Server - 沙箱进程 / 网络隔离 / 本地工具集)           |
|                                                                        |
|   +-----------------+------------------+                               |
|   | 工具执行器 (Tools / Resources)       |                               |
|   +------------------------------------+                               |
+------------------------------------------------------------------------+

Host Runtime（治理面）：负责身份认证、多租户上下文隔离、工具动态裁剪、参数风控拦截与 Human-in-the-Loop（人工确认）拦截。
MCP Client（协议适配层）：负责底层 Transport（进程 stdio 管道或 HTTP SSE）生命周期管理、协议序列化/反序列化、能力发现交互及错误标准化。
MCP Server（执行面）：暴露具体的 Tools、Resources 或 Prompts 规范，提供纯粹的无状态执行原子。

2. 标准会话生命周期与 JSON-RPC 2.0 Payload¶

MCP 协议完全基于 JSON-RPC 2.0 规范建立。客户端与服务端的初始化、能力协商及调用序列如下：

2.1 初始化握手时序 (Handshake Sequence)¶

sequenceDiagram participant Client as MCP Client participant Server as MCP Server Note over Client, Server: 1. Transport Establishment (e.g. exec server process) Client->>Server: initialize Request (JSON-RPC) Note over Server: Capability Matching & Sandboxing Server-->>Client: initialize Response (JSON-RPC) Client->>Server: notifications/initialized Notification Note over Client, Server: Handshake complete, entering normal lifecycle

2.2 核心协议 Payload 详解¶

① 初始化请求 (`initialize` Request)¶

客户端向服务端宣告其所支持的协议版本与自身能力声明：

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "initialize",
  "params": {
    "protocolVersion": "2024-11-05",
    "capabilities": {
      "roots": { "listChanged": true },
      "sampling": {}
    },
    "clientInfo": {
      "name": "AntigravityHost",
      "version": "1.2.0"
    }
  }
}

② 初始化响应 (`initialize` Response)¶

服务端返回其协议兼容版本，并输出其能够提供的核心能力列表（如是否具备 Prompts 模板、Resources 静态数据源或 Tools 执行器）：

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "protocolVersion": "2024-11-05",
    "capabilities": {
      "tools": { "listChanged": true },
      "resources": { "subscribe": true }
    },
    "serverInfo": {
      "name": "LocalFilesystemServer",
      "version": "0.9.4"
    }
  }
}

③ 工具执行请求 (`tools/call` Request)¶

当智能体决策需要执行动作时，Client 向 Server 发起具体调用：

{
  "jsonrpc": "2.0",
  "id": 42,
  "method": "tools/call",
  "params": {
    "name": "read_secure_file",
    "arguments": {
      "path": "/workspace/config.json"
    }
  }
}

④ 工具执行响应 (`tools/call` Response)¶

Server 返回执行结果封装，需指出返回内容类型及是否存在逻辑错误（isError）：

{
  "jsonrpc": "2.0",
  "id": 42,
  "result": {
    "content": [
      {
        "type": "text",
        "text": "{\"port\": 8080, \"db\": \"postgresql\"}"
      }
    ],
    "isError": false
  }
}

3. 防御性安全治理面设计¶

MCP 工具调用本质上是在执行外部或本地代码。设计安全的智能体运行时，必须对安全防护进行阶梯式防御：

能力发现（Discovery）与可见性控制：
- 即使 Server 暴露了 10 个工具，Host 也应根据当前会话的权限上下文（如：只读用户 vs 读写管理员）动态生成工具白名单，过滤后才送入大模型的 System Prompt。
静态 Schema 防御拦截：
- 在 Client 侧强校验模型输出的 arguments 是否完全符合 JSON Schema。对于恶意长参数、不合法字符及 Shell 元字符（如 ;, &&, |）直接由 Host 拦截拒执。
动态审批屏障 (Human-in-the-Loop)：
- 根据工具的风险等级（无害只读 vs 破坏性写入）标记级别。涉及文件修改、Shell 执行、外部网络请求的操作，必须通过 Host 拦截器向用户发起显式 UI 确认。

4. 故障演进与排查诊断树¶

故障阶段	现象与错误描述	根因定位	排查与修复手段
Transport 阶段	`broken pipe` 或 `EOF`	Server 进程崩溃，或标准输出被第三方日志打印污染破坏了 JSON 帧	1. 拦截 Server 的 `stderr` 写入独立日志文件，严禁污染 `stdout`。 2. 检查 Server 的启动路径与环境变量。
握手协商阶段	`Unsupported protocol version`	客户端与服务端的主版本号不兼容	检查两端依赖的 MCP SDK 版本，强制在配置项中回退或升级。
工具发现阶段	模型找不到指定工具	能力变更通知丢失，或动态白名单裁剪过滤逻辑存在 Bug	调用 `tools/list` 打印原始 JSON 响应，核对白名单过滤器函数（Filter Callback）执行状态。
执行阶段	频繁触发 `isError: true`	目标文件不存在、无访问权限或下游网络超时	1. Host 侧增加超时机制限制（建议单次调用 \(< 10\text{s}\)）。 2. 对返回的堆栈轨迹执行脱敏，防止向模型泄露内部机密目录结构。

5. 资深系统架构师面试表达方案¶

面试提问：大模型是如何安全地和本地系统（比如 MCP Server）进行数据交互的？

回答模版： 在我的架构设计中，大模型永远不直接连接 MCP Server，它只扮演意图输出层，所有的交互控制权全部收拢在宿主应用（Host）的执行管道中。

整个交互流程严格遵循三层隔离策略：第一，协议层隔离：Client 与 Server 之间通过完全标准化的 JSON-RPC 2.0 over stdio/SSE 进行通信。Server 本身是一个无状态的执行沙箱。第二，防御性拦截控制：当模型生成工具调用意图时，Host 运行时会对参数进行严格的 Schema 静态验证，杜绝 Shell 注入。同时，我们会依据“最小特权原则”，根据当前登录用户的权限动态裁剪模型可见的工具集。第三，阻断性审批保障：针对写操作或高危工具，Host 执行层会自动触发 Human-in-the-Loop 阻塞器，挂起当前会话，直到人工确认或安全哨兵系统放行，才允许将参数发往 Server 执行。结果返回后，Client 还会统一将其封装为标准 envelope 回灌模型，防止系统错误堆栈直接破坏模型的推理状态。