Polygon在9月24日公布Agent Pay Channels测试结果：由25个独立Hub组成的集群，每秒处理超过1100万次经过验证的支付更新；单个Hub在引擎直连条件下达到约53.3万至53.6万次，完整x402链路测试约4万次。这组数字瞄准AI代理的高频小额付费，但必须先说清楚，它统计的是链下支付通道更新，不是Polygon主链每秒确认1100万笔独立交易。

代理购买模型Token、数据查询和工具调用时，计费单位可能小到一次请求或100个Token。如果每个微小单位都直接上链，确认延迟和手续费会让模式不可用。Polygon的方案是先把资金锁入通道，代理持续发送累计签名凭证，Hub验证额度和签名，最后把一批状态用Merkle根结算到链上。速度来自把支付流与最终结算分开。

1100万是25个Hub的并行验证能力，最终结算仍按批次上链

流程从预存资金开始。付款方把资金存入不绑定单一商家的通道合约，并关联会话密钥。服务端通过x402表达价格与付款要求，代理消费服务时发出累计凭证。Hub检查签名、价格、重放编号、授权上限与剩余托管余额，验证通过后返回收据，服务商才释放下一段模型输出、数据或工具结果。

Hub会把累计状态批量提交到Polygon，服务商用证明领取收益。参与方可以根据风险与成本选择结算节奏：一次更新后结算，也可以累积五万次甚至更多再结算。频繁的小额更新主要发生在通道和Hub层，主链负责资金托管与批次最终性。因此，把测试结果写成“Polygon链TPS达到1100万”并不准确。

测试条件也需要保留。1100万次结果来自25个Hub、每个16个vCPU的集群；Hub之间按付款方分区，在支付路径上不需要互相协调，因此可以横向扩展。单个Hub的53万次是引擎直连数字，完整x402链路约4万次，后者包含代理、站点、促成方和Hub，更接近真实端到端流程。

Polygon称完整链路共处理240万次付款并达到100%成功，测试对象是一个模仿OpenRouter的推理API，每100个Token触发付款；支付路径真实，推理提供商是替代实现。它证明架构在开发网络和设定负载下可运行，不等于生产环境面对攻击、网络抖动和不同商户时仍能维持同一吞吐。

微支付摆脱预付账户后，新的信任点转移到Hub与结算规则

当前API服务常要求用户预充值。资金提前锁在多个商户账户里，代理也更容易被已有余额限制，难以临时选择更合适的服务。多商户通道的目标，是让代理用同一笔已托管资金按需购买不同服务，付款随工作发生，而不是在服务使用前就把资金分散出去。

便利并没有消除风险，只是改变风险位置。会话密钥被盗可能导致额度内资金被滥用；Hub验证错误或宕机会中断服务；服务商对收据的接受规则、争议处理和结算延迟，也会影响实际体验。合约托管提供余额边界，但不自动判断某次模型输出质量是否达标。

参与方还要设计重放保护、密钥轮换、额度撤销和故障恢复。累计凭证通常只记录最新总额，可降低状态数量，却要求双方正确处理旧凭证和并发请求。如果代理同时调用多个工具，怎样避免超过授权余额，怎样在Hub切换时保持一致，都是生产部署需要验证的问题。

成本数字同样属于基准环境。Polygon称该配置处理10亿次支付更新约耗费0.15美元，这主要反映Hub计算，不应理解为10亿笔主链交易总成本。硬件、网络、运营、监控、流动性与最终上链费用仍会进入商业账单。大规模服务还需要抗拒绝服务能力和可审计日志。

Polygon表示这套能力之后将接入更广泛的Open Money Stack。公告中的“将接入”是路线计划，并非所有OMS客户已经自动获得该功能。开发者目前可以联系团队探索通道，实际可用范围、服务级别与定价仍需按产品阶段确认。

这次测试真正有价值的地方，是把AI代理支付的规模问题拆成两层：高频签名更新用可横向扩展的基础设施处理，较低频的资金结算交给区块链。1100万次每秒展示了链下验证上限，却不是主链性能神话。未来判断它是否成功，要看真实商户接入、端到端延迟、故障率和资金安全，而不只是实验室最高吞吐。