MCP应用完全解读：AI的「USB时刻」如何重塑人机交互

点火三周

发布于 2026-06-01 19:04:25

100

写在前面：从 Function Calling 到 MCP Apps，我经历了一次认知翻转

大模型调用外部能力这件事，我是一路看着它演化过来的。

最早是 Function Calling——模型学会了"我应该调用一个函数"，但怎么连上那个函数、怎么认证、怎么跨客户端复用，全靠开发者自己糊。每接一个工具就写一套定制集成，N 个 AI 应用 × M 个工具 = N×M 个连接器，脆弱、昂贵、不可扩展。

然后 MCP 来了。Anthropic 在 2024 年底开源了这个协议，把 N×M 降到 N+M。一次构建，处处可用。我当时觉得这是对的方向——AI 需要一个"USB 接口"。

MCP：AI世��的USB-C接口 ▲ 就像USB-C统一了充电和数据传输，MCP正在统一AI与外部世界的连接方式

但到了 2025 年底，Skills 出现了。一个 Markdown 文件就能教会 Agent 完整的操作流程——什么时候做什么、出错怎么办、需要判断时直接用 Agent 自己的 LLM。不用启动额外进程，不用预加载一堆工具 Schema 吃掉 70% 的上下文窗口，不用管 stdio 的进程隔离问题。Perplexity 的 CTO 公开说在内部降低 MCP 优先级，YC 的 Garry Tan 说他 30 分钟就用 CLI 替代了 MCP，Hacker News 上一片"MCP is dead"的声音。

说实话，我一度也这么认为。 Skills 的渐进式加载（只在需要时才展开完整内容）、对 Agent 自身 LLM 的复用能力、以及作为"操作手册"而非"被动工具"的设计哲学，确实在很多场景下比 MCP 更优雅。我当时的判断是：MCP 会被各种 Skill 逐步蚕食，最终沦为一个小众的企业级远程工具协议。

然后 Anthropic 在 2026 年 1 月发布了 MCP Apps。

这完全刷新了我的认知。MCP 不再只是"连接工具的协议"——它变成了一个交互式应用平台。工具可以返回可操作的仪表盘、表单、3D 可视化、实时监控面板，直接在对话中渲染。而且这不是 Anthropic 一家在玩，OpenAI 联合开发，Claude、ChatGPT、VS Code、Goose 同步支持。

Skills 能教 Agent 怎么做事，但它做不到这个——它没法在对话里嵌入一个可交互的 UI，没法让用户点击、拖拽、筛选、下钻。这是协议层才能提供的能力，不是一个 Markdown 文件能解决的问题。

回头看，从 Function Calling → MCP → Skills → MCP Apps，这条线不是"后者替代前者"的线性淘汰，而是能力层的逐步叠加。Function Calling 解决了"要不要调用工具"，MCP 解决了"怎么标准化地连接工具"，Skills 解决了"怎么教 Agent 聪明地使用工具"，MCP Apps 解决了"怎么让人和 AI 在同一个界面里协作"。

每一层都没有被替代，而是被重新定位。 这篇文章，就是我在经历这次认知翻转之后，重新梳理 MCP 的全景。

二、架构深度解析：三个角色，两层协议

MCP的架构其实很优雅，理解三个角色就够了：

MCP架构图 ▲ MCP客户端-服务器架构：Host管理多个Client，每个Client对接一个Server

三个参与者

• Host（主机）：用户直接交互的AI应用——Claude Desktop、VS Code、ChatGPT、Cursor等。它是"总管"，协调一切。
• MCP Client（客户端）：住在Host里的"连接管理员"。每个Client维护与一个Server的专属连接。一个Host可以同时运行多个Client。
• MCP Server（服务器）：提供具体能力的程序。可以跑在本地（通过stdio），也可以跑在远端（通过Streamable HTTP）。

举个例子：你在VS Code里同时连了Sentry和本地文件系统，VS Code就会实例化两个MCP Client，分别维护这两个连接。

两层协议

