Agent 工程化系列 · 第 06 篇

MCP 是什么协议？为什么被称为 AI 应用的 USB-C？

从工具接入到上下文标准化，讲清 Agent 如何连接外部世界。

目录

• 00 开篇定位：这一篇讲什么
• 01 为什么需要 MCP？
• 02 MCP 一句话讲清楚
• 03 MCP 的三层角色：Host、Client、Server
• 04 MCP Server 暴露什么能力？
• 05 MCP 是怎么工作的？
• 06 MCP 和 Function Call 的关系
• 07 工程落地：本地、远程与安全边界
• 08 最后总结

---

00 开篇定位：这一篇讲什么

这一篇继续沿着 Agent 工程化系列往下走。前两篇我们把 LLM、Agent、Workflow 的边界讲清楚；第 04、05 篇讲了 Function Call 是什么，以及它在底层如何把“自然语言意图”变成“结构化工具调用”。

但真正做工程时，很快会遇到一个更大的问题：如果一个 Agent 要连接文件系统、数据库、浏览器、代码仓库、企业内部系统，难道每接一个工具都要单独写一套适配吗？

MCP 要解决的，正是这个问题。它不是一个新模型，也不是一个 Agent 框架，而是一套让 AI 应用标准化连接外部工具和上下文的协议。

---

01 为什么需要 MCP？

先看一个很现实的工程场景：你做了一个企业内部 Agent，它需要读取项目文档、查询数据库、访问 Git 仓库、调用工单系统、甚至触发自动化脚本。

如果没有统一协议，每个 AI 应用都要分别适配每个外部系统：A 应用接数据库写一套，B 应用接数据库再写一套；A 应用接 GitHub 写一套，B 应用又写一套。时间一长，就会变成典型的 N × M 集成问题。

MCP 的出现，本质上是为了把“AI 应用接外部能力”这件事标准化。AI 应用只需要理解 MCP，外部系统只要实现 MCP Server，就能以统一方式暴露能力。

所以，MCP 不是为了让大模型本身更强，而是为了让 Agent 更容易、安全、可复用地连接外部世界。

---

02 MCP 一句话讲清楚

MCP，全称是 Model Context Protocol，可以理解为：给 AI 应用连接工具、数据源和上下文的一套标准协议。

官方规范把 MCP 定义为一种开放协议，用于让 LLM 应用和外部数据源、工具实现无缝集成。它提供的不是某一个具体工具，而是一套“怎么描述能力、怎么发现能力、怎么调用能力、怎么返回结果”的通信方式。

用更通俗的话说：Function Call 解决“模型怎么发出一次工具调用意图”；MCP 解决“这些工具和上下文如何被标准化接入 AI 应用”。

这也是为什么很多人把 MCP 比作 AI 应用里的 USB-C：USB-C 不是键盘、鼠标、显示器本身，但它提供了一个统一接口，让设备可以按同一种方式连接外设。MCP 也是类似的角色。

---

03 MCP 的三层角色：Host、Client、Server

理解 MCP，最重要的是先分清三个角色：Host、Client、Server。

Host 是用户真正使用的 AI 应用，比如一个 AI IDE、桌面助手、企业内部 Agent 平台。它负责用户交互、模型调用、任务编排，以及最终结果展示。

Client 是运行在 Host 里面的连接器。一个 Host 可以连接多个 MCP Server，通常每个 Server 会对应一个 Client 连接。Client 负责建立会话、能力协商、转发请求和接收结果。

Server 是真正提供能力的一侧。它可以连接文件系统、数据库、Git 仓库、浏览器、企业业务系统，也可以暴露某些工具函数、上下文资源或提示模板。

这三者的关系可以理解为：用户在 Host 里提出目标；Host 通过 Client 连接到一个或多个 Server；Server 把自己能提供的能力按 MCP 规范暴露出来。

---

04 MCP Server 暴露什么能力？

MCP Server 最常见的能力可以分成三类：Tools、Resources、Prompts。

Tools 是“可执行动作”。比如查询天气、搜索文档、创建工单、运行脚本、读取数据库、调用业务 API。它更接近我们前面讲过的 Function Call：模型判断需要某个能力时，可以通过工具调用来触发执行。

Resources 是“可读取上下文”。比如项目文件、数据库表结构、业务知识库、日志片段、订单记录等。它的重点不是执行动作，而是把真实上下文提供给模型，降低模型凭空编造的概率。

