流支付/微支付

AI Agent 消费的很多资源天然是“按用量连续计费”的——调用一次 API、读一分钟算力、订阅一段时间的数据流，本质上都不是“一锤子买卖”，而是随时间持续产生的小额费用。但传统“整笔转账”模式下，每一笔链上转账都要付一次 Gas，几厘钱的支付会被 Gas 费吃掉大部分甚至全部价值——这意味着“按秒/按次计费”在经济上根本跑不通，逼得应用只能退回到“预充值+批量结算”的笨办法，与 Agent 高频、细粒度的消费模式脱节。流支付（Streaming Payments）要解决的正是这个“微支付不经济”的结构性问题。

机制原理

流支付的核心思路是把代币转账从“离散的一笔笔交易”改造成“连续流动的资金流”：发起方设定一个每秒流速，代币便按这个速率从发送方账户持续流向接收方账户，且只在流的开始和结束时各产生一次链上交易（对应一次 Gas 成本），中间的“持续到账”是账本状态的连续更新，不需要逐笔上链确认。这样无论这条流持续多久、实际拆分成多少“笔”消费，成本都固定在两次 Gas 消耗，彻底绕开了“每次微支付都要单独付 Gas”的死结。代表协议是 Superfluid——一套让 ERC-20 代币按秒流式转账的协议，允许创建、修改、终止实时资金流，任意时刻账户余额都能被准确计算出来。

流支付协议本身并非 2025-2026 年的新发明，但因为 AI Agent 经济对“按量付费”场景的需求集中爆发，重新被行业视为地基拼图中的关键一块：没有它，Agent 之间大量高频、小额、持续性的资源消费场景就缺一个经济上可行的结算方式。

与 x402 的互补关系

流支付并不是要取代 x402 协议，两者服务的是不同的消费形态：x402 复活 HTTP 402 状态码，适合“请求一次资源、即时付一次款”的单次调用场景（比如调一次 API）；流支付则适合持续订阅式消费（比如持续占用一份算力、持续订阅一条数据流）。一个是“按次结账”，一个是“按秒计费的水表”，Agent 经济要覆盖的支付场景足够多样，需要这两类模式并存互补，而不是二选一。

时间戳

协议机制本身不新，但 2025-2026 年因 AI Agent 经济对按量付费的需求被重新提及为地基层的关键拼图之一（据 raw 调研整理，2026 年 7 月检索）。