MCP生态 on Kalend's Blog

MCP正式版发布：你的MCP Server要改什么？12个月迁移窗口指南

Wed, 05 Aug 2026 08:30:00 +0800

2025年，Simon Willison在年度总结里给MCP泼了冷水——协议太复杂，被Skills取代了，“没人会大规模用"是他的基本判断。

2026年7月31日，同一个人一周内写了三个MCP项目（mcp-explorer、datasette-mcp、llm-mcp-client），然后发了篇博客：“Stateless MCP has recaptured my interest.”

态度反转的原因只有一个：MCP 2026-07-28正式版把协议从"带状态的长连接"改成了"无状态的HTTP请求”。这一刀砍掉了部署中最复杂、最容易出问题的部分。

我花了一天时间整理这份迁移指南。如果你有正在跑的MCP Server，这12个月窗口期你需要知道的事都在这里了。

核心变更1：无状态协议

这是最大的变化，也是Simon回心转意的原因。

旧版流程（3步握手）：

1
2
3
4
5
6
7
8


POST /mcp
→ {"method": "initialize", "params": {...}}
← {"result": {"sessionId": "abc123"}}

POST /mcp
Header: Mcp-Session-Id: abc123
→ {"method": "tools/list"}
← {"result": {"tools": [...]}}

新版流程（单次自包含请求）：

1
2
3
4
5
6


POST /mcp
Header: MCP-Protocol-Version: 2026-07-28
Header: Mcp-Method: tools/list
Header: Mcp-Name: my-server
→ {"method": "tools/list", "_meta": {"protocolVersion": "2026-07-28", "clientInfo": {...}}}
← {"result": {"tools": [...]}}

三个关键变化：

变化	旧版	新版
初始化	initialize/initialized 握手	每个请求自带 `_meta`
会话	Mcp-Session-Id 维持状态	无状态，请求自包含
发现	initialize 返回能力	`server/discover` 方法

这意味着：任何MCP请求可以落在任何服务器实例上，不需要粘性路由，不需要共享会话存储。水平扩展瞬间变得简单。

对于需要状态的场景（比如购物车），规范推荐用显式Handle模式——服务器返回一个 basket_id，模型在后续调用中传回。这比隐藏的会话状态更透明，模型可以跨工具组合Handle、推理Handle。

核心变更2：Extensions框架

旧版MCP的所有功能都挤在规范里，加一个新功能就要改规范。新版引入了Extensions框架：

反向DNS标识符（如 com.anthropic.mcp.apps）
通过 extensions map 协商
独立仓库 ext-*，委托维护者
独立于规范版本化

两个官方扩展值得关注：

MCP Apps（SEP-1865）：服务器可以渲染HTML UI，在沙箱iframe中运行。这意味着MCP工具不再只是返回JSON数据，可以直接给用户一个交互界面。

Tasks（SEP-2663）：从实验核心功能毕业为扩展。API有变化——tasks/list 被移除，新增 tasks/get、tasks/update、tasks/cancel。如果你在用Tasks，这是必改项。

核心变更3：三项功能废弃

12个月最低弃用窗口，2028年7月前必须迁移：

废弃功能	替代方案	迁移难度
Roots	Tool参数、resource URI或服务器配置	低
Sampling	直接集成LLM provider API	中
Logging	stderr（stdio）或OpenTelemetry	低

Roots和Logging的迁移基本是改几行配置。Sampling稍复杂——如果你的Server依赖Sampling让宿主LLM做决策，需要改成自己直接调LLM API。

迁移检查清单

以下是你的MCP Server需要改的内容，按优先级排列：

必须改（破坏性变更）：

1
2
3
4
5


□ 移除 initialize/initialized 握手逻辑
□ 移除 Mcp-Session-Id 处理
□ 添加 Mcp-Method 和 Mcp-Name 响应头
□ 更新错误码 -32002 → -32602
□ inputSchema 升级到 JSON Schema 2020-12

应该改（功能迁移）：

1
2
3
4


□ 迁移 Tasks API（移除 tasks/list，添加 get/update/cancel）
□ 替换 Roots 为 Tool 参数或服务器配置
□ 替换 Sampling 为直接 LLM API 集成
□ 替换 Logging 为 stderr 或 OpenTelemetry

可以做（新能力）：

1
2
3


