MCP为什么凉了？——从“工具协议崇拜”到“AI原生设计”的反思

一句话总结它试图给AI造一套专属工具语言但AI本来就会说人类的工具语言。2024年底Model Context ProtocolMCP带着“AI工具标准化”的光环登场一度被视为AI Agent时代的核心基础设施。然而不到一年热度迅速消退。与此同时一种更轻量、更“土”的方案——Skill悄然成为主流。这背后不是技术优劣的简单更替而是两种设计哲学的根本碰撞是为AI发明一套新协议还是让AI使用人类已有的工具语言一、“知识在哪里”那个被忽视的核心洞察MCP的设计者犯了一个根本性错误他们假设AI需要一套结构化的、严格定义的接口规范才能调用工具。但他们忽略了一个事实——LLM的训练数据里充满了人类使用工具的“经验”。GitHub的README、Stack Overflow的问答、Linux man pages、Shell脚本、Dockerfile……这些文本中包含了海量的工具使用范例。大模型从这些数据中学会了curl -X GET是什么意思jq .name怎么用kubectl logs后面跟什么参数。MCP的Schema对模型来说是全然陌生的。每一次MCP调用你都在用最昂贵的token去给模型上一堂它本不该上的课——教它一套只在你的Server里生效的、没有任何训练数据支撑的接口规范。而CLI呢模型从预训练阶段就已经“会”了。知识的分布决定了能力的边界。把工具接口设计得越“独特”AI用起来就越“费力”。二、MCP vs. Skill两个维度的对比维度MCPSkill核心载体JSON Schema注入上下文自然语言指令 脚本调用上下文成本每次对话都要加载完整Schema只在需要时加载简短的SKILL.md可组合性弱工具间串联靠LLM硬编码强Shell管道天然可组合调试难度困难黑盒JSON交互透明同一条命令人能跑生态基础2024年底才出现模型无先验知识CLI几十年积累模型权重大量覆盖认证机制每个Server自建一套复用系统级认证SSH、OAuth、K8s RBAC但说实话Skill不是MCP的“替代品”而是走了另一条路MCP在格式层标准化——试图统一工具的“接口形状”Skill在意图层标准化——告诉AI“遇到这类需求时按这个流程、用这些命令去做”这是一个本质差异。MCP关心的是“怎么调用”Skill关心的是“什么时候调用、以什么顺序、有哪些约束”。三、MCP的三个致命伤1. 上下文污染MCP Server返回的Tool Schema无论用不用都要塞进上下文。一个稍微复杂的Server可能定义10-20个工具每个工具的JSON Schema动辄几百token。对话还没开始几千token已经被Schema吃掉了。Skill的方案是按需加载——只有触发特定意图时才加载对应的SKILL.md。而且SKILL.md是自然语言写的300-500字就能描述清楚一个完整的工作流。2. 可组合性缺失MCP的工具是“平铺”的。要让工具A的输出作为工具B的输入LLM必须自己写胶水代码。这在简单场景下可行但一旦链条变长模型的“中间变量管理”能力就会成为瓶颈。Skill天然站在Shell的肩上command1 | command2 | command3。管道、重定向、退出码、标准错误——这套组合范式已经存在了50年模型从训练数据里早就学会了。3. 调试黑盒化“MCP调用失败了是Server挂了、Schema写错了、还是LLM参数生成错了”——这个问题几乎无法回答。而Skill的执行是一条Shell命令。人能跑通AI就能跑通。人能调试AI也能调试。四、Skill的本质不是“封装”是“意图路由”很多人误以为Skill只是把MCP的工具换成了自然语言描述。这是误解。Skill的核心价值在于将“能力”从“接口”中解放出来。一个典型的SKILL.md结构# 技能名称deploy-to-k8s ## 触发条件 用户要求部署服务到Kubernetes环境 ## 执行步骤 1. 检查kubectl context是否为目标集群 2. 验证deployment.yaml中的镜像tag 3. 执行 kubectl apply -f deployment.yaml 4. 等待rollout完成kubectl rollout status deployment/name ## 安全边界 - 禁止在production命名空间执行此技能除非用户明确确认 - 镜像tag不能为latest ## 异常处理 - 如果context不对输出当前context并请求确认 - 如果rollout超时执行 kubectl describe 并输出结果这份指令人读一遍就懂AI读一遍也能执行不需要任何解析器、Schema定义、Server实现Skill不替换CLI它在CLI之上加了一层意图路由和行为约束。它回答的是三个问题什么时候用这个能力用的时候遵循什么流程什么情况下不能用五、务实架构三层就够了基于上述分析当前构建智能应用最务实的架构是三层第一层裸CLI 文档 基础能力层原则不给LLM做任何包装。给它curl、gh、kubectl、jq、grep、awk、sed——这些都是AI的母语。给它一份README它自己会搞懂参数。这一层的优势零成本不需要写任何适配代码可调试人能在终端里跑通每一条命令可组合Shell管道就是天然的工作流引擎可观测命令的stdout/stderr/exit code就是最好的日志第二层Skill 编排与流程层当任务需要多步编排、有特定约束、或需要积累最佳实践时用Skill封装。Skill不是“替代CLI”而是“在CLI之上做约束和编排”。它解决的问题是多步骤任务的一致性避免AI每次都重新“推理”流程安全边界的强制执行哪些操作需要审批、哪些参数被禁止组织经验的沉淀把“我们团队怎么做”写成Skill第三层Agent 决策与进化层Agent负责理解用户意图选择合适的Skill或直接调用CLI管理对话状态处理异常和回退从执行轨迹中学习Agent的核心价值不是“调工具”而是在工具之上做推理和决策。一个Agent可以没有MCP但不能没有决策能力。六、一个可能得罪人的判断MCP最大的错误不是技术实现差而是它在用“给API加包装”的思路来解决“让AI使用工具”的问题。人类工程师不用专门的“工具协议”来调用工具——我们读文档、写命令、看输出。MCP假设AI需要一套不同于人类的工具交互方式但大模型恰恰是最“像人类”的工具使用者。它读README和我们读README的方式本质上没有区别。Skill能火、MCP凉了背后不是一个技术方案战胜了另一个而是一个更尊重AI原生能力的设计理念战胜了一个过度工程化的协议设计。这不是MCP团队的失败而是整个行业对“AI Native”理解的一次集体矫正。七、如果你现在要构建智能应用落地建议先别想框架——先把CLI工具链理顺确保Agent能用命令行完成所有操作。这是地基。用Skill封装复杂流程——多步骤、有约束、有安全要求的任务写成SKILL.md。比写MCP Server省90%的工作量调试成本低一个数量级。在Skill里加安全围栏——参数钳制、操作白名单、人工审批点、命名空间限制。这些比MCP的权限模型更灵活、更直观。积累执行轨迹——Skill的可观测性天然比MCP好Shell命令是透明的。用这些数据做策略优化、做异常检测、做模型微调的数据集。什么情况下MCP仍然有价值话说回来MCP并非一无是处。以下场景MCP可能仍然是合适的选择需要状态化的长连接比如实时数据推送、双向通信非CLI可调用的能力比如GUI应用、某些SaaS平台的专有API严格的类型安全要求Schema校验在某些合规场景下是硬需求但这些场景坦白说在AI Agent的实际应用中占比不高。结语CLI是地基Skill是蓝图Agent是施工队。别在地基都没打好之前先去发明一种新的砌砖协议。MCP的“凉”不是终点而是一个重要的里程碑——它用高昂的成本告诉行业AI不需要被“适配”到人类的接口规范上人类已有的工具语言就是最好的AI接口语言。未来真正成功的AI Agent框架不会是那些发明最多新协议的项目而会是那些最尊重AI现有能力、最善于复用人类已有基础设施的设计。Skill证明了这条路走得通。下一步不是做MCP 2.0而是把Skill模式做到极致——更智能的意图识别、更安全的执行沙箱、更丰富的执行轨迹分析。工具会变但CLI会一直在。因为它是人类和机器都能理解的语言。