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 需要：

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

在 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: 响应，同一个请求可以由任意服务实例处理

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

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

1. 移除 initialize / initialized 握手：客户端不再需要先建立协议会话再发送工具调用
2. 移除 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": {
        "type": "string",
        "enum": ["legal", "financial", "operational", "compliance"]
      },
      "count": {"type": "integer"},
      "severity": {"type": "string", "enum": ["low", "medium", "high", "critical"]}
    }
  },
  // v0.28+ 新增：能力语义描述
  "annotations": {
    "dataScope": "current",           // 当前数据 vs 历史数据
    "dataFreshness": "realtime",       // 实时 vs T+N 延迟
    "capabilityType": "scanning",      // 工具能力类型：查询/扫描/分析
    "requiresAnchor": true,            // 是否需要先完成主体锚定
    "prerequisites": [],               // 前置工具依赖
    "mutuallyExclusiveWith": ["risk_query_individual"], // 不应同时调用
    "cacheTtlMs": 300000               // 缓存建议：5分钟
  }
}

能力分类体系的工程实践

企查查 MCP 将工具组织为五层能力体系：

┌─────────────────────────────────────────────────────────┐
│  全局约束层 (Global Constraints)                         │
│  回答：哪些事情不能猜、不能混、不能越过                  │
├─────────────────────────────────────────────────────────┤
│  SKILL 层 (Business Tasks)                             │
│  回答：怎样组合多个工具完成一个业务任务                   │
├─────────────────────────────────────────────────────────┤
│  Resources 层 (Stable Knowledge)                        │
│  回答：调用前需要理解什么                                │
├─────────────────────────────────────────────────────────┤
│  Server 层 (Capability Boundaries)                      │
│  回答：这些能力属于哪个专业范围                           │
├─────────────────────────────────────────────────────────┤
│  Tool 层 (Real-time Data)                               │
│  回答：数据从哪里来                                      │
└─────────────────────────────────────────────────────────┘

这个五层体系映射到 MCP 协议：

• Tool 层 → tools/call 提供原子数据能力
• Server 层 → 多个 Tool 的逻辑分组，AI 理解"这个 Server 解决什么问题域"
• Resources 层 → resources/list 提供稳定知识（术语表、数据字典、报告模板）
• SKILL 层 → MCP Apps（新版引入），封装可复用的业务流程
• 全局约束层 → annotations 和 constraints 字段，规定使用边界

3.3 工具治理的生产落地

工具数量多了之后，治理变得和工具本身一样重要。2026-07-28 规范在这一点上引入了几个关键能力：

缓存语义

// 工具级别的缓存声明
{
  "name": "company_basic_info",
  "annotations": {
    "cacheScope": "tenant",       // 租户级缓存（同一租户内复用）
    "ttlMs": 3600000,             // 缓存 1 小时
    "staleWhileRevalidate": true  // 返回旧数据的同时后台刷新
  }
}

对于企业数据查询场景，缓存策略直接影响成本。以企查查为例，每次 API 调用涉及积分消耗。如果 AI Agent 在一次会话中重复查询同一企业信息，有缓存机制可以节省大量调用成本。

限流和审计语义

// 新版网关层面的工具治理
{
  "tools": [...],
  "governance": {
    "rateLimits": {
      "default": "100/minute",
      "risk_scan": "20/minute",  // 高成本工具更严格的限流
      "company_search": "500/minute"  // 查询工具可以更宽松
    },
    "costTracking": {
      "enabled": true,
      "perToolCost": {
        "risk_scan": 10,      // 每个风险扫描消耗 10 积分
        "company_search": 2    // 每个查询消耗 2 积分
      }
    },
    "auditLog": {
      "required": true,
      "fields": ["tool", "arguments", "result_hash", "timestamp", "tenant"]
    }
  }
}

这些治理能力不是给 AI 用的，而是给 MCP 网关和平台运营者用的。网关可以基于这些元信息做限流、计费、审计，而不需要每个 Server 单独实现。

四、任务协作：从"一次调用"到"持续完成"

4.1 为什么单次调用不够用

在 MCP v1.x 的设计哲学中，每个工具调用是一个独立的事务：