层级	职责	技术
数据层	定义消息结构和语义：生命周期管理、工具/资源/提示词等核心原语	JSON-RPC 2.0
传输层	处理通信通道和认证	stdio（本地进程）/ Streamable HTTP（远程服务）

三大核心原语

这是MCP最有意思的部分——Server通过三种原语向AI暴露能力：

1. Tools（工具）：AI可以执行的动作——发消息、建记录、跑查询、触发部署。这是MCP的"写"端。
2. Resources（资源）：AI可以读取的数据——文件内容、数据库记录、API响应。这是MCP的"读"端。
3. Prompts（提示词模板）：可复用的交互模板，帮助标准化AI在特定领域的行为。

一个数据库MCP Server可以同时暴露：查询工具（Tools）、数据库Schema（Resources）、以及包含few-shot示例的交互模板（Prompts）。三位一体，AI就能像一个熟练的DBA一样操作你的数据库。

三、MCP Apps：从纯文本到交互式UI的跃迁

这是我认为MCP最具革命性的部分，也是大多数人还没意识到其重要性的部分。

2026年1月，MCP Apps作为第一个官方扩展正式发布。它由Anthropic和OpenAI联合开发，一句话说清楚：MCP工具现在可以返回交互式HTML界面，直接在对话中渲染。

MCP Apps交互式UI示例 ▲ 在Claude Desktop中直接渲染的交互式仪表盘——不是截图，是真正可操作的UI

为什么这是分水岭？

想象一下：你让AI"展示各地区销售数据"。

• 没有MCP Apps：AI返回一堆数字文本。你说"只看上周的"，它重新生成。你说"按收入排序"，又重新生成。每次交互都是一轮新对话。
• 有了MCP Apps：AI直接返回一个交互式地图/图表。你点击区域下钻、悬停查看详情、切换指标——零额外提示词。

这不是"锦上添花"，这是AI从"对话工具"变成"应用平台"的质变。

工作原理

MCP Apps生态全景 ▲ MCP Apps的完整工作流：工具声明UI资源 → Host获取并沙箱渲染 → 双向通信

核心流程四步走：

1. UI预加载：工具描述中包含 _meta.ui.resourceUri 字段，指向 ui:// 资源。Host可以在工具被调用前就预加载。
2. 资源获取：Host从Server获取UI资源——一个打包了HTML/JS/CSS的页面。
3. 沙箱渲染：Host在沙箱iframe中渲染HTML。iframe隔离了应用，无法访问宿主页面的DOM、Cookie或存储。
4. 双向通信：App和Host通过 postMessage 上的JSON-RPC协议通信。App可以调用Server工具、发送消息、更新模型上下文。

// MCP App 代码示例
import { App } from "@modelcontextprotocol/ext-apps";

const app = new App();
await app.connect();

// 接收工具结果
app.ontoolresult = (result) => {
  renderChart(result.data);
};

// 从UI调用服务器工具
const response = await app.callServerTool({
  name: "fetch_details",
  arguments: { id: "123" },
});

// 更新模型上下文
await app.updateModelContext({
  content: [{ type: "text", text: "用户选择了方案B" }],
});

安全模型

跑别人写的UI代码，安全怎么办？MCP Apps用了四层防护：

• iframe沙箱隔离：所有UI内容在受限权限的沙箱iframe中运行
• 预声明模板：Host可以在渲染前审查HTML内容
• 可审计消息：所有UI-Host通信走可记录的JSON-RPC
• 用户同意：Host可以要求用户明确批准UI发起的工具调用

适用场景

场景	说明
数据探索	交互式图表、地图下钻、实时筛选
配置向导	多选项表单，字段联动，即时验证
富媒体查看	PDF内嵌阅读、3D模型旋转、图片预览
实时监控	持续更新的仪表盘，无需反复询问状态
多步骤工作流	审批流程、代码审查、问题分诊

官方示例仓库已包含：Three.js 3D可视化、CesiumJS地球、PDF阅读器、系统监控仪表盘、乐谱渲染器等。支持React、Vue、Svelte、Preact、Solid和原生JavaScript。

