1. 为什么20多条更新里只有一条值得看

OpenAI DevDay 每次都是一场信息轰炸。2024年那场发布会一口气甩出二十多项更新，实时API、视觉微调、模型蒸馏、提示缓存、语音克隆、o1系列预览……朋友圈刷屏的节奏。但如果你是一个真正在写代码、搭系统、做产品的人，看完热闹之后冷静下来，会发现绝大多数更新跟你手头的活儿关系不大。真正能改变你日常开发方式的，其实只有一条：MCP协议被OpenAI正式接纳并集成进ChatGPT桌面端和API体系。

为什么这么说？因为其他更新本质上都是“模型能力增强”——更快、更便宜、更聪明。这些当然有价值，但它们不改变你组织代码和系统的方式。而MCP不一样，它改变的是AI应用与外部世界交互的底层架构。打个比方，之前的ChatGPT像一个知识渊博但被关在房间里的人，你只能隔着门缝递纸条；有了MCP之后，相当于给这个房间装了一扇标准化的门，外面的人可以按统一规格来敲门、递东西、取东西。

MCP全称Model Context Protocol，翻译过来叫“模型上下文协议”。它做的事情说起来很简单：定义一套标准接口，让AI模型能够以统一的方式调用外部工具、读取外部数据源、访问外部服务。听起来是不是有点像之前的Plugin和Function Calling？确实有重叠，但MCP的野心大得多。Plugin是OpenAI自己搞的一套封闭体系，Function Calling是API层面的能力，而MCP是一个开放协议——任何工具、任何数据源、任何服务，只要实现了MCP协议，就能被任何支持MCP的AI客户端调用。

这意味着什么？意味着你不再需要为每个AI平台单独写一套插件适配代码。你写一个MCP Server，ChatGPT能用，Claude能用，你本地的IDE助手能用，你公司内部搭建的AI工作流也能用。这才是真正值得关注的变化。

我之所以说“只有这一条值得看”，还有一个很实际的原因：MCP直接解决了AI落地过程中最痛的痛点——上下文获取。你想想，你平时用ChatGPT最抓狂的是什么？是不是每次都要手动复制粘贴代码、文档、数据？是不是它永远不知道你项目里有什么文件、数据库里有什么表、Jira上有什么任务？MCP就是来解决这个问题的。它让AI能够主动去“拿”它需要的信息，而不是被动等你“喂”。

所以这篇文章，我不打算把20多条更新挨个复述一遍。那些你随便搜搜就能看到。我想做的是，把MCP这条线彻底讲透——它是什么、为什么重要、怎么用、踩过哪些坑、有哪些实际场景能立刻上手。如果你是一个开发者、技术产品经理、或者任何想把AI真正接入自己工作流的人，这篇内容应该能帮你省下不少自己摸索的时间。

2. MCP到底解决了什么问题

2.1 从“手动喂数据”到“自动取上下文”的范式转变

在MCP出现之前，让AI访问外部信息主要有几种方式。第一种是复制粘贴，最原始但最常用，你把代码、文档、报错信息贴进对话框，AI基于这些内容回答。第二种是Function Calling，你在API调用时定义一些函数，模型判断需要调用哪个，然后返回一个结构化请求，你的代码去执行，再把结果传回去。第三种是Plugin，ChatGPT Plus用户可以用，但开发门槛高、审核周期长、生态一直不温不火。

这三种方式有一个共同的缺陷：它们都是“拉”模式，需要你主动发起。你得先知道要什么信息，然后手动或半自动地把它送到模型面前。但实际工作中，你往往不知道自己不知道什么。你问AI一个问题，它给出的答案不对，你才意识到“哦，它不知道我项目用的是RuoYi-Vue-Pro框架”。然后你再去补上下文，再问一遍。

MCP把这个逻辑反过来了。它是“推”和“拉”结合的模式。AI可以主动去查询它需要的信息。比如你问“帮我看看这个接口为什么报500”，支持MCP的AI客户端可以自动去读取你的项目文件、查看日志、查询数据库表结构，然后综合这些信息给出诊断。你不需要告诉它“去读哪个文件”，它自己会判断。

这背后的技术机制是：MCP Server会向客户端声明自己提供哪些“资源”和“工具”。资源是可读的数据，比如文件内容、数据库记录、API响应。工具是可执行的操作，比如查询、写入、发送请求。AI模型在推理过程中，如果判断需要某个资源或工具，就会发起调用请求，客户端执行后把结果返回给模型。整个过程对用户是透明的。

