“阿宝”背后的 Agentic 终端交互引擎

a0»01移动端 Agent的应用场景«a0

移动端应用正在全面走向 Agent 化。过去两年，支付宝在搜索、出行、政务等垂类场景中以对话 Agent 转化服务供给，并在其他 Agent 中开展生态合作，如把小程序放进车机、把支付能力开放出去，逐渐呈现出 Agent 的形态。

阿宝的定位，正是成为 Agent 的 AI 入口——不是单纯的聊天机器人，而是“AI 入口 + 业务服务海量供给 + 多端开放生态”的组合。支撑这一定位，涉及大量技术选型与工程架构问题。

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

a0»02支付宝的 Agentic终端实践«a0

在 AI 对话出现之前，客户端上的请求模式通常是一次性发起请求、拿到结果，属于单次请求交互。即使有推送或同步消息，本质上也仍然是单次行为。引入 AI 之后，Agent 生成内容是持续的，用户对 Agent 说一句话，它就会持续返回内容，因此必须采用流式通信方式。同时，在对话过程中用户可以随时改变想法，补充新的要求，这就进一步要求通信链路具备全双工能力。到了需要 Agent 帮用户办事的阶段，无论是操作屏幕、查看当前界面，还是读取摄像头信息并给出数字化反馈，都需要多模态全双工流式能力，才能支撑云端 Agent 实时感知语音、视频和屏幕，再通过推理表达、工具调用或用户确认来完成任务。

a0»03流式多模态实时传输技术跟 Agent 通信«a0

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

此前我们采用 RTC 方式，并联合其他数据通道一起工作，但暴露了几个明显不足：RTC 链路本质上是面向人与人交互设计的，必须建立房间，建连时间较长；它的扩展性主要围绕语音和视频本身，对其他模态的扩展比较困难，要把多模态融合进去做统一控制也不灵活。

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

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

a0»04生成式可交互 UI和 Agent 交互«a0

交互表达层面同样经历了清晰的阶段演进。

第一个阶段是早期 AI 问答，用户提问后模型返回大量文字信息。当时 Markdown 比较流行，因为大模型对 Markdown 格式掌握得较好，输出本身就是 Markdown 形式。

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

第二个阶段，大模型的能力变得越来越强，可以生成复杂的前端代码。对话中可嵌入的内容因此不再限于文本卡片，如果需要将图表类、信息分析类、知识类等复杂内容融入对话，这就必须引入浏览器渲染技术。我们需要解决的核心问题变成性能、可靠性与稳定性，以及各类动画效果的流畅呈现。

为此，我们采用自研 Web 内核 MYWeb，并对 MYWeb 与 WKWebView 双端做了深度优化，使原生对话界面中可以嵌入 Web 区块，同时保持非常高的体验水平。这一阶段的关键是把复杂 HTML 生成能力与原生容器深度结合。

前两个阶段更偏向表达和简单的用户操作，可以让用户进行二次展开探索，但无法完成事务。

第三个阶段，我们希望在对话里真正帮用户办事，让用户完成一项服务的端到端交互。为此我们引入了 A2UI —— 谷歌提出的 UI 交互方案。它的核心原则是：我们是为了完成一个服务而去设计交互，不希望模型生成页面本身，而是希望模型生成它要做什么事情，然后把“做什么事情”转化为 UI 表达，通过工程上的标准实现组合组件、操作协议和信息过程。组合完成之后，表达层和 Agent 层通过协议进行协作和解耦，最终帮用户完成服务。

在 A2UI 框架下，云端 Agent 通过理解用户意图生成完成事项的步骤，最后将这些步骤通过 MCP 或 Skill 翻译成阶段性的不同 UI 卡片交互形式，再由端上渲染，用户在这个过程中可以查看、确认、选择，最终完成整个服务。

这样我们就形成了三代渲染交互规范：流式 Markdown 解决流式效果和输出问题，以及原生渲染的性能提升；流式 HTML 渲染解决复杂表达、复杂交互和稳定可靠的工程实现；声明式 UI 渲染与 A2UI 协议结合，并连接背后的 MCP 供给，解决用户在对话里真正办事的问题。三个阶段分别对应从表达、到复杂表达、再到完整事务闭环的递进关系。

