Amazon Bedrock AgentCore Payments 为 Anchor Browser 智能体提供可控支付方式

Amazon Bedrock AgentCore payments 现可让 Anchor Browser 智能体在不获取钱包密钥的情况下跨越 x402 付费墙，但每个会话仍须在固定预算内运行。这项于 10 月 13 日发布的集成方案，可在受管理的浏览器会话中处理支付挑战，签署获批准的交易后，对被拦截的请求重试一次。

这改变了 Web 自动化中一个长期存在的限制。智能体可能发现合适的数据集、研究页面或专用 API，却因资源需要付费而止步。赋予智能体对钱包的无限制访问权限虽然能解决一个问题，却会带来更大的安全风险。

AWS 与 Anchor Browser 的方案将智能体置于这两个极端之间。智能体可以发起付费请求，但 Amazon Bedrock AgentCore payments 控制钱包连接、授权、支出限额、签名和审计轨迹。这种托管方式如今正与 Stripe、Google、Cloudflare、Coinbase 及其他基础设施提供商的支付系统展开竞争。

Anchor Browser 智能体支付下沉至智能体运行时之下

这项集成将支付从智能体的决策转变为由基础设施强制执行的交易。

Anchor Browser 为 AI 智能体提供托管浏览器会话。这些会话能够保留身份验证状态、执行导航、捕获网络请求并记录交互，也可支持 Playwright、Puppeteer 和 Chrome DevTools Protocol 工作流。

新集成将支付上下文附加到现有浏览器会话中。开发者只需将会话的 x402 属性设为 true 即可启用。该设置默认值为 false，因为启用它意味着允许从已配置的支付工具发起真实付款。

当浏览器访问受保护资源时，商家会返回 HTTP 402 Payment Required。响应中包含金额、接受的支付方式、网络和收款地址。浏览器随后会将该请求与连接到会话的支付工具进行匹配。

AgentCore 会根据会话预算检查拟议收费。如果请求通过，它会要求已配置的钱包提供商签署支付凭证。Anchor Browser 会将该凭证加入请求，并重试一次。

具体使用的请求头取决于 x402 版本。版本 2 使用 PAYMENT-SIGNATURE，版本 1 则使用 X-PAYMENT。商家验证凭证、完成支付结算后，返回受保护资源。

AWS 在其详细的浏览器集成说明中描述了这一流程。该流程支持浏览器导航、fetch 请求、XMLHttpRequest 调用，以及在浏览器上下文中发起的付费 API 请求。

智能体永远不会获得钱包私钥，也无需构建支付请求头或维护自己的重试循环。这些职责由 AgentCore payments 和浏览器层承担。

这种职责划分至关重要，因为由提示词驱动的软件不应成为可转移资金的最终决策者。恶意页面可能通过提示注入影响智能体的推理，而有缺陷的规划循环也可能反复请求同一资源。

在模型之外强制执行的预算可降低任一故障的影响。模型可以请求访问权限，但无法暗中扩大获授权的支出上限。钱包提供商也会将签名材料保留在浏览器进程之外。

该功能可通过 AWS Marketplace 上的 Anchor Browser 使用。AWS 表示，这项工作是与其 Generative AI Innovation Center Partner Agent Factory 共同开发的。这一背景表明，该集成定位为可部署的基础设施，而非使用临时钱包的演示方案。

这一事件之所以重要，在于它将三个通常彼此分离的组件结合起来：Anchor Browser 管理有状态的 Web 交互，AgentCore 管理支付策略，x402 则定义与商家的交换方式。智能体负责协调任务，但并不掌控每个敏感组件。

Amazon Bedrock AgentCore Payments 为支出增加控制平面

核心产品决策不在于智能体能够支付，而在于它能在不控制支付系统的前提下完成支付。

AgentCore 围绕多种托管资源组织支付能力。Payment Manager 为 AWS 账户建立支付边界，PaymentConnector 则将该管理器连接至外部钱包基础设施。

AWS 目前将 Coinbase Developer Platform 和 Stripe Privy 列为受支持的钱包提供商选项。PaymentCredentialProvider 通过 AgentCore Identity 存储提供商凭据。PaymentInstrument 则标识交易所使用的钱包地址。

PaymentSession 将支付工具绑定至一次特定交互。它包含最高支出金额、货币和到期时间。达到限额或会话到期后，AgentCore 会拒绝后续请求。

这些控制措施独立于智能体的提示词和应用逻辑。开发者可以指示智能体保持节省，但这种指示并非财务控制。由支付服务强制执行的会话限额才是。

AWS 表示，钱包密钥和提供商授权密钥等凭据通过其托管身份和密钥基础设施存储。其支付架构会在处理交易时获取所需的授权材料，只有相关的托管服务会接触这些材料。

