Skill 与 MCP 详解：AI Agent 的“操作手册”与“USB-C 接口”

这篇博客把这两个概念讲清楚，盘点当下真正值得装的 Skill 与 MCP Server，并给出可直接上手的调用方法。

一、Skill 是什么：给 AI 一本可复用的操作手册

Skill 的本质，是一份可反复使用的工作说明：遇到什么任务时使用，按什么步骤做，需要查看哪些资料，结果要符合什么要求。

一个 Skill 通常就是一个文件夹，核心文件叫 SKILL.md。文件开头用元数据（名称、简介）告诉 AI 这个技能适用于什么任务，正文来写具体步骤，文件夹里还可以放脚本scripts/、参考资料references/和模板assets/，但这些不是必需的。

一个常见的比喻是菜谱卡，像一个说明书告诉厨师什么时候拿出它，步骤写明先做什么后做什么。但菜谱并不会凭空变出食材，也不能代替厨师检查食材是否新鲜。Skill 只是提供方法，实际执行仍然取决于 AI 能访问什么工具、能使用什么权限。

Skill 最关键的技术机制是 渐进式披露（progressive disclosure） ：AI 启动时只加载所有已安装 Skill 的名称和简介约 100 tokens/个，只有在判断某个 Skill 与当前任务相关时，才加载完整内容。这就是为什么你可以装几十个 Skill 而不会立刻撑爆上下文窗口。

二、2026 年真正值得装的 Skill：链接、优点与安装方式

如何发现和安装 Skill

当前 Skill 的分发主要走 skills.sh，Vercel 出品的 Agent Skills 导航站 AgenticSkills，可以理解为“AI 技能的 App Store”，安装统一走 skills CLI。先确保安装了 Node.js，然后：

# 初始化（首次使用）
npx skills init

# 安装某个 Skill 的通用格式
npx skills add <owner>/<repo> --skill <skill-name>

也可以直接从 GitHub 仓库 clone 到对应 Agent 的 skills 目录。但最好用的还是让 AI 直接进行下载，还可以挑选一个 skill 包中重要的下载，减少冗余。

生产力与工程流水线

Superpowers 的取舍：它并非对所有场景都划算。简单任务上强制走完整规划流程会多花时间，但中大型功能开发中，它能显著提升产出质量，因为绝大多数 Agent 天然倾向于跳过设计和 review。

claude-mem 的取舍：记忆连续性很强，但记忆噪声积累过多时会干扰判断，需要定期清理。安装命令为 npx claude-mem install，也有更轻量的社区替代方案（如 SomeStay07/claude-memory-skill）。

skills.sh 热度 Top 10 中值得优先装的

根据 skills.sh 的榜单（热度 = 8 周活跃度 + 安装量综合），以下 5 个是社区实测后共识度最高的：

此外，tdd（mattpocock，测试先行）、improve-codebase-architecture（技术债体检）和 web-design-guidelines（Vercel 版 UI 规范审查器）也在 Top 10 中，可按需选用。

非编码场景正在加速

Skill 生态正在从“程序员专属”向全岗位覆盖。办公场景中值得关注的有：

• PDF 长文档抽取：法务、咨询、审计场景从长文档中抽结论和风险点
• mail：邮件汇总、初稿回复、线程摘要
• xlsx：带公式的 Excel 自动生成

腾讯 SkillHub 半年内聚合了近 8 万个 Skill，月下载量 1700 万+，从侧面印证了非技术用户的需求正在快速释放。

三、MCP 是什么：AI 连接外部世界的“USB-C 接口”

MCP（Model Context Protocol，模型上下文协议） 由 Anthropic 于 2024 年 11 月发布，是一套开放标准，让 AI 应用以统一方式连接外部数据源和工具。

MCP 官方文档

它解决的核心问题是 N×M 集成爆炸。在 MCP 出现之前，你有 N 个模型和 M 个工具，传统做法是给每一对“模型 × 工具”写一套集成代码，一共 N×M 套。

MCP 的做法是：每个工具做成一个 MCP Server，AI 应用内置 MCP Client，工具实现一次，任何支持 MCP 的 AI 应用都能用，集成数量从 N×M 降到 N+M。

技术上，MCP 基于 JSON-RPC，采用主机—客户端—服务器架构，定义了三类核心能力：

四、2026 年热门 MCP Server

MCP 生态的一个现实是：Star 数不等于可用性。大量 MCP Server 在协议发布热潮中获得关注，但此后从未更新。以下按场景列出当前维护状态和可靠性较好的选择。

