Galaxy：无接触式SaaS 人工智能时代的API支付

作者：Vikram Singh，来源：Galaxy，编译：Shaw 金色财经

概述

• 如今的软件支付体系，是为静态的、人工驱动的合作关系而构建的。对于从未编写过一行代码的新型开发者而言，API/MCP 的配置与管理十分繁琐。优质数据源正因大语言模型无法与付费墙进行动态交互，而不断流失客户。

• 在无接触 SaaS 模式下，AI 智能体（AI Agent）可自主发现、调用并为 API 与数据源付费，无需创建账号、无需配置 API 密钥、也无需建立双边计费合作关系。

• “AI 预算” 能够让大语言模型在运行时高效获取付费墙内的数据，从而赋能研究工作。x402 / 机器支付协议工作流可大幅消除 API 集成阻力，实现软件动态定价，并解决非企业级开发者的冷启动难题。

• 无接触 SaaS 的经济逻辑对订阅制定价模式形成挑战，同时强力推动行业向按量计费模式转型。若无接触 SaaS 成为主流，业内或将重新思考客户获取成本（CAC）、每用户平均收入（ARPU）等 SaaS 核心指标。

迄今为止的SaaS发展历程

过去几周，从智能体支付视角来看行业动态十分值得关注：Tempo 上线主网，机器支付协议（MPP）表现尤为突出；Ramp 上周推出了智能体卡片；Visa 发布了命令行工具，并积极推进智能支付业务；Coinbase 在近几个月也一直主导 x402 协议的发展。

但目前行业焦点大多集中在大语言模型（LLM）聊天界面内的商业购物场景，针对软件与数据支付的讨论却十分有限。我认为 AI 将从根本上改变我们未来对软件支付与 SaaS 模式的认知，本文也将围绕这一观点展开探讨。

首份软件许可协议签订于 1969 年，当时 IBM 决定将庞大昂贵的硬件与软件服务拆分销售。多年过去，如今软件金融领域由 SaaS 模式主导，而 SaaS 又可分为高介入型（如 Salesforce、思爱普 SAP）与低介入型（如 X、Stripe）两类。

高介入型 SaaS 客单价高，单个增量用户的获客成本高，且客户支持成本高昂；低介入型 SaaS 客单价较低，单个增量用户获客成本更低，但为获取海量用户，整体获客投入依然很高。

随着 AI 势不可挡的发展，软件支付体系正迎来一个拐点，或将催生我所定义的无接触 SaaS 模式。

逐渐消失的编程壁垒与无接触SaaS的诞生

编程工具已经并将持续降低门槛，覆盖更多编程经验有限的 “开发者” 群体。我们完全可以预见，短短几年内，编程经验将不再是软件开发的壁垒 —— 事实上，这一趋势已然显现。

现阶段，开发个人或非企业级软件的琐碎阻碍（除少量运维知识外）主要集中在：

1. 找到合适的数据源、工具与 API

2. 配置 API 密钥并完成服务付费

3. 将其集成至自身应用中

第三点已被 Claude Code、Codex 等工具抽象简化，而前两点仍有极大的创新优化空间（从某种程度而言，机器支付协议已带来相关改变）。

如今配置 API 密钥的流程繁琐低效：①查找对应 API → ②创建账号 → ③通过邮箱验证码完成身份验证 → ④添加支付方式 → ⑤生成 API 密钥 → ⑥存储密钥 → ⑦配置调用速率限制 → ⑧设置计费提醒 → ⑨编写代码。这一流程无法跳过，且每新增一个 API、工具或数据源都需重复操作。建立机器支付协议连接的流程也大同小异。

对于 Stripe、X 这类高价值集成场景而言，API 筛选的认知成本与配置流程的阻力可通过数十万次 API 调用分摊，因此这类繁琐流程尚可接受；但对于低频使用场景，这套流程则显得过于冗余。

来源：Galaxy Ventures

抛开拟物化设计的思维定式，我们来思考一下上下文数据源的发现与调用应该是什么样子。 假设我问我的大语言模型：“今天纽约发生了什么？” 它应该能找到《纽约时报》的 API，访问相关的 API 端点，并为我获取相关的新闻文章。这样一次一次性的 API 调用，不应该因为一个微不足道的请求，就需要我去创建一个机器支付协议（MCP）连接。

同样，如果我提出一个更宽泛的查询：“为 {ABC} 股票撰写一份投资分析报告。查阅 SEC 文件（使用 Financial Datasets API）、最新新闻（使用 Parallel Web Systems API）和社交情绪（Twitter/X API）。” 这将涉及 3 个 MCP 连接，因此为了一个查询就要建立 3 个双边计费关系。这种用户体验（UX）非常糟糕，可以通过聚合与中心化来改善。

