最近提出要给 x402 协议提供数据服务层，具体要怎么做呢？

撰文：haotian

x402 赛道的大基建目前还属于一片空白境地，虽然大行情夺走的「天时」，让 Launchpad 这类应用层和 Facilitator 这种中间层都暂时沉寂了下来，但却给了底层基础设施层更多的 build 时间窗口；

@switchboardxyz 作为 Solana 生态跑出来的预言机项目，最近提出要给 x402 协议提供数据服务层，具体要怎么做呢？

1）技术架构上，Switchboard 采用 TEE 可信执行环境，区别于 Chainlink、Pyth 等传统靠网络验证确定的共识模型，数据直接基于安全飞地（Enclave）直接传输到链上；

2）协议兼容上，Switchboard 则兼容了 x402 协议标准，使得 AI Agent 可以直接通过 HTTP 402 发起数据请求，用链上小额支付完成授权，数据即时返回。整个流程不需要额外的适配层或中间合约；

3）计费模式上，打破了传统预言机的订阅制模式，支持 pay-per-call——Agent 按调用次数、按数据点付费，用多少付多少，这跟 x402 协议按需付费的设计理念完全一致；

4））更激进的一点是，Switchboard 彻底移除了 API Key 机制。传统模式下，调用数据服务得先注册、申请 Key、管理权限，这套流程对 Agent 来说是巨大的摩擦。而现在，用户的 402 交易请求中，携带足够的 就可以即时访问任意数据源，无需注册，无需审批。

问题来了，x402 协议需不需要一个专门的预言机服务层？

先理清楚一个概念，x402 协议架构里，Facilitator 负责的是支付促进——代付、广播交易、状态验证，解决的是「钱怎么流」的问题。而 Agent 真正调用的 API 服务，不管是获取价格、执行计算还是调用 LLM 推理，这些是 Provider 层提供的。

而 Switchboard 想做的就是一种特殊的 Provider：专门提供链上可信数据服务的 Provider，构造 Agent 价值传输的核心信息层。

试想，如果 Provider 是个中心化的 API，数据被篡改或者服务宕机怎么办？Web2 场景下，这些风险靠渠道品牌和法律合约兜底，但在链上执行环境尤其是涉及到复杂的 DeFi 操作，就需要一些可验证且链上有存证的数据。

如果说 ERC-8004 解决了买家 Agent 身份可信和声誉的问题，那这类预言机导向的 Provider 则是要在卖家（API）数据可信验证方面提供一层可信保障。

本质上，x402 协议构建了 Agent 服务市场的支付层，而 Switchboard 则搭建了数据服务层。如果说支付层让钱能流动，数据服务层让可信数据能流动。

两者结合起来，Agentic Economy 才算有完整的基础设施。