ملف Bluue الشخصي | Binance Square

PINNED

·

--

مقالة

عرض الترجمة

x402 ：AI Agent 让互联网文明复兴 x402是什么介绍 x402 是在 2025 年推出的一项开放支付标准，旨在正式激活 HTTP 402 状态码，将其转变为互联网原生的支付机制由网络基础设施公司 Cloudflare 和加密货币交易所 Coinbase 联合推动的一项技术标准。相比于传统模式需要创建账户、绑定信用卡或预充值，x402 将支付请求直接嵌入 HTTP 响应中，使客户端（无论是人、机器人，还是 AI agent）都可以自动识别支付信息，并完成结算。 x402 让一次 HTTP 请求同时具备“数据传输”与“价值传输”属性。只要支付完成，访问权限即可即时打开，无需账号或人工操作。设计初衷解决机器对机器（M2M）和人工智能代理（AI Agent）在访问网络服务（如 API）时，需要进行高频、小额、自动化支付的需求。例如，一个 AI 程序可能需要每秒钟调用上千次数据API，每次支付 0.001 美元。传统支付方式（如信用卡）无法处理这种场景，而 x402 旨在提供一个标准化的解决方案。历史背景 HTTP 协议自早期标准化以来预留了 402 “Payment Required” 状态码，但一直没用上原因在于：技术，商业，用户习惯的共同作用没有统一的规范，没有统一的结算方式等等（例如配套字段），消息格式写什么，付给谁，付多少，怎么付，怎么证明等，啥不知道没有一个公共的轨道，比如区块链，大家就无法达成共识微支付不经济，比如几美分级别的交易，同样要支付三十美分的固定手续费，亏（信用卡公司的设计）传统交易有拒付，退款，合规检测等，容易出问题 x402 的参与者 Client（客户端）：发起请求的用户、应用或 AI agent Server（服务端）/Provider：提供数据或服务的主体（API、网站等） Facilitator（结算方）：负责验证支付是否完成。当前大多数实现基于区块链，但理论上任何具备可验证结算能力的系统都可接入狭义和广义的角色狭义的Provider：资源提供商，理解为发出402账单的服务器广义的：配套服务商，微x402提供基础和配套的相关者工具：SDK，钱包插件等平台：Agent部署，托管等基建：RPC，索引等 Facilitator 算是一个中间件，作为web和区块链之间的桥梁假设服务器向一个AI发送了402账单，要求支付 1USDC 那么在哪条链支付？服务器怎么知道真的付钱了？ Facilitator 相当于一个外包，检查链上数据，确认交易真实生成凭证，发送给服务器服务器信任这个制定的facilitator，即完成交易 Facilitator的充当角色一般包括 Coinbase CDP，CloudFlare可能会内嵌 web3支付网关，比如USDC 节点服务商支付巨头：Paypal，Visa 自托管：api提供商自己实际使用，可能会做KYT 或者风控，针对Facilitator 基本流程客户端 (Client) → 服务端 (Provider)：请求资源。比如AI Agent向服务器请求一个付费资源（api 接口）服务端 (Provider) → 客户端 (Client)：服务端返回 HTTP 402，并附带支付条件（支付资产、金额、接收地址等）相当于标准化的账单，指明需要支付的金额，数量，货币，地址等客户端 (Client) → 区块链：客户端使用稳定币（如 USDC）发起支付，区块链完成，附带证明客户端 (Client) → 协调者 (Facilitator)：客户端拿着 txHash 去请求 Facilitator 的验证地址（即步骤 2 中指定的地址）。协调者 (Facilitator) → 区块链：Facilitator 检查该 txHash 是否真实、有效、金额正确。协调者 (Facilitator) → 客户端 (Client)：Facilitator 验证通过后，签发一个有时效性的“新凭证”（例如一个 JWT Token）给客户端。客户端 (Client) → 服务端 (Provider)：客户端重新请求资源，并在请求头中附上这个由 Facilitator 签发的“新凭证”。服务端 (Provider)：服务器只验证这个凭证是否是它信任的 Facilitator 签发的。验证整个过程是可编程的、可以无需人工参与或账户体系。对比和区别为什么在当下被提及了 AI 代理需要按次付费，符合需求，高频，小额，自动化技术成熟：区块链，稳定币其他状态码 401：未认证，身份认证，比如账号密码 403：禁止访问，权限不够 404：未找到内容 500：服务器内部错误解决的问题 AI 代理的支付问题高频，高摩擦的微支付问题 x402之前，假设ai 需要调用100个不同API来完成任务那么需要首先，人工注册100个api服务的网站对100个网站添加支付信息根据支付要求绑定，比如按月，按次等收到100个账单相关ERC EIP-3009： "Transfer ERC-20s with a signature 由 USDC (v2) 率先实现并推广让持币人先离线签好一次“转账授权”，任何中继或对方都能把这份授权打到链上完成实际转账。目标是Gas可代付、原子结算、避免 allowance 漏洞，适合按次“推送式”付款 Agent (客户端) 在本地用自己的私钥（或会话密钥）签署一个 EIP-3009 格式的消息，内容是：“授权从我的钱包转 0.01 USDC 到 Provider 的钱包”。这个过程是即时的，不花 Gas。 Agent 将这个签名作为“支付证明”发送给 Facilitator。正常交易是：agent 自己创建，签名，广播一笔交易，同时持有ETH作为Gas，假设Agent只有USDC，就会很麻烦 EIP 3009：本地生成一个签名：我，授权，100 USDC转给B Agent可以不需要Gas，可以代付，由Facilitator 代付代付的结果就是，Facilitator 会从这笔支付中拿回补偿：抽成或者Provider为了抢占市场和提高体验，来代付核心优势： AI Agent 的钱包完全不需要持有 ETH 来支付 Gas，也不需要管理复杂的链上交易（如 Nonce、Gas Price）。只需要能签名即可。 EIP-2612：Permit: Signature-based ERC-20 Approvals" (通过签名的 ERC-20 授权) 允许用户通过**“链下签名” (Off-chain Signature)** 来完成 ERC-20 代币的 approve() (授权) 操作，而无需为此单独支付 Gas 费。 2612 之前： USDC——ETH的兑换：授权——兑换，需要两次操作和签名，同时支付两笔gas 2612之后：授权转变为链下签名：免费，快速 “我授权 Uniswap（Spender）从我（Owner）这里拿走 100 USDC（Value），此签名在（Deadline）前有效”。 Uniswap 拿到签名后，按顺序执行两个事情签名发给USDC，USDC验证后，即完成授权调用交易，完成兑换 EIP-2612 告诉合约：“你被允许来我这里拿钱了。”比如签署一份授权书，允许快递员（DApp）明天来取走一个包裹。 EIP-3009 告诉合约：“请立刻把我的钱转给 B。”比如发了一个红包，任何人（中继者）拿走它都能立刻兑现。在 x402 场景中，一般3009应用更广，因为直接高效。但如果某些稳定币受限，那么可能会用到2612。隐私问题 x402 由于付款发生在区块链上，本质上一切都是公开的，包括付款方，收款方，金额，时间等等对于Facilitator而言，它能看到IP地址，验证哈希往坏了说，Facilitator 是能够将链下的IP和链上的身份关联起来的对于Provider 而言，也能看到客户端的 IP 地址以及客户端请求的特定资源（比如具体的api等）假设Facilitator 和 Provider 串通（或者它们是同一家公司，这在 Cloudflare/Coinbase 生态中很可能发生），它们就拥有了完全的监控能力：谁（IP/钱包）在何时为什么（API 路径）支付了多少钱。怎么解决问题 ZK：比如在一个隐私的Layer2上支付，比如Azetc？比如私有的支付通道：类似于闪电网络——避免公链识别，只有最后结果才会记录在链上中心化，意义不大，但肯定会有这个方案，比如客户端将 100 美元预存到他们的“Coinbase Agent 账户”（可以通过链上或信用卡）。每当 Provider 返回 402 时，Facilitator 只需在其内部数据库中扣除客户端的余额，并记入 Provider 的余额。 FHE：把想获取的资源加密发送给Provider Provider可直接在加密数据上执行计算并返回402账单加密了：数据相关信息没加密：支付相关的信息个人观点 x402 有用，但没那么大用，更像是一个垂直领域的解决方式，而不是一个general的范式现在的x402发展更多在web3，但是这件事达成大结果需要web2的更多支持ai agent其实有清晰的边界，可以关注，本质上应该属于payment领域的一部分，但并没有那么大的效果，payment和隐私更底层但是基于“胖应用，瘦协议”的概念，很有可能跑出来几个大哥大短期看好，但长期保留意见，不是概念不合适，是落地（悬）参考：https://mp.weixin.qq.com/s/gEu1c7WYx2oOFF5uyludpQ

