MCP 协议与"去 MCP 化"之争
@0xRafy 的 11 步中文指南打底,@Smartpigai 抛出"去 MCP 化"论战:CLI 与 MCP 到底怎么分工?
开篇:MCP 是什么
以下来自 @0xRafy(2026-08-13)的 11 步中文指南。MCP(Model Context Protocol)= AI 领域的 USB:Anthropic 2024 年 11 月开源,2025 年 3 月 OpenAI / Google / 微软跟进采用,现由 Linux 基金会 Agentic AI Foundation 治理。
规模(原文数字):SDK 月下载 4 亿+、公共服务器 1 万+、11 种语言 SDK。
就像 USB 接口:以前每个外设都要装自己的驱动(N×M 的集成地狱),USB 之后"插上就能用"。MCP 对 Agent 工具干的是同一件事——把 N×M 的两两对接变成 N+M 的标准对接。
时间线:2024-11 Anthropic 开源 → 2025-03 OpenAI / Google / 微软采用 → 2026-07-28 无状态大版本(本课第 2 节细讲)。
架构三角色与三种原始元素
三角色
- Host:用户交互的应用,如 Claude Desktop / Claude Code / Cursor;
- Client:Host 内部 1:1 连接 server 的"转换器";
- Server:真正提供 tools / resources / prompts 的一方。
就像翻译官体系:Host 是你要见的外国官员,Server 是对方官员,Client 是中间那位 1 对 1 的翻译——两边各说各的协议,翻译负责对齐。
三种原始元素
- Tools:模型可调用的功能,如
run_query; - Resources:模型可读的数据,如数据库 schema;
- Prompts:可复用模板,标准化团队工作流。
原文附最小 server 示例(TypeScript / Python 可直接抄):
# A minimal MCP server exposes tools, resources, or both
# Tool: a function the model can call
{
"name": "run_query",
"description": "Execute a read-only SQL query",
"inputSchema": {
"type": "object",
"properties": {"query": {"type": "string"}},
"required": ["query"]
}
}
# Resource: data the model can read
{
"uri": "postgres://mydb/schema",
"name": "Database Schema",
"mimeType": "application/json"
}
连 Claude 的三种方式
- Claude Desktop:改
claude_desktop_config.json; - Claude Code:
claude mcp add; - Claude API:
mcp_servers参数。
2026-07-28:历史最大版本
原文称之为 2026-07-28 版本规格——MCP 历史上最大的版本:
- stateless core(无状态核心):无会话、无握手,纯请求/响应模型——从此可上负载均衡横向扩展;
- extensions 系统:可扩展机制;
- Enterprise-grade auth(EMA 企业级授权管理)。
旧 server 有 12 个月 deprecation 保证;新 server 应该直接 target 新 spec(比旧的 session 模型更简单、更好部署)。
安全 checklist 与生产
MCP Server Security Checklist(原文)
- 全端点认证:远程一律 OAuth 2.1;
- 工具输入全视为不可信:防 SQL 注入 / 路径遍历(模型生成的参数里可能藏着这些);
- 最小权限:只读默认;
- 限流、审计日志、锁 SDK 版本;
- 不在描述/报错里泄密。
原文提到:NSA / CISA 出过针对 MCP 的正式安全指引——这不是玩具协议了。
5 大错误(原文逐条)
- 生产环境无认证;
- 信任模型生成的输入;
- 先造后搜——1 万+ server 已存在,先去 GitHub / mcp.so / Smithery 找;
- 工具描述模糊("Run a query" vs "Execute a read-only SQL SELECT query against the PostgreSQL database, max 1000 rows"——Claude 靠描述决定何时调用,模糊描述 = 错误调用);
- 还在用旧 spec。
找现成 server:三渠道 + 评估清单
- 官方:GitHub / Slack / GDrive / Postgres / Puppeteer / filesystem / memory;
- 社区:GitHub 搜
mcp-server-*; - 目录:mcp.so、Smithery、Glama。
评估清单:看 auth、看输入校验、看 30 天内 commits、看是否新 spec。
原文推荐的 6 个 server:Postgres、GitHub、Slack、Notion、Filesystem、自家内部 API。
"去 MCP 化":重新拥抱 CLI
以下来自 @Smartpigai(2026-08-23)。现象:前两年 MCP 被视为 Agent 连接外部世界的标准答案(GitHub / 数据库 / 浏览器各装一个 Server),但实际用久了,开发者发现:对本地开发和工程自动化,MCP 不一定是最短路径——越来越多 Agent 重新选择 CLI。
注意原文立场:不是 MCP 被淘汰,而是重新分工。
CLI 的 5 个优势(原文逐条)
Git、Docker、kubectl、ffmpeg、psql、gh 本来就有稳定的命令行接口。再包成 MCP Server,等于多一层协议、进程、配置和维护成本。Agent 能读 --help、执行命令、检查退出码就行。
MCP 工具要把名称、描述、参数 Schema 一次性暴露给模型——工具一多,上下文先被"工具说明书"塞满。CLI 可渐进式探索:先知道有哪些命令 → 需要时 help → 只读当前子命令参数,用到什么拿什么。
MCP 失败可能来自客户端、Server、传输协议、Schema、权限或底层 API;CLI 失败就是一条命令 + stdin/stdout/stderr + 退出码——开发者可直接复制重现,也易写进日志、脚本和 CI。
Unix 管道、文件、环境变量、重定向本身就是一套成熟的 Agent 工具协议:获取数据 | 过滤 | 转换 | 保存。
代码、依赖、Git 状态、容器、构建工具都在本地。Agent 经 CLI 操作的就是开发者实际用的系统,无需在 MCP Server 和真实环境间同步状态。
MCP 仍然适合的场景(原文也给了)
- 跨客户端复用同一集成;
- 连接远程 SaaS 和企业数据;
- 提供结构化参数与返回值;
- 统一认证、权限、审计和交互界面;
- 向不具备完整终端能力的 Agent 暴露工具。
原文诊断了过去的问题:把 MCP 当成了所有工具的默认封装方式。MCP 解决"如何标准化连接",CLI 解决"如何直接把事情做完"——Agent 从 Demo 进入真实工程环境后,后者往往更重要。
就像装修布线:MCP 是墙里的标准插座(跨房间通用、有漏保);CLI 是直接接电线(快、省料、师傅一眼看懂)。家里常住(本地工程)直接接线最顺;要对外出租、统一管理(跨客户端/远程 SaaS),还是标准插座靠谱。
分工共识:CLI 是本地执行层,MCP 是集成层
两篇合起来,结论出奇地一致:
| 层 | 归属 | 管什么 |
|---|---|---|
| 本地执行层 | CLI | 本地开发、工程自动化:git / docker / kubectl / psql,直接把事情做完 |
| 标准化集成层 | MCP | 跨客户端复用、远程 SaaS、企业数据、统一认证审计:把连接标准化 |
原文对未来的判断:A2A(Google 的 agent-to-agent 协议,与 MCP 互补)+ extensions 生态;"MCP 今天像 1995 年的 HTTP"——基础设施刚铺好,应用层还没开始。
术语翻卡:点卡片看解释
自测一下:点问题展开参考答案
三角色:Host(Claude Desktop/Code、Cursor 等用户应用)、Client(Host 内 1:1 连 server 的转换器)、Server(提供 tools/resources/prompts)。三种元素:Tools(模型可调用的功能)、Resources(模型可读的数据)、Prompts(可复用模板)。
引入 stateless core(无会话、无握手、纯请求/响应),外加 extensions 系统和 EMA 企业级授权。影响:MCP server 从此就是普通 HTTP 服务,可上负载均衡横向扩展,随便用 Docker/K8s/Lambda 部署;旧 server 有 12 个月 deprecation 保证。
①已存在、无需再造一层;②更省上下文(渐进式探索,用到什么拿什么);③更易调试复现(一条命令+退出码);④天然组合能力(Unix 管道);⑤更接近真实执行环境(无需在 Server 和真实环境间同步状态)。
真正需要协议边界时:跨客户端复用同一集成、连接远程 SaaS 和企业数据、需要结构化参数与返回值、统一认证权限审计、向不具备完整终端能力的 Agent 暴露工具。