AI Agent 正在复活 HTTP 402:Payment Required

很多人知道 404，但很少有人知道 402

很多人都知道 404 Not Found。网页打不开、链接失效、内容不存在，都会看到它。这个状态码几乎已经变成了互联网文化的一部分。

但在 HTTP 里，还有一个长期被放在角落里的状态码：402 Payment Required。

它指向的是另一个问题：如果互联网的一个资源需要付费，能不能先付款，再获得访问权限？402 Payment Required 并不是最近才被发明出来的东西。它很早就存在，只是一直没有成为互联网的主流支付入口。过去几十年，互联网把支付放进了广告、订阅、App Store、Stripe、PayPal 和 SaaS 账户体系里，而不是放进 HTTP 请求本身。

这也不难理解。过去互联网的主要用户是人，人会打开网页、注册账号、输入银行卡、点击确认、订阅服务、取消续费。支付被包进一个完整的人类交互流程里：页面、按钮、购物车、checkout、发票、客服、退款。

在这样的互联网里，支付不需要长在 HTTP 里。它可以长在平台里，长在 App Store 里，长在 Stripe 和 PayPal 里，长在一个个 SaaS 的 pricing page 和 subscription plan 里。

但 AI Agent 出现以后，互联网开始多了一类新的用户。

它不是坐在屏幕前慢慢点击网页的人，而是替人执行任务的软件。它可能为了完成一份报告去调用数据库，为了分析一个市场去购买实时数据，为了完成一次自动化工作流去临时使用某个付费 API、模型、工具，甚至另一个 agent 的服务。这时候，传统 checkout 就显得太重了。

Agent 真正需要的，不是一个更漂亮的 checkout 页面，而是一个更直接的资源购买流程：知道价格，检查权限，确认预算，完成付款，然后立刻拿到结果。

这就是 402 Payment Required 重新变得重要的原因。

它不是突然出现的新概念，而是一个很早就被互联网预留、但一直没有等到合适用户的接口。人类互联网没有真正用起来它，因为支付被浏览器、平台、账户和 checkout 包住了。但 agent 互联网不一样，当软件开始替人请求资源、判断价格、执行付款、获得访问权限时，Payment Required 终于不再只是一个状态码，而可能变成 agent 时代的支付入口。

x402、L402、T402、B402 到底在回答什么问题

x402 之后，L402、T402、B402 也陆续被放进 agentic payment 的讨论里。

这些名字看起来像几个不同生态各自推出的新协议，但它们共同指向的是同一个变化：402 Payment Required 这个被长期搁置的互联网接口，开始被 AI Agent 重新带回支付基础设施的讨论里。

这个老问题就是：如果一个 API、数据、内容或者工具调用需要付费，服务方能不能不把用户带到传统 checkout 页面，而是直接在一次互联网请求里表达：“这个资源需要先付款”？这就是 402 Payment Required 想解决的事情。

x402、L402、T402、B402 的差异，主要不在于“要不要付费”，而在于用什么网络、什么资产、什么验证方式来完成这次付费访问，放到这个框架里看，几个名字就没那么神秘了。

x402 更像通用的 HTTP 402 payment standard / pattern，重点是让服务方可以通过 HTTP response 告诉请求方：需要支付多少、用什么方式支付、支付后如何继续访问。

L402 是 Lightning 版本的实现思路，把 HTTP 402 和 Bitcoin Lightning Network 结合起来，更适合小额、即时、按次访问的 micropayment 场景。

T402 更偏 USDT-first，关注的是用稳定币，尤其是 USDT，完成 agent、API、内容、工具之间的付费访问。

B402 则更接近 BNB Chain 生态里的 402 / x402-style 实现或扩展。它把同一个问题放进 BNB Chain 的开发者、钱包、多 token 和 agent payment 语境里。

