MCP Apps：AI 时代的 App Store，可能不会长得像 App Store

Mon, 06 Jul 2026 08:00:00 +0800

MCP Apps 这件事，真正值得看的不是“又多了一个协议扩展”。

它的起点其实很朴素：MCP 最初解决的是“AI 应用怎么连接外部系统”。也就是让模型能通过标准接口访问文件、数据库、搜索、业务系统和自动化工具。这个阶段的 MCP，更像是给 AI 接上了手和资料库。

但用了一段时间之后，一个新的问题会冒出来：很多任务并不适合只用文字来完成。你可以让 AI 调一个销售数据工具，然后返回一段总结；可如果用户想筛选地区、拖动时间范围、比较不同指标，继续用聊天一问一答就很别扭。于是 MCP Apps 作为 MCP 的扩展形态出现：它不是只让工具返回文本或结构化数据，而是允许工具声明一个 ui:// 资源，把交互式 HTML 界面直接渲染在 AI 客户端里。

换句话说，MCP Apps 的起源不是“给 AI 做一个应用商店”这么宏大的口号，而是一个很具体的产品痛点：当 AI 开始处理复杂任务时，纯文本界面不够用了。

按官方定义，MCP（Model Context Protocol，模型上下文协议）是一个让 AI 应用连接外部系统的开放标准。过去我们更熟悉的是 MCP server 暴露工具、资源和提示词，让 Claude、ChatGPT、VS Code、Cursor 之类的客户端能读文件、查数据库、调用搜索、跑自动化流程。

但 MCP Apps 往前多走了一步：工具不再只是返回一段文本、一个 JSON 或一张图片，而是可以返回一个直接嵌在 AI 对话里的交互式 HTML 界面。

这听起来像一个小功能，其实很可能是软件入口变化的早期信号。

从“调用工具”到“打开应用”

过去一年，很多人理解 MCP 的方式都比较工程化：它像 AI 世界里的 USB-C 接口。一个 AI 客户端只要支持 MCP，就可以接各种外部能力；一个服务只要实现 MCP，就有机会被不同 AI 客户端调用。

这个比喻很准确，但它只解释了“连接”。

MCP Apps 关心的是连接之后的另一个问题：如果用户不只是想让 AI 帮他查一下数据，而是想真的操作一块复杂数据、调整参数、审批事项、查看仪表盘、预览 PDF、旋转 3D 模型，难道还要继续靠一来一回的聊天吗？

官方文档给的答案很直接：文字回复有边界。有些任务需要用户和数据互动，而不是只读一段总结。

例如你问：“帮我看看各地区销售额。”普通工具可以返回一段文字：华东增长 12%，华南下降 4%。但如果它是 MCP App，就可以在对话里直接渲染一张交互式地图，你可以点某个地区继续下钻，切换指标，查看趋势。整个过程仍然留在原来的 AI 对话中，不需要跳到一个外部网页。

这就是关键差异。

以前 AI 调工具，像是在后台帮你跑命令；MCP Apps 更像是在 AI 客户端里打开了一个小应用。

为什么不是直接发一个网页链接？

看到这里，很容易反问：这不就是 web app 吗？为什么不让 AI 直接给我一个链接？

官方文档列了几个理由，我觉得最重要的是三个。

第一个是上下文不丢。

独立网页最大的问题不是技术复杂，而是它会切断上下文。你从聊天窗口跳到浏览器标签页，再回来继续问 AI，AI 未必知道你刚才点了哪里、筛了什么条件、改了什么参数。MCP App 嵌在对话里，界面和产生它的讨论在同一个地方，用户不需要在“聊天”和“软件”之间来回搬运状态。

第二个是双向数据流（bidirectional data flow，双向数据流）。

独立网页通常要自己做 API、鉴权、状态管理和刷新逻辑。MCP App 则可以复用 MCP server 已经暴露的工具能力。界面里的按钮可以请求 host 去调用工具，host 也可以把新的结果推回界面。用户不是在看一张静态报表，而是在对话里操作一个仍然能和后端能力互动的小系统。