2.2 MCP与Function Calling的本质区别

很多人会把MCP和Function Calling混为一谈，觉得“不就是换个名字吗”。其实两者的设计哲学完全不同。

Function Calling是模型层面的能力。你在API请求里定义一堆函数签名，模型在生成回复时，如果觉得需要调用某个函数，就会输出一个特殊的结构化内容，包含函数名和参数。你的应用程序解析这个内容，执行函数，再把结果作为新一轮输入传给模型。整个流程是：你定义函数 → 模型选择函数 → 你执行函数 → 你传回结果。模型本身不执行任何操作，它只是“说”它想调用什么。

MCP是协议层面的标准。它定义的是客户端和服务器之间如何通信。MCP Server是一个独立运行的服务，它自己知道怎么执行操作、怎么读取数据。MCP Client（比如ChatGPT桌面端）连接到Server，获取Server的能力列表。当模型需要某个能力时，Client直接向Server发起请求，Server执行并返回结果。整个流程是：Server声明能力 → Client发现能力 → 模型请求能力 → Client调用Server → Server返回结果。

关键区别在于：Function Calling需要你的应用程序充当“执行者”，你得写代码去实现每个函数。MCP把执行逻辑封装在Server里，Client只需要知道“有这个能力”并转发请求。这意味着MCP Server可以被复用。你写一个查询PostgreSQL的MCP Server，任何支持MCP的客户端都能用，不需要每个客户端都重新实现一遍数据库查询逻辑。

还有一个重要区别：Function Calling是每次API调用时动态定义的，模型看到的是当前请求里的函数列表。MCP是持久化的，Server一旦连接，它的能力列表就一直在那里，模型可以随时调用。这更接近“工具包”的概念，而不是“临时借个工具”。

2.3 为什么开放协议比封闭生态更有生命力

OpenAI之前搞Plugin的时候，思路是“你来我这开店，我给你流量”。开发者要按OpenAI的规范写插件，提交审核，通过后才能在ChatGPT里用。这套模式的问题在于：审核周期长、规范变动频繁、开发者收益不明确。结果就是Plugin生态一直没起来，真正活跃的插件屈指可数。

MCP走的是另一条路：协议开源，谁都能实现。OpenAI不是MCP的发明者，Anthropic才是。但OpenAI选择拥抱这个协议，把它集成进自己的产品。这意味着什么？意味着MCP不是OpenAI的“私有财产”，它是一个行业标准。你写一个MCP Server，不仅ChatGPT能用，Claude能用，Cursor能用，Windsurf能用，你公司内部基于开源模型搭的AI助手也能用。

这种开放性带来的网络效应是巨大的。当足够多的工具和数据源都实现了MCP协议，AI客户端的选择就变成了“哪个模型更聪明”而不是“哪个平台有我要的插件”。对于开发者来说，你只需要维护一套MCP Server代码，就能覆盖所有主流AI客户端。对于用户来说，你不再被锁定在某个平台，可以自由切换。

我个人的判断是：MCP会成为AI应用层的“USB接口”。就像USB统一了外设连接标准，MCP会统一AI与外部工具的连接标准。现在可能还早，但方向已经很清楚了。

3. MCP的核心架构与工作原理

3.1 三个核心角色：Host、Client、Server

MCP的架构设计非常清晰，只有三个角色。

Host是运行AI模型的应用程序。比如ChatGPT桌面版、Claude Desktop、Cursor、你公司内部搭建的AI工作台。Host负责管理用户界面、调用模型、协调整个对话流程。

Client是Host内部的一个组件，负责与MCP Server建立连接、发送请求、接收响应。你可以把Client理解成Host的“外交官”，专门处理与外部Server的通信。一个Host可以同时连接多个Server，每个Server对应一个Client实例。

Server是提供能力和数据的服务。它可以是一个本地进程，比如读取你文件系统的工具；也可以是一个远程服务，比如查询公司数据库的接口。Server向Client声明自己提供哪些资源（Resources）和工具（Tools），然后等待Client的调用请求。

这三者的关系可以用一个生活场景来类比：Host是你家的智能音箱，Client是音箱的蓝牙模块，Server是你的手机。音箱通过蓝牙连接到手机，手机告诉音箱“我能播放音乐、能接电话、能查天气”。你对着音箱说“放首歌”，音箱通过蓝牙让手机执行播放操作。手机是能力的实际提供者，音箱是交互界面，蓝牙是通信协议。

