大家好，我是讯享网，很高兴认识大家。这里提供最前沿的Ai技术和互联网信息。



去年 MCP 火，今年 Skills 火，但关于二者的路线选择之争并没有结束。

最近有个MCP协议的拥趸David Coffee，表达了对当前“Skills取代MCP”风潮的不满认为Skills适合传递纯粹的知识和教AI如何使用一个已经存在的工具，但当涉及到让AI真正访问和操作一个外部服务时，MCP在架构上是远为优越和务实的选择。

但我觉得，这根本不是两种技术路线的优劣之辩，而是关于AI Agent的执行环境的问题，是我们在为“瘦客户端”构建可信的远程服务，还是为“胖客户端”提供本地化的超级能力。

在深入解读之前，有必要先简单定义或者说解释一下MCP和Skills。

MCP (Model Context Protocol)，模型上下文协议。本质上是一种API的抽象和封装。你可以把它理解成一个为AI模型量身定制的“插件系统”或“连接器”。模型不需要知道如何操作Google Calendar的复杂API，它只需要调用一个定义好的的函数。所有底层的鉴权、实现细节、错误处理，都由一个专门的MCP服务器来搞定。模型是消费者，MCP服务器是服务提供者，二者通过一个标准化的协议对话。

Skills，技能。目前最普遍的形态是一个Markdown文件（比如SKILL.md）。它的作用更像是一本“操作手册”或者“说明书”，直接塞给模型看。这本手册会告诉模型：“当你想做某件事时，你应该在命令行（CLI）里运行这条命令…”，或者“我们公司的代码规范是这样的…”。它本质上是一种自然语言指令集，依赖于模型本身对指令的理解能力，以及一个能够执行这些指令的本地环境。

拥护MCP的理由很简单：零安装、无缝更新、更安全的认证（OAuth）、真正的跨平台可移植性、天然的沙箱环境。这些都是面向服务架构（SOA）思想的直接体现——关注点分离，接口稳定，实现细节对消费者透明。

而反对者，则强调Skills（通常是CLI驱动的Skills）对于开发者友好，能复用现有工具链，以及更简便的可组合性。在命令行里，你可以将不同工具的输出和输入连接起来，创造出可能性。而MCP的工具调用是孤立的，模型必须扮演那个“管道”的角色，在不同的工具调用之间手动传递数据，这既笨拙又消耗上下文。

这场争论看起来就像是经典的“API vs. CLI”之战在AI时代的重演。但仔细想想就会发现，这些争论有点走偏了方向。

David的文章里提到了说：“ChatGPT不能运行CLI，Perplexity也不能，标准网页版的Claude也不能……任何依赖CLI的Skill，在这些环境里都是死路一条。”

这才是真正的分歧所在。

AI Agent的能力，根本上取决于它所处的执行环境。我们可以将这些环境粗略地分为两类：

一旦我们用“执行环境”这个坐标系来重新审视，MCP和Skills的定位就立刻清晰了。

在受限环境下，MCP几乎是让模型与外部世界互动的唯一可行路径。因为所有的计算、鉴权和状态管理都发生在远程的MCP服务器上，模型所在的客户端只是发起了一个安全的、定义明确的RPC调用。用户想让Claude帮他订一个Notion页面，通过Notion官方提供的MCP，整个流程可以在云端完成认证和操作，完全不依赖用户本地的任何环境。在这种场景下，讨论CLI的优越性毫无意义，因为它根本没有登场的机会。

而在富集环境下，由CLI驱动的Skills则展现出无与伦比的灵活性和力量。模型可以直接使用开发者熟悉的git、curl、gcloud、kubectl等工具，并将它们以前所未有的方式组合起来。它可以在本地文件系统里创建临时脚本，用jq处理JSON输出，再通过管道传给另一个工具。这种即时、动态的脚本生成和组合能力，是当前任何MCP架构都无法比拟的。在这里，AI Agent就是一个自动化脚本的“生成引擎”和“执行引擎”。

所以，MCP和Skills的争论，从一开始就是一场“关公战秦琼”式的错位对话。两拨人站在完全不同的执行环境里，却试图争论同一个工具的优劣。

既然问题的核心是执行环境，我们就有必要重新定义MCP和Skills在AI Agent生态中的角色。它们不是相互替代的竞争关系，而是处于不同抽象层级的、可以互补的组件。

MCP的本质，应该被视为一种“AI原生”的服务契约。