第三个是权限和安全。

MCP Apps 通常运行在 host 控制的 sandboxed iframe（沙箱 iframe）里。它不能随便访问父页面，不能偷读 host 的 cookie 或 local storage，也不能越过容器直接碰用户数据。它与 host 的通信走 postMessage，并由 host 决定它能请求哪些能力。

这点很重要。因为如果 AI 客户端真的变成软件入口，它面对的不是“能不能渲染 UI”这个问题，而是“我凭什么信任一个第三方界面可以出现在我的 AI 工作台里”。沙箱、权限、CSP、工具调用代理，这些听起来很底层的东西，最后都会变成用户是否敢用的产品问题。

App Store 的旧逻辑不一定会重演

所以 MCP Apps 会成为 AI 时代的 App Store 吗？

我更愿意换一种说法：它可能会把 App Store 的一部分功能拆散，重新长在 AI 客户端里。

传统 App Store 至少承担三件事：发现应用、安装应用、建立信任。用户在商店里搜索、看评分、点安装，然后授权通知、相册、定位、麦克风等权限。

AI 客户端里的应用入口不会完全照搬这套流程。

在 AI 场景里，用户很多时候不是先想“我要安装一个应用”，而是先提出一个目标：帮我分析这份表格，帮我规划预算，帮我审批报销，帮我看这个设计稿，帮我监控服务器状态。AI 再决定要不要调用某个工具、渲染某个界面、请求某个权限。

这会让“发现机制”（discovery）变得更隐形。

手机时代的发现，是你主动逛商店；AI 时代的发现，可能是客户端在理解任务时把合适的 App 推到你面前。你不是搜索“预算分配器”，而是说“帮我把下季度预算按部门和风险重新分配一下”，然后一个预算建模界面出现在对话里。

这对开发者也意味着变化。

以前做软件，要争桌面图标、浏览器书签、手机首页、App Store 排名。以后某些软件可能要争的是：当用户在 AI 客户端里提出某类任务时，你的 MCP server 和 MCP App 能不能被发现、能不能被信任、能不能给出比纯文本更好的交互体验。

这不是简单的“上架应用商店”，更像是把应用能力封装成 AI 能理解、能调用、能展示、能授权的组件。

哪些产品会最先适合 MCP Apps？

并不是所有软件都需要变成 MCP App。

如果一个产品本来就是完整网站，用户需要长时间沉浸使用，比如 Figma、Notion、飞书、GitHub，它未必应该整个搬进 AI 对话框里。AI 客户端的空间有限，聊天流也不是万能容器。

但有几类产品会很适合。

第一类是复杂数据探索。销售报表、用户分群、日志分析、财务模型、实验结果，这些东西用文字讲很累，用图表和交互控件会自然得多。AI 可以负责解释和提出下一步问题，MCP App 负责让用户看见结构、筛选数据、验证判断。

第二类是多选项配置。部署一个服务、设置自动化规则、创建营销活动、配置权限策略，如果全靠聊天逐项追问，体验会很差。一个带默认值、校验和依赖关系的表单，反而更适合人做最后决策。

第三类是审批和复核流程。报销、代码变更、内容发布、客服工单，这些任务都有“看材料、做判断、点动作”的节奏。AI 可以先整理上下文，MCP App 则提供按钮、对比视图和状态流转。

第四类是富媒体预览。PDF、图片、视频、3D 模型、乐谱、地图，这些内容如果被压缩成文字说明，会损失太多。MCP Apps 的价值不在于“让 AI 会说”，而在于让 AI 客户端可以直接承载适合人类感知的界面。

这些场景有一个共同点：它们都不是纯自动化，也不是纯聊天，而是人、AI 和界面共同完成判断。

真正的难题：谁来管权限、入口和分成？

如果 MCP Apps 继续发展，最麻烦的部分可能不是技术实现。

HTML、iframe、postMessage、JSON-RPC，这些都有成熟路径。真正难的是平台规则。