3.2 Resources、Tools、Prompts：MCP的三种能力类型

MCP Server可以向Client声明三种类型的能力。

Resources是可读的数据源。比如文件内容、数据库查询结果、API返回的JSON、日志文件。Resources的特点是“只读”，模型可以读取它们来获取上下文，但不能通过Resources修改任何东西。Resources通常用URI来标识，比如file:///project/src/main.py或postgres://localhost/mydb/users。

Tools是可执行的操作。比如“查询数据库”、“发送HTTP请求”、“创建文件”、“运行命令”。Tools是模型可以主动调用的函数，它们可以产生副作用——修改数据、发送消息、触发流程。Tools的定义包括名称、描述、参数schema，模型根据这些信息判断何时调用、如何传参。

Prompts是预定义的提示模板。这个能力用得相对少，但很有用。Server可以提供一些常用的提示模板，比如“代码审查”、“SQL优化”、“日志分析”，用户可以直接选用，不需要自己从头写提示词。

这三种能力的组合，让MCP Server既能提供上下文（Resources），又能执行操作（Tools），还能引导交互（Prompts）。一个设计良好的MCP Server应该根据实际场景，合理分配这三种能力。

3.3 通信机制：基于JSON-RPC的双向通道

MCP的通信基于JSON-RPC 2.0。这是一个轻量级的远程调用协议，请求和响应都是JSON格式。选择JSON-RPC的原因很简单：简单、通用、容易实现。任何语言都能轻松处理JSON，不需要复杂的序列化框架。

通信的传输层支持两种方式：stdio和HTTP with SSE。stdio用于本地Server，Host启动Server进程，通过标准输入输出进行通信。这种方式简单直接，适合文件系统访问、本地命令执行等场景。HTTP with SSE用于远程Server，Client通过HTTP POST发送请求，Server通过Server-Sent Events推送响应和通知。这种方式适合跨网络访问，比如连接公司内部的API网关。

连接建立后，Client和Server会进行一次“能力协商”。Client发送initialize请求，包含自己的协议版本和客户端信息。Server返回自己的协议版本、Server信息、以及支持的能力列表。协商完成后，双方就可以开始正常的请求-响应交互了。

一个典型的交互流程是这样的：Client发送tools/list请求，Server返回所有可用工具的列表。模型在推理时决定调用某个工具，Client发送tools/call请求，包含工具名和参数。Server执行工具，返回结果。Client把结果传给模型，模型继续推理。

注意：MCP Server的能力列表是动态的。Server可以在运行时添加或移除工具，并通过notifications/tools/list_changed通知Client。这意味着你可以在不重启Host的情况下更新Server的能力。

4. 从零搭建一个MCP Server的完整实操

4.1 环境准备与依赖安装

我以Python为例，搭建一个最简单的MCP Server。你需要Python 3.10或更高版本，以及mcp这个官方SDK。安装命令很简单：

pip install mcp

如果你用Node.js，对应的包是@modelcontextprotocol/sdk。安装：

npm install @modelcontextprotocol/sdk

我建议先用Python版本上手，因为它的API设计更直观，文档也更全。等你熟悉了基本概念，再根据实际需求选择语言。

创建项目目录，初始化一个Python文件：

mkdir my-mcp-server cd my-mcp-server touch server.py

4.2 编写第一个MCP Server：文件读取工具

我们来写一个能读取本地文件内容的MCP Server。这个Server提供一个工具叫read_file，接受文件路径参数，返回文件内容。

import asyncio from mcp.server import Server from mcp.server.stdio import stdio_server from mcp.types import Tool, TextContent app = Server("file-reader") @app.list_tools() async def list_tools(): return [ Tool( name="read_file", description="读取指定路径的文件内容", inputSchema={ "type": "object", "properties": { "path": { "type": "string", "description": "文件的绝对路径" } }, "required": ["path"] } ) ] @app.call_tool() async def call_tool(name: str, arguments: dict): if name == "read_file": path = arguments["path"] try: with open(path, "r", encoding="utf-8") as f: content = f.read() return [TextContent(type="text", text=content)] except Exception as e: return [TextContent(type="text", text=f"读取失败: {str(e)}")] raise ValueError(f"未知工具: {name}") async def main(): async with stdio_server() as (read_stream, write_stream): await app.run(read_stream, write_stream, app.create_initialization_options()) if __name__ == "__main__": asyncio.run(main())

