从工具调用到 AI “浏览器”：MCP 的协议演进与软件交互重构
我越来越倾向于把 MCP 看作 AI 时代软件基础设施的一条关键线索。它表面上是一个协议，解决的是 AI 应用如何连接外部工具和数据源；但继续往后看，它牵出的其实是一个更大的问题：当 AI 不再只是回答文本，而是能够调用工具、渲染组件、承接操作、写回业务系统时，软件的入口形态会不会被重新定义？
过去的软件交互大多是 App-first。用户先打开某个应用，再在应用内部寻找功能。想订酒店，就打开旅行 App；想做图，就打开设计工具；想查客户，就打开 CRM；想排任务，就打开项目管理软件。
AI 正在把这条路径改成 Intent-first。用户先表达意图，AI 再判断需要调用哪些服务、读取哪些数据、展示哪些组件、在哪一步要求用户确认。这个变化不是突然发生的，它背后需要一整套协议、运行时、UI、安全和分发机制。MCP 的演进，正好可以串起这条路径。
从接口调用到协议化连接
MCP 最初要解决的不是“Agent 能不能调接口”。Agent 当然可以直接调接口。一个开发者完全可以在 Agent 后端写 GitHub API 封装、Slack API 封装、Jira API 封装、Postgres 查询封装、CRM 接口封装。只要业务边界足够小，这种方式甚至是最直接的。
真正的问题出现在规模化之后。假设有五个 AI 应用：Claude、Cursor、企业内部助手、IDE Agent、客服 Agent；又有八个外部系统：GitHub、Slack、Jira、Notion、Postgres、CRM、文件系统和数据仓库。如果每个 AI 应用都自己接每个系统，就会出现大量重复集成。每多一个应用，工具就要重新适配；每多一个工具，所有应用又要重新接入。
这就是 MCP 的出发点。Anthropic 在 2024 年 11 月发布 MCP 时，把它定义为一个开放标准，用来在数据源和 AI-powered tools 之间建立安全的双向连接；开发者既可以通过 MCP Server 暴露数据，也可以构建 MCP Client 去连接这些 Server。Anthropic 当时也明确说，MCP 要替代碎片化集成，用单一协议连接 AI 系统和数据源。
官方文档后来用了一个很形象的说法：MCP 就像 AI 应用的 USB-C 接口。USB-C 统一了电子设备的连接方式，MCP 试图统一 AI 应用连接外部系统的方式。通过 MCP，Claude、ChatGPT 这类 AI 应用可以连接本地文件、数据库、搜索工具、计算器、工作流和专门的提示词能力。
直接调接口时，工具逻辑通常绑定在某个 Agent 应用内部。这个 Agent 知道 GitHub 怎么鉴权、Slack 怎么发消息、Jira 怎么建工单、数据库怎么查表。换一个 Agent 应用，这些封装很可能要重写一遍。
MCP 的思路是：工具提供方或企业内部系统实现一个 MCP Server，AI 应用实现 MCP Client。AI 应用不需要分别理解 GitHub、Slack、Postgres、CRM 的所有原生接口细节，而是通过 MCP 的标准方式发现工具、读取工具描述、传入参数并拿到结果。
这里需要区分 MCP 和 function calling。Function calling 解决的是模型如何选择函数、如何生成 JSON 参数、如何把工具结果送回模型。MCP 解决的是更外层的问题：这些函数从哪里来，如何被发现，如何被不同 AI 应用复用，如何连接本地或远程系统，如何暴露工具、资源和提示词。
很多时候，模型通过 function calling 决定要调用某个工具，而 Host 或 Client 再通过 MCP 去真正执行这个工具。Function calling 更像模型层的调用格式，MCP 更像应用层和工具层之间的连接协议。
所以，MCP 的价值不是让 Agent 第一次能够调接口，而是把“调接口”这件事从单个 Agent 的私有能力，升级为整个 AI 生态可复用、可发现、可治理、可扩展的标准协议。
有状态连接为什么自然
MCP 的基础结构可以理解为 Host、Client、Server 三层。
Host 是 AI 应用本身，比如 Claude Desktop、Cursor、IDE 或企业内部 Agent。Client 是 Host 内部负责连接某个 MCP Server 的组件。Server 则是暴露工具、资源和提示词的服务。MCP 2025-06-18 架构规范明确描述了这种 client-host-server architecture，并指出一个 host 可以运行多个 client 实例，用于连接不同 server，同时维持清晰的安全边界和关注点隔离。
例如 Claude Desktop 连接一个本地 filesystem MCP Server。用户提出“总结这个项目里的 README 和源码结构”这样的任务后，模型判断需要读取文件，MCP Client 向 filesystem MCP Server 获取可用工具，模型选择读取文件或列目录的工具，Server 执行文件系统操作，再把结果返回给模型。
这里的关键不在于“读文件”这个动作有多复杂，而在于这个动作被协议化了。AI 应用不直接拿到底层文件系统的所有能力，而是通过 MCP Server 暴露出来的工具边界访问外部系统。
早期 MCP 很适合本地场景。Claude Desktop 启动一个本地 MCP Server，通过 stdio 和它通信。这个 Server 可以访问本地文件、Git 仓库、SQLite、浏览器或命令行工具。在这种模式下，有状态连接非常自然。应用启动服务，双方建立连接，之后在这条连接里进行初始化、能力协商、工具列表获取、资源读取、进度通知和工具调用。
这种模式很像 IDE 和语言服务器之间的关系。LSP 标准化了开发工具接入编程语言的方式，MCP 则标准化 AI 应用接入上下文和工具的方式。MCP 架构规范也明确说，MCP 建立在 JSON-RPC 之上，并在当时提供的是 stateful session protocol，重点是 client 和 server 之间的上下文交换。
在本地环境里，有状态不是问题，反而很方便。连接通常稳定，Client 和 Server 往往在同一台机器或同一个受控环境里，session 的生命周期很清晰。真正的问题，是 MCP 走向远程之后才出现的。
从远程化到无状态核心
当 MCP Server 不再是本地进程，而是一个远程服务时，架构开始变化。前面可能有 API Gateway、反向代理、负载均衡器，后面可能有多个 MCP Server 实例。请求不一定每次都落到同一台机器上，连接也不一定长期稳定。
早期远程 MCP 使用 HTTP+SSE。简单理解，客户端通过一个 HTTP POST endpoint 给服务端发消息，再通过另一个 SSE endpoint 接收服务端推送。请求和响应被拆到了两条通道里。
这个设计可以工作，但不像标准 HTTP API 那么自然。旧方案像是在餐厅里用一个窗口点餐，再去另一个窗口等叫号。两个窗口还要互相知道同一个顾客是谁、刚才点了什么、后续要把结果发到哪里。如果只是本地小店，这没什么；如果这个餐厅要接统一收银、排队系统、会员系统、监控系统和门店调度，这种双窗口模式就会变得别扭。
技术上也是一样。HTTP+SSE 需要维护两个 endpoint，需要长期 SSE 连接，请求和服务端消息走不同通道，鉴权、日志、限流、CORS 和连接恢复都更复杂。
所以 2025 年 3 月，MCP 引入了 Streamable HTTP。2025-03-26 规范明确说，Streamable HTTP 替代了 2024-11-05 版本中的 HTTP+SSE transport。新的传输方式要求服务端提供一个单一 MCP endpoint，客户端通过 HTTP POST 发送 JSON-RPC 消息，服务端既可以直接返回 JSON，也可以在需要时用 SSE 流式返回多个消息。
这一步解决的是传输层问题，而不是协议状态问题。旧模式像是两个窗口：一个点餐，一个取餐。Streamable HTTP 像是一个统一窗口：如果结果已经准备好，直接返回；如果需要等待，就在同一个 HTTP 响应里持续推送进度和结果。
这让远程 MCP 更容易接入 API Gateway、反向代理、负载均衡、云函数、Kubernetes Ingress 和企业内部网关。2025-03-26 的 key changes 也把 Streamable HTTP、OAuth 2.1 授权框架、JSON-RPC batching、工具注解列为主要更新，说明 MCP 开始从本地工具协议走向远程服务协议。
但 Streamable HTTP 还没有解决 MCP 的根本状态问题。它只是让“消息怎么传”更标准，而不是让“协议本身”变成无状态。2025-03-26 规范里的生命周期仍然要求 client 和 server 在初始化阶段完成协议版本、capability 和实现信息的协商；Streamable HTTP 的 session management 也仍然允许 server 在初始化时返回 Mcp-Session-Id，后续请求继续携带这个 session id。
这就像餐厅已经把点餐窗口和取餐窗口合并了，但餐厅仍然要求顾客先办一张临时会员卡，之后每次点餐都带着这张卡，餐厅内部还要记住这张卡对应的状态。
对本地应用来说，这没什么。对云原生服务来说，这就是瓶颈。
有状态 session 在远程部署里会带来明显负担。如果第一次请求落到 Server A，Server A 记住了这个 session；第二次请求被负载均衡打到 Server B，而 Server B 不知道前面的 session，请求就可能失败。为了解决这个问题，要么做 sticky session，让同一个客户端的请求尽量回到同一个实例；要么做共享 session store，让所有实例都能读取同一份 session 状态；要么让网关理解更多协议细节，做更复杂的路由。
这和现代云服务的设计习惯是冲突的。现代 HTTP 服务更喜欢每个请求自包含，任意实例都能处理，实例可以随时扩缩容，失败后可以重试，状态放到数据库、缓存、token、task id 或业务 handle 里，而不是隐藏在某条连接或某个 server instance 的内存里。
因此，MCP 后来的关键判断变成：Agent 应用当然可以有状态，但 MCP 协议核心不应该强制有状态。状态应该从连接和 session 里抽出来，变成显式的业务对象。
截至 2026 年 5 月 27 日，MCP 官方已经发布 2026-07-28 规范的 Release Candidate。官方博客称这是 MCP 自发布以来最大的一次修订，核心变化包括 stateless core、Extensions、Tasks、MCP Apps、授权强化和正式弃用策略。其中最关键的一点是：MCP 在协议层变成无状态，并且可以运行在普通 HTTP 基础设施之上。
无状态核心并不是说 MCP Server 不能保存任何业务状态，也不是说不能有长任务、购物车、浏览器会话或数据库连接。它真正改变的是：协议层不再隐式维护 session。
旧模式是先 initialize，服务端返回 Mcp-Session-Id，后续请求带着这个 session id，服务端根据 session 找上下文。新的 RC 移除了 Mcp-Session-Id 和协议级 session，使任意 MCP 请求都可以落到任意 server instance，不再需要在协议层依赖 sticky routing 或共享 session store。
这个变化可以用购物车例子理解。有状态协议里，客户端建立 session，服务端在 session 里记住当前购物车。模型调用“加入苹果”，服务端因为记得这个 session，所以知道要把苹果加到哪个购物车里。问题是，这个购物车状态可能藏在某个服务实例里，换一个实例就不知道了。
无状态核心下，模型先调用创建购物车，服务端返回 basket_id。后续模型调用添加商品时，显式带上 basket_id。服务端根据 basket_id 去数据库或缓存里找到购物车。状态仍然存在，但它不再隐式依赖协议 session，而是变成了业务层的显式对象。
长任务也是同样的思路。以前长任务可能依赖持续 session。现在更合理的方式是工具调用返回 task_id，客户端后续用 task_id 查询进度、取消任务或获取结果。2026-07-28 RC 中，Tasks 被放入 extension 体系，用显式任务句柄来支持长时间工作。
服务端主动请求也发生了类似变化。旧模式下，服务端可以在连接中途询问客户端是否确认某个操作，然后保持连接等待回答。无状态设计下，服务端更倾向于返回 input required 的结果，里面包含需要用户补充的信息和 requestState。客户端收集用户回答后，再带着回答和 requestState 发起下一次请求。这样任意 server instance 都可以继续处理，因为继续执行所需的状态已经显式出现在请求里。
这一步非常关键。MCP 不再只是本地 AI 工具插件协议，也不只是 Agent 调工具的一种格式。它正在变成企业 Agent 系统里的工具连接层。企业真正关心的不只是 MCP 能不能跑 demo，而是 MCP Server 能不能像普通后端服务一样接 API Gateway、做负载均衡、多租户隔离、权限控制、审计、缓存、链路追踪、灰度发布和弹性扩缩容。
无状态核心之后，MCP Server 更容易变成普通云服务：多个无状态实例，前面挂普通负载均衡器，状态进入数据库、Redis 或对象存储，长任务用 task_id 管理，权限用 OAuth 或 OIDC 管理，追踪用标准 trace context，工具列表可以缓存。
这就是 MCP 从“工具协议”走向“云原生 Agent 基础设施”的关键一步。
从工具返回到界面返回
如果说无状态核心解决的是 MCP Server 如何在企业基础设施里稳定运行，那么 MCP Apps 解决的是另一个问题：工具调用的结果不应该永远只是文本或 JSON，它也可以是一段可交互的界面。
这会把 MCP 的意义往前推一层。它不再只是“模型调用工具，工具返回数据”，而是“模型调用工具，工具返回数据和界面，用户直接在对话中继续操作”。
MCP Apps 在 2026 年 1 月成为官方 MCP 扩展。官方博客说，MCP Apps 让工具可以返回直接渲染在对话里的交互式 UI 组件，例如 dashboards、forms、visualizations、multi-step workflows 等；当工具声明 UI resource 时，host 会在 sandboxed iframe 中渲染它，用户可以直接在对话中与组件交互。
这个变化非常重要，因为它把 AI 对话从“文本交互”推进到了“任务界面”。
传统工具调用的返回结果可能是：“找到了 10 家酒店，下面是列表。”用户如果要筛选、排序、看地图、比较房型、确认预订，通常还是要跳回应用。
MCP Apps 或类似机制出现后，工具可以直接返回一个酒店筛选组件：里面有地图、价格滑块、房型卡片、取消政策、评分、距离、确认按钮。用户不需要离开对话，就可以继续筛选、修改和确认。
OpenAI 的 ChatGPT Apps 也沿着同一方向发展。OpenAI 在 2025 年发布 ChatGPT Apps 和 Apps SDK 时说明，Apps 可以在 ChatGPT 对话中被自然发现，既可以由用户点名调用，也可以在合适上下文中由 ChatGPT 推荐；这些应用响应自然语言，并且包含可以直接在聊天中使用的交互式界面。
OpenAI 的开发者文档进一步说明，UI components 会把 MCP Server 的结构化工具结果转成面向人的界面，这些组件运行在 ChatGPT 的 iframe 中，通过 MCP Apps bridge 与 host 通信，并内嵌在对话里渲染；这一套 UI 架构最初服务于 ChatGPT Apps，后来被标准化为 MCP Apps，使开发者可以 build once and run across MCP Apps-compatible hosts。
这意味着 MCP 的边界正在扩张。
最初的 MCP 解决的是工具连接：AI 应用如何访问文件、数据库、代码仓库和业务系统。
后来的 MCP 解决的是远程部署：MCP Server 如何像标准 HTTP 服务一样运行。
现在的 MCP Apps 进一步解决的是交互承接：当工具返回结果后，用户如何在 AI 对话里直接看、改、筛选、确认、提交。
这会把传统应用的一部分界面拆出来，变成 AI 可调用、可渲染、可交互的组件。
AI 应用会成为新的软件入口
我认为未来的软件入口会发生一次明显迁移：大量轻量任务和跨应用任务，会从“打开 App”转向“表达意图”。AI 应用会理解任务，选择工具，调用服务，渲染组件，要求用户确认，并把结果写回业务系统。
过去二十年的主流交互范式是 App-first。用户想订酒店，就打开 Booking 或携程；想做图，就打开 Canva 或 Figma；想查房子，就打开 Zillow 或贝壳；想听歌，就打开 Spotify 或网易云。用户先选择应用，再在应用内部完成任务。
AI 时代的交互范式会逐渐变成 Intent-first。用户不一定先想“我要打开哪个 App”，而是直接表达意图：规划东京三天旅行、把产品方案做成一页海报、根据会议纪要生成任务、筛选适合家庭出游的酒店、查找通勤三十分钟以内的房子。
在这种模式下，用户先说意图，AI 再判断应该调用哪个服务、拿哪些数据、渲染什么界面、在哪一步要求确认。
AI 应用会越来越像浏览器，但它渲染的不再只是网页，而是意图驱动的工具组件。
传统浏览器的基本流程是：用户输入网址或搜索关键词，浏览器打开网页，用户在网页里操作。AI 浏览器式入口的流程则是：用户表达任务，AI 选择合适的工具或 MCP Server，工具返回数据和 UI 组件，AI 在对话中渲染组件，用户直接确认、编辑、筛选、提交。
OpenAI 的 Apps SDK 文档已经把这个结构描述得很清楚：UI components 是 connector 中用户可见的一半，能让用户在 ChatGPT 内部直接查看或编辑数据，也能在需要时切到全屏，并保持输入提示和 UI 操作之间的上下文同步。
这其实就是“AI 应用作为浏览器”的雏形。
只不过浏览器时代的核心对象是 URL 和网页，AI 时代的核心对象会变成用户意图、工具能力、上下文、权限、组件和动作结果。
因此，未来一个应用可能不再只需要做 Web 页面、移动端页面、小程序页面，还需要做 AI 可理解的工具描述、AI 可调用的 MCP Server、AI 可渲染的交互组件、AI 可判断何时推荐的 metadata、AI 可安全执行的权限边界。
这会把前端开发、API 设计、搜索优化、应用分发重新搅在一起。
传统 App 是一个完整目的地。用户打开它，看到首页、导航、菜单、搜索框、筛选器、详情页、下单页、个人中心。但在 AI 入口里，用户并不一定需要看到完整 App。用户只需要在当前任务中用到的那一小块能力。
旅行平台不一定展示完整首页，而是展示酒店候选卡片、地图、价格筛选和预订确认。设计工具不一定展示完整工作台，而是展示海报预览、文案编辑、风格切换和导出按钮。项目管理工具不一定展示完整看板，而是展示从会议纪要抽取出的任务列表、负责人、截止时间和确认创建按钮。电商平台不一定展示完整商城，而是展示候选商品对比组件、评价摘要、配送时间和购买确认。
这意味着应用会被拆成很多可被 AI 编排的小模块。每个模块背后可能对应一个 MCP tool、一个 UI resource、一个业务 API、一个权限范围和一个审计记录。
但是，这不会消灭所有传统 App。更可能出现分层。
轻量任务最容易被 AI 对话入口吞掉。比如查信息、生成初稿、订简单行程、创建任务、查订单、改地址、做简单图表、筛选商品、总结数据。这些任务原来需要打开 App，现在可以在 AI 对话里完成。
跨应用任务也会强烈迁移到 AI 入口。比如根据邮件内容创建项目任务，再给团队发 Slack，总结到 Notion，并安排日程。这种任务天然不是单个 App 能完成的，AI 反而更适合做总入口。MCP 的价值也正在这里：把不同系统暴露成可组合工具。
但深度专业工作仍然需要完整应用。专业设计师长期使用 Figma，程序员长期使用 IDE，分析师长期使用 BI 平台，财务人员长期使用 ERP，剪辑师长期使用 Premiere。原因很简单：这些场景需要高密度信息、复杂快捷键、精细控制、长期项目状态、多人协作和专业工作流。AI 可以嵌入其中，或者从外部调用其中某些能力，但不太可能把完整专业界面全部压缩进聊天框。
所以未来不是“AI 替代所有 App”，而是形成一种新关系：AI 对话入口负责意图理解、跨工具编排和轻量交互；专业 App 负责深度工作、复杂编辑和高密度状态管理；MCP Server、MCP Apps、Apps SDK 和 API 层负责把专业 App 的部分能力暴露给 AI；AI 渲染组件负责把关键操作嵌入当前对话。
从 SEO 到 Agent Optimization
一旦 AI 应用成为新的入口，就一定会出现新的分发竞争。
搜索时代有 SEO，因为 Google 决定用户先看到哪个网页。移动时代有 ASO，因为 App Store 决定用户先看到哪个应用。短视频时代有推荐算法优化，因为平台决定哪个视频被分发。AI 入口时代，也会出现某种形式的 Agent Optimization：应用厂商会优化自己被 AI 选择、调用和展示的概率。
这不是简单类比。OpenAI 在 2025 年 12 月宣布开发者可以提交 ChatGPT Apps 时，明确强调优秀的 ChatGPT app 应该围绕真实用户意图设计，能够把 context 和 action 直接带进 ChatGPT；最强的应用要么完成从对话开始的真实工作流，要么提供完全 AI-native 的体验。
这说明未来的“AI 应用曝光”不会只取决于品牌大小，也会取决于工具是否好用、metadata 是否清晰、schema 是否合理、组件是否能承接任务、权限是否可信、错误是否可恢复、调用成功率是否高。
所谓 Agent Optimization，不是传统 SEO 那种堆关键词，而是更偏工程、产品和安全的综合优化。
工具描述是否让模型准确理解适用场景，参数 schema 是否清晰，模型是否容易正确调用，返回结果是否结构化，是否方便模型继续推理，UI 组件是否能承接用户的下一步操作，授权流程是否顺滑，失败时是否有可恢复路径，是否支持多轮上下文，是否能在不打断对话的情况下完成关键动作，是否被平台判定为安全、可靠、低误导，这些都会成为新的优化对象。
OpenAI 的 Apps SDK 把状态管理分为 business data、UI state 和 cross-session state：权威业务数据由 MCP Server 或后端服务持有，临时 UI 状态由当前 widget 持有，跨会话持久状态由后端或存储管理。这个划分说明，AI 内嵌组件不是随便画一个界面，而是要认真处理状态归属、生命周期和跨 host 可移植性。
这也意味着未来应用厂商要优化的不只是用户体验，还包括 AI 平台信任。一个 MCP App 想被更多 AI host 展示，不仅要好看，还要安全、可审计、可治理、可恢复。
这里会出现一些新岗位或新能力：面向 Agent 的产品设计、工具 schema 设计、AI 组件体验设计、MCP Server 产品化、Agent 分发优化、AI 平台合规运营。它们既不是传统 SEO，也不是传统前端，而是围绕“模型如何理解、选择、调用、展示一个应用”展开的新增长体系。
更深一层，软件 UI 会从静态入口变成动态任务界面。
传统 App 的 UI 是产品团队提前设计好的。首页长什么样，导航在哪里，按钮怎么摆，用户路径是什么，大多是固定的。AI 入口里的 UI 可能变得更动态。同一个酒店服务，在商务出差、情侣旅行、家庭出游、长期居住这些不同意图下，应该渲染不同组件。商务出差用户关心离会场距离、发票、取消政策、早餐和交通时间；情侣旅行用户关心景观、氛围、评分、房型图片和附近餐厅；家庭出游用户关心儿童政策、床型、厨房、洗衣机和安全评价。
同一个工具，可能根据用户任务动态选择组件形态：表单、地图、卡片、对比表、时间线、图表、审批流。
但这里有一个重要边界：AI 不应该随意生成所有关键业务 UI。对于支付、医疗、金融、法律、企业审批等高风险场景，组件应该来自受信任的应用方，并在沙箱、权限、审计和确认机制下运行。低风险 UI 可以由 AI 动态生成，比如草稿、摘要、临时表格和可视化；高风险 UI 更应该由应用方提供标准组件，AI 负责选择、填充上下文和解释，最终操作仍由用户确认。
结语
把 MCP 的协议演进和 AI 新交互放在一起看，会发现它们其实是同一条线上的两个阶段。
前半段，MCP 解决工具接入标准化。AI 应用不再为每个系统单独写私有集成，而是通过 MCP Server 连接外部工具和数据源。
中间阶段，MCP 解决远程化。HTTP+SSE 的双通道模式比较别扭，于是 Streamable HTTP 把远程通信统一成更标准的 HTTP endpoint。
再往后，MCP 解决云原生部署。有状态 session 会给负载均衡、扩缩容、网关治理和故障恢复带来负担，于是 MCP 核心开始转向无状态，把状态显式化为 task_id、browser_id、basket_id、requestState 等业务 handle。
最后，MCP 开始解决交互承接。工具不再只是返回文本或 JSON，而是可以返回可交互 UI 组件，让用户在 AI 对话中直接筛选、编辑、确认、提交。
这四步连起来，MCP 就不只是工具协议了。它正在成为 AI 时代的软件连接和交互协议之一。
未来的用户交互会越来越多地从“打开某个应用”变成“表达一个任务”。AI 应用会理解任务，选择工具，调用服务，渲染组件，要求用户确认，并把结果写回业务系统。传统应用不会消失，但会被拆出大量 AI 可调用、可渲染、可交易的能力片段。
这很像浏览器重塑网站，移动系统重塑 App，小程序重塑服务入口。现在轮到 AI 重塑软件入口。
不过，AI 入口不会一口吃掉所有东西。轻量任务、跨应用任务、中间步骤会大量迁移到 AI 对话；深度专业工作、复杂创作、长期项目状态仍然需要完整应用。未来不是“AI 替代应用”，而是“AI 成为新的意图入口，应用变成能力网络”。
对开发者和企业来说，这意味着软件建设的重点会发生变化。
过去要做 Web App、Mobile App、API、Webhook、SDK 和文档。未来还要做 MCP Server、AI 可理解的工具描述、结构化返回、可嵌入 UI 组件、权限和审计边界、状态管理策略、Agent 调用体验、平台提交和分发优化。
过去产品要问：用户为什么打开这个应用？
未来还要问：AI 为什么在这个任务里选择这个应用？
过去增长团队关心：Google 上排名第几，App Store 里排名第几。
未来还会关心：当用户说“订酒店”“做海报”“找房子”“创建任务”时，AI 会不会调用这个服务，展示这个组件，并让用户在这个能力里完成动作。
这就是 MCP、MCP Apps、ChatGPT Apps SDK 这些变化背后的长期含义。它们不是单纯的协议更新，而是在为一个新的软件入口做基础设施准备。
MCP 的价值也因此变得更清晰：它不只是让 Agent 能调接口，而是把工具、数据、界面、状态、权限、交互逐步组织成 AI 可以理解、调用、渲染和治理的标准层。
一句话总结：MCP 的前半场，是把工具调用从私有封装变成标准协议；MCP 的后半场，则可能把应用软件从独立目的地，重构成 AI 入口下可组合、可渲染、可分发的能力网络。