智能体正在拿到一张有额度的"副卡"

过去两年，AI 智能体的能力变化快得有点让人跟不上。

最早的大模型只会生成信息——你问，它答。后来学会了调用工具，能搜网页、查数据库、跑代码、操作软件。再往前一步，智能体开始自己拆目标、定计划，在执行过程中根据外部反馈调整动作。

问题来了。当执行对象只是免费工具或公司内部系统时，开发者提前配好权限就行。但开放市场里真正好用的能力基本都要钱：实时金融数据按次收费，网页抓取消耗额度，推理和 GPU 算力按量计费，视频生成和专业数据库也都有明码标价。智能体想独立完成一个任务，就绕不开在运行过程中当"买方"这件事。

可传统 API 的商业模式压根不是为这种买方设计的。它要求你先上网站、注册账号、绑银行卡、选套餐、保管 API Key，再把密钥塞进程序环境。采购决策和实际调用被硬生生切成两个时间点——人在任务开始前就把钱花了，软件只负责消耗已经买好的额度。

智能体不一样。它可能跑到任务中间某一步，才知道自己需要什么。它没法提前判断最后会调用哪家数据源，也不该让用户为所有潜在服务挨个开户。它的采购特征是：即时、小额、多商户、高频、结果导向。对它来说，最自然的体验不是"先订阅，再调用"，而是"发现服务，拿到报价，授权付款，取回结果"。

所以 Agent Payment 不是给聊天机器人加个支付按钮那么简单。它意味着软件开始拥有受约束的支出权限，并形成属于机器自己的采购流程。人类设定目标、预算和风险边界，智能体在边界内分配资金。支付从一个结算动作，变成了智能体决策系统的一部分。

为什么这能成为一个独立赛道

从"调工具"到"做经济决策"

智能体和普通自动化脚本的区别，不只是推理能力强弱。脚本执行的是预先定好的流程，用什么资源、找哪个供应商，早就写死在代码里。智能体则根据环境选路径。

同一个研究任务，它可能先买搜索结果，根据结果决定要不要再买行业数据库，最后调用另一家模型做交叉验证。每一步采购都会改变后续决策。

这种"边执行、边采购"的模式，把经济选择塞进了软件运行时。智能体不仅要判断某个工具能不能用，还要判断值不值得买：价格超没超预算，响应速度够不够，历史履约靠不靠谱，有没有更合适的替代品。传统工具路由只看能力匹配，机器采购还得同时处理价格和交易对手风险。

而且在这类交易里，承担风险的是智能体自己——钱付出去了，服务可能没交付。

所以 Agent Payment 的核心需求不是"无条件自动付款"，而是"可控地把购买权交给软件"。用户不会轻易把整个钱包交给智能体，但愿意给一个明确任务设几美元预算，允许它做若干笔美分级采购。大授权需要长期建立信任，小授权现在就能创造实际价值。

微额、高频、多商户，把支付经济学给改了

人类互联网的支付基础设施，擅长处理低频、高额交易。信用卡网络、支付网关、订阅系统都有固定成本，所以商户习惯把很多次调用打包成月度套餐。对于每次只值几美分的 API 请求，传统支付的手续费、拒付风险和账户维护成本可能比商品本身还贵。

机器消费正好反过来。智能体为了交付一个结果，可以在几分钟内向多个商户发起多笔采购。单笔金额极低，但调用频率高，交易数量可能远超人类消费者。

稳定币和链上可编程结算给这类场景提供了新的经济基础：资金全天候流动，支付授权可以由软件签署，服务直接按调用计价。

更关键的是，多商户采购会改变 API 市场的竞争方式。订阅制鼓励用户长期绑一家供应商，按次购买则允许智能体每次任务动态选择。服务商不再只争年度合同，还要争某个瞬时需求。价格、性能、履约记录都可能实时影响路由结果。

稳定币正从交易媒介变成结算基础设施

加密市场早期的稳定币需求主要来自交易和资金避险。随着发行、托管、合规和跨链基础设施逐步成熟，稳定币开始进入跨境结算、企业资金管理和互联网原生支付。

对机器支付来说，稳定币还有个特殊优势：它既是货币，也是可以由程序直接操作的数字资产。

