编程 MCP 协议升级测试[片段1]

2026-07-26 07:52:03 +0800 CST views 11

MCP 2026-07-28 规范深度解剖：从「工具调用协议」到「生产级 Agent 基础设施」的最大升级

前言

2026年5月，Model Context Protocol（MCP）官方发布了 2026-07-28 规范候选版。官方罕见地将其定性为"协议问世以来规模最大的一次系统性修订"。最终规范计划于2026年7月28日正式发布。

这不是一次功能堆叠，而是一次范式转移。MCP 正从"让 AI 会调工具"的连接协议，走向可规模化部署、全链路可治理、调用全流程可追溯的生产级智能体基础设施。

对于正在构建 AI Agent、或者准备将 MCP 引入生产环境的开发者来说，这次升级直接影响了你未来一到两年的架构选型。本文将深入拆解这次升级的技术细节、生产含义，以及作为开发者你应该如何应对。

一、背景：MCP 解决了什么问题，又产生了什么问题

1.1 为什么需要 MCP

在 MCP 出现之前，AI 应用接入外部工具有多痛苦？用一个具体场景来描述：

假设你正在开发一个企业知识库问答系统。用户问："帮我查一下这批供应商的最新资质情况。"AI 需要：

查询内部 ERP 的供应商主数据
调用工商信息 API 核验资质
读取合同管理系统中的履约记录
访问风险数据库获取诉讼和处罚信息

在 MCP 出现之前，你大概需要这样写：

# 传统方案：每个工具写一套集成代码
if "供应商" in query and "资质" in query:
    # 方案A: 用 OpenAI Function Calling
    response = openai.ChatCompletion.create(
        functions=[{
            "name": "query_erp",
            "parameters": {...}
        }, {
            "name": "query_business_info",
            "parameters": {...}
        }, ...]
    )
    
    # 方案B: 用 Anthropic Tool Use
    response = anthropic.messages.create(
        tools=[{
            "name": "query_erp",
            "input_schema": {...}
        }, ...]
    )
    
    # 方案C: 用 Google Function Declaration
    response = gemini.generate_content(
        tools=[...]
    )

每换一个大模型提供商，你就得重写一遍 glue code。更痛苦的是，如果你的系统需要同时调用 5 个不同来源的工具，这 5 套接口定义可能散落在代码库的各个角落，维护成本极高。

MCP 的核心价值：统一工具描述格式，让 AI 应用和工具提供者解耦。 你只需要写一个 MCP Server 实现业务逻辑，然后任何支持 MCP 的客户端（Claude Desktop、Cursor、你的自定义 Agent）都能发现并调用它。

1.2 MCP v1.x 时代的三个核心局限

MCP 在 2024 年 11 月推出后迅速获得了广泛采纳，但也暴露出了三个显著的工程局限：

局限一：会话强绑定

v1.x 版本的远程 MCP Server 要求客户端先建立协议会话（initialize → initialized 握手），后续所有请求都依赖同一份 Session。这意味着：

# v1.x 时代的远程 MCP 调用流程
# Step 1: 先建立会话
session = await mcp_client.connect("https://api.example.com/mcp")
session_id = session.id  # 这个会话被绑定到某台服务器实例

# Step 2: 后续请求必须经过同一会话
result = await session.call_tool("query_erp", {...})  # 只能发到会话所在的服务器

对于企业级部署，这意味着：

负载均衡？不存在的——请求必须路由到持有 Session 的那个实例
滚动发布？不可能——杀掉旧实例会中断所有活跃会话
水平扩容？很难——你需要一个黏性会话的负载均衡器

局限二：能力裸列，没有治理

v1.x 只提供了 tools/list 接口，工具只是一个名称和参数 Schema 的列表。当你的 MCP Server 有 20 个工具时，AI 客户端拿到的是一张 20 项的清单。当你有 200 个工具时，这张清单就变成了噪声。更糟糕的是，没有任何机制让 AI 理解"哪个工具查当前数据，哪个查历史数据"、"哪些场景应该先做扫描再下钻"。

局限三：结果只有自然语言，没有证据链

当 AI 调用了多个工具、聚合了多个数据源之后，返回给用户的只是一段自然语言文本。用户没有办法验证"这个结论是怎么得出的"、"用了哪些数据"、"数据的时间点是什么"。在企业场景中，这带来了严重的合规和审计问题。

这三个局限，正是 2026-07-28 规范要解决的核心问题。

二、无状态核心：从"会话绑定"到"请求自包含"

2.1 什么是无状态核心

2026-07-28 规范的最大变化，是取消协议层的 Session 机制。

旧版（v1.x）的握手流程：

Client → Server: initialize (协议版本、能力声明)
Server → Client: initialized (协议版本、服务端能力)
[协议会话建立，后续所有请求携带 Mcp-Session-Id]

新版（v0.28+）的请求流程：

Client → Server: 一个 POST 请求，包含所有必要信息
Server → Client: 响应，同一个请求可以由任意服务实例处理

直观理解：每个请求自己携带完成处理所需的全部上下文，不需要服务器记住任何会话状态。

这在技术上对应两个具体变化：

移除 initialize / initialized 握手：客户端不再需要先建立协议会话再发送工具调用
移除 Mcp-Session-Id 头：请求中不再需要携带会话标识