这种分离建立了有用的信任边界。浏览器遭到入侵仍然很严重，因为攻击者可能操纵会话中的操作。不过，浏览器不会因此自动获得转移任意资金所需的私有凭据。

AgentCore 还会通过 Amazon CloudWatch 记录支付尝试、批准、拒绝和结算。这种可观测性使运营人员能够追溯智能体请求了什么，以及策略层如何响应。

当一个自主任务包含许多步骤时，这条审计轨迹尤为重要。一次用户请求可能引发多次搜索、API 调用和内容获取。若没有交易级记录，运营人员将难以把支出与触发该支出的操作关联起来。

这一模式尤其适合运行时间超过单次聊天回复的企业智能体。长时间运行的系统可以动态发现工具，也可能遇到任务启动时尚未知晓的成本。静态 API 订阅无法覆盖智能体可能发现的每项服务。

按会话设置的控制提供了更窄的授权窗口。企业可以为单项任务批准有限额度，而非永久授予对通用钱包的访问权限。到期机制也限制了被遗弃凭据的可用时长。

不过，预算上限并不能判断一项购买是否合理。AgentCore 可以验证收费是否落在批准金额内，却无法独立判断资源是否准确、必要、重复，或是否值得其标价。

这一差异将财务安全与采购质量区分开来。基础设施可以执行上限并保留证据，但智能体的规划逻辑仍必须判断购买是否推动了用户目标。

团队需要同时具备这两层能力：围绕资金的确定性控制，以及围绕价值的可靠推理。将其中一者视为另一者的替代品，会夸大该集成方案的实际能力。

x402 智能体支付如何将付费墙变为 HTTP 交换

x402 之所以重要，是因为它将机器可读的支付请求直接置于请求与响应循环之中。

传统在线购买流程假定存在人类界面。买家需要创建账户、选择套餐、输入支付信息并确认结账。这些步骤会中断自主智能体的工作，也引入了为人类设计的交互界面。

x402 使用现有 HTTP 402 状态码以编程方式请求付款。客户端首先请求受保护的页面、文件、API 或 Model Context Protocol 工具。服务器不返回资源，而是返回支付要求。

客户端签署符合这些要求的授权，随后携带支付凭证重复原始请求。完成验证和结算后，服务器返回所请求的内容。

该协议支持机器间访问，无需传统的结账页面。Cloudflare 的x402 文档描述了客户端、服务器以及可选的协调方；后者负责验证和广播交易。客户端可以是智能体、应用程序或其他自动化服务。

在 Anchor Browser 流程中，托管浏览器会检测 402 挑战。AgentCore 验证支付载荷、检查可用预算，并通过已配置的提供商签名。浏览器在收到凭证后重试相同请求。

重试只会发生一次。如果挑战格式错误、网络不受支持或预算耗尽，原始 402 响应仍会保留可见。应用程序代码随后可以将其作为普通 HTTP 错误处理。

这种行为限制了失控循环。服务器无法通过单个请求无限触发自动重试；当支付无法继续时，它也为周边应用程序提供了清晰的失败状态。

Anchor Browser 将这一机制扩展至页面导航之外。其内置 x402 工具可处理通过 fetch 或 XHR 发出的付费 POST 和 PUT 请求。这为数据增强、授权内容、专用推理及其他按量计费 API 打开了空间。

现有浏览器自动化无需在每个脚本中嵌入钱包 SDK。Playwright 工作流可以照常导航和请求资源，支付则成为该代码之下的一项会话能力。

这一底层能力也改变了服务打包访问权限的方式。提供商可以针对一次查询或一份文档收费，而不必要求用户订阅更广泛的服务。智能体则可以购买完成任务所需的确切资源。

这种模式类似无服务器计算和按量计费的云 API，但资源发现变得更加动态。智能体可以在执行过程中遇到此前未知的付费端点，机器可读的挑战会告诉它如何继续访问。

不过，按请求定价引入了新的规划问题。智能体必须在获取结果前比较其预期价值与成本，也必须识别多个单价不高的购买何时会累积为不必要的支出。

进行竞争研究的智能体体现了这种张力。它可能购买一份授权市场数据集、一份付费文件分析和一条专门的公司记录。每笔购买都可能合理，但重复获取会耗尽任务预算。

因此，具备支付意识的规划器应追踪先前的购买，并缓存可复用结果。它还应在再次付款前识别等效来源。可搜索的技术知识库可帮助团队保留已获批准的材料，避免反复为相同访问权限付费。

