AI 的能力是通天的，表达方式却被文本框锁死：让它分析季度销售数据，它脑子里建好了完美的数据模型，吐出来的却是一串干巴巴的数字。在对话框里嵌一个能跑真实网页的小窗口，是打破这把锁的方向——2026 年 10 月 OpenAI 给 ChatGPT 全量推送的 Intelligent UI 让这条路成了主流叙事，但它背后的开放标准（MCP Apps）更早出现。本文拆这套技术的两个核心问题和三条双向通信通道。
两个独立的问题，别混着解
动态 UI 拆开是两道题：怎么让一个预先写好的 UI 出现在对话里并能双向交互（MCP Apps 解决的）；UI 能不能不是预先写好、而是模型现场生成的（Intelligent UI 的终极形态）。第一道是基础设施，第二道是进阶玩法，落地时先把第一道打通。
第一把钥匙：工具身上多了个门牌号
MCP Apps 的工具和普通 MCP 工具几乎一样，唯一区别是自我介绍时多带一行 resourceUri，指向 MCP 服务中打包好的 UI 资源（HTML 加 JS）。模型调用工具时，客户端不仅执行函数，还顺着地址把对应界面拉下来渲染。一个 visualize_data 工具，带上 ui://charts/interactive 的门牌，就从一个返回文本的函数变成了一个可交互的图表窗口。
第二把钥匙：三条通信通道
窗口嵌进来了，真正硬核的是双向通信——数据怎么进去、用户的操作怎么出来。
进去靠双字段分离：工具执行结果包含 content（给模型和用户读的文本摘要）和 structuredContent（给 UI 渲染的完整结构化 JSON）。这一招"明修栈道暗度陈仓"让模型只看摘要保持专注，图表吃到全量数据，两条路径互不干扰——模型上下文不膨胀，UI 不缺数据。
出来有三条通道，语义完全不同：
callServerTool：绕过模型直达服务器。用户在图表里点"按华东区筛选"，宿主直接调 MCP 服务器重查数据再渲染。全程不经过大模型——没有幻觉、100% 准确、毫秒级响应，适合数据准确性要求极高的 BI 场景。sendMessage：代替用户向模型喊话。UI 把用户勾选的 10 个筛选条件组装成一条标准用户消息发给 Agent，模型看到的就是一条用户指令。适合把复杂的 UI 操作翻译成模型能理解的任务描述。updateModelContext：隐秘的上下文注入。把应用当前状态悄悄塞进模型上下文，不触发任何即时回复。地图 UI 里用户框选了商圈，随后随口问"有什么好吃的"，模型收到的是带系统备注的问题——体验丝滑，但注入的内容要克制，塞多了就是上下文污染。
三条通道的选型判据：改数据走直达、发任务走消息、带上下文走注入。
现场生成 UI：黑客级方案与工程权衡
预设 UI 之外还有更激进的路线：劫持 MCP App 的静态资源获取流程，宿主请求 ui:// 资源时返回一块空白画布，模型调用专用工具把现场生成的 HTML/JS 直接糊上去。对比 Intelligent UI 那种"原生组件库加专用编译器保流式体验"的路线，狂野方案灵活但质量不可控。工程上的折中判断：交互模板固定、数据多变的场景走预设 UI；探索性、一次性的可视化走现场生成。
为什么它此前不温不火
场景决定的：适合做成高度交互 App 形态的，要么是企业内部复杂业务流，要么是重交互的 B2C 应用（电商、地图、外卖），纯个人使用场景相对较少。大厂强行重塑用户习惯后，这个窗口正在打开。落地建议按风险递进：先用预设 UI 替换纯文本报表（收益确定、风险最低），再评估现场生成（收益大但需要渲染安全审查——模型生成的 HTML 直接执行，脚本注入面必须先封住）。
评论0