它为外部服务提供了一个标准化的、强类型的、安全的入口，专门为AI模型的“思维方式”（即函数调用）而设计。一个设计良好的MCP，就像一个高质量的SDK，它向模型清晰地声明了“我能做什么（功能），你需要给我什么（参数），我会返回给你什么（结果）”。它关注的是可靠性、安全性和治理。对于企业而言，MCP是管理AI访问内部系统、进行权限控制和审计的天然关口。MCP在企业环境中意义重大，因为它提供了一种可控的方式来扩展AI的能力，而不是让AI在内部网络里随意执行命令。

Skills的本质，则应该被视为一种“上下文感知”的编排蓝图。

它的核心价值在于传递领域知识和定义复杂工作流。一本好的SKILL.md，是教会模型如何“像一个专家一样”思考和行动。它可以告诉模型：

如何使用工具：这包括如何使用一个CLI（比如gh命令的各种高级用法），也包括如何有效地调用一个MCP服务。David自己也在文末领悟到了这一点：“一个解释如何使用MCP服务器的Skill其实非常有意义……它成为MCP的备忘录，而不是替代品。”

如何遵循流程：比如一个公司的代码提交规范，一个处理客户支持工单的标准流程，或者一个多步骤的数据分析任务。

如何理解上下文：例如项目的技术栈、团队成员的角色、内部术语的含义等“部落知识”。

Skills是架设在底层能力之上的一层“智能”。它不关心底层能力是由MCP提供，还是由CLI提供，它只关心如何将这些能力编排起来，以最高效、最正确的方式完成特定任务。

基于以上的分析，一个成熟、健壮且能适应不同场景的AI Agent架构，不应该是单选MCP或Skills，而应该是一个分层的、协同工作的生态系统。

这一层由标准化的API和协议构成，核心是为AI提供安全、可靠的外部能力入口。MCP是这一层的有力竞争者。无论是SaaS服务（如Notion、Jira）、硬件设备（如智能家居）、还是本地应用，都应该考虑提供一个类似MCP的“AI原生接口”。这一层的目标是，让AI“接入”世界。

对于那些已经拥有强大CLI的工具（如Git、Docker、AWS），CLI本身就是最高效的接口。在富集环境中，AI应该被鼓励直接使用这些经过千锤百炼的工具。重复发明轮子去创建一个git-mcp是没有意义的。

对于那些只提供MCP接口的服务，可以而且应该存在一层薄薄的CLI封装。murl就是一个绝佳的例子，它允许用户在命令行中调用远程MCP服务。这弥合了富集环境中CLI生态和MCP生态之间的鸿沟，让MCP服务也能享受到CLI的可组合性优势。

这一层就是Skills的天下。Skills文件坐镇顶层，作为AI的“大脑皮层”。它根据任务需求，向下调用第二层的各种工具（无论是原生CLI还是封装后的CLI），或者在没有CLI可用（受限环境）的情况下，直接调用第一层的MCP接口。它负责将底层的原子能力，组合成有意义的、符合特定领域规范的宏观行为。

我们可以虚拟一个具体的例子，假设我们要让AI Agent处理一个GitHub Issue。

在这个分层架构下，争论MCP还是Skills就变得毫无意义。它们各司其职，共同构成了一个可扩展、可维护的Agent生态。开发者可以专注于打磨自己熟悉的CLI工具，企业可以专注于构建安全可控的MCP服务，而团队和个人则可以将自己的宝贵经验沉淀为可复用的Skills。

所以，关于智能体协议的争论的焦点其实被长期误导了。我们不应该问“MCP和Skills哪个更好”，而应该问“我的AI Agent运行在什么样的环境里？我需要的是一个安全的API网关，还是一个灵活的本地执行器？”

对于服务提供商而言，未来的方向是明确的：请为你的服务构建一个稳定、安全的“AI原生API”，MCP是一个值得认真考虑的范本。这不仅仅是提供一个新功能，而是为即将到来的Agent经济时代铺设基础设施。

对于开发者和高级用户而言，CLI依然是你们最强大的武器。拥抱Skills，用它来教会AI像你一样思考和使用工具，将你的生产力提升到新的维度。

最终，这场看似对立的争论，将在一个更高维度的分层架构中得到统一。协议只是手段，环境决定路径，而如何将知识和流程注入AI，才是这场变革中最激动人心的部分。与其在协议的泥潭里打滚，不如抬头看看，一个更清晰、更模块化的AI Agent架构蓝图，已经浮现在我们眼前。

参考来源：I still prefer MCP over skills