x402 ：AI Agent 让互联网文明复兴

x402是什么
介绍
x402 是在 2025 年推出的一项开放支付标准，旨在正式激活 HTTP 402 状态码，将其转变为互联网原生的支付机制
由网络基础设施公司 Cloudflare 和加密货币交易所 Coinbase 联合推动的一项技术标准。
相比于传统模式需要创建账户、绑定信用卡或预充值，x402 将支付请求直接嵌入 HTTP 响应中，使客户端（无论是人、机器人，还是 AI agent）都可以自动识别支付信息，并完成结算。 x402 让一次 HTTP 请求同时具备“数据传输”与“价值传输”属性。只要支付完成，访问权限即可即时打开，无需账号或人工操作。
设计初衷
解决机器对机器（M2M）和人工智能代理（AI Agent）在访问网络服务（如 API）时，需要进行高频、小额、自动化支付的需求。
例如，一个 AI 程序可能需要每秒钟调用上千次数据API，每次支付 0.001 美元。传统支付方式（如信用卡）无法处理这种场景，而 x402 旨在提供一个标准化的解决方案。
历史背景
HTTP 协议自早期标准化以来预留了 402 “Payment Required” 状态码，但一直没用上
原因在于：技术，商业，用户习惯的共同作用
没有统一的规范，没有统一的结算方式等等（例如配套字段），消息格式写什么，付给谁，付多少，怎么付，怎么证明等，啥不知道没有一个公共的轨道，比如区块链，大家就无法达成共识微支付不经济，比如几美分级别的交易，同样要支付三十美分的固定手续费，亏（信用卡公司的设计）传统交易有拒付，退款，合规检测等，容易出问题
x402 的参与者
Client（客户端）：发起请求的用户、应用或 AI agent
Server（服务端）/Provider：提供数据或服务的主体（API、网站等）
Facilitator（结算方）：负责验证支付是否完成。当前大多数实现基于区块链，但理论上任何具备可验证结算能力的系统都可接入
狭义和广义的角色
狭义的Provider：资源提供商，理解为发出402账单的服务器
广义的：配套服务商，微x402提供基础和配套的相关者
工具：SDK，钱包插件等平台：Agent部署，托管等基建：RPC，索引等

