哲见WISE AITHE INTELLIGENCE JOURNAL
加入讨论
浏览栏目
AWS Machine Learning

Cher Simon

构建使用 Anchor Browser 和 AgentCore 支付进行交易的智能体

AWS与Anchor Browser合作构建能在浏览器会话内自动完成x402付费请求的AI代理：遇到HTTP 402时，AgentCore payments校验会话预算、通过Coinbase CDP或Stripe Privy等钱包签名交易，代理重试请求获取内容，且私钥不进入代理运行时，并经CloudWatch提供支付可观测性。文章偏产品集成方案，未给出独立评估结果。

Agent payment stack with eight embedded components connecting to an x402 API, showing a 402 challenge returning and a retry sent forward
配图来源 · AWS Machine Learning

AI 智能体越来越需要访问按请求计费的网页资源。例如，高级数据集按查询收费，研究 API 按调用计费，付费墙出版商将内容置于付费之后。当 AI 智能体遇到其中某种资源时，服务器会返回 HTTP 402 Payment Required。智能体没有内置的支付机制，会话没有附加预算，也没有程序化的方式来满足该请求。任务停滞，需要人工干预。

具有智能体支付功能的 Anchor Browser 代表智能体处理机器对机器的支付工作流。该功能是与 AWS 生成式 AI 创新中心 Partner Agent Factory合作开发的，现已在 AWS Marketplace上推出。本文介绍 Anchor Browser 如何与 Amazon Bedrock AgentCore 支付 集成，使 AI 智能体能够自主为受 x402 保护的页面和 API 付费。x402 协议是一种基于 HTTP 的机器对机器支付的开放标准。服务器以 402 Payment Required 响应，并附带金额、接受的支付方式以及智能体用于完成交易的支付地址。

Anchor Browser 是一种专为 AI 智能体打造的基于云的浏览器自动化解决方案。每个智能体会话都在一个托管浏览器环境中运行，该环境维护身份验证状态、处理导航、捕获网络请求，并提供页面交互的实时视图。

Amazon Bedrock AgentCore 提供大规模构建、连接和优化智能体的能力。Amazon Bedrock AgentCore 支付是 AgentCore 中的一项完全托管的能力，AI 智能体可利用它自主发现、访问并为 API、Model Context Protocol（MCP）服务器和网页内容付费。AgentCore 支付管理钱包连接，在基础设施层强制执行可配置的支出限额，并通过 x402 协议处理支付。它还通过 Amazon CloudWatch 提供对支付尝试、批准、拒绝和结算的可观测性。

当在 Anchor Browser 中运行的智能体遇到 402 响应时，AgentCore 支付会在配置的预算内授权并完成交易。工作流不间断地继续进行。

挑战

当自主智能体遇到受 x402 保护的资源时，工作流会停滞。智能体发出请求，例如获取一份高级研究报告或调用付费数据增强 API，而服务器以 HTTP 402 Payment Required 响应。由于没有支付机制，本应自主运行的任务现在需要人工干预。

如今，开发人员必须构建整个支付栈。这项工作涉及四类复杂性：

支付协议处理

  • 从 HTTP 响应中检测并解析 402 挑战，并将需要支付的响应与其他 4xx 错误区分开来。
  • 以商家期望的确切格式构建包含加密证明的正确支付标头。
  • 支持多种 支付方案 （exact、upto 和协议变体），而不将特定于供应商的逻辑硬编码到智能体中。
  • 在挑战格式、支持的稳定币或结算时间可能各不相同的 x402 商家实现之间保持兼容性。

安全与密钥管理

  • 存储用于签署支付的私钥，这需要在暴露于不可信输入的环境中实现安全的密钥存储。
  • 管理钱包生命周期操作，包括密钥轮换、凭据刷新和提供商故障转移。

运营韧性

  • 在保留会话状态、Cookie 和请求上下文的同时，携带支付标头重新提交原始请求。
  • 提供幂等性，这对钱包操作至关重要。
  • 通过跨并发代理执行的实时预算跟踪，强制执行每会话和每交易支出限额。

可观测性与合规性

  • 将每一次支付尝试、批准、拒绝和结算记录在审计日志中，以用于合规与对账。