AWS 集成负责处理交易边界，但不会取代周边的信息架构。组织仍需建立来源追溯、留存规则、访问控制，以及规范采购数据如何进入后续工作流的政策。

核心竞争在于托管授权与运行时自主性

正在形成的分野，是持有支付权限的代理与通过独立控制平面运行的代理之间的差异。

让运行时环境直接访问钱包看似更简单。代理可以签署请求、发送资金并立即继续执行。开发者也无需依赖托管授权服务。

但这种简单性带来了棘手后果。任何能够触及运行时的攻击，也可能触及签名能力。提示注入、工具滥用、暴露的环境变量或受损依赖项，都可能演变为金融安全事件。

AgentCore 的方法缩小了运行时拥有的权限范围。代理携带支付会话和支持 x402 的工具；钱包集成、凭据、支出限额及证明生成则保留在托管服务边界之后。

这一模式类似于短期有效的云凭据。应用程序获得的权限仅足以完成一项受限任务，而非永久访问某个账户。即使支付工作流较新，其背后的原则也并不陌生。

Anchor Browser 通过将网页交互限制在托管会话内，增加了另一层边界。同一会话会维护登录状态、导航历史、网络事件和录制记录。因此，支付证据可与触发支付的浏览序列关联起来。

这种关联有助于事件审查。运营人员可以检查导致扣费的导航过程，而非只看到一笔孤立的区块链交易。组合记录为审批、拒付和意外支出提供了更多上下文。

AWS 还表示，Anchor 会将第三方 x402 收费整合到与浏览器使用相同的计费关系中。客户无需为每个自动化工作流管理独立的加密货币余额。这是 Anchor 的服务安排，而非 x402 本身具备的属性。

托管模式也增加了依赖项。可用性如今依赖于 Anchor Browser、AgentCore、所选钱包提供商、商户和结算网络。任一层发生故障，都可能阻断代理的任务。

供应商边界同样重要。Payment Manager 资源、AgentCore Identity、CloudWatch 记录和 AWS 权限都会成为运营模式的一部分。若要将同一工作流迁移到其他环境，可能需要重建策略与可观测性控制。

市场并未收敛到单一协议。Stripe 和 Tempo 推出了 Machine Payments Protocol，该协议采用 HTTP 身份验证质询。Stripe 的 MPP 公告也强调了商户报告、退款、欺诈控制以及结算至既有余额等能力。

Google 的 Agent Payments Protocol 面向更广泛的商业问题。AP2 定义了用户、代理、商户和支付提供商之间的关系。Google 宣布推出 AP2 框架时，有超过 60 家组织参与其中。

这些系统存在重叠，但并不相同。x402 对于可通过 HTTP 访问的资源和按量计费 API 尤其直接。AP2 面向跨支付方式的委托采购，而商业协议则处理目录、结账、履约和商户关系。

AgentCore 已同时支持 x402 和 MPP。这降低了其支付服务仅绑定单一质询格式的风险，也表明 AWS 预计多种机器支付标准将长期共存。

因此，竞争压力将落在那些让代理代码直接发起支付的基础设施提供商身上。企业会越来越多地询问：代理能否在不持有秘密信息的情况下完成支出？它们还会期待在模型之外提供限额、日志、撤销和策略执行机制。

AWS 和 Anchor Browser 给出了一个具体答案。其设计以牺牲部分运行时独立性为代价，换取集中化控制。对企业而言，这种权衡可能比将不受限制的签名权限置于不可预测的软件进程中更具吸引力。

预算限额无法解决欺诈、质量或合规问题

将密钥置于运行时之外能降低凭据暴露风险，但并不意味着每一笔由代理发起的采购都是安全或有价值的。

恶意商户仍可能通过有效的 x402 质询，描述价格过高或质量低劣的资源。AgentCore 可以确认请求符合预算并使用受支持的网络，但这些检查无法验证底层内容的价值。

提示注入仍是另一项担忧。受保护页面可能引导浏览器代理访问额外的付费资源。攻击者无法获取私钥，却可能影响获授权预算的使用方式。

会话限额可以限制最大损失，却不能防止低于阈值的浪费。开发者需要商户白名单、单笔交易限额、类别策略以及针对重复支付的规则。

仅重试一次的规则解决的是一种狭窄的故障模式。它能防止单个请求演变为自动支付循环。但除非更高层级的控制发现这种模式，否则规划型代理仍可能发出大量独立请求。

凭据隔离同样依赖于正确的云配置。AWS 警告称，对提供商秘密信息授予过宽访问权限，可能绕过预期的预算和审计控制。拥有直接秘密访问权限的受损身份，可能在 AgentCore 之外执行钱包操作。