Facilitator
算是一个中间件，作为web和区块链之间的桥梁
假设服务器向一个AI发送了402账单，要求支付 1USDC 那么在哪条链支付？服务器怎么知道真的付钱了？
Facilitator 相当于一个外包，检查链上数据，确认交易真实
生成凭证，发送给服务器服务器信任这个制定的facilitator，即完成交易 Facilitator的充当角色一般包括 Coinbase CDP，CloudFlare可能会内嵌
web3支付网关，比如USDC 节点服务商支付巨头：Paypal，Visa 自托管：api提供商自己
实际使用，可能会做KYT 或者风控，针对Facilitator
基本流程
客户端 (Client) → 服务端 (Provider)：请求资源。比如AI Agent向服务器请求一个付费资源（api 接口）服务端 (Provider) → 客户端 (Client)：服务端返回 HTTP 402，并附带支付条件（支付资产、金额、接收地址等）相当于标准化的账单，指明需要支付的金额，数量，货币，地址等客户端 (Client) → 区块链：客户端使用稳定币（如 USDC）发起支付，区块链完成，附带证明客户端 (Client) → 协调者 (Facilitator)：客户端拿着 txHash 去请求 Facilitator 的验证地址（即步骤 2 中指定的地址）。协调者 (Facilitator) → 区块链：Facilitator 检查该 txHash 是否真实、有效、金额正确。协调者 (Facilitator) → 客户端 (Client)：Facilitator 验证通过后，签发一个有时效性的“新凭证”（例如一个 JWT Token）给客户端。客户端 (Client) → 服务端 (Provider)：客户端重新请求资源，并在请求头中附上这个由 Facilitator 签发的“新凭证”。服务端 (Provider)：服务器只验证这个凭证是否是它信任的 Facilitator 签发的。验证
整个过程是可编程的、可以无需人工参与或账户体系。
对比和区别