□ 启用 tools/list 的 ttlMs 和 cacheScope 缓存
□ 集成 W3C Trace Context（traceparent/tracestate）
□ 探索 MCP Apps 扩展（服务器渲染UI）

生态影响

这些数字说明MCP已经不是实验品了：

SDK月下载量接近5亿次，TypeScript和Python各自突破10亿次总下载
Gartner预测：2026年底75%的API网关厂商将加入MCP特性
微软Azure正在全面适配MCP 2.0无状态架构
FastMCP v3.4.5已发布（2026-07-28），原生支持2026-07-28规范

如果你用FastMCP框架，升级到v3.4.5可以自动处理大部分迁移。但底层逻辑还是建议理解清楚——框架帮你屏蔽了复杂度，但出了问题你得知道往哪看。

结论

MCP从"太复杂没人用"到"一个人一周写三个项目"，核心原因是无状态架构砍掉了部署中最反人类的部分。

12个月窗口期听着很长，但如果你的MCP Server有用户在用，建议现在就开始改。先改破坏性变更（握手和Session），再逐步迁移废弃功能。

Simon Willison用一周写了三个项目证明新协议的简洁。你的Server迁移大概用不了三天。

varkm

4万个MCP Server，你该信谁？六家平台横评，别再只看数量了

Thu, 02 Jul 2026 23:00:00 +0800

先说结论

别被"4万个"唬住了。

MCP Server 不是越多越好。你真正需要的可能就 5-10 个，关键是谁帮你把好质量关、谁的访问速度能让你不骂街。我花了两天时间把六个平台翻了个底朝天，结论很粗暴：

个人开发者：Smithery 为主（量大、开源透明），ModelScope 做补充（在线测试真香）
企业团队：ModelScope 一把梭（阿里云官方、SLA、百炼生态打通）
对安全敏感的：mcp-marketplace.io（有审核流程）或 MCP Hub中国（精选）
想偷懒选最多的那个：MCP Store——但做好踩坑准备，40000 这个数字水分不小

下面是完整的横评。

六个平台，一张表看懂

维度	Smithery	MCP Store	ModelScope	MCP Hub中国	MCP World	mcp-marketplace.io
服务器数	6000+	40000+	未公开	74+	未确认	4700+
路线	海量开源	海量聚合	官方生态	精选	导航	安全审核
安全审核	❌	❓	✅（官方）	✅（精选）	❓	✅
中文支持	❌	✅	✅	✅	✅	❌
在线测试	❌	✅	✅	❌	❌	❌
一键安装	✅	✅	✅	❌	❌	✅
开源自托管	✅	❌	❌	❌	❌	❌
企业级SLA	❌	❌	✅	❌	❌	❌

看完这张表，你应该有个感觉了：没有一个平台样样都行。 这才是现实。

逐个拆解

Smithery：海外生态王，但访问是真痛

smithery.ai 是目前海外最大的 MCP 开源托管平台，6000+ 个服务器，社区驱动，代码开源（Smithery Connect），每个服务器都提供标准化 install command，直接复制就能用。想查源码？一键跳 GitHub。

好的地方：生态丰富到离谱，你能想到的工具基本都有人做了。开源透明，你可以自托管整个平台。比如你想接 GitHub、接数据库、接 Slack，搜一下全有，而且每个 Server 都附带 GitHub 源码链接，代码能翻个底朝天。

不好的地方：服务器在海外，国内访问慢得你想砸键盘——搜索一个关键词等 5 秒，装一个 Server 等 30 秒，体验差距明显。英文为主，对不习惯看英文文档的人不友好。最要命的是没有安全审核——任何开发者都能上传，你装的 Server 里藏了什么代码，全靠你自己的审查能力。好消息是它开源，你可以自己审查甚至自托管整个平台来规避第三方风险。

MCP Store：4万这个数字，我存疑

mcpmarket.cn 号称 40000+ 服务器，两步安装到 Claude/Cursor，中文界面，看起来很美好。

但我查了一下数据：Smithery 作为海外最大的开源平台，社区贡献了一年多才攒到 6000+。一个国内平台突然冒出 40000+，这个数字怎么来的？详情页写的 30000+，首页写的 40000+，自己都对不上。注水嫌疑很大。

优势是确实方便——中文界面 + 两步安装，对新手友好。但如果你在乎质量，建议谨慎。我试了几个标称"热门"的 Server，有的文档基本为零，有的工具描述和实际功能完全对不上。40000 这个数字更像是把各处抓来的条目全堆上去，真正能稳定跑起来的可能远不到十分之一。

