支付宝“阿宝”背后的 Agentic 终端：从对话到办事，xUI 如何重构 AI 交互

蚂蚁集团客户端团队在移动端 AI 应用方向上的技术探索，正随着大模型与 Agent 技术的成熟逐步走向系统化。围绕国民级超级应用支付宝，团队推出了面向 AI 的入口产品“阿宝”，尝试把支付、生活、政务服务等海量供给以对话和 Agent 执行的方式提供给用户。

本文整理自蚂蚁集团支付宝 AI 端云交互负责人魏凤笛在 AICon 全球人工智能开发与应用大会 2026 深圳站的分享《支付宝 xUI -- “阿宝”背后的 Agentic 终端交互引擎》。他系统介绍了支撑阿宝的 xUI 技术体系，覆盖全双工多模态通信、生成式渲染交互、服务执行技术以及多 Agent 生态协同四个核心方向，完整梳理这套技术架构的演进逻辑、关键选型和工程实践，并在此基础上呈现团队对异步任务与伴随式交互的远期判断。

以下是演讲实录（经 InfoQ 进行不改变原意的编辑整理）。

移动端 Agent 应用场景的演进，可以大致划分为几个阶段。最初模型只能完成基础的聊天和信息类查询，背后往往依赖搜索工具的简单调用。随后出现了持续的上下文对话和内容生成能力，各种工具被组合到对话流中，由此催生了大量聊天机器人产品。再往后，大模型开始通过 Agent 方式把事务从头到尾完整办完，在编码、深度研究以及一些垂直任务领域逐步发力。这一过程中，围绕大模型 Agent 的工程方法也在持续演进，包括 RAG、Prompt、MCP、Multi-Agent 等能力，这些都在不断重塑移动端应用的产品形态。

在各大移动端场景中，互联网业务自身的场景最先以 Agent 方式落地。搜索类应用向 AI 对话与 AI 搜索方向演进，通过更清晰的内容供给激发用户灵感。娱乐类应用则大量生成放生图、表情，提供陪伴聊天等体验。垂直领域中的购物、医疗、办公等场景，会把自己的运营做深，训练自有模型，构建自有供给，把 AI 带来的服务变化直接传递给用户。当前几家大厂在不同领域向 Agent 方向发展的路径，可以归纳为几种类型：一类以聊天问答和灵感陪伴为起点，逐步走向办事，在自有模型和业务之外引入三方 MCP 服务，在对话中帮助用户完成任务；另一类坚持垂类路线，比如阿福和灵光，不追求超级入口，而是持续强化自身领域内的供给，如挂号、知识、聊天、买药等，整体偏内敛，开放性相对较低；还有一类系统级智能体，做系统层能力的平台化，通过智能体框架加上意图路由，与系统中安装的各类 APP 协同，为用户完成跨应用任务。

支付宝作为国民级超级 APP，我们把它定位为一个整体的服务入口。思考框架分两层：一层是如何把用户的意图从外部引入支付宝；另一层是支付宝内部产生的服务意图，如何把开放平台上的各种服务、小程序、政府服务、生活服务等供给，整体转化为 AI 化的服务提供给用户。在启动阿宝之前，团队已经做过很多尝试。前两年我们在搜索、出行、政务等垂类场景中，以对话类 Agent 方式把每个垂类场景的服务供给做了转化，以对话形式给出知识回答，并把用户对应的服务诉求提取出来，引导用户使用服务。与此同时，支付宝作为支付工具，也在其他 Agent 智能体中逐步开展生态合作，包括把小程序放进车机、把支付能力开放出去等。这些工作让支付宝逐渐体现出一种 Agent 的形态。

阿宝的定位，就是成为一个 Agent 的 AI 入口。它不是单纯的聊天机器人，而是战略入口加业务服务海量供给加多端开放生态的组合。这一目标背后，涉及大量技术选型和工程架构问题。我把这些问题抽象为四个领域：一是通信，如何让人和 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 生成能力与原生容器深度结合。

