一、MCP 为什么变得重要

过去一段时间里，大模型应用经历了一次很明显的重心迁移。早期大家关注的是模型能不能回答问题、能不能写文案、能不能生成代码；而当模型逐渐进入业务系统之后，问题很快就变成了另一类：它能不能读取真实数据，能不能调用外部系统，能不能在权限约束下完成具体动作。

这时，系统设计的难点就不再只是模型本身，而是模型与外部世界之间的连接方式。

如果一个 AI 助手想帮你分析订单数据，它需要接数据库；如果它想帮你审查代码，它需要接 GitHub、文件系统和 CI 结果；如果它想做运营自动化，它可能还要接 Slack、Notion、邮件和浏览器自动化。表面上看，这只是多接几个 API，但工程上很快就会遇到一系列问题：接入重复、能力描述不统一、不同客户端之间无法复用、权限边界混乱、工具数量一多 prompt 迅速膨胀，模型反而更容易失控。

MCP 出现的背景，正是这个阶段。

MCP 的全称是 Model Context Protocol，通常翻译为模型上下文协议。它不是某个产品，也不是某一家模型厂商私有的接口，而是一套面向大模型应用的标准协议。它试图解决的核心问题并不复杂：让模型客户端以统一方式访问外部工具、数据资源和提示模板。

如果把传统 API 看成软件之间的连接方式，那么 MCP 更像是 AI 应用与外部能力之间的连接方式。它面向的不只是函数调用，而是更完整的上下文接入问题。也正因为如此，MCP 的价值不在于又多了一个新名词，而在于它给 Agent 和 AI 工程提供了一层真正可以复用、治理和演进的基础设施。

本文会从工程背景出发，先讲清楚 MCP 是什么，再讨论它为什么会在今天成为热点；然后进一步展开它的架构、协议对象、通信机制，以及它和 Tool Calling、Skill、Agent Runtime 之间的关系。最后，我会重点讨论一个在落地中经常被忽略、但实际非常致命的问题：Prompt 膨胀与上下文治理。

---

二、MCP 到底是什么

在很多介绍里，MCP 往往被一句话概括成大模型访问工具的协议。这个说法不能算错，但明显不够完整。

MCP 的更准确理解方式是：它定义了一套标准化的能力暴露与访问协议，让客户端可以发现服务端提供的工具、资源和提示模板，并把这些能力以适合模型理解的方式组织进推理过程。

也就是说，MCP 不是某种特定 SDK，也不是模型内部固有能力。它更接近一个协议层，位于模型应用与外部世界之间。

从职责边界上看，MCP 不做三件事。它不负责模型训练，不负责模型推理本身，也不替代业务工作流编排。模型负责理解、推理和决策；业务系统负责流程、状态和权限域控制；MCP 负责连接、描述、发现、调用和回传。

这个边界非常重要。因为一旦把 MCP 误解成某个具体工具库，或者误解成模型厂商自带能力，就很容易在架构上走偏。它真正解决的是接入层标准化，而不是推理层智能化。

（一）它不是产品，而是协议

很多工程团队第一次接触 MCP 时，最容易犯的一个错误，是把它理解为一个现成的工具平台。实际上，协议和平台是两回事。

协议关心的是双方如何通信、消息长什么样、工具如何被描述、资源如何被访问、返回结果如何组织。只要遵守协议，不同语言、不同运行时、不同宿主环境都可以互通。这正是协议的价值所在。

也因此，MCP 的核心不是某个 SDK，而是协议约束本身。今天你可以用 Python 写一个 MCP Server，明天也可以用 Node.js、Go 或 Rust 重写；客户端可能是桌面 AI 助手、IDE 插件，也可能是云端 Agent Runtime。只要它们遵守同一套描述与调用方式，就具备互操作性。

（二）它不是模型能力，而是模型的外部能力接口

很多人会把 MCP 和 Tool Calling 混在一起谈，这也是一个常见误区。

Tool Calling 更偏向模型侧能力，它解决的是模型如何表达调用意图，例如模型决定要调用哪个函数、携带什么参数、分几步执行。而 MCP 更偏向系统侧协议，它解决的是这些能力如何被统一暴露、如何被发现、如何被安全调用、如何返回结果，以及工具之外的资源和 prompt 如何组织。

换句话说，Tool Calling 关注模型怎么说我要调用某个能力，MCP 关注系统怎么把能力提供给模型去选、去用、去管理。

这两个层面不是替代关系，而是典型的互补关系。模型侧的 Tool Calling 越成熟，越需要系统侧有更稳健的 MCP 接入层；反过来，MCP 接入做得越标准，模型越容易在复杂环境下做可靠决策。

（三）它关心的不只是工具，还有上下文

如果只从函数调用角度理解 MCP，就会低估它的设计边界。

大模型在实际任务里并不只是需要执行动作。很多时候，它更需要的是读取上下文。比如审查代码前要先读团队规范，写 SQL 之前要先看数据库 schema，回答业务问题前要先读指标口径文档。除此之外，在很多团队中，还会沉淀一些稳定的 prompt 模板，用来规范特定任务的推理行为。

因此，MCP 不只是为工具而生，它同时定义了三类核心对象：Tools、Resources 和 Prompts。它真正统一的是能力、上下文和约束的接入方式。

---

三、为什么今天需要 MCP，而不是继续堆 API 适配层

MCP 的出现，并不是因为行业里突然想再发明一个协议。它背后真正的驱动力，是大模型应用进入执行时代之后，原有接入方式越来越难支撑复杂场景。

