支付宝做阿宝，为什么通信协议没选RTC而是MoQ？

支付宝为什么要做一个叫“阿宝”的AI入口？蚂蚁集团客户端团队给出的答案，藏在四个技术领域里。

蚂蚁集团支付宝AI端云交互负责人魏凤笛在AICon全球人工智能开发与应用大会2026深圳站上，系统介绍了支撑阿宝的xUI技术体系。这套体系覆盖全双工多模态通信、生成式渲染交互、服务执行技术以及多Agent生态协同四个核心方向。

阿宝的定位不是单纯的聊天机器人。按魏凤笛的说法，它是战略入口、业务服务海量供给、多端开放生态的组合。支付宝要把支付、生活、政务服务等供给，以对话和Agent执行的方式提供给用户。

移动端Agent走过的三个阶段

魏凤笛把移动端Agent应用场景的演进划成了几个阶段。最初模型只能做基础聊天和信息查询，背后依赖搜索工具的简单调用。随后是持续的上下文对话和内容生成，各种工具被组合进对话流，催生了大量聊天机器人产品。

再往后，大模型开始通过Agent方式把事务从头到尾办完，在编码、深度研究以及一些垂直任务领域逐步发力。围绕大模型Agent的工程方法也在持续演进，RAG、Prompt、MCP、Multi-Agent这些能力不断重塑移动端应用的产品形态。

当前几家大厂向Agent方向发展的路径，被他归纳为几种类型：

• 一类以聊天问答和灵感陪伴为起点，逐步走向办事，在自有模型和业务之外引入三方MCP服务，在对话中帮用户完成任务；
• 一类坚持垂类路线，比如阿福和灵光，不追求超级入口，持续强化自身领域内的供给，如挂号、知识、聊天、买药，整体偏内敛，开放性相对较低；
• 还有一类是系统级智能体，做系统层能力的平台化，通过智能体框架加意图路由，与系统中安装的各类APP协同，完成跨应用任务。

支付宝把自己定位为一个整体的服务入口。思考框架分两层：一层是如何把用户意图从外部引入支付宝；另一层是支付宝内部产生的服务意图，如何把开放平台上的各种服务、小程序、政府服务、生活服务等供给，整体转化为AI化的服务提供给用户。

启动阿宝之前，已经试过很多次

在启动阿宝之前，团队已经做过不少尝试。前两年在搜索、出行、政务等垂类场景中，以对话类Agent方式把每个垂类场景的服务供给做了转化，以对话形式给出知识回答，并把用户对应的服务诉求提取出来，引导用户使用服务。

与此同时，支付宝作为支付工具，也在其他Agent智能体中逐步开展生态合作，包括把小程序放进车机、把支付能力开放出去。这些工作让支付宝逐渐体现出一种Agent的形态。

阿宝要解决的问题被抽象成四个领域：通信，如何让人和Agent持续高效地通信；在通信之上，如何与Agent高效友好地交互并完成服务；音视频多模态交互方式；端上能力和服务如何被Agent调用并执行。这些技术栈横跨端和云，还要考虑与其他多端厂商Agent的协同效果。

从单次请求到全双工，通信链路必须换

AI对话出现之前，客户端上的请求模式通常是一次性发起请求、拿到结果，属于单次请求交互。即使有推送或同步消息，本质上仍然是单次行为。

引入AI之后，Agent生成内容是持续的。用户对Agent说一句话，它就会持续返回内容，因此必须采用流式通信方式。对话过程中用户可以随时改变想法、补充新要求，这进一步要求通信链路具备全双工能力。

到了需要Agent帮用户办事的阶段，无论是操作屏幕、查看当前界面，还是读取摄像头信息并给出数字化反馈，都需要多模态全双工流式能力，才能支撑云端Agent实时感知语音、视频和屏幕，再通过推理表达、工具调用或用户确认来完成任务。

早期做文本对话时，主要强调文本内容的高效流式传输，一些简单的数据对话基于gRPC等双工数据通道可以满足需求。但当场景变复杂，尤其是音视频联合再加上数字人之后，问题就不再简单。

此前团队采用RTC方式，并联合其他数据通道一起工作，但暴露了几个明显不足：

• RTC链路本质上是面向人与人交互设计的，必须建立房间，建连时间较长；
• 它的扩展性主要围绕语音和视频本身，对其他模态的扩展比较困难；
• 要把多模态融合进去做统一控制也不灵活。

MoQ协议提供了一种面向人和Agent交互的新思路。它是面向客户端与Agent之间通信设计的协议，能够把所有模态进行复用，通过标准的人和Agent交互协同方式，原生支持打断等行为，从而更好地融合多模态体验。MoQ的链路、模态扩充能力和信息灵活性都非常强。

因此，整个网络通信协议以MoQ为基础，配合RTC和多种其他通信方式，整体解决人和Agent交互中的通信问题。这一选型既保留了RTC在特定场景下的成熟能力，又通过MoQ获得了更灵活的多模态扩展空间。

交互表达的三个阶段

交互表达层面同样经历了清晰的阶段演进。第一个阶段是早期AI问答，用户提问后模型返回大量文字信息。当时Markdown比较流行，因为大模型对Markdown格式掌握得较好，输出本身就是Markdown形式。

这个阶段主要考虑的是如何让输出有AI感，能够随时输出随时展示，并附带一些流式交互效果。为了实现这一目标，团队基于Markdown做了三端原生渲染。选择原生渲染而不是为Markdown引入浏览器引擎，是因为前端渲染虽然实现简单，但工程成本较高且稳定性较差。原生渲染能够更好地支持三端标准协议，并保证AI交互效果。

第二个阶段，大模型能力变得越来越强，可以生成复杂的前端代码。除了文本看板之外，可以嵌入很多表现力丰富的内容。业务方看到这种能力后，开始在对话中表达复杂内容，包括图表类、信息分析类、知识类内容，都希望融合进去。这就必须引入前端浏览器技术。

核心问题随之变成性能、可靠性和稳定性，以及各种动画效果。为此团队采用了自研Web内核，对MY Web和WKWebView都做了深度优化，使得在原生对话界面中能够嵌入Web区块，同时保持非常高的体验水平。这一阶段的关键是把复杂HTML生成能力与原生容器深度结合。

第三个阶段，团队希望在对话里真正帮用户把事办掉。前两个阶段更偏向表达和简单的用户操作，可以让用户进行二次展开探索，但无法完成事务。

四个方向拼出的xUI

回到xUI这套体系本身，通信、交互、多模态、服务执行四个方向并非孤立。通信层解决的是人和Agent之间持续、可打断、多模态的信息流动；交互层解决的是这些信息如何被友好地呈现和操作；多模态层处理音视频等更丰富的输入输出；服务执行层则负责让端上能力和服务真正被Agent调用起来。

魏凤笛在分享中还呈现了团队对异步任务与伴随式交互的远期判断。这套技术架构的演进逻辑、关键选型和工程实践，构成了阿宝背后的完整支撑。