所以它们真正争夺的，不是“谁代表下一代支付系统”这么大的叙事，而是一个更具体的位置：agent 时代的 payment request layer。也就是当机器请求一个付费资源时，服务方如何报价，agent 如何判断授权，付款如何被验证，访问权限如何被释放。

这个位置看起来很窄，但它很关键。因为它决定了未来很多 API、数据、内容和工具，能不能被 agent 以机器可读的方式购买。所以我不太愿意把这件事简单理解成“AI 用 crypto 付款”。

如果只是多一种付款方式，这个故事其实很小，信用卡、虚拟卡、企业账户、Stripe、PayPal 都可以参与，传统支付系统也不会因为 agent 出现就消失。

真正值得关注的是，支付入口本身可能在变化。过去互联网的支付入口，是给人设计的：页面、按钮、购物车、checkout、账户体系。现在，如果越来越多请求资源、调用服务、购买结果的主体变成软件，支付入口就有可能从页面和按钮，慢慢移动到请求和协议里。

这才是 402 重新被捡起来的原因。

从协议名字，到真实支付记录

讲到这里，一个自然的问题是：这些东西只是协议名字，还是已经真的有人在用？至少在 x402 上，这个问题开始有了一些可观察的答案。它和很多过去的“支付协议叙事”不同的一点是：支付行为已经开始在链上留下痕迹。

现在已经有一些 explorer 和数据面板在追踪 x402 的支付活动。x402scan 会看近 30 天的交易数、交易量、买方数、卖方数，也会显示哪些服务正在通过 x402 收费。lookx402 则更细地观察 Base 上的 x402 支付行为，包括 payer、merchant、facilitator、交易频率、交易金额和服务关系。

这些数据现在还很早，但它们提供了一个很重要的观察入口。如果 AI Agent 真的要成为一种新的经济参与者，我们不能只看谁发布了协议、谁发了白皮书、谁融了资。更关键的问题是：有没有真实的付款行为开始发生？

这类数据真正有价值的地方，不是告诉我们“交易量涨了多少”，而是让一些更细的问题变得可追踪：谁在为一次 API call 付钱？谁在为一条数据付钱？谁在为一个 agent 服务付钱？这些支付是偶发测试，还是开始形成持续关系？

在过去，这些问题很容易停留在概念层。现在，它们至少开始有了可以观察的痕迹。当然，早期数据不能被过度解读。这里面一定会混有测试交易、开发者实验、活动激励、自交易，甚至为了排行榜或叙事而制造出来的 volume。所以我不会把交易数直接等同于真实采用，也不会说 agent economy 已经成熟。

更准确的判断是：402 Payment Required 已经不只是一个被浏览器时代遗忘的状态码，而是开始变成可以被观察、统计和分析的支付行为。

这也是为什么我觉得 402 值得观察。它不是只在讲“AI 可以用 crypto 付款”，而是在让一个过去很抽象的问题变得可见：当机器开始替人购买资源，互联网应该如何记录、验证和理解这些付款？

过去我们讨论 agentic payment，很多时候还停留在想象里：AI Agent 以后会不会自己买东西？会不会自己付钱？会不会用稳定币？

但如果一个 agent 已经可以在请求服务时收到 Payment Required，签名授权付款，然后服务方在确认付款后释放资源，这件事就不再只是一个未来设想。

它开始变成一种新的互联网交互记录。这就是链上数据的意义：不是证明一切已经发生，而是证明这件事开始有痕迹。

为什么过去 402 没有成为主流

这就带出另一个问题：如果 402 Payment Required 很早就存在，为什么它过去没有成为互联网主流？

我的理解是，不是 402 这个想法没有价值，而是它一直没有遇到真正适合自己的使用场景。因为过去互联网的主要用户，是人。人类用户访问一个网站，不只是“请求一个资源”。他会看页面、比较价格、注册账号、输入卡号、确认订单、收到邮件、联系客服、申请退款。支付不是一个单独的技术动作，而是被包进一整套消费体验和商业流程里。