在没有 MCP 的时候，模型接外部能力通常有几种做法。最传统的是应用自己写 API 适配层，把外部系统封装成内部函数，再喂给模型使用。稍微先进一点的方式，是把能力包装成 Function Calling 或 Tool Calling 接口，让模型按 schema 发起调用。再往前一步，一些平台会做自有插件机制，试图提供某种统一扩展能力。

这些方式都能工作，但都存在相同的结构性问题：它们可以解决单点接入，却很难解决生态复用与治理。

（一）重复接入成本会随着工具数量线性失控

单看一个工具接入，工作量并不夸张。定义工具名、写描述、设计参数 schema、做鉴权、写返回格式、补异常处理，看起来都只是一些常规工程动作。

问题在于，大模型应用天然是多工具场景。它不会只接一个 GitHub，也不会只接一个数据库。真实系统往往很快就会扩展到文件系统、浏览器、搜索、知识库、IM 协作平台、内部业务 API 等多个域。一旦工具数量上来，重复定义和重复封装就会迅速膨胀。

更麻烦的是，这种工作往往不是一次性的。你在桌面客户端接了一套 GitHub 工具，到了 IDE 插件里可能还要再接一次；你在测试环境封了一层，进生产后又要补权限控制和审计逻辑。表面上看是接了同一个能力，实际上却反复做了多套接入工程。

MCP 的意义，首先就在于把这些重复劳动协议化。能力定义不是在每个客户端里重复书写，而是由服务端统一暴露，客户端按协议发现和消费。

（二）传统方案缺少能力发现机制

模型调用工具，不只是执行问题，更是认知问题。

它要知道自己能用什么工具，工具能做什么，参数应该怎么传，哪些内容是可读资源，哪些 prompt 模板可以复用。如果没有一套统一的发现机制，开发者只能把所有能力硬编码在客户端里，再想办法塞进 prompt。这种方式短期可以跑通，长期一定难以维护。

因为一旦能力是写死的，它就天然不具备动态演进能力。新增一个工具，要改客户端代码；删掉一个资源，也要改客户端；不同宿主环境之间还可能各自维护一份工具定义副本。系统复杂度会随着能力数量增加而不断上升。

MCP 的一个核心改进，就是把发现机制协议化。客户端不是默认知道一切，而是可以在建立连接后先询问服务端：你有哪些 tools、有哪些 resources、有哪些 prompts。这样能力就是可发现的，而不是预埋在代码里的。

（三）不同客户端之间难以复用，生态容易割裂

在没有标准协议之前，每个 AI 应用都很容易发展出自己的插件体系。短期看，这有利于平台快速迭代；长期看，则会造成生态碎片化。

一个工具如果只能服务某个特定产品，那么迁移到别的宿主环境时，往往需要重写一遍。桌面端一套，IDE 一套，Web Copilot 一套，Agent 平台再来一套。结果不是能力复用，而是同一能力在多个系统中重复造轮子。

协议的价值就在于解耦。MCP 试图把能力提供者和能力消费者隔离开：工具不必针对某个产品私有接入，只需要按协议暴露；客户端也不必为每个外部系统单独做定制适配，只要会说同一种协议即可。

（四）模型真正需要的是能力、上下文和约束的统一接入

很多人把 MCP 理解为又一种 Tool Calling，这个理解只抓住了一部分。

因为在真实任务里，模型需要的并不只是可执行函数。它还需要知道有哪些上下文可读、有哪些提示模板可复用，以及在什么限制下这些能力才允许被调用。尤其在 Agent 场景中，单纯给模型一堆函数名并不足以形成稳定执行，它还需要围绕任务目标拿到足够的上下文和约束信息。

从这个角度看，MCP 解决的问题其实很清楚：它不是单纯让模型能调工具，而是给模型提供一整套可发现、可描述、可治理的外部能力接入层。

---

四、MCP 解决的到底是什么问题

如果只记定义，MCP 很容易变成另一个被神化的缩写。真正理解它，更好的方式是看它解决了哪些具体问题，以及它不解决哪些问题。

总体来看，MCP 主要解决三类问题：能力标准化描述、能力可发现、能力可治理。

（一）能力标准化描述

模型不是直接执行代码的程序员，它只能基于上下文理解能力边界。因此，任何一个想被模型调用的外部能力，都必须先被描述成模型能够理解的形式。

这种描述至少要包含工具名、功能说明、参数结构、输入输出格式。进一步扩展之后，还会包含可读取资源、可复用 prompt 模板，以及某些能力约束。

过去这些描述往往散落在各个客户端和工具封装中，定义风格不统一，甚至连命名习惯都不一致。MCP 的价值之一，就是把能力描述协议化，尽量让客户端消费不同服务端能力时具备一致体验。

这件事听起来很基础，但它其实是大模型系统工程能否规模化的前提。因为没有统一描述，就不存在真正意义上的跨客户端复用，也很难做自动化发现和治理。

（二）能力可发现

在传统硬编码方案里，模型能用哪些工具，完全取决于开发者提前写进了什么。如果要动态新增、变更、下线工具，整个流程就会牵一发动全身。

MCP 改变了这个模式。客户端可以先与服务端建立连接，再查询服务端当前暴露的能力清单。这个清单不仅告诉客户端有哪些工具，也告诉它有哪些资源和 prompt 模板可用。

这带来的好处不只是灵活性，更重要的是工程上的解耦。能力提供端可以独立演进，能力消费端只关心标准化发现结果，而不必预置所有具体实现。

