随着大模型的快速发展，如何让模型与企业数据、工具高效对接成为核心挑战。传统方式需为每个数据源/工具编写定制化代码，导致开发成本高、扩展性差、安全性低，形成“烟囱式开发”。

如何让大语言模型与外部系统交互，已经成为AI系统急需解决的问题。从2023年到现在，业界也有过多种尝试，我们也一起来梳理一下：

 

2024年11月25日Anthropic 发布的文章： Introducing the Model Context Protocol ，标志着MCP协议诞生。

按照博文所说：MCP （Model Context Protocol，模型上下文协议）为连接 AI 系统和数据源提供了一个通用的开放标准，用单一协议取代了分散的集成。换一个说法是 以一致的方式将各种数据源、工具和功能连接到 AI 模型中间协议。可以说MCP协议类似大家现在使用的type-c接口，可以让不同的设备通过相关的接口协议连接在一起，组成不同功能的系统。更通俗的方式类比是，你拿着一个万能翻译器，去不同的国家和地区旅游，可以以不同的人员通过万能翻译器实时对话，这个万能翻译器就是MCP协议。

针对MCP有几点需要注意：

Agent能力	MCP特性
工具（技能）调用	Tool
LUI 交互	Prompt
感知	Resource（Changed Notification）
深度思考	Resource（Listing/Reading Resources）

那为什么需要MCP协议呢？下面通过一张图来说明。

可以看到，MCP协议将原本M×N集成问题（M AI客户端×N数据源）转化为M+N问题-任何MCP兼容的AI客户端都可以与任何MCP兼容的数据源或工具一起工作。

为什么需要MCP？

总之出现MCP，根本原因是 大模型百家争鸣，各有所长并且数据孤岛的壁垒无法打破。

MCP作为连接AI模型与外部系统的标准化协议，其核心价值在于打破数据孤岛、提升模型交互能力，并推动AI从“被动响应”向“主动执行”转型。目前可以预知到的MCP的应用场景有四大核心场景。

军政、金融、医疗等强监管行业需对AI访问权限进行细粒度控制，例如限制模型仅读取脱敏数据或禁止写入关键系统。通过MCP的数据沙箱机制和权限审批流程，实现动态策略调整与操作审计，满足GDPR、HIPAA等法规要求。MCP 服务器可以支持不同的访问策略并且可以实现访问时进行身份验证，有效地充当AI模型和企业之间的门神。内部数据的获取和响应都是通过MCP服务器，类似数据网关，实时监控模型行为，发现异常（如数据泄露风险）时自动触发防护机制（如阻断敏感API调用）。

AI模型对过去交互的记忆有限，因此在推理时提供相关的、实时的上下文至关重要。MCP服务器连接实时数据源（如OS Drive、Slack、数据库），确保AI响应基于最新信息（如客户最新订单、库存状态）。通过MCP资源功能加载专业文档（如法律条款、产品手册），提升AI在垂直领域的专业性（如法律咨询、技术支持）。通过MCP服务器允许AI模型可以在需要的时候从指定的渠道获取到相关的数据甚至可以进行相关的操作。比如创建一个Excel文档将收集和整理好的简历写入。在客服场景中，可以关联用户的信息（订单、兴趣、）和之前与客服的沟通内容，结合企业内的SOP，为用户解决问题。还有在AI编码的场景也是有很好的应用，AI模型可以通过MCP服务器获取git仓库的代码和接口文档、产品设计、方案设计甚至是编码规范，可以为程序员提供更好的编码提示和建议。

同时，使用结构化格式传递信息避免歧义，可以更有效地指导AI模型推理。更可靠的知识源，结合结构化的数据上下文，AI模型就可以应用在要求可靠性更高的场景，比如医疗诊断。

试想一下，这样的场景。用户反馈APP的一个bug上来后，AI模型自动根据Git 的MCP服务器，结合产品文档需求和用户描述，自动化实现bug修复并通过CI/CD MCP服务器实现服务上线。MCP协议将会是AI模型和各个工具之间互联互动的桥梁。MCP如果成为了标准协议，将各个AI模型和丰富的工具和平台链接起来，打破信息孤岛，让AI的自动化升级为AI智能化。MCP可以成为AI模型对工具和平台的监督和驱动大脑，让它们协同的完成工作。

