关注微信公众号：Linux内核拾遗 文章来源：mp.weixin.qq.com/s/J7Xwy8ESe...
最近几乎所有做 AI 应用的人，都听过 MCP。
讨论很多，但真正的疑问其实只有一个：
人人都在聊 MCP，它到底解决了什么？
如果你只是调用大模型写写文案，答案可能并不重要。
但一旦你开始做 Agent、做工具调用、做「让模型真的参与系统工作」的事情，很快就会发现：
问题从来不在模型，而在模型之外。
模型要频繁切换，工具要不断接入；
上下文要被精细管理，权限和安全必须可控；
而当你试图用现有框架把这些拼起来时，复杂度并没有消失，只是换了一种形态。
- LangChain、LlamaIndex 提供了高度抽象的能力，但也带来了陡峭的学习曲线和越来越重的心智负担；
- Vercel AI SDK 体验流畅，却深度绑定具体技术栈，很难成为普适的工程基础设施。
在这些长期存在、无法靠"再封一层"解决的工程摩擦下，MCP 才真正显得有意义。
它并不是又一个 Agent 框架，而是在回答一个更基础的问题：
当模型不再只是聊天工具时，它到底应该通过什么方式，安全、清晰、可扩展地接入真实世界？
1. 什么是 MCP（Model Context Protocol）
MCP（Model Context Protocol，模型上下文协议）是 Anthropic 在 2024 年 11 月底提出的一种开放标准。
它做的事情很克制：
统一大模型与外部数据源、工具之间的通信方式。
注意几个关键词：
不是模型能力、不是推理方式，而是------通信协议。
在 MCP 出现之前，大模型想"用数据"，通常只有几种笨办法：
- 人工复制粘贴；
- 上传成知识库；
- 每接一个新系统，就手写一套定制逻辑。
这导致一个非常典型的问题：
模型越强，系统反而越难扩展。
MCP 的目标很明确：
在 AI 和数据（本地或远程）之间，搭一座标准化的桥。
只要遵循协议，就能互联，而不需要反复造轮子。
2. MCP、Function Calling 与 Agent 的关系
在讨论 MCP 之前，有三个概念如果不拆清楚，后面的理解一定会混乱：
Function Calling、MCP，以及 AI Agent。
先用一张表，把三者在工程体系中的位置一次性对齐。
| 维度 | MCP（Model Context Protocol） | Function Calling | AI Agent |
|---|---|---|---|
| 本质 | 开放通信协议 / 标准 | 模型内置能力机制 | 自主运行的智能系统 |
| 解决的问题 | 模型如何标准化、安全地访问外部能力 | 模型如何调用一个函数 | 模型如何完成一个目标 |
| 所处层级 | 系统集成与治理层 | 能力调用层 | 行为与决策层 |
| 是否是标准 | 是（开放标准） | 否（模型厂商实现） | 否（实现方式多样） |
| 与模型的关系 | 模型无关（Model-agnostic） | 强依赖模型原生支持 | 依赖模型能力 |
| 与工具的关系 | 统一管理工具、资源、上下文 | 直接调用函数 | 使用工具执行任务 |
| 是否关注权限与安全 | 协议内建为核心能力 | 基本不涉及 | 通常依赖底层实现 |
| 可复用性 | 高（跨模型、跨应用） | 低（一次性封装） | 取决于架构设计 |
| 工程复杂度 | 中 | 低 | 高 |
| 典型作用 | "我应该怎么调你、谁能调你" | "我能不能调你" | "我接下来要做什么" |
如果用一句工程化的话来总结三者的关系：
- Function Calling 解决的是 "模型能不能调用某个能力"。
- MCP 解决的是 "这些能力如何被规模化、规范化地接入系统"。
- AI Agent 解决的是 "在什么时机、以什么策略去使用这些能力"。
因此，三者并不是替代关系，而是天然的分层关系。
你可以只用 Function Calling 写一个 Demo；
也可以在没有 MCP 的情况下堆出一个 Agent；
但一旦系统开始变复杂------
Agent 的复杂度会被迫下沉，而 MCP 这层迟早会被补上。
这也是为什么 MCP 正在被越来越多真正做工程的人接受。
3. MCP 的真正价值：解决"信息孤岛"和工程不可扩展性
哪怕是最强的大模型，一旦脱离数据，也会迅速退化成"聪明但失明"的系统。
问题在于：
- 每个新数据源都要重新接入；
- 每个工具都要重新描述；
- 权限、安全、审计全靠人肉约定。
这在 Demo 阶段还能忍，一到工程化就会崩。
MCP 的价值不在于"连接万物"这句口号，而在于：
- 标准化上下文获取；
- 工具能力的可复用；
- 权限与安全的系统内收敛。
只要 MCP Server 按协议暴露能力，不同模型、不同 Agent、不同应用，都能直接使用。
这就是为什么 MCP 更像 HTTP，而不是某个框架。
4. MCP 的安全设计：为什么"敢让模型连真实系统"
"万物互联"听起来很美，但任何工程师都会本能地警惕：
那数据不就全裸奔了吗？
MCP 在这点上反而比很多现有方案更保守。
核心原则只有一个：
模型永远不直接接触敏感资源。
- MCP Server 自己控制资源访问；
- API Key 不需要暴露给 LLM 提供商；
- 请求必须经过验证和授权；
- 传输层支持加密。
换句话说：
即使模型被攻破，攻击面也被压缩在协议边界之外。
这也是 MCP 能被企业环境认真考虑的根本原因之一。
5. MCP 的工作原理与核心架构
从整体设计上看，MCP 并不复杂，它的核心思想只有一句话：
让模型只负责思考，让系统负责连接。
为此，MCP 采用了清晰的 Client--Server 架构，把职责边界切得很干净：
- MCP Host：发起请求的 AI 应用，例如 Claude Desktop、IDE、AI 工具；
- MCP Client：嵌在 Host 内部，与 MCP Server 建立一对一连接；
- MCP Server：对外暴露能力的服务端；
- 本地 / 远程资源：文件、数据库、API、系统能力。
在 MCP 体系中，真正关键的只有两个组件：MCP Client 和 MCP Server。
5.1 MCP Client
MCP Client 充当的是 LLM 与 MCP Server 之间的桥梁。
它并不负责"思考"，也不负责"执行"，而是把模型、工具和系统串成一个闭环。
一个典型的工作流程可以概括为：
- MCP Client 启动后，先从 MCP Server 获取当前可用的工具与能力描述；
- 将用户输入，连同这些工具描述，通过 Function Calling 一起交给 LLM；
- LLM 根据上下文判断：
- 是否需要使用工具；
- 使用哪个工具，以及对应参数；
- 如果需要调用工具，MCP Client 会将请求转发给 MCP Server；
- MCP Server 执行真实操作后，将结果返回给 MCP Client；
- MCP Client 再把结果作为上下文交回给 LLM；
- LLM 基于完整信息生成最终的自然语言响应，并呈现给用户。
在整个过程中，MCP Client 只做中转与适配，不包含业务逻辑，也不替模型做决策。
像 Claude Desktop、Cursor 这类工具，本质上都只是 MCP Client：
它们负责"连接和使用能力"，而不是"实现能力"。
5.2 MCP Server
如果说 MCP Client 是桥梁，那么 MCP Server 就是能力的源头和边界。
在 MCP 架构中，Server 是真正对外提供上下文与操作能力的组件，主要包括三类：
- 资源（Resources）：类似文件或数据内容，例如 API 响应、文件内容、数据库查询结果，通常以只读或受控方式提供。
- 工具（Tools）：可被 LLM 调用的操作函数，用来执行具体动作，通常需要用户授权。
- 提示（Prompts）：预先定义的提示模板，用于约束或引导模型完成特定任务。
这些能力共同构成了 MCP Server 对外暴露的"能力接口"，
而 权限控制、访问策略和底层实现细节，全部被收敛在 Server 一侧。
模型本身从不直接接触真实资源，
所有访问都必须通过 MCP Server 这道关口完成。
目前社区已经实现了大量 MCP Server，覆盖文件系统、数据库、开发工具、浏览器自动化、生产力工具等场景，可以通过在 MCP Servers Repository 和 Awesome MCP Servers 这两个 repo 中找到许多由社区实现的 MCP server。。
对上层应用来说，它们的存在意义只有一个：
能力可以被复用，而不必被反复实现。
6. 为什么 MCP 值得关注
MCP 并不会让你的模型突然变聪明。
但它会让你的系统：
- 更容易扩展，
- 更容易治理，
- 更不依赖某个具体框架或厂商。
当 AI 应用从"能跑"走向"长期运行"，
这种看起来无聊的协议层，反而会变成真正的基础设施。
关注微信公众号：Linux内核拾遗 文章来源：mp.weixin.qq.com/s/J7Xwy8ESe...