为什么在当下被提及了
AI 代理需要按次付费，符合需求，高频，小额，自动化技术成熟：区块链，稳定币
其他状态码
401：未认证，身份认证，比如账号密码
403：禁止访问，权限不够
404：未找到内容
500：服务器内部错误
解决的问题
AI 代理的支付问题高频，高摩擦的微支付问题
x402之前，假设ai 需要调用100个不同API来完成任务
那么需要首先，人工注册100个api服务的网站对100个网站添加支付信息根据支付要求绑定，比如按月，按次等收到100个账单
相关ERC
EIP-3009： "Transfer ERC-20s with a signature
由 USDC (v2) 率先实现并推广
让持币人先离线签好一次“转账授权”，任何中继或对方都能把这份授权打到链上完成实际转账。目标是Gas可代付、原子结算、避免 allowance 漏洞，适合按次“推送式”付款
Agent (客户端) 在本地用自己的私钥（或会话密钥）签署一个 EIP-3009 格式的消息，内容是：“授权从我的钱包转 0.01 USDC 到 Provider 的钱包”。这个过程是即时的，不花 Gas。 Agent 将这个签名作为“支付证明”发送给 Facilitator。
正常交易是：agent 自己创建，签名，广播一笔交易，同时持有ETH作为Gas，假设Agent只有USDC，就会很麻烦 EIP 3009：本地生成一个签名：我，授权，100 USDC转给B
Agent可以不需要Gas，可以代付，由Facilitator 代付代付的结果就是，Facilitator 会从这笔支付中拿回补偿：抽成或者Provider为了抢占市场和提高体验，来代付
核心优势： AI Agent 的钱包完全不需要持有 ETH 来支付 Gas，也不需要管理复杂的链上交易（如 Nonce、Gas Price）。只需要能签名即可。
EIP-2612：Permit: Signature-based ERC-20 Approvals" (通过签名的 ERC-20 授权)
允许用户通过**“链下签名” (Off-chain Signature)** 来完成 ERC-20 代币的 approve() (授权) 操作，而无需为此单独支付 Gas 费。
2612 之前：
USDC——ETH的兑换：授权——兑换，需要两次操作和签名，同时支付两笔gas
2612之后：
授权转变为链下签名：免费，快速 “我授权 Uniswap（Spender）从我（Owner）这里拿走 100 USDC（Value），此签名在（Deadline）前有效”。
Uniswap 拿到签名后，按顺序执行两个事情签名发给USDC，USDC验证后，即完成授权调用交易，完成兑换
EIP-2612 告诉合约：“你被允许来我这里拿钱了。”比如签署一份授权书，允许快递员（DApp）明天来取走一个包裹。
EIP-3009 告诉合约：“请立刻把我的钱转给 B。”比如发了一个红包，任何人（中继者）拿走它都能立刻兑现。

在 x402 场景中，一般3009应用更广，因为直接高效。但如果某些稳定币受限，那么可能会用到2612。
隐私问题
x402 由于付款发生在区块链上，本质上一切都是公开的，包括付款方，收款方，金额，时间等等
对于Facilitator而言，它能看到IP地址，验证哈希往坏了说，Facilitator 是能够将链下的IP和链上的身份关联起来的对于Provider 而言，也能看到客户端的 IP 地址以及客户端请求的特定资源（比如具体的api等）
假设Facilitator 和 Provider 串通（或者它们是同一家公司，这在 Cloudflare/Coinbase 生态中很可能发生），它们就拥有了完全的监控能力：谁（IP/钱包）在何时为什么（API 路径）支付了多少钱。
怎么解决问题
ZK：比如在一个隐私的Layer2上支付，比如Azetc？
比如私有的支付通道：类似于闪电网络——避免公链识别，只有最后结果才会记录在链上
中心化，意义不大，但肯定会有这个方案，比如客户端将 100 美元预存到他们的“Coinbase Agent 账户”（可以通过链上或信用卡）。
每当 Provider 返回 402 时，Facilitator 只需在其内部数据库中扣除客户端的余额，并记入 Provider 的余额。
FHE：
把想获取的资源加密发送给Provider Provider可直接在加密数据上执行计算
并返回402账单
加密了：数据相关信息没加密：支付相关的信息
个人观点
x402 有用，但没那么大用，更像是一个垂直领域的解决方式，而不是一个general的范式现在的x402发展更多在web3，但是这件事达成大结果需要web2的更多支持ai agent其实有清晰的边界，可以关注，本质上应该属于payment领域的一部分，但并没有那么大的效果，payment和隐私更底层但是基于“胖应用，瘦协议”的概念，很有可能跑出来几个大哥大短期看好，但长期保留意见，不是概念不合适，是落地（悬）

参考：https://mp.weixin.qq.com/s/gEu1c7WYx2oOFF5uyludpQ

Bluue

x402 ：AI Agent 让互联网文明复兴

AI Agent 支付和代理经济的小巨头：Skyfire

المواضيع الرائجة