2.2 为什么这对生产部署至关重要

让我们通过一个具体场景来理解无状态的价值。

场景：企查查 MCP 的生产压力

企查查智能体数据平台（agent.qcc.com）截至 2026 年 7 月已有 9 个 MCP Server、197 个工具。平台面对的调用方包括：

不同 AI 工具（WorkBuddy、QoderWork、QClaw 等）
多个合作平台
不同客户租户
大规模并发调用

在有会话绑定的旧版协议下：

某个 AI 客户端建立了 Session，这个 Session 被路由到了 Server 实例 A
如果 Server A 因为负载高、滚动发布或故障而不可用，这个 Session 就断了
客户端需要重新建立会话，但之前的状态（如果有的话）已经丢失

在无状态的新版协议下：

每个请求都是自包含的，可以被路由到任意一个健康的 Server 实例
负载均衡器可以根据实时的 CPU、内存、响应时间做最优路由
滚动发布时，任意实例可以随时下线，请求自动分发到其他实例

# 无状态 MCP 请求的典型结构
# 每个请求携带完整上下文，无需服务端维护会话状态

request = {
    "jsonrpc": "2.0",
    "id": 42,
    "method": "tools/call",
    "params": {
        "name": "business_search",
        "arguments": {
            "keyword": "企查查科技股份有限公司",
            "data_scope": "current"  # 明确数据范围
        },
        # v0.28+ 新增：请求级别的上下文信息
        "meta": {
            "trace_id": "uuid-for-correlation",
            "tenant_id": "enterprise-customer-123",
            "capabilities_requested": ["real-time-data"]
        }
    }
}

2.3 无状态与 HTTP 网关的整合

无状态设计带来的另一个重要变化：MCP 可以复用成熟的 HTTP 网关生态。

旧版限制：远程 MCP 使用 HTTP + SSE（Server-Sent Events），但 SSE 是长连接，Session 维护在服务端。这让大多数 API 网关（Kong、Nginx、Envoy）无法正确处理——它们习惯处理无状态的请求-响应交互。

新版优势：每个请求是独立的 HTTP POST + JSON 响应，可以被任何标准 HTTP 网关处理。

# 一个典型的 v0.28+ MCP 部署架构
services:
  mcp-gateway:
    # Envoy 或 Kong 网关处理路由、限流、鉴权
    image: envoy-mcp-gateway:latest
    ports:
      - "8080:8080"
    environment:
      UPSTREAM_CLUSTERS: "mcp-server-1,mcp-server-2,mcp-server-3"
      LOAD_BALANCER: "round_robin"
      RATE_LIMIT: "1000/minute"
  
  mcp-server-1:
    image: qcc-mcp-server:latest
    replicas: 3
    resources:
      limits:
        memory: "512Mi"
        cpu: "500m"
  
  mcp-server-2:
    image: legal-mcp-server:latest
    replicas: 2
  
  mcp-server-3:
    image: docparse-mcp-server:latest
    replicas: 2

在这个架构中：

网关负责路由（根据 tool name 或 server 名称分发到对应后端）
网关负责限流（每个租户的调用频率限制）
网关负责鉴权（JWT token 验证）
每个 Server 实例无状态运行，水平扩容完全自由

三、能力发现：从"列清单"到"可治理"

3.1 为什么工具数量是双刃剑

当 MCP Server 只有 10 个工具时，tools/list 返回的清单是有用的。但当你的 Server 有 50 个、100 个、200 个工具时，清单就变成了噪声。

企查查 MCP 提供了 197 个工具，覆盖工商、股权、风险、知识产权、经营、历史、司法、法规等多个领域。对于 AI Agent 来说，直接面对 197 个工具选项，会产生几个具体问题：

问题一：选错工具

AI 看到 "company_search"、"company_basic_query"、"company_info_get" 三个工具，它怎么知道应该用哪个？旧版 MCP 的描述通常是这样的：

{
  "name": "company_search",
  "description": "查询企业信息",
  "inputSchema": {
    "type": "object",
    "properties": {
      "keyword": {"type": "string"}
    }
  }
}

这个描述没有说明：

这个工具查的是当前数据还是历史数据？
搜索结果是模糊匹配还是精确匹配？
返回的数据字段有哪些，和 company_basic_query 有什么区别？
在什么场景下应该用这个工具而不是另一个？

问题二：重复调用

AI 可能对同一个数据维度调用多个相似工具，造成浪费。更严重的是，可能产生矛盾的结果——两个工具查出的同一字段值不一样，AI 不知道该信哪个。

问题三：上下文污染

一次任务调用了几十个工具，每个工具返回的数据都塞进上下文窗口，很快就把宝贵的上下文空间填满了。AI 实际上在做"暴力搜索"而不是"精准下钻"。

3.2 能力发现机制的工程实现

2026-07-28 规范引入的能力发现机制，核心是让工具描述从"清单"升级为"可被系统化理解的语义网络"。

新增的 server/discover 接口

// 新版工具描述（简化示例）
{
  "name": "risk_scan",
  "description": "对企业进行综合风险扫描，返回各风险维度的数量和分布",
  "inputSchema": {...},
  "outputSchema": {
    "$schema": "https://json-schema.org/draft/2020-12/schema",
    "type": "object",
    "properties": {
      "dimension

复制全文生成海报 MCP AI Agent