MCP协议0.5史诗级升级：从有状态会话到无状态核心，AI工具链的「断舍离」

前言：AI工具链正在经历一次静默的架构革命

2026年7月28日，Anthropic正式发布了MCP（Model Context Protocol）协议自诞生以来最重大的一次架构重构——从有状态（Stateful）连接全面转向无状态（Stateless）核心。

这不是一次普通的版本迭代。这是一次对协议灵魂的重写：initialize握手被移除、Mcp-Session-Id被删除、SSE长连接推送被替换、Tasks API被重写为Extension。协议从"建立连接→维持会话→交换数据"的经典模式，转变为"每次请求自给自足"的HTTP风格。

对于普通开发者来说，这可能只是一个技术细节的变动。但对于整个AI工具链生态来说，这是自MCP协议发布以来最具影响力的架构决策——它直接影响着：如何部署MCP服务器、如何设计AI Agent的工作流、如何构建企业级的AI基础设施。

本文将深入拆解这次变更的技术细节、架构演进逻辑、对开发者的实际影响，以及从旧版本迁移的最佳实践。

一、背景：为什么MCP协议最初设计成有状态？

要理解这次变更的深远意义，我们首先需要理解MCP协议最初为什么被设计成有状态架构。

1.1 MCP协议的诞生背景

MCP（Model Context Protocol）由Anthropic在2024年末推出，定位是解决AI模型与外部工具、数据源之间上下文共享的标准化问题。它的核心目标是：让一个AI模型能够可靠地调用多个外部工具，同时保持上下文的连贯性。

在MCP出现之前，每个AI编程助手、每个AI Agent都是自己实现与工具的集成——GitHub Copilot用插件机制、Claude Code用内置工具系统、Cursor用Composer……这些方案互不兼容，开发者无法复用，社区无法共享。

MCP的出现，试图成为AI工具互操作的"USB-C接口"——一个标准，多种实现。

1.2 有状态设计的合理性

最初，MCP采用了基于会话的有状态设计，这在桌面应用场景下是完全合理的：

┌─────────────────────────────────────────────────────┐
│  Desktop Application (AI Coding Tool)               │
│                                                     │
│  ┌─────────┐    stdio     ┌──────────────────┐      │
│  │   AI    │◄───────────►│  MCP Server      │      │
│  │  Model  │   长连接     │  (本地进程)        │      │
│  └─────────┘             └──────────────────┘      │
│       │                         │                 │
│  启动时握手                      │                 │
│  交换能力                        │                 │
│  维持会话                        │                 │
└─────────────────────────────────────────────────────┘

在这种场景下：

• MCP服务器是一个本地进程，通过标准输入输出与应用通信
• 连接建立后长期存活，随时响应工具调用
• 会话ID用于标识这次通信会话的生命周期
• 能力协商在启动时完成一次，后续复用

在这种场景下，有状态设计的开销几乎为零——握手成本可以忽略不计，会话管理也简单直观。

1.3 但当服务器走向远程部署时，问题出现了

然而，现实的AI基础设施远比桌面场景复杂。当MCP服务器需要提供远程服务时，问题来了：

旧版MCP（有状态）远程部署架构：

                    Client
                      │
                      │ 1. initialize (TCP)
                      ▼
              ┌─────────────────┐
              │  Load Balancer  │◄── 粘性会话路由要求
              │   (Nginx/LB)    │
              └────────┬────────┘
                       │
          ┌────────────┼────────────┐
          ▼            ▼            ▼
    ┌──────────┐ ┌──────────┐ ┌──────────┐
    │ Server A │ │ Server B │ │ Server C │
    │Session-1 │ │Session-2  │ │Session-3  │
    └──────────┘ └──────────┘ └──────────┘
         │            │            │
         └────────────┼────────────┘
                      │
              ┌────────▼────────┐
              │  Shared Session │◄── Redis/数据库
              │     Storage     │    必须保存会话状态
              └─────────────────┘

分布式噩梦：Mcp-Session-Id将客户端与发起会话的服务器实例绑定。如果Session-1的请求被路由到Server B，B根本不认识这个会话，整个请求就会失败。

为了解决这个问题，团队不得不引入：

• 会话亲和性配置：确保同一会话的请求永远路由到同一服务器
• 外部会话存储：用Redis等外部存储共享会话状态
• MCP专用网关逻辑：能够解析JSON请求体以判断路由的中间件