所以过去几十年，互联网真正长出来的不是 HTTP 原生支付，而是围绕人类行为建立的支付系统：广告、订阅、会员、App Store、SaaS pricing page、Stripe checkout、PayPal、信用卡网络、企业采购和发票流程。这些系统的默认前提都很清楚：屏幕前有一个人，他会阅读、比较、判断、确认。

所以如果用户是人，你不一定需要在 HTTP response 里告诉他“这个资源需要付款”。你可以给他一个页面、一个按钮、一个套餐、一个 checkout flow。流程可以慢一点、重一点，因为人本来就在屏幕前。这也是 402 长期没有真正被用起来的原因。

但 agent 不一样，Agent 不是来逛网页的，也不是来被营销文案说服的。它不需要一个漂亮的 pricing page，也不适合每调用一次 API，就注册一个账号、绑定一张卡、创建一个 subscription。

它更像一个在任务中不断请求资源的软件。对它来说，最重要的问题很直接：资源是否可用？价格是多少？是否在授权范围内？付款以后能不能马上拿到结果？

这就是为什么过去的支付系统对人很自然，对 agent 却显得很别扭。人类互联网把支付做成了页面、按钮和账户体系。Agent 互联网更需要把支付做成请求、响应和权限释放。

所以 402 过去没有成为主流，不是因为它完全没有价值，而是因为它一直没有等到合适的用户。现在，这个用户出现了，它不是浏览器前的人，而是替人工作的软件。

真正的新场景，是任务中的按需购买

AI Agent 真正改变的，不是多了一种付款主体，而是付款发生的位置。在人类互联网里，付款通常发生在一个明确消费场景的最后：你选好了商品、确认了订单、进入 checkout，然后付款。

但 agent 的工作方式不一定是这样。它不是先进入一个商店，再完成一次购买；它是在完成任务的过程中，不断遇到需要付费的资源。

我前段时间就遇到过一个很典型的例子。我想做一个流量分析 agent：给它一个网站，它可以在需要的时候调用 Semrush 这类工具，分析这个网站的流量、关键词、竞争对手和市场方向。真正的问题不是 agent 能不能分析，而是它怎么获得数据。

今天很多商业数据服务，仍然是为人和公司采购设计的。你要注册账号、选择套餐、购买订阅，或者进入更贵的 API 商业版。它们未必提供一种自然的 pay-as-you-go 方式，让一个 agent 在任务中临时购买一次查询。

这对传统 SaaS 商业模式来说很合理，但对 agent 来说很别扭。Agent 想要的不是先变成一个 SaaS 用户，而是在任务进行到某一步时，发现自己需要一条数据，然后能够判断价格、确认授权、支付、拿到结果，继续完成任务。

类似的问题不只发生在流量分析里。一个研究 agent 为了完成一份行业报告，可能需要临时调用多个数据源；一个 coding agent 为了修复问题，可能需要访问付费 API、模型服务或者测试环境；一个营销 agent 为了分析竞争对手，可能需要购买流量数据、关键词数据或者社媒数据；一个财务 agent 为了完成自动化对账，可能需要调用 KYC、汇率、发票、银行接口。

这些动作都不像传统电商购物。它们更像是在任务执行过程中，软件临时遇到一个付费资源，然后判断：这个资源对当前任务有没有帮助？价格是否合理？是否在用户授权范围内？能不能立即支付并拿到结果？

这也是 agentic payment 和传统 payment 的关键区别。

传统支付更擅长处理“人已经决定购买以后，钱如何完成流转”。而 agentic payment 真正要解决的是：软件在执行任务时，如何按需购买资源。表面上看，这只是付款位置的变化。但如果这个变化成立，很多互联网资源的商业模式都会被重新打开。

一旦软件可以按需购买资源，很多原来只能被打包销售的数字能力，就有机会被拆成更小的付费单元。一次 API call、一次数据查询、一次模型推理、一次网页抓取、一次身份验证，甚至一次 agent-to-agent 服务调用，都可能变成可以被 agent 临时购买的资源。