对于 Agent 来说，这尤其关键。因为 Agent 并不是按照固定业务代码一步步执行，而是先在可选能力集合里做决策。能力必须先可枚举、可解释，模型才有可能稳定地选中合适能力。

（三）能力可治理

如果说前两类问题偏向接入和描述，那么治理问题则是 MCP 真正进入生产环境时的分水岭。

普通程序调用 API，调用者通常是确定的业务代码，路径、参数和责任边界都相对清晰。AI 调工具则不同，调用发起者变成了一个会推理、会尝试、会犯错的模型。它的行为不是事先逐行写死的，这会自然带来更高的治理要求。

例如，一个写文件工具是否允许被任意调用？数据库查询是否允许跨库访问？浏览器自动化是否允许提交表单？Shell 命令是否只能运行白名单指令？某些动作是否必须人工确认？调用日志是否要审计？多租户场景下是否需要强隔离？

这些问题不是简单的工具封装能解决的，它们需要在协议接入层和执行层之间建立清晰边界。MCP 本身不是完整安全方案，但它为治理提供了更明确的对象边界和控制入口，这也是它和简单 Function Calling 最大的工程差异之一。

---

五、MCP 的整体架构

从架构上看，MCP 通常是一个典型的 Client-Server 模型。这个模型并不复杂，但理解它的职责分层，对后面的工程设计非常关键。

在最常见的场景里，会有三个角色：MCP Client、MCP Server 和 LLM 或 Agent Runtime。Client 通常内嵌在 AI 应用里，比如桌面端、IDE 插件、Copilot 宿主或 Agent 框架；Server 负责把外部能力包装成协议对象；模型则根据上下文决定是否调用某个能力。

下面这张图可以先建立一个整体视角：

这个架构真正的关键点在于，模型并不直接面对各种异构外部系统，它面对的是 MCP Client 整理后的能力描述；而客户端也不直接硬编码每个外部系统的细节，而是通过 MCP Server 获取统一能力接口。

（一）MCP Client 的职责

MCP Client 是连接模型与外部能力的桥梁。它看上去像个中间层，但实际上承担了非常关键的协议组织工作。

首先，它需要与 MCP Server 建立连接，并完成初始化协商。随后，它要获取服务端暴露的工具、资源和提示模板列表，并决定如何将这些信息注入模型上下文。等模型做出调用决策后，Client 还要把模型意图翻译成标准协议请求，再把调用结果回传给模型继续推理。

这意味着 MCP Client 本身并不只是一个转发层，它实际上承担了模型上下文组织、能力路由、调用代理和状态回填等一系列职责。很多 MCP 系统的质量问题，最后并不出在 Server，而是出在 Client 如何把能力暴露给模型。

（二）MCP Server 的职责

MCP Server 则负责把某种外部能力包装成协议能力。它的职责边界通常更清晰：声明自己有哪些工具，提供工具的参数 schema，暴露可读取资源，暴露可复用的 prompt 模板，并在收到调用请求后执行真实动作，再返回结构化结果。

Server 还经常承担执行层治理职责，例如鉴权、权限控制、目录白名单、异常处理、重试策略、结果裁剪和审计记录等。

如果说 Client 更偏向模型适配和上下文管理，那么 Server 更偏向能力封装和执行治理。两者的分工清晰与否，决定了系统能否在复杂场景下保持可维护性。

（三）MCP 不属于模型本身

这一点值得单独强调。MCP 不属于模型，也不是某个模型厂商内部机制的一部分。它更像是大模型应用生态中的一层连接基础设施。

这意味着，模型可以替换，MCP 不一定要跟着替换；MCP Server 可以复用，模型供应商也可以变化；同一套工具层理论上可以服务多个不同客户端和多个不同模型。

从长期架构演进看，这种解耦非常重要。因为模型能力会持续变化，推理框架也会不断迭代，如果工具接入层与模型深度耦合，整个系统会变得非常脆弱。MCP 的价值之一，就是在快速变化的模型层之下，给外部能力接入建立一个相对稳定的中间层。

---

六、MCP 的核心对象：Tools、Resources 与 Prompts

理解 MCP，不能只盯着 Tool。它的完整性恰恰体现在它把工具、资源和提示模板都纳入了统一协议视角。

可以先看下面这个分层图：

这三类对象分别解决的是动作、内容和行为模板的问题。

（一）Tools

Tool 表示可以做某件事的能力。它通常对应一个可执行函数或者命令式操作，比如创建 GitHub Issue、运行 SQL、打开浏览器、发送 Slack 消息、读取文件、写入文件、执行 shell 命令等。

从本质上说，Tool 是面向模型暴露的可执行动作能力。一个 Tool 一般会包含名称、描述、输入参数 schema，以及返回结果的结构约束。模型通过这些描述来理解它的用途和使用方式。

但工程上必须注意，Tool 的设计不是越细越好，也不是越大越好。过于原子化会导致工具数量爆炸，模型选择困难；过于粗粒度则会让参数复杂度上升，失败场景更难控制。好的 Tool 设计，往往是围绕稳定的动作边界，而不是围绕底层 API 机械映射。

（二）Resources

Resource 是 MCP 里一个经常被忽视、但其实非常关键的对象。它表示可读取并纳入模型上下文的内容，比如本地文件、项目 README、数据库 schema 文档、知识库页面、仓库配置文件或者某个 URL 抓取后的文本。

它和 Tool 的区别并不只是能不能调用，而在于语义边界不同。Tool 强调动作，Resource 强调内容。前者更像执行操作，后者更像提供上下文入口。

