AI智能体也要花钱:Stripe与iWallet正在构建机器支付轨道

3 阅读11分钟

\n\nStripe与iWallet分别推出MPP和ASP协议,旨在解决现有支付体系无法适配AI自主交易的问题。前者关注机器支付授权,后者聚焦复杂的多方结算,共同助力AI智能体实现经济闭环。

译自:AI agents need to spend money — Stripe and iWallet are building the rails

作者:John Biggs

两种新的协议,一种来自Stripe,另一种来自名为iWallet的金融科技初创公司,正试图解决同一个问题:我们现有的支付基础设施是为人类构建的。那些需要购买商品、调度资金和结算多方交易的AI智能体正面临重重阻碍。以下是必须改变的现状。

当Stripe在2010年推出时,它解决了一个具体的问题:在互联网上收钱异常困难。Stripe抽象掉了银行关系、商户账户和欺诈逻辑。突然之间,任何人都可以在一个下午内接受信用卡支付。这是为尝试在网上进行贸易的人类提供的基础设施。

我们现在正处于一个不同的时刻。AI智能体——能够自主规划、行动并评估结果的软件——开始需要花钱了。这不仅仅是授权一笔随后由人类审核的交易,而是要在没有人触碰键盘的情况下,实际完成购买、在多个参与方之间调度款项,并结算复杂的多方供应商财务关系。Stripe为人类驱动的电子商务构建的基础设施并非为此设计,这一差距正成为一个真正的瓶颈。

最近的两项进展让这种紧张关系变得显而易见。Tempo和Stripe共同发布了机器支付协议(Machine Payments Protocol, MPP),这是一个用于AI智能体及其所需服务之间进行程序化交易的标准。另外,服务于家庭服务行业的金融科技公司iWallet勾勒出了它所谓的自主结算协议(Autonomous Settlement Protocol, ASP),旨在用于经过验证的物理事件(如完成暖通空调维修)自动触发多方财务结算的场景。这是两个不同的团队,在攻击同一个问题的两个不同层面。两者单独都不足以解决问题。但结合在一起,它们揭示了支付堆栈需要进行多大的变革。

支付是为人类构建的

今天的支付基础设施假设人类参与其中。创建账户需要身份验证。选择定价层级需要阅读UI。输入账单详情需要填写表单。即使是对开发者最友好的支付API,也假设人类工程师在某个时刻对其进行了配置,并且人类持卡人正在授权扣费。

AI智能体打破了这些假设。一个能够自主调度云计算任务、调用付费API,然后将成本分摊到适当成本中心的智能体,需要在没有人类干预的情况下进行交易。同样,作为多步骤旅行行程的一部分,预订一段航程的智能体不能停下来在结账表单中输入其公司卡详细信息。一旦你引入了必要的人类触点,你就中断了使智能体发挥作用的自主性。

随着智能体系统变得能力更强,这个问题变得更加棘手。简单的按Token计费的API调用已经实现。更有趣且更困难的案例涉及需要购买服务、触发现实世界行动并代表用户或组织管理持续财务关系的智能体,而不会让每笔交易都变成一张客服工单。

第一层:机器支付协议

Tempo/Stripe的机器支付协议直接针对交易层。该协议建立了一个标准,规定了AI智能体如何请求资源、授权支付并以编程方式完成交易。企业通过现有的Stripe基础设施接受这些支付,支持卡支付、先买后付选项和稳定币,同时保留他们已经使用的相同报告、欺诈保护和结算管道。

早期用例展示了已经运作的范围:智能体按API调用付费、按需购买服务,以及触发发送实体邮件或下单订餐等现实世界行动。这些在商户端都是相对简单的、离散的、单方的、由人类配置的交易,即使买方是自动化的。

MPP没有解决的是结算层:即在资金易手后,当多个参与方都应获得其中的一部分资金时会发生什么。这是一个不同的问题,而家庭服务行业为此提供了一个意想不到且具有启发性的案例研究。

第二层:物理世界中的多方结算

在美国,家庭服务每年产生超过一万亿美元的产值。一次暖通空调(HVAC)安装可能涉及制造商、区域分销商、持牌承包商、融资公司以及一个或多个公用事业回扣项目。每个参与者都期望获得其交易份额。今天,这些关系中的每一项都是通过手动开票、电子表格和对账来解决的,这在工作完成后可能需要数天或数周时间。

“支付是将资金从客户手中移走……结算则决定了这些资金最终流向何处。我们的目标是为服务经济实现整个过程的自动化。” ——Jim Kolchin,iWallet首席执行官

iWallet的首席执行官Jim Kolchin将其定义为一个结算问题,而非支付问题。“支付将资金从客户手中移走,”Kolchin说道。“结算决定了这些资金最终流向何处。我们的目标是为服务经济实现整个过程的自动化。”这种区分很重要,因为这两个层面需要不同的解决方案。

