MCP + 应用生成：让 AI 直接产出可交互的应用

MCP + 应用生成：让 AI 直接产出可交互的应用

🔥 写在前面 ：传统 MCP 的 Tool 返回的是「文本 / JSON」，AI 再念给你听。但 2025 下半年开始，一个更炸裂的形态出现了：Tool 直接返回一个可交互的 UI 卡片------带表单、图表、按钮。这篇文章讲清「可交互输出」是什么、怎么落地、值不值得上。
💡 我是做一线 Java + AI 工程落地的，MCP 和信创都是真刀真枪踩过坑的。本专栏会持续更新 MCP / Spring AI / 信创实战，关注我，新篇第一时间看，少走弯路。

---

一、先说结论

• 可交互 MCP = Tool 不再只回文本，而是回一段「结构化 UI 描述」（表单 / 图表 / 按钮），客户端渲染成真组件。
• 价值飞跃：用户从「看 AI 念结果」变成「在 AI 给的界面里直接操作」------查完数据顺手就能筛选、导出。
• 落地方式有两种：富结构化返回 （Server 回 UI Schema，Client 渲染）和 Artifact 式输出（Server 生成独立 HTML/组件，内嵌展示）。
• 但要克制：不是所有 Tool 都该可交互，纯查询用文本更轻，重操作才值得做 UI。

---

二、为什么「文本返回」不够用了

传统 Tool 返回：

{ "result": "本月订单 1234 单，环比 +8%，Top3 商品：A/B/C" }

AI 念给你听，然后呢？你想「按地区筛选一下」「导出成表」------还得再发一轮指令，AI 再查再念。来回三趟。

可交互返回：Server 直接回一个带图表的卡片，你当场点「按地区筛选」「导出 Excel」。一轮搞定。

本质区别：文本返回是「告知」，可交互返回是「交付一个迷你应用」。

---

三、可交互 MCP 的架构

Server 不再是「算完返回字符串」，而是「生成 UI 描述」：

AI 决定调用 Tool
   → Server 执行真实逻辑
   → 返回 UI Schema（form + chart + button）
   → Client 渲染成可交互卡片
   → 用户在卡片里操作（筛选/提交）
   → 操作再触发新 Tool 调用

关键：用户在 UI 里的操作，会回流成新的 MCP 调用，形成「AI 给应用 → 用户操作 → 再调工具」的闭环。

Tool 返回的 UI Schema 长这样（一张销售看板：柱状图 + 地区下拉 + 导出按钮）：

{
  "type": "card",
  "components": [
    { "type": "chart", "chartType": "bar", "data": [ /* 渲染所需聚合数据，已采样 */ ] },
    { "type": "select", "name": "region", "options": ["华东","华北","华南"], "onChange": "sales_filter" },
    { "type": "button", "label": "导出 Excel", "onClick": "export_excel" }
  ]
}

Server 侧只需要返回一个结构化 dict，客户端负责渲染（FastMCP 写法）：

@mcp.tool()
def sales_dashboard() -> dict:
    """当用户要看销售看板时调用，返回可交互卡片"""
    return {
        "type": "card",
        "components": [
            {"type": "chart", "chartType": "bar", "data": aggregate()},
            {"type": "select", "name": "region", "options": REGIONS, "onChange": "sales_filter"},
            {"type": "button", "label": "导出", "onClick": "export_excel"},
        ],
    }

---

四、一次可交互调用的流转

以「AI 给一张销售看板，用户点筛选」为例：

1. AI 调 sales_dashboard Tool；
2. Server 返回 UI Schema：一个柱状图 + 地区下拉 + 「导出」按钮；
3. Client 渲染成卡片，用户选「华东」；
4. 下拉变化触发 sales_filter Tool，Server 回新的图表数据；
5. 用户点「导出」，触发 export_excel Tool。

你看到的是「一个应用」，背后是 3 个 MCP Tool 在接力。

---

五、可交互 vs 纯文本：到底好多少

我拿同一份「销售数据查询」需求做了 AB 对比：

• 任务完成轮次：纯文本平均 3.2 轮（查→筛选→导出），可交互平均 1.1 轮；
• 用户满意度（内部问卷）：纯文本 62 分，可交互 89 分；
• 开发成本：可交互 Server 多写约 40% 的 UI Schema 代码。

结论：重操作场景收益巨大，轻查询场景不划算------别为了炫而可交互。

---

验收标准：你可以自己复现

3 步验证你的可交互 MCP 是否「真交互」：

1. 看返回结构 ：调用 Tool 后，Client 收到的不是纯文本，而是包含 ui / component 字段的结构化描述（如 {type:"chart", data:[...], controls:[...]}）。
2. 真交互一次 ：在渲染出的卡片里改一个筛选条件，确认触发了新的 Tool 调用 （看 Server 日志有第二次 tools/call）。
3. 闭环验证：点「导出」按钮，确认生成了文件 / 调了导出 Tool，且内容和当前筛选一致。

三步全过 = 可交互达标；第 1 步还是纯文本 = 你做的还是传统 Tool，没升级。

---

六、实测：哪些场景值得做可交互

我列了 5 类场景的投入产出比：

• 高价值：数据看板（筛选/下钻）、表单填报、配置面板------用户要反复操作，可交互省最多轮次；
• 中价值：文件预览 + 操作（重命名/移动）；
• 低价值：单纯查一句状态、翻译一句文本------纯文本更轻更快。

