把时间锚定在 2026 年 3 月，中国 AI 市场最关键的变化已经不只落在模型能力或 OpenAI 兼容接口，更深层的重排发生在工具分发：MCP 正从协议层上移为分发层。

表面看只是术语位移，真正被改写的是控制杠杆与锁定点的位置。厂商不再把 MCP 当作一层薄适配，而是把它产品化为托管服务、插件目录或带配额的远程能力包，接入方要面对的就不只是模型端点，而是覆盖工具、智能体流程与发布路径的一整套上层控制平面。[1][2][3][4][5][6][7][8]

放在采购与平台治理语境里，标准化决策也随之上移。更难的问题不再只是模型端点能否替换，而是哪一层工具界面在负责计量、审核、编目与发布整条工作流。 图片说明：题图使用深圳腾讯滨海总部的现场照片，把这篇讨论放回真实平台运营语境，强调 MCP 从协议能力上移为分发能力后，控制边界会落在具体平台与发布体系里。

发生了什么：工具调用正被重新做成平台界面

Qwen 当前的 agent 框架把第一层变化写得很清楚。Qwen-Agent 文档里，MCP 已经是一个一等安装选项（qwen-agent[...,mcp]），智能体也可以直接通过 mcpServers 配置块接工具，同时模型端既可以指向本地 OpenAI 兼容服务，也可以指向 DashScope 兼容入口。[1] 这已经不只是“支持一个协议”。它说明在这套 SDK 里，工具分发本身已经被视作应用默认界面的一部分。

阿里云百炼又往上走了一层。它在 2026 年 2 月更新的 MCP 文档里，重点已经放到官方云部署 MCP 服务怎样在平台内部开通，再嵌入智能体或工作流，并且通过外部调用接到第三方应用里。[2] 在智能体应用路径下，单个智能体最多可以接 5 个 MCP 服务。[2]

再看阿里云的自定义 MCP 文档，平台化意图就更完整了。开发者可以通过三条路径把 MCP 带进来：给 npx 或 uvx 代码包做脚本部署、把现有 REST API 通过 AI 网关包成 MCP、或者把阿里云 OpenAPI 直接导入成 MCP。[3] 一旦一个平台同时支持托管 MCP、网关托管 MCP，以及云产品 MCP，它卖的就已经不只是推理能力，而是推理之上的装配线。

智谱和腾讯给出下一步：分发已经按客户端形态重写

智谱这组面向编程场景的产品文档走的是另一条路。它没有把重心放在托管式工作流画布，而是把 MCP 做成面向编程客户端的现成服务产品。

搜索 MCP 文档给出的是一个远程 HTTP MCP 入口，也就是通过网络调用的 MCP 服务，可以直接接入 Claude Code、Cline、OpenCode、Crush、Goose 等兼容客户端。[4] ZRead MCP 页把这件事又往前推了一步：它把开源仓库访问能力包装成独立远程服务，按客户端逐一给出配置方式，同时把调用额度和套餐直接绑在一起——Lite 每月 100 次，Pro 1,000 次，Max 4,000 次，适用于 ZRead、联网搜索与网页读取这一组能力。[5]

视觉理解 MCP 文档则展示了与远程服务互补的另一种形态：本地包分发。这个视觉服务通过 npm 包 @z_ai/mcp-server 以本地 stdio（标准输入/输出）方式接入，但商业控制仍然留在上游，需要 API Key，视觉额度还与一个 5 小时 恢复周期的共享资源池绑定。[6] 也就是说，就算服务进程跑在本地，真正决定边界的仍然是鉴权、配额和打包方式。

腾讯的落点又不一样，它押注的是插件市场的治理。它在 2025 年 11 月更新的插件文档里，把插件分成 4 种类型：API、MCP、代码、应用；又把来源分成 3 类：官方、第三方、自定义。[7] 到 2025 年 12 月的使用文档里，MCP 插件已经可以被拉进 Multi-Agent 应用，再顺着发布流程推到生产环境，生成体验链接、分享入口和 API 调用信息。[8]

智谱和腾讯的共同点在于：MCP 已经不再是工程师自己拼出来的一层协议，它正在被做成一种会被客户端和平台界面持续塑形的分发格式。

中国 AI 栈里已经出现三种 MCP 包装模型

到 2026Q1，市场里至少已经能看出三种不同的 MCP 包装方式。

1. SDK 组装型 MCP

Qwen-Agent 代表的是最轻的一种。框架把 MCP 配置暴露出来，真正的组合逻辑——模型入口、工具服务组合、运行时装配——大体还握在开发者自己手里。[1]

这种形态的可移植性最高，但运维和拼装工作也更多落在开发团队身上。

2. 平台托管型 MCP