除了上下文数据源和我们的高层级大语言模型工作流，我们再来思考一下非企业级开发者的体验将如何演变。 假设你开发了一个提供上述股票分析工作流的 Web 应用，并想将其推向 2500 名客户的用户群 —— 这算不上企业级规模，但也绝对不小。为了让应用在生产环境中稳定运行而不崩溃，你可能需要同时将 Financial Datasets、Parallel、Twitter/X 的服务升级到更高收费套餐，而你的服务器成本（Vercel、Supabase、Railway 等）也会随之飙升。

如此一来，为提供该服务，你已经累积（并锁定）了高额成本。在这个节点上，你有以下选择：

• 自掏腰包预付高额成本，但对收入来源的前景却不甚明朗；

• 寻求风险投资，但你的这个半正式的业余项目很可能吸引不到风投资金；

• 让你的客户根据实时使用情况付费。

实时支付的成本计算方式可以是：

用户捆绑成本 = 累计 API 成本（Financial Datasets、Parallel、Twitter/X） + 累计服务器成本（Vercel、Supabase、Railway） + 增值 / 平台服务费

实时支付理论上可以解决需要预付费用的冷启动问题，并支持动态定价模式（根据供需关系调整收费，并基于实时使用情况优化收费套餐和服务器空间）。

内容、数据与聚合

来看两个案例：

案例一

“深入研究美国的 GPU 与数据中心市场。最重要的参与者有哪些？芯片制造商的进出口量是多少？新的数据中心正在哪里建设？”

这种搜索的深度在结构上是受限的，结果往往平庸。它最多只能访问 SemiAnalysis 的免费版本和其他免费数据源，而真正高质量的数据都隐藏在付费墙之后。

案例二

与案例一使用相同的提示词 + “这项研究对我很重要，你有 10 美元的预算，请使用最好的数据源。”

来源：Galaxy Ventures

案例二可以接入并调取 Aterio、Cleanview 等优质数据源，这类检索在结构上更为优质。在数据源支持按量付费 API 端点的前提下，大语言模型可以自主检索这些数据源、使用预算完成支付，并利用高价值信息完善深度研究。

若要让案例一达到案例二的同等效果，人类用户必须自行寻找数据源、配置密钥，并与各家 API/MCP 服务商建立计费关系。而在案例二中，大语言模型会动态检索并付费调用最优数据源，省去了人类寻找、决策和重复配置的成本。

稍作题外话，但这一点十分重要：从上述例子中可以发现，数据与上下文数据源的发现流程出现了根本性错位。寻找合适 API 的探索成本、判断该 API 是否值得付费的决策成本，从终端用户身上剥离，转移到了大语言模型的检索引擎与预算约束中。从这个角度看，大语言模型正成为内容与数据的核心聚合层。

为何AI预算至今尚未普及？

实现 AI 预算需要在大语言模型运行时调用 API，而运行时 API 调用要求支付具备原子性。例如，你为某项任务支付 5 美元调用 XYZ API：如何保证 XYZ 会真正提供服务，而不是直接卷走款项？如果支付与数据获取能够原子化完成，我们就能拥有一套无需信任的系统。要规模化实现这一点，就需要微支付。然而，现有金融基础设施在结构上无法支撑微支付。信用卡每笔交易约收取 2.9% + 0.3 美元的手续费。假设一次调用成本为 0.01 美元，仅固定手续费就达到 API 成本的 30 倍。按上述费率计算，手续费低于成本 10% 的最低可行交易金额为 4.29 美元。不过，信用卡可以作为微支付的抽象层（后文会详细说明）。

因此，按次 API 付费本就不适合在现有支付通道上运行，行业只能通过批量计费解决 API 支付问题：预存额度、月度账单、订阅套餐。你不会在 Claude Code 调用中看到 10 万条单笔 0.001 美元的明细，Anthropic 只会从你的预存账户中扣除 100 美元。同理，亚马逊不会对每次 AWS Lambda 调用单独计费，而是每月出具一张总额账单。这套模式行之有效，既然没坏，为何要改？

首先，在上述两种场景中，检索流程由你自己完成，费用规划是你（或公司）的决策负担，调用方式的架构设计也由你决定。每新增一个 API，就需要建立一段新的静态双边合作关系。每个计费周期，都是为预期使用的服务预付资金。

在动态检索的世界里，建立静态合作关系是一大瓶颈。当你甚至不知道会使用哪个 API 时，预付资金便毫无意义。这就需要一套新的基础设施：既能在不打破信任前提的情况下建立合作关系，又能摆脱陈旧定价体系的约束实现支付。一个自然而然的解决方案是：基于区块链的微支付。

但微支付在历史上从未成功过？

