Anchor Browser 接入 AgentCore payments，让智能体为受保护网页和 API 付款
据 AWS 提供的文章介绍，具备 Agentic Payments 功能的 Anchor Browser 已与 Amazon Bedrock AgentCore payments 集成，使智能体能够自主为受 x402 保护的网页和 API 付款。该方案由 Anchor Browser 与 AWS Generative AI Innovation Center Partner Agent Factory 合作开发，并已在 AWS Marketplace 提供。以下能力和运行方式均来自这一篇 AWS 文章，没有独立来源的交叉确认。
把支付要求纳入浏览器任务
文章将 x402 描述为通过 HTTP 进行机器间支付的开放标准。当智能体请求受保护的资源时，服务端可以返回 HTTP 402 Payment Required，并附上支付挑战，说明所需金额、接受的支付方式以及收款地址。如果智能体没有处理付款的机制，任务就可能停在这里，需要人来介入，才能继续获取所需内容。
这一集成针对的正是从收到支付要求到重新请求资源的过程。浏览器识别支付挑战后，将相关操作交给支付层处理，再携带签名证明重试原始请求。因此，支付成为当前访问流程的一部分。不过，是否能够继续获取内容仍取决于支付方式是否兼容、预算是否充足，以及支付是否获准；文章并未承诺每次请求都能成功。
Anchor Browser 提供托管的云端浏览器会话，保留身份验证状态，并支持页面导航、网络流量捕获、录制和实时查看。支付发生在同一浏览器会话内，录制内容可以覆盖首次请求、收到四〇二支付挑战、付款以及内容交付的完整顺序，便于查看任务在支付环节发生了什么。
据文章说明，其内置 x402 工具不要求修改现有的 Playwright、Puppeteer 或 Chrome DevTools Protocol 工作流程。对已经使用这些方式控制浏览器的应用而言，文章描述的接入方式是在原有浏览器自动化流程中加入支付处理，而支付证明的构造和钱包操作由集成组件承担。
支付控制放在托管基础设施中
AWS 将 AgentCore payments 描述为完全托管的能力，用于发现、访问和支付 API、MCP 服务器及网页内容。它负责钱包连接和 x402 支付处理，并在基础设施层执行可配置的支出限制。支付尝试、批准、拒绝和结算均可通过 Amazon CloudWatch 观察；当会话达到支出上限时，后续支付会被拒绝。
文章也解释了自行构建支付组件的复杂性。开发者需要解析不同支付挑战、生成包含支付证明的请求头，并处理支付方案及商户实现之间的差异。与此同时，还要管理凭证、在重试时保留原始请求上下文、保证幂等性、跟踪并发执行中的预算，并记录供审计使用的事件。这些工作横跨协议处理、安全、运行可靠性和可观测性。
如果支出控制不足，系统可能产生非预期花费；如果运行环境隔离不充分，凭证也可能暴露。文章给出的架构把身份验证、钱包秘密信息、支付限额、监控和支付证明签名移入托管支付层，留给 Anchor Agent 的是预算会话和 x402 工具。这说明了各层的职责安排，并不意味着所有安全风险都已消失。
Anchor Browser 通过支持的钱包提供方完成钱包设置，不把钱包秘密信息或私钥放入智能体运行环境。在所描述的支付流程中，钱包凭证始终由 AgentCore 和已配置的钱包提供方持有。浏览器需要的是可随请求提交的密码学证明，而不是用于生成该证明的密钥材料。
账户配置与单次会话如何衔接
账户层面的支付操作由 Payment Manager 协调。创建这一组件时，需要指定授权器类型和 IAM 角色，随后 AgentCore 会在 AgentCore Identity 中为工作负载配置身份。这里的账户级配置与后续浏览器会话关联：前者准备支付管理所需的组件，后者使用指定支付工具和预算发起具体操作。
文章列出的组件各有分工：PaymentConnector 用于连接 Coinbase Developer Platform 或 Stripe Privy；PaymentCredentialProvider 在 AgentCore Identity 中保存提供方凭证；PaymentInstrument 标识提供资金的钱包地址。此外，AgentCore 通过 Gateway 暴露经过筛选的 Coinbase x402 Bazaar MCP 服务器，用于发现端点。资源发现、凭证保存和资金来源因此有各自对应的配置对象。
当浏览器以启用 x402 的方式启动会话时，Anchor Browser 会创建专用的 AgentCore PaymentSession，并将其关联到已配置的支付工具和预算。这个支付会话为后续付款提供预算上下文。收到支付挑战并不直接等于已经完成扣款：浏览器还要选择兼容的支付方式，支付层也必须检查相应的限制。
在选定支付方式后，AgentCore 检查会话支出上限，通过 Coinbase CDP 或 Stripe Privy 完成签名，并返回密码学证明。根据文章描述，这个过程不会把密钥材料暴露给浏览器或智能体运行环境。预算检查和签名都在托管流程中进行，浏览器随后使用返回的证明继续原来的资源请求。
签名重试与结算责任
对于 x402 v2，浏览器通过 PAYMENT-SIGNATURE 请求头附加签名证明；对于 x402 v1，则使用 X-PAYMENT。随后，它将原始请求准确地重试一次。文章逐步描述的成功流程是：商户验证证明，在链上结算交易，再返回受保护资源，让智能体继续执行任务。这里的重试次数有明确描述，不能据此推断会持续重复付款或请求。
关于结算责任，来源本身存在需要保留的区别。逐步流程将链上结算交给商户，而后面的另一段文字又称签名和结算发生在 AgentCore payments 内部。因此，可以说明文章描述了支付证明、结算和资源交付的流程，但仅凭这份材料，无法明确断言商户与 AgentCore 之间究竟如何分配全部结算职责。
启用意味着授权真实支付
配置需要有效的 Anchor Browser API 密钥。自动支付通过将 session.x402 设置为 true 开启，该属性默认是 false。文章明确说明，开启功能会授权从已配置的支付工具进行真实付款。因此，这个设置不仅影响浏览器如何解释响应，也决定它是否可以启动实际支付操作。
即使启用自动支付，会话的支出限制和有效期限制仍然适用。所提供的文章没有给出具体支出上限、默认预算或有效期时长，而是让读者参阅技术文档。因此，不能从这一介绍中得出统一的可花费金额或会话持续时间，也不能把自动处理理解为没有预算边界的支付授权。
自动支付挑战处理覆盖文档导航、fetch 和 XMLHttpRequest。内置 x402 工具还支持付费 API 调用，包括需要 POST、PUT 或其他 HTTP 方法的情况。按照文章说明，应用代码无需自行构造支付请求头、管理钱包或实现支付重试逻辑，这些操作由所描述的集成流程处理。
失败响应仍需由自动化代码处理
集成也规定了无法付款时的行为。如果商户响应格式不正确、没有提供兼容网络、预算已经耗尽，或 AgentCore 拒绝支付，浏览器会原样返回最初的四〇二响应。这意味着自动支付没有把所有失败都转化为成功访问；应用仍需要识别和处理未解决的支付要求，才能决定后续任务如何进行。
这一失败路径与成功路径同样重要：成功时，浏览器携带证明重试并取得资源；无法满足条件时，则保留原始响应交给自动化代码。文章没有提供完整的支持网络或货币列表，也没有给出支付成功率和性能测量结果，因此不能据此扩展出兼容所有资源或必然缩短任务耗时的结论。
第三方资源费用与浏览器费用的关系
session.x402 只适用于第三方资源的支付。它不会替代 Anchor 积分，也不会支付浏览器会话本身的运行时间。理解这一点有助于区分功能的支付对象与账单展示方式：开启第三方资源自动支付，并不等于已经通过该属性承担浏览器服务的全部费用。
与此同时，文章称 Anchor Browser 会把第三方 x402 费用按积分计费，并与浏览器会话时间放在同一张发票上。AWS 将这种合并计费描述为让客户无需另行管理加密资产托管、监控 USDC 余额或为财务核对链上结算。这里描述的是客户侧的账务处理安排，并不能消除前述来源对底层结算责任分工的含糊之处。