用户: "帮我查一下这家公司的情况"
AI: → tools/call: company_search
AI: ← 返回企业基本信息
AI: → tools/call: risk_scan  
AI: ← 返回风险扫描结果
AI: → tools/call: shareholder_query
AI: ← 返回股东信息
AI: [整合所有结果，生成自然语言回复]

这个模式有三个明显的问题：

问题一：无法处理长任务

"帮我生成一份完整的尽调报告" 这样的任务，可能需要：

1. 30 分钟的数据采集
2. 多次用户确认（"这个股权结构你确认吗？"）
3. 分阶段的结果呈现

单次工具调用模式无法支持这种多轮交互、多阶段执行的长任务。

问题二：无法处理补充输入

在任务执行过程中，可能需要用户补充信息："您想查的是注册地在深圳的总部，还是所有分支机构？" 旧版协议没有标准的方式来处理这种暂停和补充输入。

问题三：任务状态无法持久化

如果 AI Agent 崩溃或会话中断，旧版协议下正在执行的任务就丢失了。用户不得不重新描述整个任务。

4.2 MCP Apps 与任务协作的新范式

2026-07-28 规范引入了 Tasks 和 MCP Apps 作为一等公民来解决这些问题。

Tasks：长任务的持久化状态管理

# 任务创建
task = {
    "id": "task-uuid-123",
    "name": "enterprise_due_diligence",
    "status": "in_progress",
    "stages": [
        {
            "id": "stage-1",
            "name": "主体锚定",
            "tools": ["company_search", "credit_code_validate"],
            "status": "completed",
            "output": {
                "confirmed_entity": "企查查科技股份有限公司",
                "credit_code": "91110108MA01XXXXX"
            }
        },
        {
            "id": "stage-2",
            "name": "综合风险扫描",
            "tools": ["risk_scan"],
            "status": "pending",
            "prerequisite": "stage-1"
        },
        {
            "id": "stage-3",
            "name": "报告生成",
            "tools": ["report_compile"],
            "status": "pending",
            "prerequisite": "stage-2"
        }
    ],
    "progress": {
        "completed": 1,
        "total": 3,
        "pct": 33
    }
}

这个任务结构意味着：

• 任务执行可以被暂停和恢复
• 每个阶段的输出被持久化，后续阶段可以直接引用
• 用户可以在任何阶段介入确认或补充信息
• 即使 Agent 重启，也可以通过 task ID 恢复执行

MCP Apps：可复用的业务流程封装

如果说 Tasks 是单个任务的状态管理，那么 MCP Apps 是更高层次的能力封装——将多个工具、多个任务组合为一个可复用的"应用"。

// MCP App 示例：企业尽调应用
{
  "name": "enterprise_kyb_app",
  "version": "1.0.0",
  "description": "企业 KYB（了解你的客户）核验应用",
  "stages": [
    {
      "name": "entity_anchor",
      "description": "确认要核验的企业主体",
      "requiresUserInput": true,
      "validation": {
        "requiredFields": ["company_name", "credit_code"],
        "uncertaintyThreshold": 0.7
      }
    },
    {
      "name": "risk_comprehensive_scan",
      "description": "综合风险扫描",
      "parallelTools": ["risk_scan", "litigation_query", "penalty_query"],
      "aggregation": "union"
    },
    {
      "name": "shareholder_analysis",
      "description": "股权结构分析",
      "requiresUserConfirmation": true,
      "confirmationPrompt": "股权穿透结果显示有VIE架构，请确认是否继续深入分析"
    },
    {
      "name": "report_generation",
      "description": "生成核验报告",
      "outputFormat": "structured_json_with_evidence",
      "evidenceFields": ["data_sources", "query_timestamps", "confidence_scores"]
    }
  ]
}

MCP Apps 的价值在于：企业可以把最佳实践封装为可复用的应用模板，而不需要每次都重新描述任务流程。

4.3 多轮交互的工程实现

新版 MCP 支持补充输入的标准机制：

# 用户补充输入
await client.send_input({
    "task_id": "task-uuid-123",
    "stage_id": "entity_anchor",
    "input": {
        "company_name": "企查查科技股份有限公司",
        "credit_code": "91110108MA01XXXXX",
        "confirmed_by": "user_id_456"
    }
})

#