亚马逊AWS官方博客
用 Amazon Bedrock AgentCore Payment 构建自主支付 AI Agent: x402 协议实战
摘要:本文基于 AWS Agentcore和开源项目 sample-agentcore-cloudfront-x402-payments,完整记录了使用 Amazon Bedrock AgentCore 构建一个能自主发现付费服务、执行链上支付并获取内容的 AI Agent 的实践过程。文章以 AgentCore 的三大核心能力(Runtime、Gateway、Payments)为主线,结合 x402 协议的支付流程,展示 Agent 如何在不接触私钥的前提下完成”请求 → 402 挑战 → 链上支付 → 内容交付”的完整闭环。
目录
一、背景:为什么 Agent 需要支付能力
AI Agent 正从”对话助手”演进为”自主执行者”——它需要实时购买数据、调用付费API、代用户完成交易。但传统支付体系是为人类设计的:需要身份验证、手动确认、最低手续费让微支付不可行,预置 API Key 的方式更无法应对动态发现数千种服务的场景。
Agent 需要的是一种原生的、可编程的支付能力:在预授权范围内自主交易,有预算治理和可观测性,且不中断推理循环。Visa、Mastercard 等传统巨头已在布局 Agent支付方案。
2026 年 5 月,AWS 发布了 Amazon Bedrock AgentCore Payments(Preview),为 AI Agent 提供了原生的托管支付能力。让 Agent真正具备”能做事、能花钱”的闭环能力。本文通过一个完整的 PoC 项目,展示如何将 AgentCore Payments 与 x402 协议结合使用。
二、项目介绍与整体架构
2.1 开源项目简介
本文基于 AWS 官方开源项目 sample-agentcore-cloudfront-x402-payments 展开。该项目演示了一个 HTTP 402 付费内容门禁系统:
- Payer(付款方):运行在 AgentCore Runtime 上的 AI Agent,通过 AgentCore Payments 执行支付
- Seller(卖家):CloudFront + Lambda@Edge 构建的 x402 付费内容网关
- Web UI:React 前端,提供 3 步交互界面(请求内容 → 确认支付 → 查看内容)
2.2 整体架构
[图1] |
2.3 业务模块组成
项目由三个独立部署的模块组成:
| 模块 | 职责 | 部署方式 |
| seller-infrastructure | 付费内容网关:接收请求 → 返回 402 → 验证支付 → 交付内容 | CloudFront + Lambda@Edge + S3(us-east-1) |
| payer-infrastructure | 付款方基础设施:IAM 角色、Agent 运行时、支付配置 | AgentCore Runtime + Payments + Gateway |
| web-ui-infrastructure | 用户交互界面:浏览器 → API Gateway → Lambda → AgentCore | CloudFront + S3 + API Gateway + Lambda |
用户通过 Web UI 发起请求,请求经 API Gateway 转发到 AgentCore Runtime 中的 Agent。Agent 自主完成”发现服务 → 请求内容 → 处理支付 → 获取内容”的完整流程。
三、系统架构:支付流程与技术实现
3.1 支付流程总览
下面的序列图展示了一次完整支付交易的全貌(6 个泳道、12 步消息):
[图2] |
接下来我们按三个阶段逐一展开。
3.2 阶段一:发起请求 & 402 挑战
[图3] |
技术要点
1. AgentCore Gateway 的 MCP 工具发现:Agent 不硬编码服务列表,而是通过 Gateway 的 MCP 协议动态发现。Gateway 将 OpenAPI spec 转换为标准 MCP 工具,Agent 可以获取每个服务的价格、网络、资产等元数据。
2. Lambda@Edge 的 402 响应:当请求不携带 X-PAYMENT-SIGNATURE header 时,Lambda@Edge 根据路径匹配定价配置,返回标准 x402 v2 格式的支付要求(包含 scheme、network、amount、payTo、asset 等字段)。
3. AgentCore Runtime 的会话管理:每次 InvokeAgentRuntime 调用通过 runtimeSessionId 维持上下文,Agent 在后续步骤中能记住 402 返回的 x402_payload。
对应代码——request_content 工具检测 402 并提取支付要求:
3.3 阶段二:服务端签名(信任边界)
这是整个流程中最敏感的环节——涉及私钥操作,但 Agent 代码完全不参与:
[图4] |
技术要点
1. 4 角色 IAM 最小权限模型:Agent 只能 AssumeRole 到 ProcessPaymentRole(只有 bedrock-agentcore:ProcessPayment 权限),不能创建 session、instrument 或直接访问凭证。
2. AgentCore Payments 的预算控制:ProcessPayment 调用时,服务端首先校验 session 的 maxSpendAmount。如果累计花费超过预算,直接返回 REJECTED,不会到达 CDP。
3. EIP-3009 签名:这是 USDC 合约原生支持的”无 gas 授权转账”标准。签名后生成的 authorization 包含 from、to、value、validAfter、validBefore、nonce 等字段,后续由 Facilitator 在链上执行。
4. proof 不进入 LLM 上下文:签名结果缓存在 Agent 的模块级变量中,不会作为对话内容传给 LLM,避免敏感数据泄露。
对应代码——process_payment 工具:
3.4 阶段三:结算 & 内容交付
Agent 带着 payment proof 重试请求,Seller 验证签名并在链上结算:
[图5] |
3.4.1 技术要点
1. x402 Facilitator 的角色:Facilitator(x402.org)是一个公共服务,负责验证 EIP-3009 签名的有效性并在链上执行 transferWithAuthorization 调用。Seller 不需要自己跟区块链交互。
2. Lambda@Edge 的本地校验:在调用 Facilitator 之前,Lambda@Edge 先做本地校验(payload 结构、时间窗口、金额匹配、收款地址匹配),快速拒绝明显无效的请求。
3. 指数退避重试:链上交易需要约 2 秒出块。Agent 的 request_content_with_payment 工具内置了指数退避重试逻辑——如果 Seller 仍返回 402(说明链上还没确认),等待后重试。
4. 结算证明:成功后 Seller 在 X-PAYMENT-RESPONSE header 中返回 Base64 编码的结算信息(包含 txHash),Agent 可以提供给用户在区块浏览器上验证。
对应代码——request_content_with_payment 工具(带指数退避):
3.5 图表与 Web UI 操作的对应关系
| 阶段 | 序列图 | 对应 Web UI 操作 | 前置依赖 |
| 阶段一 | 3.2 发起请求 & 402 挑战 | Request Content 按钮 | 无 |
| 阶段二 | 3.3 服务端签名 | Confirm Payment 按钮(前半) | 依赖阶段一的 x402_payload |
| 阶段三 | 3.4 结算 & 内容交付 | Confirm Payment 按钮(后半) | 依赖阶段二的 proof |
| — | 无新后端交互 | View Purchase Record 按钮 | 展示已获取的内容 + txHash |
3.6 AgentCore 三大组件总结
在上述三个阶段中,AgentCore 的三个组件各司其职:
| 组件 | 在流程中的角色 | 核心能力 |
| Runtime | 阶段一~三全程:托管 Agent 容器,维持会话上下文,管理生命周期 | 容器化部署、会话管理、自动扩缩、networkMode: PUBLIC 外网访问 |
| Gateway | 阶段一(可选):将 OpenAPI spec 转换为 MCP 工具供 Agent 发现 | MCP 协议、OpenAPI 转换、工具路由、认证注入 |
| Payments | 阶段二核心:预算校验 + 服务端签名,Agent 永不接触私钥 | ProcessPayment API、session 预算控制、CDP 凭证托管、审计追踪 |
3.7 x402 协议实现要点
3.7.1 v1 vs v2 的兼容处理
本项目同时支持 x402 v1 和 v2 协议:
| 方面 | v1 | v2 |
| 支付要求位置 | 响应 body | PAYMENT-REQUIRED header(Base64 JSON) |
| 支付 proof header | X-PAYMENT | PAYMENT-SIGNATURE |
| proof 对象字段 | x402Version, scheme, network, payload | x402Version, resource, accepted, payload, extension |
| merchant payload 处理 | 完整透传 | 剥除 description, mimeType, resource, outputSchema |
Agent(content.py)和 Lambda@Edge(payment-verifier.js)都实现了双向兼容:接收时两种 header 都尝试解析,发送时按 x402Version 字段决定格式。
3.7.2 防重放 & 防篡改机制
- nonce:32 字节随机数(0x + 64 hex),每次支付唯一,防止重放攻击
- 时间窗口:validAfter / validBefore 必须包含当前时间 + 6 秒(留出出块时间)
- 地址校验:payTo 小写比较,防止大小写欺骗
- 金额校验:value >= amount 用 BigInt 比较,避免浮点误差
- 签名长度:至少 130 hex(EOA 签名),智能钱包签名可更长
3.7.3 为什么 POST 收到 402 后要用 GET 重新获取支付要求
原因:x402 Facilitator 在 verify 时会用 GET 重新拉取 payment requirement 作为签名校验的基准。如果 Agent 从 POST 的 402 响应里取 payload 签名,Facilitator 得到的 canonical payload 会不一致,导致校验失败。
四、部署概要
4.1 前置条件
| 工具 | 版本 | 用途 |
| AWS CLI | ≥ 2.15 | AWS 资源操作 |
| boto3 | ≥ 1.43.0 | AgentCore API |
| Docker | ≥ 20 | 构建 Agent 镜像 |
| Node.js | ≥ 18 | Lambda@Edge |
| Python | 3.12 | Agent 代码 |
4.2 准备 Coinbase CDP 凭证 + 钱包
整个 demo 涉及 2 个钱包:付款钱包(Agent 用,部署时由 AgentCore Payments 自动创建)和收款钱包(需要手动创建)。两者都通过 Coinbase Developer Platform (CDP) 管理。
4.2.1 注册 CDP 账号
打开 https://portal.cdp.coinbase.com ,邮箱注册,测试网阶段不需要 KYC。
4.2.2 创建 API Key
1. 左侧 Dashboard → 蓝色按钮 Create API Key
2. 填名字(例如 x402-demo-agentcore),权限选 Full access
3. 创建后下载 JSON 文件(含 id 和 privateKey)
4.2.3 生成 Wallet Secret
- 左侧 Wallets → Server Wallet
- 顶部 Accounts tab 下有 Wallet Secret 区块
- 点 Generate new secret,弹窗显示 secret,立刻保存
4.2.4 创建收款钱包(EVM EOA)
CDP Portal 没有 GUI 创建账户功能,需要用 CLI:
4.2.5 启用 Delegated Signing
在 CDP Portal 中:左侧 Embedded Wallets → Policies 标签 → 打开 Delegated Signing 开关。
4.2.6 付款钱包的创建与授权
付款钱包在部署步骤 2 中由 CreatePaymentInstrument API 自动创建,返回: – walletAddress:付款钱包地址 – redirectUrl:WalletHub 授权链接
用户需要访问 redirectUrl,用注册邮箱登录后: 1. 在 Permissions 区域点击 Grant permission,授权 Agent 代签 2. 在 Balances 区域充值 USDC,或通过 https://faucet.circle.com/ 领取测试网 USDC(选 Base Sepolia 网络)
4.2.7 两个钱包的区别
| 付款钱包(Payer) | 收款钱包(Seller) | |
| 创建方式 | AgentCore Payments 自动创建 | 开发者用 CDP CLI 手动创建 |
| 类型 | Embedded Wallet | Server Wallet (EOA) |
| 谁控制 | AgentCore 代签(需用户授权) | 开发者完全控制 |
| 用途 | Agent 付款 | 接收付款 |
| 配置位置 | AgentCore Payments 环境变量 | seller-infrastructure/.env 的 PAYMENT_RECIPIENT_ADDRESS |
4.3 部署步骤
步骤 1:部署卖家侧(us-east-1)
这一步创建: – S3 内容桶(存放付费内容) – Lambda@Edge 函数(x402 支付验证器,Node.js 20) – IAM 执行角色(Lambda + edgelambda 双信任) – CloudFront OAI + 桶策略 – CloudFront 缓存策略(禁缓存 + 转发 x402 header) – CloudFront 分发(关联 Lambda@Edge 为 origin-request 触发器)
关键命令:
验证:curl -i https://dXXX.cloudfront.net/api/premium-article 应返回 HTTP 402 + x-payment-required header。
步骤 2:配置 AgentCore Payments
这一步创建 5 个资源,形成完整的支付链路:
- Credential Provider(安全存储 CDP 凭证到 AgentCore Identity)
- Payment Manager(顶层协调资源,指定授权方式)
- Payment Connector(关联 CDP 凭证提供者)
- Payment Instrument(创建付款钱包,返回 walletAddress + redirectUrl)
- Payment Session(设置预算上限和有效期)
关键代码:
步骤 3:创建 IAM 角色
这一步创建 4 个角色,实现最小权限分离:
| 角色 | 权限 | 信任实体 |
| ProcessPaymentRole | 只能 bedrock-agentcore:ProcessPayment | Account root + RuntimeRole |
| ManagementRole | 管理 instrument/session,显式 Deny ProcessPayment | Account root |
| ResourceRetrievalRole | secretsmanager:GetSecretValue + bedrock-agentcore:* | bedrock-agentcore.amazonaws.com |
| AgentRuntimeRole | Bedrock 调用 + ECR 拉取 + AssumeRole 到 ProcessPaymentRole + CloudWatch Logs | bedrock-agentcore.amazonaws.com |
步骤 4:部署 Agent 到 AgentCore Runtime
这一步完成: – 创建 ECR 仓库 – 构建 Docker 镜像(Python 3.11 + Strands Agents + FastAPI + Uvicorn) – 推送镜像到 ECR – 创建 AgentCore Runtime(容器模式 + PUBLIC 网络) – 创建 Runtime Endpoint
关键命令:
步骤 5:部署 AgentCore Gateway
这一步创建: – Gateway(MCP 协议类型) – API Key Credential Provider(Gateway 强制要求,CloudFront 本身不需要认证) – Gateway Target(OpenAPI schema 类型,将 OpenAPI spec 转换为 MCP 工具)
关键代码:
验证:
步骤 6:部署 Web UI
这一步创建: – API Lambda(Python 3.12,代理浏览器请求到 AgentCore Runtime) – API Gateway REST API(4 条路由:health / info / invoke / wallet) – S3 静态网站桶 + OAI – CloudFront 分发(SPA 路由 + 404/403 → index.html) – 构建并上传 React 前端产物
关键注意事项:
五、结语
Amazon Bedrock AgentCore 通过 Runtime + Gateway + Payments 三个组件,为 AI Agent 提供了从部署、工具发现到自主支付的完整基础设施:
- Runtime 解决了”Agent 在哪里运行”——托管容器、自动扩缩、会话管理
- Gateway 解决了”Agent 如何发现工具”——MCP 协议、OpenAPI 转换、集中治理
- Payments 解决了”Agent 如何付费”——服务端签名、预算控制、审计追踪
结合 x402 协议,AI Agent 可以像人类浏览付费网站一样,自主发现、评估、购买和消费付费内容——而开发者只需要关注业务逻辑,不需要自建支付基础设施。
参考资源
- Amazon Bedrock AgentCore 文档
- AgentCore Payments 文档
- 示例项目 GitHub
- x402 协议规范
- Strands Agents SDK
- Coinbase Developer Platform
➡️ 下一步行动:
相关产品:
- AWS Lambda — 无需服务器即可运行代码
- Amazon CloudFront — 全球内容分发网络
- Amazon Bedrock — 用于构建生成式人工智能应用程序和代理的端到端平台
- Amazon Bedrock AgentCore — 加快代理投入生产的速度
- Amazon IAM — 身份管理和访问权限
相关文章:
- 基于 Amazon Bedrock AgentCore Runtime 部署 Apache Doris MCP Server为 Quick Suite 等 AI 客户端提供原生数据分析能力
- 自己的工具自己控:MCP Server、Amazon Bedrock AgentCore、Quick Suite集成指南
- AI Agent 的迁移与现代化 — 使用 Amazon Bedrock AgentCore 将 OpenClaw 从单机改造为多租户 Serverless 架构 第四篇
- AI Agent 的迁移与现代化 — 使用 Amazon Bedrock AgentCore 将 OpenClaw 从单机改造为多租户 Serverless 架构 第五篇
- AI Agent 的迁移与现代化 — 使用 Amazon Bedrock AgentCore 将 OpenClaw 从单机改造为多租户 Serverless 架构 第二篇
*前述特定亚马逊云科技生成式人工智能相关的服务目前在亚马逊云科技海外区域可用。亚马逊云科技中国区域相关云服务由西云数据和光环新网运营,具体信息以中国区域官网为准。
本篇作者
亚马逊云科技中国峰会开发者挑战赛现场开启,基于真实业务场景亲手构建 Agent。 |
![]() |






