MCP 是一座桥
前言
前两天刘老师吐了个槽,印象里是个问句:大家猜猜 KCD 为什么是 KCD?我觉得问得挺好的,所以作为 Kubernetes 老饼一张,我今天也来聊一点 AI 相关的事。
ChatGPT 横空出世之后,一直还是保持一点关注的,应该也交了几百刀的 AI 税了。除了聊天玩之外,也尝试使用流行的大模型解决一些实际问题,这一段时间以来,对于 AI 的有效使用大概归结成几种模式:
- 洗稿:当然不是抄袭的那种,我经常会将要发表的文字交给 GPT 类的东西,帮我查查错字,部分字句进行润色等。
- 翻译:传统翻译工具,包括 Deepl 在内,对于凌乱格式的文档(例如 PDF 中的胡乱换行、HTML 中的代码和标签等)都是力有不逮的,大模型对这种情况可以说是信手拈来。
- 辅助开发:函数级的代码、单元测试的编写,还有代码的阅读解释,甚至是一些配置参数的跟踪、特定功能的查找和调试,目前不管是 Windsurf 还是 Cursor 的效果都远超我的预期。
- 资料查询和整合:目前不管是 Search 还是 Research,都属于这个范畴。
除了这些工具类的东西,我有没有真的把大模型的能力融入到我的实际业务之中呢?你别说还真有。
运维老师傅
在运维现场,老师傅的最大价值之一就是:见多识广。然而在所有的主流大模型眼中,知名软件的日志信息毫无秘密可言。所以就随手写了个 Pipe2GPT 的小玩意,这东西现在一直在我的 Mac 和 Home Server 里呆着,随便遇到什么疑难 STDOUT/STDERR,Pipe 过去就行了。绝大多数情况下,能给出不弱于 StackOverflow 之类的结果,最重要的是说的的确是经过组织的人话,这点太重要了。
哄娃小工具
我有个工作流,效果是用广东话根据几个关键字生成童话故事,并使用方言 TTS 生成语音朗读给小朋友听——为保留粤语尽点绵薄之力?
调制和解调
其实跟翻译类似,让大模型的能力,对信息进行翻译和重整,使之生成新的信息模式,包括但不限于:
- 从自然语言的网页,例如公告、通知等信息中,提取规范化信息,交由其它系统进一步的处理。这种应用方式非常广泛,非常适合小打小闹的做一些趁手的搜集工作。
- 云 SDK 到 IaC:就拿虚拟机来说,同样的 4 核 8G,每个厂商都提供了多种机型可选,在 Terraform 的 Provider 之中,又有各种不同的表达。而有了大模型的辅助,反倒是可以轻松地在不同厂商 SDK 格式、不同的 IaC 代码之间进行转换。
…
然而这蹭热度的过程中,一直有些粗糙的感觉,应用侧和模型侧始终是泾渭分明、各自为战。训练练不起,对接呢,因为个人架构能力有限,每次都会因为需求的微小差异,进行大量的代码调整。尤其是和一些商业数据系统对接时,缺乏最佳实践的指导,由此产生草台班子的感觉会让人非常受挫。
MCP
前不久看到了 claude MCP,感觉这高冷的大模型开始有味道了。总算可以有办法,将“传统”服务和系统,跟各种大模型能够相对规矩的对接起来。
MCP 是 Model Context Protocol 的缩写。官方简介称:
模型上下文协议(MCP)是一种开放式协议,可实现 LLM 应用程序与外部数据源和工具之间的无缝集成。无论您是要构建人工智能驱动的集成开发环境、增强聊天界面,还是要创建自定义的人工智能工作流,MCP 都能提供一种标准化的方式,将 LLM 与它们所需的上下文连接起来。
目前已经提供了 TypeScript、Python、Java 和 Kotlin 的 SDK。
官方提供的架构图如下所示:
从核心上讲,MCP 遵循客户端-服务器架构,其中主机应用程序可以连接到多个服务器:
- 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 中进行使用。这个例子分为三个部分:
- 服务端,提供了多种语言的开发方法,其中定义了
get_forcast
和get_alert
两个 Tool - 客户端:如何创建 Bot 并使用前面开发的 MCP 服务器
- claude App 中如何使用 MCP Server。
例子中表达的主要“业务”就是在 LLM 中获取(美国)的天气信息,并结合 LLM 自有能力来响应用户需求。
提问时发生了什么?
- 客户端把问题发送给 Claude
- Claude 分析可用的工具并决定使用哪一个
- 客户端通过 MCP 服务器执行所选工具
- 结果被发回给 Claude
- Claude 根据响应内容回答问题
在 claude App 中启用 MCP
App 属性窗口中,Developer Tab 直接编辑 Settings,加入如下定义就可以得到:
{
"mcpServers": {
"weather": {
"command": "uv",
"args": [
"--directory",
"/ABSOLUTE/PATH/TO/PARENT/FOLDER/weather",
"run",
"weather.py"
]
}
}
}
启用 Server 之后,在 claude 聊天窗口输入框右下方会出现一个 🔨 图标,点击后就可以展示当前启用 MCP Server 所提供的 Tools 了。
生态
目前支持 MCP 的工具还是颇有一些的,官方列表:https://modelcontextprotocol.io/clients
官方列出的示例服务:https://modelcontextprotocol.io/examples
mcp.so
中列出了超过 2000 个 MCP Server。
展望
MCP 的整体实现是较为简洁的,这一方面方便参与,另一方面就是碎片化的前兆。目前来说仅能支持本地,很大程度上消减了可能的性能和安全性问题,但是对于自动化、实时性要求来说,MCP 目前体现的能力还是不很清晰的。
综上,跟社区的普遍思路不太一样,个人认为 MCP 作为一个便宜(便宜坊的便宜)途径,在独占大模型环境是颇有吸引力的一种解决方案。