原文作者：Hendrix，外捕研究（Web3Caff Research）研究员
随着 AI 智能体能力不断增强并覆盖越来越多的端到端任务，面向智能体构建支付系统变成了传统商家、服务提供商必须进行的改变，但现有的方案都有各自的局限：传统支付系统，如信用卡、第三方支付平台等原本是面向真实人类用户设计，要求复杂的身份验证、风险评估等过程，对于智能体不适用；而新兴的智能体支付协议，如 x402（由 Coinbase 开发推广）、MPP（由 Tempo 和 Stripe 开发的 Machine Payment Protocol）等又像是另起门户，完全面向链上支付构造，整个支付在链上处理，靠链上验证保证安全，服务提供商需要在传统支付渠道之外另外搭建一套不同的支付系统，提升了使用门槛。传统支付方案和新兴智能体支付协议像是两条平行的车道，并没有很好的融合在一起，这也导致智能体能够自主购买的服务通常限制在 Web3 友好的范围内，因此无法大规模串联工作流。为此，Solana 基金会与 Google Cloud 联合发布 Pay.sh，定位为 “智能体与企业级服务设施之间的支付网关”，打通智能体调用更多服务的最后一步。
合规提示：以下内容仅为客观分析 Pay.sh 及其技术原理与设计规则，并不构成任何提议和要约，请您勿以此信息进行相关决策，并请您严格遵守您所在国家和地区的法律法规（中国大陆读者强烈建议阅读《中国大陆涉及区块链与虚拟货币相关法律法规整理及重点提要》），不参与任何您所在国家和地区法律禁止内的相关金融行为。
Pay.sh 允许用户通过信用卡或者稳定币给 Solana 钱包快速充值，此后 Solana 钱包就可以在 Web2 资源世界中充当智能体的身份和支付账户代理。当智能体需要调用服务时，无需再注册账户或输入 API 密钥，Pay.sh 网关会像 Google 身份系统一样声明智能体的合理身份，允许智能体使用统一账户身份购买 Google Cloud 、阿里云等过去难以获取的开发资源。
当前 Pay.sh 已支持的 API 服务 图源：项目官网
Pay.sh 的支付流程与前段时间大火的 x402 协议类似，都是建立在 HTTP 402 状态码之上：当智能体发现需要调用的外部服务时，它会对付费资源发起请求，服务器会返回状态码 402（需要支付），并同时附上支付的详细信息，包括支付金额、付费方案、收款地址、支付有效期等等。Pay.sh 会解析相应的内容并向钱包发起授权，钱包支付完成并生成支付凭证后，Pay.sh 会携带凭证再次发起服务请求就能获得正常的响应。但为了覆盖各种 API 使用场景，Pay.sh 同时兼容了 x402 和 MPP 的支付逻辑：当服务器返回状态码 402 时，Pay.sh 会进一步判断目标服务的付款方式，如果是一次性的数据访问（支付获得一次访问权限），或者是基于用量的访问类型（支付获得固定量的访问权限），Pay.sh 会构造一笔一次性固定数额转账并在链上广播；如果是连续性计费或者基于会话的计费（按照用量统一账单一次性支付），Pay.sh 会支持 MPP 协议（Machine Payment Protocol）推出的会话授权凭证，将预算上限写入授权并传回给服务器，这时智能体就可以在短时间内反复调用某项服务，避免频繁发起同类授权，Pay.sh 会在每次调用时更新剩余额度，当额度耗尽或者服务过期时会自动重新发起会话授权。Pay.sh 会根据目标服务的要求自动选择更合适的支付轨道，能够降低使用成本和管理成本。Pay.sh 同时会保证钱包始终在本地安全存储，仅在需要支付时请求用户确认。当有信息返回时，Pay.sh 会区分数据和指令，服务商返回的所有外部内容（包括标题、正文以及 API 描述）都会被 Pay.sh 视为不可信输入，代理不得直接执行服务商返回的指令防止恶意的提示词注入或其他攻击。
Pay.sh 最大的优势在于，它为服务提供者也提供了一套可以轻松部署的网关，服务商无需对自己的支付通路或者 API 进行大规模修改就可以将支付网关集成在自己的服务网络内。服务商只需要提供一个声明式文件，说明支付相关的参数就可以适配各种复杂的使用场景，比如通过定义路由规则，可以让智能体在一定量内免费使用服务，超过定额开始收费，甚至可以实现阶梯式收费（不同用量收取不同价格）；此外 Pay.sh 还提供支付拆分功能，服务商收到的费用可以自动发往多个地址，例如 2% 支付数据版权费，5% 支付云成本，剩下部分留给自身运营，服务商只需要在设置收款地址时定义不同的百分比或者金额就可以一次性实现多账户结算。完成注册后服务商可以将自己提供的 API 服务员数据发布到 Pay Skill Registry，智能体可以通过查询注册表来发现和选择合适的 API 服务。
Pay.sh 本身并不是 x402 和 MPP 的竞争者。当 x402 和 MPP 协议尽可能的将链上智能体支付变得更加可靠时，Pay.sh 想做的是将 Web2 和 Web3 支付生态打通，为智能体获取资源赋予相应的身份。智能体的钱包既是身份也是支付方式，它无需再自行在服务商官网注册账号获取服务（目前部分服务商可能会将智能体模仿人类注册服务当作违规行为处理）。此外 ，Pay.sh 通过与 Goolge 的合作能够让智能体执行 API 代理和流量调度在 Google Cloud 商完成，可以保证访问控制与日志合规，将智能体的行为规范在合理地带内。Pay.sh 能够提供经过筛选的服务目录与定价发现，智能体无需在无防护的网络环境内随机发现服务，同时能够调用 x402 与 MPP 的不同支付方式，服务过程能够在 Google Cloud 上完成企业合规要求，这些都补全了 x402 与 MPP 作为单一的支付通道无法覆盖的智能体支付能力，同时也为智能体商业向 Web3 流动打开了入口。此外 Pay.sh 也能为 Google 推出的多个智能体商业协议补上最终的支付环节，比如 A2A（Agent2Agent Protocol）可以完成智能体间的通信与任务委派，AP2（Agent Payments Protocol ）可以完成合规验证，UCP（Universal Commerce Protocol）能够完成服务发现和执行，Pay.sh 则负责最终的服务价值无痛结算。Pay.sh 的出现也同时完善了 Web2 智能体商业的环节，成为了两个世界价值流动的交汇点。这一步同时也是 Solana 公链生态本身的升级机会。在 x402 协议环境中存在大量的套壳 API，服务提供者存在违反原始服务商的服务条款并对其服务进行转售的情况，比如恶意抓取数据库网站数据转售，或者将大模型 API 封装后转售给他人的情况。智能体在这种环境下没有办法分辨哪些是经过授权的服务，哪些是恶意垃圾服务，而通过 Pay.sh 支付网关和 Google 的配合，智能体在通过 Pay.sh 使用服务时有望降低潜在的风险。Pay.sh 的推出标志着 Solana 公链下场为智能体支付提供背书和基础设施支持，这不仅能够为 Solana 本身引来更多的 Web2 支付流量，也能够进一步提升 Solana 钱包本身的能力并加速普及。
但 Pay.sh 目前距离一个完美的支付网关方案还很远。Pay.sh 的服务商注册表目前缺乏准入机制以及去中心化验证机制，仍旧很难有效区分未授权的第三方套壳服务以及恶意服务，智能体有很大的风险接入冒牌服务，给用户带来损失。此外，由于 Pay.sh 本身不做底层的支付协议设计，支付过程的安全其实更多的落在了底层协议本身的设计上，这为 Pay.sh 引入了不可控的外部风险，同时也有可能因为对不同协议适配不足导致潜在的支付失败。从服务商的角度来看，尽管有 Google 平台的背书，不同国家和地区的 API 供应商仍有可能出于服务本身对数据隐私管理的合规需求以及对支付的合规需求，对 Pay.sh 提供的服务望而却步。这不仅会限制使用 Pay.sh 的服务商数量，还有可能在未来要求 Pay.sh 做出更多合规上的努力。但不论如何，Pay.sh 的推出都标志着智能体支付基础设施迈出了 Web2 与 Web3 融合落地的一步，链上钱包将有机会成为智能体参与多样任务的背书。因此我们可以继续观察 Pay.sh 相应的后续发展。
要点结构图：
免责声明: 本报告由外捕研究（Web3Caff Research）编写，所含信息仅供参考，不构成任何预测或投资建议、提议或要约，投资者请勿依赖此类信息购买、出售任何证券、加密货币或采取任何投资策略。报告中使用的术语和表达的观点旨在帮助理解行业动向，促进 Web3 包括区块链行业负责任发展，不应被解释为明确的法律观点或外捕研究（Web3Caff Research）的观点。报告中的看法仅反映作者截至所述日期的个人意见，与外捕研究（Web3Caff Research）立场无关，且可能随后续情况而变化。本报告中所含的信息和看法来自外捕研究（Web3Caff Research）认为可靠的专有和非专有来源，并不一定涵盖所有数据，亦不保证其准确性。因此，外捕研究（Web3Caff Research）不对其准确性和可靠性作任何形式的担保，也不承担以任何其他方式产生的错误和遗漏的责任（包括因疏忽而对任何人产生的责任）。本报告可能含有 “前瞻性” 信息，这类信息可能包括预测和预报，本文并不构成对任何预测的担保。是否依赖本报告所载信息完全由读者自行决定。本报告仅供参考，不构成购买或出售任何证券、加密货币或采取任何投资策略的投资建议、提议或要约，并请您严格遵守所在国家或地区的相关法律法规。
原文链接：https://www.odaily.news/zh-CN/post/5210732