第三个阶段，我们希望在对话里真正帮用户把事办掉。前两个阶段更偏向表达和简单的用户操作，可以让用户进行二次展开探索，但无法完成事务。第三阶段要解决的是如何让用户在对话中完成一个背后服务的完整交互。这里基于 A2UI 概念来实现，A2UI 是谷歌输出的 UI 交互方案。它的核心原则是：我们是为了完成一个服务而去设计交互，不希望模型生成页面本身，而是希望模型生成它要做什么事情，然后把“做什么事情”转化为 UI 表达，通过工程上的标准实现组合组件、操作协议和信息过程。组合完成之后，表达层和 Agent 层通过协议进行协作和解耦，最终帮用户完成服务。

在 A2UI 框架下，云端 Agent 通过理解用户意图生成完成事项的步骤，最后将这些步骤可能通过 MCP 或 Skill 翻译成阶段性的不同 UI 卡片交互形式，再由端上渲染，用户在这个过程中可以查看、确认、选择，最终完成整个服务。这样一来，我们形成了三代渲染交互规范：流式 Markdown 解决流式效果和输出问题，以及原生渲染的性能提升；流式 HTML 渲染解决复杂表达、复杂交互和稳定可靠的工程实现；声明式 UI 渲染与 A2UI 协议结合，并连接背后的 MCP 供给，解决用户在对话里真正办事的问题。三个阶段分别对应从表达、到复杂表达、再到完整事务闭环的递进关系。

除文本对话外，用户还存在语音和多模态交互需求。第一阶段是解决用语音跟 Agent 聊天的问题，最初的做法是通过语音流式上传给语音识别模块，识别转写为文本后再交给 Agent，Agent 回答后再通过 TTS 播报。这种方式需要经过一次转换节点，问和答两个阶段被分开，体验上并不好。因此我们后续转向实时回答：语音上去之后直接实时理解成文本，实时交给 Agent 流式推理，结果也实时做 TTS 播报，形成全双工形式。再往后，用户还希望有表情和更丰富的多模态表达，比如上传图片、实时采集视频、做实时数字人。于是我们把更多模态融合到多模态实时链路中，进行协同和双工连续协同，并且支持打断等行为。结合前面通信网络的演进，这些能力共同构成了一个体验较好的多模态交互体系。

整体架构可以分成几层。最上层是业务层，各个业务都可以使用这套多模态能力。业务层之下是标准 SDK，负责交互控制、生成渲染和会话管理。针对多模态这一核心能力，我们又细分出几层：第一层是与媒体相关的事情，包括状态管理、会话管理、媒体采集播放、硬件算法、生产量优化等，这些能力本身相关的内容放在上层。中间设置网络抽象层，把媒体信息和网络通道传输解耦，隔离开两者的依赖关系。最底层以 MOQ 为主、RTC 为备份、gRPC 为兜底，通过这三种方式使整体传输效率保持在较高水平。这套分层做完之后，无论是建连耗时、体感可用耗时，还是入网卡顿率，都获得了非常明显的提升。

这里的关键设计在于网络抽象层的引入。原本媒体采集播放、编码算法与网络传输耦合较深，引入抽象层后，上层媒体能力可以独立演进，底层网络协议替换或降级不会影响业务体验。例如在弱网环境下，通过 gRPC 兜底可以保证基础文本交互依然可用；强网环境下优先使用 MOQ 实现完整多模态体验。这种分层为后续不同终端设备、不同网络条件下的适配留下了空间。同时，标准 SDK 的存在让不同业务可以快速接入，而不需要各自重复实现复杂的会话管理和媒体控制逻辑。

A2UI 方案能够解决背后有真实 MCP 和 API 供给的服务场景，比如打车、买咖啡这类可以抽象 MCP 接口和 Skill 的服务，直接调用供应商能力即可完成，但并非所有服务都能通过这种方式提供。支付宝内有大量小程序，并不是所有服务方都有能力或意愿提供标准 MCP。比如蚂蚁庄园里领饲料，或者去政务场景办一件事，政府不会提供 MCP 给我们。这种情况下，我们就需要自己找到一种方式，把服务直接帮用户完成。用户只需要说“我要办什么”，系统就可以替用户进入页面完成点击操作。对用户来说，很多服务第一次使用本身就很难找到入口，执行代理能够帮助一部分用户解决问题。

