x402生态新增WebTransport探测与DID解析API

x402支付协议正在把AI Agent之间的能力调用变成一种可计量的服务。最新一轮更新中，开发者上线了两个新的付费API：一个用于检测目标网站是否真正支持WebTransport，另一个则统一查询W3C去中心化标识符（DID）的解析状态。单个请求定价0.0005 USDC，通过Base网络结算——这类服务正在填补Agent工具链中"最后一公里"的验证空白。

为什么WebTransport需要专门的探测工具

WebTransport（RFC 8441、RFC 9290、RFC 9221）是基于HTTP/3的双向低延迟传输层，Google Meet式实时应用、Cloudflare Realtime平台以及越来越多A2A智能体协议栈都建立在它之上。问题在于，一个网站宣称支持HTTP/3，并不等于它真的开放了WebTransport端点。

新上线的 /api/webtransport-probe?url=<URL> 端点执行8项审计：解析Alt-Svc头中的h3端口声明、发送带 :protocol=connect-udp 伪头的Extended CONNECT请求、HEAD探测6条约定路径寻找会话端点、校验端点是否为https、检测 Supports-Transport-Webtransport 响应头、探查SCITT端点、识别HTML中的客户端库，以及从Alt-Svc参数中提取ECH配置ID。

输出结果包含 webtransport_advertised、http3_drafts[]、webtransport_endpoints[]、connect_udp_endpoints[] 以及0-100分的 webtransport_score 评级。作者在cloudflare.com上的实测结果显示：Cloudflare广播了 h3=":443"; ma=86400，但评分为25，结论是 connect_udp_explicitly_disabled——它支持HTTP/3，却尚未暴露WebTransport端点。这个案例恰好说明了探测的必要性：传输层能力需要逐项验证，不能靠厂商宣传推断。

有意思的是，该端点与作者此前上线的通用Alt-Svc检查、QUIC握手探测、0-RTT重放风险评估等工具形成分工，专门覆盖WebTransport协议层与端点发现。

Alt-Svc 头与协议协商：Alt-Svc（Alternative Services，RFC 7838）是 HTTP 响应头，用于告知客户端该源站的同一资源可通过其他端点或协议提供服务，常见形式如 h3=":443"; ma=86400，表示 HTTP/3 可通过同一主机的 443 端口访问，ma 是缓存有效期（秒）。探测工具从 Alt-Svc 中解析 h3 端口，是判断服务端是否"宣告"HTTP/3 的第一步，但宣告并不意味着端点可用的 WebTransport 会话已开放，因此还需后续的 Extended CONNECT 探测。

Extended CONNECT 与 :protocol 伪头：在 HTTP/2 与 HTTP/3 中，CONNECT 方法可通过扩展机制携带 :protocol 伪头（RFC 8441、RFC 9221），从而在一条 HTTP 连接内建立 WebSocket 或 WebTransport 之类的双向隧道。当 :protocol=connect-udp 时，表示在 HTTP/3 之上承载 UDP 语义的数据报流，这是 WebTransport 底层的关键能力。探测端点主动发送这类请求，可以直接验证服务端是否真的处理了 WebTransport 握手，而不仅是静态宣告。

ECH（Encrypted Client Hello）：ECH 是 TLS 1.3 的扩展，用于加密 ClientHello 中的 SNI 等敏感字段，避免中间人窥探访问的目标域名。其配置通过 DNS HTTPS 记录或 Alt-Svc 参数中的 ech 字段以 base64 形式分发。从 Alt-Svc 参数中提取 ECH 配置 ID，可以辅助判断服务端是否部署了加密 SNI，属于传输层隐私能力的旁证。

DID解析碎片化催生统一目录API

W3C DID方法注册表（2024-12版）列出了28种方法，但目前没有公共解析器能统一覆盖全部。Universal Resolver主要处理did:ion等少数方法，did:web依赖 /.well-known/did.json，did:plc走plc.directory，ATProto又有自己的身份层——对需要跨方法验证身份的Agent应用来说，集成成本很高。

/api/did-method-catalog?did=<DID> 将13种以上方法的解析收敛到一次调用中：did:web读取well-known路径；did:key通过multibase与multicodec离线解码；did:plc查询AT Protocol目录；did:webvh读取 /.well-known/did.jsonl；did:ion走Microsoft Sidetree接口；did:jwk直接解码base64url的JWK；did:ethr通过公共以太坊RPC查询ERC1056注册表；其余方法回退到DIF通用解析器。

