KechuAI

Skybridge：把 React 组件直接渲染进 ChatGPT 与 Claude 的 MCP 应用全栈框架

AI
开源
MCP
React
前端
TypeScript
2026/9/29
·

阅读时间: 大约 9 分钟

Skybridge：把 React 组件直接渲染进 ChatGPT 与 Claude 的 MCP 应用全栈框架

Skybridge 文档首屏：用 server.registerTool 注册一个工具，并通过 view: { component: "greeting" } 把它绑定到一个 React 视图

2025 年 12 月 8 日，MCP 部署平台 Alpic 在 Launch Week #2 正式开源了 Skybridge——一个专为 MCP Apps 设计的全栈 TypeScript/React 框架。它的目标是：开发者定义好工具、写好 React 组件，剩下的 MCP server 搭建、视图渲染、客户端兼容、测试隧道都由框架接管，让同一份代码跑在 Claude、ChatGPT、VS Code、Cursor、Goose 等任意 MCP 兼容客户端里。本文基于 Alpic 官方发布博客与 Skybridge 文档，分析它解决了什么、怎么解决、边界在哪。

一、背景：从”对话即界面”到”对话里塞应用”

过去两年，MCP（Model Context Protocol）解决了”模型怎么调用外部工具”的问题，但工具的返回往往只是一段文本。随着 ChatGPT Apps、MCP Apps 出现，开发者可以在对话流里直接渲染交互式组件——轮播图、地图、可点列表、视频播放器。Alpic 判断这会成为 B2C 乃至大量 B2B 产品的重要分发入口（官方援引 ChatGPT 8 亿周活跃用户作为论据）。

但 OpenAI 放出的 Apps SDK 是一堆”裸原语”：window.openai 接口负责状态持久化、工具调用、后续消息与布局管理，却几乎没有现代前端栈该有的东西（数据获取状态、状态管理、类型安全、HMR）。更麻烦的是 双界面一致性：UI 上展示的内容和发给模型的内容必须对齐，否则用户看到的和模型”以为”的不一致。

二、它是什么：三件套

Skybridge 由三部分组成：

  1. React 库：提供 hooks、组件和运行时粘合，把你的 widget 渲染进 ChatGPT 的 iframe 环境；
  2. 官方 MCP SDK 的 drop-in 替代：在其之上增加 widget 注册与类型推断能力；
  3. Vite 插件 + 开发服务器：开箱即得 HMR、本地模拟器、永久隧道（把本地应用直接连到线上 Claude/ChatGPT 测试）。

文档把 MCP Apps 定义为一个三方系统——与传统双向 Web 应用不同，数据在”你的应用、用户、模型”三者之间流动。框架围绕三个核心概念组织：Architecture（用模型智能设计体验）、Tools（定义人与 agent 能看/能做什么）、Views（在对话里渲染的交互 UI）。

三、关键机制

工具即视图绑定。在 server.ts 里注册工具时，直接用 view: { component: "greeting" } 把一次工具调用映射到一个 React 组件（见上图）。工具的 inputSchema 用 Zod 声明，返回 structuredContent，框架由此做 tRPC 风格的端到端类型推断——从服务端工具定义一路推断到 React 视图。

data-llm：声明式 widget-to-context 同步。这是 Alpic 发布着墨最多的设计。任何 React 节点都可以挂一个 data-llm 属性，其值是一段字面文本，会被聚合（按节点嵌套结构）后通过 window.openai.setWidgetState 注入模型上下文。这样”只有渲染出来、用户看得见的内容，才会共享给模型”，天然避免了 UI 与模型上下文漂移。示例里 ProductCard 把 product.description 写进 data-llm，模型就知道卡片在展示什么。

useCallTool：react-query 风格的数据获取。OpenAI 原生 window.openai.callTool 只是一个返回 Promise 的命令式 API，loading/error/data 状态全得自己写。Skybridge 包成 react-query 风格的 hook，一行拿到 callTool / isPending / isSuccess / data，并带类型。官方称这类封装能减少”约 85% 的样板代码”。

createStore：基于 Zustand 的隔离状态。每个 widget 只有一份状态，多组件并发更新容易互相覆盖或竞态。Skybridge 用 Zustand 提供 createStore 工厂，给组件隔离 store。

Agent-ready：框架自带 CLI、skill 与程序化开发 API，甚至提供 npx skills add alpic-ai/skybridge -s skybridge，让编码 agent 自主开发 MCP App。

四、口径与局限

  1. “85% 更少代码”是官方定性说法，没有给出对照样本与测量方法，应理解为”大幅减少样板”而非严格基准。
  2. “8 亿周活用户”是 ChatGPT 的营销口径，与 Skybridge 自身采用度无关；能触达多少取决于各 MCP 客户端对 Apps/widget 的支持成熟度。
  3. 仍受宿主能力约束：底层依赖 window.openai 这类宿主 API，而 Alpic 自己也承认各客户端”认证不完善、协议更新频繁、功能支持碎片化”。跨客户端一致性需要框架抹平，但宿主一旦改协议仍需跟进。
  4. Koala 点评指出：Skybridge 目前是通过”为每次工具调用请求/结果定制 React 组件”来扩展 UI 的，对于希望脱离聊天对话框、构建更独立复杂界面的场景，它暂时帮不上忙——本质上它仍是”对话内嵌组件”范式。
  5. 主站当时访问异常：本次调研期间 www.skybridge.tech 出现重定向循环、裸域证书过期，信息主要来自 docs.skybridge.tech 与 Alpic 发布博客。

五、客观分析：优势与谁该关注

优势：把 MCP Apps 里最脏的活（协议、认证、宿主差异、HMR、隧道、模拟器）一次性封装；tRPC 风格端到端类型对 TypeScript 团队友好；data-llm 用声明式思路解决了双界面同步这个真问题。

局限：范式锁定在”对话内嵌 widget”，不适合想做独立 Web 产品的团队；深度依赖 ChatGPT/Claude 的宿主 iframe 环境，跨端一致性是长期运维负担；框架较新（2025 年 12 月才发布），生态与最佳实践仍在积累。

适合谁：已经在 MCP 上做工具、想顺手给工具加交互 UI、并把 ChatGPT/Claude 当作分发渠道的 TypeScript 团队；尤其适合电商、旅游、SaaS 这类”卡片式结果”天然适合对话内渲染的场景。

参考来源