这个区分很重要，因为很多任务根本不需要执行动作，而只需要读取内容。比如解释项目结构、生成 SQL 前读取表结构、代码审查前读取团队规范、回答业务问题前读取指标定义。如果把这些都揉成工具调用，工具语义会变得很混乱，模型也更难理解什么时候是在取上下文，什么时候是在做操作。

MCP 把 Resource 独立出来，本质上是承认一件事：上下文供给本身就是 AI 系统中的一等能力，而不是工具调用的附庸。

（三）Prompts

Prompt 在 MCP 里的定位也很有现实意义。很多团队在生产实践中都会沉淀一批高复用提示模板，比如根据 diff 做代码审查、根据数据库 schema 生成 SQL、为 PR 生成总结、基于知识库回答问题等。

这些模板如果散落在客户端代码里，不利于维护，也很难在不同宿主之间复用。MCP 将 Prompt 作为独立对象暴露出来，相当于把团队经验、任务约束和最佳实践也纳入了协议层。

这带来的价值并不是简单的复用，而是任务稳定性。因为在很多业务场景里，决定质量的并不只是能不能调用工具，而是模型在调用前后如何被约束、如何组织上下文、如何遵循输出格式。Prompt 模板可以显著降低模型自由发挥带来的偏差。

---

七、MCP 的底层原理与通信机制

讲到这里，一个很自然的问题是：MCP 在底层到底怎么工作？

答案并不神秘。它本质上是一种结构化消息通信机制，常见实现会采用 JSON-RPC 风格。客户端与服务端通过结构化 JSON 消息完成初始化、能力发现、工具调用、结果返回、资源读取和 prompt 获取等动作。

从这个角度看，MCP 的重点不在于某种神奇能力，而在于消息结构和交互流程的统一。

（一）为什么说它是协议，而不是 SDK

SDK 可以帮助开发，但不是本质。真正决定两个组件能否互通的，是它们是否遵守同样的通信约定、消息格式和对象语义。

所以 MCP 的核心价值并不来自某个官方库，而来自协议本身。只要双方理解相同的消息结构，就能跨语言、跨运行时、跨宿主环境工作。这也是为什么 MCP 能够在桌面、本地 IDE、远程平台和云端 Agent 等不同场景中复用。

（二）本地场景下常见的 stdio 传输

很多本地 MCP Server 会采用 stdio 作为传输层。方式很直接：客户端拉起一个本地进程，双方通过标准输入和标准输出传递 JSON 消息。

这类设计非常适合桌面客户端、IDE 插件、本地文件系统工具和 shell 工具等场景。它的优势也很明显：实现简单，不需要额外开放网络端口，本地权限边界更清晰，易于调试，也更容易做沙箱化。

在工程实践里，stdio 是一种非常务实的选择。尤其对本地能力接入来说，它避免了把本地工具强行网络服务化，从而降低了部署和安全复杂度。

（三）远程场景下的 HTTP 与 SSE

如果 MCP Server 部署在远端，或者你希望构建团队共享的工具中心，那么基于网络的传输方式会更合适，例如 HTTP、SSE，或者某些支持流式返回的扩展协议。

这种方式更适合企业级统一能力平台、云端 Agent 服务、团队共享工具服务、MCP Gateway 等场景。它的优点是集中管理、便于复用、适合多人共享；缺点则是网络引入的延迟、鉴权复杂度、跨租户治理难度都会提高。

因此，stdio 和 HTTP/SSE 并不是谁取代谁，而是各自适应不同部署边界。

（四）初始化协商为什么重要

MCP 不是一连上就直接调用工具。典型流程通常是：客户端启动或连接服务端，双方协商协议能力，客户端请求服务端的能力清单，服务端返回 tools、resources 和 prompts 列表，客户端再将这些能力描述组织进模型上下文，最后模型在推理时决定是否使用。

这个过程说明了一件事：模型不是盲目调用工具，而是在已知能力边界的前提下做选择。对 Agent 来说，这一点尤其重要，因为它不是沿着固定业务代码往下执行，而是在动态能力集合中做计划和决策。

---

八、架构演进路径

理解 MCP 的一个好方法，是把它放在架构演进链条里看。因为它并不是凭空出现的，而是大模型系统从简单到复杂逐步演化后的结果。

这个演进过程背后，不是技术名词升级，而是系统复杂度升级。

（一）早期阶段：直接调用 API

最早的大模型应用往往只是单点能力增强。比如在问答系统里接一个搜索 API，在代码助手里接一个文件读取接口。这时直接在应用里写 API 调用是最简单的方案。

这种方式的好处是成本低、开发快、调试直观。但缺点也很明显：能力定义散落在业务代码里，没有抽象边界，几乎不具备复用性。

（二）中间阶段：内部工具封装与 Tool Calling

随着模型开始具备结构化调用能力，很多团队会把外部能力包装成函数或工具 schema，让模型输出调用意图，再由应用去执行。这个阶段通常会引入 Function Calling 或 Tool Calling。

这一步已经明显优于最原始的 API 直连，因为模型开始能够基于结构化描述做工具选择。但问题也开始显现：这些工具通常仍然是宿主私有定义，描述方式、返回格式、资源访问方式和治理机制都不统一。

（三）平台阶段：自有插件体系

再往后，平台方往往会构建自己的插件或扩展机制，试图把工具接入标准化。这个阶段的架构已经接近 MCP 的雏形，但问题在于它通常服务于单一平台，生态边界较封闭，难以跨客户端复用。

也就是说，它解决了平台内部统一问题，却没有解决行业层面的能力互操作问题。