一句话概括：一个交付MCP服务器的团队，不得不为协议本身制造的分布式系统问题买单。

二、核心变更：从有状态到无状态的架构重构

2.1 变更总览

2026-07-28版本的MCP协议，核心变更可以归纳为以下几点：

2.2 新版架构：每次请求自给自足

新版MCP的核心设计哲学是**"按需复杂度"（Complexity on Demand）**——协议核心保持精简，有状态性仅在功能真正需要时才出现。

新版MCP（无状态）远程部署架构：

                    Client
                      │
                      │ POST /message
                      │ Headers: Mcp-Method, Mcp-Name
                      │ Body: request + _meta
                      ▼
              ┌─────────────────┐
              │  Load Balancer  │
              │   (普通轮询)     │
              └────────┬────────┘
                       │
          ┌────────────┼────────────┐
          ▼            ▼            ▼
    ┌──────────┐ ┌──────────┐ ┌──────────┐
    │ Server A │ │ Server B │ │ Server C │
    │ 无会话    │ │ 无会话    │ │ 无会话    │
    │ 存储      │ │ 存储      │ │ 存储      │
    └──────────┘ └──────────┘ └──────────┘
         │            │            │
         └────────────┼────────────┘
                      │
              ┌────────▼────────┐
              │   数据库/存储    │◄── 仅用于业务数据（句柄等）
              └─────────────────┘

关键区别：不再需要粘性会话路由、不再需要外部会话存储、不再需要JSON包体检查。三个副本，轮询负载均衡，完美水平扩展。

2.3 协议版本与能力信息的内嵌传递

新版协议将版本信息和客户端能力信息通过每次调用的_meta字段随请求传递，客户端也需在其中携带自身身份标识：

// 请求示例
{
  "jsonrpc": "2.0",
  "id": "req-uuid-001",
  "method": "tools/call",
  "params": {
    "name": "filesystem_read",
    "arguments": { "path": "/data/config.json" }
  },
  "_meta": {
    "protocolVersion": "2026-07-28",
    "clientId": "cursor-desktop-v0.48",
    "clientCapabilities": {
      "streaming": false,
      "longRunning": true
    }
  }
}

这意味着服务器不需要"记住"客户端的能力——每次请求自带说明书。

2.4 server/discover：按需查询能力

新版还引入了server/discover方法，使服务器能力可以在任意时刻独立查询：

// discover请求
{
  "jsonrpc": "2.0",
  "id": "req-uuid-002",
  "method": "server/discover",
  "params": {},
  "_meta": {
    "protocolVersion": "2026-07-28",
    "clientId": "claude-code-cli"
  }
}

// discover响应
{
  "jsonrpc": "2.0",
  "id": "req-uuid-002",
  "result": {
    "protocolVersion": "2026-07-28",
    "serverInfo": {
      "name": "filesystem-server",
      "version": "2.1.0"
    },
    "capabilities": {
      "tools": { "listChanged": true },
      "resources": { "subscribe": true, "listChanged": true },
      "prompts": { "listChanged": true }
    },
    "extensions": {
      "mcp-apps": { "version": "1.0.0" },
      "tasks": { "version": "1.0.0" }
    }
  }
}

这解决了旧版"能力信息只在连接建立时交换一次"导致的问题——现在可以随时获取最新的服务器能力列表。

三、句柄模式：状态管理的优雅解决方案

3.1 显式句柄（Handle）替代隐式会话

新版协议中，对于确实需要记录状态的场景，主要解决方案是显式句柄（handle）——这正是HTTP购物车二十年来一直沿用的模式。

// 旧版（有状态）：服务器自动记住会话
// 客户端调用 tool_use → 服务器记住 context
// 客户端再次调用 → 服务器自动使用之前记住的 context

// 新版（无状态）：显式句柄
// 客户端调用 tool_use → 服务器返回 session_handle
// 客户端再次调用 → 携带 session_handle 作为参数

// 场景示例：购物车
// 1. 创建购物车
{
  "method": "shopping/create_cart",
  "params": { "userId": "user-123" }
}
// 响应
{
  "result": {
    "cart_id": "cart-abc-789",  // 显式句柄
    "items": []
  }
}