ModelScope MCP：阿里云亲儿子，稳

modelscope.cn/mcp 是阿里云魔搭社区的 MCP 板块。这不是一个纯导航站，而是一个有官方运营、企业级 SLA、在线测试的完整平台。

最大的亮点是：你可以直接在网页上测试 MCP Server 的工具，不用先装到本地。官方的 modelscope-mcp-server 接入了模型、数据集、创空间、论文，跟阿里云百炼平台深度打通。

优势：官方背书、稳定可靠、在线测试省了大量试错时间。对团队协作场景来说，有人兜底和没人兜底是两个概念。

劣势：偏阿里生态，如果你不用百炼，很多价值发挥不出来。服务器数量不如 Smithery，找冷门工具时大概率要转战其他平台。

MCP Hub中国：74个，少但精

mcp-cn.com 走的是完全不同的路线——不追求量，只选 74+ 个经过筛选的 Server。

74 个听着少，但如果你真正用 MCP 做开发的场景，常用的也就那几十个：文件系统、Git、数据库、搜索、邮箱、日历……主流需求基本都覆盖了。精选意味着每个都过了基本审查，不会出现"装完发现是空壳"的情况。

劣势也很明显：覆盖面有限，你要找冷门工具时这里大概率没有。而且没有在线测试和一键安装，找到之后还得自己手动配置。

MCP World：存在感低

mcpworld.com 2025年9月上线，定位"海量 MCP 工具导航"。中文、分类清晰，但知名度低，质量审核机制不透明。可以作为备用搜索入口，不建议作为主力。

海外补充：mcp-marketplace.io 和 PulseMCP

mcp-marketplace.io 有 4700+ 服务器，走的是安全审核路线——每个 Server 上架前都要过审核。如果你对安全性敏感（比如企业环境），这是海外最靠谱的选择之一。

PulseMCP 则主打客户端整合，直接把 MCP Server 接入你的工作流，体验比较丝滑。它更像一个"推荐引擎"而非商店，帮你从海量 Server 里筛选出适合你使用习惯的那些，适合不想花时间研究的人。

怎么选？决策表

你的场景	推荐	理由
个人开发，想多试工具	Smithery	量大、开源、可直接安装
企业团队，要稳定可靠	ModelScope	官方背书 + SLA + 在线测试
对安全敏感	mcp-marketplace.io / MCP Hub中国	有审核流程
纯中文需求，图省事	MCP Store	但注意质量风险
不确定，先试试	ModelScope 在线测试	零安装就能跑工具

不可能三角

MCP 应用商店有三个核心维度：数量、质量、访问速度。

这三个你最多只能选两个：

选数量+质量 → Smithery + mcp-marketplace.io，但海外访问慢
选质量+速度 → ModelScope / MCP Hub中国，但数量有限
选数量+速度 → MCP Store，但质量没保障

没有银弹。认了吧。

我的推荐组合

国内开发者，我的建议是双平台策略：

ModelScope 做主力：在线测试筛选 → 确认可用后部署，稳定且有官方兜底
Smithery 做补充：ModelScope 找不到的工具去 Smithery 搜，接受访问慢的代价

不推荐：只看 MCP Store 的 40000+ 数字就闭眼选。数量是最容易造假的指标，你装的每一个 Server 都有潜在的安全风险——从恶意代码到权限滥用，MCP Server 跑在你的环境里，有文件系统访问权限、有网络请求能力。选平台，本质上是选一个帮你过滤风险的中间人。

数量不等于价值。能用、安全、快，才是真正重要的三件事。

MCP + A2A：给Agent装手还是装同事？2026协议栈三层架构拆透

Thu, 02 Jul 2026 08:00:00 +0800

作者：varkm

Salesforce的技术架构师在2026年3月的Trailblazer大会上展示了一张架构图——他们的Agentforce平台同时跑着MCP和A2A两个协议。客服Agent通过A2A调用外部的技术支持Agent，技术支持Agent再通过MCP连接内部知识库。

这张图揭示了一个正在发生的事实：单Agent时代结束了，协议栈时代开始了。

