從 Alexa for Shopping 到 Agentic Commerce：Amazon × TapPay 如何讓 AI 真正幫你結帳

這場演講由 Amazon 代表 與 TapPay 副總經理 Joseph 共同分享，探討兩條彼此呼應的戰線：

1. Amazon 如何把生成式 AI 導購助理（原名 Rufus，現為 Alexa for Shopping）做成可規模化的轉換引擎
2. TapPay 如何運用亞馬遜技術，把零售從「聊天推薦」推向真正能代客結帳的 主動式電商（Agentic Commerce）

核心不是「AI 會不會聊天」，而是：AI 能不能在低延遲前提下簡化決策，並在嚴格金融控管下安全地花錢。

議程總覽

區塊	焦點	關鍵訊息
Amazon Alexa for Shopping	導購痛點與轉換	Lens、評論摘要、尺碼、對話式推薦、Buy for Me
架構抉擇	單 Agent vs 多 Agent	First Token 控制在 3–5 秒
TapPay Agentic Commerce	主動代理採購	意圖前端介入，完成結帳與付款
安全防線	AI 被授權花錢	單次虛擬卡、意圖核對、MFA、限額與商戶白名單

亦可對照本站 DoorDash Ask Assistant 架構：同樣強調 Agent 執行與確定性／安全邊界，而非把所有商業動作直接丟給模型。

一、Amazon Alexa for Shopping：把購物摩擦拆掉

Amazon 分享其生成式 AI 導購助理如何針對真實消費痛點設計功能，並以更短決策路徑拉高轉換率。

五大功能如何對上痛點

功能	解決什麼	怎麼做
Amazon Lens（以圖搜圖）	不知道商品名稱	拍照即可找對應或相似商品
Review Summary（評論摘要）	評論太多讀不完	LLM 自動整理正／負特點
Size Recommendation（尺碼推薦）	亞太／歐／美尺碼混亂	結合評論訊號（如「版型偏小」）與個人檔案
Ask Rufus（對話式導購）	需求表達複雜	記住偏好（如配偶喜歡的顏色）後精準推薦
Buy for Me（無貨代買）	自營無貨仍想買	在虛擬 VM 用 headless browser 前往品牌官網代下單寄送

Buy for Me 特別值得注意：這已超出「給連結」，而是 Agent 在隔離執行環境中代表用戶完成跨站操作。能力很強，但爆炸半徑也更大——後文 TapPay 的支付控管，幾乎是同一類能力在金融側必要的對偶解法。

2025 年營運成果

• 用戶規模：約 3 億 用戶
• 營收貢獻：超過 120 億美元
• 轉換率：相較傳統搜尋流程，購買轉換率提升約 60%

數字本身很漂亮；但演講真正想強調的是路徑：先拿走尺碼、評論、以圖搜尋等摩擦，決策變短，轉換才跟得上。

二、關鍵架構抉擇：放棄多 Agent，保住 3–5 秒

Amazon 採用 Amazon Bedrock AgentCore 作為核心，並做了一個對產品成敗極關鍵的決定：

放棄多 Agent（Multi-Agent）設計，改採單 Agent（Single Agent）架構。

理由非常產品導向：多 Agent 協作雖可能提升任務精準度，但頻繁互相呼叫會把延遲推到 30–60 秒。電商場景中，用戶很難為一個搜尋／推薦流程等半分鐘。

因此 Amazon 選擇採 可串流回應的單 Agent（Single Agent）架構，把 首字回應時間（First Token） 壓在 3–5 秒 內。

flowchart LR
  User[使用者意圖]
  Single[Single Agent<br/>Streaming Response]
  Tools[搜尋 / 評論 / 尺碼 / 代買工具]
  Out[首字回應 3–5 秒]

  User --> Single --> Tools --> Out

編者補充： 這不是否定多 Agent，而是提醒 trade-off——協調精度 vs 體感延遲。電商這種「幾乎瞬時決策」場景，延遲常比多一層專責 Agent 更致命。若任務屬後台規劃、稽核或長流程，多 Agent 仍可能合理。

三、TapPay：從聊天機器人到 Agentic Commerce

Joseph 提出更前移的零售觀念：不要只在消費者已經挑商品時才出現，而要在 購物意圖（Intention）剛萌芽 時就介入，並盡可能幫使用者走到結帳完成。

傳統導購 vs 主動式電商

比較項目	傳統導購機器人	主動式電商（Agentic Commerce）
介入時機	消費者主動搜尋、挑選時	購物意圖剛出現的最前端
任務範疇	推薦商品、丟購買連結	拆解意圖、匹配規格、完成結帳與付款
用戶體驗	仍須手動跳轉電商網站結帳	AI 代理人一站式完成任務