（四）协议阶段：MCP 带来的解耦

MCP 的价值就在于，它把原本平台内部的私有能力描述和调用方式提升为通用协议。这意味着能力提供方和能力消费方可以被彻底解耦。

工具提供者不用知道最终宿主是谁，只要按协议暴露；客户端也不用关心具体能力是本地进程还是远端服务，只要能完成发现、描述、调用和回传即可。

这一步真正改变的，是生态复用方式。系统不再围绕某个产品内部插件体系闭环，而是围绕协议形成可移植能力层。

---

九、一次完整的 MCP 调用流程

抽象架构讲清楚之后，最好再看一个具体流程。假设用户提出一个典型数据分析请求：帮我查询今天新增订单数，并做一个简单分析。

在接入了 MCP 的系统里，这个任务通常会经历下面一条链路。

（一）用户只表达业务目标，而不是指定工具

用户不会说请调用 run_sql，然后执行某段 SQL，再读取 schema，最后做总结。用户通常只会表达目标，例如查询今天新增订单数并分析。

这意味着系统必须自己完成从目标理解到能力选择的转译过程。

（二）客户端准备好当前可用能力

在此之前，MCP Client 已经通过初始化和能力发现拿到了可用能力清单。比如它知道当前某个 MCP Server 暴露了 run_sql、get_schema 和一个用于销售分析的 prompt 模板。

注意，这里的关键不是客户端把所有能力无脑塞给模型，而是它需要决定哪些能力应该在当前任务上下文中可见。这一点与后文要讲的 Prompt 膨胀治理直接相关。

（三）模型判断是否需要工具

模型会先分析用户意图。如果它发现单靠已有对话上下文无法回答，就需要使用外部能力。在这个例子里，它会意识到订单数据必须来自数据库，因此需要读取 schema 或直接执行查询。

这一步是模型能力所在。MCP 并不替模型做判断，它只是确保可选能力被标准化地提供出来。

（四）客户端把模型意图转成协议调用

模型输出的通常是某种结构化调用意图，例如它打算调用 run_sql，参数是一条特定 SQL。MCP Client 随后把这个意图转成标准协议请求，发给相应的 MCP Server。

（五）服务端执行真实动作并回传结构化结果

MCP Server 负责连接真实数据库，执行 SQL，并把结果按结构化形式返回。它可能还会做权限校验、结果裁剪、敏感字段过滤和错误处理。

（六）模型继续推理并生成最终回答

客户端拿到结果后，会把结果回传给模型。模型基于这些数据完成分析、总结和自然语言生成，最后形成对用户的回答。

下面这张流程图可以把整个运行过程串起来：

十、MCP 与 Tool Calling 的关系

这是目前最容易被误解的一个问题。很多人看到 MCP 能调工具，就会自然得出结论：它不就是 Tool Calling 吗？

这类判断只说对了一半。

（一）Tool Calling 解决的是模型如何表达调用意图

Tool Calling 是模型层面的能力。它让模型在生成自然语言之外，还能输出结构化调用请求。这个请求通常包括要调用哪个函数、参数是什么、调用顺序如何，有时还会支持多轮规划。

从推理视角看，Tool Calling 解决的是表达问题。模型不再只能回答文本，还可以表达我要调用某个能力。

（二）MCP 解决的是能力如何被系统化提供和管理

MCP 关心的是另一个层面：工具从哪里来，如何被统一描述，客户端如何发现它们，如何发起标准化调用，如何返回结构化结果，以及资源和 prompts 如何与工具共同组织。

如果说 Tool Calling 是模型说我要做什么，那么 MCP 是系统说这里有哪些能力可做、怎么做、在什么边界内做。

（三）两者结合才是完整的 Agent 工程方案

一个成熟的 Agent 系统通常同时需要两种能力：模型侧要有足够强的工具选择和调用规划能力，系统侧要有足够稳健的能力接入和治理能力。

因此未来更现实的方向不是二选一，而是强 Tool Calling 配合强 MCP。模型负责思考和决策，MCP 负责标准化接入和执行边界治理，两者结合才能把 Agent 从演示效果推进到生产系统。

---

十一、Skill

如果说 Tool 是原子动作，那么 Skill 更像是围绕某类任务组织起来的能力包。

虽然 Skill 不一定是所有 MCP 讨论中的核心协议对象，但在 Agent 工程和产品设计里，它非常重要。因为现实中的任务通常不是调用一个函数就结束，而是需要工具、资源、提示模板和流程约束共同协作。

（一）Skill 更像任务级能力封装

举一个典型例子。一个 PR 审查 Skill 可能并不是单个工具，而是一套组合：

它需要读取 PR diff 的工具，需要访问仓库规则的资源，需要一个代码审查 checklist prompt，还需要输出评论格式约束，最后可能还要调用写回评论的工具。

从任务视角看，Skill 表示一类稳定可复用的工作流能力，比如帮我审查一个 PR、帮我生成数据分析报告、帮我定位线上故障原因、帮我总结会议纪要并同步到 Notion。

（二）Tool 是零件，Skill 是装配好的能力单元

很多团队在构建 Agent 时，初期只做 Tool，后期会发现模型虽然拥有很多工具，但任务完成质量仍然不稳定。原因很简单：模型拿到的是零件，但缺少装配方式。

Skill 的价值就在于，它把工具、资源、prompt 和流程约束按任务组织起来，让模型不必每次都从零进行组合探索。这本质上是在提升任务稳定性和可预测性。

（三）Skill 往往构建在 MCP 之上