信用卡支付依赖持卡人身份、银行账户和地域网络。智能体本身没有自然人身份，也没法独立走完传统开户流程。而一个受策略约束的钱包可以成为智能体的资金接口——操作者注入有限余额，设好单笔和会话上限，保留冻结与撤销权限，智能体只在授权范围内签名付款。

这不意味着链上支付天然优于所有传统支付。消费者保护、退款机制、隐私、密钥管理和监管责任都还需要解决。但在机器对机器、低额按次、全球服务采购这些场景里，可编程稳定币的适配性明显更强。它让"调用接口"和"支付接口"第一次有机会压缩进同一个网络交互。

支付轨道已经有了，但只是一半

让 402 从状态码变成商业接口

HTTP 协议里早就预留了 402 Payment Required 状态码，但将近 30 年都没形成通用工作流。机器支付协议重新激活了这个语义：客户端请求一个付费端点，服务端返回 402 和机器可读的付款条件；客户端选一个能接受的方案，完成签名或支付，再带着凭证重试请求。

这个流程最重要的一点是——它取消了人类注册页。价格发现、支付要求和内容交付全部发生在程序能理解的协议层。对开发者来说，付费 API 不用再围绕账户、套餐和密钥搭一整套 SaaS 门户；对智能体来说，服务可以像普通网页一样被发现，在真正需要时购买。

x402 是这条路径上最受关注的开放协议之一，围绕 HTTP 402 组织支付挑战和凭证，让服务商按请求收款。MPP 则从另一套生态出发，探索面向机器的 charge、session 等支付方式。两者设计不同，但共同验证了一个方向：机器支付可以成为应用协议的一部分，而不是在应用之外另建人工结算流程。

碎片化不会自动消失

行业经常期待最终只剩一个标准协议、一条结算网络、一种支付方案。但从商户视角看，多元化有长期合理性。

一次性数据查询适合按次收费，持续推理或流式服务可能更适合会话计费；高价值服务需要更强的担保和争议处理，低价值调用更在意速度和成本；不同地区和企业也会选不同的合规与结算网络。

协议层还会继续创新。商户可能采用直接扣款、预授权、托管、流支付或批量结算；网络可能在成本、最终性、流动性和生态工具上各有取舍。对卖方来说是自由选择，对买方来说，每多一种组合就多一个集成面。

银行卡市场发展了这么多年，也没只剩一家卡组织；云计算也没有收敛到一个供应商。成熟市场通常不是消灭差异，而是在差异之上形成聚合、路由和清算层。Agent Payment 很可能走同样的路。

这种分裂已经可以量化。x402scan 和 mppscan 两个公开浏览器近 30 天的数据显示（截至 2026 年 9 月 3 日）：MPP 协议在 Tempo 链上有 65,591 个活跃买方钱包，x402 在 Base 链上有 19,472 个，而同时出现在两条轨道上的钱包只有 365 个——不到 MPP 买方的 0.6%，也不到 x402 Base 买方的 2%。其中在两条轨道各完成十笔以上交易的只有 112 个，而且相当一部分是双轨聚合器用同一把密钥代付，不是买方自己真的用了第二条轨道。买方没有跨轨道流动，每条轨道都在积累自己独立的买方群。

卖方接入只是交易的一半

支付协议首先降低的是商户收款门槛。一个端点能发布报价、验证凭证、返回服务，就具备了面向机器营业的基本条件。越来越多开发者工具、数据服务和内容接口由此进入机器可购买状态。

但供给能付钱，不代表需求会自动来。商户解决的是"我怎么向机器收款"，智能体还得回答"我该向谁买、用哪种方式付、付完怎么确认交付"。如果每个买方都要分别集成每种协议、准备不同网络的资金、维护独立账本，机器支付就会重演早期 API 集成的复杂性——只是把 API Key 换成了钱包和协议适配器。

真正的采用率取决于交易的总摩擦，而不只是结算那一步的摩擦。

真正的瓶颈：交易没有闭环

第一关：发现可购买的服务

智能体需要机器可读的服务目录。一个有效目录不能只有名称和网址，还要描述端点能力、输入输出、价格单位、可用协议、延迟、地域限制和更新状态。自然语言意图和 API 参数之间也需要映射，否则智能体知道自己"需要宏观数据"，却判断不了哪个端点能满足任务。