先给结论：MCP、A2A、ACP不是竞争关系，而是解决不同维度问题的三层协议栈。垂直方向，MCP负责Agent到工具的连接；水平方向，A2A负责Agent到Agent的协作；基础设施层，ACP负责Agent的注册、发现和生命周期管理。三层叠加，构成企业级多Agent系统的完整通信骨架。

为什么需要协议栈？单Agent时代的终结

过去一年，几乎所有AI框架都在做同一件事：给Agent接MCP。接了数据库、接了文件系统、接了GitHub、接了Slack。一个Agent能力越来越强，能调用的工具越来越多。

但企业里遇到的真实问题不是"一个Agent能调多少工具"，而是"五个不同平台的Agent怎么协作"。

举个例子：客服Agent跑在Salesforce上，技术支持Agent跑在ServiceNow上，工单系统在Jira。用户提了一个技术问题，客服Agent需要判断这个问题该转给谁，然后跟技术支持Agent交接上下文，技术支持Agent解决完还要回写工单。

这个流程里，MCP完全帮不上忙。MCP解决的是"一个Agent怎么调用外部工具"，不解决"Agent之间怎么对话"。就像USB接口标准化了设备连接，但两台电脑之间传输文件还需要网络协议。

这就是A2A和ACP诞生的原因。三个协议各管一层：

协议	解决什么	方向	类比
MCP	Agent调用工具和数据	垂直（Agent→Tool）	USB接口
A2A	Agent之间通信协作	水平（Agent→Agent）	网络协议
ACP	Agent注册、发现、治理	基础设施	DNS+目录服务

MCP层：垂直的「手」（Agent→Tool）

MCP（Model Context Protocol）是Anthropic在2024年底推出的开放协议，目标是标准化大模型与外部工具、数据源的连接方式。

核心数据：截至2026年7月，MCP的TypeScript SDK在npm上月下载量达到1.55亿次，官方servers仓库在GitHub上获得了8.8万颗星。生态数据比半年前翻了一倍。

MCP的核心设计很简单：一个MCP Server暴露一组工具（Tools）、资源（Resources）和提示（Prompts），MCP Client（通常是AI框架）通过标准化的JSON-RPC协议调用它们。任何支持MCP的框架都能直接接入任何MCP Server，不需要为每个工具写定制集成。

主流框架已经全面支持：Claude、Cursor、Windsurf、Cline、Zed、以及各大云厂商的Agent平台。你写一个MCP Server，理论上所有这些平台的用户都能直接用。

MCP的局限也很明确：它只解决"Agent能用什么"，不解决"Agent能找谁"。 一个MCP Server就是一个工具箱，但工具箱之间不能互相调用。如果你的客服Agent需要跟另一个平台的技术支持Agent协作，MCP给不了方案。

A2A层：水平的「同事」（Agent→Agent）

A2A（Agent2Agent Protocol）是Google在2025年4月发布的开放协议，目标是解决跨平台Agent之间的通信和协作问题。2026年3月12日发布v1.0正式版，5月28日发布了v1.0.1维护版本，项目已捐赠给Linux Foundation托管。

核心数据：GitHub上获得24,574颗星，超过150家组织表态支持，包括Google、Microsoft、AWS、Salesforce、SAP、ServiceNow、Atlassian、Box、Cohere等。

A2A的三个核心概念：

AgentCard——每个Agent发布一个能力声明文件（类似OpenAPI Spec），描述自己能做什么、接收什么输入、返回什么输出。其他Agent通过读取AgentCard就知道该不该找你协作。

Task生命周期——A2A不是简单的远程函数调用，而是定义了完整的任务状态机：submitted → working → input-required → completed/failed/canceled。长任务可以中途要求补充信息，可以流式返回进度。

流式通信——基于HTTP + SSE（Server-Sent Events），支持长连接和流式输出。适合需要长时间运行的任务，比如"分析这份100页的财报"。

生产案例已经落地。Salesforce的Agentforce通过A2A实现了跨生态Agent协作：一个跑在Salesforce上的销售Agent可以直接调用跑在ServiceNow上的IT运维Agent，上下文和任务状态在两个平台之间无缝传递。ServiceNow在Zurich版本（2026年Patch 4）中也集成了A2A支持，Now Assist的Agent可以跨平台响应外部请求。

ACP层：生命周期管理（Agent注册/发现/治理）

ACP（Agent Communication Protocol）由IBM发起，i-am-bee组织维护，目标是解决Agent生态的"基础设施"问题：Agent在哪里注册、怎么被发现、生命周期怎么管理。