因此，团队必须审查 IAM 角色、秘密访问权限、连接器权限和日志留存策略。托管服务缩小了敏感攻击面，但管理员仍决定谁能接触该攻击面。

结算带来了另一个运营问题。链上支付在退款、争议或错误发生时，可能与银行卡交易表现不同。技术上有效的付款一旦由商户结算，可能很难撤回。

稳定币核算也可能为财务和合规团队增加工作。AWS 表示，Anchor 的计费安排简化了客户体验。组织仍应确认费用、税费、收据和退款将如何体现在自己的记录中。

协议碎片化带来了额外不确定性。商户可能提供 x402、MPP、AP2 或传统结账方式。代理将需要协商逻辑，在不削弱用户策略的前提下选择正确路径。

支持多种协议并不意味着保障措施等效。一种方式可能使用稳定币，另一种则使用代币化银行卡凭据。每种方式在结算、欺诈、隐私和监管层面都具有不同影响。

关于生产可靠性的独立证据也仍有限。AWS 的文章解释了架构和预期行为，但并未公布对比成功率，也没有提供跨商户或网络的支付延迟公开基准。

同样，这一公告也未说明代理目前多常遇到有价值的 x402 资源。Cloudflare 和 Coinbase 支持该标准，AWS 则通过精选 Bazaar 连接提供发现能力。实际商户覆盖率仍是检验采用情况的关键。

开发者应将该集成视为一种能力，而非成熟市场的证明。如果高质量数据提供商没有提供兼容端点，再流畅的支付路径也价值有限。商户参与度必须与客户端基础设施同步增长。

对于许多交易而言，人工审批仍然合适。低价值 API 请求可以纳入预先批准的预算；涉及受监管数据、合同条款或个人信息的采购，则可能需要明确审查。

最稳健的部署模式很可能是分级授权。来自已知商户的常规采购可以在严格限额内自动进行；新卖家、异常金额或敏感数据则可触发审批。

这种策略不能只存在于自然语言提示中。它需要确定性的评估和持久化记录。AgentCore 提供了部分基础，但每个组织都必须界定可接受的交易边界。

Amazon Bedrock AgentCore Payments 的下一步

下一个考验在于，受控支付能否成为常规代理能力，而不只是少数供应商之间令人印象深刻的集成。

第一个信号是商户采用情况。更多出版商、数据供应商、MCP 服务器和专业 API 必须提供 x402 或其他受支持的机器支付质询。此类增长将强化 AWS 的观点：代理需要通用支付层。

这些端点的质量比单纯数量更重要。开发者需要权威、及时且足以证明按请求付费合理性的资源。一个充满实验性端点的目录无法建立持久需求。

第二个信号是企业策略的深度。团队将寻求商户限制、交易级阈值、审批路由、异常检测和统一报告。预算上限是必要条件，但成熟采购需要更精细的规则。

AWS 已提供会话限额和 CloudWatch 可观测性。未来的控制机制应更容易区分常规使用与可疑行为。用户请求、代理操作和已结算费用之间的清晰关联将至关重要。

第三个信号是协议互操作性。AgentCore 对 x402 和 MPP 的支持，已初步承认没有单一标准能够主导市场。开发者将关注 AP2 和商业协议能否与同一策略层顺畅连接。

互操作性将强化托管控制模式。企业可以定义一套支出策略，同时允许代理通过多种协议访问商户。策略碎片化则会削弱这一优势并增加运营风险。

Anchor Browser 还需要证明该功能能够适应真实浏览条件。身份验证、重定向、JavaScript 应用、网络故障和延迟结算，都可能让简洁的六步流程图变得复杂。生产证据应涵盖故障行为，而不只是成功请求。

开发者可以从范围有限的测试用例开始。一个受限的研究代理可以在短期会话内访问一个获批准的付费 API。团队随后可检查其浏览器录制、支付日志、输出质量和总支出。

此类评估应询问付费来源是否改善了结果，还应衡量重复采购、被拒请求、结算延迟和人工干预。交易成功本身并不是正确的结果指标。

构建这些工作流的团队应记录商户选择过程，并保留检索到的证据。它们可以使用 AI workflow审查输出，同时保留每项决策背后的上下文。这使支付记录的价值不止于财务用途。

Amazon Bedrock AgentCore payments 为 Anchor Browser 代理提供了一种可信方法：无需将钱包凭据置于运行时中，也能完成付费任务。其更大的贡献在于，将代理的意图与其财务权限分离开来。

现在，市场必须证明三件事：商户愿意支持机器可读支付，企业会信任这些控制机制，竞争协议能够共存。在向自主代理授予更大预算之前，应关注这些信号。先从一个获批准资源、一个受限会话，以及一套人类能够理解的审计流程开始。