这些东西过去当然也能收费，但收费方式常常很重：注册、订阅、充值、套餐、额度、销售沟通、合同。对公司来说，注册、订阅、套餐、额度、合同这一套模式很熟悉。但对 agent 来说，它很不自然。

Agent 最自然的购买方式，不是先变成一个 SaaS 用户，而是在需要某个资源的时候，直接看到价格，确认授权，完成付款，然后继续任务。

这就是 402-style protocol 最有想象力的地方：它把支付从“页面里的一个动作”，变成“任务流里的一次响应”。

如果这件事成立，很多互联网资源的商业模式都会被重新打开。数据服务不一定只能卖整月订阅，也可以卖单次查询；API 不一定只能卖企业套餐，也可以卖按次访问；小工具、小模型、小 agent，也可能把每一次服务调用变成收入。

这不意味着 subscription 会消失。大客户、稳定需求、高频使用，仍然会需要合约、套餐、额度和账户体系。但在 subscription 之外，会多出一层更细的市场：按资源付费，按调用付费，按结果付费，按 agent 任务中的一次需要付费。

这可能是 402 复活真正重要的地方。它不是让旧互联网多一个支付选项，而是让很多原来不能被轻量交易的数字资源，重新具备了被软件购买的可能。

如果 402 成立，价值会流向哪些层

如果 402-style protocol 真的变成 agent 时代的 payment request layer，价值不会只停留在协议本身。它会沿着 agent 购买资源的链路，分散到几层基础设施里。

第一层，是 API 和 data provider。这是最直接的一层。今天很多数据服务、搜索服务、分析工具、链上数据、身份验证、风控接口，仍然以 subscription 或 enterprise contract 为主。这个模式适合人和公司采购，但不一定适合 agent 临时调用。如果 402-style payment 成熟，API 和 data provider 可以把一部分服务从“卖账户、卖套餐、卖合同”，拆成“卖一次访问”。

不需要先注册，不需要先签合同，也不需要先买一个月套餐。请求来了，报价；付款完成，释放结果。这对长尾 API、专业数据、小模型服务尤其重要。它们未必能让一个人专门注册账号，但可能会被很多 agent 在任务中偶尔调用。

第二层，是 wallet 和 agent wallet。Agent 可以付款，并不等于它应该无限制付款。真正难的问题是：谁来保存资金？谁来设置预算？谁来限制可购买的服务类型？谁来记录这笔钱为什么花出去？如果 agent 买错了，责任怎么界定？这些都不是单纯的支付问题，而是权限和控制问题。

所以 agent wallet 的价值，不只是“让 agent 有一个钱包”，而是成为 agent 的支出控制层：预算、白名单、规则、授权、审计、撤销、风险控制。

人类钱包解决的是“我如何持有和转移资产”，Agent wallet 还要解决的是：“软件在什么条件下，可以替我花钱”。

第三层，是 stablecoin 和 chain。

稳定币在 agent payment 里出现得很自然，不是因为 agent 要投资 crypto，而是因为它需要一个稳定的计价和结算单位。一个 agent 为一次数据查询支付 0.1 美元，为一次模型调用支付 0.03 美元，为一次工具结果支付 1 美元，它关心的不是资产涨跌，而是价格是否清楚、预算是否可控、付款是否可编程、结算是否能被验证。

这也是为什么 USDC、USDT，以及 Base、Solana、BNB Chain 这类低成本网络会进入这个讨论。当然，这不代表所有 agent payment 都必须上链。信用卡、虚拟卡、银行账户、Stripe、企业支付系统都还会存在。

但在小额、高频、跨平台、机器可读、需要快速结算和可验证记录的场景里，稳定币和链上结算确实更容易变成底层选项。

第四层，是 facilitator / payment gateway。