在没有托管支付服务的情况下，代理必须将整个支付栈内化。在每个返回 402 响应的受 x402 保护的调用上，代理必须在内部编排完整的支付流程，包括：

  • 签署证明。
  • 附加正确的头部。
  • 重试请求。
  • 结算交易。
  • 记录结果。

其中每一步都需要开发人员构建、保护并维护的自定义代码。图 1 展示了这一架构。代理包含八个紧密耦合的组件（Wallet、Private Keys、Budget Controls、Sign Proof、Attach Header、Retry Logic、Settle Payment 和 Logging）。代理连接到一个 x402 API，402 质询向后流动，重试向前流动。

Agent payment stack with eight embedded components connecting to an x402 API, showing a 402 challenge returning and a retry sent forward

图1：代理支付栈

安全方面的考量超出了工程工作本身的范畴。

不受控制的支出。 如果在基础设施层面没有强制执行硬性支出限额，一个漏洞、重试循环、提示注入或意外访问都可能触发意外的付款。在循环中重试付费端点的智能体会持续授权付款，直到有人为干预发生。

密钥暴露。 当私钥驻留在代理运行时环境中时，它们与不受信任的网页、第三方工具和外部依赖共享同一个执行环境。这些攻击向量可能会无意中泄露控制真实资金的凭据。

注册流程暴露。 如果签名基础设施可以从运行时访问，威胁行为者就可能尝试访问密钥或将支付重定向到未经授权控制的地址。有效的缓解措施要求密钥从一开始就不进入运行时。

基于浏览器的代理引入了一个额外的约束：支付必须发生在同一个浏览器会话内。否则，会话录制和实时视图将不再与实际执行的内容相符。

解决方案

Anchor Browser 和 AgentCore payments 通过将整个支付堆栈迁移到托管基础设施中来解决这一复杂性。

与无状态工具调用不同，Anchor Browser 提供一个真实的云浏览器，具有持久身份、可重复且确定性的工作流，以及可靠地登录、导航和完成任务所需的会话上下文。身份验证、导航、网络请求、录制和实时视图都发生在同一个浏览器会话内。当需要支付时，交易在该会话内进行。录制捕获从请求到 402 再到支付再到内容交付的完整序列。Anchor 代理内置了一个 x402 工具，可在浏览器上下文中原生处理付费 API 调用。该内置工具无需对现有的基于 Playwright、Puppeteer 或 Chrome DevTools Protocol 的工作流进行任何更改。

AgentCore payments 充当支付层。该服务的核心是 Payment Manager，它是协调 AWS 账户支付操作的顶层资源。创建 Payment Manager 需要指定授权器类型和 IAM 角色。随后 AgentCore 会在 Amazon Bedrock AgentCore Identity 中预置相应的工作负载身份。

其余组件将 Payment Manager 连接到外部钱包基础设施：

  • A PaymentConnector 将 Payment Manager 与外部钱包提供商集成，可以是 Coinbase Developer Platform（Coinbase CDP）或 Stripe Privy。
  • A PaymentCredentialProvider 将钱包提供商的凭据安全地存储在 AgentCore Identity 中。
  • A PaymentInstrument 标识提取资金的具体钱包地址。

Anchor Browser 通过受支持的钱包提供商使用 AgentCore payments 设置钱包，而不会将钱包密钥或私钥置于代理运行时内。AgentCore payments 通过配置的提供商处理钱包操作。对于端点发现，AgentCore 通过 Amazon Bedrock AgentCore Gateway 提供一个精心筛选的 Coinbase x402 Bazaar MCP 服务器，使代理能够以编程方式发现可用的按次付费 x402 端点。

AgentCore payments 重构了支付架构。敏感操作从代理运行时中移出，进入托管服务层。Anchor 代理仅持有两个与支付相关的组件：预算会话和 x402 工具。基础设施（包括身份验证、钱包密钥、支付限制、可观测性和支付证明签名）驻留在 AgentCore payments 层中。图 2 显示了 Anchor 代理连接到 AgentCore payments 托管层，该层处理与 Coinbase CDP 或 Stripe Privy 的钱包提供商集成。

Anchor Agent connecting to the AgentCore payments managed layer, which integrates with Coinbase CDP or Stripe Privy wallet providers

图 2：Anchor Browser 与 AgentCore payments 集成

支付流程的工作原理