开放市场里的目录还面临重复、失效和虚假声明的问题。任何商户都可以宣称自己提供高质量数据，但智能体没法像人类采购那样花几天做背景调查。发现层必须持续验证端点是否可调用、报价是否真实、描述是否和返回内容一致。

这让服务发现不同于传统搜索。搜索引擎优化的是信息相关性，机器采购目录还要优化可交易性：能力是否匹配、价格是否可接受、支付是否兼容、商户能不能交付。

第二关：理解和比较报价

表面上同类 API 都能按次标价，实际上报价的可比性很弱。一家按请求收费，另一家按结果条数收费；一家把模型推理含在价格里，另一家要额外付；还有服务根据输入长度、运行时间或成功结果动态计费。

智能体不能只挑名义价格最低的端点。它得算总成本、交付概率、延迟和结果质量。如果一个便宜接口连续失败，重试成本和任务延误可能让实际价格更高。报价应该和服务等级、历史表现、任务上下文一起评估。

机器可读报价还需要明确有效期和最终金额。动态定价环境里，智能体签署的必须是一个确定承诺，而不是模糊的价格区间。操作者也需要知道费用构成——服务费、网络成本、路由费——才能设可信预算。

第三关：资金分布与跨轨道流动性

如果一个智能体要同时在多条链、多种协议上买服务，最直接的做法是在每个网络预置余额。但这会把少量资金切成很多碎片。钱躺在暂时不用的网络上，热门网络又可能余额不够；补充余额涉及桥接、兑换、Gas 和安全操作。

对单个用户来说已经很烦。对管理大量智能体的企业来说，问题会成倍放大：每个智能体该持多少余额，谁负责补充，怎么防止资金被错误消耗，怎么汇总不同网络上的资产和费用？缺了统一资金层，支付轨道越多，财务反而越复杂。

理想状态下，智能体看到的应该是一份可支配预算，而不是多个网络余额。底层系统负责选结算路径、管流动性、给透明报价。原则类似旅行者用一张卡在不同国家消费——用户关心的是总额度和汇率，不需要为每个目的地预先开本地账户。

第四关：基于策略的授权

自主支付最容易引发的担忧，是智能体会不会失控消费。解法不是简单地在"完全禁止"和"完全授权"之间二选一，而是建立多层策略。

单笔上限限制一次错误的损失，会话预算约束一个任务的总支出，商户白名单或黑名单控制交易对手，品类规则限制可购买内容，速率限制阻止短时间异常调用。高风险或高金额交易还可以触发人工确认。策略由操作者设定，智能体只能在边界内行动，不能自己提高限额。

钱包也不该只承担签名功能。它需要和任务、身份、审计记录结合，回答"哪个智能体为了什么任务、以什么策略批准了这笔付款"。否则企业最后拿到的只是一串链上交易哈希，满足不了内部控制和成本归因的要求。

第五关：结算成功不等于服务交付

区块链擅长证明资金从一个地址转到了另一个地址，却不能天然证明 API 返回了正确内容。一笔交易可能完成结算，但服务端超时、返回错误状态，或者交付的数据和宣传不符。对智能体来说，这不是边缘问题，而是采购风险的核心。

传统电商靠物流、评价和退款连接支付与交付；机器服务没有实体物流，交付可能只是一段瞬时 HTTP 响应。支付系统如果只记录资金轨迹，商户如果只记录自己的响应，市场就缺少一份跨商户、跨协议的统一履约视图。

需要谨慎的是，记录响应不等于证明质量。但把付款和响应关联起来，至少能区分"已付款且收到结果""已付款但服务失败""未结算"这些基本状态。这是建立机器交易信誉的第一层事实。

第六关：统一对账与责任界定

一项任务可能包含十几笔微额采购。如果每笔交易散落在不同钱包、协议和商户后台，用户很难知道最终交付物为什么花了这些钱。企业还需要把支出归属到项目、团队、客户和成本中心，并保留可审计证据。

统一账本应该同时记录采购意图、商户、报价、授权策略、结算结果、响应状态和失败原因。它不仅服务财务，也服务智能体优化。系统可以分析哪些数据源经常失败、哪些路线成本更高、某类任务的典型采购组合是什么。