对于不同的企业和平台来说，MCP可以让不同AI模型的能力获取最大化，也建议让AI模型方案统一化。 AI模型不应该只是在浏览器上，也不应该只是在APP应用上，而是应该集成到操作系统中，在系统层面获得更大的能力。

MCP作为企业内部AI Agent的“数据总线”，整合CRM、MES等多系统数据，例如制造业AI Agent通过MCP协调IoT传感器与生产调度系统。企业部署MCP驱动的虚拟助手，可统一响应员工IT支持、审批进度查询等需求，响应时效缩短至秒级。在医院，可通过MCP构建AI助手，实时分析患者病史并提醒医生药物相互作用风险。MCP可以让Agent的构建更加强大。

MCP本质还是一种C/S架构，官方给出的架构图：

MCP 由三个核心组件构成：Host、Client 和 Server。

MCP的规范中协议层、传输层和消息类型：

MCP 目前定义了两种标准的 client-server通信传输机制：stdio（标准输入输出）和基于 SSE 的 HTTP。此外，客户端和服务器也可以以可插拔的方式实现自定义传输机制。

通信传输机制	部署方式	网络要求	场景	应用
Stdio transport 标准传输	本地子进程	无需网络	本地开发 高效实现同机通讯 简单的流程管理	filesystem
HTTP with SSE transport 带有 SSE 传输的 HTTP	独立服务器进程	需要网络连接	分布式部署、多客户端 对于需要 HTTP 兼容性的场景使用 SSE 考虑安全影响，包括身份验证和授权	search

所有在 MCP clients 和 servers 之间的消息必须遵循 JSON-RPC 2.0 规范，基于 JSON-RPC 2.0，确保消息格式结构统一。该协议定义了三种基本类型的消息：

消息类型	描述	约束
Requests	用于具体操作的消息	必须包含唯一的 ID 和方法名称 ID 不能为 null 请求 ID 在同一会话中不得被请求者之前使用过
Responses	请求的响应	必须包含与请求相同的 ID 必须设置 result 或 error 之一。不得同时出现 错误代码必须是整数
Notifications	单向消息，不需要回复	不得包含 ID

Requests可以从Client端或者Server端发起，其格式为：

 { jsonrpc: "2.0"; id: string | number; method: string; params?: { [key: string]: unknown; }; }

在MCP Server中对请求需要做到：

在MCP中定义的requests的业务类型：

表格 还在加载中，请等待加载完成后再尝试复制

initialized是非常重要的阶段，是MCP Client和MCPServer之间的第一次交互。类似HTTPS一样需要确认彼此协议版本的兼容性、交换和协商各自能力。Client 必须发送其支持的协议版本，如果server支持请求的协议版本，则必须以相同的版本进行响应。否则，server必须以其支持的其他协议版本进行响应。这应该是server支持的最新版本。

initialized能力协商

表格 还在加载中，请等待加载完成后再尝试复制

Prompts

MCP还提供Prompt能力，可将重复使用的提示模板和工作流程放在Server以便Client使用。Prompts的主要价值是对Resource的内容进行解释，让LLMs能够更好的理解返回的数据，从而更好的完成任务。

Responses是对requests的回复，其格式为：

 { jsonrpc: "2.0"; id: string | number; result?: { [key: string]: unknown; } error?: { code: number; message: string; data?: unknown; } }

