OpenAI今日宣布用户将能够在ChatGPT内部直接运行功能完备的Apps，并同步发布了供开发者使用的Apps SDK预览版。这并非其早期Plugins和GPT Store功能的简单迭代，而是基于MCP技术。
ChatGPT Apps SDK的整个技术体系构建于模型上下文协议（Model Context Protocol, MCP）之上。
在此架构中，各组件的角色分工明确：ChatGPT本身扮演着MCP主机（Host）和客户端（Client）的角色，负责处理用户输入、驱动对话流程、并根据其强大的推理能力决定何时以及如何与外部服务交互。而开发者构建的应用则以后端MCP服务器（Server）的形式存在。OpenAI Apps SDK本质上是在此基础上增加了一个标准化的UI呈现层。
这种将业务逻辑（运行在开发者的MCP服务器上）与表示和推理逻辑（由ChatGPT客户端处理）进行分离的设计，是一种AI时代经典的应用模式，但出现在ChatGPT里这种具有很高市占率的APP里还是头一遭。
当模型在其推理过程中决定调用某个工具时，它会向该工具对应的MCP服务器发送一个标准化的请求。服务器在执行完相应逻辑后，其返回的响应是实现交互式体验的关键。该响应不仅包含业务逻辑处理后的结构化数据（封装在structuredContent字段中），还可以在元数据（_meta）中包含一个名为_meta.openai/outputTemplate的关键字段。
该字段的值是一个统一资源标识符（URI），它指向一个HTML模板资源。ChatGPT客户端在接收到此响应后，会执行以下UI渲染管线：
解析_meta.openai/outputTemplate字段，获取指向UI组件的URI。
根据该URI，向MCP服务器请求对应的HTML、JavaScript和CSS资源。
在一个严格隔离的沙盒化iframe环境中，加载并渲染这些前端资源。
将响应中structuredContent字段的JSON数据，注入到这个iframe的window对象中，供组件的JavaScript代码消费和渲染。
这是Apps SDK相较于传统Function Calling的核心创新。它通过一个标准化的协议机制，将一个抽象的工具调用（返回数据）与一个具体的可视化组件（呈现数据）进行了绑定。这使得开发者不仅能向对话流中提供数据，还能完全掌控这些数据的呈现方式。例如，一个查询Zillow房源的工具调用，其MCP响应可以包含房源列表的JSON数据，并通过_meta.openai/outputTemplate指向一个地图组件的HTML文件。ChatGPT随后会在对话中渲染一个可交互的地图，并在地图上标记出这些房源，从而实现从简单的文本回复到丰富的交互式体验的跨越。
在iframe沙盒内运行的UI组件并非完全孤立。Apps SDK提供了一个全局的window.openaiJavaScript对象，作为组件与ChatGPT宿主环境之间通信的桥梁(https://developers.openai.com/apps-sdk/reference）。这个桥接API提供了一系列至关重要的能力：
数据访问: 组件可以通过window.openai.toolInput和window.openai.toolOutput属性，分别获取调用该工具时的输入参数和工具返回的结构化数据。
组件内发起动作: 组件内的用户交互（如点击按钮）可以通过调用window.openai.callTool函数，直接触发对MCP服务器上其他工具的调用。这使得刷新数据、提交表单或执行新动作成为可能。
状态持久化: window.openai.setWidgetState函数允许组件保存其当前的UI状态（例如，用户选中的标签页、应用的筛选条件或表单中未提交的草稿内容）。这个状态会与当前对话绑定，当用户在后续的对话中再次与该组件交互时，该状态会被恢复。这解决了无状态的Web组件在多轮对话中保持上下文的难题，对于构建复杂的、有记忆的应用至关重要。
发起新对话轮次: window.openai.sendFollowupTurn函数允许组件模拟用户发起一个新的提问。这使得交互可以从UI操作无缝地转回到对话流中，例如，在一个看板应用中点击“总结任务”按钮，可以触发一个新的对话轮次，要求ChatGPT总结所有未完成的任务。
请求显示模式: window.openai.requestDisplayMode函数允许组件向宿主环境请求更大的显示空间，例如从默认的行内卡片模式切换到全屏模式，以适应地图、编辑器等更复杂的内容展示。
Apps SDK安全机制核心是iframe沙盒模型。所有由开发者提供的自定义UI组件都在一个具有严格限制的iframe中运行。
这个沙盒环境实施了严格CSP，主要限制包括：
网络访问限制: 默认情况下，组件内的代码（如fetch请求）只能访问预先声明并经过审核的域名。开发者需要明确其应用需要访问的外部API域名，并可能需要通过OpenAI的审核流程将其加入白名单。
浏览器API限制: 沙盒环境禁止调用一系列可能带来安全风险或破坏用户体验的特权浏览器API，例如window.alert、window.prompt、navigator.clipboard等。
DOM隔离: iframe内的代码无法访问或操作ChatGPT主页面的DOM结构，从而防止了跨站脚本攻击、界面篡改或用户凭证窃取等风险。
为了更清晰地定位ChatGPT App的架构特性，可将其与两个成熟的生态——微信小程序和Telegram Mini App——进行横向对比。这三者虽然都旨在将第三方服务集成到主应用内，但其底层的技术架构和核心设计哲学存在显著差异。
微信小程序和Telegram Mini App本质上都是由用户直接驱动的应用。用户通过点击菜单、按钮或链接来启动和操作这些小程序，其界面和交互逻辑是对用户显式操作的直接响应。
相比之下，ChatGPT App的交互驱动者发生了根本性的变化。很多时候，UI的出现是LLM推理过程的结果。用户向LLM陈述一个目标（例如，“帮我规划去西雅图的周末旅行”），LLM理解意图后，自主决定调用Expedia或Booking.com的工具，而相应的UI（如航班和酒店列表）是作为该决策的产物而被渲染出来的。用户的主要交互对象是LLM，而非UI本身。这种模式将开发者的设计重心从传统的“用户流和界面导航设计”转移到了“工具功能和元数据设计”上，即如何让工具的功能和意图能被LLM准确理解和可靠调用。
下表总结了三者在关键维度上的架构差异：
OpenAI CEO Sam Altman表示，Apps SDK将帮助开发者触达ChatGPT数以亿计的庞大用户群体。这一愿景常被业界比作苹果公司在2008年推出的App Store，预示着一个新生态的诞生。然而，ChatGPT App生态的核心分发逻辑与传统应用商店存在本质区别。
传统App Store主要依赖于用户的主动发现行为，如图标浏览、榜单排名和关键词搜索。而ChatGPT App的分发在很大程度上是由模型驱动的、基于上下文的被动推荐 1。用户可以通过在对话开头直接点名来调用某个App，但更常见的发现方式是，ChatGPT在理解用户意图后，在对话中主动建议并调用最相关的App。
这意味着应用的可见性不再仅仅取决于市场预算、下载量或用户评分，而是更多地取决于其“工具”对于模型的“可理解性”和“相关性”。如果应用的分发是由模型智能驱动的，那么影响模型决策的关键就在于开发者通过MCP服务器提供的元数据——即工具的名称、功能描述以及输入输出参数的模式（Schema）。
由此，一个全新的优化领域应运而生，可以称之为“工具元数据优化”（Tool Metadata Optimization, TMO）或“面向Agent的优化”（Agent-Facing Optimization, AFO）。这类似于传统互联网领域的搜索引擎优化（SEO）和应用商店优化（ASO）。开发者需要精心撰写清晰、准确、面向动作的工具描述，以确保模型能在恰当的时候选择自己的工具，而非竞争对手的工具或内置功能。成功的关键将在于开发者能否通过工具定义，“说服”模型自己的工具是完成用户任务的最佳选择。这要求开发者不仅要懂代码，更要懂如何与模型沟通。
作为Apps SDK能力的一个重要应用实例，OpenAI与支付巨头Stripe合作，共同开发并开源了“智能体商业协议”（Agentic Commerce Protocol, ACP）33。该协议旨在为AI Agent代表用户进行交易提供一个开放、安全、标准化的框架。基于ACP，ChatGPT推出了“即时结账”（Instant Checkout）功能，允许美国用户在对话中直接完成商品购买，而无需跳转到商家网站。
对于商家而言，这开辟了一个极具吸引力的新销售渠道，但也带来了新的挑战——它们可能会失去对用户发现旅程的直接控制，这一环节的主导权将更多地转移到AI平台手中。Shopify、Etsy等主流电商平台选择积极参与ACP的早期试点，表明它们认识到了这一趋势的不可逆转，并选择主动拥抱变革，以避免在新的商业范式中被边缘化。
Apps SDK为开发者提供了一套完整的端到端工具栈，包括连接外部数据、触发后端动作和渲染自定义交互界面的能力。开发者可以连接自己的后端服务，从而实现现有用户的登录认证和高级付费功能。
这个平台的出现，极大地降低了构建和分发复杂应用的门槛，其中最重要的可能是--付款。过去，一个个人开发者或小团队需要投入大量精力去从零开始构建用户管理系统、支付集成、跨平台UI适配和市场推广渠道。而现在，他们可以专注于自己最擅长的垂直领域，将其核心能力封装成一个或多个高效、可靠的MCP服务器，然后借助ChatGPT庞大的用户基础和智能分发能力来触达潜在用户。
然而，机遇与挑战并存。开发者社区对此也表达了一些担忧。例如，在Hacker News的讨论中，开发者普遍对新平台的质量控制表示疑虑，担心其重蹈GPT Store早期内容泛滥、质量参差不齐的覆辙。同时，由MCP引入的提示注入等安全风险也让许多开发者感到不安。
此外，一个关键的不确定性在于商业化模式。OpenAI表示将在未来公布盈利细节，包括可能的收入分成机制。这与Roblox或Shopify App Store等成熟平台明确的收入分成模式形成对比。在商业化路径明朗之前，这种不确定性是当前开发者在评估投入产出比时面临的主要风险。
从Plugin到GPT Store, OpenAI在试图像苹果当年一样绑定创作者的路上一直都是毫无意为的先驱--但先驱和先烈很多时候是同义词。
之前的尝试毫无意外的都失败了，希望这次不是又一个大的要来了的故事。