阿里云把 MCP 推进到了托管中层。官方服务、工作流节点、智能体接入、网关导入、OpenAPI 导入，都落在同一个平台边界里。[2][3]

它确实减少了装配摩擦，但生命周期控制也随之集中到了厂商控制台、凭据体系和部署抽象里。

3. 市场或远程分发型 MCP

智谱和腾讯都在把 MCP 做成更接近目录项的东西，而并非一份裸协议。对智谱来说，这意味着面向编程客户端的远程或本地 MCP 产品，外面再套上套餐配额和预写好的配置块。[4][5][6] 对腾讯来说，这意味着插件广场、来源分类，以及工具怎样进入智能体应用、怎样进入发布流程。[7][8]

这种形态减少了发现和接入摩擦，但决定性边界也随之转移到了目录治理、审核和打包策略上，也更容易让“协议兼容”与“真正可迁移”之间出现落差。

如果把这件事翻成买方最容易抓住的话，大致已经可以这样理解。

买方看演示时，30 秒就能先判一层

如果你想快速判断一家厂商到底只是“支持 MCP”，还是已经把 MCP 做成了分发面，可以先盯演示里的 3 个信号。

这组判断有用，是因为“兼容”这两个字现在越来越便宜；真正昂贵的部分，落在目录控制、配额政策与发布权。

兼容性在变好，分裂点却在上移

所以现在再问“支不支持 MCP”，已经太浅了。

从协议层看，兼容性确实在变好。MCP 官方介绍仍然把它定义为 AI 应用连接工具、数据与工作流的一套通用标准。[9] 就这个狭义定义而言，市场是在收敛。

但供应链的分裂，正在协议之上发生。新的分歧点在于：

这比单纯的互操作更重要，因为它决定了真正的迁移边界。模型端点越来越容易替换，真正难迁的是被平台打包好的工具层、配额逻辑、工作流绑定和发布路径。

三个能暴露真实锁定点的买方问题

在签平台合同之前，先把三个问题问死。

  1. MCP 定义、鉴权配置与工具元数据，能不能在不重建控制台内智能体的前提下完整导出？ 如果不能，这条 MCP 线路的可移植性就只是表面成立。
  2. 配额到底绑在哪一层：协议端点、客户端套餐，还是市场目录项？ 控制点越往上，所谓“兼容工具面”就越难迁走。
  3. 同一套工具，能不能从内部工作流直接走到外部发布面，而不经过厂商专有的审核或上架步骤？ 如果发布路径被专有闸门卡住，分发权其实仍然在协议之上。

如果这三题里有两题答得含糊，锁定强度通常已经高于协议图面显示的程度。

接下来该看什么

下个季度有三件事最值得继续盯。

  1. 会不会有更多中国厂商公布托管式 MCP 目录，而不只是协议支持？ 阿里云已经先走到了这一步。[2][3]
  2. 远程 MCP 入口会不会真正变成客户端中立能力，还是继续围绕少数 coding client 和套餐层级来打包？ 目前智谱的做法仍然带着明显的客户端定制和配额分层。[4][5][6]
  3. 市场治理会不会变成真正护城河？ 腾讯这条线提示，插件来源、应用发布和生产上线流程，未来会和模型 API 一样黏人。[7][8]

如果这三条都继续成立，中国 AI 下一轮控制权竞争，争的就不只是基础模型，而是谁拥有工具、智能体与发布界面交汇的那一层北向分发面。

结论

中国 AI 厂商开始把 MCP 包装成分发基础设施，而不再只是互操作协议。

这就是 2026Q1 更值得记住的栈更新。协议收敛确实在发生，但市场正在更高一层分化：鉴权、配额、目录、工作流嵌入，以及发布控制。还把 MCP 当成一枚简单兼容徽章的买方，实际上是把观察视角放低了一层。

来源

  1. Qwen-Agent 文档（MCP 安装选项、mcpServers、OpenAI 兼容与本地端点示例）
  2. 阿里云 Model Studio 官方 MCP 服务文档（官方云部署服务、智能体/工作流集成、外部调用、单智能体最多 5 个 MCP 服务）
  3. 阿里云 Model Studio 自定义 MCP 文档（脚本部署、AI 网关导入、OpenAPI 导入）
  4. 智谱 Search MCP 文档（远程 MCP 端点、客户端支持与配置示例）
  5. 智谱 ZRead MCP 文档（远程 MCP 打包形态、客户端支持、Lite/Pro/Max 月度配额）
  6. 智谱 Vision MCP 文档（本地 npm MCP 包、客户端集成、5 小时恢复共享配额池）
  7. 腾讯智能体平台插件文档（4 类插件、3 类来源、MCP 插件广场）
  8. 腾讯智能体平台 MCP 插件使用文档（Multi-Agent 集成与发布流程）
  9. MCP 官方简介（标准范围与生态支持）