Digicash、Flooz、Beenz、Blendle 等都是微支付领域的失败案例。但正如尼克・萨博在《微支付的心理记账壁垒》一文中所言，微支付从一开始就注定失败 —— 人类的决策与记账成本，通常总会高于实际交易成本。

简单来说，人类更看重可预测性，而非精准性。每月 15 美元的 Spotify 订阅，即便只用了一半，在心理上也优于按量计费、最终可能仅需 7.5 美元的模式。前者的心理交易成本更低，后者则需要多次思考决策。这就是订阅制胜出的原因：它将一系列平均价值固定的小额决策，转化为一次可预测的大额决策（服务商也能借此收取高于实际使用价值的费用）。这也是 SaaS 定价中普遍存在 “损耗” 的原因 —— 用户付费往往高于实际使用量。

但当经济主体从人类转向大语言模型 / AI 智能体时，这套逻辑便不再成立。AI 智能体不会产生决策疲劳，它们的 “心理记账成本” 并非以认知精力衡量，而是以推理算力计算。智能体唯一的约束是人类分配的预算，可简化为一个简单的成本最小化函数。

实现无接触式SaaS

低介入 SaaS 通过砍掉销售团队降低了获客成本。而无接触 SaaS 则让工具与数据源可被直接检索并完成原子化支付，彻底省去获客流程。

这需要三项基础设施变革：

• 机器可读的价格发现：这相当于形成一个 API 市场。可以理解为在已具备能力描述功能的 MCP 之上，增加一层包含标准化定价信息的请求头或元数据。skills.sh 排行榜与插件市场已出现这类雏形。

• 支付与 API 抽象：目前 “一键调取付费数据” 更多停留在理论阶段，因为绝大多数服务仍要求创建 API 密钥。MCP 在一定程度上实现了抽象，Coinbase 的 x402 协议与 Tempo 的机器支付协议（MPP）在这一领域极具价值。

• 即时结算：出于结构需求，结算必须快速且低成本。众所周知，资金流转速度远慢于软件。通常这不算瓶颈，但在该场景下，超快支付至关重要。若支付完成速度慢于数据返回速度，服务方就要承担智能体带来的信用风险，进而需要中介介入。原子性要求为数据获取延迟设定了下限，而这一下限由底层支付通道的执行速度决定。

无接触SaaS的经济模型探讨

正如 Stripe 的 Patrick McKenzie （@patio11）所言，SaaS 最基础的收入公式为：

收入 = Σ（获客 × 转化率 × 单用户平均收入）/ 流失率

高介入 SaaS 通过六位数的单客交易额最大化单用户平均收入。低介入 SaaS 则通过产品驱动增长、免费增值模式与低门槛入驻，最大化获客与转化效率。

在无接触模式下，获客成本理论上趋近于零 —— 除非出现贿赂智能体或付费提升 API 排名的手段 —— 因为智能体会自动检索资源。转化率也几乎是 100%，因为检索与支付原子化同步完成。但单用户平均收入会大幅下降：收益不再是每月 15 美元的订阅费，而是单笔 0.0X 美元的调用费，且调用量波动极大。

这种模式下，只有交易量实现规模化增长，单位经济模型才能成立。单笔调用收益 0.003 美元的服务，需要每月 5000 次调用才能与 15 美元订阅费的收入持平。

这一领域仍有大量问题值得研究，我会留到后续文章展开。

最后，提出一些宏观思考与开放性问题：

1. 凭借即时入驻与更高可检索性，服务商可以同时服务数百万智能体，而非数千人类订阅者。因此，即便单用户收入下降，“用户” 数量可能呈指数级增长。

2. 无接触 SaaS 需要参与者接受低毛利、高交易量的模式。当下，大语言模型动态检索的吸引力，是否足以让企业从订阅制转向按量付费？

3. 若实现大规模实时按量付费，底层支付通道的成本必须极低，才不会侵蚀本就微薄的利润。

4. 各层级如何分配价值？大语言模型聚合层（Anthropic/OpenAI）能否将 API 纳入目录并收取平台费？金融层 / 区块链的利润空间如何（结构上无法收取高额费用）？

5. 授权与实名认证流程如何设计？如何区分真实的大语言模型 API 调用与女巫攻击？

6. 信用卡在其中扮演何种角色（MPP 支持信用卡作为支付方式）？基于会话的支付实际如何运行？谁承担信用风险？虚拟卡是一个值得关注的方向。

全新支付范式

无接触 SaaS 揭示了一种全新的软件支付范式：检索层从人类转向智能体，服务选择的决策成本从人类情感转向量化的成本收益权衡。由于数据获取与支付需要原子化同步，实时支付成为必然要求。

在下篇文章中，我将深入探讨这些趋势如何重塑 API 捆绑模式、各层级利润如何分配，以及完全原生的智能体经济在现实中究竟会呈现何种形态。