x402 碾压 AP2 与 ACP：AI 支付协议数据横评

AI 智能体要代替人花钱，底层用什么协议结算？x402、AP2、ACP、L402 四条路线正在抢这个位置。观点满天飞，但把公开数据摆在一起对比的几乎没有。PinkWallet 团队在 2026 年 10 月 13 日做了这件事：抓取 GitHub 活跃度、npm/PyPI 下载量、MCP Registry 服务器数量，并逐条比对各规范对预算与审批的定义。结果指向一个相当悬殊的格局。

数据表：四条协议的真实使用量

协议	GitHub Stars	贡献者	90 天提交	官方 npm 周下载	官方 PyPI 月下载	MCP 服务器	合作方
x402	6,715	334	278	494,987	204,765	222	15
AP2	3,226	19	0	n/a	n/a	3	n/a
ACP	1,571	26	1	n/a	n/a	3	n/a
L402	91	8	0	n/a	n/a	5	3

表中的 “n/a” 含义需要说清楚：不是下载量为零，而是无法确认存在官方发布的包。x402 的 npm 数字来自其 monorepo 中五个官方包的加总（x402、x402-fetch、x402-axios、x402-express、x402-next），其中核心包 x402 一个就占了 467,272。ACP 的 MCP Registry 计数经过人工核验：裸搜 “ACP” 会返回 10 个结果，但其中 7 个是恰好也缩写为 ACP 的无关工具（一个 AI 社交网络、一个叫 “Agentic Control Plane” 的成本策略工具、一个编码智能体桥接器、一个 ACPI 表工具等），真正属于 Agentic Commerce Protocol 集成的只有 3 个。

x402 是 Coinbase 于 2025 年 5 月开源的支付协议，它把 HTTP 早已预留却从未真正落地的 402 Payment Required 状态码重新启用，让 API 或内容服务可以在返回 402 时附带一个支付要求，客户端用加密货币（主要是 USDC，走 Base 等 L2 网络）完成付款后重试请求。它的设计目标就是让机器对机器的微支付无需账户、无需订阅、无需人工介入，因此天然贴近日志式按次计费场景。它之所以在 npm 下载量上遥遥领先，很大程度上因为它是四种方案里唯一同时提供官方 SDK、中间件（Express、Next.js 等框架的封装）并提供 MCP 服务器实现的协议，开发者接入成本最低。理解这一点，才能明白为什么它的使用量数字会比其他几条路线高出一个数量级。

MCP（Model Context Protocol）是 Anthropic 在 2024 年底推出的开放协议，用于让 AI 模型以标准化方式连接外部工具与数据源，MCP Registry 则是社区维护的服务器索引。一个支付协议能在 MCP Registry 里拥有多少个服务器，反映的是它被 AI 智能体工具链直接集成的程度，而不只是人类开发者手动调用的程度。这正是这张表把 MCP 服务器数列为独立指标的原因：官方 npm 包下载量衡量的是传统软件集成，MCP 服务器数量衡量的则是它是否真正进入了智能体运行时。两者结合看，能判断一条协议是停留在文档和规范层面，还是已经被打包成智能体可以即插即用的能力。

五个值得注意的信号

使用量差距是一个数量级

x402 不只是领先，而是在每一个衡量真实使用的指标上都领先一个数量级。五个官方包合计每周 49.5 万次 npm 下载，PyPI 月下载 20.5 万，222 个 MCP 服务器建立在其之上。AP2 和 ACP 找不到可确认的官方包。Stars 反映关注度，下载量反映开发者是否真的在跑代码——后者才是这个故事的核心。

AP2 与 L402 近 90 天零提交

AP2 的规范仓库（google-agentic-commerce/AP2）最后一次推送停留在 2026 年 6 月 17 日。这未必说明协议已死，Google 可能在其他地方迭代，但作为公开的活跃度信号，它是平的。ACP 在同一窗口内只有 1 次提交。

AP2 与 ACP 都没有可安装的官方 SDK