四、跨平台安装与运行实战

这是很多人困惑的地方：同一个MCP Server，在不同工具里的安装和体验差异很大。

安装方式对比

平台	.mcpb安装	手动配置Server	沙箱UI支持	体验评级
Claude Desktop	✅ 双击安装	✅	✅ 完全支持	⭐⭐⭐⭐⭐
Claude Code	✅ 命令行安装	✅	✅	⭐⭐⭐⭐⭐
ChatGPT	❌	✅ 远程Server URL	✅	⭐⭐⭐⭐
VS Code (Copilot)	❌	✅	✅ Insiders版支持	⭐⭐⭐⭐
Cursor / Windsurf	❌	✅	✅	⭐⭐⭐⭐
Goose	❌	✅	✅	⭐⭐⭐⭐
WorkBuddy（腾讯龙虾）	❌	✅	❌ 仅纯工具调用	⭐⭐

通用安装三步法

对于不支持 .mcpb 的工具，统一流程：

1. 解压：将 .mcpb 改后缀为 .zip，解压出 server 和 ui 文件夹
2. 配置Server：
- • 本地（stdio）：填启动命令，如 node server/index.js
- • 远程（Streamable HTTP）：填Server URL，如 https://your-server.com/mcp
3. 重启生效

关键认知：同一个MCP Server可以服务所有支持MCP的客户端。 差异只在安装方式和UI渲染能力上。这就是标准协议的力量。

五、生态全景：谁在用MCP？

MCP生态构建 ▲ MCP正在成为AI Agent与外部系统交互的标准层

客户端阵营

Claude、ChatGPT、Gemini、Microsoft Copilot、GitHub Copilot、Cursor、Windsurf、VS Code、Openclaw、hermes、xClaw——几乎所有你叫得出名字的AI工具都已入局。

服务端生态

Slack、GitHub、Google、Salesforce、Stripe、HubSpot、Shopify、Notion、Linear、Sentry、Figma、Webflow、Cloudflare、Postman、WooCommerce……MCP Registry已收录近2000个服务器。

一个有意思的数据：Cloudflare的"Code Mode"通过让Agent动态发现和调用工具（而非预加载所有工具定义），实现了98%以上的Token节省。这说明MCP不只是"能用"，而是在效率上有质的提升。

SDK覆盖

• 官方：TypeScript、Python
• 社区：Java、Kotlin、C#、Go、Rust、Swift

治理

2025年12月，Anthropic将MCP捐赠给Linux Foundation下的Agentic AI Foundation。OpenAI和Block作为联合创始成员，AWS、Google、Microsoft、Cloudflare、GitHub、Bloomberg作为支持成员。这不再是Anthropic的"自家协议"，而是真正的行业标准。

六、2026路线图：四大优先方向

2026年3月发布的路线图，从"按版本发布"转向了"按工作组驱动"。四个核心优先领域：

1. 传输演进与可扩展性

Streamable HTTP让远程Server成为可能，但规模化运行暴露了问题：有状态会话与负载均衡冲突、水平扩展需要变通方案、缺乏标准化的服务器发现机制。工作重点：无状态水平扩展 + MCP Server Cards（通过 .well-known URL暴露元数据）。

2. Agent通信

Tasks原语（异步任务）已作为实验特性发布，生产使用暴露了生命周期管理的缺口：失败重试语义、结果过期策略。这是"先发布再迭代"策略的典型体现。

3. 治理成熟化

目前每个SEP（规范增强提案）都需要核心维护者全量审查——这是瓶颈。目标：建立贡献者阶梯，让受信任的工作组在其领域内自主接受SEP。

4. 企业就绪

企业部署MCP遇到的可预见问题：审计追踪、SSO集成认证、网关行为、配置可移植性。大部分工作预计以扩展而非核心规范变更的形式落地。

七、我的观点：三个经历过认知翻转之后的判断

判断一：Skills 和 MCP 不是替代关系，而是"菜谱"和"厨具"的关系

