MCP 是一座桥

前言

前两天刘老师吐了个槽，印象里是个问句：大家猜猜 KCD 为什么是 KCD？我觉得问得挺好的，所以作为 Kubernetes 老饼一张，我今天也来聊一点 AI 相关的事。

ChatGPT 横空出世之后，一直还是保持一点关注的，应该也交了几百刀的 AI 税了。除了聊天玩之外，也尝试使用流行的大模型解决一些实际问题，这一段时间以来，对于 AI 的有效使用大概归结成几种模式：

1. 洗稿：当然不是抄袭的那种，我经常会将要发表的文字交给 GPT 类的东西，帮我查查错字，部分字句进行润色等。
2. 翻译：传统翻译工具，包括 Deepl 在内，对于凌乱格式的文档（例如 PDF 中的胡乱换行、HTML 中的代码和标签等）都是力有不逮的，大模型对这种情况可以说是信手拈来。
3. 辅助开发：函数级的代码、单元测试的编写，还有代码的阅读解释，甚至是一些配置参数的跟踪、特定功能的查找和调试，目前不管是 Windsurf 还是 Cursor 的效果都远超我的预期。
4. 资料查询和整合：目前不管是 Search 还是 Research，都属于这个范畴。

除了这些工具类的东西，我有没有真的把大模型的能力融入到我的实际业务之中呢？你别说还真有。

运维老师傅

在运维现场，老师傅的最大价值之一就是：见多识广。然而在所有的主流大模型眼中，知名软件的日志信息毫无秘密可言。所以就随手写了个 Pipe2GPT 的小玩意，这东西现在一直在我的 Mac 和 Home Server 里呆着，随便遇到什么疑难 STDOUT/STDERR，Pipe 过去就行了。绝大多数情况下，能给出不弱于 StackOverflow 之类的结果，最重要的是说的的确是经过组织的人话，这点太重要了。

哄娃小工具

我有个工作流，效果是用广东话根据几个关键字生成童话故事，并使用方言 TTS 生成语音朗读给小朋友听——为保留粤语尽点绵薄之力？

调制和解调

其实跟翻译类似，让大模型的能力，对信息进行翻译和重整，使之生成新的信息模式，包括但不限于：

1. 从自然语言的网页，例如公告、通知等信息中，提取规范化信息，交由其它系统进一步的处理。这种应用方式非常广泛，非常适合小打小闹的做一些趁手的搜集工作。
2. 云 SDK 到 IaC：就拿虚拟机来说，同样的 4 核 8G，每个厂商都提供了多种机型可选，在 Terraform 的 Provider 之中，又有各种不同的表达。而有了大模型的辅助，反倒是可以轻松地在不同厂商 SDK 格式、不同的 IaC 代码之间进行转换。

…

然而这蹭热度的过程中，一直有些粗糙的感觉，应用侧和模型侧始终是泾渭分明、各自为战。训练练不起，对接呢，因为个人架构能力有限，每次都会因为需求的微小差异，进行大量的代码调整。尤其是和一些商业数据系统对接时，缺乏最佳实践的指导，由此产生草台班子的感觉会让人非常受挫。

MCP

前不久看到了 Cloude MCP，感觉这高冷的大模型开始有味道了。总算可以有办法，将“传统”服务和系统，跟各种大模型能够相对规矩的对接起来。

MCP 是 Model Context Protocol 的缩写。官方简介称：

模型上下文协议（MCP）是一种开放式协议，可实现 LLM 应用程序与外部数据源和工具之间的无缝集成。无论您是要构建人工智能驱动的集成开发环境、增强聊天界面，还是要创建自定义的人工智能工作流，MCP 都能提供一种标准化的方式，将 LLM 与它们所需的上下文连接起来。

目前已经提供了 TypeScript、Python、Java 和 Kotlin 的 SDK。

官方提供的架构图如下所示：

从核心上讲，MCP 遵循客户端-服务器架构，其中主机应用程序可以连接到多个服务器：

