前言
前两天刘老师吐了个槽，印象里是个问句：大家猜猜 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 作为一个便宜（便宜坊的便宜）途径，在独占大模型环境是颇有吸引力的一种解决方案。
