Showing Posts From

Mcp

MCP 与 Skill：搞清楚 AI 能力扩展的两个核心概念

MCP 与 Skill：搞清楚 AI 能力扩展的两个核心概念

在 AI 和智能体（Agent）开发领域，MCP（Model Context Protocol，模型上下文协议） 和 Skill虽然都与「扩展 AI 的能力」有关，但它们处于完全不同的架构层级。 简单来说：MCP 是「接口标准」，而 Skill 是具体的「功能实现」。 就像 MCP 是电脑上的 USB 接口协议，而 Skill 则是插在这个接口上的 U 盘、鼠标或打印机。核心概念对比 MCP (Model Context Protocol) MCP 是由 Anthropic 开源的一种标准化通信协议。它解决的是「AI 模型如何安全、统一地连接外部数据源和工具」的问题。本质： 一套 Client-Server 架构的底层基础设施。 作用： 过去，开发者要让 AI 查数据库、读本地文件、调用外部 API，需要为每个平台写定制化的集成代码。MCP 提供了一套通用标准，只要数据源封装成了「MCP Server」，任何支持 MCP 的 AI 客户端（如 Claude Desktop、Cursor、各类 IDE 插件）都可以无缝接入，读取上下文或调用工具。 关注点： 安全性、连接性、标准化、跨平台。Skill (技能) Skill 通常指的是 AI Agent 能够执行的具体任务或业务逻辑。这个概念在 AI 行业存在已久（比如 Amazon Alexa Skills，或者智能体框架中的 Tools/Actions）。本质： 封装好的业务能力。 作用： 赋予 AI 完成特定指令的能力。例如：「搜索网络」、「查询天气」、「总结指定的本地 PDF 代码库」、「在 Jira 中创建一个 Bug 工单」。 关注点： 业务逻辑、Prompt 设计、输入输出的处理。详细区别 {% table %}维度 MCP (模型上下文协议) Skill (技能)层级定位 底层/架构层 (Infrastructure) 上层/应用层 (Application/Logic)核心问题 AI 如何与外部世界建立标准化的连接？ AI 能够为用户完成什么具体任务？通用性 极高。跨平台、跨模型通用。 较低。通常依赖具体的提示词或特定的 AI 框架。开发对象 开发「MCP Server」，定义资源（Resources）和工具（Tools）的暴露方式。 编写代码逻辑或 Prompt，定义输入参数、执行动作和输出结果。 {% /table %}它们是如何协同工作的？ 在现代的 AI 架构中，MCP 往往是实现 Skill 的底层通道。 假设你正在为运维团队开发一个基于 RAG（检索增强生成）的企业知识库系统： 没有 MCP 之前开发 Skill： 你需要写一个大长串的 Python 脚本，直接把 AI 的 API 和公司内部的 Confluence API 绑死在一起。这个「查文档」的 Skill 只能在你的代码库里运行。 使用 MCP 之后开发 Skill：你开发一个连接 Confluence 的 MCP Server。 这个 Server 向外暴露了一个叫 search_internal_docs 的 Skill（或 Tool）。 现在，不仅是你自己写的代码，团队里的开发者用 Cursor 写代码时，或者用 Claude 客户端聊天时，只要连接了这个 MCP Server，他们的 AI 就瞬间具备了「查询公司内部运维文档」的 Skill。总结：你可以通过 MCP 协议，将各种强大的 Skill 标准化地分发给不同的 AI 应用。有了 MCP，为什么还到处是 Skill？ 这是一个很敏锐的问题。你可能会觉得：「既然已经有了一个统一的底层协议（MCP），为什么还要反复强调或者大量去写上层的 Skill 呢？」 其实，MCP 的出现不仅没有消灭 Skill，反而直接促成了 Skill 的「大爆发」。像 Claude、Cursor 现在之所以大量依赖 Skill，正是因为 MCP 把开发和接入 Skill 的门槛降到了前所未有的低。 1. 模型本质上是「缸中之脑」，它永远需要手和眼 无论是多么强大的大语言模型（Claude 3.5 Sonnet、GPT-4o），它们的本质都只是一个「文本预测引擎」。如果没有任何外部工具，它们既不知道现在是几点，也无法读取你 MacBook 上的本地文件，更无法帮你执行终端命令。Skill 就是 AI 的手和眼睛（例如：读取本地文件、执行终端命令、搜索网页）。 MCP 是连接大脑（AI）和手眼（Skill）的神经系统。神经系统再好，没有手眼也干不了活。因此，要想让 AI 真正帮你干活，依然需要大量具体的 Skill。 2. 「解耦」带来了类似 App Store 的效应 在 MCP 出现之前，如果 AI 厂商想让 AI 拥有一个新 Skill（比如「读取本地代码库」），他们必须亲自在自己的客户端里硬编码写死这套逻辑。这导致 AI 能干的事情非常受限。 有了 MCP 之后，发生了类似「苹果推出 App Store」的效应：以前： Claude 团队自己吭哧吭哧写几百个集成逻辑。 现在： Claude 只需要说「我支持 MCP 协议」。然后，全世界的开发者就可以用几行代码写出一个「读取本地 Git 仓库」的 Skill，或者「查询 Jira 状态」的 Skill，封装成 MCP Server 喂给 Claude。正因为 MCP 提供了一个标准的「插座」，现在任何开发者都可以轻松地把成千上万个 Skill（U盘）插到 Claude 这个主机上。 3. 具体到代码开发场景 假设你在本地 macOS 环境下进行开发，遇到了依赖管理或编译报错的问题，AI 需要帮你排查。AI 要真正解决问题，它可能需要调用以下几个 Skill：read_file：读取你本地的配置文件 execute_command：在你的终端跑一下相关的环境检查命令 search_internal_knowledge：去你们公司的内部运维知识库检索在这个过程中，MCP 和 Skill 是如何配合的？Claude/Cursor 客户端 会通过 MCP 协议 与你本地机器上的服务建立安全连接。 通过这个连接，AI 会发现你暴露给了它上述三个 Skill（工具）。 AI 大脑经过思考后决定：「为了排查这个依赖报错，我需要调用 execute_command 这个 Skill。」一句话总结 MCP 是修好的高速公路，而 Skill 是跑在上面的货车。 正因为高速公路（MCP）修通了且标准统一了，你才会看到现在马路上跑着比以前多得多的货车（Skill），去帮你运送数据、执行任务。 未来，随着企业知识库、自动化工作流的普及，这种原子化的 Skill 只会越来越多。搞清楚这两个层级的关系，是理解 AI 工程化、构建真正有用的 AI Agent 系统的关键第一步。