MCP 更关注基础能力对象，也就是 Tools、Resources 和 Prompts 的标准化接入。Skill 通常构建在这些对象之上，属于更高一层的任务编排或能力打包。

所以从工程角度看，可以把 MCP 理解为能力层，把 Skill 理解为任务层。能力层负责标准接入，任务层负责稳定复用。两者并不是同一个概念，但经常一起出现。

---

十二、当前主流的 MCP 生态：客户端形态与服务端类型

MCP 之所以在最近一段时间迅速升温，一个重要原因是它已经不是停留在概念层面，而是开始进入不同产品形态和工程场景。

从生态分布上看，可以先从客户端和服务端两个方向理解。

（一）主流 MCP 客户端形态

1. 桌面 AI 客户端

桌面客户端是最早拥抱 MCP 的一类形态。原因很直接：它们天然需要连接本地能力，例如文件系统、shell、浏览器、本地数据库等，而 stdio 方式又非常适合本地进程通信。

这类客户端的优势是贴近个人工作流，权限边界相对清晰，本地能力调用也更自然。局限则在于共享性弱，团队级治理和统一管理能力不足。

2. IDE 与编程助手

IDE 插件和代码助手是另一个非常适合 MCP 的场景。因为开发工作流天然依赖文件系统、GitHub、shell、数据库和浏览器等外部能力。代码生成、自动修复、仓库问答、PR 审查，本质上都不是纯文本推理问题，而是强依赖上下文和执行能力的问题。

在这类场景里，MCP 的价值特别明显，因为它既能提供可执行工具，也能提供可读取资源，例如仓库规范、项目 README、配置文件、代码 diff 等。

3. Agent 平台与 AI 开发框架

一些 Agent Runtime、Copilot 平台和工作流引擎，也正在把 MCP 作为工具接入层。它们最看重的不是单个工具调用，而是能力标准化、动态发现、多工具复用，以及更清晰的治理边界。

不过，这类平台接入 MCP 时也会面临更高要求，因为一旦进入多租户、远程服务和企业内部系统接入，权限控制、审计、延迟和故障隔离都比本地场景复杂得多。

（二）主流 MCP Server 类型

从服务端类型看，当前比较主流的 MCP Server 大致有以下几类。

1. Filesystem MCP

这是最容易理解、也最常见的一类。它提供读取文件、写入文件、列出目录、获取项目结构等能力，通常还会配置目录白名单来控制访问边界。

它特别适合代码助手、本地文档分析、自动修改项目文件、读取配置说明文档等场景。很多开发类 Agent 的第一步，往往就是接入 Filesystem MCP。

2. GitHub MCP

GitHub 类 MCP 往往会暴露仓库信息读取、Pull Request 和 Issue 访问、diff 获取、Issue 创建与更新、提交历史分析等能力。

这类服务非常适合代码审查、仓库问答、自动生成 PR 总结、Issue 归类与创建等工程场景。它的难点通常不在能力本身，而在权限边界与写操作治理上。

3. Database MCP

数据库类 MCP 也非常常见，尤其是在 BI 助手、数据问答和运营分析场景中。它通常提供执行 SQL、获取 schema、查询元数据、做基础数据分析等能力。

这类服务的工程重点往往是权限控制、读写分离、结果裁剪、慢查询保护和敏感数据治理。

4. Browser MCP

浏览器自动化类 MCP 通常基于浏览器控制能力，提供打开网页、抓取内容、点击输入、提交表单、流程自动化等操作。

这类能力适合网页信息采集、Web 自动化测试、表单填报和跨系统流程串联，但风险也更高，因为它往往涉及真实交互、副作用操作和页面状态不确定性。

5. Search / Fetch MCP

搜索和抓取类 MCP 提供联网搜索、网页抓取、文档检索、企业知识库搜索等能力，适合联网问答、实时信息获取、RAG 增强和市场研究场景。

它的挑战不只是接入，而是结果质量控制、噪声过滤和长文本结果治理。

6. 办公协作类 MCP

Slack、Notion、Jira、Confluence、Google Drive、邮件系统等办公协作平台，也是 MCP 很自然的落地方向。日报周报生成、工单助手、知识归档、会议纪要整理和团队协作自动化，都很适合通过这类服务完成。

不过这类系统通常带有更复杂的组织权限和审计要求，因此真正生产化时要比演示场景复杂得多。

---

十三、Prompt 膨胀与上下文治理

如果说 MCP 解决了能力接入标准化，那么它也会自然带来一个副作用：Prompt 会随着能力数量、对话轮次和调用历史不断膨胀。

这是 MCP 落地时最常见、却经常被忽视的问题之一。很多系统的失败，不是因为工具接不上，而是因为接入以后模型上下文迅速失控。

（一）Prompt 膨胀是如何产生的

一个典型客户端在接入 MCP 后，通常会做几件事：拉取所有 tools 列表，把每个 tool 的名称、描述、参数 schema 注入 prompt，把 resources 的说明也注入，把 prompts 模板信息也注入，再在多轮对话里不断追加历史调用和返回结果。如果同时连接多个 MCP Server，还会把多个能力集合并在一起。

这样做短期看最简单，因为省去了动态选择和按需加载逻辑；但代价也非常直接：prompt 会越来越长。

更麻烦的是，这种膨胀不是静态的，而是持续积累的。工具越多，历史越长，结果越大，模型越容易被无关信息淹没。

（二）它带来的问题不只是成本上涨

Prompt 膨胀的第一个后果当然是成本显著上升。上下文越长，token 消耗越大，请求越贵，多轮会话尤其明显。

