# 面向 AI 智能体的按次推理付费：Incarna 与 BlockRun 的案例

- Source: MechNext — https://mechnext.eu/zh/article/34-pay-per-inference-for-ai-agents-incarna-and-blockrun
- Published: 2026-10-09
- Updated: 2026-10-09
- Category: Industry News
- Language: zh (Markdown in other languages: ?lang=en, ?lang=de, ?lang=sk, ?lang=pl, ?lang=ru)

> AWS 介绍 Incarna 如何使用 Amazon Bedrock AgentCore payments 和 x402，按每次请求向 BlockRun 支付模型推理费用。

AWS Machine Learning Blog 于 2026 年 10 月 8 日发布了一篇关于 AI 智能体按次推理付费的文章。文章介绍了 Incarna 与 BlockRun 的案例，说明服务费用可以围绕单个请求进行支付。其核心是 Amazon Bedrock AgentCore payments。文章将其描述为一种托管式支付能力，可为智能体处理支付协议、钱包连接、交易签名和支出限额。这个案例关注的不是单独展示价格，而是把支付环节放进智能体请求服务的流程之中。

在文章描述的流程里，智能体请求一项付费服务，服务提供方或商家要求支付，支付能力则把请求与钱包、授权和支付证明联系起来。支付完成后，商家可以收到与该请求相关的加密证明。由于示例涉及模型推理，每次模型调用都可以分别计价、授权和结算。这样描述的支付单位是一次调用，而不是必须把许多次请求合并成一笔总额。

### Incarna 如何配置钱包

Incarna 使用 Coinbase CDP connector 为每个智能体配置钱包。文章称，钱包由客户拥有，客户授予 Incarna 代表其使用钱包的委托授权。这个安排说明了钱包所有权和操作权限的关系：客户是钱包所有者，而 Incarna 获得了在授权范围内使用它的权限。文章把这一钱包设置作为将支付能力接入智能体的一部分来介绍。

AgentCore payments 所处理的内容包括支付协议、钱包连接、交易签名和支出限额。对于一项付费调用而言，支付流程需要关联到一个配置好的钱包，并受到支出边界约束。文章将这些工作作为托管能力的一部分呈现，说明支付不只是智能体发出请求之后再单独处理的环节，还包括钱包接入、签署交易以及限制可用额度等内容。

### 从 HTTP 402 响应到支付证明

文章说明，当服务返回 HTTP 402 响应时，AgentCore payments 可以进行 x402 支付，使用已配置的钱包签署支付，并把加密支付证明返回给商家。商家收到的证明与正在付费的请求相关联。在这一流程中，HTTP 402 响应引出支付处理，配置好的钱包用于签署，随后证明被交还给服务提供方。文章以此说明支付流程如何连接服务请求与付款确认。

Incarna 使用 Base 网络上的 USDC 进行结算。AWS 的文章称，每笔交易都可以在链上验证。这个细节与按请求支付的方式相互对应：交易可以逐笔观察和核验，而不必在示例中将所有请求合并为一笔付款。文章同时描述了付款如何发起，以及交易结算结果如何得到验证。这里所说的可验证性是文章对 Incarna 支付安排的描述。

### 两种 x402 方案与支出边界

文章介绍 AgentCore payments 支持两种 x402 方案。_exact_ 用于价格事先已知的情况；_upto_ 用于动态定价。使用 _exact_ 时，价格在请求执行前已确定。使用 _upto_ 时，智能体授权一个最高金额，服务提供方再根据实际使用量结算，但结算金额不超过该上限。这两种方案对应不同的价格确定方式：一种预先给出确定价格，另一种允许最终金额随实际使用情况变化，同时保留经授权的额度上限。

Incarna 的支付会话设置了支出上限和到期时间。文章称，Incarna 按一天的预算来确定会话额度。会话的金额上限和有效期限为智能体的支付授权划定边界：额度不超过预先设定的上限，会话也不会无限期有效。文章通过一天预算的设置，展示了支付会话可以按照工作期间的预算来安排。这个安排与动态定价方案中的上限相呼应，但二者在文中分别作为方案支持和会话设置来说明。

### 集成时间与测试阶段的支付

AWS 报道称，Incarna 用三天完成 AgentCore payments 集成：一天用于构建，两天用于测试。应用代码约有 200 行。文章还说，最初的估算是两到三个月。这些数字描述的是 Incarna 对这次集成工作的经验，并把原先的时间估算与公司报告的实际完成时间放在一起。它们属于文章对该案例的具体陈述。

在 beta 阶段，智能体处理了超过 1000 笔支付。每次调用的支付金额在 0.001 美元至 0.05 美元之间，并且每笔都单独在链上结算。笔数与金额范围展示了文章描述的使用情形：许多金额较小的支付分别对应单次调用，而不是对一批请求统一收取一个总价。文章提供这些数字，以说明 beta 阶段已经出现的支付活动规模和单次金额区间。

### BlockRun 与推理付费

文章将 BlockRun 描述为一个按使用付费的推理路由器，通过 x402 提供模型推理服务。每次调用都会单独报价、授权、付款，并在 Base 网络上以 USDC 结算。结合 Incarna 的案例，这构成了一种智能体请求模型推理、并在每个调用上重复支付流程的安排。路由服务与付款流程在文章中围绕单次调用建立联系。

BlockRun 的案例强调每次调用分别报价和结算；Incarna 的案例则说明智能体的钱包配置、委托使用授权、会话支出限额以及 HTTP 402 的处理方式。两者都涉及通过 x402 支付模型推理费用，并使用 Base 网络上的 USDC 进行结算。文章把这些内容放在同一个讨论中，展示 AgentCore payments 如何承担支付协议、钱包连接、签名和限额管理等环节。

### 这些案例提供了哪些信息

AWS 的文章列出了几个具体方面：托管支付能力覆盖的功能、客户拥有而由 Incarna 经授权使用的钱包、HTTP 402 响应后的 x402 支付步骤、_exact_ 与 _upto_ 两种方案，以及支付会话的限额和到期时间。文章还报告了三天的集成时间、约 200 行应用代码、beta 阶段超过 1000 笔的支付，以及每次调用 0.001 至 0.05 美元的金额范围。

这些信息共同描述了按次支付的组成部分。价格方案决定如何表达一次调用的费用；钱包和授权决定使用哪个支付账户及其权限；限额和到期时间为会话设定边界；签名和支付证明则把付款与请求及商家连接起来。Incarna 和 BlockRun 的例子分别呈现了这些要素在推理服务场景中的使用方式。以上内容均为 AWS 文章所报告的案例与说明。