Prompts 是“可复用提示模板”。比如某个团队内部的代码审查模板、故障分析模板、日报生成模板。它适合把高频任务的提示词沉淀成标准入口。

从工程视角看，Tools 让 Agent 会做事，Resources 让 Agent 有上下文，Prompts 让 Agent 的任务入口更稳定。

---

05 MCP 是怎么工作的？

MCP 的通信不是靠“模型随便猜”，而是基于明确的协议消息。官方规范要求 MCP 客户端和服务器之间的消息遵循 JSON-RPC 2.0。

一次典型流程可以拆成六步：第一，Host 中的 Client 与 MCP Server 建立连接；第二，双方初始化并进行能力协商；第三，Client 获取 Server 暴露的工具、资源和提示模板；第四，模型在任务过程中判断是否需要调用某个能力；第五，Client 通过 MCP 请求 Server 执行；第六，Server 返回结果，模型再把结果整合成用户能看懂的回答。

这里要注意一个关键点：MCP Server 并不是直接把所有数据都塞进模型上下文。它更像一个标准化能力提供方。模型需要什么、应用允许什么、Server 能提供什么，要通过协议和应用层策略共同决定。

这也是 MCP 比普通 API 封装更进一步的地方：它不仅有调用，还包含能力发现、上下文资源、提示模板、会话生命周期和权限边界。

---

06 MCP 和 Function Call 的关系

很多人会问：既然已经有 Function Call，为什么还需要 MCP？

简单说，Function Call 更像一次工具调用机制；MCP 更像工具和上下文的接入协议。Function Call 关注的是模型如何输出“调用哪个函数、传什么参数”；MCP 关注的是一个外部系统如何把自己的工具、资源和提示模板标准化暴露给 AI 应用。

在实际系统里，两者不是替代关系，而是协作关系。MCP Server 暴露的 Tools，最终往往仍会以模型可调用工具的形式进入 Agent 执行链路。模型看到的是可用工具，应用侧通过 MCP Client 把调用请求转给对应 Server。

所以可以这样理解：Function Call 是“调用动作”；MCP 是“能力接入层”。Agent 真正落地时，往往需要两者配合。

---

07 工程落地：本地、远程与安全边界

MCP 工程落地时，第一件事不是“接多少工具”，而是判断 Server 跑在哪里、权限给多少、哪些调用需要审批。

常见形态有两类：一类是本地 MCP Server，比如本地文件系统、开发工具、代码仓库辅助能力，通常适合通过 stdio 或本地 HTTP 通信；另一类是远程 MCP Server，比如云端服务、SaaS 系统、企业内部接口，通常更依赖 HTTP 传输、认证授权和网络边界控制。

OpenAI Agents SDK 文档中也把 MCP Server 形态拆成 Hosted MCP、Streamable HTTP、stdio 等不同方式，并明确提到 SSE 已属于旧式传输形态，新集成更推荐 Streamable HTTP 或 stdio。

安全上一定要克制：不要默认信任第三方 MCP Server；不要让模型直接拥有过大权限；敏感操作要有人确认；工具参数要校验；调用过程要可观测；返回结果也要防 Prompt Injection。

Agent 一旦可以调用工具，就不只是“回答错”的风险，而是“执行错”的风险。MCP 把连接标准化了，但不等于自动把安全做好了。

---

08 最后总结

MCP 可以看成 Agent 工程里的“协议层”。它解决的核心问题不是模型推理，而是外部能力接入。

如果说 LLM 是大脑，Agent 是执行系统，Function Call 是一次工具调用动作，那么 MCP 就是在系统层面规定：工具、数据源和上下文应该如何被发现、描述、调用和返回。

它让 AI 应用不必为每个外部系统重复造轮子，也让工具生态可以通过统一协议被更多 Agent 复用。

但同时要记住：MCP 是连接能力，不是安全保证。真正生产可用的 Agent 系统，还必须在权限、审批、审计、隔离和可观测性上继续做工程设计。

下一篇，我们会继续看 MCP 解决的实际问题：它为什么不只是“能调工具”，而是解决了 Agent 工具生态碎片化的问题。

---

参考资料

• Model Context Protocol Specification 2025-11-25
• MCP Basic Overview: JSON-RPC、生命周期、Server Features 与 Client Features
• MCP Authorization: OAuth 2.1 与 HTTP-based transports
• OpenAI Agents SDK: Model Context Protocol integration
• OpenAI API: MCP and Connectors
• Anthropic: Introducing the Model Context Protocol