这段代码做了几件事：创建Server实例、注册工具列表、实现工具调用逻辑、通过stdio启动服务。@app.list_tools()装饰器告诉SDK这个函数返回可用工具列表。@app.call_tool()装饰器处理实际的工具调用。

4.3 在ChatGPT桌面端配置MCP Server

ChatGPT桌面端支持通过配置文件添加MCP Server。配置文件的位置根据操作系统不同：

• macOS:~/Library/Application Support/ChatGPT/config.json
• Windows:%APPDATA%\ChatGPT\config.json

如果你遇到“无法加载config.toml”或“无法加载此ChatGPT对话”的错误，通常是配置文件格式不对或路径写错了。ChatGPT桌面端用的是JSON格式，不是TOML。网上有些教程会混淆这两个格式，导致配置失败。

配置文件的内容如下：

{ "mcpServers": { "file-reader": { "command": "python", "args": ["/absolute/path/to/server.py"] } } }

把/absolute/path/to/server.py替换成你的实际路径。保存后重启ChatGPT桌面端。如果配置正确，你会在工具列表里看到read_file这个工具。

提示：路径一定要用绝对路径。相对路径在不同工作目录下会解析成不同的位置，导致Server启动失败。我踩过这个坑，排查了半天才发现是路径问题。

4.4 测试与验证：确认Server正常工作

重启ChatGPT后，你可以直接问它：“帮我读取一下 /path/to/some/file.txt 的内容”。如果一切正常，ChatGPT会调用read_file工具，返回文件内容。

如果没反应，按以下顺序排查：

1. 检查配置文件路径是否正确。不同版本的ChatGPT桌面端可能使用不同的配置目录。
2. 检查Python路径。command字段写python可能找不到，建议写完整路径，比如/usr/bin/python3。
3. 手动运行Server，看是否有报错。在终端执行python server.py，如果没有输出且不退出，说明Server正常启动。
4. 查看ChatGPT的日志。日志文件通常在配置目录下的logs文件夹里。

我实测下来，最常见的失败原因是Python环境问题。如果你用conda或venv，command字段需要指向虚拟环境里的Python，而不是系统Python。否则Server启动时找不到mcp包。

5. 进阶实战：把MCP接入真实工作流

5.1 数据库查询Server：让AI直接读你的表结构

文件读取只是热身。真正有用的是让AI能查询你的数据库。我以PostgreSQL为例，写一个MCP Server，提供两个工具：list_tables和query。

import asyncio import asyncpg from mcp.server import Server from mcp.server.stdio import stdio_server from mcp.types import Tool, TextContent app = Server("postgres-reader") DB_CONFIG = { "host": "localhost", "port": 5432, "database": "mydb", "user": "readonly_user", "password": "your_password" } @app.list_tools() async def list_tools(): return [ Tool( name="list_tables", description="列出数据库中所有表名", inputSchema={"type": "object", "properties": {}} ), Tool( name="query", description="执行只读SQL查询", inputSchema={ "type": "object", "properties": { "sql": {"type": "string", "description": "SELECT语句"} }, "required": ["sql"] } ) ] @app.call_tool() async def call_tool(name: str, arguments: dict): conn = await asyncpg.connect(**DB_CONFIG) try: if name == "list_tables": rows = await conn.fetch( "SELECT table_name FROM information_schema.tables WHERE table_schema='public'" ) result = "\n".join([r["table_name"] for r in rows]) return [TextContent(type="text", text=result)] elif name == "query": sql = arguments["sql"] if not sql.strip().upper().startswith("SELECT"): return [TextContent(type="text", text="只允许SELECT查询")] rows = await conn.fetch(sql) result = "\n".join([str(dict(r)) for r in rows]) return [TextContent(type="text", text=result)] finally: await conn.close() raise ValueError(f"未知工具: {name}") async def main(): async with stdio_server() as (read_stream, write_stream): await app.run(read_stream, write_stream, app.create_initialization_options()) if __name__ == "__main__": asyncio.run(main())

这个Server的关键设计点：使用只读账号。你绝对不应该给MCP Server一个能执行DELETE或DROP的数据库账号。AI可能会误解你的意图，生成危险的SQL。即使用户明确要求删除数据，也应该通过其他流程审批，而不是让AI直接执行。