需要留意的是，浏览器自动化领域的 mcp-chrome 虽然以 11.4K stars 位居赛道前列，但月提交为 0、Issue 无人处理，属于“高人气但已停更”的典型，选择时需要避开。

五、MCP 调用方法详解

这一节回答一个实操问题：MCP 到底是怎么被“调用”的，理解这条链路，比记住概念更重要。

5.1 协议操作：两个核心 RPC

MCP 的工具调用围绕两个 JSON-RPC 方法展开：

一个工具的典型定义长这样（JSON Schema 描述输入）：

{
  "name": "searchFlights",
  "description": "Search for available flights",
  "inputSchema": {
    "type": "object",
    "properties": {
      "origin": { "type": "string", "description": "Departure city" },
      "destination": { "type": "string", "description": "Arrival city" },
      "date": { "type": "string", "format": "date", "description": "Travel date" }
    },
    "required": ["origin", "destination", "date"]
  }
}

客户端拿到这份定义后，模型据此判断是否需要调用、传什么参数；tools/call 携带工具名和参数发起执行，服务器校验后返回结果。

5.2 完整调用链路（从用户提问到结果返回）

一次典型的 MCP 工具调用经历以下步骤：

1. 工具发现 客户端向 MCP Server 发送 tools/list，获取当前可用工具及其 schema。这个发现是动态的，服务器新增工具后客户端无需硬编码即可看到。

2. 模型决策 用户提问后，模型结合 tools/list 返回的工具定义，判断是否需要调用工具、调用哪个、参数怎么填。这一步本质上复用了 Function Calling 能力——模型只负责“点单”，不负责执行。

3. 客户端发起调用 客户端向 Server 发送 tools/call，携带工具名和符合 schema 的参数。

4. Server 执行并返回 Server 校验参数、执行实际操作（查数据库、调 API、读写文件等），将结果返回给客户端。

5. 结果回填 客户端将工具执行结果以 role: "tool" 的消息追加到对话中，再次请求模型，模型基于真实结果生成最终回答。

用一句话概括：tools/list 解决“有什么可用”，tools/call 解决“执行哪一个”，Function Calling 解决“模型怎么表达调用意图”。MCP 把后端的执行细节标准化了，模型不需要知道工具是用 REST、gRPC 还是本地脚本实现的。

5.3 两种传输方式与客户端配置

MCP 支持两种主要传输方式，客户端配置中通常这样体现：

stdio（本地进程） ：Server 作为本地子进程运行，通过标准输入输出通信，适合本地工具，如文件系统、本地数据库。

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/path/to/dir"]
    }
  }
}

HTTP/SSE（远程服务） ：Server 部署在远端，通过 HTTP 端点通信。适合云服务、共享工具和 Serverless 部署。客户端只需配置端点 URL。

{
  "mcpServers": {
    "remote-server": {
      "url": "https://mcp.example.com/rpc"
    }
  }
}

5.4 服务端实现：官方 SDK 示例

如果要自己暴露一个 MCP Server，官方提供 TypeScript 和 Python SDK，分别对应 @modelcontextprotocol/sdk 和 mcp。

TypeScript（McpServer + server.tool()）：

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { z } from "zod";

const server = new McpServer({ name: "my-server", version: "1.0.0" });

server.tool(
  "get_customer",
  "Look up a customer by ID. Use when the user asks about a specific customer.",
  { customer_id: z.string().describe("The customer's unique ID") },
  async ({ customer_id }) => {
    const customer = await db.customers.findById(customer_id);
    if (!customer) {
      return {
        content: [{ type: "text", text: JSON.stringify({ error: "Customer not found", code: "NOT_FOUND" }) }],
        isError: true,
      };
    }
    return { content: [{ type: "text", text: JSON.stringify(customer) }] };
  }
);

const transport = new StdioServerTransport();
await server.connect(transport);

TypeScript SDK 自动把 Zod schema 转换成 JSON Schema，工具 handler 返回 content 数组和可选的 isError 标志。

Python（FastMCP + @mcp.tool()）：

from mcp.server.fastmcp import FastMCP

mcp = FastMCP("my-server")

@mcp.tool()
def get_customer(customer_id: str) -> dict:
    """Look up a customer by ID. Use when the user asks about a specific customer."""
    customer = db.customers.find_by_id(customer_id)
    if not customer:
        return {"error": "Customer not found", "code": "NOT_FOUND"}
    return customer

Python SDK 的 FastMCP 把函数签名和 docstring 自动转换为工具定义，handler 直接返回 Python 对象即可。