返回字段包括逐方法的 resolution_status、did_document_present、resolution_url、错误信息，以及成功解析时的完整DID文档、registry_completeness 与0-100分的 did_method_score。对构建跨平台身份验证的开发者而言，这种"一次查询、多种回退"的模式可以显著减少适配代码。

W3C DID 与 DID 文档：去中心化标识符（Decentralized Identifier，DID）是 W3C 制定的字符串标识符，形如 did:method:identifier，其中 method 指明解析规则（如 did:web、did:key），identifier 由该方法自行定义。每个 DID 可解析为一份 DID 文档（DID Document），其中包含公钥、验证方法、服务端点等，是身份验证与密钥协商的载体。"解析"（resolution）即指从 DID 字符串得到 DID 文档及其元数据的过程。

multibase 与 multicodec：这是两个配套的编码规范。multicodec 为不同的密钥或数据格式分配短前缀（如 ed25519-pub 对应 0xed01），multibase 则在编码结果前加一个字符表示所用编码（如 z 表示 base58btc）。did:key 正是把公钥按 multicodec 加前缀后再用 multibase 编码，因此可以完全离线地从一个 DID 字符串还原出公钥，无需网络查询——这也是统一目录 API 中 did:key 分支"离线解码"的原因。

Sidetree 与 ERC1056：Sidetree 是 DIF 提出的一个规范，用于在现有分布式账本（如比特币、以太坊）之上批量锚定 DID 状态，did:ion 即基于比特币的 Sidetree 实现。ERC1056 则是以太坊上的"轻量级身份"标准，通过一个智能合约把以太坊地址映射到 DID 与公钥，did:ethr 依赖公共 RPC 读取该合约状态。两者的共同点是解析时需要访问链上或索引服务，因此统一 API 需要为它们配置各自的后端。

x402付费模式与Agent经济的接口设计

两个端点均定价0.0005 USDC，通过x402协议在Base网络（eip155:8453）结算，资产合约为USDC。服务方宣称已连续运行165个周期、开放238条付费路由，目录通过 /.well-known/x402 和 /openapi.json 持续更新，结算由 pay.openfacilitator.io 处理，而非模拟桩。

从更宏观的视角看，这类微支付API解决的是Agent自动发现与验证外部能力的问题。当AI Agent需要判断某个服务是否支持特定传输协议或身份体系时，与其内置大量探测逻辑，不如支付不到一美分调用一个专用端点。这种"验证即服务"的形态，可能成为Agent工具生态中一类稳定的基础设施。

不过需要提醒：服务地址目前托管在trycloudflare.com临时域名下，且相关信息来自项目方自述，实际可用性与结算稳定性仍需独立验证。

x402 协议与 HTTP 402：x402 是一套基于 HTTP 状态码 402（Payment Required）的微支付协议，其思路是服务端在响应中返回支付要求（金额、资产、网络、收款地址），客户端完成链上支付后携带支付凭据重试请求，服务端验证后放行。由于支付与请求在同一 HTTP 往返中协商，它天然适合 API 按次计费，也便于 AI Agent 在无人工干预的情况下完成"付费—调用"的闭环，无需预先注册账户或签订合同。

Base 网络与 eip155:8453：Base 是 Coinbase 基于 OP Stack 构建的以太坊 Layer 2，采用 Optimistic Rollup，交易费用以 ETH 计价但远低于主网，因此适合 0.0005 USDC 这类极小额的支付。eip155:8453 是 CAIP-2 格式的链标识，eip155 表示 EVM 兼容链命名空间，8453 是 Base 主网的 chain ID。选择 L2 作为结算层，是微支付在成本上可行的前提。

/.well-known/x402 与 OpenAPI 目录：/.well-known/ 是 RFC 8615 定义的约定路径，用于放置站点级元数据（如 /.well-known/did.json）。服务方在 /.well-known/x402 与 /openapi.json 中公开其付费路由清单与接口描述，使 Agent 能够自动发现"有哪些付费能力、如何调用、价格多少"，这正是 Agent 自动调用微支付 API 所需的发现机制。

核心要点

• WebTransport探测端点执行8项协议层审计，实测发现Cloudflare广播HTTP/3但未开放WebTransport端点
• DID目录API统一解析13种以上W3C DID方法，覆盖did:web、did:key、did:plc、did:ion等主流体系
• 两个端点均通过x402以0.0005 USDC微支付计价，低门槛适合Agent自动调用
• 验证即服务的微支付API正在成为Agent工具链中的基础设施形态，但服务稳定性需持续观察