即刻App年轻人的同好社区
下载
The Information这篇对OpenAI问题的独家，印证了我之前发过的「主动性」问题（m.okjike.com）和「ChatGPT本身才是最大的AI应用，是下一代Agentic Web浏览器」（m.okjike.com）。ChatGPT的聊天界面本质上是一种新的浏览器渲染引擎，既超越了现有引擎中人为设计的外链/布局规则，也集成MCP这样的新标准（相当于在URL和HTML外面加一层抽象）
使用ChatGPT过程的实质，不是在「聊天」，也不止是在「搜索」，而是在「上网」。当前这个界面太围绕文本（很多人津津乐道的「LUI」），相当于Agentic OS的「DOS时代」，OpenAI要让更多用户不把ChatGPT当成一个普通聊天对象来说，必然需要让这个界面进一步发挥出GUI的优势，进入「Windows时代」，变得更多模态、更像一个真正的「浏览器」
使用ChatGPT过程的实质，不是在「聊天」，也不止是在「搜索」，而是在「上网」。当前这个界面太围绕文本（很多人津津乐道的「LUI」），相当于Agentic OS的「DOS时代」，OpenAI要让更多用户不把ChatGPT当成一个普通聊天对象来说，必然需要让这个界面进一步发挥出GUI的优势，进入「Windows时代」，变得更多模态、更像一个真正的「浏览器」
1 00
上次说的液态玻璃材质的意义（m.okjike.com），后续爆料来了（图1），图2是我用notebooklm提取的郭明錤播客原话
关键洞察：更大屏幕有利于多模态AI——意思是折叠屏iPhone是AR设备，要透过更大屏幕看背后的现实空间环境，结合传感器（多模态交互输入）和AI，在空间中叠加软件UI和虚拟内容（增强现实的多模态交互输出）
想起我之前总结过「用手机满足AI需求」的瓶颈（图3底部），正好也包括「屏幕小」，不过当时我强调的是「屏幕小不利于真人和AI一起在本地虚拟软件界面上协作」，漏掉了「真人和AI一起在现实物理环境中协作」
手机的这些瓶颈，只有屏幕小是可以靠折叠屏来改善的，所以就像郭明錤说的，折叠屏手机确实就是从手机发展到眼镜之前手机最大和最后的进化了
关键洞察：更大屏幕有利于多模态AI——意思是折叠屏iPhone是AR设备，要透过更大屏幕看背后的现实空间环境，结合传感器（多模态交互输入）和AI，在空间中叠加软件UI和虚拟内容（增强现实的多模态交互输出）
想起我之前总结过「用手机满足AI需求」的瓶颈（图3底部），正好也包括「屏幕小」，不过当时我强调的是「屏幕小不利于真人和AI一起在本地虚拟软件界面上协作」，漏掉了「真人和AI一起在现实物理环境中协作」
手机的这些瓶颈，只有屏幕小是可以靠折叠屏来改善的，所以就像郭明錤说的，折叠屏手机确实就是从手机发展到眼镜之前手机最大和最后的进化了
1 00
ChatGPT对于这些app（web.okjike.com）还没有之前那个帖子说的「Tool Search Tool」（按需搜索发现工具）能力，只能先在应用商店里逐个连接（相当于提前安装），添加到聊天时的「工具列表」中（相当于应用库/主屏），在聊天时勾选启用这个「工具」（相当于手动open一个原生app或web，再让AI自动操作。启用前后的区别见下图：
2 30
纠正下误解：ChatGPT这个新应用商店里的app，不是GPTs，不是以前那种来自UGC/PGC的、有固定提示词或工作流编排的Agent，而是「Tool」，每个app都是一个 MCP App，本质是MCP Server with MCP-UI（HTML/CSS/JS 模版），是用 OpenAI 的 Apps SDK 开发的。具体解释见之前这个帖子：web.okjike.com
2 00
一个拖延好久懒得晒的投资成果：8月听了一场创新药大佬青侨阳光的演讲，回来后用 AI 逆向出了一堆受益于入胞技术的美股小微盘生物科技股，筛选出来建仓的9个企业里有7个都大涨了，其中4个一度翻倍，图4是最近收益回撤后其中几个最新的状态（跟我买的 XBI 对比）
4 00
阿里系垂直Agent合订本
蚂蚁似乎是Agent化最积极的，可能根本原因是：图里这些产品的「旧流量」都是「工具属性」的而不是「入口属性」的，本来就都是需要有助于你解决问题，才能获得你的留存和使用频次，工具使用过程不重要，结果才是重点。现在Agent化之后的「新流量」都是进一步直接给你解决问题， 从而进一步促进留存和频次，不怕取代「旧流量」的「使用过程」，只要最终结果更好就行
淘宝也一样，如果只考虑「工具属性」，用搜索和列表让你下单，用内容电商信息流让你下单，用直播让你下单，还是用Agent让你下单，都一样，不需要谁代偿谁，只要最终下单更多、退货率更低就行
但淘宝的「旧流量」还有「入口属性」，要靠特定的「使用过程」获得来自商家的广告收入，这部分会受到 「Agent化」的严重冲击，需要被其他收入来源代偿
因为「旧流量」中的很多广告位，本质上都是来自「低效」的，比如搜索结果列表跟Agentic AI的结果相比是低效的，正是这种低效的特定「使用过程」创造了广告需求、留出了冗余空间增加了广告库存
在Agentic AI的结果中，会有一些「相关推荐」广告位的空间，而结果本身的实现过程（自动化agentic过程）中可以加入一些实时竞价机制（前提是竞价者提供的Tool都能满足质量要求），但由于总体效率更高，广告库存肯定要减少
而如果直接面向用户为这种「高效」收费（比如ChatGPT Pro的200刀月费），代偿减少的广告库存，就转变成了上次说的 Netflix 和 XBox Game Pass 的「bundling 商业模式」，让大众用户为「娱乐」支付这种费用相对容易，让他们为「高效」直接付费就难多了
因此淘宝「Agent化」的积极性似乎比蚂蚁弱
而微信不仅同样依赖「入口属性」的「旧流量」来变现，连「工具属性」都依赖人与人互动这个特定「使用过程」，因此积极性好像更低……很多人（似乎包括腾讯自己）都认为这是「战略定力」、「审慎克制」，其实如果不需要瞻前顾后，为啥要有定力要审慎克制，像蚂蚁这样全都先挂上agent再迭代就完事了
蚂蚁似乎是Agent化最积极的，可能根本原因是：图里这些产品的「旧流量」都是「工具属性」的而不是「入口属性」的，本来就都是需要有助于你解决问题，才能获得你的留存和使用频次，工具使用过程不重要，结果才是重点。现在Agent化之后的「新流量」都是进一步直接给你解决问题， 从而进一步促进留存和频次，不怕取代「旧流量」的「使用过程」，只要最终结果更好就行
淘宝也一样，如果只考虑「工具属性」，用搜索和列表让你下单，用内容电商信息流让你下单，用直播让你下单，还是用Agent让你下单，都一样，不需要谁代偿谁，只要最终下单更多、退货率更低就行
但淘宝的「旧流量」还有「入口属性」，要靠特定的「使用过程」获得来自商家的广告收入，这部分会受到 「Agent化」的严重冲击，需要被其他收入来源代偿
因为「旧流量」中的很多广告位，本质上都是来自「低效」的，比如搜索结果列表跟Agentic AI的结果相比是低效的，正是这种低效的特定「使用过程」创造了广告需求、留出了冗余空间增加了广告库存
在Agentic AI的结果中，会有一些「相关推荐」广告位的空间，而结果本身的实现过程（自动化agentic过程）中可以加入一些实时竞价机制（前提是竞价者提供的Tool都能满足质量要求），但由于总体效率更高，广告库存肯定要减少
而如果直接面向用户为这种「高效」收费（比如ChatGPT Pro的200刀月费），代偿减少的广告库存，就转变成了上次说的 Netflix 和 XBox Game Pass 的「bundling 商业模式」，让大众用户为「娱乐」支付这种费用相对容易，让他们为「高效」直接付费就难多了
因此淘宝「Agent化」的积极性似乎比蚂蚁弱
而微信不仅同样依赖「入口属性」的「旧流量」来变现，连「工具属性」都依赖人与人互动这个特定「使用过程」，因此积极性好像更低……很多人（似乎包括腾讯自己）都认为这是「战略定力」、「审慎克制」，其实如果不需要瞻前顾后，为啥要有定力要审慎克制，像蚂蚁这样全都先挂上agent再迭代就完事了
5 14
上次写了 Agentic AI 注定让超级应用 unbundling（m.okjike.com），最近随着 OpenAI、Anthropic、Shopify 在 MCP-UI、MCP App 上的开放合作，以及由此发展出的以MCP为基础的「Agentic AI基金会」（AAIF）纳入了主要 AI Lab 和 Infra 厂商（图1。让我想起图2这个 USD/Khronos 和GLTF/W3C 强强联合的元宇宙标准基金会/MSF），下一代「Agentic OS/Web」的应用形态已经比较清晰了：
分发应用环节，会共存两类适合被通用 AI Agent 分发、可借助 「Tool Search Tool」被通用 AI Agent 自动发现的「Tool」：
1. 搜索发现「Action」（通过纯数据接口交互的 Tool） -> 发现 MCP Server -> 使用 MCP App
2. 搜索发现「UI」（通过 GUI 交互的 Tool） -> 发现 Web Page -> 使用 Web App
使用应用环节（这个使用过程也可以理解为对应用内部细粒度功能/内容的进一步分发），会共存两类适合通过（或结合）通用 AI Agent 来使用的「Install-free App」（这种应用能按需直接运行，能用完即抛无负担，不用限定于预设好的 Tool/Skill，能标准化和跨平台）：
1. 以「UI」为中心、采用「Action 嵌在 UI 里」模式的「Install-free App」——Web App
就是现有的网站、PWA。可以基于 WebMCP、PWA Actions 这类等价于原生 App Intents 的技术，在 HTML 或 Web App Manifest 这样的 UI 代码中内嵌「Action」的声明和实现（比如就是 JS 函数）
通用 AI Agent 既可以跟真人一样直接操作这些 UI，也可以精准调用 UI 代码中声明的这些 Actions
2. 以「Action」为中心，采用「UI 嵌在 Action 里」模式的「Install-free App」——MCP App
这种应用就是返回数据中包含 MCP-UI 的 MCP Server，是对「Apps in ChatGPT」和 OpenAI 「Apps SDK」的标准化（ MCP App 是 MCP 协议中的一个新标准，整合了另一个标准化项目 MCP-UI 和 ChatGPT 的 Apps）
目前已经有 ChatGPT App 之外的其他宿主应用支持 MCP-UI 和 MCP App，Block 的本地 AI Agent 开发框架 Goose 就重点支持了 MCP-UI，这次也被贡献给了 Agentic AI 基金会
其中的 MCP-UI 包含三种实现方式，都是基于 Web 技术的（后两种方式都来自 MCP-UI 项目，暂时还没有被 MCP Apps 协议纳入）：
2.1 HTML Template（含 CSS/JS）
这种 UI 模版被作为「资源」，通过 MCP Server 下发，被通用 AI Agent 预加载/注册（因此在 UI 渲染前有机会先做自动化审查），可以在通用 AI Agent 渲染自身对话界面的过程中被按需使用，在对话界面中嵌入这些第三方 UI
可以在这些 UI 代码中注入当前实时的上下文数据，甚至对 UI 代码做大幅修改，但仍然要用标准的浏览器引擎来渲染这些 UI 模版（比如注入到 iframe / WebView 里渲染），否则无法支持跨平台兼容性、无法兼容已有的开放 Web 生态（比如 OpenAI 推荐用 React、乃至开了 SSR 的 Next.js 来提供「Apps in ChatGPT」 中的 UI 模版）
这些 UI 由第三方负责实现和发布，不能由通用 AI Agent 自己随意杜撰，在很多情况下这是刚需，因为第三方产品中很多独有的用户价值需要借助这些 UI 来实现和交付，这些 UI 是产品中核心功能和「解决问题」的必要组成部分
另一方面，通用 AI Agent 这个「平台方」就像应用商店一样，对这些第三方 UI 拥有一定的掌控，用不用、如何用都由自己决定，包含隐私信息的上下文数据也都在自己内部，不提供给第三方
这种模式可以进一步跟一个新 Web 标准——IWA（Isolated Web App，特别是其中的 Web Bundles 技术）结合，这种 Web App 需要事先签名和离线打包，从而锁定代码，有资格获得更多原生权限。MCP Server 下发的「HTML 模版」可以换成 Web Bundles，变成整套 Web App 实现，而不仅限于单一网页
2.2 External URL
就是在 MCP Server 返回的数据里，直接提供服务器端现成的 Web Page、Web App 的 URL
通用 AI Agent 只能直接使用这些 URL（比如在 iframe / WebView 里加载），如果 UI 中要包含当前实时的上下文数据，只能通过约定好的 URL 参数、postMessage 消息等 Web 标准方式提供给网页，由网页代码自行使用
这种模式相当于在通用 AI Agent 主导的交互界面中，直接使用现有的标准开放 Web 生态，只不过 URL 不来源于用户在地址栏输入或点击链接，也不来源于 AI Agent 的「搜索发现」，而是在 AI Agent 使用「Action」形式的第三方应用（MCP Server）过程中，作为配套 UI 自动获得，并附加第三方应用开发者提供的使用方式等信息
2.3 Remote DOM
相当于 React Native 模式。MCP Server 只提供 UI 描述（比如基于非标准 HTML 元素的 DOM API 调用代码，或基于自定义 JSX 组件的声明式代码），不提供具体 UI 实现，由通用 AI Agent 用本地原生 UI 组件，按照这些 UI 描述来渲染原生 UI
这种模式会受限于平台原生组件，只能渲染出原生组件支持的 UI（在前面两种模式里，借助浏览器引擎这个最强大的通用标准 App Runtime，第三方可以实现相对任意的 UI）
也始终面临跨平台难题，因为各个通用 AI Agent 平台的原生组件体系和原生 UI 风格趋向差异化，使用这种 MCP-UI 实现方式的应用开发者很难提供跨平台的 MCP App。而如果给各平台搞统一的原生 UI 组件体系设计，就相当于重复造轮子搞非标准 web 了，类似小程序
以上发展趋势已经非常明显，行业事实标准已经形成，所以只要满足下面这些条件，建议就别自己造轮子搞「卡片应用」、「AI Native 小程序」了，现在就可以开始用 MCP App（含 MCP-UI）实现：
1. 你产品中的 AI Agent 主要通过纯数据接口来自动化操作第三方工具，而不是通过模拟 UI 交互
2. 你产品中 AI Agent 使用过程的交互界面，是自己实现的 UI（比如不像浏览器插件那样围绕别人的 GUI、或寄身在别人的 GUI 里）
3. 你产品中的 AI Agent 在借助第三方工具完成任务的过程中，无法仅凭自然语言为中心的粗粒度交互界面满足需求，需要在信息流中「内嵌」一些 GUI 反馈给用户，方便用户查看，或让用户可以直接在图形界面上做些「确认」之类的人工交互作为补充
4. 不希望自己独立负担 AI Agent 使用第三方工具过程中的所有 GUI 需求，需要「内嵌/聚合/混搭」一些第三方的 GUI
如果第三方工具没有提供 MCP Server，或提供的 MCP Server 里没有 MCP-UI，很多时候你可以低成本先帮他做一个部署到 Cloudflare，这也是对 Web 独有优势的利用——Web 中的 URL、代码和 HTTP API 都是天然对混搭友好的
补充：这个帖子里术语很多，没做解释，可能会被误解为虚指或我生造的概念，我更新了一下发在知乎的版本，加了大量链接：zhuanlan.zhihu.com
分发应用环节，会共存两类适合被通用 AI Agent 分发、可借助 「Tool Search Tool」被通用 AI Agent 自动发现的「Tool」：
1. 搜索发现「Action」（通过纯数据接口交互的 Tool） -> 发现 MCP Server -> 使用 MCP App
2. 搜索发现「UI」（通过 GUI 交互的 Tool） -> 发现 Web Page -> 使用 Web App
使用应用环节（这个使用过程也可以理解为对应用内部细粒度功能/内容的进一步分发），会共存两类适合通过（或结合）通用 AI Agent 来使用的「Install-free App」（这种应用能按需直接运行，能用完即抛无负担，不用限定于预设好的 Tool/Skill，能标准化和跨平台）：
1. 以「UI」为中心、采用「Action 嵌在 UI 里」模式的「Install-free App」——Web App
就是现有的网站、PWA。可以基于 WebMCP、PWA Actions 这类等价于原生 App Intents 的技术，在 HTML 或 Web App Manifest 这样的 UI 代码中内嵌「Action」的声明和实现（比如就是 JS 函数）
通用 AI Agent 既可以跟真人一样直接操作这些 UI，也可以精准调用 UI 代码中声明的这些 Actions
2. 以「Action」为中心，采用「UI 嵌在 Action 里」模式的「Install-free App」——MCP App
这种应用就是返回数据中包含 MCP-UI 的 MCP Server，是对「Apps in ChatGPT」和 OpenAI 「Apps SDK」的标准化（ MCP App 是 MCP 协议中的一个新标准，整合了另一个标准化项目 MCP-UI 和 ChatGPT 的 Apps）
目前已经有 ChatGPT App 之外的其他宿主应用支持 MCP-UI 和 MCP App，Block 的本地 AI Agent 开发框架 Goose 就重点支持了 MCP-UI，这次也被贡献给了 Agentic AI 基金会
其中的 MCP-UI 包含三种实现方式，都是基于 Web 技术的（后两种方式都来自 MCP-UI 项目，暂时还没有被 MCP Apps 协议纳入）：
2.1 HTML Template（含 CSS/JS）
这种 UI 模版被作为「资源」，通过 MCP Server 下发，被通用 AI Agent 预加载/注册（因此在 UI 渲染前有机会先做自动化审查），可以在通用 AI Agent 渲染自身对话界面的过程中被按需使用，在对话界面中嵌入这些第三方 UI
可以在这些 UI 代码中注入当前实时的上下文数据，甚至对 UI 代码做大幅修改，但仍然要用标准的浏览器引擎来渲染这些 UI 模版（比如注入到 iframe / WebView 里渲染），否则无法支持跨平台兼容性、无法兼容已有的开放 Web 生态（比如 OpenAI 推荐用 React、乃至开了 SSR 的 Next.js 来提供「Apps in ChatGPT」 中的 UI 模版）
这些 UI 由第三方负责实现和发布，不能由通用 AI Agent 自己随意杜撰，在很多情况下这是刚需，因为第三方产品中很多独有的用户价值需要借助这些 UI 来实现和交付，这些 UI 是产品中核心功能和「解决问题」的必要组成部分
另一方面，通用 AI Agent 这个「平台方」就像应用商店一样，对这些第三方 UI 拥有一定的掌控，用不用、如何用都由自己决定，包含隐私信息的上下文数据也都在自己内部，不提供给第三方
这种模式可以进一步跟一个新 Web 标准——IWA（Isolated Web App，特别是其中的 Web Bundles 技术）结合，这种 Web App 需要事先签名和离线打包，从而锁定代码，有资格获得更多原生权限。MCP Server 下发的「HTML 模版」可以换成 Web Bundles，变成整套 Web App 实现，而不仅限于单一网页
2.2 External URL
就是在 MCP Server 返回的数据里，直接提供服务器端现成的 Web Page、Web App 的 URL
通用 AI Agent 只能直接使用这些 URL（比如在 iframe / WebView 里加载），如果 UI 中要包含当前实时的上下文数据，只能通过约定好的 URL 参数、postMessage 消息等 Web 标准方式提供给网页，由网页代码自行使用
这种模式相当于在通用 AI Agent 主导的交互界面中，直接使用现有的标准开放 Web 生态，只不过 URL 不来源于用户在地址栏输入或点击链接，也不来源于 AI Agent 的「搜索发现」，而是在 AI Agent 使用「Action」形式的第三方应用（MCP Server）过程中，作为配套 UI 自动获得，并附加第三方应用开发者提供的使用方式等信息
2.3 Remote DOM
相当于 React Native 模式。MCP Server 只提供 UI 描述（比如基于非标准 HTML 元素的 DOM API 调用代码，或基于自定义 JSX 组件的声明式代码），不提供具体 UI 实现，由通用 AI Agent 用本地原生 UI 组件，按照这些 UI 描述来渲染原生 UI
这种模式会受限于平台原生组件，只能渲染出原生组件支持的 UI（在前面两种模式里，借助浏览器引擎这个最强大的通用标准 App Runtime，第三方可以实现相对任意的 UI）
也始终面临跨平台难题，因为各个通用 AI Agent 平台的原生组件体系和原生 UI 风格趋向差异化，使用这种 MCP-UI 实现方式的应用开发者很难提供跨平台的 MCP App。而如果给各平台搞统一的原生 UI 组件体系设计，就相当于重复造轮子搞非标准 web 了，类似小程序
以上发展趋势已经非常明显，行业事实标准已经形成，所以只要满足下面这些条件，建议就别自己造轮子搞「卡片应用」、「AI Native 小程序」了，现在就可以开始用 MCP App（含 MCP-UI）实现：
1. 你产品中的 AI Agent 主要通过纯数据接口来自动化操作第三方工具，而不是通过模拟 UI 交互
2. 你产品中 AI Agent 使用过程的交互界面，是自己实现的 UI（比如不像浏览器插件那样围绕别人的 GUI、或寄身在别人的 GUI 里）
3. 你产品中的 AI Agent 在借助第三方工具完成任务的过程中，无法仅凭自然语言为中心的粗粒度交互界面满足需求，需要在信息流中「内嵌」一些 GUI 反馈给用户，方便用户查看，或让用户可以直接在图形界面上做些「确认」之类的人工交互作为补充
4. 不希望自己独立负担 AI Agent 使用第三方工具过程中的所有 GUI 需求，需要「内嵌/聚合/混搭」一些第三方的 GUI
如果第三方工具没有提供 MCP Server，或提供的 MCP Server 里没有 MCP-UI，很多时候你可以低成本先帮他做一个部署到 Cloudflare，这也是对 Web 独有优势的利用——Web 中的 URL、代码和 HTTP API 都是天然对混搭友好的
补充：这个帖子里术语很多，没做解释，可能会被误解为虚指或我生造的概念，我更新了一下发在知乎的版本，加了大量链接：zhuanlan.zhihu.com
3 10
大家都应该有图中这位同学的行动力和主动性。不过这种模式的应用之后会趋向被平台「模板化」，普通C端用户在使用OS全局AI助手（下一代分发入口）的过程中会无意中按需动态创建很多这样的免安装App（基于Bun这样的App Runtime），可能一次性使用也可能作为个性化工具留用。所以说AI编程最大的应用场景不是面向专业开发者的，未来大多数AI编程的用户根本不知道自己在coding在 build
从更广义的角度来说，现在AI Agent在使用MCP工具的时候，最佳实践已经完全是通过动态生成一次性代码去使用了，相当于用代码作为软件交互中的输入方式，而前面说的是用代码作为人机交互中的输出方式，这两种交互需求加在一起带来的token生产需求才是AI编程能力的主要应用场景
从更广义的角度来说，现在AI Agent在使用MCP工具的时候，最佳实践已经完全是通过动态生成一次性代码去使用了，相当于用代码作为软件交互中的输入方式，而前面说的是用代码作为人机交互中的输出方式，这两种交互需求加在一起带来的token生产需求才是AI编程能力的主要应用场景
2 00
类比：中国移动互联网就像北京城市规划（朝阳国际化区域除外），由很多大院、墙围起来的庞大小区、集中的商业地产综合体和稀疏的宽大多车道马路组成，这些区域没法citywalk，大院小区的门卫还不让「外人」进去
通用Agentic平台生态就像日本城市，密集路网、海量小地块建筑和沿街店面铺开形成都市圈， 由轨道交通紧密链接在一起。有些人一进地铁站就晕了，需要粗粒度的要求机器人（或XR设备里的虚拟助手）带路，有时需要机器人替自己去逛街淘货，否则只能等待上门推销或吃社区食堂
通用Agentic平台生态就像日本城市，密集路网、海量小地块建筑和沿街店面铺开形成都市圈， 由轨道交通紧密链接在一起。有些人一进地铁站就晕了，需要粗粒度的要求机器人（或XR设备里的虚拟助手）带路，有时需要机器人替自己去逛街淘货，否则只能等待上门推销或吃社区食堂
dexteryy: Agentic AI在超级应用主导的体系内注定是赢不了的，无法共存，就像整个移动互联网时代通用搜索引擎从没赢过 从桌面互联网直接迁移过来就是无缝衔接，只是把Google们换成了ChatGPT/豆包们，把地址栏/搜索框换成聊天框和 AR/MR 透视画面，网页还要比之前更离散（比如 MCP-UI）更语义化（继承 Semantic Web 遗志，回归Web不为人而为机器优化的初衷，比如目前发展中的WebMCP和其他Agentic Web协议） 只有从国内这种被超级应用和封闭小程序主导的畸形移动互联网迁移过来，冲突才不可调和。国外即使在移动互联网也有很多Shopify这样基于开放Web的平台，无缝衔接进入ChatGPT 从 bundling 到 unbundling 的转变，对很多只经历过移动互联网这一个周期的人来说可能难以想象，其实无论在小尺度（很多 startup 赛道）和大尺度（宏观范式转移）上这种转变都是经常发生、反复发生的，有很多先例可以参考，比如搜索引擎之前的媒体就是 bundling 的，也激烈冲突过（图2、图3） 对客户端 Agentic AI 的刚需至少来自两方面，一个是对「粗粒度交互」的需求： 说「关车窗」是「细粒度交互」。说「车里不舒服」，AI 结合来自车内环境和用户可穿戴设备的多模态输入（传感器数据），自动触发关车窗、开暖气、座椅加热等一系列并行动作，再自动串行触发一个屏幕上的 UI 反馈询问用户是否一键创建「workflow」在类似使用场景下自动提前做这些环境优化。这就是「粗粒度交互」 对大众用户来说，粗粒度交互的有无，很多时候不是能不能偷懒省事这样的好用「程度」的问题，而是对一款软件「会不会用」、「能不能用出足够好结果」的「有无」问题 这种粗粒度交互就像 vibe coding 一样不必一口气干完所有事情，一次软件使用任务可以由多次粗粒度交互和多次细粒度交互组成，客户端 AI Agent 跟用户可以紧密协作、轮流操作（在原 GUI 上或 GenAI 动态提供的 GUI 上） 另一方面是对「跨工具」和「个性化聚合混搭工具」的需求。微信应用自己内部的全局Agent也可以支持粗粒度交互，但无法实现跨微信美团苹果日历等多个app/web的粗粒度交互 Web天然对「跨工具的使用场景」友好，是顺趋势的，超级应用则天然是反跨工具的，逆趋势，注定赢不了，手机上还需要互相拉扯，到了下一代平台（包括由「手机外设」带来的新一代人机交互平台）就直接没有超级应用的生存空间了。下一代平台上根本无法存在现在这样的微信 「跨工具」需求不但要求Agentic AI对「分发 」环节解绑（unbundling），也要求对更上游的「创造、构建」环节解绑（图4）：用户使用的 GUI 和功能/内容很多不再是超级应用厂商预制/规定好的，而是由按需动态生成的代码，把跨工具的现有功能/内容作为 building blocks 或 raw 数据，聚合混搭成个性化或一次性的新功能/内容（就好像古典互联网中一个收录整理了很多URL的论坛帖子） 从商业模式角度，Agentic AI 对超级应用的先解绑（unbundling）再捆绑（bundling）也是不可避免的（图5），比如类似 Netflix 会员和 XBox Game Pass 的模式，结合 x402 这样细粒度自主化计费方式（每次细粒度功能/内容调用、每个 HTTP 请求都自动付费），以及为单次解决问题付费等，上游垂直agent平台（比如外卖平台）对更上游供应商的提成等商业模式不受影响
0 00
Agentic AI在超级应用主导的体系内注定是赢不了的，无法共存，就像整个移动互联网时代通用搜索引擎从没赢过
从桌面互联网直接迁移过来就是无缝衔接，只是把Google们换成了ChatGPT/豆包们，把地址栏/搜索框换成聊天框和 AR/MR 透视画面，网页还要比之前更离散（比如 MCP-UI）更语义化（继承 Semantic Web 遗志，回归Web不为人而为机器优化的初衷，比如目前发展中的WebMCP和其他Agentic Web协议）
只有从国内这种被超级应用和封闭小程序主导的畸形移动互联网迁移过来，冲突才不可调和。国外即使在移动互联网也有很多Shopify这样基于开放Web的平台，无缝衔接进入ChatGPT
从 bundling 到 unbundling 的转变，对很多只经历过移动互联网这一个周期的人来说可能难以想象，其实无论在小尺度（很多 startup 赛道）和大尺度（宏观范式转移）上这种转变都是经常发生、反复发生的，有很多先例可以参考，比如搜索引擎之前的媒体就是 bundling 的，也激烈冲突过（图2、图3）
对客户端 Agentic AI 的刚需至少来自两方面，一个是对「粗粒度交互」的需求：
说「关车窗」是「细粒度交互」。说「车里不舒服」，AI 结合来自车内环境和用户可穿戴设备的多模态输入（传感器数据），自动触发关车窗、开暖气、座椅加热等一系列并行动作，再自动串行触发一个屏幕上的 UI 反馈询问用户是否一键创建「workflow」在类似使用场景下自动提前做这些环境优化。这就是「粗粒度交互」
对大众用户来说，粗粒度交互的有无，很多时候不是能不能偷懒省事这样的好用「程度」的问题，而是对一款软件「会不会用」、「能不能用出足够好结果」的「有无」问题
这种粗粒度交互就像 vibe coding 一样不必一口气干完所有事情，一次软件使用任务可以由多次粗粒度交互和多次细粒度交互组成，客户端 AI Agent 跟用户可以紧密协作、轮流操作（在原 GUI 上或 GenAI 动态提供的 GUI 上）
另一方面是对「跨工具」和「个性化聚合混搭工具」的需求。微信应用自己内部的全局Agent也可以支持粗粒度交互，但无法实现跨微信美团苹果日历等多个app/web的粗粒度交互
Web天然对「跨工具的使用场景」友好，是顺趋势的，超级应用则天然是反跨工具的，逆趋势，注定赢不了，手机上还需要互相拉扯，到了下一代平台（包括由「手机外设」带来的新一代人机交互平台）就直接没有超级应用的生存空间了。下一代平台上根本无法存在现在这样的微信
「跨工具」需求不但要求Agentic AI对「分发 」环节解绑（unbundling），也要求对更上游的「创造、构建」环节解绑（图4）：用户使用的 GUI 和功能/内容很多不再是超级应用厂商预制/规定好的，而是由按需动态生成的代码，把跨工具的现有功能/内容作为 building blocks 或 raw 数据，聚合混搭成个性化或一次性的新功能/内容（就好像古典互联网中一个收录整理了很多URL的论坛帖子）
从商业模式角度，Agentic AI 对超级应用的先解绑（unbundling）再捆绑（bundling）也是不可避免的（图5），比如类似 Netflix 会员和 XBox Game Pass 的模式，结合 x402 这样细粒度自主化计费方式（每次细粒度功能/内容调用、每个 HTTP 请求都自动付费），以及为单次解决问题付费等，上游垂直agent平台（比如外卖平台）对更上游供应商的提成等商业模式不受影响
从桌面互联网直接迁移过来就是无缝衔接，只是把Google们换成了ChatGPT/豆包们，把地址栏/搜索框换成聊天框和 AR/MR 透视画面，网页还要比之前更离散（比如 MCP-UI）更语义化（继承 Semantic Web 遗志，回归Web不为人而为机器优化的初衷，比如目前发展中的WebMCP和其他Agentic Web协议）
只有从国内这种被超级应用和封闭小程序主导的畸形移动互联网迁移过来，冲突才不可调和。国外即使在移动互联网也有很多Shopify这样基于开放Web的平台，无缝衔接进入ChatGPT
从 bundling 到 unbundling 的转变，对很多只经历过移动互联网这一个周期的人来说可能难以想象，其实无论在小尺度（很多 startup 赛道）和大尺度（宏观范式转移）上这种转变都是经常发生、反复发生的，有很多先例可以参考，比如搜索引擎之前的媒体就是 bundling 的，也激烈冲突过（图2、图3）
对客户端 Agentic AI 的刚需至少来自两方面，一个是对「粗粒度交互」的需求：
说「关车窗」是「细粒度交互」。说「车里不舒服」，AI 结合来自车内环境和用户可穿戴设备的多模态输入（传感器数据），自动触发关车窗、开暖气、座椅加热等一系列并行动作，再自动串行触发一个屏幕上的 UI 反馈询问用户是否一键创建「workflow」在类似使用场景下自动提前做这些环境优化。这就是「粗粒度交互」
对大众用户来说，粗粒度交互的有无，很多时候不是能不能偷懒省事这样的好用「程度」的问题，而是对一款软件「会不会用」、「能不能用出足够好结果」的「有无」问题
这种粗粒度交互就像 vibe coding 一样不必一口气干完所有事情，一次软件使用任务可以由多次粗粒度交互和多次细粒度交互组成，客户端 AI Agent 跟用户可以紧密协作、轮流操作（在原 GUI 上或 GenAI 动态提供的 GUI 上）
另一方面是对「跨工具」和「个性化聚合混搭工具」的需求。微信应用自己内部的全局Agent也可以支持粗粒度交互，但无法实现跨微信美团苹果日历等多个app/web的粗粒度交互
Web天然对「跨工具的使用场景」友好，是顺趋势的，超级应用则天然是反跨工具的，逆趋势，注定赢不了，手机上还需要互相拉扯，到了下一代平台（包括由「手机外设」带来的新一代人机交互平台）就直接没有超级应用的生存空间了。下一代平台上根本无法存在现在这样的微信
「跨工具」需求不但要求Agentic AI对「分发 」环节解绑（unbundling），也要求对更上游的「创造、构建」环节解绑（图4）：用户使用的 GUI 和功能/内容很多不再是超级应用厂商预制/规定好的，而是由按需动态生成的代码，把跨工具的现有功能/内容作为 building blocks 或 raw 数据，聚合混搭成个性化或一次性的新功能/内容（就好像古典互联网中一个收录整理了很多URL的论坛帖子）
从商业模式角度，Agentic AI 对超级应用的先解绑（unbundling）再捆绑（bundling）也是不可避免的（图5），比如类似 Netflix 会员和 XBox Game Pass 的模式，结合 x402 这样细粒度自主化计费方式（每次细粒度功能/内容调用、每个 HTTP 请求都自动付费），以及为单次解决问题付费等，上游垂直agent平台（比如外卖平台）对更上游供应商的提成等商业模式不受影响
4 11