卡片式对话的协议方案探索和思考

📌 一句话摘要

本文系统性地探讨了在智能助手对话流中实现卡片式交互的工程挑战，提出了包含 Markdown 标记、消息传输、UI 渲染及事件通信的四层统一协议体系，为构建标准化、可协作的卡片式对话系统提供了落地的架构参考。

📝 详细摘要

文章深入剖析了在 AI 智能助手对话流中嵌入可交互卡片所面临的系统性工程问题，并提出了从技术实现到团队协作的完整解决方案。文章围绕三个核心问题展开：1）卡片如何嵌入 Markdown 流，对比了代码块扩展、占位符替换和自定义标签三种方案的优劣及适用场景；2）卡片数据从何而来，分析了模型直出、增量 Patch 更新和 Tool 驱动三种数据获取模式的演进逻辑，并探讨了 MCP Apps 与 A2UI 等社区协议的设计哲学；3）多团队协作如何不乱，最终提出了一套四层统一协议体系，旨在通过标准化的 Markdown 标记、消息传输、UI 渲染和事件通信协议，解决 Agent 时代下多端一致性、数据实时性及跨团队协作混乱的问题。文章基于大淘宝技术的真实实践，提供了具体的代码示例、架构图和演进思考，具有很高的工程参考价值。

💡 主要观点

- 卡片嵌入对话流的核心是在不破坏 Markdown 流式解析的前提下嵌入 UI 语义，代码块扩展是稳健的实践方案。 通过复用 Markdown 代码块的 language 字段作为组件标识，将 JSON 数据置于代码体内，前端解析后渲染对应组件。该方案复用现有解析链路，兼容流式渲染，且通过 System Prompt 约束模型输出格式即可实现。

卡片数据应与 UI 解耦，Tool 驱动是架构最清晰的方案，将数据生产和 UI 描述的责任从模型转移至工具链。 模型直出数据不可靠，增量 Patch 存在体验断裂和工程复杂度问题。Tool 驱动方案（如 MCP Apps 或 A2UI）让 Agent 调用工具，工具直接返回结构化数据与 UI 描述，实现数据与 UI 一步到位，职责清晰。

为应对多团队协作，需要建立四层统一协议体系，从标记、传输、渲染到事件形成标准化约束。 四层协议包括：Markdown 标记协议（统一嵌入格式）、消息传输协议（定义流式数据包结构）、UI 渲染协议（采用如 A2UI 的声明式 JSON Schema）、事件通信协议（标准化交互动作）。该体系为复杂系统建立确定性，提升排查、复用和接入效率。

卡片式交互重新定义了 Agent 时代的前后端协作模式，前端演变为面向标准协议的渲染引擎。 模型角色转变为“界面规划师”，后端成为“协议协调者”，而前端则从定制化页面渲染器转变为面向标准 JSON Schema 的“协议执行引擎”，这要求前后端共同面向协议而非具体业务实现进行开发。

💬 文章金句

- 卡片式交互不是‘在聊天框里塞组件’这么简单。它重新定义了 Agent 时代的前后端协作方式。

• 四层协议体系（Markdown 标记 → 消息传输 → UI 渲染 → 事件通信）的价值，不在于技术有多先进，而在于为复杂系统建立了确定性。
• 核心方向是：把数据生产的责任从模型转移到工具链，让模型专注于意图理解和对话编排。
• 理解这两个协议（MCP Apps 和 A2UI）的关键在于看它们的驱动方式：MCP Apps 是工具驱动，A2UI 是 Agent 驱动。
• 模型从‘文本生成器’变成‘界面规划师’——它需要理解什么时候该展示卡片、展示什么类型的卡片。

📊 文章信息

AI 初评：92

来源：大淘宝技术

作者：大淘宝技术

分类：人工智能

语言：中文

阅读时间：35 分钟

字数：8659

标签： AI Agent, 卡片式对话, 协议设计, MCP, A2UI

阅读完整文章