当支付被嵌入推理链，成本就成为模型决策的反馈信号。没有统一对账，智能体只能优化答案，不能优化获得答案的经济过程。Agent Payment 的长期价值，很大一部分恰恰来自这种可观测性。

从支付协议到机器采购层

未来的核心抽象不是 Pay，而是 Buy

支付是明确对象和价格之后的动作，采购则覆盖从需求到验收的完整过程。给智能体暴露一个 pay() 函数，只能让它向已知地址转账；暴露一个 buy() 能力，才意味着系统可以接收需求、发现服务、比较方案、执行支付并返回可验证结果。

这个区别决定了行业分工。协议提供标准化付款消息，钱包管理签名和资产，结算网络移动价值，目录聚合供给，而采购层把这些组件组织成一次任务。任何单一组件都很重要，但都无法独立代表完整交易。

机器采购层需要保持开放。它不该要求所有商户迁移到同一协议，也不该通过封闭目录决定谁能被购买。更可持续的模式是兼容多种支付轨道，在报价中披露路由成本，允许智能体根据策略自主选择。

买方聚合可能比卖方聚合更重要

互联网平台通常先聚合供给，再吸引消费者。机器市场里，供给已经以 API 形式广泛存在，缺的是能持续购买的标准化买方。一个被装备好的智能体，可以把零散、偶发的需求转化为稳定交易流。

买方聚合还会提高长尾服务的可见性。人类开发者倾向用熟悉的大品牌，因为评估新供应商的时间成本很高；智能体如果能读取标准化能力、价格和履约信号，就能每次任务选更合适的服务。这可能降低新商户获客成本，也迫使成熟商户在真实表现上竞争。

但买方入口也会形成新的平台权力。谁控制默认目录、排序和支付路径，谁就可能影响流量分配。所以行业需要透明的排序规则、可解释的费用和可迁移的交易记录。聚合可以降低摩擦，但不应把开放协议重新包装成封闭渠道。

用真实交易数据建立信誉

机器买方决策速度很快，没法依赖漫长尽调。它需要在报价出现时同时拿到交易对手信号。传统评分和用户评价可以提供参考，却容易被刷量、女巫账户和利益关联方操纵。如果评价不要求真实支付，攻击成本尤其低。

最近对 ERC-8004——首个面向智能体的无许可链上信任层——的实证研究印证了这一点。该协议规范原文写明"Payments are orthogonal to this protocol"（支付与本协议正交），评价默认不必绑定任何真实付费交易，付款证明只是可选字段。结果是：在以太坊、BSC 与 Base 三条链上（截至 2026 年 5 月 13 日），分别有 73.5%、59.2% 与 90.6% 的评价者表现出协同女巫行为。

更可靠的基础是与真实付费调用关联的结果记录：某服务端点完成过多少笔结算，响应成功率如何，常见延迟是多少，付款后无响应的比例多高。这些指标仍不能完全代表内容质量，但比自我声明更接近可验证事实。

随着数据积累，市场可能出现分层信誉。第一层是客观交易状态，第二层是可复现的服务指标，第三层才是针对具体任务的质量评价。智能体可以根据金额和风险选择所需证据强度：几美分的数据查询依赖统计信号就行，高价值采购则需要担保、审计或争议解决。

预算策略会成为智能体的重要能力

今天评估智能体，主要看回答质量、任务完成率和工具调用准确性。进入付费环境后，还要增加经济指标：为达到同等质量花了多少，是否在预算内完成，什么时候值得买更贵的数据，如何在速度、成本和可靠性之间权衡。

这会产生新的训练和评测方向。智能体不仅学"哪个工具能回答问题"，还要学"在当前任务价值下，买这个工具划不划算"。它可能先用低成本服务筛选，再对关键结论购买高质量验证；也可能在预算快耗尽时降低调用频率，或向用户申请额外授权。

从这个意义上说，Agent Payment 不是模型能力之外的财务插件，而是决策智能的一部分。真正成熟的智能体，应该既会用资源，也会为资源定价。

演进路径大概会怎么走

第一阶段：开发者工具和数字服务先行

最早规模化的场景大概率还是纯数字交付——搜索、数据、代理抓取、模型推理、代码执行、存储和内容生成。这些服务本身通过 API 提供，边际交付成本低，付款和响应可以在同一网络会话中完成，也不涉及复杂物流。

