AI替人下单：支付宝、AWS抢着接通智能体付款

今年9月，金融数据服务商Massive上线了一个面向智能体的股票数据按次付费入口。智能体接上支付钱包后，执行任务时就能买下所需数据：用USDC付完款，再拿到结果。调用方通过这条新入口可以按请求购买，不用事先开通传统订阅、也不用保存API密钥。原有的订阅服务照旧保留。

这样一来，交给AI的一项研究任务，中途就可能产生一笔真实采购：用户给出目标，AI发现数据不够，就在被授予的权限内买下来，接着做分析。挑服务、付钱、拿到结果，正逐渐成为AI干活时连贯的几步。乌镇峰会上关于智能体身份、授权与跨平台协作的讨论，也因此有了很具体的落点。蚂蚁集团副总裁陈亮表示，要让身份、授权和责任进入每一次连接。AI开始替人采购之后，商家得知道是谁在付款，用户也得清楚自己把多大的决定权交了出去。

眼下已经开放的这些入口，主要面向数据、API和数字服务。钱还是用户或企业的，支付来源要提前配置好；AI能花多少、能买什么，由授权范围说了算。变化出在任务执行过程中：有些原本要人一项项办的采购，现在可以交给AI去做。

交给AI的任务里，多了一笔采购

传统软件同样会自动调用收费接口，按次数计费早就有了。一般是由开发者先选好供应商、开好账户、配好凭证，软件运行时沿着已经接通的线路去调用。用户看不到这些过程，但采购关系早就定下来了。智能体想做的，是把其中一部分选择推迟到任务执行的时候：先判断需要什么能力，再找到对应的服务，问清价格，在授权范围内付款并拿到结果。服务商不一定非得先挤进开发者固定的采购清单，才有机会挣到这一笔。

Massive的入口就是这种路径的一个例子。智能体发现数据服务后发起请求，服务端通过HTTP 402返回付费要求；等付款完成、凭证通过校验，数据才会返回。HTTP 402可以简单理解成网页通信里“这里要收费”的信号，它把请求资源和支付费用接在了一起。

不妨设想一次研究任务：AI做完初步检索，发现还缺一段收费的实时数据。拿到相应的预算和权限后，它买下这部分材料，再继续分析。用户最后收到研究结果，账单里则多出一项外部数据支出。这个示意场景说明，委托AI做事和授权AI花钱，正在同一项任务里碰头。

任务需要的能力越多，这类采购关系就越有意义。智能体不必自己造齐所有工具，可以按需调用外部服务；提供工具的企业，也有机会只卖自己擅长的那一小段能力。前提是任务确实用得上它，而且调用结果能被后面的流程接住。大量服务上线只是增加了供给，替代不了真实需求。

这也会改变“小功能”的商业想象。过去，一个工具用得不多，想让用户专门注册、订阅并不容易。按次采购则允许它在某个任务需要时冒出来，完成一次转换、一次查询或一项计算，再收对应的费用。生意能不能成立，要看每次调用带来的价值够不够覆盖供给和交易成本。

支付宝和AWS开始接通这笔付款

国内市场也已经有对应产品。支付宝Machine Pay面向API、数字内容、算力资源等提供按用量收费的方案，支持服务商向访问这些资源的智能体发起收款。它把服务请求、价格反馈、付款和履约串在一起，开发者可以为单次调用设置收费。

对用户来说，支付接进来意味着采购有机会在任务中一气呵成，省掉逐家注册、配置调用凭证的麻烦。对供应商来说，商品也得写得更清楚：卖什么、收多少、交付什么，都要让程序读得懂。光接上收款能力，还不足以让AI挑中这项服务。

海外的云平台也在往同一环节挤。AWS今年5月发布AgentCore payments预览功能，与Coinbase、Stripe合作，支持智能体在执行过程中购买API、网页内容、MCP服务及其他能力。用户要授权钱包，并设定会话支出限制，交易记录会进入监控体系。AWS还把服务发现接了进来：借助Coinbase的x402 Bazaar目录，智能体可以搜索自己需要的收费服务。目录和支付一起进入开发环境，意味着云平台开始影响智能体去哪里找供应商，以及一项付费能力怎样接进工作流程。

支付宝一头连支付、一头连开发者，云平台一头连智能体运行环境、一头连外部服务，两条路径都在减少临时采购的摩擦。它们的商业位置也因此不止于一个前台聊天入口：即使用户用的是别家公司的AI助手，任务里的某一笔交易仍可能从它们手里过。

这也是支付、云服务和工具平台愿意提前投入的原因。智能体产品还会不断变，但任务对数据和服务的需求可能一直在。谁能把发现、调用和结算做扎实，谁就有机会参与更多应用的交易。接入方便了，供应商之间的竞争也会被推着走，平台还得有持续交易才能见到回报。

