阿寶背後的 Agentic 終端引擎

阿寶的產品定位：把支付寶能力變成 AI 入口

阿寶被定位為支付寶面向 AI 的入口，而非單純的聊天機器人。使用者可由支付寶入口進入，透過對話提出需求；其背後的產品命題，是把支付寶內既有的服務、小程式與開放服務供給，整理為 Agent 可調用的服務能力。換言之，對話只是入口，真正要完成的是「理解意圖—選擇服務—執行任務—取得確認」的服務閉環。

「我們想把阿寶打造成一個 agent 的一個 AI 入口。」
— 魏鳳笛

這個定位建立在三個組合上：Agent 的推理與循環能力、支付寶海量的業務服務供給，以及面向多端的開放生態。相較於只回答問題的聊天產品，阿寶要處理的是服務世界裡的具體任務；相較於只服務單一場景的垂直 Agent，它又必須面對服務類型多、入口分散、供給方不一的現實。

• 早期：以資訊檢索、問答為主，模型主要輸出文字。
• 中期：引入上下文、內容生成與工具組合，形成聊天機器人型產品。
• 進一步：Agent 能規劃並調用工具，在編碼、研究與垂直服務領域完成較完整的任務。
• 支付寶的方向：將站內服務 Agent 化，同時思考如何接住站外發生的使用者意圖。

互動演進：從一次請求到持續的多模態對話

傳統 App 請求多是「送出一次、回傳一次」：使用者操作後等待結果，系統再回應。Agent 對話則更像一通可以隨時插話的電話——使用者能持續補充條件、改變主意或中途打斷，Agent 也需要在過程中回傳推理、工具調用、展示內容與確認請求。因此，終端通訊必須從單次往返升級為持續串流。

當互動再加入語音、影像、螢幕或鏡頭資訊，以及即時語音回饋時，需求便進一步升級為全雙工、多模態的串流系統。這不只是傳輸更多資料，而是要讓不同模態能同步被理解、被控制，並支援打斷與切換，才能讓 Agent 依當下情境協助使用者完成任務。

串流通訊全雙工多模態即時打斷語音互動

傳輸底座：以 MoQ 解耦多模態互動

魏鳳笛指出，RTC 原本更偏向人對人的即時互動；當 Agent 互動要承載更多模態與控制需求時，擴展與整合會變得複雜。阿寶因此以 MoQ 為通訊協議主軸，並搭配 RTC 與其他傳輸方式。MoQ（Media over QUIC）是 IETF 正在開發的流媒體傳輸協議，目標是回應大規模、超低延遲的即時媒體傳輸需求；在此脈絡中，它的價值是將不同模態解耦，並提供更適合人與 Agent 互動的傳輸基礎。

整體設計採取多層備援：以 MoQ 為主、RTC 為備援、gRPC 兜底，並在終端建置阿寶抽象層，將媒體資訊與 Agent 傳輸解耦。這類架構像是為不同類型的貨物安排專屬車道，同時保留替代路線；目的不是追求單一協議，而是在建連、首屏與整體互動穩定性之間取得平衡。

UI 演進：從 Markdown 輸出走向可完成服務的 A2UI

Agent 能力升級後，互動介面也不能停留在「輸出一大段文字」。分享將對話 UI 的演進分為三層：先以流式 Markdown 呈現 AI 回答；再引入可嵌入 H5 區塊的流式頁面，以表達圖表與較複雜的內容；最後進入生成式 UI，讓 Agent 與使用者能在對話中共同完成服務流程。

第一層選擇原生 Markdown 渲染，是為了避免只為顯示 Markdown 而嵌入瀏覽器，並在多端維持較好的原生性能。面對圖表、互動卡片等更複雜的內容時，則透過輕量化的瀏覽器能力，在原生對話中嵌入 H5 區塊，同時處理性能、體積與穩定性問題。

第三層的關鍵是 A2UI。此方案不讓模型直接生成頁面本身，而是讓模型描述「要做什麼」，再由端上依協議與工程規範組合元件、操作與流程。這相當於把「決定要點什麼菜」與「廚房如何出餐」拆開：模型負責理解意圖與規劃，UI 層負責可靠地呈現及交互，使用者則能在關鍵節點查看與確認。

「不希望模型去生成頁面本身，而是希望模型去生成他要做什麼事情。」
— 魏鳳笛

端上執行方案：API 之外，還要補上服務覆蓋

若服務方已提供 MCP 介面、Skill 或 API，Agent 可以直接調用，例如出行、買咖啡、點餐等場景。然而支付寶內有大量小程式與服務，不是每一個都能立即提供標準化接口。要讓 Agent 的服務覆蓋不受限於 API 供給，阿寶還需要一套能在終端內操作既有服務的執行方案。