背后的问题就变成：在业务服务无法提供标准 MCP 时，如何帮用户把事情办掉。我们的方案是以 GUI Agent 驱动感知执行实现的。一个典型的参照案例是豆包手机。豆包手机通过系统级权限采集用户屏幕，并利用系统能力直接操作界面。但在一个客户端内部做同样的事情，无法依赖系统级权限，必须靠自己的技术栈突破。我们通过终端技术栈实现，把模型对 UI 点击的操作意图转化成可执行的动作。具体做法包括融合终端内多个技术栈，通过布局树分解合并、采集、点击检测等手段，在没有系统能力的情况下，在应用内部模拟出相当于系统点击操作的权限，从而支撑 GUI 执行。

除了 GUI 方式，页面结构本身可以被描述为结构化信息。我们把一个页面上有哪些功能、在什么位置，用文字结构化表达给大模型，大模型不依赖视觉和绝对坐标，只需要通过文本方式理解页面服务，然后告诉我们要去点击那个结构化位置，这种方式是 TUI 方式。GUI 的泛化性较高，整个过程都可以通过通用 GUI 模型持续迭代优化。TUI 受限于页面结构化表达的设计，泛化性略低一些，但执行速度更快，也避免了复杂视觉推理的开销。第三种方式是无模型推理的执行方式，主要针对固定场景和固定动线。比如搜索某个固定对象、执行某些标准流程，这些场景基本不会变化，不需要模型参与推理。我们只需基于前两种操作能力组合一个 Workflow 或脚本，当用户意图匹配到该脚本时直接运行。这种方式执行速度最快，但泛化性最低，维护成本来源于业务表达逻辑的变化。

无论采用哪种执行方式，都需要一套标准的管理机制。首先，端上需要明确哪些能力有供给，例如标准 GUI 操作能力如何调用，每个场景可提供的 Workflow 和脚本如何被 Agent 发现。Agent 需要在场景中发现这些工具，然后执行采集、调用等操作。整个调用过程必须包含鉴权和授权控制，不能让 Agent 乱调用。实际执行中，成功率是非常关键的指标。做 GUI 执行不能只做到百分之七八十的成功率，必须达到百分之九十以上，才能真正帮用户把事情办完。端云协同中，用户界面随时可能发生变化，我们的做法是在用户操作过程中，不让用户点击界面，否则可能产生意料之外的情况。在执行采集和执行之前，必须做一次明确校验，确认页面稳定，确认模型推理后准备点击的目标仍然还在原位置，这样整个执行过程的错误率才能保持低水平。如果不做校验，模型就会乱点，上下文和操作过程随之变得异常复杂，体验会急剧变差。

云端则根据端上的各种状态和调用做工具选择，负责任务规则和状态管理，整体通过 MCP 完成调度。算法层面也需要大量投入。市面上的通用 GUI 模型对支付宝、政务类以及地方类布局的理解并不深入。我们需要迭代模型对海量小程序的理解能力，为此必须定义如何描述这些服务，完成高质量标注，再训练到合适的模型规模，同时保证推理速度足够快，使得每一步操作都顺畅。这里需要构建算法创新闭环和飞轮，让数据和服务场景持续反哺模型，寻求长期泛化性。从整体策略看，固定场景、固定动线直接执行掉；花哨复杂场景如蚂蚁森林、蚂蚁庄园，用 GUI 方式支持；出行等简单场景如果可以通过结构化数据理解，就用 TUI 方式做。根据不同场景选择不同执行方式，把整个执行扩展推进下去。背后最关键的是拥有自己的执行能力，以及算法上的持续模型建设。

