如果说 2024 年大家还在讨论怎么让 AI 更好地聊天那 2025 年几乎所有团队都在讨论怎么让 AI 真正干活。干活意味着模型不再只是生成文字而是要主动去读文件、查数据库、操作浏览器、读取设计稿、调用内部系统。这时候就会出现一个非常实际的工程问题每接一个新工具都要重写一遍对接逻辑。我见过很多团队在同一个项目里给不同的工具写不同的 prompt、自定义接口、临时脚本工具一旦换掉整套 prompt 和代码全部作废。MCPModel Context Protocol模型上下文协议就是在这个背景下出现的。它的目标如果用一句话说不是让模型变得更聪明而是让模型连接工具的方式从“私有定制”变成“标准插座”。这篇文章想聊清楚一个看起来基础但很多人还没真正理解的问题为什么我们需要 MCP而不是继续靠 prompt 或者 function calling 一路写到底。1. 先理解 MCP 解决的是哪一类混乱1.1 在 MCP 之前AI 应用是怎么接工具的在 MCP 被广泛讨论之前AI 应用接入外部能力通常有三条路。第一种是自己写胶水代码。比如要接数据库就写一个 Python 脚本把 SQL 查询结果转成文本塞进 prompt。要接 Figma就调 Figma API把图层数据拉下来整理成 JSON。这种方式能跑通但每接一个数据源就要写一套新的解析逻辑而且这套逻辑往往只属于当前项目换一个客户端、换一个模型就要重写。第二种是依赖模型的函数调用能力。以 OpenAI 的 function calling 为例开发者需要在请求里传入一个 tools 列表定义每个函数的参数 schema模型根据用户的输入决定调用哪个函数然后你拿到函数名和参数再去执行。这个方案比起裸写 prompt 已经规范很多但仍然有一个无法回避的问题工具的发现和注册完全靠开发者在代码里手动维护。每新增一个工具就要改代码、发版、更新 schema。工具数量一多维护成本迅速上升。第三种是干脆把工具的用法写进 prompt。让模型“知道”有某个工具然后期望模型在合适的时候按照格式输出调用指令。这种方式对小规模实验很灵活但它本质上是在用提示词工程对抗工具复杂度。当工具参数特别多、返回结果特别长、状态来回切换的时候这种方案会变得不可控。1.2 MCP 的真正切入点不是能力是标准化MCP 要解决的问题不是“模型能不能调用工具”而是“工具应该如何被模型调用”。你可以把 MCP 理解为 AI 应用和外部工具之间的一层统一协议。它规定了工具提供方要如何暴露能力、工具使用方要如何发现和调用这些能力、数据响应要用什么格式返回。这样一来同一个 MCP server 可以被任何支持 MCP 的客户端使用同一个客户端也可以接入任意符合协议的 server。这才是 MCP 的关键价值。它没有发明“让 AI 调用工具”这件事它发明的是“让所有工具用同一种方式被 AI 调用”的约定。就像 USB 之前各种外设都有自己的接口游戏手柄有游戏手柄的接口鼠标有鼠标的接口打印机有打印机的接口。MCP 的目标是以后 AI 要接任何设备只需要认准同一个协议。所以如果只看单一场景你完全可以不用 MCP。你自己写一段脚本调一个 API速度更快、依赖更少。但当你面对的是十几个工具、多个客户端、不断新增的业务系统时没有标准就意味着每一次接入都是一次新的集成开发。1.3 一个最小体系里的三个角色理解 MCP 之前先把三个角色弄清楚。Host运行 AI 应用的宿主程序。常见的就是 Claude Desktop、Codex、Cline、各类 IDE 插件。它负责持用户会话、调用模型、展示结果。Client在 Host 内部建立与 MCP server 连接的客户端。它负责维护连接、发送请求、接收响应。通常一个 Host 会内嵌一个或多个 Client。Server真正的工具提供方。它把文件系统、数据库、设计稿、浏览器、任务追踪系统等能力封装成标准接口向外暴露。Server 和 Client 之间通过 MCP 协议通信。协议内容不是自然语言而是结构化的 JSON-RPC 消息。Server 可以运行在本地也可以部署在远程服务器上。本地运行最常见的启动方式是通过命令行拉起一个子进程使用 stdio 通信远程服务则通常使用 HTTP 或 SSE。一个常见的误解是MCP Server 必须很复杂必须用某个特定框架。其实它只是一个轻量进程负责把工具能力包一层标准接口。真正复杂的是 Server 背后的业务逻辑比如怎么安全地操作文件、怎么查询数据库这些才是工程重心。2. MCP 的设计逻辑它像 AI 世界的 USB-C2.1 三种原语Tools、Resources、PromptsMCP 协议中心不是一堆复杂配置而是三个核心原语。Tools 是最直观的能力单位。它对应一个可执行的动作比如“读取某个 Figma 文件”、“执行某条 SQL”、“点击浏览器里的某个按钮”、“发布一条 Jenkins 构建”。模型可以在对话过程中主动决定调用这些工具调用时需要按照 server 定义的输入 schema 传入参数执行完成后拿到结构化结果。Resources 是数据源。它代表可读取的内容比如一个文件、一张表、一个设计稿节点、一份日志。和 Tools 的区别在于Resources 通常是“只读的数据”不需要让模型执行副作用操作。客户端可以把 Resources 内容直接作为上下文传给模型相当于把外部数据“粘”进对话。Prompts 是可复用的提示模板。它用于把某个任务的执行方式固化成标准流程。比如服务器可以提供一个 “review 设计稿” 的 prompt 模板客户端拿到后会把这段指令和相关的 resource 一起组合成上下文。这三个原语合起来其实覆盖了 AI 应用最常见的三类需求读数据、执行动作、按既定流程处理任务。这也是 MCP 和单纯的 function calling 体系之间一个很重要的差异。function calling 基本只解决“模型发起一个调用”的问题而 MCP 把可发现能力、数据读取、模板治理一起做了。2.2 两种传输方式stdio 和 HTTPMCP 在实际部署中主要有两种传输方式选择方式会影响使用体验和运维复杂度。stdio 方式最常见于本地开发场景。客户端启动一个子进程比如npx某个 server 包然后通过标准输入输出和这个进程通信。好处是配置简单不需要开端口、不需要处理网络攻击面tool server 和 AI 客户端在同一个机器上权且只对本机操作可见。缺点是 server 必须能在这台机器上跑起来而且无法直接服务多个远程用户。HTTP/SSE 方式用于远程 server。比如团队里部署一个统一的 MCP server供多人使用。这种方式把工具能力变成网络服务可以集中管理权限、日志、更新策略。但同时要处理认证、限流、超时、TLS 等一系列网络问题复杂度比本地 stdio 高不少。从实际落地看先跑本地 stdio server 是体验 MCP 最快速的方式。很多团队一开始也会把 shared server 先在本机验证再部署到内网。不要一上来就架远程服务否则排查问题时多了一层网络故障变量。2.3 工具发现机制为什么是关键一个经常被忽略但极其重要的设计是 “tools/list” 这类能力发现机制。传统 function calling 方案里工具列表是开发者硬编码在请求参数里的模型只知道代码里给它的那些函数。MCP 则不同server 可以动态地声明自己提供哪些工具、每个工具的参数 schema 是什么、需要什么权限。客户端启动时先向 server 发送工具列表请求拿到全部可调用工具后再决定后续怎么路由。这种动态发现机制带来的变化是新增一个工具只需要改 server 而不需要改客户端。比如同一个 MCP server 今天提供了一个查询工具明天又加了一个写入工具AI 客户端启动后自动感知不需要重新发布客户端版本。对于有大量工具、频繁上线的团队来说这是非常重要的工程收益。所以 MCP 的价值可以总结成一句话它把 AI 应用和工具之间的耦合度从“代码级绑定”降到了“协议级发现”。这也是为什么很多人形容它像一个标准插座插上就能用不用管内部是显示器还是硬盘。3. MCP 和 Function Calling、Skill 不是一回事3.1 MCP 与 Function Calling一个关于插座一个关于供电很多人会把 MCP 和 function calling 混在一起甚至以为两者是对立关系。理解它们最简单的方式是function calling 是模型侧的能力MCP 是工具侧的连接协议。function calling 解决的是模型如何在生成回复的过程中决定调用一个函数并输出结构化的参数。它是由模型提供商定义的 API 特性。比如 OpenAI、Anthropic、Google 各自的 function calling 格式就不完全一致。MCP 解决的是工具如何被 AI 客户端发现、连接和调用。它不关心模型具体怎么决策它只保证工具在协议层面用统一的方式暴露。所以你可以用 MCP 来替换掉项目里手工维护 function schema 的那部分工作。尤其是当你同时接 Anthropic、OpenAI、本地模型等多个模型时MCP 能帮你把工具层抽象成一份避免为每个模型各写一套 function 描述。3.2 MCP 与 Skill一个是能力接口一个是使用说明书最近很多平台都在提 Skill比如 Claude 的 Agent Skill或者各类 Agent 框架里的技能概念。于是出现了大量搜索“agent skill 和 mcp 有什么区别”的人。Skill 的核心是“怎么做”它把完成某个任务所需的指令、步骤、判断逻辑、可能用到的工具调用方法封装成一份可复用的知识包。比如一个 “代码 review skill”会告诉模型应该先看 diff、再检查是否有安全风险、最后按什么格式输出意见。它更多是在 prompt 层操作。MCP 的核心是“能做什么”它提供一个工具能力的外部入口。它不承诺模型会怎么用这个工具也不负责教你“什么时候该用这个工具、用完后怎么整理结果”它只负责让这个工具能被标准调用。所以两者完全不是替代关系。MCP 把工具变成可以插拔的电源插座Skill 更像一本设备使用手册。真正完整的 Agent 工作流通常是Skill 指导模型接下来该怎么处理任务MCP 在执行过程中提供能力调用。我见过很多团队一开始只做 MCP给模型塞了一堆工具结果模型经常在错误的时机调用。后来又补了 Skill 来框定流程效果才稳定下来。原因就是光有工具没有流程Agent 很容易像第一次进厨房的人什么厨具都有但不知道先开火还是先切菜。3.3 一个组合使用框架如果你正在设计一个接入 AI 的完整工具方案可以按这个顺序判断如果你的需求是 “模型要能执行某个动作”优先考虑 MCP Server 提供 Tools。如果你的需求是 “模型要把某些外部数据读进上下文”优先考虑 MCP Server 提供 Resources。如果你的需求是 “按固定流程处理一类任务不希望每次重新写指令”优先考虑 Skill 或 MCP Prompts。如果你的需求是一次性实验、只调一个私有 API直接写几行代码可能比引 MCP 更快。这个框架不算发明但它能避免一个常见误区遇到 Agent 工具化什么都往里塞 MCP。适不适合用 MCP关键看“这个工具是否会被多个客户端复用”、“是否存在长期维护成本”、“是否需要统一的能力发现和变更机制”。如果三个问题都是否那 MCP 就有点杀鸡用牛刀了。4. 从 Figma MCP、Playwright MCP 看真实落地价值4.1 为什么设计稿、浏览器、数据库是最先爆发的场景如果你去看当前热门的 MCP server 清单会发现几个反复出现的品类Figma MCP、Playwright MCP、数据库类的 MCP比如 Chat2DB 这类把数据库能力暴露给 AI 的服务、文件系统 MCP、DevOps 类 MCP。这些场景有一个共同点它们的操作对象是结构化的、机器可读的。拿 Figma 举例。前端工程师拿到设计稿后要反复查看颜色、间距、组件命名、切图资源。过去让 AI 帮忙理解设计稿你需要手动把截图发给它或者写脚本去调 Figma 的 REST API。而 Figma MCP server 把“读取设计稿节点”、“获取样式信息”、“查找图层”等能力封装成 ToolsAI 客户端可以直接调用。整个链路变成AI 通过 MCP server 读取设计稿数据再结合前端代码生成需求输出可落地的修改建议。Playwright MCP 的思路也类似。它把浏览器自动化能力暴露给模型模型可以自己打开页面、点击按钮、读取控制台日志、截图。这对自动化测试、页面回归、Bug 复现场景很有价值因为原本需要人逐步操作浏览器验证的事情现在可以由模型按步骤执行。数据库类的 MCP 则更直接它把 SQL 查询能力封装成工具AI 可以根据用户的自然语言描述生成并执行查询。不需要再把查询结果复制粘贴进对话。4.2 常见落地形态读取数据 vs 执行操作使用 MCP 时要区分两类工具一类是只读型工具。比如读取设计稿、查询数据库、获取文件内容。这类工具相对安全模型调用后只产生读取行为风险主要是数据暴露范围。另一类是写操作型工具。比如发送消息、发布部署、写入文件、修改配置。这类工具会改变外部系统状态风险明显更高。模型一旦误调用可能造成不可逆影响。所以在接入真实业务时我建议先对照明这两类。对于写操作型工具初期至少要加一层确认机制。很多 MCP 客户端已经有“工具调用前等待用户确认”的设置不要为了追求全自动就关掉它。等模型在特定场景下的调用准确率足够高再考虑逐步放开。4.3 工具注册不上怎么办一条排查链路最近常见的一个问题是 “Figma MCP 在 Codex 中总是工具注册不上”很多人在网上问。这类问题本质上不是某一个 bug而是一条链路上的多个环节需要逐一检查。建议排查顺序先确认 MCP server 本身能在命令行单独启动。直接运行配置里的启动命令看是否报错。再确认客户端配置文件的路径、命令、参数是否准确。不同操作系统对 npx、node、python 的引用路径不一样尤其是 Windows 系统配置里经常需要指定具体的可执行文件路径。然后看客户端有没有成功发起 tools/list 请求。如果请求没有返回问题多半在连接建立阶段。如果 tools/list 返回成功但模型仍然说找不到工具可能是客户端缓存或模型上下文没有刷新。重启客户端再试一次。如果 server 返回了工具但调用报错要检查输入参数 schema 是否与实际情况匹配以及 server 依赖的外部服务是否可用。比如 Figma MCP 通常需要配置 Figma access tokentoken 没有权限工具能发现但不能成功读数据。这里面最容易蒙蔽人的是第二步。很多人改了命令发现还是没有效果就开始怀疑协议有问题。其实首先要确认配置里的命令在 shell 里能否直接跑通然后再去排查客户端。4.4 那些容易忽略的 Schema 细节还有一个从热词里能看到的经典问题MCP Tools 的 InputSchema 是否支持类型嵌套答案在协议层面是支持的。MCP 工具的参数使用 JSON Schema 描述自然支持嵌套对象、数组、枚举等结构。比如一个工具需要传入 { filters: [{ field, operator, value }] }这种复杂结构可以被完整描述。但要注意不同客户端的兼容性并不同。有些客户端在处理嵌套 schema 时可能无法正确解析复杂的组合关键字或者生成 UI 表单时表现不佳。在工具设计上尽量保持输入参数平坦化如果必须嵌套请先用支持 MCP 的客户端做实测不要想当然觉得协议支持就一定没问题。5. 自己跑通一个最小 MCP 流程5.1 环境准备体验 MCP 不需要太复杂的工程环境。常见准备是Node.js 或 Python 3.10 环境取决于你想用哪种 SDK。一个支持 MCP 的客户端。常见的有 Claude DesktopVSCode 里的 Cline、Continue 等插件或者 Codex。一个简单的 MCP server 示例。如果你选择 Python 方式需要先安装 MCP SDK。具体安装命令以对应 SDK 的官方文档为准这里不做版本绑定的假设。5.2 写一个最小 MCP Server下面是一个极简 MCP server 的示例结构用 Python 风格展示目的是理解“把函数暴露成工具”这一过程。from mcp.server import Server from mcp.server.stdio import run_server from mcp.types import Tool, TextContent server Server(demo-server) server.list_tools() async def list_tools(): return [ Tool( nameget_current_time, description返回当前时间用于演示 MCP 工具调用, inputSchema{ type: object, properties: {} } ) ] server.call_tool() async def call_tool(name: str, arguments: dict): if name get_current_time: from datetime import datetime now datetime.now().isoformat() return [TextContent(typetext, textf当前时间是 {now})] raise ValueError(f未知工具: {name}) if __name__ __main__: run_server(server)这段代码只做三件事声明工具列表、定义工具行为、在 stdio 上启动服务。真实的 server 会复杂很多但这个骨架足够让你看到 MCP 的核心结构。5.3 配置客户端并验证要让客户端发现这个 server需要在客户端配置里添加一条记录。不同客户端格式不一样常见思路是配置命令和参数。比如{ mcpServers: { demo: { command: python, args: [path/to/server.py] } } }配置完成后重启客户端。正常情况下客户端会启动这个进程并通过 stdio 获取工具列表。你可以在对话里问 “当前时间是多少”如果配置正确模型会调用你刚写的 get_current_time 工具而不是凭空回答一个时间。5.4 从最小流程到真实业务先跑通再工程化最小流程跑通后不要急着写几十个工具。更稳妥的节奏是先在一个 server 里只暴露 1 到 2 个核心工具。用真实数据和真实客户端跑完整个调用链路。确认输出、日志、错误处理都符合预期。再逐渐增加工具数量。你之后会发现MCP 的接入难点从来不是写一个简单工具而是工具变多之后schema 冲突怎么处理调用失败时客户端怎么回退长耗时工具怎么处理超时写操作怎么加确认。这些才是工程化要解决的事。注意不要一上来就写 50 个工具。工具数量越多模型的选择难度越大误调用概率也会明显上升。先让模型在少量工具上形成稳定表现再加量。6. 生产环境使用 MCP真正要关心的五件事6.1 权限与信任边界MCP server 拥有的能力可能比普通 API 大得多。它可以读本地文件、执行命令、连接内网服务。模型一旦被注入恶意指令或者获得了过大的工具权限风险是实际的。所以在生产环境里要严格管控 MCP server 的权限边界。比如使用独立的低权限账号运行 server限制它只能读取必要的目录禁止它访问非相关端口对每一个新接入 server 做代码和依赖审计。6.2 资源暴露范围当你给模型提供一个读文件工具时你实际上把什么范围的文件暴露给了模型如果 model 可以任意读取整个磁盘的路径那么对话历史里的“灵感”和“提示注入”都可能成为数据泄露入口。建议做法是给文件类工具设置明确的根目录白名单数据库类工具限制只能执行 SELECT设计稿类工具限制只读当前项目的文件。不把整个系统的可见面一次性交给模型。6.3 日志与可观测性AI 应用和传统服务的最大不同是模型的行为难以完全预测。它可能在某个时刻调用了一个你没想到的工具传入了你没预料到的参数。这种不确定性要求 MCP server 必须有完善的日志。日志里至少要记录谁发起了调用、调用的是哪个工具、传入什么参数、返回什么结果、调用耗时、是否失败、错误原因。如果没有日志一旦模型误操作你只能看到结果已经发生却无法回溯过程。6.4 并发、超时与错误重试MCP server 在处理并发请求时需要关注两件事一是资源竞争二是超时控制。如果一个 server 同时被多个 AI 客户端使用而它本身是无状态设计问题不大。但如果它内部依赖数据库连接池、临时文件、限流器等有状态资源就需要认真处理并发冲突。另外模型调用工具的时长不确定工具内部一旦卡死客户端可能一直等待。服务端应设置合理的超时时间并对失败任务提供可理解的错误信息。6.5 版本锁定与依赖管理MCP 作为一个新协议演进速度非常快。今天能用的配置明天客户端升级后可能就变了。为了避免线上服务突然不可用需要在项目里固定 server 的版本、客户端版本和对应配置。给团队的内部 MCP server 建立 CI/CD 流程每次改动都跑一遍工具发现和最小调用测试。不要只依赖外部 server 的最新版必要时要 fork 或者锁定版本保持环境可复现。7. 回到最初的问题我们到底为什么需要 MCP7.1 AI 从对话走向做事连接层必须标准化把视野拉长一点看 MCP 之所以在 2025 年成为高频词是因为 AI 产品的形态正在从“chatbot”走向“agent”。Chatbot 只要处理文字不需要碰外部世界Agent 要真正完成任务就必须操作外部系统。一旦涉及外部系统就会出现无数种接口、权限、数据格式的组合。如果我们回到一年前一个团队要接 Figma、Postgres、Jira、GitHub Actions、浏览器自动化大概需要写 5 套独立的集成代码。每套代码都要单独维护、单独更新、单独测试。而当它们都变成 MCP server 后AI 客户端只需要学会一种协议新增工具只是增加一条 server 配置。这才是 MCP 的根本价值。它把“连接工具”这件事从项目级定制变成了基础设施级标准。理解了这一点你就不需要问“MCP 能做什么”而要问“当所有工具都标准化之后AI 应用的上限在哪里”。7.2 什么样的人现在不需要 MCP虽然 MCP 热度很高但它不是所有场景的银弹。如果你只是在做一次性脚本让 AI 调一个私有 API不需要多个客户端复用那直接写代码或者写一段 function calling 完全足够。它更快、更可控。如果你只需要简单的 webhook 触发也没有必要为了所谓标准去套 MCP。另外如果你的团队还没有跑通单个 Agent 任务先不要急着接一堆 MCP server。一个常见的失败模式是工具接了很多模型反而不知道该用什么任务准确率下降。先把单个核心场景跑通再逐步增加工具是更稳妥的顺序。7.3 下一步怎么开始如果你看完这篇文章认同 MCP 的核心价值那下一步最该做的是找一个小场景做一次端到端验证。我建议从这三个选项里选一个文件系统读取、数据库查询、设计稿或浏览器工具。这三个方向最容易看到效果也最容易暴露配置、权限、schema、日志问题。选一个你日常工作里高频但是重复性强的工具用 MCP server 包起来然后让 AI 客户端调用它跑真实任务。跑通之后你会有两个感受一是原来几天的集成工作被压缩成了几十分钟的配置二是真正的问题不在能不能调用而在怎么让调用边界清晰、安全、可追踪。而这两点恰好就是 MCP 在接下来一年里会不断变厚的地方。