互联网上的价值交换正在发生迁移。过去十年，支付创新的主战场是人与平台之间——怎么让用户更快下单、怎么让商户更省心地收款。但现在，一个更大的交易量正在从人类之手转移到机器之手。API调用按次收费，AI模型推理按token计费，数据接口按请求结算，MCP工具按调用付费......这些行为的共同特征是，发起方是程序，不是人。

　　这个迁移带来一个根本性的问题。现有的支付基础设施是为人类交易构建的，每一步都预设了人的参与。注册账号是人在填表，绑定支付方式是人在输入卡号，确认支付是人在点按钮，对账是人在看账单。当交易发生在机器之间时，这些步骤没有一个能派上用场。程序不会填表，不会收验证码，也不会在月底打开一份PDF对账单。它只做一件事：发请求，等响应。

　　PayGo做的事情，就是让这个“请求-响应”的循环里，直接完成支付。

　　这个思路叫做请求级结算。听起来技术化，但逻辑并不复杂。一次API调用，如果服务方设置了付费，调用方的程序在请求时没有携带有效的付费证明，服务端不会直接拒绝，而是返回一个HTTP 402状态码。这个状态码在HTTP协议里已经存在了二十多年，意思是“需要付费”。区别在于，PayGo的402响应里不只是说“你要付钱”，而是附上了一份机器可读的报价单：价格多少、收什么币种、钱打到哪个地址、怎么证明你已经付过。

　　调用方的程序收到这个402，不需要停下来等人操作。它按照报价单里的信息，自动完成链上支付，拿到一个支付凭证，把这个凭证附在原来的请求里再发一次。服务端验证凭证没问题，返回200，资源交付。整个过程发生在两次请求之间，程序不用跳出当前任务，人不用参与。这是 PayGo 设计的核心逻辑：支付不是一次额外的操作，而是HTTP请求链路里的一个状态转换。402不是报错，是“请先付费再重试”的标准信号。

　　要让这套逻辑跑通，需要解决三个实际问题。调用方的程序怎么自动处理 402？服务方怎么验证支付凭证？不懂代码的服务方怎么接入？

　　第一个问题由Client SDK解决。它封装了402响应的识别、报价的解析、链上支付的执行和凭证的重试携带。调用方开发者引入SDK后，不需要为支付写额外代码，只需要设一个预算上限。SDK兼容浏览器钱包、服务端钱包和Agent钱包，覆盖不同的运行场景。

　　第二个问题由Facilitator解决。它是一个独立的验证层，负责报价的结构化处理、支付凭证的标准化、校验结果的缓存，以及防止同一笔凭证被重复使用。但有一个边界很明确：它不碰钱。调用方付的稳定币直接进入服务方的地址，Facilitator只验证凭证，不托管资金，不中转结算。

　　第三个问题由Gateway托管版解决。不懂代码的服务方，通过可视化的界面就能完成定价配置和接入部署，不需要理解402协议，也不需要写一行代码。对于有开发能力的服务方，Server SDK 封装了报价模板生成、凭证校验和防重放保护，语言版本先支持 Node.js/TypeScript，Go和Java/Spring在规划中。

　　把这些组件放在一起，PayGo提供的是一个完整的闭环：调用方程序自动付钱，服务方程序自动验证，资金直接到账，不需要账号体系，不需要订阅绑定，不需要人工确认。这也解释了为什么它在设计上选择了稳定币优先——服务方收的是USDT或USDC，价值稳定，对账直观。协议自己的代币只做治理和安全用途，不参与支付计价，服务方的商业收入和代币市场波动互不干扰。Agent/MCP Adapter则为AI智能体调用付费工具留好了接口，让这套逻辑可以延伸到机器自主消费的场景里。

　　PayGo不是一个在现有支付体系上打补丁的方案。它从起点开始，就假设了调用者是一个程序，而不是一个人。这个假设看似简单，但它让一系列设计选择变得自然，不要账号，不要订阅，不要人工确认，不要让支付跳出请求链路，不要让资金经过中间账户。它不是在改善支付的体验，而是在移除支付这个动作本身，让它变成HTTP协议里的一个标准响应。对于机器来说，这才是最直接的方式。