第二个问题是延迟。模型读入上下文需要时间，prompt 越长，首 token 延迟越高，推理速度也会下降。

但真正影响系统质量的，往往是第三个问题：注意力被稀释。即使上下文窗口足够大，模型的有效注意力也不是无限的。大量无关工具描述会让模型抓不住当前任务重点，导致错误选择工具、忽略关键信息，甚至出现明明有工具却不会用的情况。

再往后，就是窗口上限问题。一旦同时叠加长对话历史、多次工具返回结果、用户上传大段文本和大量工具定义，上下文很容易触顶。结果不是简单截断，而是状态混乱、工具定义不完整、早期关键约束丢失。

一个反直觉但很真实的事实是：工具越多，Agent 不一定越聪明，有时候反而越乱。因为对模型而言，更多能力意味着更高决策负担。

（三）工程上怎么解决这个问题

解决 Prompt 膨胀，关键不是做单点优化，而是建立完整的上下文治理策略。

1. 不要全量暴露所有能力，而要按需注入

这是最重要的一条原则。

错误做法是把所有 MCP Server 的所有 tools 一次性塞进 prompt。正确做法是根据当前任务做能力筛选，只暴露相关工具子集。

如果用户在做订单数据分析，那么优先暴露 Database 相关工具；如果用户在做 PR 审查，那么优先暴露 GitHub 和 Filesystem 相关工具；如果用户在总结文档，那么优先暴露资源读取能力，而不是浏览器自动化和写操作工具。

本质上，这是在模型之前增加一层能力路由。没有这层路由，工具再标准化，最终也会被上下文膨胀吞掉。

2. 用两阶段暴露替代一次性注入完整 schema

很多系统一上来就把几十个工具的完整 schema 全部给模型，这往往是最浪费 token 的地方。

更合理的方式是采用两阶段策略。第一阶段只给工具目录，例如名称加一句话描述；第二阶段在模型决定要使用某个工具之后，再补充该工具的详细参数 schema。

这样做的收益非常直接：几十个工具的完整定义，往往可以先压缩成几十行摘要。模型只在真正需要时才看到细节。

3. 工具 schema 本身要做瘦身

不少团队在设计 tool schema 时，把它写成了给人类看的完整文档。描述过长、字段注释冗长、返回值说明过度展开、示例堆了一大段，结果全都变成了模型上下文负担。

工程上更合理的做法是：描述尽量短，字段命名尽量自解释，只保留关键约束，把复杂说明留在服务端文档中，而不是全部塞给模型。

原则很简单：让模型够用，而不是让文档完美。

4. Tool 返回结果不要原样回填，要做摘要化和裁剪

很多系统的真正膨胀源，并不是工具 schema，而是工具结果。

数据库查询一次返回几百行，网页抓取直接回完整 HTML，文件读取回整篇长文档，搜索结果一口气几十条。如果这些内容都原样注入 prompt，几轮调用下来上下文一定爆炸。

更好的策略是限制返回字段和条数，服务端先做摘要，长内容分页返回，必要时只返回引用 ID 或摘要，而不回传全文。

5. 历史工具结果要提炼为任务状态，而不是全量保留

多轮 Agent 系统里，不应该每轮都带上之前所有 SQL 结果、网页内容和文件原文。真正应该保留的是任务状态，而不是原始材料全集。

例如，把历史结果压缩成一个状态块：已完成哪些查询，得到什么关键结论，当前还缺什么步骤。模型保留的是任务记忆，而不是数据仓库。

6. Resources 要懒加载，而不是预加载

资源可读，不代表资源应该一开始就读进来。

更好的方式是先告诉模型有哪些资源可用，例如 README、设计文档、schema 文档存在；等模型真正需要时，再按需读取具体内容。这样可以显著减少初始上下文负担。

7. 工具太多时，要做工具检索而不是全量列举

当工具数量增长到几十甚至上百个时，静态暴露就不再可行。这时应该借鉴 RAG 思路，对工具本身做检索。

可以根据用户任务、embedding 相似度、分类标签、业务域路由等方式，先选出最相关的 3 到 5 个工具，再注入模型。这样模型面对的是一个候选集合，而不是整个工具市场。

8. 维护两套描述：给系统的完整文档，与给模型的极简摘要

这是一个非常实用的工程手法。

一套完整描述用于维护、测试和人类阅读；另一套摘要描述专门给模型消费。二者不必完全一致。前者强调完备性，后者强调 token 效率和模型可理解性。

9. 给上下文做预算管理

成熟系统应该像管理内存一样管理上下文。system prompt 占多少，tools 摘要占多少，当前用户问题占多少，历史对话占多少，tool results 占多少，状态摘要占多少，都应该有预算。

一旦超过预算，就触发裁剪、摘要或替换策略。没有预算管理，prompt 膨胀迟早会演变成系统性问题。

10. 建立短上下文执行与长上下文存储的双层机制

这是我最推荐的一种架构思路。

短上下文层只保留当前任务真正需要的最小信息，服务于当前推理；长记忆层则放在外部存储中，例如向量库、状态存储或任务数据库，需要时再检索。

换句话说，prompt 不应该承担保存全部历史的职责，它只应该承担当前推理所需最小上下文的职责。

（四）一个更合理的推荐流程

如果把上面的建议落成一个更实用的执行流程，大致会是这样：

先根据用户任务做域路由，例如分析订单数据时只路由到数据库能力域。第一轮只给模型少量候选工具摘要，例如 run_sql、get_schema、export_csv。等模型决定用 get_schema 后，再补它的详细信息。查询结果只返回前若干行、聚合统计和摘要，而不是整表原文。历史结果持续压缩成任务状态，而不是原样堆积。

