★ FEATURED ARTICLE 1. 这场发布会真正的主角不是模型而是协议DevDay 结束那天晚上我刷了一圈技术社区满屏都是“20 多项更新汇总”“GPTs 商店上线”“Assistants API 来了”。说实话这些东西重要但它们都是“果”不是“因”。真正让我从椅子上坐直了的那一条是MCPModel Context Protocol相关的动作——OpenAI 开始把“模型怎么连接外部世界”这件事从各家自己造轮子往一个统一协议上收。我先说结论如果你只关心“ChatGPT 又多了什么功能”那这 20 条你随便看看就行但如果你在写代码、做工具、搭工作流那 MCP 这一条决定了你未来半年到一年的技术选型方向。它解决的不是“模型聪不聪明”的问题而是“模型能不能稳定、可复用、低摩擦地调用你手头那些工具和数据”的问题。我自己是从 Plugin 时代一路踩过来的。早期 ChatGPT Plugin 出来的时候我兴致勃勃写了一个内部知识库查询插件结果发现鉴权链路绕、调试靠猜、不同平台各写一套。后来 Function Calling 出来好了一点但每个模型厂商的 schema 格式、调用约定都不一样你给 A 平台写的工具描述搬到 B 平台就得改。MCP 想干的就是把这一层标准化——工具提供方按一个协议暴露能力模型侧按一个协议去发现和调用中间不用再为每个宿主单独适配。这篇文章我不打算复述那 20 条更新清单网上到处都是。我想做的是把 MCP 这条线拆开讲清楚它为什么重要、核心机制是什么、实际怎么落地、以及我在实操里踩过的坑。适合三类人看一是正在做 AI 工具集成的开发者二是想把内部系统接进对话式入口的工程团队三是单纯想搞明白“MCP 到底是什么、跟我有什么关系”的技术爱好者。哪怕你之前只听过这个词看完应该能自己动手跑通一个最小示例。2. 为什么偏偏是 MCP 值得单独拎出来讲2.1 从 Plugin 到 Function Calling 再到 MCP 的演进逻辑要理解 MCP 的价值得先看清楚前面两代方案卡在哪。第一代是 Plugin。它的思路是“给 ChatGPT 装 App”。你写一个插件声明一个ai-plugin.json描述你的 APIChatGPT 就能调用。听起来很美但实际用起来问题一堆插件必须公网可访问、鉴权方式受限、manifest 格式死板、调试基本靠日志猜。更致命的是它是ChatGPT 专属的你为它写的东西换个模型宿主就废了。我当时写那个知识库插件光是把 OAuth 流程跑通就花了两天最后发现 token 刷新还有坑。第二代是 Function Calling。这个进步很大它把“工具调用”抽象成了模型输出结构化 JSON由宿主程序去执行。你不再需要公网暴露服务本地函数也能被调用。但它的问题在于每个厂商的 schema 和调用约定都不一样。OpenAI 一套、Anthropic 一套、国内各家又一套。你写了一个查天气的工具想同时接三个平台就得维护三份描述。而且工具发现是静态的——你得在请求里把所有工具定义塞进去工具一多prompt 就被撑爆。第三代就是 MCP。它的核心洞察是工具不应该绑定到某个模型或某个宿主而应该像 USB 设备一样插上就能用。MCP 定义了一套客户端-服务端协议工具提供方跑一个 MCP Server宿主比如 IDE、桌面客户端、命令行工具作为 MCP Client 去连接它动态发现能力、按需调用。模型侧只负责“决定调什么”协议侧负责“怎么调、怎么传参、怎么回传”。这个演进逻辑其实很清晰Plugin 解决“能不能接”Function Calling 解决“接得顺不顺”MCP 解决“接得通不通用”。前两代是功能MCP 是基础设施。2.2 MCP 到底解决了谁的痛点我把它拆成三个角色来看每个角色的痛点都不一样。对工具开发者来说最大的痛点是“重复适配”。你写了一个数据库查询工具想让它能被各种 AI 客户端用以前得为每个客户端写适配层。MCP 之后你只写一个 Server任何支持 MCP 的 Client 都能连。这是一次开发、多处复用。对 AI 应用开发者来说痛点是“工具生态碎片化”。你想给自己的应用加能力要么自己写要么找现成的但现成的往往格式不兼容。MCP 之后你可以直接接入社区里现成的 MCP Server比如文件系统、数据库、浏览器自动化、甚至某些专业软件我看到热词里有 IDA、Altium Designer、Unreal 相关的 MCP 插件说明这个生态已经在往专业工具渗透了。对终端用户来说痛点是“配置复杂”。以前接一个工具要填 API Key、配环境变量、改配置文件一步错就报错。MCP 的配置相对统一很多客户端支持一键添加 Server配置文件格式也趋同。热词里那个“chatgpt 无法加载 config.toml”其实就反映了这个阶段——配置成了新的门槛但至少格式在收敛。提示MCP 不是银弹。它解决的是“连接标准化”不解决“模型会不会用工具”的问题。工具描述写得烂再标准的协议也救不了调用准确率。2.3 一个生活化类比MCP 就是 AI 世界的 USB-C我用一个类比帮你记住 MCP 的定位。以前每个设备有自己的充电口诺基亚圆口、苹果 30 pin、micro USB、mini USB出门得带一把线。后来 USB-C 统一了一根线走天下。MCP 就是 AI 工具连接领域的 USB-C。MCP Server 你的设备鼠标、硬盘、显示器MCP Client 你的电脑提供 USB-C 接口MCP 协议 USB-C 接口规范针脚定义、供电标准、数据传输协议你不需要知道鼠标内部怎么工作插上就能用。同样AI 客户端不需要知道你的数据库怎么连按 MCP 协议问一句“你能干什么”Server 返回能力列表然后按需调用。这个“能力发现”机制是 MCP 比 Function Calling 更优雅的地方——工具是动态发现的不是静态塞进 prompt 的。3. MCP 核心机制拆解三个原语和一次握手3.1 三个核心原语Tools、Resources、PromptsMCP 把服务端能提供的东西分成三类这个分类很关键理解错了后面全乱。Tools工具是最常用的就是“可以被模型调用的函数”。比如query_database、send_email、run_shell_command。它有明确的输入 schema 和输出。模型决定要不要调、传什么参。Resources资源是“可以被读取的数据”。比如一个文件、一条数据库记录、一个 API 返回的 JSON。它和 Tools 的区别是Resources 是被动读取的Tools 是主动执行的。你可以把 Resources 理解成“给模型看的资料”Tools 理解成“让模型做的动作”。Prompts提示模板是“预定义的提示词模板”服务端可以提供一些常用的 prompt 片段客户端可以选用。这个用得相对少但在一些标准化场景比如代码审查、日志分析里很有用。我一开始只关注 Tools后来发现 Resources 在处理“让模型读一批文件再回答”这类场景时特别顺手。你不用把文件内容塞进对话而是让模型通过 Resource 去读上下文更干净。3.2 通信流程从 initialize 到 callMCP 的通信流程可以简化成四步我用一个查数据库的例子串起来。第一步握手initialize。Client 连上 Server双方交换协议版本、能力声明。Server 告诉 Client“我支持 Tools 和 Resources”Client 告诉 Server“我支持采样和根目录”。这一步确定了双方能聊什么。第二步能力发现list。Client 问“你有哪些 Tools”Server 返回一个列表每个 Tool 带名字、描述、输入 schema。Client 把这些信息整理后交给模型。注意这一步是动态的Server 可以随时增减工具Client 下次 list 就能看到。第三步调用call。模型决定调用某个 ToolClient 把调用请求发给 ServerServer 执行后返回结果。结果可以是文本、JSON、甚至图片。第四步回传与继续。Client 把结果喂回模型模型基于结果继续推理可能再调下一个 Tool直到任务完成。这个流程里最关键的是第二步的动态发现。Function Calling 时代你得在每次请求里把所有工具定义塞进 system prompt工具一多就爆 token。MCP 把工具定义放在协议层模型只在需要时看到相关工具上下文利用率高很多。3.3 传输层stdio 和 SSE 两种模式MCP 支持两种传输方式选错了会踩坑。stdio标准输入输出是最常用的Server 作为子进程启动Client 通过 stdin/stdout 通信。优点是简单、无需网络、适合本地工具。缺点是 Server 必须和 Client 在同一台机器上。我本地跑的文件系统 Server、数据库 Server 都是 stdio 模式。SSEServer-Sent Events是远程模式Server 跑在某个地址上Client 通过 HTTP 连接。优点是跨机器、可共享。缺点是要处理网络、鉴权、断线重连。如果你要把内部系统暴露给团队用SSE 更合适。注意stdio 模式下Server 的日志千万不能往 stdout 打会污染协议数据。要打日志就打到 stderr 或文件。我因为这个坑调试了半小时一直以为协议有问题结果是 Server 里一句print把 JSON-RPC 消息冲乱了。4. 动手实操从零跑通一个最小 MCP Server4.1 环境准备与依赖选择我用 Python 来演示因为官方 SDK 成熟社区示例多。你需要Python 3.10 以上3.10 是因为 SDK 用了一些新语法mcp官方 SDKpip install mcp一个支持 MCP 的 Client我推荐先用命令行工具或桌面客户端测试如果你用 Node.js官方也有modelcontextprotocol/sdk思路一样。选 Python 是因为它的类型提示和 schema 生成更顺手。我建议先用 stdio 模式跑通本地确认逻辑没问题再考虑 SSE。很多人一上来就搞远程结果网络问题、鉴权问题混在一起根本不知道错在哪。4.2 写一个查询本地 SQLite 的 Server我写一个最小但完整的例子一个能查询 SQLite 数据库的 MCP Server。这个场景很实用很多内部系统就是 SQLite 或类似的小型库。import sqlite3 import asyncio from mcp.server import Server from mcp.server.stdio import stdio_server from mcp.types import Tool, TextContent app Server(sqlite-query-server) DB_PATH ./demo.db app.list_tools() async def list_tools(): return [ Tool( namequery, description执行一条只读 SQL 查询返回结果。仅支持 SELECT 语句。, inputSchema{ type: object, properties: { sql: { type: string, description: 要执行的 SELECT SQL 语句 } }, required: [sql] } ) ] app.call_tool() async def call_tool(name: str, arguments: dict): if name ! query: raise ValueError(f未知工具: {name}) sql arguments[sql].strip() if not sql.lower().startswith(select): return [TextContent(typetext, text只允许 SELECT 查询)] conn sqlite3.connect(DB_PATH) try: cur conn.execute(sql) rows cur.fetchall() cols [d[0] for d in cur.description] result [dict(zip(cols, row)) for row in rows] return [TextContent(typetext, textstr(result))] finally: conn.close() async def main(): async with stdio_server() as (read, write): await app.run(read, write, app.create_initialization_options()) if __name__ __main__: asyncio.run(main())这段代码有几个点值得说。第一list_tools返回的是工具定义。注意inputSchema用的是 JSON Schema 标准模型侧就是靠这个理解参数格式的。描述要写清楚尤其是“仅支持 SELECT”这种约束写在 description 里能显著降低模型乱调的概率。第二call_tool里做了二次校验。即使 description 说了只读代码里还是检查了select前缀。永远不要信任模型会遵守描述安全边界必须在代码里兜底。这是我从实际项目里学到的血泪教训——你永远不知道模型会生成什么 SQL。第三返回的是TextContent列表。MCP 支持多种内容类型文本是最常用的。你也可以返回图片、嵌入资源等。4.3 配置到客户端并验证写完之后你需要在客户端里配置这个 Server。不同客户端配置格式略有差异但核心都是命令、参数、环境变量。以常见的配置文件为例很多客户端用类似的 JSON 结构{ mcpServers: { sqlite-query: { command: python, args: [/path/to/server.py], env: { DB_PATH: /path/to/demo.db } } } }配置完重启客户端你应该能在工具列表里看到query。然后试着问一句“帮我查一下 users 表里有多少条记录”看模型会不会调用。提示如果工具没出现先检查 Server 能不能独立跑起来直接python server.py看有没有报错再检查路径是不是绝对路径。相对路径在客户端启动 Server 时经常出问题因为工作目录不一定是你以为的那个。我第一次配的时候工具死活不出现排查了半天发现是 Python 环境不对——客户端用的是系统 Python而我的依赖装在虚拟环境里。配置里最好写虚拟环境里的 Python 绝对路径别偷懒。5. 进阶玩法把 MCP 接进真实工作流5.1 多 Server 协同文件 数据库 浏览器单个 Server 只是玩具真正有意思的是多个 Server 协同。我现在的日常配置里有三个文件系统 Server读写本地项目文件SQLite Server查本地数据浏览器自动化 Server抓取网页、填表单当模型同时拥有这三个能力时它能做的事情就上了一个台阶。比如你说“把这个项目的 README 读一下然后去官网查最新版本对比一下有没有更新”它会先调文件 Server 读 README再调浏览器 Server 查官网最后综合回答。这里的关键是工具描述要清晰区分职责。如果文件 Server 和浏览器 Server 的描述都含糊模型会调错。我的经验是每个工具的 description 里明确写“什么时候用我”而不是只写“我能干什么”。5.2 用 MCP 把内部系统接进对话入口这是我觉得 MCP 最有商业价值的地方。很多公司内部有一堆系统工单系统、监控系统、部署系统。以前要让 AI 用上这些得一个个写适配。现在只要给每个系统写一个 MCP Server就能统一接进任何支持 MCP 的客户端。我帮一个团队做过类似的事把他们的部署系统包了一个 MCP Server暴露list_deployments、trigger_deploy、rollback三个工具。然后接进他们日常用的对话客户端。效果是以前查部署状态要登系统点半天现在直接问一句就行。但这里有个权限设计的坑。trigger_deploy这种写操作一定要加确认机制。我的做法是Server 里对写操作返回一个“待确认”状态需要用户在对话里明确说“确认”才真正执行。不要让模型直接触发不可逆操作这是底线。5.3 流式输出与长任务处理热词里有个“使用 mcp 工具流式输出内容到文件”这个场景很实际。有些工具执行时间长比如跑一个分析脚本你希望边执行边看到输出。MCP 本身支持流式返回但需要 Server 和 Client 都正确处理。我的做法是Server 里把长任务拆成多个进度事件通过TextContent分批返回。Client 侧要支持增量渲染否则用户会以为卡死了。注意流式输出时错误处理要格外小心。如果任务中途失败要确保已经输出的部分不会让用户误以为成功了。我一般会在最后追加一个明确的“完成/失败”标记。6. 常见问题与排查技巧实录6.1 配置类问题速查现象可能原因排查方法工具列表为空Server 启动失败手动运行 Server 命令看报错报 config.toml 加载失败配置文件格式错误用 JSON 校验工具检查语法连接后立即断开stdout 被日志污染检查 Server 里有没有 print工具调用超时Server 阻塞在主线程确认用了 async耗时操作放线程池中文乱码编码未指定确保 stdin/stdout 用 UTF-8这个表是我踩坑踩出来的。尤其是“stdout 被污染”那条新手几乎必踩。MCP 用 stdout 传协议数据你任何一句调试 print 都会破坏消息格式表现就是“连接成功但立刻断开”非常迷惑。6.2 调用准确率低的三个原因模型调错工具通常不是模型笨是描述没写好。我总结三个常见原因第一工具描述太笼统。“查询数据”这种描述模型根本不知道查什么、怎么查。要写成“查询 SQLite 数据库中的用户表支持按姓名和注册时间过滤”。第二工具之间职责重叠。如果你有两个工具都能“获取信息”模型会随机选。要么合并要么在描述里明确边界。第三参数 schema 不清晰。参数名用arg1、arg2模型只能猜。用user_name、start_date这种自解释的名字准确率立刻上去。6.3 安全边界必须自己兜底我再强调一次MCP 协议不负责安全安全是你的责任。文件系统 Server 要限制可访问目录别把根目录暴露出去数据库 Server 要限制只读或者对写操作加白名单执行命令的 Server 要极其谨慎最好只允许预定义的命令模板所有涉及敏感数据的返回要考虑脱敏我见过有人直接把 shell 执行包成 MCP Server然后接进对话客户端。这等于把机器完全交出去了。便利性和安全性永远要权衡涉及写操作和敏感数据时宁可多一步确认。7. 我对 MCP 生态接下来走向的判断从这次 DevDay 释放的信号看MCP 正在从“社区自发”走向“平台支持”。这意味着两件事一是会有更多官方和第三方 Server 涌现二是客户端支持会越来越普遍。我个人的判断是接下来半年到一年MCP 会经历一个“工具爆炸”阶段——各种系统都会有人包 Server。然后会进入“质量分化”阶段——描述写得好、安全做得好的 Server 留下来粗糙的被淘汰。再往后可能会出现“Server 市场”或“Server 注册中心”这类东西让发现和安装更简单。对开发者来说现在是个不错的入场时机。协议还在演进但核心已经稳定早写早积累。对普通用户来说可以先从现成的 Server 用起感受一下“对话即操作”的体验再考虑自己动手。我自己的下一步是把手头的几个内部工具都包成 MCP Server统一接进日常客户端。踩过的坑已经够多了现在写起来顺手不少。如果你也在做类似的事欢迎交流——尤其是安全边界这块我觉得整个社区都还在摸索多分享踩坑经验比什么都实在。
阅读完成 · 觉得有帮助？
