塞尔根·乌伊萨尔

2026年3月17日 — 阅读时间6分钟

大多数关于x402 的讨论x402 将其x402 API 密钥的替代方案。实际上，这两者各司其职，开发人员应根据自身具体的架构来选择合适的工具。

API密钥x402 区块链基础设施的两种不同访问模式：一种基于账户凭证，另一种基于互联网原生支付。了解两者的区别，有助于更轻松地决定何时使用哪种模式。

本文详细分析了每种模型的工作原理，以及现代基础设施为何越来越需要同时采用这两种模型。

凭证模型是围绕账户身份构建的

当前访问开发者基础设施的模式假设在入口处存在一位身份明确、可追责的人员。您使用身份信息（电子邮件地址、所属组织）进行注册，获取凭证，并长期管理这些凭证。

这种模式运行良好，支持的对象远不止人类用户。Agents 管理 API 轻松管理终端、监控计费情况，并与基础设施进行交互。但该系统仍然假设，这些凭证背后的账户属于某个人。必须有人进行注册。必须有人签发凭证。必须有人对该账户负责。

对于agents 动态启动、跨多个服务运行，或在没有单个人类负责工作流的系统中运行agents AIagents ，这一假设便成为了一处阻力点。这并非因为工具本身存在缺陷，而是因为该模型在设计之初就未曾考虑过在没有持久账户关系的情况下进行访问的情况。

这就是x402 空白。

x402：一种原生于HTTP的支付层

x402 是由 Coinbase 开发的一种开放协议，为HTTP提供了原生支付机制。它重新激活了长期未被使用的HTTP 402“需要支付”状态码，并将其转变为机器间商务的实用标准。

flow 很简单。

1. 客户端请求一项资源。

2. 服务器返回 HTTP 402 状态码，并在响应中嵌入了支付要求（价格、接受的代币、支持的支付网络）。

3. 客户端签署一份受支持的支付授权，并在 X-PAYMENT 头中包含该支付信息后重新发送请求。

4. 服务器通过中介机构验证支付，在链上完成结算，并返回资源。

无需账户。无需 API 密钥。无需注册。任何拥有已充值钱包的客户端均可立即付款并开始发送请求。

agent 之所以重要，不仅仅是因为不需要账户，更在于整个访问生命周期都变得可编程了。agent 单一工作流中，自动查询服务费用、从自身钱包中支付访问费用、消耗资源并继续执行后续操作，整个过程无需任何人工干预。

该协议在设计上具有无状态和跨链特性，这对其实践中的具体实现方式至关重要。下文将对此进行详细说明。

两种访问模式

但这一切丝毫不会削弱 API 密钥所提供的价值。

随着x402 与标准 API 密钥访问x402 ，区块链基础设施现已支持两种截然不同的访问模式。二者之间的选择取决于访问模式，而非参与者类型。

Account-based access (API keys) gives teams full operational control over their infrastructure. This includes configurable rate limits, usage monitoring, predictable billing, and team-level management. It also provides one-stop-shop access to the broader Quicknode platform, including services like Streams, Webhooks, and the Admin API. This model works for teams and their agents alike. An agent operating with an API key has the same platform access as any other client, including administrative capabilities. The credential model fits here because there is a team accountable for it.

基于按次付费的访问方式（x402）完全取消了账户要求。 钱包即身份，支付即授权。该模式特别适用于无需预先配置凭证agents 进行身份验证和支付agents 自主agents 。它还支持开发者构建agent工具，使终端用户无需自有账户即可与基础设施交互；支持使用频率较低的开发者，使其无需订阅套餐即可偶尔跨链访问；同时也支持注重隐私的用户，他们更倾向于基于钱包的访问方式，而非账户注册。

In practice, many systems will use both. A team might maintain a standard plan for their core application and deploy x402 for agent workloads at the edges. The two models are additive, not competitive. They run in parallel and do not interfere with each other.

Quicknode 如何Quicknode x402

Quicknode x402 “预付额度”模式 x402 。开发者无需为每次调用单独签名和支付费用，而是只需一次性充值账户余额，随后从该余额中提取额度即可。

该流程采用 SIWx（Sign-In with X）进行基于钱包的身份验证，同时支持 EVM 和Solana 。后续请求会自动从已充值的余额中扣款，从而消除了逐笔交易签名带来的延迟和计算开销。

一个重要的设计细节：支付网络与查询网络是解耦的。目前，多条链（包括Base、Polygon、XLayer 和Solana）均支持稳定币支付。在上述任何一条网络上agent ，均可通过 JSON-RPC、REST、gRPC 和 WebSocket 协议，查询 130 多条受支持的链中的任意一条。 您可以在最适合自己钱包的网络上进行支付；同时，也可以根据应用程序的需求，查询所需的区块链和协议。

开发者可在支持的测试网中使用稳定币，针对Quicknode 部署在 130 多个网络上的生产级区块链端点，进行最多 10,000 次免费请求的测试。开始测试无需投入真实资金。

对于生产环境部署，建议从一开始就将钱包范围控制机制纳入设计。任何支持相关稳定币的 EVM 兼容Solana 或Solana 均可开箱即用，但赋予agent 支出权限会带来风险。像 Coinbase 的 Agentic Wallets 等专用解决方案则提供了受限的支出权限，允许团队定义agent 支出哪些资金以及用于哪些操作。

所得模型

事情将如何发展

x402 早期x402 ，其周边的生态系统仍在形成之中。该协议是 开源的，基础设施提供商、API 开发者和工具构建者正开始对其提供支持。

其中一项颇为引人注目的进展是 x402 ，这是一个x402服务的机器可读目录。Agents 编程方式查询该目录，以发现可付费的API，并无需人工配置即可访问这些API。随着目录规模的扩大，agents 自主访问的服务范围也将随之扩大。

更广泛的发展趋势是构建能够原生支持这两种访问模式的基础设施，使每种模式都能为设计所针对的工作负载提供服务。归根结底，选择的重点不在于API密钥x402，而在于如何最好地利用二者，在稳定性和自主性之间取得平衡。通过同时支持凭证式访问和基于交易的访问，区块链基础设施终于正朝着一种与agents 服务的agents 同样灵活且无边界的新模式迈进。

Quicknode 同时Quicknode 130 多个区块链网络的访问路径。如需了解更多信息，请查阅 x402 ，或开始 使用QuicknodeAI 文档开始开发。