介绍
关于生成式 UI
在普通聊天界面里，模型通常只能输出 Markdown。它可以写出列表、表格和代码块，但很难表达更适合交互的内容：时间线、计划表、指标卡、表单、图表、商品卡片、步骤进度、可展开的诊断结果，等等。
生成式 UI 的目标是让模型在合适的时候生成结构化界面。用户看到的不再只是文本描述，而是更清晰、更可操作的组件。应用仍然掌控视觉渲染、交互逻辑和设计系统；模型只生成组件数据。
生成式 UI 的问题
组件很适合展示，却不一定适合作为消息历史。
如果聊天记录里只有一个视觉组件，用户复制消息时会丢失内容；服务端把历史上下文重新发给模型时，也很难表达这个组件的含义。如果直接把 JSON、HTML 或内部状态塞进上下文，模型能看到的内容会变得冗长、不稳定，也不适合搜索、审计和分享。
很多生成式 UI 方案解决了“如何渲染组件”，但没有同时解决“这个组件如何变回一段可靠的文本”。这会影响几个常见需求：
- 复制一条 AI 回复。
- 把历史消息重新放入模型上下文。
- 存储、搜索和审计聊天记录。
- 在不支持某个组件的客户端里显示消息。
- 在渲染器升级后仍然保留消息原本的含义。
MFUI 的方案
MFUI 是一层可以接入现有 AI 工作流的消息协议和工具包。它实现生成式 UI 的同时，也解决组件消息在复制、历史上下文、搜索和未知客户端里的表达问题。
它不会限制你的前端框架、后端框架或模型提供商。前端定义组件、schema 和文本投影；服务端把这些定义交给模型，校验模型返回的组件数据，并生成稳定的文本兜底。具体组件如何渲染、如何交互，仍然由你的应用决定。
这意味着同一条 AI 消息同时拥有两种形态：
| 形态 | 用途 |
|---|---|
| 组件规格 | 用于客户端渲染丰富、可交互的界面。 |
| 文本投影 | 用于复制、历史上下文、搜索、审计和未知组件兜底。 |
这是发布计划：
3 月 15 日
项目启动
确认目标、里程碑和协作方式。
3 月 22 日
设计评审
3 月 29 日
公开预览
发布首个可试用版本，并收集反馈。
组件 UI用于展示与交互
这是发布计划：
- 3 月 15 日: 项目启动 - 确认目标、里程碑和协作方式。
- 3 月 22 日: 设计评审
- 3 月 29 日: 公开预览 - 发布首个可试用版本，并收集反馈。文本投影用于复制、分享和作为上下文
和其它方案的区别
大多数生成式 UI 方案优先解决“模型如何生成 UI”或“前端如何渲染 UI”。MFUI 更关注另一层问题：当 UI 成为一条 AI 消息的一部分时，这条消息如何被复制、保存、搜索、审计，并重新作为模型上下文使用。
| 能力 | MFUI | json-render | A2UI | assistant-ui | OpenUI |
|---|---|---|---|---|---|
| 生成可渲染组件 | ✅ | ✅ | ✅ | ✅ | ✅ |
| 使用应用自己的组件 | ✅ | ✅ renderer | ✅ native | ✅ React | ⚠️ runtime |
| 服务端校验组件数据 | ✅ 内置 | ⚠️ spec/schema | ✅ 协议层 | ⚠️ allowlist 为主 | ⚠️ 框架处理 |
| 复制成稳定文本 | ✅ 内置 | ❌ | ❌ | ❌ | ❌ |
| 适合作为模型上下文 | ✅ portable text | ❌ JSON spec 偏重 | ❌ UI 状态偏重 | ⚠️ 自行设计 | ❌ UI response 偏重 |
| 未知组件文本兜底 | ✅ 内置 | ⚠️ renderer 自行处理 | ⚠️ renderer 自行处理 | ⚠️ fallback 组件 | ⚠️ renderer 自行处理 |
| 消息级语义表达 | ✅ 文本 + 组件 | ❌ UI spec 为主 | ⚠️ agent/surface | ⚠️ chat parts | ⚠️ UI response |
| 动态 UI 和交互 | ⚠️ 应用组件负责 | ✅ | ✅ | ✅ | ✅ |
| 跨平台 native | ❌ | ⚠️ 取决于 renderer | ✅ | ❌ | ❌ |
| 接入成本 | ✅ 小层接入 | ⚠️ 要接 spec 体系 | ❌ 协议面更大 | ⚠️ React chat 栈 | ❌ 更像完整框架 |
这些方案并不互斥。如果你需要 agent 长时间驱动复杂界面状态，A2UI、OpenUI 或 assistant-ui 这类方案会更完整。MFUI 更适合补上消息语义层：让结构化组件和稳定文本同时存在。