x402解决的问题：把付费协商放回HTTP
本文基于Coinbase发布资料，对x402的机制做解读，不构成对新闻事件的报道。x402针对的是机器发起的按次支付如何在HTTP请求内完成。Coinbase在发布说明中将其定位为开放支付协议，复用长期闲置的HTTP 402“需要付费”状态码：服务端对受限资源返回402及价格、可接受的代币等条件；客户端在后续请求中附带已签名的支付载荷；支付facilitator验证并完成链上结算后，服务端返回资源，并通过响应头区分支付结果与服务返回。对AI代理而言，支付协议自身不强制传统订阅、预付费API密钥等人工开通流程，单次调用可按条件付费；对服务端而言，付费门槛可以落在具体接口上，不必先自建一套账户和计费体系。应用仍可要求身份、权限或其他准入条件，协议解决的是支付协商，不是替代全部访问控制。
协议能力不等于部署后的保护
发布说明强调认证、自动结算和HTTP原生集成，但不应据此认为每个接入方自动获得完整的支出治理。授权额度、单次上限、收款方白名单、代理身份与密钥托管，通常要由钱包、代理框架或facilitator侧策略实现，属于集成层设计。支付成功也不等于服务成功：收到402只表示存在付费条件，带支付载荷的请求被接受，也不代表资源一定可用；最终交付要看服务端返回的数据和错误状态。业务失败后的重试、退款与重复收费，需要在集成层处理，不能由状态码本身保证。
采用情况：看结算，不看演示数量
发布资料列出的合作场景覆盖云算力、模型上下文协议、社交数据、实时数据和日历服务等，其中部分明确是演示或测试性集成。这些材料能说明接口形态和潜在场景，不能说明已有稳定收入或规模化付费用户；请求数、演示数量同样不能当作活跃付费客户。评估采用宜看三类可核验信息：真实服务端是否持续返回402并完成结算；付费方是否以代理而非人工为主；结算失败、服务错误和争议如何处理。缺少这些，合作名单只能视为生态意向。跨链并非x402必需流程，具体结算路径取决于接入方对链与代币的选择，不能据此推断必须桥接。