flowchart LR     subgraph "Your Computer"         Host["MCP 客户端(Claude, IDEs, Tools)"]         S1["MCP Server A"]         S2["MCP Server B"]         S3["MCP Server C"]         Host <-->|"MCP Protocol"| S1         Host <-->|"MCP Protocol"| S2         Host <-->|"MCP Protocol"| S3         S1 <--> D1[("本地数据源 A")]         S2 <--> D2[("本地数据源 B")]     end     subgraph "Internet"         S3 <-->|"Web APIs"| D3[("远端服务 C")]     end 

• MCP Hosts
  : 例如 Claude Desktop、集成开发环境 (IDEs) 或希望通过 MCP 访问数据的 AI 工具
• MCP Clients
  : 与服务器建立一对一连接的协议客户端
• MCP Servers
  : 轻量级程序，通过标准化的 Model Context Protocol 提供特定功能
• 本地数据源
  : 您计算机上的文件、数据库和服务，MCP 服务器可以安全访问它们
• 远程服务
  : 通过网络（如 API）可访问的外部系统，MCP 服务器能与之连接

从架构图中可以看到，MCP 定义了一种行为规范及其依赖的通信方式和对应的对象。LLM 客户端应用，作为 MCP Client，通过 MCP Server，和本地资源、外部服务连接起来，从而形成了完整的数据通路，让 MCP Server 所提供的数据和能力，直接在 LLM 客户端应用中得以使用。

MCP 中的核心概念包括用于描述原子能力的资源（Resource）和工具（Tool），用于复用提示词的（Prompt），以及能够控制文本生成的 Sampling 能力。除了这些能力之外，对于传输、安全、敏感信息等，也提出了相对完善的建议和最佳实践。因此虽然存在只能本地调用等短板，MCP 仍然不失为一个开拓 LLM 应用的一个非常有用的方向（不够好没关系，Who can who up 就是了）。

例子

官网文档里提供了一个天气预报的 Sample，这个例子很典型：从外部服务获取实时信息作为上下文在 LLM 中进行使用。这个例子分为三个部分：

1. 服务端，提供了多种语言的开发方法，其中定义了 get_forcast 和 get_alert 两个 Tool
2. 客户端：如何创建 Bot 并使用前面开发的 MCP 服务器
3. Cloude App 中如何使用 MCP Server。

例子中表达的主要“业务”就是在 LLM 中获取（美国）的天气信息，并结合 LLM 自有能力来响应用户需求。

提问时发生了什么？

1. 客户端把问题发送给 Claude
2. Claude 分析可用的工具并决定使用哪一个
3. 客户端通过 MCP 服务器执行所选工具
4. 结果被发回给 Claude
5. Claude 根据响应内容回答问题

在 Cloude App 中启用 MCP

App 属性窗口中，Developer Tab 直接编辑 Settings，加入如下定义就可以得到：

{     "mcpServers": {         "weather": {             "command": "uv",             "args": [                 "--directory",                 "/ABSOLUTE/PATH/TO/PARENT/FOLDER/weather",                 "run",                 "weather.py"             ]         }     } } 

启用 Server 之后，在 Cloude 聊天窗口输入框右下方会出现一个 ? 图标，点击后就可以展示当前启用 MCP Server 所提供的 Tools 了。

生态

目前支持 MCP 的工具还是颇有一些的，官方列表：https://modelcontextprotocol.io/clients

官方列出的示例服务：https://modelcontextprotocol.io/examples

mcp.so 中列出了超过 2000 个 MCP Server。

展望

MCP 的整体实现是较为简洁的，这一方面方便参与，另一方面就是碎片化的前兆。目前来说仅能支持本地，很大程度上消减了可能的性能和安全性问题，但是对于自动化、实时性要求来说，MCP 目前体现的能力还是不很清晰的。

综上，跟社区的普遍思路不太一样，个人认为 MCP 作为一个便宜（便宜坊的便宜）途径，在独占大模型环境是颇有吸引力的一种解决方案。