以下步骤描述了从浏览器会话遇到受 x402 保护的资源到代理接收响应并继续任务的端到端过程。

  1. Anchor Browser 为该浏览器会话创建一个专用的 AgentCore PaymentSession。 当会话在开启 x402 的情况下启动时，Anchor Browser 通过 AgentCore payments 预置一个 PaymentSession，将浏览器会话链接到已配置的支付工具和预算。
  2. 浏览器收到 HTTP 402 Payment Required 响应。 代理导航到一个 URL，或发起 fetch 或 XMLHttpRequest (XHR) 请求。商户以一个 402 质询作为响应，其中指定金额、接受的支付方式和支付地址。
  3. 浏览器选择一种兼容的支付方式。 Anchor Browser 读取 402 质询负载，并将所请求的支付方式与绑定到 PaymentSession 的支付工具进行匹配。
  4. AgentCore 验证会话预算并生成加密支付证明。 AgentCore payments 验证支付金额是否在会话消费限额之内。然后，该服务使用配置的钱包提供商（Coinbase CDP 或 Stripe Privy）对交易进行签名，并返回加密证明。任何密钥材料都不会进入浏览器或代理运行时。
  5. 浏览器附带支付头重试原始请求。 浏览器将签名的证明作为 PAYMENT-SIGNATURE 附上（针对 x402 v2），或作为 X-PAYMENT 附上（针对 x402 v1），然后仅重试原始请求一次。
  6. 商户验证并结算支付，然后返回受保护的资源。 商户验证加密证明，在链上结算交易，并提供内容。代理继续执行任务。

在整个流程中，钱包凭证始终保留在 AgentCore 和所配置的钱包提供商处。

前提条件

开始之前，请确保您拥有有效的 Anchor Browser API 密钥（ANCHOR_API_KEY）。要创建密钥，请参阅 Anchor Browser 的 快速入门 指南。

设置自动 x402 付款

为 Anchor Browser 设置代理付款只需一个会话属性。将 session.x402 设置为 true。该属性默认为 false。启用后，浏览器会话可以自动访问受 x402 保护的网站，付款由 AgentCore payments 签名并在同一浏览器会话内重试。启用 session.x402 即授权浏览器从所配置的付款工具进行真实付款。

以下示例展示了如何使用 cURL 和 JavaScript 为 Anchor Browser 创建启用付款的会话：

cURL

curl --request POST
--url https://api.anchorbrowser.io/v1/sessions
--header "anchor-api-key: $ANCHOR_API_KEY"
--header "content-type: application/json"
--data '{"session":{"x402":true}}'

JavaScript

const response = await fetch('https://api.anchorbrowser.io/v1/sessions', {
  method: 'POST',
  headers: {
    'anchor-api-key': process.env.ANCHOR_API_KEY,
    'content-type': 'application/json',
  },
  body: JSON.stringify({ session: { x402: true } }),
});
const { data: session } = await response.json();
console.log(session.cdp_url);

通过 Chrome DevTools Protocol 连接后，代理即可正常导航。您无需在自动化代码中包含钱包密钥或付款标头。浏览器会透明地处理 402 挑战、付款签名和重试，涵盖文档导航、fetch 和 XHR 请求。

付款会话限制与行为

Anchor Browser 通过 AgentCore payments 集成在会话级别实施以下防护措施。每个支持付款的浏览器会话都在所配置的支出和时间限制内运行。具体限制请参阅 Anchor Browser 技术文档.

如果商户响应格式错误、未提供兼容网络、预算已耗尽，或 AgentCore payments 拒绝付款，浏览器将原样向页面返回原始 402 响应。您的自动化代码随后可以将 402 作为标准 HTTP 错误进行处理。

x402 会话属性仅控制对第三方资源的付款。该属性不能替代 Anchor 积分，也不用于支付浏览器会话费用。

Anchor Browser 的自动化代码

您针对 Anchor Browser 的自动化代码保持不变。以下示例表明无需任何付款专用代码：

const { chromium } = require('playwright');
// Connect to the x402-enabled session via CDP
const browser = await chromium.connectOverCDP(session.cdp_url);
const page = await browser.newPage();
// Navigate to an x402-protected resource exactly as with a free page
await page.goto('https://premium-research.example.com/market-report');
// The page loaded, the payment was handled automatically
// Extract content as normal
const content = await page.textContent('article');