// 2. 添加商品（携带句柄）
{
  "method": "shopping/add_item",
  "params": {
    "cart_id": "cart-abc-789",  // 显式传递
    "item": { "sku": "ITEM-001", "qty": 2 }
  }
}

// 3. 结账（继续携带句柄）
{
  "method": "shopping/checkout",
  "params": {
    "cart_id": "cart-abc-789"
  }
}

3.2 句柄为什么比隐式会话更好？

对模型可见：句柄出现在工具结果中，模型可以感知和推理，可以在不同工具间组合使用，可以在工作流步骤间传递。

# 模型视角的差异

# 旧版：隐式会话，对模型不可见
# model: "读取配置文件，然后查询数据库"
# 系统内部：会话中保存了配置路径和数据库连接
# 但模型根本不知道这些细节

# 新版：显式句柄，对模型可见
# model: "读取配置文件，返回 config_handle"
# model: "用 config_handle 作为参数连接数据库"
# model: "最后用 config_handle 和 db_handle 完成分析"
# 整个过程模型完全可见、可控、可调试

可追溯：句柄出现在提示词、对话记录和日志中，任何时候都能追溯状态来源。

安全可控：句柄绑定至已认证主体，每次使用都需验证权限——不像会话ID那样一旦泄露就能横跨整个会话。

四、扩展生态系统：Tasks的浴火重生

4.1 Tasks API的教训

Tasks API是MCP协议历史上一个典型的"先上车后补票"的案例：

• 2025-11-25：作为实验性核心功能发布
• 实际生产使用：暴露了设计缺陷——会话绑定导致长时间任务无法跨服务器执行
• 2026-07-28：被重写为Extension，脱离核心协议

这个历程正好说明了扩展机制的价值：将不成熟的实验性功能隔离在核心协议之外，避免核心协议的破坏性变更。

4.2 新版扩展框架

新版协议引入了版本化扩展框架：

{
  "extensions": {
    "io.modelcontextprotocol/tasks": {
      "version": "1.0.0",
      "capabilities": ["create", "status", "cancel"]
    },
    "io.modelcontextprotocol/mcp-apps": {
      "version": "1.0.0",
      "capabilities": ["interactive"]
    }
  }
}

命名空间规则：

• 官方扩展：io.modelcontextprotocol 前缀
• 第三方扩展：作者持有的反向域名前缀（如 com.example.my-extension）

这与Kubernetes的自定义资源定义（CRD）模式如出一辙，熟悉的开发者会感到非常亲切。

4.3 扩展的生命周期管理

新版协议定义了明确的功能生命周期：

活跃（Active）──→ 弃用（Deprecated）──→ 移除（Removed）
    │                   │
    │                   └── 从弃用版本起，至少保留12个月
    │                       特殊情况：安全漏洞可缩短至90天
    │
    └── 通过能力标志或设置级版本控制演进
        只有不可避免的破坏性变更才使用新标识符

五、对开发者实际影响的深度分析

5.1 服务器开发者：运维简化

旧版痛点：

# Nginx配置：必须粘性会话
upstream mcp_backend {
    server 10.0.1.10:8080;
    server 10.0.1.11:8080;
    server 10.0.1.12:8080;
    ip_hash;  # 关键！按IP保持会话亲和性
}

# 如果IP_hash不够精确，还需要：
sticky cookie srv_id expires=6h domain=.example.com path=/;

# 还需要Redis存储会话状态
import redis

r = redis.Redis(host='localhost', port=6379)

def get_session_server(session_id: str) -> str:
    server = r.get(f"mcp:session:{session_id}")
    if not server:
        return None
    return server.decode()

def set_session_server(session_id: str, server: str, ttl: int = 3600):
    pipe = r.pipeline()
    pipe.set(f"mcp:session:{session_id}", server)
    pipe.expire(f"mcp:session:{session_id}", ttl)
    pipe.execute()

新版（普通无状态服务）：

# Nginx配置：普通轮询，无需任何粘性配置
upstream mcp_backend {
    server 10.0.1.10:8080;
    server 10.0.1.11:8080;
    server 10.0.1.12:8080;
}

# 无需任何会话存储
# 每次请求自带完整上下文，服务器无需记忆任何东西
def handle_request(request):
    # 直接处理，零会话依赖
    meta = request.get("_meta", {})
    protocol_version = meta.get("protocolVersion")
    return process(request, protocol_version)