GitHub仓库i-am-bee/acp目前有1,014颗星，已经发布到v1.0.3版本。相比MCP和A2A的热度，ACP关注者少得多，但它解决的问题是绕不开的。

想象一下：企业内部部署了50个Agent，分别跑在不同平台上。现在要找一个"能处理中文合同审查"的Agent——你怎么找？没有统一的注册中心，只能靠人去问、靠文档去翻。

ACP的设计思路是建立一个Agent注册表（Registry），每个Agent在部署时向注册中心注册自己的元信息：名称、能力描述、端点地址、认证方式、SLA等级。其他Agent或应用通过查询注册表来发现和定位目标Agent。

ACP还定义了Agent的生命周期管理：注册、上线、下线、版本更新。当Agent的能力发生变化时，注册表自动更新，确保调用方拿到的永远是最新信息。

ACP和A2A的关系是互补而非竞争。A2A定义了Agent之间怎么说话，ACP定义了怎么找到对方、怎么管理对方的生命周期。就像HTTP协议和DNS的关系——HTTP负责传输，DNS负责寻址。

三层协议栈如何协同工作

把三层叠起来，一个完整的多Agent协作流程是这样的：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


用户请求: "帮我查一下客户A上个月的订单异常原因"

┌─────────────────────────────────────────────┐
│ 客服Agent (Salesforce Agentforce) │
│ 1. ACP查询: 找一个能做"订单分析"的Agent │
│ 2. ACP返回: 技术支持Agent @ ServiceNow │
│ 3. A2A调用: 发送Task到技术支持Agent │
└──────────────────┬──────────────────────────┘
 │ A2A (Agent→Agent)
 ▼
┌─────────────────────────────────────────────┐
│ 技术支持Agent (ServiceNow Now Assist) │
│ 1. 接收A2A Task, 状态=working │
│ 2. MCP调用: 连接ERP数据库查询订单记录 │
│ 3. MCP调用: 连接日志系统拉取异常日志 │
│ 4. 分析完成, A2A返回结果 │
└─────────────────────────────────────────────┘

整个流程中，ACP负责"找到人"，A2A负责"交代任务"，MCP负责"使用工具"。三层各司其职，没有重叠。

MCP和A2A正在走向融合。2026年以来，两个社区已经组建了联合工作组（Joint Working Groups），讨论如何在协议层面实现更好的互操作。一个可能的方向是：A2A的AgentCard中直接嵌入MCP工具声明，让Agent在发现彼此时就能看到对方提供了哪些MCP工具。两层架构（MCP + A2A）正在快速成为事实标准，ACP作为可选的治理层，在企业级场景中逐步渗透。

开发者该怎么做？

三层协议的成熟度差异很大，投入优先级也不同：

协议	成熟度	生态规模	开发者优先级
MCP	生产就绪	1.55亿月下载 / 8.8万星	最高——现在就该用
A2A	快速成长	2.5万星 / v1.0.1 / 150+组织	关注——多Agent场景必上
ACP	早期阶段	1千星 / v1.0.3	观望——企业级治理场景再考虑

场景一：单Agent + 工具调用。 只需要MCP。你有一个Agent，需要连接数据库、文件系统、外部API——写几个MCP Server，用任何支持MCP的框架直接接入。不需要A2A，更不需要ACP。这是目前90%的场景。

场景二：多Agent跨平台协作。 MCP + A2A。你有多个Agent跑在不同平台上，需要互相调用——用MCP连接各自的工具，用A2A实现Agent间通信。这是企业级场景的主流方向，Salesforce和ServiceNow已经在这么做了。

场景三：大规模Agent治理。 MCP + A2A + ACP。你有几十上百个Agent需要统一管理——加上ACP做注册发现和生命周期管理。目前只有极少数大型企业在探索这个阶段。

避坑提醒：不要过度设计。如果你的场景是"一个Agent调用几个工具"，上A2A是杀鸡用牛刀。A2A的Task生命周期、流式通信、AgentCard机制都增加了复杂度，单Agent场景完全不需要。协议栈的每一层都有成本，只在你真正遇到对应问题时才引入。

三层协议栈不是噱头，是企业级多Agent系统的必经之路。但路要一步一步走，从MCP开始，在真实需求驱动下逐层叠加。