MCP的核心就是将资源暴露给到AI模型，Response的类型是多种多样的，有文本、二进制文件、API等等。Server拥有的Responses如何让AI模型知道呢？这就需要Direct resources直连资源，MCP Server 通过esources/list 端点公开固定的资源列表，每个资源的属性包含：

 { uri: string; // Unique identifier for the resource name: string; // Human-readable name description?: string; // Optional description mimeType?: string; // Optional MIME type }

如果Server端的Responses的生成是动态资源，那么还可以通过Resource templates来支持。在实际中，Server的Resource并不会固定不变，而是时常变化，MCP提供了资源更新（Resource updates）机制：

机制类型	机制描述	应用场景	核心特点
资源列表变更通知	服务器通过notifications/resources/list_changed通知客户端资源列表结构性变化	目录结构变动、新增资源类型等全局性更新	结构化变更推送 客户端需主动拉取更新
资源内容实时订阅	客户端通过resources/subscribe订阅资源，服务器通过notifications/resources/updated推送变更	日志文件追加、API数据刷新等动态内容更新	支持实时推送 可随时取消订阅 客户端主动拉取最新内容
Streamable HTTP传输	新增流式传输协议，支持断点续传、无状态服务器及动态SSE升级	高并发场景、云平台部署、需要兼容CDN/API网关的场景	断点续传解决掉线问题 无状态服务器降低部署成本 兼容标准HTTP生态

现在AI模型已经知道Server有哪些资源了，还需要可以读取到这么Resource，就需要使用resources/read请求。

 

在MCP Server中对响应需要做到：

Notifications是从client 发送到server 或反向发送的，不需要回复。其格式为：

 { jsonrpc: "2.0"; method: string; params?: { [key: string]: unknown; }; }

本小节以github.com/mark3labs/mcp-filesystem-server 为例介绍MCP相关的消息类型。

Request

 { "jsonrpc": "2.0", "id": 12, "method": "initialize", "params": { "protocolVersion": "1.0", "capabilities": { "roots": { "listChanged": true } }, "clientInfo": { "name": "test-client", "version": "1.0.0" } } }

Responses

 { "jsonrpc": "2.0", "id": 12, "result": { "protocolVersion": "2024-11-05", "capabilities": { "resources": { "subscribe": true, "listChanged": true }, "tools": { } }, "serverInfo": { "name": "secure-filesystem-server", "version": "0.4.1" } } }

Request

 { "jsonrpc": "2.0", "id": 12, "method": "tools/list", "params": { } }

Responses

 { "jsonrpc": "2.0", "id": 12, "result": { "tools": [ { "description": "Create a new directory or ensure a directory exists.", "inputSchema": { "type": "object", "properties": { "path": { "description": "Path of the directory to create", "type": "string" } }, "required": [ "path" ] }, "name": "create_directory" }, { "description": "Retrieve detailed metadata about a file or directory.", "inputSchema": { "type": "object", "properties": { "path": { "description": "Path to the file or directory", "type": "string" } }, "required": [ "path" ] }, "name": "get_file_info" }, { "description": "Returns the list of directories that this server is allowed to access.", "inputSchema": { "type": "object" }, "name": "list_allowed_directories" }, { "description": "Get a detailed listing of all files and directories in a specified path.", "inputSchema": { "type": "object", "properties": { "path": { "description": "Path of the directory to list", "type": "string" } }, "required": [ "path" ] }, "name": "list_directory" }, { "description": "Move or rename files and directories.", "inputSchema": { "type": "object", "properties": { "destination": { "description": "Destination path", "type": "string" }, "source": { "description": "Source path of the file or directory", "type": "string" } }, "required": [ "source", "destination" ] }, "name": "move_file" }, { "description": "Read the complete contents of a file from the file system.", "inputSchema": { "type": "object", "properties": { "path": { "description": "Path to the file to read", "type": "string" } }, "required": [ "path" ] }, "name": "read_file" }, { "description": "Recursively search for files and directories matching a pattern.", "inputSchema": { "type": "object", "properties": { "path": { "description": "Starting path for the search", "type": "string" }, "pattern": { "description": "Search pattern to match against file names", "type": "string" } }, "required": [ "path", "pattern" ] }, "name": "search_files" }, { "description": "Create a new file or overwrite an existing file with new content.", "inputSchema": { "type": "object", "properties": { "content": { "description": "Content to write to the file", "type": "string" }, "path": { "description": "Path where to write the file", "type": "string" } }, "required": [ "path", "content" ] }, "name": "write_file" } ] } }

Request

 { "jsonrpc": "2.0", "id": 12, "method": "tools/call", "params": { "name": "list_allowed_directories", "arguments": { "path": "/Users/ouerqiang/Downloads/1.txt" } } }

Responses

 { "jsonrpc": "2.0", "id": 12, "result": { "content": [ { "type": "text", "text": "Allowed directories:\n\n/Users/ouerqiang/project/gopath/src/github.com/mark3labs/mcp-filesystem-server (file:///Users/ouerqiang/project/gopath/src/github.com/mark3labs/mcp-filesystem-server)\n/Users/ouerqiang/Downloads (file:///Users/ouerqiang/Downloads)\n" } ] } }

Request

 { "jsonrpc": "2.0", "id": 12, "result": { "content": [ { "type": "text", "text": "Allowed directories:\n\n/Users/ouerqiang/project/gopath/src/github.com/mark3labs/mcp-filesystem-server (file:///Users/ouerqiang/project/gopath/src/github.com/mark3labs/mcp-filesystem-server)\n/Users/ouerqiang/Downloads (file:///Users/ouerqiang/Downloads)\n" } ] } }

Responses

 { "jsonrpc": "2.0", "id": 12, "resources": [ { "uri": "file://", "name": "File System", "description": "Access to files and directories on the local file system" } ] }

其他的格式就请各位同学自行去验证。

MCP 服务器可以提供三种主要类型的功能：

上面的三个功能并不要求MCP Server全部提供，可以提供一种或者多种类型的功能。

 

看着也是在MCP Server实现了对外部服务的API对接给到AI模型，为什么还需要多加MCP，直接让AI模型直接调用外部服务API不是更好吗？这是因为，MCP 不仅实现了 API 的功能，还带来了更高的标准化和灵活性。

表格 还在加载中，请等待加载完成后再尝试复制

 

对于大多数开发者而言，主要开发的模块还是MCP Server，而MCP Client 主要面对的还是直接的用户。客户端可以向服务器提供以下功能：

在业界中也有很多支持MCP 的应用程序，每个客户端可能支持不同的 MCP 功能，从而允许与 MCP 服务器进行不同程度的集成。

https://modelcontextprotocol.io/clients

本人主要使用Golang为主，但是官网上只提供了Python、TypeScript、Java、Kotlin的SDK，并未提供golang。我也查看了github库，也亲身验证了一些框架，目前比较好的Go MCP框架有两个：

我们可以对比一下这两个框架。

表格 还在加载中，请等待加载完成后再尝试复制

表格 还在加载中，请等待加载完成后再尝试复制

从代码的设计、使用灵活度和对外部框架的集成而言，使用 metoro-io/mcp-golang是不错的选择。

MCP作为Anthropic开源的AI系统与数据源交互协议，凭借其统一性、可控性和高效性在AI集成领域展现出潜力。该协议通过标准化工具调用、资源访问和提示模板，解决了传统插件或自定义工具开发的高成本问题，尤其为非技术人员提供了便捷的AI能力扩展途径。例如，开发者可通过MCP Server快速暴露功能，供Claude、Cursor等客户端直接调用，显著提升跨系统协作的灵活性。

然而，MCP仍面临多重挑战。协议公布仅半年，主流编程语言（如Go、Rust）的支持尚不完善，生态建设仍处于早期阶段，可用工具数量和质量难以满足复杂场景需求。同时，LangChain创始人Nuno Campos指出，当前模型对工具的调用成功率仅约50%，且MCP的双向通信机制和本地化部署方式增加了实现复杂度，对比IBM新推出的ACP协议，其在无状态设计、跨平台兼容性等方面可能存在劣势。

尽管如此，MCP的前景值得期待。随着基础模型能力的迭代优化，工具调用准确率有望提升。若协议能进一步简化部署流程（如云端托管）、扩大语言支持范围，并借助社区力量构建高质量工具生态，其有望成为连接AI系统与现实世界的核心桥梁。正如Harrison Chase所言，MCP的核心价值在于为不可控的第三方Agent提供标准化接入方案，这种开放性使其在长尾场景中具备持久生命力。

一句话，MCP未来可期！

 

https://www.anthropic.com/news/model-context-protocol

https://mp.weixin.qq.com/s/WndS_QSbQFalFvBcGzur4A

https://mp.weixin.qq.com/s/kQrltrzRk-SVLfWm_zsPoA

https://github.com/CherryHQ/cherry-studio/releases/tag/v1.1.7