前段时间有位同行大佬抛了个问题：KCD 为什么叫 KCD？这个问题问得挺有意思。作为一个在 Kubernetes 领域摸爬滚打多年的“老饼”，今天也想聊聊 AI 相关的一些实践观察。
打从 ChatGPT 横空出世那会儿起，就一直在持续关注，前前后后也交了几百美元的“AI 税”。除了日常聊天消遣，确实也尝试用主流大模型解决过一些实际问题。这一路摸索下来，AI 的有效用法，大概可以归纳成这么几种模式：
- 润色和校对。这可不是抄袭那种。经常把要发布的文字丢给 GPT 类工具，帮忙检查错别字、润色语句，确实省心不少。
- 翻译。传统翻译工具，哪怕强大如 DeepL，面对格式混乱的文档（比如 PDF 里乱换行、HTML 里掺杂代码标签）往往也力不从心，而大模型处理这种“脏活”简直是信手拈来。
- 辅助开发。函数级别的代码编写、单元测试生成，还有代码阅读和逻辑解释，甚至追踪特定配置参数、定位功能缺陷，无论是用 Windsurf 还是 Cursor，效果都远超预期。
- 资料查询与整合。不管是智能搜索还是深度研究，基本都属于这个范畴。
除了这些工具类应用，有没有真的把大模型能力融入实际业务中？还真有。
运维老师傅
在运维现场，老师傅最大的价值之一就是见多识广。然而对主流大模型来说，知名软件的日志信息几乎毫无秘密可言。所以随手写了个叫 Pipe2GPT 的小东西，一直放在 Mac 和家庭服务器里。但凡遇到什么看不懂的 STDOUT 或 STDERR，Pipe 过去就行了。绝大多数情况下，给出的结果不输 StackOverflow，最关键的是——它说的是经过组织的人话，这点实在太重要了。
哄娃小工具
还搭建过一个工作流：用粤语根据几个关键字生成童话故事，再通过方言 TTS 生成语音读给小朋友听——也算是为保留粤语尽点绵薄之力。
调制和解调
这其实跟翻译类似，让大模型对信息进行翻译和重整，生成新的信息模式。比如：
- 从自然语言的网页（如公告、通知）中提取规范化信息，交给其他系统进一步处理。这种方式应用很广，特别适合小打小闹地做一些顺手的数据搜集工作。
- 云 SDK 到 IaC 的转换。以虚拟机为例，同样 4 核 8G，不同厂商有不同机型，在 Terraform Provider 里又有各自表达。有了大模型辅助，反而能轻松在不同厂商 SDK 和 IaC 代码之间进行切换。
……
不过，这种蹭热度的过程一直有些粗糙的感觉：应用侧和模型侧始终泾渭分明、各自为战。模型训练搞不起，对接时又因为个人架构能力有限，每次需求稍有变化，就得大量调整代码。尤其是跟商业数据系统对接时，缺乏最佳实践指导，那种“草台班子”的感觉，确实挺让人挫败的。
MCP
前段时间看到 Claude MCP，感觉这个高冷的大模型终于开始有“味道”了。总算有办法把传统服务和系统，跟各种大模型相对规范地对接起来。
MCP 是 Model Context Protocol 的缩写。官方简介里说得很清楚：
模型上下文协议（MCP）是一种开放式协议，可实现 LLM 应用程序与外部数据源和工具之间的无缝集成。无论你是在构建 AI 驱动的集成开发环境、增强聊天界面，还是创建自定义的 AI 工作流，MCP 都能提供一种标准化的方式，把 LLM 和它们需要的上下文连接起来。
目前官方已提供 TypeScript、Python、Ja va 和 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、IDE 或希望通过 MCP 访问数据的 AI 工具。
- MCP Clients: 与服务器建立一对一连接的协议客户端。
- MCP Servers: 轻量级程序，通过标准化协议提供特定功能。
- 本地数据源: 电脑上的文件、数据库和服务，MCP 服务器可以安全访问。
- 远程服务: 通过 API 可达的外部系统。
从架构图能直观看到，MCP 定义了一套行为规范以及通信方式和对象。LLM 客户端应用作为 MCP Client，通过 MCP Server 与本地资源、外部服务连接起来，形成完整的数据通路，让 MCP Server 提供的数据和能力直接在 LLM 应用里被使用。
MCP 的核心概念包括：用于描述原子能力的 Resource（资源）和 Tool（工具）、用于复用提示词的 Prompt，以及控制文本生成的 Sampling 能力。除此之外，对传输、安全、敏感信息等也给出了相对完善的建议和最佳实践。所以即使目前存在只能本地调用等短板，MCP 仍然不失为一个开拓 LLM 应用边界的非常有价值的方向——不够好没关系，谁能谁能上就是了。
例子
官方文档里有个天气预报的 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 作为一个“便宜”（就像北京便宜坊那种实惠吧）的途径，在独占大模型环境的场景下，是一种颇有吸引力的解决方案。