这一阶段典型金额很小，用户关注的是开发便利和任务完成率。市场会快速验证协议，但交易量可能高度分散。很多调用仍会由传统 API Key 和订阅承担，机器支付更多用于临时需求、跨商户采购和无法预先开户的长尾服务。

第二阶段：企业预算与多智能体协作

当企业开始部署多个智能体，资金管理会从个人钱包升级为组织级账户体系。企业需要给不同角色分配预算，控制可购买品类，设置审批阈值，把支出写进财务系统。智能体之间也可能形成内部结算：研究智能体采购数据，分析智能体购买算力，执行智能体调用外部服务。

这时候，安全与合规的重要性会超过支付新颖性。企业关心密钥托管、权限隔离、交易监控、供应商审查和审计留痕。能兼容现有财务流程的基础设施，才可能从试验进入生产。

第三阶段：从数字服务延伸到现实经济

机票、酒店、物流、广告和专业服务都可能成为智能体采购对象，但现实世界交易需要更复杂的身份、退款、税务和争议处理。稳定币只能解决一部分结算问题，替代不了消费者权益和商业合同。

所以行业不该把"自主支付"误解为取消所有中介。相反，随着交易价值提高，担保、保险、信用和仲裁会重新出现，只是它们需要转化为机器可调用的服务。未来的 Agent Payment 栈可能同时包含开放支付协议和传统金融连接，而不是单一路线取代另一条。

第四阶段：从跨协议路由走向跨市场执行

长期看，智能体购买的不只是一个 API 响应，而是一个结果。用户可能提出"生成一份可信的行业报告"，系统自行组合搜索、数据库、翻译、模型和校验服务。底层发生多笔交易，用户只看到总预算、证据来源和最终交付。

这会让支付路由升级为市场执行。系统需要把复杂目标拆成采购组合，动态更换失败供应商，在总成本与质量之间优化。协议兼容只是基础，真正的壁垒来自需求理解、交易数据和执行反馈。

风险与还没解决的问题

Agent Payment 想象空间很大，但现实约束不能忽视。

安全是第一位。提示词注入可能诱导智能体购买恶意服务，供应链攻击可能替换收款地址，错误策略也可能造成大量重复付款。支付动作必须与不可信内容隔离，并具备限额、模拟、撤销和异常检测。

隐私是第二位。采购记录会暴露智能体正在执行什么任务，链上公开数据还可能连接用户身份与商业意图。系统需要尽量减少敏感元数据泄露，在审计需求与隐私之间取得平衡。

责任是第三位。当智能体错误购买、商户未交付或协议转换失败时，损失该由谁承担？低额交易可以接受自动化风险，高额交易则需要明确责任边界。没有争议机制的支付网络，很难直接进入高价值商业。

监管是第四位。稳定币发行、钱包控制、跨境转移和商户收款受不同司法辖区规则影响。机器是执行者，不是法律责任主体。基础设施必须能把每笔自主交易追溯到明确的操作者、授权政策和资金来源。

商业可持续性是第五位。微额支付收入很容易被网络成本、流动性和风控费用吞噬。平台若通过隐藏加价补贴体验，又会损害买方信任。费用必须透明，并通过规模、路由效率和附加服务建立合理商业模式。

这些问题不否定赛道，而是说明 Agent Payment 不会只靠一个协议完成。它最终会成为支付、身份、权限、发现、信誉与对账的复合基础设施。

买方层长什么样：以 SELAT 为例

"SELAT"取自马来语中的"海峡"，比如马六甲海峡（Selat Melaka）。数百年来，不管货物来自哪个港口、驶向哪片市场，东西方贸易的主流都从这条水道通过。SELAT 想成为机器原生商业中的那条海峡：无论商户在哪条轨道靠岸，智能体的需求都能从这里流过。

SELAT 是一家 AI 原生公司，选择从买方侧切入机器支付。它的核心目标不是再创造一条要求商户迁移的新支付轨道，而是让智能体能够跨现有轨道完成采购。它聚焦两个核心问题：一是支付配置的碎片化——轨道、协议、链与凭证各不相同，每个商户都要做一次新集成；二是交易对手风险缺乏度量——结算成功并不说明服务已经交付。