另一个设计点是限制查询类型。我在代码里检查了SQL必须以SELECT开头。这能挡住大部分误操作，但不是万无一失的。更安全的做法是在数据库层面设置只读事务，或者用视图来限制可访问的数据范围。

5.2 与RuoYi-Vue-Pro等框架的集成思路

如果你在用RuoYi-Vue-Pro这类快速开发框架，MCP可以帮你做很多事情。比如：

• 让AI读取项目的代码生成器配置，自动生成CRUD代码
• 让AI查询系统菜单表，帮你梳理权限结构
• 让AI读取操作日志，分析异常请求
• 让AI查询定时任务表，检查任务执行状态

集成方式有两种。第一种是写一个通用的数据库查询Server，让AI直接查RuoYi的数据库表。这种方式灵活但风险高，需要严格控制权限。第二种是写专门的Server，封装RuoYi的API接口，AI通过调用API来获取信息。这种方式更安全，但需要额外开发。

我倾向于第二种方式。因为RuoYi的API已经做了权限校验和数据过滤，MCP Server只需要转发请求，不需要自己实现安全逻辑。而且API的返回格式是固定的，AI更容易理解。

5.3 多Server协同：构建你的AI工具矩阵

一个Host可以同时连接多个MCP Server。你可以把不同功能拆分成独立的Server：

• file-server：文件读写
• db-server：数据库查询
• git-server：Git操作
• jira-server：任务管理
• api-server：内部API调用

每个Server独立运行、独立配置、独立权限。这样做的好处是故障隔离。如果db-server挂了，不影响file-server的使用。而且你可以针对不同Server设置不同的安全策略，比如file-server只能读特定目录，db-server只能用只读账号。

配置多个Server的写法：

{ "mcpServers": { "file-reader": { "command": "python", "args": ["/path/to/file_server.py"] }, "db-reader": { "command": "python", "args": ["/path/to/db_server.py"] }, "git-tools": { "command": "node", "args": ["/path/to/git_server.js"] } } }

ChatGPT会自动发现所有Server的能力，并在需要时调用。你不需要手动指定用哪个Server，模型会根据工具描述自己判断。

6. 常见问题与排查技巧实录

6.1 配置类问题速查表

6.2 权限与安全：必须遵守的三条红线

MCP给了AI很大的权力。它能读你的文件、查你的数据库、调用你的API。如果不加限制，后果可能很严重。我总结了三条必须遵守的红线：

第一条：最小权限原则。给MCP Server的权限，只够它完成既定任务。文件Server只能读特定目录，数据库Server只能用只读账号，API Server只能调用必要的接口。不要图省事给root权限。

第二条：敏感操作必须二次确认。如果Server提供写操作（创建文件、修改数据、发送请求），应该在执行前要求用户确认。MCP协议本身支持这种交互模式，你可以在工具描述里说明“此操作会修改数据”，让模型在调用前询问用户。

第三条：日志审计不可少。每个MCP Server都应该记录所有调用请求和结果。出了问题能追溯，平时也能分析AI的使用模式。日志里不要记录敏感数据，比如密码、密钥、个人隐私信息。

6.3 性能优化：减少不必要的上下文传输

MCP Server返回的数据会作为上下文传给模型。如果返回内容太大，会消耗大量token，增加成本，还可能超出模型的上下文窗口。几个优化技巧：

• 分页返回。查询数据库时加LIMIT，不要一次返回几万行。
• 摘要优先。先返回摘要信息，模型需要详情时再调用另一个工具获取。
• 过滤无关字段。数据库查询时只SELECT需要的列，不要SELECT *。
• 压缩文本。如果返回的是代码或日志，可以去掉空行和注释，减少体积。

我实测过一个案例：查询一个有5000行记录的表，不加LIMIT直接返回，消耗了约15万token，直接超出模型限制。加上LIMIT 100后，token消耗降到3000左右，完全在可接受范围内。

6.4 调试技巧：如何快速定位Server问题

MCP Server的调试比普通程序麻烦，因为它运行在Host内部，你看不到它的输出。几个实用的调试方法：

方法一：写日志到文件。在Server代码里加日志记录，把关键信息写到文件里。比如：

import logging logging.basicConfig( filename="/tmp/mcp-server.log", level=logging.DEBUG, format="%(asctime)s - %(levelname)s - %(message)s" )