大多数服务方并不想自己处理链上细节。他们不一定想管理钱包、处理 gas、验证签名、支持多链、多资产、多种 payment payload。

他们真正想要的是一个更简单的接口：有人替我确认付款已经完成，我只需要在付款确认后释放资源。这就是 facilitator 的位置。它有点像 agent payment 里的 payment service provider，但形态不完全一样。它帮助服务方验证付款、执行结算、抽象链上复杂性，也可能连接传统支付和稳定币支付。如果 402-style protocol 变成更多 API 和 agent 服务的入口，facilitator 可能会成为非常关键的基础设施层。

第五层，是 agent platform 和 marketplace。

当越来越多服务可以被 agent 按次购买，新的问题会出现：agent 怎么知道该买哪个服务？这就不只是支付问题，而是 discovery 和 trust 问题。

哪些 API 可用？价格是多少？质量怎么样？响应是否稳定？有没有历史记录？是否值得信任？同类服务之间怎么比较？

如果未来有大量 pay-per-call service 出现，agent platform 很可能会把 discovery、trust、pricing、payment、execution 放到一起。到这一步，支付就不只是一个结算动作，而会变成 agent marketplace 的一部分。

所以 402 的商业机会，不是“某个协议收手续费”这么简单。它更像是在打开一条新的价值链：资源提供方可以更细地卖，agent 可以更轻地买，钱包负责权限，稳定币和链负责结算，facilitator 负责支付执行，platform 负责发现和匹配。这也是为什么我觉得 402 值得关注。它不是一个孤立的协议新闻，而是在提醒我们：当软件开始成为新的买方，互联网资源的定价、分发和支付方式都会跟着变。

支付入口从按钮变成协议

过去二十多年，互联网支付入口大多是给人设计的。按钮、购物车、checkout 页面、订阅套餐、二维码、App 内购买、Stripe link、PayPal button，都是这个时代的典型入口。

它们背后当然有很复杂的金融基础设施，但在用户体验上，都围绕一个前提：屏幕前有一个人，他会阅读、判断、点击、确认，AI Agent 让这个前提开始松动。

未来的很多购买行为，可能不会从一个人看到页面开始，而是从一个软件发出请求开始：它需要某个资源，服务方返回价格，agent 检查权限和预算，支付完成，资源释放，任务继续。

在这个流程里，支付入口不一定是一个按钮，而可能是一次 API response、一个 402 Payment Required、一段机器可以理解的 pricing metadata、一笔稳定币授权、一个 wallet policy，或者一个 facilitator 的验证结果。这就是 402 复活背后的真正变化。

它不是 HTTP 多了一个被重新包装的状态码，也不是 crypto 又找到了一个新叙事，而是互联网正在出现一种新的经济参与者：替人工作的软件。

当访问资源的不再只是人，而是 agent；当购买动作不再只发生在 checkout 页面，而是发生在任务执行过程中；当数字资源可以被按次、按需、按结果调用，支付入口就会开始从页面、按钮和账户，移动到请求、响应和协议里。这件事现在还很早。

早期数据有噪音，协议之间也会竞争，很多服务只是实验，很多 agent 还没有真正稳定地进入生产环境。但这个方向已经值得认真看。

因为 402 的复活，本质上不是一个技术怀旧，而是在问一个更大的问题：如果 AI Agent 开始成为互联网的新用户，互联网原来的支付系统，够不够它用？我的判断是：不够。

不是因为信用卡、Stripe、PayPal、银行账户会消失，而是因为它们主要解决的是人类 checkout。Agent 需要的是另一层东西：机器可读的价格、可控的授权、即时的支付、可验证的结算，以及付款后自动释放的资源访问。这就是 x402、L402、T402、B402 这些协议共同指向的位置。

它们还不成熟，也不一定都会成功。但它们正在把一个长期沉睡的状态码，重新放回互联网的中心问题里。

当机器开始参与经济活动，互联网应该如何让价值像信息一样被请求、验证和传递？