针对碎片化问题，SELAT CLI 把协议、支付方案和结算网络的差异留在基础设施层，让智能体用一条命令完成跨轨道采购。发现、报价、授权、支付、交付状态记录和对账，都被纳入同一个采购流程，每一笔调用也记录在同一账本中。

  • 一个资金库，使用 N 条支付轨道：智能体持有一份自托管的 USDC 余额，无需按链预置资金，也无需为不同协议维护不同客户端。

  • 聚合式端点目录：SELAT CLI 整合 Circle、MPP、Apify、pay.sh 四个第三方服务注册表及 SELAT 自有目录，让智能体根据实时意图发现和比较 4,000 多个服务端点。

  • 硬支出上限：操作者可以设置单笔上限和会话预算，随时冻结支出权限；智能体无法自行提高限额。

  • 商户零迁移：商户可以保留自己选择的支付轨道，无需向 SELAT 重新注册，即可被智能体发现和购买。


资金侧，SELAT 可与任意智能体钱包组合使用，包括 Circle 和 MetaMask 的智能体钱包。SELAT 在 x402 与 MPP 等支付轨道之间路由每笔采购，并以实时报价为准。

ERC-8004：原语正确，信号存疑

ERC-8004 定义了身份、信誉和验证三类注册表，允许买方向卖方提交评价。方向是对的，但它把支付与信誉明确分开：反馈不必来自真实交易，附带支付证明也是可选项。

对已部署生态的实证研究显示，在 Base 上，93.8% 的评价者从未进行过 x402 支付，却贡献了 94.9% 的反馈；大量反馈还呈现出协同女巫行为。注册表记录的是声明，而买方真正需要的是结果。

关联真实交易数据的信誉才是买方所需

支付轨道能确认资金是否结算，却看不到服务返回了什么；商户看得见自己的响应，却看不见整个市场；注册表可以列出端点，却无法证明评价来自真实采购。

执行采购的买方层最有机会连接交易的两端：每一笔经 SELAT 完成的采购，都会记录支付了哪个端点、结算了多少，以及付款后的交付状态元数据（2xx、4xx、5xx）。这些记录按商户和支付轨道持续累积，构成了"结算—交付图谱"（Settlement–Delivery Graph）的数据基础。

需要准确区分：关联了支付与交付状态的记录，并不等同于对交付质量或报价准确性的独立证明。但它提供了登记式信誉所缺少的基础——与真实付费调用相关联的结果数据。

在交易前拿到交易对手的信誉

SELAT 已经在结算—交付图谱之上，上线了"可交易性指数"（Transactability Index），目标是让智能体在运行时获得由真实交易结果支撑的交易对手信誉数据。

指数随报价一同返回，不要求智能体暂停任务、另行调查商户。它标注风险而不替市场设卡：端点仍可被发现和购买，智能体根据预算、任务重要性和风险偏好做决定。

智能体没有时间读品牌故事。它需要在付款之前知道：这个端点在真实交易中表现如何。机器原生商业的信誉，不该来自声明，而应来自结果。

目前，SELAT CLI 已适配 Claude Code、Codex、Cursor、Gemini CLI、OpenClaw、Hermes 与 Grok Bot 等智能体运行环境。

机器经济要的不只是更快的支付轨道

Agent Payment 正处在一个容易被高估、也容易被低估的阶段。

容易被高估，是因为技术上完成一次稳定币付款，并不代表智能体已经具备成熟的商业自治能力。容易被低估，是因为一旦软件可以在明确约束下购买外部能力，机器经济的组织方式、定价方式和竞争边界都会发生变化。

支付协议已经证明机器可以收到报价并完成结算。接下来的关键，是把一次孤立付款扩展为完整采购：让智能体找到合适服务，理解真实成本，在预算内跨轨道支付，确认交付，并把每一次交易转化为可审计、可学习的记录。

未来的机器经济不会只有一条链、一个协议或一个钱包。多元供给会长期存在，真正有价值的基础设施将帮助买方穿越这种复杂性。Agent Payment 需要把轨道、供给、默认支付和信任机制组合起来，才能让技术容量转化为真实需求。

当软件开始成为买方，支付只是它迈出的第一步。更重要的问题始终是：它能否以可控、透明和可验证的方式，完成一笔真正有用的交易。