按次花钱，也要算一项任务的总账

面对这样的客户，服务商首先得换一种方式表达商品。面向人的销售页面可以放案例、给试用，让销售人员去解释套餐；面向智能体，还得给出机器能读懂的接口定义、参数要求、价格和返回格式。调用失败时怎么反馈，也会直接影响任务能不能往下走。

这些看着像技术文档的细节，正在靠近商业转化那一环。一个服务就算功能很好，如果智能体判断不了它接受什么输入、会返回什么结果，就很难在任务中被临时用上。品牌知名度仍然有价值，但还得转化成可调用、可验证的产品能力。收费单位也可以切得更细：用户订阅一款软件，买的通常是一段时间内的使用资格；智能体临时采购，则可以只买一份数据、一次处理或一次工具调用。Massive保留传统订阅、同时加上新入口，说明这两种方式能并行。高频客户需要稳定的安排，偶发任务可能更适合临时购买。

用户会碰上一笔更细碎的账。一次查询看着便宜，可反复调用同一个工具，累计支出可能超过订阅套餐；结果不合要求，还可能付费重试。每一步都不贵，不等于整项任务划算。服务商也得在单次价格与计算、维护成本之间找平衡，按次收费让买卖双方都得把使用量估得更准。

服务商也得划清自己交付到哪一步。数据接口按约定把材料交出来，研究报告好不好，还要看后面的分析；图片工具把文件给到创作方，创作方仍得判断它合不合整部作品的要求。采购者只有弄清自己买的是什么，才能把不同服务拼成一件完整任务。

所以替用户采购，里面也包含对质量和总花销的判断。某项服务贵一点，但能少掉后面的重试和人工返工，整件任务算下来可能反而更值。AI只会挑便宜接口，还当不了靠谱的采购者；它得判断买来的能力能不能让任务往下走，并把开销压在委托范围之内。

谁决定AI把钱花给谁

一旦AI开始替我们挑服务、付钱，订单就会顺着它的选择走。它去哪个目录里找服务、怎么排序、会不会优先用某个平台合作方的产品，都牵动着钱最终落在谁手里。过去商家争的是用户点一下，往后可能还要争着进AI执行任务时的候选名单。

AWS接入服务目录，正是一个能观察的起点——发现和购买在这里接上了。各平台可以各自维护目录，供应商也能提供多个入口。一个工具能不能跨平台被发现、被调用，直接决定它能碰到多少潜在任务。

买卖双方的利益在这里也不总是一致。用户想用合理成本把任务做完，工具商想多拿调用收入，平台想做大交易量。将来服务推荐里要是掺进付费推广、商业分成，推荐规则就得和委托方自己的目标分开来。这是个随市场长大而要处理的商业问题，光靠模型“聪明”解决不了。

用户的委托还要落成具体的采购权限：任务能买哪些服务、能花多少钱、什么情况下必须回来问一声，都得变成可执行的限制。AWS预览产品里的会话预算，就是这类安排的一种落地方式。任务拖得越长，越要让用户看清累计花了多少、买回了什么。

对重度AI用户来说，账单也得更明白。模型推理本身要花钱，外部数据和工具各有各的价。一次任务的总支出，会横跨不同供应商的服务。产品只显示模型消耗，用户就难判断某项任务为什么变贵；要是能把采购项目、返回结果和费用一一对上，用户下次批多少预算才有依据。

乌镇之所以要谈身份与授权，道理也在这里：服务商得知道调用者代表谁，用户得能管住委托的边界，平台得留下可追溯的交易记录。这几层关系接得上，跨平台采购才可能从一次演示变成经常做的生意。

对开发者来说，能稳定拿出专业数据、处理能力或者行业工具，就有机会挤进这类采购的供应商名单。他们要盯付费调用能不能反复发生，也要看同一任务里的总成本合不合理。用户拿到能用的成果、愿意再授权，持续订单才会来。

智能体支付还在早期，AWS对应功能也是预览形式推出。眼下能确认的进展，是数据商、支付平台和云平台已经开始为任务里的采购提供产品。要让AI在更多消费场景里代为下单，还得商家接入、支付支持和用户授权继续跟上，现有能力到哪儿为止，界限仍然清楚。

AI开始替我们花钱，付费决定就不再全发生在点下“开始任务”之前。执行到哪一步、还差什么、值不值得买，都可能改写最终账单。用户交出去的是一部分采购决定权，想换回来的是成果，外加一笔说得清的支出。这两样谁能做好，谁才更可能拿到下一次授权。