这样做的结果并不只是节省 token，它还会带来更稳定的工具选择、更快的响应和更可控的系统行为。

---

十四、生产落地中的常见坑

很多团队在试用 MCP 时，前几天体验往往很好，因为一旦工具接通，演示效果通常很直观。但真正进入生产环境之后，问题往往集中暴露在几个地方。

（一）把 MCP 万能化

MCP 能统一接入，不代表它适合承载所有业务逻辑。

有些团队会把复杂业务流程、业务规则判断、长链编排全部试图丢给模型和工具调用来做。这种做法的问题在于，模型适合做推理和决策，不适合替代稳定流程引擎。MCP 适合做能力接入层，不适合替代业务编排层。

一旦边界混乱，最终系统通常会既不好测，也不好控。

（二）把工具设计成 API 镜像，导致模型难用

很多 Server 设计是把底层 API 原封不动包装成工具。工程上看这很省事，但模型并不擅长消费底层实现细节。它更需要围绕任务目标设计的动作边界。

好的 Tool 通常是任务友好的，不是 API 友好的。否则模型会在大量技术细节里迷失，调用成功率和参数正确率都会下降。

（三）忽视写操作和副作用治理

读操作往往比较容易接入，一旦开始支持写文件、发消息、提工单、提交表单、执行 shell，就会进入副作用区。这个时候，最怕的不是工具不能用，而是模型在错误场景下做了不该做的事。

因此，生产系统里必须明确哪些工具允许自动执行，哪些工具必须人工确认，哪些参数需要白名单校验，哪些动作必须审计。这些规则应该尽量放在 Server 或执行层，而不是寄希望于模型自己永远遵守。

（四）低估多租户和权限隔离难度

MCP 在单用户本地环境里看起来很简单，但一旦进入企业内部共享平台，多租户和权限隔离会迅速变成核心问题。

不同用户看到的工具集合可能不同，能访问的资源范围也不同；同一个 GitHub Server 可能要区分不同组织权限；同一个数据库工具可能要区分只读、脱敏和字段级权限。这些都不是协议定义本身能自动解决的，必须在平台实现层认真设计。

（五）只关注接入成功，不关注观测性

Agent 系统出问题时，如果没有调用链日志、工具调用审计、失败原因分类、工具命中率统计和上下文预算监控，排障会非常困难。

MCP 系统要想可运营，至少需要做到：知道模型看到了哪些能力，知道它为什么选择某个工具，知道某次调用失败在哪一层，知道哪些工具经常被错误使用，知道上下文长度是如何膨胀的。

很多时候，系统不是不能用，而是因为不可观测，所以无法持续优化。

---

十五、 实践思路

如果要给出一套相对稳健的工程建议，我更倾向于把 MCP 放在一个分层清晰的架构里，而不是把所有逻辑都堆在客户端。

这套架构有几个关键点。

（一）先路由，再暴露能力

不要把能力发现等同于能力全量暴露。客户端或中间层应该先根据任务做域路由，再决定暴露哪些工具、资源和 prompt。这样做既能控制上下文，也能减少错误调用。

（二）把治理前置到执行边界

权限、白名单、人工确认、写操作限制、审计日志，这些都应该放在执行边界，而不是依赖模型自律。Server 可以理解为能力的最后一道安全门。

（三）把工具层和任务层分离

基础能力通过 MCP 暴露，任务能力通过 Skill 或 workflow 组织。不要让一个工具承担过多工作流职责，也不要让模型每次都从零组合全部能力。

（四）把上下文当成资源管理对象

上下文不是免费的，也不是越多越好。需要预算、裁剪、摘要、懒加载和状态压缩机制。没有上下文治理，再好的 MCP 接入也会被长 prompt 拖垮。

（五）保留观测与回放能力

任何可用于生产的 MCP 系统，都应该能追踪一次完整任务里：看到了哪些能力、调用了哪些工具、读了哪些资源、返回了多少结果、花了多少 token、失败发生在哪里。只有这样，系统才有可优化性。

---

十六、总结

如果把视角放高一点看，MCP 的价值并不只是统一工具调用，而是为大模型应用建立一种更像工程系统的外部能力接入方式。

过去软件系统的核心问题，是服务与服务如何通过 API 协作；而在大模型时代，新的问题变成了模型如何在不确定推理过程中稳定地使用外部能力。这个问题比传统 API 集成更复杂，因为调用发起者不再是确定代码，而是一个会思考、会尝试、也会犯错的模型。

MCP 之所以重要，正是因为它把这个问题从零散适配、平台私有插件、工具硬编码，推进到了协议化、可发现、可治理的阶段。它不属于某个模型，不局限于某个宿主，也不只是工具调用的替代品。它更像是 Agent 时代的一层能力基础设施。

当然，MCP 并不是银弹。它不能替代模型能力本身，也不能替代工作流编排，更不能自动解决权限、安全和产品设计问题。如果把它神化，很容易在实践里失望。真正成熟的工程思路，是把它放在正确的位置上：作为能力接入层，与模型推理层、任务编排层、治理层和观测层协同工作。

如果说 API 定义了传统软件的连接方式，那么 MCP 很可能正在定义 AI 应用与真实世界能力之间的新连接方式。这个过程才刚刚开始，但它已经足够值得每一个做 Agent、Copilot 和 AI 工程系统的人认真理解。

---

~码文不易，留个赞再走吧~