AP2 的代码目录里有一个 Python 的 pyproject.toml，但从未在 Google 控制下发布到 PyPI（PyPI 上占着 ap2 名字的包指向一个无关仓库）。ACP 的包名 @agentic-commerce-protocol/specification 在 npm registry 上返回 404。今天想基于这两条协议开发，你只能照规范手写实现。

“ACP” 作为搜索词几乎不可用

这是一条方法论提醒，不是对协议的批评：GitHub 裸搜 “ACP” 返回 47,243 个结果，绝大多数与 Stripe/OpenAI 的商务协议无关。必须换成精确短语 "agentic commerce protocol" 才能得到可用的 989 个仓库计数，MCP Registry 的 10 个结果也得逐个人工读。自己研究这个领域，要预留这部分时间。

L402 最老也最小，且有分叉问题

L402 是这里最老的协议（2020 年），现在所有 GitHub 指标上都是最小的：91 stars、8 个贡献者、90 天零提交。它还有一个“脑裂”问题——存在第二个 star 更多的仓库（l402-protocol/l402，227 stars），自称是同一规范的新延续。PinkWallet 把起源仓库 lightninglabs/L402 作为正统来测量；诚实的说法是，L402 的合并足迹很可能比报告中更大，只是分散在两个地方。

比任何数字都重要的一行

研究团队通读了四份规范，专门找一件事：协议是否定义了持续性支出预算、收款方规则，或人工审批环节，而不只是针对单笔交易的授权？

x402 的规范在 scope 章节里直接给出了答案：

“Out of Scope: This specification does not include: ... Client-side budget management”

AP2 是三者中最接近的：它定义了可携带单笔价格上限的签名 “Mandates”，并区分 “human present” 与 “human not present” 流程。但一个 Mandate 授权的是一辆购物车，不是持续额度。ACP 定义的是智能体、商户与支付处理方之间的结账会话，完全没有涉及预算。L402 用于按次 API 支付的 HTTP 402 挑战/应答流程同样没有预算或审批概念。

实际影响是：当你要决定是否给一个 AI 智能体配钱包时，这些协议都不会阻止它花超你预期的钱、付给你没批准的收款方，或在没有人工确认的情况下继续执行。它们都假定协议上游已经有人做了这个决定。这是一个具体的、有据可查的缺口，而非笼统的“需要更多护栏”式抱怨。

这里说的“单笔交易授权”与“持续性支出预算”之间的区别，是理解整个支付授权体系的关键。传统的信用卡或 API 密钥授权，本质上是针对一次具体请求的允许或拒绝；而智能体自主运行时，需要在没有人类逐笔确认的情况下连续发起多笔支付，这就要求系统能维护一份跨时间、跨交易的额度状态，并配合收款方白名单和金额上限。OAuth 2.0 里的 scope 与 token 过期机制、以及银行卡体系里的“商户类别码 + 单笔限额”都属于这类思路，但它们都假定了人类在授权环里。四条协议目前都只处理“这一笔付不付”，把“这一段时间里总共能付多少、付给谁”留给上游系统解决，这正是文中指出缺口的实质。

Pink 的位置

需要再次披露：作者供职于 Pink Agentic AI Payments，这是一个 MCP 服务器，在执行支付前检查每个智能体的预算、收款方规则和人工审批挂起。它正是这些规范明确排除的那一层，用于通过 Pink 自家 MCP 服务器发起的支付。要说清楚：Pink 目前并不接入 x402、AP2、ACP 或 L402。如果想看预算/审批层的实际样子，有一个使用测试币的公开沙盒。

自己复现或提交更正

文中的每一个数字都是 tracker.csv 中的一行，带有 source_url 和 method 列，可以核对。collect.py 可复现 GitHub/npm/PyPI/MCP Registry 的各项指标（GitHub token 可选，用于避免限流）：

export GITHUB_TOKEN=ghp_xxx
python3 collect.py > tracker_rerun.csv

如果某个协议的维护者发现数据有误或过期，可以带上公开来源提交 issue，团队承诺 7 天内修正。