尧图网页设计 
Skill、MCP 与 APIAI 应用开发的三个 “能力层级” 学习笔记一、先给结论三个词分别是什么概念一句话定义API程序与程序之间的调用契约规定 “谁能调、怎么调、返回什么”MCP专为大模型设计的标准化工具连接协议让任何 AI 客户端都能 “即插即用” 外部工具和数据Skill把 “指令 知识 流程 代码” 打包成可复用单元的技能包让 AI 能完整地做成一类任务浓缩成一句记忆锚点API 提供能力MCP 让 AI 用得上能力Skill 让 AI 用得专业。二、逐个拆解2.1 API能力的 “原子单元”什么是 APIAPIApplication Programming Interface应用程序接口是一组明确定义的规则和端点Endpoint让不同软件之间能够通信。它是软件世界最底层的协作方式 —— 从 1990 年代的 SOAP、REST到今天的 GraphQL核心思想没变过把能力封装成可被调用的接口。一个典型的 REST API 包含四要素要素说明例子端点 URL能力所在的地址https://api.openweathermap.org/data/2.5/weather方法操作类型GET/POST/PUT/DELETE参数请求条件?cityShanghaiunitsmetric鉴权你是谁apikey、Authorization: Bearer xxx代码示例用 Python 调用一个天气 APIimport requests # 以 OpenWeatherMap 为例https://openweathermap.org/api免费注册即可申请 key API_KEY 你的_APPID CITY Shanghai resp requests.get( https://api.openweathermap.org/data/2.5/weather, params{q: CITY, appid: API_KEY, units: metric}, timeout10, ) data resp.json() print(f城市: {data[name]}) print(f天气: {data[weather][0][description]}) print(f温度: {data[main][temp]}°C)API 的特点面向开发者和程序不关心调用方是人还是 AI无状态、一次一调用是 “能力的原子单元”接口一旦发布就尽量保持稳定向后兼容变更成本高。2.2 MCPAI 世界的 “USB 接口”背景为什么会有 MCP传统 API 时代每个 AI 应用要接入一个新工具都要为它单独写一遍适配代码把 API 的参数、鉴权、返回格式翻译成模型能理解的形式。工具越多代码越爆炸生态碎片化严重。2024 年底Anthropic 提出并开源了MCPModel Context Protocol模型上下文协议目标是把 “AI 连接外部工具” 这件事标准化。如今 MCP 已是多家厂商共同推进的开放标准现已移交 Linux 基金会管理。MCP 的架构三要素┌─────────────────────────────────────────────┐ │ MCP Host客户端 │ │ 例如Claude Desktop / Cline / 各类 AI 应用 │ │ —— 发起请求、使用工具 │ └──────────────┬──────────────────────────────┘ │ 统一协议stdio / SSE / HTTP ┌──────────────▼──────────────────────────────┐ │ MCP Server工具提供方 │ │ —— 暴露三类能力 │ │ · Resources 资源数据 │ │ · Tools 工具可执行操作 │ │ · Prompts 提示可复用指令模板 │ └──────────────┬──────────────────────────────┘ │ 内部调用 ┌──────────────▼──────────────────────────────┐ │ 真实业务能力天气 API / 数据库 / 文件系统 │ └─────────────────────────────────────────────┘类比USB 与电源线没有标准之前每个外设都有自己的 “电源线”每个 API 有各自的 SDK 和文档换一台电脑可能就用不了有了 USB任何设备往标准接口上一插就能用对应关系API 是 “电源线”MCP 是 “USB 接口”AI 客户端是 “电脑”。代码示例 1在支持 MCP 的客户端中配置一个 MCP Server以下配置直接放入 Claude Desktop、Cline 等客户端的配置文件如claude_desktop_config.json即可让 AI 拥有天气查询能力{ mcpServers: { weather: { command: npx, args: [ -y, modelcontextprotocol/server-weather ] } } }代码示例 2用官方 Python SDK 手动连接同一个 MCP Serverimport asyncio from mcp import ClientSession, StdioServerParameters from mcp.client.stdio import stdio_client async def main(): # 通过标准输入输出(stdin/stdout)启动一个本地 MCP Server server_params StdioServerParameters( commandnpx, args[-y, modelcontextprotocol/server-weather], ) async with stdio_client(server_params) as (read, write): async with ClientSession(read, write) as session: # 1. 列出这个 MCP Server 暴露了哪些工具 tools await session.list_tools() for tool in tools.tools: print(f工具名: {tool.name}) print(f描述: {tool.description}) print(f入参 Schema: {tool.inputSchema}) print(- * 40) asyncio.run(main())MCP 的特点面向大模型设计让模型可以 “发现工具、理解参数、调用工具、拿到结构化结果”一套代码接入所有支持 MCP 的客户端大幅降低工具接入成本本质是协议Protocol不是能力本身 —— 它必须依托真实的 API / 数据源才能干活。2.3 SkillAI 的 “岗位说明书 工具箱”什么是 SkillAPI 解决 “能不能调用”MCP 解决 “好不好接入”但要让 AI像专家一样完整做成一件事比如 “每日生成一份天气日报”还需要第三个东西把任务流程、领域知识、提示词指令、可执行脚本组织成一个可复用的单元这就是Skill技能包。一个 Skill 通常是一个目录包含my-weather-daily-skill/ ├── SKILL.md # 技能说明书名称、触发条件、执行流程、注意事项 ├── assets/ # 模板、示例、图片等静态资源 └── scripts/ └── build_report.py # 实际执行脚本可选代码示例一份 SKILL.md 长什么样--- name: 天气日报生成 description: 当用户需要天气日报 / 每日天气总结时使用本技能。 --- ## 执行步骤 1. 调用 MCP 天气工具查询目标城市当日及未来 3 天天气 2. 按模板组织日报天气概述、穿衣建议、通勤提示 3. 输出 Markdown 报告并标注数据更新时间。 ## 注意事项 - 城市未指定时默认使用用户所在城市 - 温度单位统一使用摄氏度 - 数据异常如接口超时时提示用户稍后重试不要编造数据。Skill 与 Function Calling / Prompt 的区别方案层级解决什么局限Prompt 工程指令层告诉 AI “怎么做”每次都要重新注入知识无法沉淀Function Calling函数层让 AI 调用单个函数只解决 “调用”不解决 “流程与知识”Skill任务层指令 知识 流程 代码一体封装需要 Agent 运行时支持加载Skill 的特点面向AI Agent设计描述的是 “一类任务怎么做才专业”可复制、可分享、可版本管理本质是一个文件夹内部可以自由组合可以调 MCP 工具也可以直接调 API甚至只包含指令与模板、不含任何代码。三、区别一张表说清楚维度APIMCPSkill本质接口契约通信协议工作流 / 知识封装抽象层级低能力原子中连接层高任务层服务对象开发者 / 程序大模型与 AI 客户端AI Agent是否依赖 LLM否纯软件概念是专为 LLM 而生是依赖 Agent 运行时粒度单个函数 / 端点一组工具 资源 提示完整任务解决方案复用方式代码 / HTTP 调用客户端配置即插即用拷贝文件夹即复用典型例子天气查询接口weather MCP Server“每日天气日报” 技能包没有它会怎样程序无法互通AI 每接一个工具就写一遍适配代码AI 只会单步调用不懂完整流程三个关键差异务必记住抽象层级不同API 在最底层能力MCP 在中间连接Skill 在最上层任务服务对象不同API 服务程序MCP 服务模型Skill 服务 Agent“是否依赖 AI” 不同API 是纯软件概念没有 AI 它也成立MCP 和 Skill 都是为 AI 时代而生。四、重点三者之间的 “联系”4.1 一张图看懂整体调用链┌───────────────────────────────────────────────────┐ │ 用户 / 应用层 │ ├───────────────────────────────────────────────────┤ │ AI Agent决策大脑 │ │ ┌─────────────────────────────────────────────┐ │ │ │ Skill 技能包任务层 │ │ │ │ · 任务流程 · 领域知识 · 模板 · 脚本 │ │ │ └────────────────────┬────────────────────────┘ │ │ │ ① 编排决定怎么做 │ │ ┌────────────────────▼────────────────────────┐ │ │ │ MCP 连接层协议层 │ │ │ │ · 发现工具 · 参数映射 · 统一返回格式 │ │ │ └────────────────────┬────────────────────────┘ │ │ │ ② 路由决定调什么 │ │ ┌────────────────────▼────────────────────────┐ │ │ │ API 能力层接口层 │ │ │ │ · 天气服务 · 数据库 · 业务系统 · 文件 │ │ │ └─────────────────────────────────────────────┘ │ ├───────────────────────────────────────────────────┤ │ 后端服务 / 数据源 │ └───────────────────────────────────────────────────┘一句话概括这张图Skill 负责 “怎么干”MCP 负责 “怎么连”API 负责 “干什么”。上层决定方向下层提供能力数据沿着相反方向流回。4.2 联系维度一层层封装不是并列关系三者是包含式的调用链而不是同一层次上的三个选项Skill 可以调用 MCP推荐方式也可以绕过 MCP 直接调 API例如在脚本里写死一个requests.getMCP 内部必然调用 API / 数据源—— 协议本身不产生能力它只是 “翻译官” 和 “快递员”API 不依赖任何上层—— 没有 AI 它依然服务普通程序它是这条链上唯一 “独立存活” 的一层。依赖关系用代码表达一个简化示意# skill_layer.py —— 任务层编排流程 class WeatherDailySkill: def run(self, city: str) - str: data self.mcp.call_tool(weather, {city: city}) # 经 MCP 调用 return self.render_report(data) # 按模板产出成品 # mcp_layer.py —— 连接层协议适配 class MCPClient: def call_tool(self, tool: str, args: dict): schema self.discover(tool) # 发现工具 return self.session.call_tool(tool, args) # 调底层 API # api_layer.py —— 能力层真实服务 # 最终由 weather API 返回 JSON 数据4.3 联系维度二数据流与控制流 —— 每层都在 “提纯”同样一份天气数据经过三层时形态完全不同原始 JSONAPI 层 │ {weather:[{description:clear sky}],main:{temp:18.0}} ▼ 结构化工具结果MCP 层 │ ToolResult[weather: clear sky, temp: 18°C, city: Shanghai] ▼ 用户可读成品Skill 层 │ 「上海今日晴气温 18°C早晚偏凉建议穿薄外套出行。」控制流下行用户指令 → Agent 决策 → Skill 规划 → MCP 路由 → API 执行数据流上行API 给原始数据MCP 给模型可读的 SchemaSkill 给用户可用的成品关键点每一层都在 “降噪提纯”—— 这正是分层存在的意义让模型少处理噪音让用户少看中间态。4.4 联系维度三时间演进 —— 同一个问题被回答了三次三者不是同时出现的而是 AI 应用工程化逐步上移的三个阶段阶段1人肉时代 开发者写代码调 API ──► 能力可用但每接入一个工具都要人写适配 阶段2Function Calling 时代 模型学会自己选函数调 API ──► 能力可被 AI 用了但每个工具仍要单独适配 阶段3MCP 时代2024 底起 协议标准化一次接入处处可用 ──► AI 连接工具从定制变成即插即用 阶段4Skill 时代2025 起 把流程/知识/代码打包成技能 ──► 从能调用进化到会做事理解这条时间线就理解了为什么三者在工作中同时存在老问题没消失新问题叠加上来每一层解决一层问题。4.5 联系维度四生态上互相成就MCP Server 越多 → Skill 可编排的工具越多Skill 的威力上限取决于底层工具的丰富度Skill 的需求越旺盛 → 越倒逼服务商提供 MCP 端点因为 “能被 AI 用” 成了新卖点API 是源头活水无论上面怎么包装最终能力都落在 API 与数据上 —— 包装层可以换底层能力不可替代。4.6 完整场景走一遍把上面的联系串起来用户说“看看上海明天天气帮我出一份日报。”Agent收到指令识别任务类型是 “天气日报”加载对应的Skill拿到步骤、模板、注意事项Skill 流程第 1 步调用MCP Client按协议查找 weather 工具MCP Client 完成参数映射调用MCP ServerMCP Server 内部真正去请求天气 API可能还串了数据库缓存原始 JSON 沿链路返回MCP 转成结构化结果Skill 按模板加工AI 把成品 Markdown 报告呈现给用户天气概述、穿衣建议、通勤提示。五、重点未来的演进方向5.1 方向一协议层继续收敛 —— 从 “工具标准” 到 “智能体标准”MCP 正在成为 “AI 时代的 USB”越来越多的 SaaS 平台、云厂商直接提供 MCP 端点就像今天所有服务都提供 REST API 一样企业接入 AI 的成本会从 “开发适配” 降为 “填一行配置”智能体间协议兴起MCP 解决 “模型 ↔ 工具”而 A2AAgent-to-Agent这类协议正在解决 “Agent ↔ Agent”未来会是 “工具层 MCP、协作层 A2A” 的双协议格局结果是Skill 的可移植性大增—— 同一个技能包换任何支持协议的客户端都能跑。5.2 方向二Skill 生态化 —— 技能像 App 一样分发技能市场 / 技能仓库类似 npm 与 App StoreSkill 可以安装、分享、评分、收费规范统一与版本管理SKILL.md等元数据规范逐步标准化技能可声明依赖需要哪些 MCP、哪些 API可签名、可审计结果是“复制粘贴一个文件夹” 的轻量复用升级为 “一键安装、自动校验依赖” 的工业化复用。5.3 方向三从 “工具调用” 到 “自主工作流”现在的 Skill 本质是 “静态流程说明书”未来会内嵌规划、记忆、反思、校验能力先规划步骤 → 执行 → 检查结果 → 失败自动重试或换策略Agent 从 “一步一步调工具” 升级为 “经营一个任务”自己拆解、自己调度多个 Skill 和 MCP、自己向用户汇报进度结果是Skill 从 “说明书” 进化为 “自主执行的微程序”API/MCP 变成它的执行器官。5.4 方向四安全与治理成为硬门槛MCP 权限分级按工具粒度授权只读 / 可写 / 不可调用避免 “模型能调一切”Skill 沙箱化技能脚本在受限环境中运行隔离敏感数据全链路审计API 调用 → MCP 路由 → Skill 编排每一步可回溯、可撤销结果是能力越强管控越严—— 安全会成为这三层之上新的 “第四层”。5.5 方向五个性化与知识沉淀 ——“越用越懂你”Skill 与用户画像、长期记忆结合同一套技能对不同用户产出不同风格的结果API/MCP 返回的数据会反哺记忆库形成 “数据 → 知识 → 技能” 的闭环结果是通用能力API→ 标准接入MCP→ 专业流程Skill→ 私人定制个性化 Skill四层递进。5.6 演进全景图现在2025-2026 未来3-5 年 ────────────────────── ───────────────────────────── API 仍是能力底座 ──────────► API 底座不变更多服务原生开放 MCP 端点 MCP 快速普及工具连接标准──► MCP 成为事实标准A2A 补上智能体协作层 Skill 以文件夹形式分发 ─────► Skill 进入技能市场带依赖、签名、版本 Agent 按技能说明书执行 ─────► Agent 自主规划Skill 变成可自省的微程序 权限靠手工配置 ──────────► 权限分级 沙箱 全链路审计成为默认项六、类比速记生活类比APIMCPSkill水电场景自来水管能出水标准水龙头接口谁都能拧上一套 “净水→烧水→泡茶” 的完整流程外设场景各种电源线各管各的USB 接口统一标准一键安装的 “驱动 软件套装”厨房场景食材能力原料标准灶具接口一整套菜谱步骤 火候 摆盘一句话记忆链API 有东西可调MCP 调起来方便Skill 调得好、调得专业。七、总结Skill怎么做才专业 → MCP怎么接入才标准 → API有什么能力可用 任务层 连接层 能力层API是软件世界的基石没有 AI 也成立MCP是 AI 时代的 “USB 接口”解决工具接入碎片化Skill是 AI 时代的 “岗位说明书 工具箱”让 Agent 完成端到端的专业任务。三者不是替代关系而是层层封装、协同分工、同步演进底层能力标准化上层任务专业化中间协议打通一切。未来五年这条链会继续向上生长 —— 从 “工具连接” 到 “智能体协作”从 “静态技能” 到 “自主工作流”。理解这条链路就抓住了 AI Agent 工程化的主线。 Datawhale学习笔记：Skill、MCP与API的区别和联系
Skill、MCP 与 APIAI 应用开发的三个 “能力层级” 学习笔记一、先给结论三个词分别是什么概念一句话定义API程序与程序之间的调用契约规定 “谁能调、怎么调、返回什么”MCP专为大模型设计的标准化工具连接协议让任何 AI 客户端都能 “即插即用” 外部工具和数据Skill把 “指令 知识 流程 代码” 打包成可复用单元的技能包让 AI 能完整地做成一类任务浓缩成一句记忆锚点API 提供能力MCP 让 AI 用得上能力Skill 让 AI 用得专业。二、逐个拆解2.1 API能力的 “原子单元”什么是 APIAPIApplication Programming Interface应用程序接口是一组明确定义的规则和端点Endpoint让不同软件之间能够通信。它是软件世界最底层的协作方式 —— 从 1990 年代的 SOAP、REST到今天的 GraphQL核心思想没变过把能力封装成可被调用的接口。一个典型的 REST API 包含四要素要素说明例子端点 URL能力所在的地址https://api.openweathermap.org/data/2.5/weather方法操作类型GET/POST/PUT/DELETE参数请求条件?cityShanghaiunitsmetric鉴权你是谁apikey、Authorization: Bearer xxx代码示例用 Python 调用一个天气 APIimport requests # 以 OpenWeatherMap 为例https://openweathermap.org/api免费注册即可申请 key API_KEY 你的_APPID CITY Shanghai resp requests.get( https://api.openweathermap.org/data/2.5/weather, params{q: CITY, appid: API_KEY, units: metric}, timeout10, ) data resp.json() print(f城市: {data[name]}) print(f天气: {data[weather][0][description]}) print(f温度: {data[main][temp]}°C)API 的特点面向开发者和程序不关心调用方是人还是 AI无状态、一次一调用是 “能力的原子单元”接口一旦发布就尽量保持稳定向后兼容变更成本高。2.2 MCPAI 世界的 “USB 接口”背景为什么会有 MCP传统 API 时代每个 AI 应用要接入一个新工具都要为它单独写一遍适配代码把 API 的参数、鉴权、返回格式翻译成模型能理解的形式。工具越多代码越爆炸生态碎片化严重。2024 年底Anthropic 提出并开源了MCPModel Context Protocol模型上下文协议目标是把 “AI 连接外部工具” 这件事标准化。如今 MCP 已是多家厂商共同推进的开放标准现已移交 Linux 基金会管理。MCP 的架构三要素┌─────────────────────────────────────────────┐ │ MCP Host客户端 │ │ 例如Claude Desktop / Cline / 各类 AI 应用 │ │ —— 发起请求、使用工具 │ └──────────────┬──────────────────────────────┘ │ 统一协议stdio / SSE / HTTP ┌──────────────▼──────────────────────────────┐ │ MCP Server工具提供方 │ │ —— 暴露三类能力 │ │ · Resources 资源数据 │ │ · Tools 工具可执行操作 │ │ · Prompts 提示可复用指令模板 │ └──────────────┬──────────────────────────────┘ │ 内部调用 ┌──────────────▼──────────────────────────────┐ │ 真实业务能力天气 API / 数据库 / 文件系统 │ └─────────────────────────────────────────────┘类比USB 与电源线没有标准之前每个外设都有自己的 “电源线”每个 API 有各自的 SDK 和文档换一台电脑可能就用不了有了 USB任何设备往标准接口上一插就能用对应关系API 是 “电源线”MCP 是 “USB 接口”AI 客户端是 “电脑”。代码示例 1在支持 MCP 的客户端中配置一个 MCP Server以下配置直接放入 Claude Desktop、Cline 等客户端的配置文件如claude_desktop_config.json即可让 AI 拥有天气查询能力{ mcpServers: { weather: { command: npx, args: [ -y, modelcontextprotocol/server-weather ] } } }代码示例 2用官方 Python SDK 手动连接同一个 MCP Serverimport asyncio from mcp import ClientSession, StdioServerParameters from mcp.client.stdio import stdio_client async def main(): # 通过标准输入输出(stdin/stdout)启动一个本地 MCP Server server_params StdioServerParameters( commandnpx, args[-y, modelcontextprotocol/server-weather], ) async with stdio_client(server_params) as (read, write): async with ClientSession(read, write) as session: # 1. 列出这个 MCP Server 暴露了哪些工具 tools await session.list_tools() for tool in tools.tools: print(f工具名: {tool.name}) print(f描述: {tool.description}) print(f入参 Schema: {tool.inputSchema}) print(- * 40) asyncio.run(main())MCP 的特点面向大模型设计让模型可以 “发现工具、理解参数、调用工具、拿到结构化结果”一套代码接入所有支持 MCP 的客户端大幅降低工具接入成本本质是协议Protocol不是能力本身 —— 它必须依托真实的 API / 数据源才能干活。2.3 SkillAI 的 “岗位说明书 工具箱”什么是 SkillAPI 解决 “能不能调用”MCP 解决 “好不好接入”但要让 AI像专家一样完整做成一件事比如 “每日生成一份天气日报”还需要第三个东西把任务流程、领域知识、提示词指令、可执行脚本组织成一个可复用的单元这就是Skill技能包。一个 Skill 通常是一个目录包含my-weather-daily-skill/ ├── SKILL.md # 技能说明书名称、触发条件、执行流程、注意事项 ├── assets/ # 模板、示例、图片等静态资源 └── scripts/ └── build_report.py # 实际执行脚本可选代码示例一份 SKILL.md 长什么样--- name: 天气日报生成 description: 当用户需要天气日报 / 每日天气总结时使用本技能。 --- ## 执行步骤 1. 调用 MCP 天气工具查询目标城市当日及未来 3 天天气 2. 按模板组织日报天气概述、穿衣建议、通勤提示 3. 输出 Markdown 报告并标注数据更新时间。 ## 注意事项 - 城市未指定时默认使用用户所在城市 - 温度单位统一使用摄氏度 - 数据异常如接口超时时提示用户稍后重试不要编造数据。Skill 与 Function Calling / Prompt 的区别方案层级解决什么局限Prompt 工程指令层告诉 AI “怎么做”每次都要重新注入知识无法沉淀Function Calling函数层让 AI 调用单个函数只解决 “调用”不解决 “流程与知识”Skill任务层指令 知识 流程 代码一体封装需要 Agent 运行时支持加载Skill 的特点面向AI Agent设计描述的是 “一类任务怎么做才专业”可复制、可分享、可版本管理本质是一个文件夹内部可以自由组合可以调 MCP 工具也可以直接调 API甚至只包含指令与模板、不含任何代码。三、区别一张表说清楚维度APIMCPSkill本质接口契约通信协议工作流 / 知识封装抽象层级低能力原子中连接层高任务层服务对象开发者 / 程序大模型与 AI 客户端AI Agent是否依赖 LLM否纯软件概念是专为 LLM 而生是依赖 Agent 运行时粒度单个函数 / 端点一组工具 资源 提示完整任务解决方案复用方式代码 / HTTP 调用客户端配置即插即用拷贝文件夹即复用典型例子天气查询接口weather MCP Server“每日天气日报” 技能包没有它会怎样程序无法互通AI 每接一个工具就写一遍适配代码AI 只会单步调用不懂完整流程三个关键差异务必记住抽象层级不同API 在最底层能力MCP 在中间连接Skill 在最上层任务服务对象不同API 服务程序MCP 服务模型Skill 服务 Agent“是否依赖 AI” 不同API 是纯软件概念没有 AI 它也成立MCP 和 Skill 都是为 AI 时代而生。四、重点三者之间的 “联系”4.1 一张图看懂整体调用链┌───────────────────────────────────────────────────┐ │ 用户 / 应用层 │ ├───────────────────────────────────────────────────┤ │ AI Agent决策大脑 │ │ ┌─────────────────────────────────────────────┐ │ │ │ Skill 技能包任务层 │ │ │ │ · 任务流程 · 领域知识 · 模板 · 脚本 │ │ │ └────────────────────┬────────────────────────┘ │ │ │ ① 编排决定怎么做 │ │ ┌────────────────────▼────────────────────────┐ │ │ │ MCP 连接层协议层 │ │ │ │ · 发现工具 · 参数映射 · 统一返回格式 │ │ │ └────────────────────┬────────────────────────┘ │ │ │ ② 路由决定调什么 │ │ ┌────────────────────▼────────────────────────┐ │ │ │ API 能力层接口层 │ │ │ │ · 天气服务 · 数据库 · 业务系统 · 文件 │ │ │ └─────────────────────────────────────────────┘ │ ├───────────────────────────────────────────────────┤ │ 后端服务 / 数据源 │ └───────────────────────────────────────────────────┘一句话概括这张图Skill 负责 “怎么干”MCP 负责 “怎么连”API 负责 “干什么”。上层决定方向下层提供能力数据沿着相反方向流回。4.2 联系维度一层层封装不是并列关系三者是包含式的调用链而不是同一层次上的三个选项Skill 可以调用 MCP推荐方式也可以绕过 MCP 直接调 API例如在脚本里写死一个requests.getMCP 内部必然调用 API / 数据源—— 协议本身不产生能力它只是 “翻译官” 和 “快递员”API 不依赖任何上层—— 没有 AI 它依然服务普通程序它是这条链上唯一 “独立存活” 的一层。依赖关系用代码表达一个简化示意# skill_layer.py —— 任务层编排流程 class WeatherDailySkill: def run(self, city: str) - str: data self.mcp.call_tool(weather, {city: city}) # 经 MCP 调用 return self.render_report(data) # 按模板产出成品 # mcp_layer.py —— 连接层协议适配 class MCPClient: def call_tool(self, tool: str, args: dict): schema self.discover(tool) # 发现工具 return self.session.call_tool(tool, args) # 调底层 API # api_layer.py —— 能力层真实服务 # 最终由 weather API 返回 JSON 数据4.3 联系维度二数据流与控制流 —— 每层都在 “提纯”同样一份天气数据经过三层时形态完全不同原始 JSONAPI 层 │ {weather:[{description:clear sky}],main:{temp:18.0}} ▼ 结构化工具结果MCP 层 │ ToolResult[weather: clear sky, temp: 18°C, city: Shanghai] ▼ 用户可读成品Skill 层 │ 「上海今日晴气温 18°C早晚偏凉建议穿薄外套出行。」控制流下行用户指令 → Agent 决策 → Skill 规划 → MCP 路由 → API 执行数据流上行API 给原始数据MCP 给模型可读的 SchemaSkill 给用户可用的成品关键点每一层都在 “降噪提纯”—— 这正是分层存在的意义让模型少处理噪音让用户少看中间态。4.4 联系维度三时间演进 —— 同一个问题被回答了三次三者不是同时出现的而是 AI 应用工程化逐步上移的三个阶段阶段1人肉时代 开发者写代码调 API ──► 能力可用但每接入一个工具都要人写适配 阶段2Function Calling 时代 模型学会自己选函数调 API ──► 能力可被 AI 用了但每个工具仍要单独适配 阶段3MCP 时代2024 底起 协议标准化一次接入处处可用 ──► AI 连接工具从定制变成即插即用 阶段4Skill 时代2025 起 把流程/知识/代码打包成技能 ──► 从能调用进化到会做事理解这条时间线就理解了为什么三者在工作中同时存在老问题没消失新问题叠加上来每一层解决一层问题。4.5 联系维度四生态上互相成就MCP Server 越多 → Skill 可编排的工具越多Skill 的威力上限取决于底层工具的丰富度Skill 的需求越旺盛 → 越倒逼服务商提供 MCP 端点因为 “能被 AI 用” 成了新卖点API 是源头活水无论上面怎么包装最终能力都落在 API 与数据上 —— 包装层可以换底层能力不可替代。4.6 完整场景走一遍把上面的联系串起来用户说“看看上海明天天气帮我出一份日报。”Agent收到指令识别任务类型是 “天气日报”加载对应的Skill拿到步骤、模板、注意事项Skill 流程第 1 步调用MCP Client按协议查找 weather 工具MCP Client 完成参数映射调用MCP ServerMCP Server 内部真正去请求天气 API可能还串了数据库缓存原始 JSON 沿链路返回MCP 转成结构化结果Skill 按模板加工AI 把成品 Markdown 报告呈现给用户天气概述、穿衣建议、通勤提示。五、重点未来的演进方向5.1 方向一协议层继续收敛 —— 从 “工具标准” 到 “智能体标准”MCP 正在成为 “AI 时代的 USB”越来越多的 SaaS 平台、云厂商直接提供 MCP 端点就像今天所有服务都提供 REST API 一样企业接入 AI 的成本会从 “开发适配” 降为 “填一行配置”智能体间协议兴起MCP 解决 “模型 ↔ 工具”而 A2AAgent-to-Agent这类协议正在解决 “Agent ↔ Agent”未来会是 “工具层 MCP、协作层 A2A” 的双协议格局结果是Skill 的可移植性大增—— 同一个技能包换任何支持协议的客户端都能跑。5.2 方向二Skill 生态化 —— 技能像 App 一样分发技能市场 / 技能仓库类似 npm 与 App StoreSkill 可以安装、分享、评分、收费规范统一与版本管理SKILL.md等元数据规范逐步标准化技能可声明依赖需要哪些 MCP、哪些 API可签名、可审计结果是“复制粘贴一个文件夹” 的轻量复用升级为 “一键安装、自动校验依赖” 的工业化复用。5.3 方向三从 “工具调用” 到 “自主工作流”现在的 Skill 本质是 “静态流程说明书”未来会内嵌规划、记忆、反思、校验能力先规划步骤 → 执行 → 检查结果 → 失败自动重试或换策略Agent 从 “一步一步调工具” 升级为 “经营一个任务”自己拆解、自己调度多个 Skill 和 MCP、自己向用户汇报进度结果是Skill 从 “说明书” 进化为 “自主执行的微程序”API/MCP 变成它的执行器官。5.4 方向四安全与治理成为硬门槛MCP 权限分级按工具粒度授权只读 / 可写 / 不可调用避免 “模型能调一切”Skill 沙箱化技能脚本在受限环境中运行隔离敏感数据全链路审计API 调用 → MCP 路由 → Skill 编排每一步可回溯、可撤销结果是能力越强管控越严—— 安全会成为这三层之上新的 “第四层”。5.5 方向五个性化与知识沉淀 ——“越用越懂你”Skill 与用户画像、长期记忆结合同一套技能对不同用户产出不同风格的结果API/MCP 返回的数据会反哺记忆库形成 “数据 → 知识 → 技能” 的闭环结果是通用能力API→ 标准接入MCP→ 专业流程Skill→ 私人定制个性化 Skill四层递进。5.6 演进全景图现在2025-2026 未来3-5 年 ────────────────────── ───────────────────────────── API 仍是能力底座 ──────────► API 底座不变更多服务原生开放 MCP 端点 MCP 快速普及工具连接标准──► MCP 成为事实标准A2A 补上智能体协作层 Skill 以文件夹形式分发 ─────► Skill 进入技能市场带依赖、签名、版本 Agent 按技能说明书执行 ─────► Agent 自主规划Skill 变成可自省的微程序 权限靠手工配置 ──────────► 权限分级 沙箱 全链路审计成为默认项六、类比速记生活类比APIMCPSkill水电场景自来水管能出水标准水龙头接口谁都能拧上一套 “净水→烧水→泡茶” 的完整流程外设场景各种电源线各管各的USB 接口统一标准一键安装的 “驱动 软件套装”厨房场景食材能力原料标准灶具接口一整套菜谱步骤 火候 摆盘一句话记忆链API 有东西可调MCP 调起来方便Skill 调得好、调得专业。七、总结Skill怎么做才专业 → MCP怎么接入才标准 → API有什么能力可用 任务层 连接层 能力层API是软件世界的基石没有 AI 也成立MCP是 AI 时代的 “USB 接口”解决工具接入碎片化Skill是 AI 时代的 “岗位说明书 工具箱”让 Agent 完成端到端的专业任务。三者不是替代关系而是层层封装、协同分工、同步演进底层能力标准化上层任务专业化中间协议打通一切。未来五年这条链会继续向上生长 —— 从 “工具连接” 到 “智能体协作”从 “静态技能” 到 “自主工作流”。理解这条链路就抓住了 AI Agent 工程化的主线。