• A2UI＋MCP／API：適用於已有標準服務供給的場景，可直接完成服務調用。
• GUI Agent：由模型理解畫面與操作意圖，透過端內技術棧取得畫面、解析布局並執行點擊，泛化能力較高。
• TUI：以頁面的結構化描述將功能提供給模型理解與操作。TUI 可理解為 Text-based User Interface，以文字、方塊等符號表達選單、按鈕、表格或進度等介面；相較 GUI 泛化性較受結構設計限制，但執行速度可更快。
• Workflow／腳本：適合固定、少變化的任務動線，不必進行端雲模型推理，因此速度最快，但泛化性較低且需隨業務調整維護。

這三類執行方式不是互斥關係，而是依場景特性分工：固定動線可優先以腳本快速完成；出行、點單等可取得結構化資料的服務，適合以 TUI 類方式處理；面對高度變動或視覺脈絡複雜的頁面，則需要 GUI Agent。核心原則是以不同的可靠度、速度與泛化性，擴展 Agent 的實際辦事能力。

端雲協同的底線：可靠執行與授權控制

讓 Agent 代操作，難點不只是「能不能點」，而是「能不能可靠地點對」。分享明確指出，任務執行不能停在七、八成成功率，而需要超過九成的可靠程度，才適合協助使用者完成實際服務。這也使端雲協同成為必要條件：雲端提供理解與規劃，端上掌握頁面、狀態與操作時機，兩者共同維持任務正確性。

• 端上需提供標準化的 UI 操作、工具發現與調用機制。
• Agent 程序必須具備鑑權與授權控制，避免越權操作。
• 執行前要確認頁面是否穩定、推理後的目標是否仍在預期位置。
• 代操作期間需控制使用者與 Agent 同時操作造成的狀態衝突。
• 通用 GUI 模型還需針對支付寶、小程式及政務等服務型頁面持續理解、標準化描述與微調。

跨平台服務協同：當意圖發生在別人家

使用者想完成一件事時，意圖未必發生在支付寶內。它可能先出現在手機系統助手，或其他廠商的 Agent 中；因此，阿寶的關鍵課題是如何將外部意圖引入支付寶，同時把自身服務能力安全地提供出去。這可視為服務業的「跨平台轉接」：入口方先理解使用者想做什麼，再將意圖分發給真正能履約的服務主體。

分享提出的分工是：系統助手負責理解意圖與發起服務分發，支付寶在自身服務領域內承接並執行任務。這避免由手機廠商直接操作支付寶，或支付寶跨越系統邊界進行非必要操作，從而降低邊界與合規問題。以購買電影票為例，外部助手可將意圖交給支付寶處理，使用者不必全程停留在支付寶畫面等待。

與終端廠商合作還帶來兩項實際增益：第一，系統能力可支援任務在背景完成，完成後再通知使用者；第二，作業系統可提供更完整的畫面感知與操作能力，相比 App 自行突破 UI 限制，具備更高的控制力與較低錯誤率。這使跨平台協同不只是導流，而是任務閉環能力的延伸。

未來終端展望：異步任務、伴隨式服務與多設備復用

阿寶的下一步，不只是在對話頁回答更多問題，而是擴展到更完整的任務系統。首先是異步化：現階段部分任務受限於前台運行與交互方式，未來可探索讓知識查詢，乃至某些服務任務，以端雲協同方式在背景持續執行，並以更穩定的履約機制回報結果。

第二是伴隨式互動。理想狀態下，使用者不必每次都先進入對話入口；在使用支付寶任一服務的過程中，都能與阿寶對話，讓它理解當下畫面與情境，提供即時協助。第三則是多終端復用：除了手機與支付寶 App，手錶、眼鏡及各類支付設備也可能成為服務觸點，阿寶的服務供給需要能跨設備、跨場景延展。

異步任務任務管理伴隨式 Agent多設備上下文雲端沙箱服務履約

「從人找服務到服務找人。」
— 魏鳳笛

重點回顧

• 阿寶的本質是支付寶的 Agentic AI 入口，目標是將服務供給轉化為可理解、可調度、可執行的能力。
• 人機互動從單次請求轉為持續、全雙工、多模態串流；MoQ 搭配 RTC 與 gRPC，構成傳輸與備援策略。
• UI 從流式 Markdown、複雜內容渲染，走向以 A2UI 支援的生成式服務交互，將意圖與頁面實作解耦。
• 端上執行以 MCP／API、GUI、TUI 與腳本分層補足服務覆蓋，但可靠度、頁面校驗與授權控制是能否落地的前提。
• 當意圖發生在其他 Agent 或系統助手中，應以意圖分發與服務分工協同，而非跨越邊界直接代操作。
• 未來焦點在異步任務、伴隨式服務與跨手機、手錶、眼鏡等終端的服務復用，讓 Agent 從入口逐步成為無處不在的服務能力。