5.2 平台团队：Mcp-Method请求头带来的网关能力

新版引入的Mcp-Method请求头，使得网关可以在不检查请求体的情况下实现精细化控制：

# 基于Mcp-Method的限速
limit_req_zone $binary_remote_addr$http_mcp_method zone=mcp_api:10m rate=100r/s;

server {
    location /mcp/ {
        limit_req zone=mcp_api burst=20 nodelay;
        
        # 按方法路由到不同后端
        if ($http_mcp_method = "tools/call") {
            proxy_pass http://mcp_tools_backend;
        }
        if ($http_mcp_method = "resources/read") {
            proxy_pass http://mcp_resources_backend;
        }
        if ($http_mcp_method = "prompts/get") {
            proxy_pass http://mcp_prompts_backend;
        }
    }
}

Mcp-Name请求头：用于命名工具、资源和提示词的操作维度网关控制。

5.3 缓存机制优化

受影响的列表与读取结果现在必须包含ttlMs和cacheScope字段：

// 工具列表响应（新格式）
{
  "result": {
    "tools": [
      {
        "name": "filesystem_read",
        "description": "读取文件内容",
        "inputSchema": { "type": "object", "properties": {} }
      }
    ],
    "_meta": {
      "ttlMs": 300000,        // 5分钟内可缓存
      "cacheScope": "client"  // 仅客户端可缓存，不允许中间件缓存
    }
  }
}

这一改进的意义在于：

• 工具列表需要以确定性顺序返回（提升提示词缓存命中率）
• 在高并发场景下，可以降低Token成本和延迟
• 参照HTTP Cache-Control设计，开发者容易理解

六、迁移实战：从旧版到0.5的完整指南

6.1 迁移前的准备清单

在开始迁移之前，你需要清点以下内容：

□ 统计所有MCP客户端的版本（是否支持2026-07-28协议）
□ 统计所有MCP服务器的版本（是否支持2026-07-28协议）
□ 检查是否使用了以下旧版特性：
  - initialize握手流程
  - Mcp-Session-Id请求头
  - SSE长连接推送
  - Tasks API（旧版实验性实现）
  - 客户端中介Sampling（Sampling扩展）
  - 结构化日志流（logging扩展）
□ 评估迁移风险：
  - 客户端和服务器必须同时升级吗？
  - 是否需要灰度发布？
  - 是否有回滚方案？

6.2 TypeScript SDK迁移示例

// 旧版SDK（2025-11-25）
import { Client } from '@modelcontextprotocol/sdk';

const client = new Client({
  name: 'my-app',
  version: '1.0.0'
});

// 有状态连接
await client.connect(transport);

// 握手和能力协商由SDK自动完成
const tools = await client.listTools();

// SSE长连接订阅
client.subscribe('notifications/tools/list_changed', (notification) => {
  // 监听工具列表变更
});

// 新版SDK（2026-07-28）
import { Client } from '@modelcontextprotocol/sdk';

// 无状态连接（transport可以是HTTP/POST）
const client = new Client({
  name: 'my-app',
  version: '1.0.0'
});

// 直接发送请求，无需先握手
// _meta信息在每次请求中自动携带
const tools = await client.request({
  method: 'tools/list',
  params: {},
  _meta: {
    protocolVersion: '2026-07-28',
    clientId: 'my-app-v1.0.0',
    clientCapabilities: { streaming: false }
  }
});

// 轮询获取变更通知（替代SSE）
async function pollToolChanges(lastKnownVersion: string) {
  const result = await client.request({
    method: 'tools/list',
    params: { since: lastKnownVersion }
  });
  return result;
}

// discover替代启动时握手
async function discoverServerCapabilities() {
  const info = await client.request({ method: 'server/discover' });
  return info.capabilities;
}

6.3 Python SDK迁移示例

# 旧版Python SDK
from mcp.client import Client
import asyncio

async def main():
    client = Client("my-app", "1.0.0")
    
    # 有状态连接
    await client.connect("http://mcp-server:8080")
    
    # 获取工具列表（会话已建立）
    tools = await client.list_tools()
    print(f"可用工具: {[t.name for t in tools]}")
    
    # 调用工具
    result = await client.call_tool("bash_execute", {"command": "ls -la"})
    print(result)

asyncio.run(main())

# 新版Python SDK（2026-07-28）
import asyncio
from mcp.client import Client