iWallet已经为承包商和服务公司处理了数亿美元的支付额。其现有平台处理移动支付、融资集成、回扣处理和工后资金分配。该平台的下一个版本(内部称为iWallet 4.0)引入了Kolchin所描述的可编程结算层:一旦获取支付,一组定义的规则将自动决定资金如何流向该项工作供应链中的每个参与者。

在技术上更有趣的补充是机器验证。家庭服务环境的数据日益丰富。现代暖通空调系统传输远程遥测数据。安装人员拍摄完工照片。设备带有可对照制造商记录检查的序列化标识符。能源效率项目收集安装数据,以确定客户是否有资格获得回扣。

ASP设计利用AI智能体分析这些信号、工作文档、设备数据、安装图像和IoT设备读数,并确认服务事件已正确完成。该验证事件随后自动触发结算序列。无需提交文书工作。无需等待回扣项目处理表单。事件本身完成了财务闭环。

为何如此困难:技术差距

这两种方法在方向上都是正确的,且都遇到了真正的工程问题

机器对机器的支付授权需要以当前系统无法清晰支持的方式解决身份和信任问题。当AI智能体出示凭证以完成购买时,谁是责任方?如何执行支出限制?当智能体犯错或被操纵进行错误交易时会发生什么?卡网络、银行风险系统和欺诈检测管道是根据人类行为信号进行训练的。默认情况下,智能体发起的交易看起来会很异常。

结算层增加了另一个维度的复杂性。可编程资金分配需要参与方之间正式的协议结构,而这些结构目前尚未以标准化形式存在。承包商、制造商和公用事业回扣项目各自拥有不同的系统、不同的时间表和不同的收款条件。让这些参与方在工作开始前就机器可读的结算规范达成一致,是一个远超软件范畴的协调问题。

机器验证引入了其自身的可靠性问题。计算机视觉确认安装照片符合预期标准,或传感器遥测表明维修成功,其执行水平必须达到这样一个高度:即争议结果不会产生比它们所取代的手动流程更多的开销。误报会触发对未完成工作的支付,而漏报则会延误合法承包商的收款。

而在这一切之下,是监管层未能跟上技术的步伐。跨多个参与方的自动资金拨付正开始看起来像资金转移(money transmission),这是金融服务中受监管最严格的活动之一。监管机构如何对待智能体授权的交易,以及当交易出错时由谁承担责任,目前尚未定论。

需要存在的堆栈

如果你绘制出自主经济闭环可靠关闭所需的要素,你会得到类似这样的结果:

在交易层,像MPP这样的协议需要从早期用例走向成熟,以金融系统认为值得信赖的方式处理授权、身份和错误恢复。MPP中对稳定币的支持在这里值得注意。稳定币避开了传统卡网络中的一些摩擦,并可能正因为其可编程性而成为智能体对智能体贸易的原生货币。

在结算层,工作更多在于标准化而非技术。有条件路由资金的软件已经存在。不存在的是一种共享的规范语言,让多个参与方、设备供应商、融资公司、保修管理员和回扣项目能够同意将其支付条款编码于其中。iWallet实际上正试图为一个垂直行业创建这种规范。更难的问题在于它是否具有通用性。

在验证层,需求是能够以足够的可靠性确认现实世界服务事件的AI系统,从而证明触发财务后果是合理的。这就是物理IoT系统与智能体AI的交汇点,成为了真正新颖的工程领域。信号是存在的:设备遥测、图像文档和序列化组件跟踪,但将它们集成到一个结算逻辑可以信赖的管道中,需要大多数服务行业尚未进行的底层设施投资。

实际交付情况

直截了当地说明现状:MPP是真实存在的,且已上线,在生产环境中处理离散的智能体对服务的交易。iWallet现有的平台是真实存在的,且正在处理大量的支付额。ASP路线图是一个前瞻性的设计,而非现成的产品。

MPP目前处理的内容与ASP愿景之间的差距,实际上是未来工作的一张有用地图。为单次API调用付费是一个已解决的问题。而根据机器验证的物理结果,在十个交易对手之间自动分配该次调用的收益,距离成为常规操作还有数年的基础设施建设工作要做。

如今人们构建的智能体,充其量只能被授权触发由人类审核的支付。而人们在三年后构建的智能体,将需要自主关闭经济闭环。

但方向已经足够明确,开发智能体系统的开发者现在就应该考虑这个问题。如今人们构建的智能体,充其量只能被授权触发由人类审核的支付。而人们在三年后构建的智能体,将需要自主关闭经济闭环。这些智能体所需的基础设施尚未完全存在,构建它的团队才刚刚开始协作。

2010年代的金融科技革命使得在互联网上向人类收钱变得容易。未来十年的变革将使软件能够代表人类管理资金,并最终在机器之间管理资金,且具备财务关系所要求的可靠性。Tempo/Stripe和iWallet的工作是对这种基础设施雏形的早期投注。底层工程问题仍然敞开着大门。全 工智能