AWS 发布 AgentCore payments 实践案例：Incarna 用 3 天接入 BlockRun，实现按次付费推理
来源AWS Machine Learning查看原文
速览
- AgentCore payments 把支付协议、钱包、签名和限额封装成一个托管服务，开发者只需几行代码接入
- 按次付费推理是高频低价值场景，单笔常低于 1 美分，传统卡组织网络并不适合
- Incarna 的集成从预估数月压缩到 3 天，说明支付基础设施的抽象层已相对成熟
- 限额在基础设施层而非模型层执行，即使提示词被操纵也无法超支
- Agent 拥有独立钱包和身份，链上付款方可归属到具体 Agent 而非共享平台密钥
- BlockRun 作为卖方负责模型选择与交付，Agent 无需为每个供应商单独订阅
AWS 官方博客披露了 Amazon Bedrock AgentCore payments 的一个落地案例：AI Agent 身份平台 Incarna 通过 AgentCore payments，让 Agent 以 x402 协议向推理路由器 BlockRun 按次付费购买模型推理。BlockRun 聚合 15 家以上供应商的 90 多个模型，每次调用独立报价、独立结算。Incarna 原本预估需要 2 到 3 个月完成 x402 支付支持，实际用 3 天完成（1 天开发、2 天测试），约 200 行应用代码。Beta 期间 Agent 已处理超过 1000 笔支付，单笔金额在 0.001 到 0.05 美元之间，每笔都在链上单独结算。
关键事实
- BlockRun 通过 x402 协议提供按需付费推理路由，覆盖 15 家以上供应商的 90 多个模型，每次调用独立报价与结算
- Incarna 完成 AgentCore payments 集成只用了 3 天（1 天开发、2 天测试），约 200 行应用代码，原预估为 2 到 3 个月
- Beta 期间 Agent 已处理超过 1000 笔支付，单笔金额区间为 0.001 至 0.05 美元，每笔在链上单独结算
- AgentCore payments 支持 x402 的 exact 与 upto 两种支付方案，前者用于价格已知场景，后者用于动态定价场景
- 支付在基础设施层执行限额，Agent 的代码和提示词无法突破，每个支付会话还带过期时间，Incarna 按一天预算设置会话
- 结算使用稳定币，Incarna 采用 Base 网络上的 USDC，每笔交易可在链上验证
本站视角
对国内做 Agent 的团队来说，这个案例的价值不在于 AWS 又发了一个功能，而在于它给出了一个可复制的模式：Agent 可以拥有自己的钱包和身份，按次购买推理，且支付限额由基础设施而非模型控制。这直接影响到那些需要让 Agent 自主调用外部 API、但又担心失控超支的团队。我们认为，AgentCore payments 把支付抽象成托管服务，确实降低了接入门槛，3 天完成集成、约 200 行代码是很有说服力的数字。但需要指出的是，这些数据来自 AWS 官方博客和两位合作方创始人的自述，属于单一来源的厂商案例，没有第三方验证，也没有披露失败率、争议处理或退款机制。另外，结算使用 Base 网络上的 USDC，对国内团队而言存在合规和资金通道的现实障碍，短期内更可能被海外团队或面向海外市场的产品采用。值得观察的是，x402 能否从 AWS 生态扩展到更多云厂商和支付服务商，以及 upto 这种动态定价方案在实际计费争议中如何裁定。
背景与影响
AI Agent 在执行任务时经常需要临时购买服务，例如模型推理、API 响应、网页内容访问或调用另一个 Agent。这类交易金额极小、频率极高，且发生在 Agent 循环内部，没有人工审批环节。传统支付网络按笔收费，难以支撑亚美分级别的小额支付。x402 协议试图用 HTTP 402 状态码和链上稳定币结算解决这一问题。Amazon Bedrock AgentCore payments 是 AWS 与 Coinbase、Stripe 合作推出的托管支付能力，支持 x402 兼容端点，包括 Amazon Bedrock 推理端点。本次案例中，Incarna 作为买方 Agent 身份层，BlockRun 作为卖方推理路由，AgentCore payments 负责连接钱包、执行限额和签名。这意味着 Agent 经济的基础设施正在从概念验证走向生产环境，但需要观察的是：链上结算的延迟与成本是否适合更小额的支付，以及企业客户是否愿意接受稳定币结算和链上审计。
本文由 AI 辅助整理自公开信源，事实部分以原文为准；「本站视角」一节为编辑部判断，欢迎指正。版权归原作者所有，如有异议请联系我们。