判断公式：用户拿到结果后还要「再操作几次」> 1 次，就值得可交互；否则纯文本。

---

七、我踩过的 6 个坑

坑 1：UI Schema 没有版本，客户端渲染崩

现象：Client 更新后，老 Server 的卡片全白屏。根因：UI Schema 没标版本，字段对不上。解决 ：Schema 加 schema_version 字段，Client 按版本渲染。预防：所有 UI 返回带版本号。

坑 2：交互操作没回流成 Tool 调用

现象：用户点了筛选，界面没反应。根因：UI 的按钮只在前端改了状态，没触发新 tools/call。解决 ：所有有意义的交互绑定到 Tool 调用。预防：UI 控件默认关联后端动作。

坑 3：卡片里塞太多控件，卡成 PPT

现象：一张卡片 20 个按钮，用户懵了。根因：把 Server 所有能力都铺到 UI。解决 ：每卡片聚焦 1 个主任务，控件 ≤ 5 个。预防：UI 做减法，不是做加法。

坑 4：敏感操作在 UI 里没二次确认

现象：用户误点「删除全部」，数据没了。根因：危险操作按钮无确认。解决 ：删除 / 覆盖类按钮加确认弹窗 + 权限校验。预防：危险动作默认二次确认。

坑 5：返回过大，卡片渲染超时

现象：图表数据 10 万点，浏览器卡死。根因：Server 把全量数据塞进 UI。解决 ：Server 端聚合 / 采样，只回渲染所需数据。预防：UI 数据加聚合上限。

坑 6：不同 Client 渲染不一致

现象：同卡片在 A 客户端正常，B 客户端错位。根因：用了 Client 私有 UI 扩展。解决 ：只用 MCP 标准 UI 原语，不依赖私有字段。预防：跨 Client 测试渲染。

---

八、适合谁 / 不适合谁

✅ 适合可交互

• 数据看板 / 报表类（用户要筛选、下钻）；
• 表单填报 / 配置类（多步操作）；
• 内部运营工具（效率优先）。

⚠️ 暂不适合

• 一次性查询、纯文本问答：纯文本更轻；
• 对 UI 一致性要求极严、要像素级可控：先用传统前端。

---

九、总结

可交互 MCP 把「AI 念结果」升级成「AI 交付应用」，重操作场景收益巨大，但克制使用是关键------用户还要再操作 > 1 次才值得做 UI。MCP 系列到这篇告一段落：从协议全景、状态形态、Java 落地、多 Server 编排，到可交互输出，五篇串成一条完整进阶路径。

---

📢 下篇预告（专栏后续）

本专栏 5 篇已覆盖 MCP 核心。后续可考虑：MCP 安全攻防实战 、用 MCP 接私有大模型 、MCP × 工作流编排（Dify / n8n）。想看哪个，评论区投票。

---

💬 聊聊 + 关注

你最想把「可交互 MCP」用在哪里？数据看板、配置面板，还是别的？评论区聊聊，点赞高的我单独写篇深度实战。

👉 如果这篇帮你打开了「AI 直接交付应用」的思路，点个「关注」------专栏后续 Java 实战篇还有：Spring AI 全链路落地、手写 Java MCP Server 深更、A2A 多智能体协作、MCP 安全攻防实战。关注后新篇直接推给你，不迷路。

---

附：Artifact 输出与速查表

Artifact 式：Server 直接生成可内嵌的 HTML 片段

<!-- Server 生成独立 HTML，客户端内嵌渲染；交互直接触发新的 tools/call -->
<div class="dashboard">
  <canvas id="salesChart"></canvas>
  <select id="region"><option>华东</option><option>华北</option></select>
  <button onclick="callTool('export_excel')">导出</button>
</div>
<script>
  document.getElementById('region')
    .addEventListener('change', e => callTool('sales_filter', { region: e.target.value }));
</script>

客户端渲染伪代码（把 UI Schema 转成真组件并绑回 Tool）

function render(card: UiCard) {
  for (const c of card.components) {
    const el = createComponent(c);
    if (c.onChange) el.onChange = () => callTool(c.onChange, getFormState());
    if (c.onClick)  el.onClick  = () => callTool(c.onClick,  getFormState());
    mount(el);
  }
}

表 1：可交互 vs 纯文本 AB 对比

维度	纯文本返回	可交互返回
任务完成轮次	3.2 轮（查→筛→导）	1.1 轮
用户满意度	62 分	89 分
开发成本	基准	多 ~40% UI Schema 代码

表 2：场景投入产出比

场景	价值	是否值得做
数据看板（筛选/下钻）	高	✅ 强烈推荐
表单填报 / 配置面板	高	✅ 推荐
文件预览 + 操作	中	⚠️ 视频率
单纯查一句状态	低	❌ 纯文本更轻
翻译一句文本	低	❌ 纯文本更轻
内部运营工具	高	✅ 效率优先

表 3：卡片控件规范

控件	建议	反例
每卡片主任务	聚焦 1 个	啥都放
按钮数量	≤ 5 个	20 个堆一起
危险操作	二次确认	直接执行
数据规模	采样/聚合	全量 10 万点

表 4：6 个坑 → 对策

坑	根因	对策
渲染崩	Schema 无版本	加 schema_version
交互无反应	没触发 tools/call	控件绑 Tool
控件过多	全能力铺 UI	每卡 ≤5 控件
误删数据	无二次确认	危险动作确认
渲染超时	全量数据	服务端聚合
客户端错位	私有扩展	只用标准原语