Amazon Bedrock AgentCore Payments 是什麼？GA、x402 與設定

Amazon Bedrock AgentCore Payments 已於 2026 年 8 月 GA。本文整理 x402、MPP、Coinbase／Stripe 錢包、預算限制、費用與台灣團隊可用區域。

發佈於： 2026-05-31 | 更新於： 2026-09-14

中級 Amazon Bedrock AgentCore AgentCore Payments AWS

內容查核： 2026-09-14 來源查核： 2026-09-14

Amazon Bedrock AgentCore Payments 已於 2026 年 8 月 18 日正式 GA。 它讓 AI Agent 在工作流程中，對付費 API、MCP server、資料來源或數位內容完成受控付款；目前重點是機器對機器的小額交易，不是讓模型拿公司信用卡任意購買一般商品的完整方案。

如果你在 5 月 preview 時看過這項功能，現在有幾個關鍵變化：GA 版除了 x402，也加入 Machine Payments Protocol（MPP）、Coinbase 憑證快速建立、Coinbase Bazaar MCP server，以及 x402 的 upto 授權方式。AWS 同時把可用區域從原本四區擴大到更多美洲、歐洲與亞太區域。

現在是 GA，和 5 月 preview 差在哪？

依 GA 公告，AgentCore Payments 把錢包憑證、交易簽署、每次任務的預算及可觀測性納入 Agent 基礎設施，開發者不必把私鑰直接塞進提示詞。這些能力仍要和應用程式的採購判斷分開。

項目	2026 年 5 月 preview	2026 年 8 月 GA
產品狀態	預覽	正式可用
支付協議	以 x402 為主	x402、MPP，並新增 x402 `upto`
錢包	Coinbase CDP、Stripe Privy	保留兩種連接器
服務探索	付費 API 與 MCP 情境	更新 Coinbase Bazaar MCP server 的端點探索與篩選
控制與追蹤	Session 預算、logs、metrics、traces	延續預算與可觀測性，並增加較快的 Coinbase 設定流程

這個定位和 ChatGPT 代購、信用卡網路的 Agentic Commerce 不完全相同。AgentCore Payments 現階段更接近「Agent 呼叫某個要付費的數位端點時，能否在授權額度內即時付款」。若想了解一般商品、商家結帳與卡片授權的差別，可搭配閱讀 AI Agent 支付怎麼運作。

AgentCore Payments 付款流程怎麼運作？

官方架構由四個角色組成。Payment Manager 是帳戶內管理付款設定的頂層資源；Payment Connector 連到 Coinbase CDP 或 Stripe Privy，所需憑證交由 AgentCore Identity 管理。Payment Instrument 是實際簽署付款的嵌入式加密錢包，新建時餘額為 0 USDC，必須由使用者明確授權資金。每次 Agent 任務再建立 Payment Session，用最高支出、幣別與到期時間框定付款範圍。

以 x402 付費 API 為例，模型不會直接產生轉帳。Agent 先呼叫端點；若服務回傳 402 Payment Required，AgentCore 會檢查該 session 是否仍有額度，再用指定 instrument 簽署付款證明。Agent 帶著證明重試請求，服務完成結算後才回傳資源。如果簽署或付款失敗，文件說明預留額度會回滾，不應把失敗交易算成已花掉的 session budget。

呼叫付費端點
  → 收到 402 與付款要求
  → 檢查 Payment Session 額度
  → 錢包簽署付款證明
  → 帶證明重試請求
  → 結算、取得資料並留下追蹤紀錄

這套流程解決「怎麼安全交付付款能力」；至於 Agent 該不該買，仍要由應用程式的政策與人工核准決定。收款方是否可信、價格是否合理、資料是否值得購買，都不在支付協議的判斷範圍內。

x402 與 MPP 有什麼差別？

x402 把 HTTP 402 Payment Required 變成可執行流程。付費端點直接回覆金額、資產與收款條件，Agent 付款後重送請求，適合按次收費的 API、MCP 工具和內容。GA 新增的 upto scheme 允許在預先核准的上限內處理實際金額，適合最終費用要等請求完成才知道的場景。

Machine Payments Protocol（MPP） 是 GA 版加入的另一種機器支付協議。採用前應先確認目標服務支援哪個協議、哪種資產與網路，以及錯誤和退款如何處理；不必先押注哪個協議會勝出。AgentCore Payments 支援兩種協議，不代表每一個付費端點都能互通。

MCP 也不會因為接上 Payments 就自動變成可信市集。MCP 定義 Agent 如何發現與呼叫工具，支付協議負責付款；身分、工具權限、提示注入防護與服務品質仍是不同層次。第一次接觸可先看 MCP 是什麼，正式上線則要把 Prompt Injection 防護一起納入設計。

怎麼開始？台灣可以用嗎？

官方快速入門提供 AgentCore CLI／SDK，也可從支援 AgentCore Payments skill 的開發工具開始。手動走 Python 路線時，文件列出的套件安裝方式如下：

pip install boto3 "bedrock-agentcore[strands-agents]" strands-agents strands-agents-tools

實際導入順序建議是：

選定支援 Payments 的 AWS Region，建立 Payment Manager。
選 Coinbase CDP 或 Stripe Privy，透過 AgentCore Identity 保存連接憑證。
建立 Payment Instrument，再由使用者授權資金；測試時先用官方提供的測試網路與測試端點。
每次任務建立獨立 Payment Session，設定最高支出與到期時間。
由 Agent 呼叫 x402 或 MPP 端點，確認成功、拒絕、逾時與重試都能正確對帳。

