AI-translated from English; not yet reviewed by a fluent editor. # Anchor Browser 與 AgentCore Payments：代理如何跨越 x402 付費牆 > 開發者啟用工作階段並設定獲授權、設有預算的付款工具後，Anchor Browser 可透過 AgentCore payments 重試採用 x402 付費的頁面或 API 呼叫。 By BIG CHANGE Editorial Published: 2026-10-14T05:55:23.177Z Updated: 2026-10-14T05:55:23.177Z Canonical: https://bigchange.ai/blog/anchor-browser-agentcore-x402-payments ![A payment card and blank purchase order sit on a track beside an adjustable mechanical stop with an orange knob.](https://bigchange.ai/api/media/file/payment-authority-hero-v1.png) AI-generated conceptual illustration by BIG CHANGE. Delegating a purchase still requires a boundary around payment authority. The intact card, order and adjustable stop are a conceptual illustration, not a depiction of a specific product. AWS 與 Anchor Browser 已[記錄一項整合](https://aws.amazon.com/blogs/machine-learning/building-agents-that-transact-with-anchor-browser-and-agentcore-payments/)讓瀏覽器代理能在既有工作階段中，為受 x402 保護的頁面或 API 付款。瀏覽器可回應 HTTP 402 付款挑戰，向 Amazon Bedrock AgentCore payments 取得簽署的付款證明，再重試請求。對開發者而言，關鍵變化在於這些工作由哪一層處理：瀏覽器處理挑戰與重試，獨立設定的付款服務則檢查支出權限。 ## 主要變化 - **變更內容：**收到 x402 挑戰後，付費網路請求可在代理的瀏覽器工作階段中完成，不必把錢包金鑰或付款標頭寫進自動化程式碼。開發者必須明確為該工作階段啟用付款。 - **為何重要：**使用按次付費資料或內容的代理可以延續同一工作流程，而付款工具、身分權限與支出上限則由頁面和代理執行環境之外的設定控制。這把實際購買決定移入營運者必須設定與監控的基礎設施。 - **觀察重點：**重要界線是最初的 402 回應。格式錯誤的挑戰、不相容的付款網路、預算耗盡或付款遭拒，都會使資源對自動化程式維持不可用；開發者仍須處理這些回應。 ## 瀏覽器在付費頁面上的處理方式 AWS 與 Anchor 的[教學](https://aws.amazon.com/blogs/machine-learning/building-agents-that-transact-with-anchor-browser-and-agentcore-payments/)說明在 Anchor Browser 工作階段中，文件導覽`fetch`或 XMLHttpRequest 的流程。商家會回傳含付款挑戰的 HTTP`402 Payment Required`。Anchor 讀取條款，並尋找與工作階段連結付款工具相容的方法。AgentCore 檢查工作階段剩餘預算，並使用已設定的錢包供應者簽署證明。瀏覽器把證明加入**原始請求**，並重試一次；x402 v2 使用`PAYMENT-SIGNATURE`，v1 則使用`X-PAYMENT`。商家在傳回資源前驗證並結算付款。 這是文件所述的流程，並非 BIG CHANGE 對付費端點所做的測試。AWS 表示，瀏覽器在付款和重試期間會保留工作階段脈絡。既有的 Playwright、Puppeteer 與 Chrome DevTools Protocol 工作流程可繼續透過瀏覽器導覽或呼叫 API，無須自行組裝付款標頭。成功付款也不代表所有付費牆都能讀取：網站必須提供支援的 x402 挑戰，商家仍可決定是否接受證明並傳送回應。 ## 開發者必須啟用的設定 瀏覽器開關必須明確設定。[教學中的工作階段請求](https://aws.amazon.com/blogs/machine-learning/building-agents-that-transact-with-anchor-browser-and-agentcore-payments/)裡，`session.x402`預設為`false`；設為`true` 才會授權使用已設定工具進行**真實付款**。建立瀏覽器工作階段也需要 Anchor API 金鑰。這個旗標是連結到付款權限的最後一步，不能取代付款權限本身的設定。 AWS 的[AgentCore 付款指南](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/payments-how-it-works.html)說明底層資源。Payment Manager 定義 AWS 帳戶的付款設定，並使用 IAM 角色與授權器。Payment Connector 連接 Coinbase Developer Platform 或 Stripe Privy。Payment Credential Provider 透過 AgentCore Identity 保存供應者憑證。Payment Instrument 指定購買所用的錢包與網路。瀏覽器工作階段會連結到設有支出上限與到期時間的 AgentCore Payment Session。AWS 的[快速入門](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/payments-getting-started.html)也要求付款工具已注資，且使用者須先授予代理委派簽署權限，代理才能付款。 這些是彼此獨立的控制。IAM 管理服務存取權；使用者的錢包授權允許簽署；付款工具決定資金來源與網路；工作階段上限則限制一段時間內的支出。AWS 表示，工作階段到期或達到上限後，AgentCore 會拒絕後續付款。其可觀測性服務會在 CloudWatch 顯示付款嘗試與結果。整合可讓供應者密鑰離開瀏覽器與代理執行環境，但營運者仍須選擇適合工作的付款工具與上限。 ## 自動化流程的停止點 Anchor 文件說明的失敗行為很明確：如果 402 挑戰格式錯誤、未提供相容網路、預算耗盡，或 AgentCore 拒絕付款，瀏覽器會將**原始 402**原樣傳回頁面。因此，即使工作階段已啟用，自動化仍應把 402 視為可能結果。AWS 的[疑難排解指南](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/payments-troubleshooting.html)也列出其他設定失敗，包括 IAM 權限不足、委派簽署授權未啟用、供應者憑證無效，以及 Coinbase 缺少 Marketplace 訂閱。 這個`session.x402`開關適用於第三方資源的付款。AWS 表示，它不會支付 Anchor 瀏覽器工作階段費用，也不會取代 Anchor 點數。教學提到工作階段支出與時間限制，但將具體限制指向 Anchor 技術文件；本文無法取得那些細節。特定第三方請求的費用取決於商家的挑戰與實際結算。我們未核實端到端發票或交易，因此本文無法為已啟用的工作階段提供通用價格。 對開發者而言，實際決策應在代理抵達付費網址之前完成：連結已注資且獲授權的工具，為瀏覽器工作階段設定預算，再只在預期購買時啟用 x402。瀏覽器可免去導覽流程中的付款協定程式碼，但不會免除營運者對支出權限、失敗請求或核對商家實際收費的責任。這個權限問題也貫穿我們對[AI 代理付款選擇的深入檢視](https://bigchange.ai/blog/ai-agent-payments-stablecoins-bank-deposits)。 ## 資料來源與延伸閱讀 - [AWS 與 Anchor Browser，〈使用 Anchor Browser 和 AgentCore payments 建構可交易的代理〉](https://aws.amazon.com/blogs/machine-learning/building-agents-that-transact-with-anchor-browser-and-agentcore-payments/)（2026 年 10 月 13 日）。整合教學說明瀏覽器選擇啟用、x402 挑戰、依版本而異的付款標頭，以及失敗時回傳原始 402 的行為。這是對預期流程的文件說明；我們未測試付費工作階段。 - [AWS，〈AgentCore payments 的運作方式〉](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/payments-how-it-works.html)（開發者指南，於 2026 年 10 月 14 日查閱）。說明 Payment Manager、供應者連接器、身分憑證、付款工具、支出工作階段與可觀測性。這是一般服務設計，並與瀏覽器專用教學搭配閱讀。 - [AWS，〈AgentCore payments 快速入門〉](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/payments-getting-started.html)（開發者指南，於 2026 年 10 月 14 日查閱）。提供供應者憑證、已注資且獲授權的付款工具，以及付款工作階段的設定步驟。範例預算與時間長度是示例，並非已核實的 Anchor 工作階段預設值。 - [AWS，〈AgentCore payments 疑難排解〉](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/payments-troubleshooting.html)（開發者指南，於 2026 年 10 月 14 日查閱）。列出可能阻止付款的 IAM、供應者、錢包授權、訂閱與 x402 載荷錯誤。我們未重現這些錯誤。 ## Sources - [AWS Machine Learning Blog，〈Building agents that transact with Anchor Browser and AgentCore payments〉](https://aws.amazon.com/blogs/machine-learning/building-agents-that-transact-with-anchor-browser-and-agentcore-payments/) — 主要整合教學。說明 session.x402 預設值與真實付款啟用方式、瀏覽器／AgentCore 流程、僅重試一次，以及所列失敗時原始 402 不變。這是供應商描述的行為；BIG CHANGE 未執行付費工作階段。其關於 Anchor 點數／發票整合的另一項說法，未與 AgentCore 錢包注資文件獨立核對，因此不把它寫成通用收費模式。 - [AWS，〈How AgentCore payments works〉](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/payments-how-it-works.html) — 維護中的服務架構與控制參考。定義 Payment Manager、連接器、身分憑證供應者、付款工具、工作階段上限與到期、使用者錢包授權、付款流程及可觀測性。通用 x402 流程使用 X-PAYMENT；Anchor 專用教學則區分 x402 v2 的 PAYMENT-SIGNATURE 標頭。 - [AWS，〈AgentCore payments quick start〉](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/payments-getting-started.html) — 設定步驟與先決條件，包括 Coinbase 或 Stripe Privy 供應者連線、已注資工具、委派簽署授權與限時付款工作階段。範例金額和時間不是 Anchor 預設值或上限。 - [AWS，〈Troubleshooting AgentCore payments〉](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/payments-troubleshooting.html) — 記錄權限、訂閱、錢包授權、憑證與 x402 載荷錯誤。服務端錯誤補充 Anchor 瀏覽器教學所述的原始 402 回傳行為；本文未測試任何失敗路徑。