方法二：用MCP Inspector。这是官方提供的调试工具，可以模拟Client连接Server，查看能力列表、手动调用工具、查看返回结果。安装：

npx @modelcontextprotocol/inspector python server.py

方法三：单独测试工具逻辑。把工具的实现逻辑抽成独立函数，写单元测试。这样可以在不启动MCP Server的情况下验证功能是否正确。

提示：如果你在Windows上遇到“该进程没有程序包标识符”的错误，通常是ChatGPT桌面版的安装问题。尝试重新安装最新版本，或者用管理员权限运行。这个问题和MCP配置无关，是桌面端本身的bug。

7. MCP在实际场景中的落地案例

7.1 代码审查助手：自动读取项目文件并给出建议

我搭建了一个MCP Server，提供list_files、read_file、search_code三个工具。配置到ChatGPT桌面端后，我可以直接说：“帮我审查一下src/main/java/com/example/service/目录下的代码，看看有没有潜在问题。”

ChatGPT会自动调用list_files获取目录下的文件列表，然后逐个调用read_file读取内容，最后综合所有文件给出审查意见。整个过程不需要我手动复制任何代码。

这个场景的关键在于工具描述的准确性。list_files的描述要说明它返回文件名列表，read_file要说明它返回文件内容，search_code要说明它支持正则搜索。描述越清晰，模型越能正确选择工具。

7.2 运维排查：让AI直接查日志和监控数据

运维场景下，MCP可以大幅缩短排查时间。我配置了一个Server，提供query_logs、get_metrics、list_alerts三个工具。当告警触发时，我直接问ChatGPT：“过去一小时order-service的错误日志有哪些？”

ChatGPT调用query_logs，传入服务名和时间范围，Server查询日志系统返回结果。ChatGPT分析日志内容，提取关键错误信息，给出可能的原因和排查建议。整个过程从原来的十几分钟缩短到一两分钟。

这个场景的难点在于日志格式的解析。不同服务的日志格式不同，Server需要做归一化处理，把日志转成模型容易理解的格式。我的做法是提取时间戳、日志级别、服务名、错误码、错误消息这几个关键字段，其他内容截断。

7.3 数据分析：用自然语言查询数据库

这是MCP最直观的应用场景。配置好数据库Server后，你可以直接问：“上个月销售额最高的十个产品是哪些？”ChatGPT会生成SQL，调用query工具执行，然后格式化结果返回给你。

这个场景的挑战在于SQL生成的准确性。模型需要知道表结构、字段含义、关联关系。我的做法是在Server里提供一个get_schema工具，返回所有表的DDL和字段注释。模型在生成SQL前会先调用这个工具获取schema信息。

另一个挑战是数据安全。我严格限制了可查询的表范围，敏感表（用户密码、支付信息）完全不允许访问。查询结果也会做脱敏处理，比如手机号中间四位用星号代替。

8. 我对MCP未来发展的几个判断

MCP现在还在早期阶段，但方向已经很明确了。我的几个判断：

第一，MCP会成为AI应用的基础设施。就像HTTP协议支撑了Web，MCP会支撑AI与外部世界的交互。未来你评估一个AI产品，会看它支持哪些MCP Server，而不是看它内置了哪些插件。

第二，MCP Server的市场会起来。现在已经有人在做MCP Server的聚合平台，类似“应用商店”的概念。你可以订阅别人写好的Server，连接你的数据库、你的API、你的工具。这会催生一个新的开发者生态。

第三，安全会成为最大的挑战。MCP给了AI太多权力，如何审计、如何限制、如何防止提示注入攻击，这些问题还没有标准答案。我预计未来会出现专门的MCP安全网关产品，做权限控制、流量审计、内容过滤。

第四，国内生态会跟进。虽然OpenAI和Anthropic是先行者，但国内的大模型厂商和AI应用开发者已经在关注MCP。我了解到一些团队在内部实现类似的协议，或者直接兼容MCP。这个趋势不可逆。

如果你现在开始学MCP，投入产出比很高。它不像学一个新框架那样需要大量时间，核心概念一两天就能掌握。但它的应用范围很广，几乎任何需要AI访问外部信息的场景都能用上。我建议你先从最简单的文件读取Server开始，跑通整个流程，然后根据实际需求逐步扩展。踩几个坑之后，你就知道怎么设计好用的MCP Server了。