比如，一个 MCP App 想帮你安排会议。它自己不一定直接接 Google Calendar、Outlook、飞书日历，而是请求 host 通过用户已经连接的能力去完成“安排会议”这个目标。这样做的好处是开发者不用为每个日历服务重复写集成；坏处是用户必须清楚知道：到底是谁在请求权限？谁执行了动作？失败或误操作算谁的责任？

再比如，发现机制由谁控制？

如果 Claude、ChatGPT、VS Code、Microsoft 365 Copilot 都支持 MCP Apps，它们会不会各自形成自己的推荐规则、审核规则、权限弹窗和默认排序？开发者是“写一次，到处运行”，还是最后又要适配一堆平台差异？

还有商业化。

传统 App Store 有明确的支付和抽成模型。MCP Apps 如果嵌在 AI 客户端里，付费对象可能变复杂：用户付给 AI 客户端订阅费，企业付给 SaaS 服务费，MCP App 开发者可能还要按工具调用、数据源、席位或结果收费。谁掌握入口，谁就有机会掌握这笔账本。

所以，MCP Apps 的故事如果继续往下走，一定不只是开发者工具故事。它会碰到平台、生态、审核、分发和商业模式。

对开发者来说，机会在哪里？

如果你是独立开发者或小团队，我不建议现在就把它理解成“赶紧做一个 MCP 应用商店”。这个判断太早了。

更现实的机会，是从你已经熟悉的垂直工作流里找一个“聊天不够用、完整网页又太重”的环节。

比如：

给数据库查询结果加一个可交互分析面板；
给日志排障做一个时间线和过滤器；
给内容发布做一个审核、预览、确认界面；
给企业知识库做一个引用可追踪的答案卡片；
给自动化流程做一个参数配置和运行状态面板。

这些东西单独做成 SaaS，可能太小；只做成 MCP tool，又太难用。MCP App 正好卡在中间：它不是完整产品，但也不只是一个函数调用。

这也是它最像“下一代软件组件”的地方。

以前我们把软件能力封装成 API，给程序调用；后来封装成插件，给 IDE 或浏览器调用；现在可能要封装成 MCP server 加 MCP App，给 AI 客户端调用，也给人类在对话中操作。

它不会取代 App，但会吃掉一部分入口

我不认为 MCP Apps 会让传统 App 消失。

手机、浏览器、桌面软件仍然会存在。很多复杂创作、长时间协作、高频操作，仍然需要完整应用形态。把所有东西塞进聊天框，只会制造新的混乱。

但有一部分软件入口会被吃掉：那些用户本来就不是为了“打开某个软件”，而是为了完成一个任务的场景。

当用户说“帮我看一下这组数据”“帮我审批这批工单”“帮我整理这个项目风险”“帮我生成一个可调整的预算方案”时，他不一定关心背后打开的是哪个应用。他关心的是：AI 是否理解目标，界面是否足够好操作，权限是否清楚，结果是否能继续推进。

这就是 MCP Apps 和 App Store 之间的真实关系。

App Store 解决的是“我想找一个应用”。MCP Apps 更可能解决的是“我在一个 AI 工作流里，需要一个刚好够用的界面”。

前者以应用为中心，后者以任务为中心。

如果说 MCP 是 AI 连接外部世界的接口，那么 MCP Apps 就是在这个接口上补了一层人能操作的表面。Agent 负责理解目标和调度能力，MCP server 负责暴露工具和数据，MCP App 负责把复杂状态变成用户能看、能点、能确认的界面。

这三者的边界越清楚，AI 客户端就越不像一个聊天框，而越像一个工作台。

真正的变化也在这里：下一代软件入口未必是一个新的商店图标，而可能是一次对话里突然出现的那块交互界面。

参考来源

以上来源主要用于确认 MCP 与 MCP Apps 的公开定义、能力边界和客户端支持情况；对“AI 时代 App Store”这一判断，属于基于公开文档和产品趋势的分析，不等同于官方路线图。

软件生态 on 奇诺分享 | 重在分享