x402 新增两款 AI Agent API：JSON-LD 跨块校验与 SSL 固定策略探测

URL Metadata API 在 x402 支付协议下新增了两个面向 AI Agent 的付费端点，单价 $0.0005。两者都填补了现有工具链中的检测空白，并已在 stripe.com、github.com、example.com 上完成端到端验证。

两个新端点解决什么问题

现有 API 已经覆盖了不少场景：/api/jsonld 负责解析 JSON-LD，/api/structured-data-validator 检查每种类型的字段是否存在，但它们都无法发现同一页面内多个结构化数据块之间的内部矛盾。类似地，/api/tls-handshake-probe、/api/tls13-pqc-ech-probe、/api/tls-audit、/api/header-policy-audit 各自审计 TLS 或 HTTP 头的某一部分，却没有一个端点真正打开 TLS 连接去验证 HSTS 等策略在运行时是否被强制执行。

这次新增的两个端点正是针对这两个缺口。

JSON-LD 跨块一致性校验

/api/jsonld-cross-validate 会提取页面上所有 JSON-LD 块，解析跨块的 @id 引用，并找出以下矛盾：

• 同一 @id 对应不同的 @type
• 同一实体的 name、url、logo 声明不一致
• 跨块的 priceRange 冲突
• aggregateRating.count 或 ratingValue 冲突
• datePublished / dateModified 的 ISO 8601 日期有效性
• sameAs URL 的 HEAD 探测（最多 8 个），用于发现失效或外部矛盾链接

返回结果包含按严重程度标记的 contradictions[]、per_block_summary，以及 0-100 的 cross_block_score（A-F 等级）。

实测数据：stripe.com 返回 2 个块、0 个矛盾、8 次 sameAs 探测（1 个死链），得分 97/A。example.com 没有 JSON-LD，正确返回 0/F。

这个端点对做结构化数据 SEO 的团队、以及需要自动审核网页元数据一致性的 AI Agent 来说很实用——尤其是在电商或本地商户场景下，同一实体在多个块中声明不一致是很常见的问题。

JSON-LD 是 W3C 推荐的一种基于 JSON 的序列化格式，用于在网页中内嵌 Schema.org 等词汇表描述的结构化数据，搜索引擎据此生成富摘要。同一页面常因模板拼接而出现多个独立的 JSON-LD 块，通过 @id 字段互相引用同一实体。所谓「跨块一致性」，就是指这些分散声明的字段必须在类型、名称、URL、评分等维度上彼此吻合；一旦出现冲突，搜索结果可能出现评分丢失或错误富摘要。sameAs 是 Schema.org 中用于声明同一实体在其他权威站点上的等价 URL 的属性，HEAD 探测即对这些链接发起仅请求响应头的 HTTP 请求以验证存活。

SSL 固定与 HSTS-preload 主动探测

/api/ssl-pinning-policy-probe 会打开到 443、80、8443 端口的 TLS 连接，捕获以下信息：

• HSTS（RFC 6797）：max-age、includeSubDomains、preload 标志
• HSTS preload 列表成员资格（通过 hstspreload.org API 查询）
• Expect-CT（RFC 8470）：是否存在、max-age、enforce 标志
• HPKP（Public-Key-Pins，2018 年已弃用，仅供参考）
• X-Content-Type-Options: nosniff
• 旧版 X-Frame-Options 头
• 80 端口到 HTTPS 的降级重定向探测

返回 pinning_policy_score（0-100，A-F 等级）以及 verdict（production_fortified / standard / weak / no_hsts）和逐端口的探测结果。

实测数据：

• stripe.com：HSTS max-age=63072000s（2 年）、includeSubDomains、preload 标志、hstspreload_list_member=true、nosniff、X-Frame-Options=SAMEORIGIN，得分 60/C，评级 "weak"——因为缺少 Expect-CT 且没有降级重定向被扣分。
• github.com：HSTS max-age=31536000s（1 年）、includeSubDomains、hstspreload_list_member=true，80 端口安全重定向到 HTTPS，得分 70/C。
• example.com：没有 HSTS，正确返回 0/F，评级 "no_hsts"。

一个值得注意的细节是：stripe.com 与 github.com 虽然都已在 HSTS preload 列表中，得分却都只有 C 级。这说明 HSTS preload 只是传输层安全的一个维度，Expect-CT 缺失和降级重定向未配置同样会拉低整体评分。对于安全审计类 AI Agent 而言，这种细粒度的分项扣分比单一的通过/失败结论更有参考价值。

HSTS（HTTP Strict Transport Security，RFC 6797）通过 Strict-Transport-Security 响应头中的 max-age 告知浏览器在未来一段时间内强制使用 HTTPS，includeSubDomains 将其扩展到子域，preload 则声明站点希望被加入浏览器内置的预加载列表。HSTS preload 列表由 hstspreload.org 维护并经 Chrome、Firefox 等浏览器随安装包分发，是保护首次访问免遭降级攻击的关键机制。Expect-CT（RFC 8470）原本用于强制证书透明度，但因浏览器停止支持已被弃用。HPKP（Public-Key-Pins）则早在 2018 年即因配置风险过高被主流浏览器移除，此处仅作历史参考。SSL pinning 指将服务端证书或公钥与预期值绑定，防止中间人攻击。

x402 支付信封与调用方式

两个路由都返回 HTTP 402，包含以下支付信息：

• payTo：0xCa0a6c6Aa7A8F0D5893636CF166Ea2b44fb6500c
• asset：0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913（Base 上的 USDC）
• network：eip155:8453
• maxAmountRequired：500 atomic（$0.0005）

在两个端点上发送伪造的 X-PAYMENT 头都会返回 402，并附带来自真实 pay.openfacilitator.io 的 malformed_payment_header 错误——而非桩实现。

调用示例：

curl "https://history-primarily-interesting-penalties.trycloudflare.com/api/jsonld-cross-validate?url=https://stripe.com" -i
curl "https://history-primarily-interesting-penalties.trycloudflare.com/api/ssl-pinning-policy-probe?domain=github.com" -i

两者都先返回 402，通过 x402 结算后即可获得 JSON 结果。完整路由目录（192 条）可在 /.well-known/x402 查看。

x402 是一套基于 HTTP 402「Payment Required」状态码构建的按调用付费协议，旨在让 AI Agent 能在无人干预的情况下自动完成 API 结算。客户端首次请求无支付凭据的端点时，服务端返回 402 及一个结构化的支付信封，其中 payTo 是收款地址，asset 指定结算代币合约，network 用 CAIP-2 标识链（这里是 eip155:8453，即 Coinbase 的 Base 主网），maxAmountRequired 以代币最小单位表示价格。客户端随后构造 X-PAYMENT 头重放请求即可。0.0005 美元价格对应 USDC 的 6 位小数精度，即 500 atomic units。

对 AI Agent 工具生态的意义

这两款 API 的定位很清晰——它们不是通用爬虫或安全扫描器，而是把某类具体检测做到可编程、可计费、可由 Agent 自主调用。$0.0005 的单价意味着 Agent 可以在一次任务中调用数百次而成本仍然可忽略。

对于构建自动化审计流程的开发者，JSON-LD 跨块校验补上了结构化数据质量检测中缺失的一环；SSL 策略探测则把 HSTS preload 成员资格和运行时强制执行验证结合到了同一个调用里。两者都已在真实站点上完成端到端验证，不是概念性端点。

随着 x402 这类按调用计费协议的成熟，Agent 调用外部 API 的门槛正在下降。像这样针对特定检测缺口的小而专的端点，可能会成为 Agent 工具链中的常见组成部分。