独立解读
AWS AgentCore Payments：给 Agent 安排付款，但钱包由谁提供？
产品分析｜资料核对：2026-10-28｜公开资料研究，未创建 AWS 资源或测试支付
一个研究 Agent 访问付费 API 时，要处理付款要求、检查预算、调用钱包签名，再拿凭证重试请求。AWS 的 AgentCore Payments 把这些步骤放到托管编排层中，连接外部钱包及 Agent 运行环境。它不是 AWS 自行发行的一只独立钱包。
背景与产品位置
AWS 于 2026 年 8 月宣布 AgentCore Payments 正式可用，官方公告列出 Coinbase 和 Stripe Privy 钱包连接、支付限额、可观测性，以及 x402 和 MPP 支持。GA 公告。地区、具体钱包和协议方法依产品状态而异。
| 参与方 | 承担的工作 |
|---|---|
| Agent 开发者 | 配置支付管理、会话预算、钱包连接和业务流程 |
| 用户 | 通过钱包提供方建立钱包、充值和授权 Agent |
| AgentCore Payments | 管理支付会话、检查配置限制、编排支付请求 |
| Coinbase 或 Privy | 提供连接的钱包与签名能力 |
| 付费服务商 | 提出支付条件、验证付款并交付内容 |
一次付费 API 调用
根据 AWS 工作原理，开发者先配置支付工具及有期限的会话；在支持的 x402 路径中，服务商返回 402、AgentCore 检查额度，通过钱包提供方签署，Agent 随后重试。MPP 使用不同的挑战和凭证头。上图是概念示意，具体支付和结算顺序要按协议方法及实现核对。
规则与限制
| 关注点 | AWS 描述 | 还要验证 |
|---|---|---|
| 会话预算 | 可以设置金额与过期时间，达到条件后拒绝 | 范围、并发请求及资产币种处理 |
| 钱包权限 | 用户通过钱包服务授权 Agent | 撤销和恢复由具体提供方决定 |
| 密钥与凭证 | AgentCore Identity 管理敏感凭证 | 组织 IAM、日志与权限配置 |
| 失败 | 文档描述失败时释放预算预留、记录失败 | 网络超时后商户是否已收款、如何避免重复扣费 |
| 可用范围 | 官方列出支持的提供方和协议 | 地区、资产、网络、账户开通条件 |
AWS 故障排查材料提示 MPP 支持可能取决于账户启用状态，且某些方法与钱包提供商组合有限制；不能从“支持 MPP”推断所有网络组合均可用。故障排查
钱从哪里赚、账怎么算？
AWS AgentCore 定价说明：Payments 的 CreateInstrument 和 ProcessPayment 按所选钱包服务商的操作费用计费，除此之外的 Payments API 调用无额外费用；Coinbase 的两项调用各算一次钱包操作，Privy 的创建免费、支付处理算一次钱包操作。AgentCore 的 Runtime、Gateway 或日志等周边服务可能另计，数据服务商与链上费用也应核对。AWS 文档指出 Coinbase 连接需要订阅 AWS Marketplace 对应产品；订阅本身无额外订阅费，但 Coinbase 使用费按其价格计入 AWS 账单。订阅说明。
分析推断：AWS 可以借钱包伙伴扩展 Agent 平台，并从相关云服务用量获益；不能据此假定 AWS 在钱包操作费中获得分成。公开资料未披露 Payments 的单独营收。
与直接接钱包相比
对已用 AWS、希望预算控制与日志融入现有云工作流的企业，AgentCore 减少自行拼接环节，但需要接受其支持的连接器、区域和协议范围。直接接钱包可以拥有更多自定义空间，却要自行处理凭证、控制与可观测性。选型时应针对同一个 API 场景估算 AWS 调用、钱包、链和数据服务的总费用，并模拟超额、商家超时及重复请求。
从创建连接到第一次付费
假设一个已经运行在 AWS 的研究 Agent 需要读取收费 API。开发者首先建立 Payment Manager 与钱包 Connector，选择 Coinbase CDP 或 Stripe Privy。Coinbase Quick Create 允许在浏览器中完成授权并由服务配置凭证；Privy 则按文档提供现有凭证。使用 Coinbase 前，还需要相应 AWS Marketplace 订阅。创建 Connector
接着创建 Payment Instrument 和 Payment Session：前者关联用户的钱包，后者定义有期限的支付上下文与可选预算。用户通过对应 WalletHub 登录、入金并授予 Agent 权限。Agent 请求受保护接口，收到相应 402 挑战后，使用 ProcessPayment 处理并提交返回的凭证，再由服务商决定能否交付。具体环节和授权范围取决于提供方及协议。处理支付
这是一条文档路径，不代表我们已经开设 AWS 账户或付款。特别是用户批准 Agent 使用钱包与 AWS 会话预算是两个控制环节：一个被撤销或失效，另一个仍可能存在，应用需要把状态向用户说清楚。
出错时应该查哪里？
| 现象 | 根据 AWS 文档首先检查 | 避免的错误 |
|---|---|---|
| Coinbase 连接 403 | Marketplace 订阅及 IAM 权限 | 反复重建钱包但不处理订阅 |
| 授权失效 | 用户是否撤销或未完成钱包授权 | 以为会话预算足够就能签名 |
| MPP 挑战无效 | 请求头、协议方法及账户权限 | 把不兼容挑战当成余额不足 |
| 服务商请求超时 | 日志、支付和商户状态 | 仅凭超时就重复付款 |
| 支付被拒绝 | 会话预算、余额和第三方策略 | 只检查 Agent 的自然语言指令 |
AWS 文档列举了如委托签名未激活、Marketplace 订阅缺失及 MPP 方法限制等具体错误；不同问题应按错误代码和提供方定位。故障排查
举例算一算，哪些费用在谁的账单？
假设开发者创建 100 个 Coinbase 工具，并处理 1,000 次支付，按 AWS 页面描述，这会映射为 1,100 次钱包操作，具体金额按 Coinbase 当时定价。若使用 Privy，页面描述 CreateInstrument 免费，而 ProcessPayment 映射到钱包操作，且仍需遵守 Privy 的套餐及额度。以上是对计费单位的示例，不是对某个客户最终账单的承诺。AWS 价格页
同时还要分开核算购买的 API 内容、Agent Runtime、Gateway、日志、模型推理、网络与兑换等费用。若 Agent 请求很多低价服务，支付处理的固定操作费与模型/日志成本都可能影响是否值得按次采购；先用预估调用量和真实报价做敏感性分析。
对目标客户的意义
对于已经使用 AgentCore 的企业，价值在于把钱包连接、会话预算和观测接入已有云流程。对于希望不绑定 AWS、直接控制协议处理的开发者，自行对接钱包可能更灵活，但也需要自己负责凭证、并发预算和排错。当前官方列示的提供方及网络限制值得重点比较，不能假定任何已有钱包都能连接，也不能把商户内容真实性归给 AgentCore 验证。