Coinbase 連接器需要先訂閱 AWS Marketplace 上的 Coinbase 項目，相關錢包操作會依供應商方案計費；Stripe Privy 連接器目前不要求這項 Marketplace 訂閱。憑證的保存與執行身分可先參考 Amazon Bedrock AgentCore Identity 指南。

截至 2026 年 9 月 14 日查核，Payments 支援區域表的亞太欄位列出新加坡與雪梨；東京、首爾、孟買、馬來西亞與泰國未列為支援。這是特定服務的覆蓋範圍，不能據此說 AWS 沒有台灣區域。台灣團隊可先依這份清單評估延遲、資料存放與內部合規，再確認錢包供應商是否接受自身業務與所在地；AWS 區域可選，不代表錢包與資金來源一定能用。

預算還有剩，為什麼也應該停止付款？

假設研究代理有 1 USDC 任務預算，向已核准端點買一份價格 0.20 USDC 的資料。這是自行設定的流程案例，不是市場報價或實際交易。正常情況是取得付款與交付證據，確認同一份資料已收到，再把它用於原任務；剩餘 0.80 USDC 是額度，不是必須花完的購物清單。

最難的是「付款送出後沒有收到回應」。逾時只表示客戶端沒有得到完整結果，不能直接推論商家沒收款。AWS 的流程文件說明失敗會釋放預算預留，但預算紀錄、錢包結算與商家交付仍是需要核對的不同證據；不能把預留釋放當成所有外部結算都已退款。

應先把該請求標為待對帳，查原請求識別、付款證明、錢包紀錄與商家回應，不要立刻新建付款再買一次。重試能否沿用同一識別碼、對方是否保證不重複收款，要按實際協議、供應商 API 與保存期限驗證；在提示詞裡寫「不要重複」不會形成這種保障。

若查到已付款卻沒有交付，下一步是依商家機制補取資料、申請退款或交由負責人處理，不是換另一個代理繼續嘗試。若商家臨時要求改付另一個地址，或把價格提高，即使總額仍在預算內，也要重新核對收款對象與用途。金額上限只能限制支出，不能判斷交易是否合理。

測試驗收至少要留下四種不同結果：正常付款且取得內容、超額被拒、簽署失敗、結果不明待對帳。只有第一種可以直接算作任務完成；其他情況應保留原任務與付款關聯，避免報表把「API 呼叫結束」誤算成「資料已買到」。撤銷使用者授權後，也要確認待執行工作不會自動建立另一個 session 繼續支出。

預算、安全與會計要檢查什麼？

Payment Session 的最高支出是必要控制，但它只回答「最多損失多少」，沒有回答「錢會付給誰」和「這筆購買是否合理」。如果 Agent 被惡意網頁或 MCP 回應提示注入，它仍可能在額度內向錯誤端點付款。

正式環境至少要補上這些限制：

收款方白名單：預先核准商家、網域、錢包地址與協議，首次出現的收款方要求人工確認。
單筆與期間上限：除了 session 總額，再限制單筆、每日與每個供應商的支出。
用途綁定：支付授權要綁定任務、工具與資料類型，不能讓研究 Agent 的額度被其他流程共用。
重複付款防護：保存穩定的請求識別，核對各端點的冪等性支援與期限；測試逾時、網路中斷及已收款但回應遺失，不假定所有服務都認同一種識別欄位。
環境隔離：開發、測試與正式環境使用不同 manager、connector、instrument 和資金來源。
對帳與告警：把 AgentCore logs／traces、錢包紀錄、供應商帳單與取得的數位資源互相比對，異常金額或頻率立即停用。
退款與爭議流程：先確認付費端點是否提供退款、如何證明服務未交付，以及誰有權停用錢包。

AWS 定價頁列出，除所選供應商的標準錢包操作費外，Payments API 沒有另外的呼叫費。建立錢包與簽署交易的計費方式要依 Coinbase CDP／Stripe Privy 分開看；實際購買金額，以及 Runtime、Identity、Gateway、Observability 等元件仍可能有成本。不要把「Payments 無額外 AWS 費用」理解成整條交易流程免費。

此外，AWS 提供的預算與稽核能力不會取代公司的稅務、會計、制裁名單、洗錢防制、採購與資料授權責任。若 Agent 會碰真實資金，資安、財務、法務和採購應共同定義上限與停用流程；在 prompt 裡寫一句「請謹慎付款」無法形成有效控制。

常見問題

Amazon Bedrock AgentCore Payments 還在 preview 嗎？

已經正式可用。AWS 在 2026 年 8 月 18 日宣布 AgentCore Payments GA；5 月 7 日的舊公告才是 preview。搜尋結果或部分舊頁面若仍寫 preview，應以較新的 GA 公告和目前文件為準。

AgentCore Payments 可以讓 Agent 自動刷信用卡購物嗎？

目前不應這樣理解。官方主打的是以 Coinbase CDP 或 Stripe Privy 嵌入式錢包，透過 x402／MPP 向付費 API、MCP server 和數位內容付款。一般信用卡購物、訂票與實體商品履約屬於更廣的 Agentic Commerce 問題。

設定 session spending limit 就足夠安全嗎？

不夠。它能限制一次任務最多花多少，不能保證收款方可信、價格合理或內容真的交付。還要有收款方白名單、單筆上限、首次商家人工核准、重複付款防護、退款流程與持續對帳。

台灣開發者該選哪個 AWS Region？

截至 2026 年 9 月 14 日查核，Payments 的亞太支援區域是新加坡與雪梨，東京和首爾未列為支援。應依延遲、資料存放、公司政策及錢包供應商資格評估，並在部署前重查區域表；不能把這份清單當成 AWS 全部區域清單。

參考來源

№ · further reading