5.5 规范的关键变化：无状态调用

2026 年 7 月 28 日发布的第五版 MCP 规范是该协议问世以来最大的一次修订，对调用方式有直接影响：

• 移除协议级会话和初始化握手。旧版需要先 initialize/initialized，新版每个请求完全自包含，协议版本和能力放在 _meta 中携带。
• Mcp-Session-Id 被移除。请求不再绑定会话，可以路由到任意实例，适合部署在 AWS Lambda、Cloudflare Workers 等 Serverless 架构上。
• tools/list 等列表端点不再随连接变化。需要跨调用状态的场景，改用服务器显式返回的 handle 作为普通工具参数传递。
• 新增 server/discover。服务器通过这个 RPC 声明支持的协议版本和能力，客户端可以在正式调用前探测。

这意味着在最新规范下，一个 MCP Server 更像一个无状态函数：收到请求、校验、执行、返回，不在两次调用之间保留任何东西。对于调用方来说，tools/call 的语义没有变，但部署和扩展的约束大幅放宽了。

5.6 认证：生产环境不能省

MCP 协议层面把认证设计为可扩展的，生产环境通常走 OAuth 2.1 或 Bearer Token。客户端可以通过预注册的 client_id/client_secret、动态客户端注册或 Client ID Metadata Documents 来完成授权服务器登记。如果使用托管 Server（如 Notion、GitHub 官方 MCP），通常只需要在客户端配置中填入对应的 token 或走 OAuth 授权流程，不需要自己实现协议细节。

六、Skill 与 MCP 的真实关系：互补，而非替代

把 Skill 和 MCP 放在对立面，是当前社区讨论中最大的误解。用一句话概括两者的分工：

MCP 解决“能不能连”，Skill 解决“会不会做”。

MCP 有一个被很多人忽略的代价：每个 MCP Server 连上 AI 时，必须把所有工具定义一次性塞进上下文。GitHub MCP Server 有 27 个工具，约 18,000 tokens；Playwright MCP Server 约 13,600 tokens。有开发者配置 7 个 MCP Server，还没开始对话，上下文就被吃掉了 67,000 tokens，占窗口的 33%。Skill 的渐进式披露机制恰恰缓解了这个问题——它只在需要时加载完整内容。

在真实项目中，两者是分层协作的关系。一个典型场景是：Skill 负责编排业务流程（“先审查代码安全性，再按规范格式化，最后提交”），MCP 负责提供底层动作（读取文件、调用 GitHub API）。Skill 可以调用 MCP 提供的工具，但 MCP 不关心 AI 的思考过程，它只负责把能力暴露出来。用技术层级来定位，三者的关系是：MCP（平台连接层） > Skill（业务编排层） > Function Calling（原子调用层） 。

七、生态版图与冷静提示

Skill 和 MCP 正在被主流平台同时纳入。腾讯云 ADP 4.0 将 Connector、Skills、MCP 一并纳入企业级 AgentOps 平台的构建、连接与治理链条。终端消费品牌也在跟进：滴滴、麦当劳、瑞幸、飞猪等至少 20 个品牌在 2026 年上半年上线了各自的 Skill/MCP/CLI 服务，把点单、叫车、预订等标准化能力开放给外部智能体调用。

但有几个风险需要如实呈现：

• MCP 的认证在协议层面是“可选”的。2025 年一次互联网扫描发现至少 1,862 个公开 MCP Server 存在暴露问题。2026 年头六十天针对 MCP 部署的 CVE 报告超过 30 个，扫描 500+ 个 MCP Server 时 38% 的关键端点缺少认证、43% 存在命令执行漏洞。NSA 也专门发布了 MCP 相关的安全设计考量，指出序列化风险、信任边界和 Agent 滥用是系统性关注点。

• Skill 生态的质量参差不齐。有人测试 100 个社区 Skill，70% 不合格，失败原因高度集中在：SKILL.md 臃肿（4000+ tokens）、description 写成营销文案而非路由规则、一个 Skill 包揽过多职责。判断一个 Skill 是否值得装，可以先看 SKILL.md 前 50 行——好的 Skill 的 description 读起来像路由规则，而不是宣传语。

选型的一句话建议：如果你的工具只有给 AI 用、且会被多个 AI 应用调用，MCP 值得上；如果你需要把一套稳定的工作流程固化下来、让 AI 在不同会话中保持一致的专业判断，用 Skill。两者一起用，才是 AI Agent 同时拥有“大脑”和“双手”的完整形态。

附：本文推荐资源的快速索引