这是我踩过的认知坑，所以说得具体一点。

Skills 本质上是知识层——它是一份操作手册，告诉 Agent "遇到这种情况，先做 A，再做 B，出错了做 C"。它的优势是轻量（只加载元数据，按需展开）、能复用 Agent 自身的 LLM 做判断、能编码多步骤工作流。Zilliz 团队的实践很有说服力：他们用 MCP Server 做向量搜索，返回 10 条结果，其中 7 条是噪音——但 MCP Server 跑在独立进程里，没法调用 Agent 的 LLM 来过滤。换成 Skill，Agent 自己就能判断哪些结果值得保留。

但 Skills 有一个根本性的局限：它依赖执行环境。 一个需要 CLI 的 Skill，在 ChatGPT 网页版里是废的，在 Perplexity 里是废的，在手机上的 Claude 里也是废的。而一个远程 MCP Server？你只需要一个 URL，任何支持 MCP 的客户端都能用，不装任何东西，不管任何密钥。

所以我现在的理解是：

• MCP = 厨具（连接器）：标准化地连接服务，处理认证、传输、发现
• Skills = 菜谱（知识层）：教 Agent 怎么聪明地使用这些厨具
• 两者最佳实践 = 菜谱 + 厨具一起用

David Mohl 的做法我很认同：用 MCP 连接 Notion、DEVONthink 等服务，然后写 Skill 记录使用这些 MCP 工具时踩过的坑——日期格式要用 YYYY-MM-DD、搜索函数不加参数会截断结果之类的。MCP 负责连接，Skill 负责让连接变得聪明。

判断二：MCP Apps 是 Anthropic 对"MCP 已死"论调最有力的回应

2025 年底到 2026 年初，"MCP is dead"几乎成了共识。我自己也差点信了。

但 MCP Apps 的发布，本质上是在说：你们讨论的 MCP 只是 MCP 的上半场。

上半场的 MCP 确实有问题——工具 Schema 预加载吃上下文、stdio 模式下进程隔离不稳定、本地开发体验不如 CLI + Skills。这些批评都是对的。

但下半场的 MCP 做了一件 Skills 永远做不到的事：在对话中嵌入可交互的应用界面。

想想看：

• 一个 Skill 可以教 Agent 怎么查询销售数据并格式化输出。但它没法让你在对话里直接看到一个可点击的地图，悬停查看各区域详情，切换时间维度。
• 一个 Skill 可以教 Agent 怎么配置部署参数。但它没法给你一个表单，选"生产环境"时自动展开安全选项，选"测试环境"时显示不同默认值。
• 一个 Skill 可以教 Agent 怎么分析 PDF。但它没法在对话里内嵌一个 PDF 阅读器，让你点击高亮条款直接批注。

MCP Apps交互式UI示例 ▲ 在Claude Desktop中直接渲染的交互式仪表盘——这是Skills做不到的事

这就是为什么 MCP Apps 由 Anthropic 和 OpenAI 联合开发，Claude、ChatGPT、VS Code、Goose 同步支持。这不是一家公司的功能更新，这是行业在用行动投票：AI 的交互界面需要一个协议级的标准，而不是各家各搞一套。

MCP Apps 让 AI 对话从"信息交换"升级为"操作界面"。如果说 Skills 让 Agent 变得更聪明，MCP Apps 则让 Agent 变得更可用。聪明但只能输出文本的 Agent，和聪明且能提供可交互界面的 Agent，是两个物种。

判断三：真正的终局是分层协作，不是赢者通吃

经历了"MCP 要死了"到"MCP Apps 真香"的认知翻转，我现在对这类"A 替代 B"的叙事保持高度警惕。

回看整条演化链：

层级	解决的问题	代表
决策层	要不要调用工具？	Function Calling
连接层	怎么标准化地连接工具？	MCP Protocol
知识层	怎么教 Agent 聪明地用工具？	Skills / Skill.md
交互层	怎么让人和 AI 在同一界面协作？	MCP Apps