async def main():
    client = Client("my-app", "1.0.0")
    
    # 无状态请求（无需先连接）
    # 每次请求自带完整上下文
    capabilities = await client.discover()
    print(f"服务器能力: {capabilities.serverInfo}")
    
    # 获取工具列表
    tools = await client.list_tools()
    print(f"可用工具: {[t['name'] for t in tools]}")
    
    # 调用工具（携带必要上下文）
    result = await client.call_tool(
        name="bash_execute",
        arguments={"command": "ls -la"},
        _meta={
            "protocolVersion": "2026-07-28",
            "requestId": "req-001"
        }
    )
    print(result)

asyncio.run(main())

6.4 滚动部署策略

由于新版协议提供了协商机制的过渡路径，推荐使用客户端优先回退策略：

# 推荐：客户端优先尝试新版，失败时回退旧版
async def connect_to_mcp_server(url: str):
    client = Client("my-app", "1.0.0")
    
    # 第一步：尝试新版discover
    try:
        capabilities = await client.request(
            url=url,
            method="server/discover",
            timeout=5.0
        )
        print(f"使用新版协议: {capabilities['protocolVersion']}")
        return client, "2026-07-28"
    except Exception as e:
        print(f"新版discover失败，尝试旧版initialize: {e}")
    
    # 第二步：回退到旧版initialize
    try:
        await client.connect(url)
        print("使用旧版协议: 2025-11-25")
        return client, "2025-11-25"
    except Exception as e:
        print(f"连接失败: {e}")
        raise

6.5 迁移中的注意事项

1. Sampling扩展的迁移成本最高

# 旧版：服务器不持有凭证，客户端中介Sampling
{
  "method": "sampling/createMessage",
  "params": {
    "systemPrompt": "You are a helpful assistant.",
    "messages": [...],
    "maxTokens": 1024
  }
  # 服务器返回的是: 
  # { "model": "claude-3-5-sonnet", "content": "..." }
  # 但计费方是客户端，不经过服务器
}

# 新版：服务器需直接调用服务商API
# 服务器需要：
# 1. 持有服务商API凭证
# 2. 成为计费方
# 3. 成为用户数据的独立处理方
# 这对隐私合规和成本管理都有重大影响

2. 幂等性设计

# 新版协议移除了可恢复性机制
# 如果滚动部署中断了正在进行的请求，客户端需要：
# 1. 用新的requestId重新发起请求
# 2. 自行处理重放的幂等性

import uuid
from typing import Optional, Dict, Any

class IdempotentMCPClient:
    def __init__(self, client):
        self.client = client
        self.processed_ids: set = set()
        self.pending_results: Dict[str, Any] = {}
    
    async def call_with_idempotency(
        self, 
        method: str, 
        params: dict,
        idempotency_key: Optional[str] = None
    ):
        # 如果提供了幂等性键，先检查是否已处理
        if idempotency_key and idempotency_key in self.processed_ids:
            return self.pending_results[idempotency_key]
        
        request_id = str(uuid.uuid4())
        
        try:
            result = await self.client.request(
                method=method,
                params=params,
                _meta={"requestId": request_id}
            )
            
            if idempotency_key:
                self.processed_ids.add(idempotency_key)
                self.pending_results[idempotency_key] = result
            
            return result
        except Exception as e:
            # 滚动部署期间的重试
            if idempotency_key and idempotency_key in self.pending_results:
                return self.pending_results[idempotency_key]
            raise

3. 架构检查清单

## 迁移后架构检查清单

### 无状态验证
□ 所有MCP请求都不依赖服务器内存中的会话状态
□ 每个请求都携带完整的_meta信息
□ 不再依赖粘性会话路由

### 句柄模式
□ 所有状态相关操作使用显式句柄
□ 句柄在每次请求中作为参数传递
□ 句柄有合理的生命周期管理（创建→使用→过期）

### 扩展机制
□ 如使用Tasks功能，确认已迁移到新版Tasks扩展
□ 如使用Sampling，确认已评估凭证和计费影响
□ 扩展版本已正确声明

### 缓存策略
□ 列表操作响应包含ttlMs和cacheScope
□ 工具列表按确定性顺序返回（与提示词缓存相关）

### 监控运维
□ 请求日志包含requestId便于追踪
□ 错误日志包含协议版本信息
□ 性能监控已适配新的请求模式（轮询替代SSE）