a0»05音视频通话技术和 Agent 交互«a0

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

整体架构可以分成几层。最上层是业务层，各个业务都可以使用这套多模态能力。业务层之下是标准 SDK，负责交互控制、生成渲染和会话管理。

针对多模态这一核心能力，我们又细分出三层：第一层是与媒体相关的事情，包括状态管理、会话管理、媒体采集播放、硬件算法、生产量优化等，这些能力本身相关的内容放在上层；中间设置网络抽象层，把媒体信息和网络通道传输解耦，隔离开两者的依赖关系；最底层以 MOQ 为主、RTC 为备份、gRPC 为兜底，通过这三种方式使整体传输效率保持在较高水平。

这套分层无论是建连耗时、体感可用耗时，还是入网卡顿率，都获得了非常明显的提升。

这里的关键设计在于网络抽象层的引入。原本媒体采集播放、编码算法与网络传输耦合较深，引入抽象层后，上层媒体能力可以独立演进，底层网络协议替换或降级不会影响业务体验。

例如在弱网环境下，通过 gRPC 兜底可以保证基础文本交互依然可用；强网环境下优先使用 MOQ 实现完整多模态体验。这种分层为后续不同终端设备、不同网络条件下的适配留下了空间。同时，标准 SDK 的存在让不同业务可以快速接入，而不需要各自重复实现复杂的会话管理和媒体控制逻辑。

a0»06终端 MCP、UI Agent 执行技术使 Agent 办事儿«a0

A2UI 方案能够解决背后有真实 MCP 和 API 供给的服务场景，比如打车、买咖啡这类可以抽象 MCP 接口和 Skill 的服务，直接调用供应商能力即可完成，但并非所有服务都能通过这种方式提供。

在服务无法提供标准 MCP 时，如何帮用户把事情办掉？我们的方案是以 GUI Agent 驱动感知执行实现的。我们把模型对 UI 点击的操作意图转化成可执行的动作，具体做法包括融合终端内多个技术栈，通过布局树分解合并、采集、点击检测等手段，在没有系统能力的情况下，在应用内部模拟出相当于系统点击操作的权限，从而支撑 GUI 执行。

除了 GUI 方式，页面结构本身可以被描述为结构化信息。我们把一个页面上有哪些功能、在什么位置，用文字结构化表达给大模型，大模型不依赖视觉和绝对坐标，只需要通过文本方式理解页面服务，然后告诉我们要去点击那个结构化位置，这种方式是 TUI 方式。

GUI 的泛化性较高，整个过程都可以通过通用 GUI 模型持续迭代优化。TUI 受限于页面结构化表达的设计，泛化性略低一些，但执行速度更快，也避免了复杂视觉推理的开销。

第三种方式是无模型推理的执行方式，主要针对固定场景和固定动线。比如搜索某个固定对象、执行某些标准流程，这些场景基本不会变化，不需要模型参与推理。我们只需基于前两种操作能力组合一个 Workflow 或脚本，当用户意图匹配到该脚本时直接运行。这种方式执行速度最快，但泛化性最低，维护成本来源于业务表达逻辑的变化。

无论采用哪种执行方式，都需要一套标准的管理机制。

首先，端上需要明确哪些能力有供给，例如标准 GUI 操作能力如何调用，每个场景可提供的 Workflow 和脚本如何被 Agent 发现。Agent 需要在场景中发现这些工具，然后执行采集、调用等操作。整个调用过程必须包含鉴权和授权控制，不能让 Agent 乱调用。

实际执行中，成功率是非常关键的指标。做 GUI 执行不能只做到百分之七八十的成功率，必须达到百分之九十以上，才能真正帮用户把事情办完。端云协同中，用户界面随时可能发生变化，我们的做法是在用户操作过程中，不让用户点击界面，否则可能产生意料之外的情况。在执行采集和执行之前，必须做一次明确校验，确认页面稳定，确认模型推理后准备点击的目标仍然还在原位置，这样整个执行过程的错误率才能保持低水平。如果不做校验，模型就会乱点，上下文和操作过程随之变得异常复杂，体验会急剧变差。