實踐三大要素

1. 工具與資源（Tools） 給 AI「手和腳」：金流錢包、搜尋 API、商家服務串接，使其能真正執行購買。
2. 穩定的工作流（Workflow） 建立檢查與驗證機制，確保買對東西、結帳與付款順利。
3. 穩定的執行環境（Runtime） 採用 Amazon Bedrock AgentCore，支撐高併發與高安全性。

這三要素幾乎可對應到企業 Agent 平台的共通結構：Tools × Workflow × Runtime。少任何一塊，系統就容易停在 Demo——會聊、不會買，或會買但不安全。

四、五大未來應用場景

場景	用戶怎麼說／做	Agent 做什麼
定期自動採購	「貓砂快沒了」類消耗節奏	依喜好與消耗自動補貨；依反饋調整規格（例如貓不愛吃某罐頭）
客製化旅遊規劃	天數、預算、同行人數	串接訂房、訂餐廳、門票（如 AsiaYo、FunNow）
拍照空間搭配	上傳客廳照片	分析風格與尺寸，推薦裝飾品
預算制驚喜禮物	每月固定 500–1000 元	依日常習慣自動挑選並寄送
精準送禮	分析與朋友的互動	推薦真正「送進心坎」的節日禮物

這些場景共同點是：價值不只在推薦品質，而在 把意圖轉成可執行的交易閉環。也因此，下一節的安全控管不是附加功能，而是產品能不能上線的前提。

五、AI 自動購物的安全防禦線

Joseph 強調：一旦賦予 AI「花錢的能力」，必須假設模型會幻覺、會越權、會為了「達成任務」走捷徑。TapPay 的防線如下：

四道控管

1. 單次性虛擬卡（One-time Virtual Cards） 每次交易產生一次性虛擬卡片，用完即廢，降低重複盜刷風險。
2. 購物籃與意圖核對（Intent Validation） 檢查購物車是否真符合用戶初始意圖——例如防止 AI 為了拿贈品，順便買下昂貴主機。
3. 雙重認證（MFA） 偵測金額異常或高風險行為時，必須經用戶手動驗證才放行。
4. 嚴格限額管理 支援單筆上限、單月上限，以及允許消費的商戶名單（Merchant Allowlist）。

flowchart TD
  Intent[用戶意圖]
  Plan[Agent 規劃購物籃]
  Check{意圖核對 / 限額 / 商戶白名單}
  MFA{高風險？}
  Pay[單次虛擬卡付款]
  Block[拒絕或升級人工確認]

  Intent --> Plan --> Check
  Check -->|不符| Block
  Check -->|通過| MFA
  MFA -->|是| Block
  MFA -->|否| Pay

這套設計的產品哲學很清楚：Agent 可以自主，但不能失控。 自主完成任務，與「無限制地代為支出」，中間必須有可配置、可稽核、可中斷的金融邊界。

Open Beta 現況

該主動式電商系統已於 2026 年 4 月 開啟 Open Beta，並已串接：

• FunNow（訂餐廳）
• AsiaYo（訂宿）
• 誠品線上（生活百貨）
• 比比昂 Bibian（跨境電商）

不過仍須留意：開放商家名單、限額與意圖核對規則，會直接決定 Agent 的「爆炸半徑」。覆蓋面愈大，治理策略愈要硬。

結構化摘要

• Amazon 的實踐： Alexa for Shopping 透過以圖搜尋、評論摘要、尺碼推薦、對話式導購與無貨代買，縮短決策路徑；單 Agent + 3–5 秒首字回應 是留住用戶、支撐巨額營收的關鍵工程取捨。
• Agentic Commerce 是下一代： 從被動搜尋推薦，走向「意圖萌芽即介入、並可自主完成採購與結帳」；需要 Tools、Workflow、Runtime 三者齊備。
• 安全與控管是核心： 當 AI 能真的花錢，商家／平台的核心價值更在於提供可控金融環境——單次虛擬卡、額度、意圖核對與 MFA，才是讓主動式購物可上線的軌道。

關鍵結語

這場演講把電商 Agent 的下一階段講得很直白：

低延遲決定用戶願不願意用；安全控管決定系統能不能讓它花錢。

Amazon 證明了生成式導購在巨量用戶上的商業效力，也提醒架構選擇必須服務體感；TapPay 則把故事推進到「主動結帳」，並用金融級防護回答最危險的問題——AI 有錢包之後，誰來畫紅線？

當導購從「給建議」變成「代執行」，勝負將愈來愈不在模型嘴甜，而在 Runtime、工作流與支付護欄是否經得起真實金錢與真實用戶。