七、性能对比与Benchmark

7.1 水平扩展性能对比

# 模拟测试：10000个并发请求的响应时间分布

import statistics
import random

# 旧版（有状态，需要会话亲和性）
# 场景：会话跨服务器重路由时失败 → 需要重连
# 实际测试中，约3%的请求会遇到跨服务器路由失败
stateful_times = []
for i in range(10000):
    t = random.gauss(45, 10)  # 平均45ms，标准差10ms
    if random.random() < 0.03:  # 3%失败率（会话不匹配）
        t = random.gauss(300, 50)  # 重连开销
    stateful_times.append(t)

# 新版（无状态，普通轮询）
# 场景：无会话亲和性，每个请求独立处理
stateless_times = []
for i in range(10000):
    t = random.gauss(38, 8)  # 平均38ms，标准差8ms（略好，因为无会话开销）
    stateless_times.append(t)

print(f"旧版（有状态）: 平均={statistics.mean(stateful_times):.1f}ms, P99={sorted(stateful_times)[9900]:.1f}ms")
print(f"新版（无状态）: 平均={statistics.mean(stateless_times):.1f}ms, P99={sorted(stateless_times)[9900]:.1f}ms")
# 输出：
# 旧版（有状态）: 平均=54.3ms, P99=312.5ms
# 新版（无状态）: 平均=38.2ms, P99=52.1ms

7.2 部署复杂度对比

八、展望：MCP协议的未来演进方向

8.1 无状态架构的长期价值

这次变更的核心价值，不是"去掉了一个握手步骤"，而是将MCP从"需要专门运维知识的分布式系统"，变为了"任何熟悉HTTP服务的团队都能运维的普通服务"。

这意味着：

• 更多的云服务商将原生支持MCP协议
• MCP服务器的部署门槛大幅降低
• 企业级AI基础设施集成将更加顺畅

8.2 即将到来的功能演进

基于新版扩展框架，以下功能有望在2026-2027年持续演进：

1. 交互式UI扩展（MCP Apps）：在Agent工作流中嵌入自定义界面组件
2. 多模态工具扩展：标准化图像、音频、视频处理工具的集成方式
3. 安全增强：基于OAuth 2.0和OIDC的细粒度权限控制
4. 联邦学习支持：跨组织的隐私保护型模型协作

8.3 开发者建议

立即行动：

1. 盘点当前使用的MCP客户端和服务器版本
2. 评估迁移优先级（高风险项优先）
3. 在测试环境验证新版协议兼容性

短期（1-3个月）：

1. 升级开发环境和CI/CD流水线
2. 更新文档和内部培训材料
3. 建立新版协议的监控和告警体系

中期（3-6个月）：

1. 生产环境灰度升级
2. 建立版本兼容性策略
3. 参与社区讨论，推动协议演进

九、总结：一次迟来但必要的重构

MCP协议0.5的无状态化，是一次迟来但必要的重构。

迟来，是因为有状态设计在桌面场景下运行良好，团队有足够的理由维持现状。

必要，是因为AI基础设施正在从"单用户桌面工具"快速演进为"多租户云端服务"。一个面向未来的协议，不能建立在需要特殊运维知识的分布式系统之上。

这次变更的深层逻辑，是Anthropic对协议设计哲学的一次清晰表达：让简单的保持简单，让复杂的只在需要时出现。不是无脑去掉所有复杂性，而是诚实地面对每一种复杂性的来源——如果是协议自身引入的，那就去掉它；如果是业务本身需要的，那就用显式、可见、可控的方式处理它。

句柄模式取代隐式会话，正是这一哲学的完美体现。

对于开发者来说，这是一次难得的"架构升级窗口期"。趁着协议版本更替，清掉那些技术债务，重新审视你的AI工具链架构——这可能是未来几年内最容易做这件事的时刻。

参考资源

• MCP Protocol 2026-07-28 Specification：modelcontextprotocol.io/specification
• MCP Python SDK GitHub：github.com/modelcontextprotocol/python-sdk
• MCP TypeScript SDK GitHub：github.com/modelcontextprotocol/typescript-sdk
• Anthropic Model Context Protocol Blog：anthropic.com/news/model-context-protocol

本文首发于程序员茄子（chenxutan.com），如需转载，请保留原文链接。