AI 支付的陷阱：链上转账不等于买到真实服务

BiRun 消息，撰文：Vaidik Mandloi 编译：Chopper，Foresight News 如今由 AI 生成的虚假收据，已经占到所有被标记费用欺诈案例的 71%，而一年前，这一数据还是 0，并且目前这类欺诈行为大多仍由人类实施。 现在，我们拥有了能够发现服务并通过 x402 进行支付的 AI 代理，这一切都无需任何人工审核。随之而来一个难题是，如何核验这些智能体究竟实际购买了什么。OpenAI 近期发布一份实操指南，为支付流程实现收据核验与三方对账提供方案。 这是目前我们所能看到针对智能体支付最接近可用的欺诈校验方案。本文拆解了这套核验机制完整运行逻辑：链上结算记录，能否证明智能体以正确价格、从正规供应商买到对应商品？还是仅仅只能证明资金发生了转移？ 欺诈校验机制 AI 智能体已经在自主执行采购行为。一个负责采购任务的智能体，可能为获取数据向权限 API 付费、调用其他大模型算力处理自身无法运算的数据，或是购买付费墙背后的市场情报。随着这类交易越来越多，一个关键问题浮出水面：如何验证智能体实际买到的东西。 如今所有处理费用报销的企业都拥有一套收据核验流程。当员工完成采购，提交收据；应付账款部门会把收据、采购订单、银行流水三者交叉核对，之后才完成打款。 这套流程已经沿用数十年，能够生效的核心原因在于：三份核验记录来自相互独立的不同主体。采购方出具采购订单，另一方负责收货，供应商开具发票。想要造假，就必须串通三方共同伪造记录，而这种串通的高昂成本，在很大程度上遏制了欺诈。 现在，智能体支付正在搭建一套类似的校验流程。当智能体想要向付费 API 发起采购，它并不能直接完成交易。请求首先会递交至应用层，应用层依据预先配置的支出规则进行校验，包含预许可商户名单、预算上限、准许的消费品类。一旦请求不符合策略规则，这笔采购直接被拦截。 链上支付执行完成、智能体获取对应服务之后，应用层会执行第二轮校验，比对三份信息： 智能体自身上报的采购内容采购过程由应用独立生成的收据区块链生成的结算记录伪造收据会在这一步被识别。即便智能体谎称交易并未发生，应用层已经留存独立记录与之相互印证。 对于智能体欺诈检测来说，这已经是巨大进步，在此之前完全没有可行核验手段。但对比传统收据核验模式，这套方案存在短板：传统模式三份凭证分别来自互不相关的第三方；而智能体支付体系里，两份凭证 —— 智能体的上报信息、应用生成的收据，都来自这套系统开发者自身的软件。唯一真正独立的外部凭证只有链上记录。 同时链上记录本身承载信息十分有限：支付签名只会记录付款方、收款方、转账金额，并不包含实际采购标的物信息。资源元数据、访问地址、内容描述会跟随签名报文一同传输，但并不属于密码学校验覆盖范围。 也就是说这套核验，仅能够确认智能体上报内容和转账记录保持一致，却没办法核实花钱之后，智能体究竟拿到了什么。 举个例子：智能体花费 2 美元购买一份供应商风险报告，链上可以确认 USDT 已经完成转账；但交付给智能体的报告，可能只是 AI 几秒钟生成的几段无效凑数文本。整套系统依旧会核验通过，因为授权绑定的是转账行为，而非采购标的物本身。 这还会引发全市场层面的问题。买方是一段软件程序，收到返回结果就直接继续运行，不会主动甄别好坏。智能体不会调用信誉系统，也不会货比三家。 除非开发者手动干预，否则无论交付质量高低，智能体会持续向同一个商户下单。提供高质量服务的卖方，失去愿意为优质产品支付溢价的客户；整个市场会向 “能完成请求的最低成本供给方” 倾斜。 任何支付系统都只能容忍一定比例欺诈。想要彻底根除欺诈，付出。