无需钱包逻辑、无需构造付款标头，也无需重试代码。代理导航到该 URL。如果服务器返回 402，Anchor Browser 会与 AgentCore payments 协作签署付款证明，使用相应的付款标头重试请求，并将内容交付给页面。您的自动化代码收到最终渲染的页面，且不会察觉到曾发生付款。

此模式统一适用于付费新闻、授权金融数据、受限 API 文档、按量计费的研究数据库以及其他通过 402 挑战限制内容访问的资源。

使用内置 x402 工具进行 API 调用

付费资源不仅限于网页。许多资源是要求 POST、PUT 或其他 HTTP 方法的 API。常见示例包括数据增强服务、高级推理端点和授权内容 API。对于这些用例，Anchor Browser 代理内置了一个 x402 工具，您可以在浏览器上下文中像标准 HTTPS API 一样调用它。

您的代理通过 fetch 或 XHR 进行 API 调用。如果服务器返回 402 挑战，浏览器会通过 AgentCore payments 协调付款签名，并使用已签名的付款标头重试请求。您的代码收到的响应就好像该端点是免费的一样。该工具不与特定供应商、模型或框架绑定。付款作为会话级能力在您现有工具链之下运行，无需更改代理代码。

// Fetch call to a paid API endpoint within the x402-enabled session
const response = await page.evaluate(async () => {
  const res = await fetch('https://data-enrichment.example.com/api/v1/enrich', {
    method: 'POST',
    headers: { 'content-type': 'application/json' },
    body: JSON.stringify({ company_domain: 'example.com' }),
  });
  return res.json();
});
// If the API returned 402, AgentCore handled payment automatically
// The response contains the enriched data
console.log(response);

您的自动化代码不会收到钱包凭证。仅当 session.x402 设置为 true 时，自动付款才可用，并且仍受上一节所述的支出和过期限制约束。

主要优势

此集成将支付从应用代码迁移到基础设施层：

无需构建任何支付基础设施。 无需集成钱包 SDK，无需编写 402 响应解析器，无需实现重试循环，无需维护请求头构造逻辑，也无需构建自定义审计日志。AgentCore payments 管理整个支付栈。

无需对现有工具进行任何更改。 Anchor Browser 中的 Playwright 脚本、Puppeteer 自动化、Chrome DevTools Protocol 命令和 agent 流程仍与之前完全一样正常运行。支付是附加到浏览器上的会话能力，而不是对 agent 逻辑、提示词或工具定义的修改。

私钥不会进入运行时。 签名和结算在 AgentCore payments 内部完成。该服务通过 AgentCore Identity 中的安全凭据存储与 Coinbase CDP 或 Stripe Privy 通信。agent 运行时无法访问可移动资金的密钥材料。

预算在基础设施层面强制执行。 每个会话都在 AgentCore 在授权支付前强制执行的既定支出限额内运行。Amazon Bedrock AgentCore Observability 通过 Amazon CloudWatch 提供完整的支付审计跟踪。当会话达到支出限额时，AgentCore payments 会拒绝该支付。

付费任务成功完成。 付费 GET 页面正常加载。付费 API 调用返回响应。agent 完成整个工作流，而不是停在 402 响应处并需要人工干预。

账单合并统一。 Anchor Browser 将第三方 x402 费用以积分形式与浏览器会话时长结算在同一张发票上。无需管理单独的加密货币托管，无需监控 USDC 余额，财务团队也无需对链上结算进行对账。

结论

Anchor Browser 与 AgentCore payments 集成，使 AI 代理能够自主处理 x402 付费墙网页和付费 API 端点的支付挑战。钱包凭证不会进入代理代码，也无需自定义支付基础设施。

随着越来越多的网络转向按请求计费，缺乏支付机制的代理无法完成涉及付费资源的任务。此集成解决了这一缺口：代理可以在定义的预算内端到端地完成付费工作流，通过 AgentCore Observability 获得完整的可观测性，并且运行时中不含加密密钥材料。

要开始使用，请探索以下资源：

关于作者

原始出处

AWS Machine Learning

内容说明

原始发布及相关权利归来源方。

机器翻译 · 请以原文为准