云端则根据端上的各种状态和调用做工具选择，负责任务规则和状态管理，整体通过 MCP 完成调度。算法层面也需要大量投入。市面上的通用 GUI 模型对支付宝、政务类以及地方类布局的理解并不深入。我们需要迭代模型对海量小程序的理解能力，为此必须定义如何描述这些服务，完成高质量标注，再训练到合适的模型规模，同时保证推理速度足够快，使得每一步操作都顺畅。这里需要构建算法创新闭环和飞轮，让数据和服务场景持续反哺模型，寻求长期泛化性。

从整体策略看，固定场景、固定动线直接执行；复杂场景用 GUI 方式支持；简单场景如果可以通过结构化数据理解，就用 TUI 方式做。根据不同场景选择不同执行方式，把整个执行扩展推进下去。背后最关键的是拥有自己的执行能力，以及算法上的持续模型建设。

a0»07AHA Agent 互联技术多 Agent 协同«a0

用户意图不一定发生在支付宝内部。很多意图分布在各个场景中，如何把这些意图引入支付宝，同时把我们的服务供给对外输出，是另一个关键问题。

手机自带的系统助手可以随时陪用户聊天，却无法包办所有事情 —— 大量服务意图就分布在各个 App 之中，这就需要系统 Agent 与应用侧的 Agent 协同。

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

在多主体 Agent 互联互通中，我们通过意图来区分合作关系。意图可能发生在终端系统，也可能发生在支付宝内部；两者的关系是围绕意图进行服务分发。如果意图发生在手机助手中，助手根据意图找到背后对应的另一个主体的 Agent 服务，然后唤起该 Agent，把意图交付过去，由后者在自己的领域内闭环完成。

这种方式可以避免手机厂商直接操作支付宝，或支付宝突破权限调用系统能力带来的边界性、安全性和合规性问题。职责分工明确：系统助手负责理解意图，我们提供执行能力本身和服务供给。

厂商合作还能带来两个额外增益：一是能让我们在后台自己完成一些任务，从系统助手出发后，支付宝可以在后台把任务干完再通知用户，具备异步完成任务能力；二是系统助手具备的系统级能力比我们自己在客户端内模拟的方式更标准，错误率更低。这两点优势叠加起来，就形成了一个完整的多 Agent 互联互通方案。

a0»08Agentic 终端的发展展望«a0

前面几个方面分别解决了通信、交互、执行和协同问题，把支付宝的服务和能力以 Agent 方式提供给用户，但还有一些能力值得继续探索。

以异步执行为例：知识查询类与服务触发类任务已经可以异步完成；而在支付宝内，涉及 GUI 操作的服务执行类任务，目前仍需要用户盯着 Agent 一步步完成 —— 能否通过端云协同，让这类任务也异步执行，正是我们在探索的重要方向。

更进一步，目前用户要么在阿宝中发起对话，要么通过系统 Agent 触发；有没有可能让用户在支付宝的任意场景中，随时与阿宝对话 —— 它实时理解当前场景，给出可感知的响应与帮助，形成伴随式的交互形态？

此外，除手机之外，阿宝本身会与手表、眼镜以及各类支付设备交互——我们的服务供给能否延伸到这些场景，同样是未来的重要方向。

云端执行方面，一个值得关注的方向是部署沙箱环境：沙箱中可以运行 MCP、OpenClaw，那么能否直接运行小程序服务本身？如果可以，我们就能在云端帮用户直接完成服务，把结果返回端上，支持更长时间的异步任务。

伴随式体验是另一个重点：我们希望支付宝与阿宝的服务随时可用、随处可用——这意味着必须从“人找服务”向“服务找人”转变，让阿宝无处不在。围绕这一目标，终端在异步任务、任务协同与语音交互上的持续增强，端云在多设备、多场景上下文管理上的能力建设，以及云沙箱对小程序服务的直接执行，将共同构成下一阶段的演进路径。