用户意图不一定发生在支付宝内部。很多意图分布在各个场景中，如何把这些意图引入支付宝，同时把我们的服务供给对外输出，是另一个关键问题。举一个常见场景：用户手机上自带的智能体，可以跟它聊天说话，但那个智能体并不能把所有事情办掉，大量意图分布在各个 APP 中。例如用户想每天早晨醒来后，语音跟助手说“帮我领一下蚂蚁能量”，但不想打开支付宝，这件事怎么办？这就需要我们与厂商 Agent 进行协同。

我们和一个厂商合作的实际案例可以说明这一过程。用户从对话出发，说“能帮我买一张电影票吗？”系统助手理解意图后，把任务转交给支付宝，支付宝 Agent 在后台帮用户操作买票。此时用户不必盯着屏幕，可以去刷别的 APP 看与电影票相关的事情，也可以继续和助手聊其他话题。当后台任务完成后，助手会通知用户已经进入最后下单页面，并给出异步结果。类似的功能还包括收蚂蚁能量，用户可以通过对话触发，也可以通过语音触发，用户可以随时打断或取消。这些案例共同展现了跨应用 Agent 协作的实际体验。

在多主体 Agent 互联互通中，我们通过意图来区分合作关系。意图可能发生在终端系统，也可能发生在支付宝内部；两者的关系是围绕意图进行服务分发。如果意图发生在手机助手中，助手根据意图找到背后对应的另一个主体的 Agent 服务，然后唤起该 Agent，把意图交付过去，由后者在自己的领域内闭环完成。这种方式可以避免手机厂商直接操作支付宝，或支付宝突破权限调用系统能力带来的边界性、安全性和合规性问题。职责分工明确：系统助手负责理解意图，我们提供执行能力本身和服务供给。厂商合作还能带来两个额外增益：一是能让我们在后台自己完成一些任务，从系统助手出发后，支付宝可以在后台把任务干完再通知用户，具备异步完成任务能力；二是系统助手具备的系统级能力比我们自己在客户端内模拟的方式更标准，错误率更低。这两点优势叠加起来，就形成了一个完整的多 Agent 互联互通方案。

前面几个方面分别解决了通信、交互、执行和协同问题，把支付宝的服务和能力以 Agent 方式提供给用户，但还有一些能力值得继续探索。例如，在支付宝内部，用户目前仍需看着 Agent 完成点击操作；有没有可能通过技术突破或端云协同，让支付宝内的任务也能异步执行？知识查询类和服务触发类任务已经可以异步完成，但那些需要 GUI 操作的服务执行类任务是否能异步，是我们在探索的一个重要能力。进一步，现在用户要么在阿宝中对话触发，要么通过系统 Agent 对话触发；有没有可能在使用支付宝任意场景的过程中，用户都可以随时跟阿宝 Agent 对话，阿宝实时理解当前场景，给出可感知的响应和帮助，形成一种伴随式形态？此外，除了手机，阿宝本身会与手表、眼镜、各种支付设备产生交互。我们的服务供给能否在这些场景下被应用起来，也是未来发展方向。

围绕这些方向，我们正在通过端云协同方式解决异步任务和任务协同问题，并继续增强语音本身的能力。云上则涉及多设备、多场景的上下文协同、上下文延续和任务管理。对于云端执行，一个值得关注的方向是在云上放置沙箱环境。这个沙箱可以运行 MCP，也可以运行 OpenClaw，那么是否可能直接运行小程序服务本身？如果可以，我们就能在云端帮用户把服务本身直接完成，再把结果返回端上，从而支持更长时间的异步任务。另一个重点是把伴随式体验做好。我们希望支付宝的服务、阿宝的服务做到随时可用、随处可用、无所不能。这意味着必须从“人找服务”向“服务找人”转变，让阿宝无处不在、无所不知、无所不能。围绕这一目标，终端在异步任务、任务协同和语音交互上的持续增强，端云在多设备多场景上下文管理上的能力建设，以及云沙箱对小程序服务直接执行的探索，将共同构成下一阶段的演进路径。

会议推荐