第 245 期

Anthropic为何考虑自主研发计费系统

Anthropic一边使用外部支付服务,一边自主探讨计费功能。本文探讨其将在多大程度上掌控价格策略与用量计量。

商业Anthropic为何考虑自主研发计费系统

一边使用Stripe,一边自主探讨计费系统的Anthropic

在Stripe的客户案例中,介绍了Anthropic如何在支付、账单及财务报告中使用其产品的全过程。据介绍,初期为了专注于产品研发而利用了外部基础设施,随着交易量的增加,还将销售数据发送至BigQuery的方式进行了优化。Stripe客户案例

Stripe的Anthropic客户案例

与此同时,Anthropic的计费平台(Billing Platform)招聘公告中明确列出了一项职责:判断哪些部分托付给外部服务、哪些部分自主研发。也就是说,即使使用支付服务商,依然向自研计费系统投入开发人员。

我在上一期中谈到了Stripe就收购OpenRouter达成一致的消息。Stripe正在将业务拓展至管理AI模型用量与成本的领域,而其重要客户Anthropic也试图亲自掌控其中的一部分。这两大动向在何处产生交集,颇值得探究。

计费系统的范畴远比刷卡支付广泛

Anthropic的资深主任工程师(Staff Engineer)招聘公告将价格配置、支付流程、合约与使用权限、营收数据等列为工作职责。公告写道,目前大量使用外部计费、支付及税务平台,正在评估是继续扩展外部平台还是构建自研功能。计费平台招聘公告

公告中还包含了支付授权通过率、重试机制、处理成本、争议处理与反欺诈等内容。我们既不能断定他们只研发账单计算、而将刷卡支付处理排除在考量之外;但这也不是要完全取代外部服务商的公开声明。其核心内容是招募相关人才,以评估究竟托付到何种程度,又在哪些环节实施自主掌控。

解析支付与计费功能关系的图解

从银行卡中收款与计算客户应付金额这两件事虽然紧密相连,却截然不同。例如,要生成AI API的账单,就必须确定以下事项:哪些调用属于计费范畴、输入与输出的单价如何适用、折扣与预付额度(Credit)按照怎样的顺序扣减等。

统计用量的功能被称为计量(Metering)。而根据价格方案和合同条款将计量转化为金额并出具账单的功能则是计费(Billing)。哪怕是相同的调用,根据是否使用缓存、批处理(Batch)方式以及针对特定客户的折扣条款,最终生成的账单金额都可能存在差异。

向什么内容收取多少费用,必须由服务企业自行决定。这并不意味着所有计算都必须完全由自己开发实现。如果外部产品能够支持所需条件,自然可以加以利用。但关键在于,当企业希望调整价格体系时,必须清楚知道自己能够自主改动哪些部分。

反欺诈也需要将支付与用量结合考量

Anthropic 的金融反欺诈工程师招聘公告涉及支付授权时的风险评估,以及退款与争议处理、试用及促销滥用检测。这项工作需要与支付服务商合作,利用设备信息、短时间内反复交易、账户间关联等多种信号。金融反欺诈工程师招聘公告

在 AI 服务中,即使尚未收到付款,也可能产生算力成本。例如,若有人为了获取免费额度而反复注册账号并大量调用 API,服务商就必须承担相应的使用成本。这是潜在的滥用场景,并非该公告披露的实际损失规模。

要排查这类问题,就需要将银行卡支付信息与服务使用信息关联起来。这并不意味着盗刷卡检测变得不再重要,也不意味着免费权益滥用仅存在于 AI 领域,而是要根据成本与损失发生的环节,补充所需的监测信号。

第三方支付公司同样提供欺诈检测功能。Stripe 的客户案例显示,Anthropic 结合运用了 Radar 的风险评分与自定义规则,从而减少了对正常交易的误判拦截。这可以视为自营功能与外部工具结合使用的典型案例。

支付失败也需要分类处理。临时错误、卡片信息问题与真正的涉嫌欺诈,应对方式截然不同。拥有多条支付路由有时确实会有所帮助,但就算只有一家支付服务商,也并非完全无法重试。更何况,盲目换用其他路由反复请求并不见得能提高授权成功率。明确重试条件与防止重复扣款的机制必须协同配合。

还需要确认是否能够更换支付服务商

Adyen 在 2026 年 8 月的上半年业绩发布会上,将 OpenAI 列为新拓展的重要企业客户之一。不过,单凭这一公告,还无法获知 OpenAI 究竟用它替代了原有支付服务商的哪些功能。Adyen 上半年公告

企业若想增加或更换支付服务商,就必须审视如何迁移持卡人信息与现有的订阅合约。这正是存储位置至关重要的原因。借助独立的存储服务固然有助于接入多家支付机构,但仅凭这一点,并不能保证随时都能轻松完成切换。

反过来,卡信息保存在支付服务商那里,也未必就一定要让客户重新绑定。Stripe 提供了向符合特定安全资质的新支付机构迁移卡信息的正规流程。不过,存储在 Link 中的支付凭证不包含在导出范围之内。而且卡信息与支付记录、订阅数据的迁移方式也各有不同。Stripe 数据迁移指引

如果是我,在商讨费率之前,一定会先摸清可以迁移哪些数据、支持哪些支付方式,以及迁移需要投入多少时间和开发工作。唯有真正能够转移到替代方案,在谈判桌上才算拥有切实的底牌。

Stripe拓展的业务与客户的自研领域产生了重叠

Stripe于2026年1月14日完成了对按用量计费服务商Metronome的收购。在此之前的8月19日,Stripe还宣布了收购OpenRouter的协议,后者可以在多个AI模型之间分发请求并管理使用成本。完成收购与达成收购协议属于不同的阶段。完成收购Metronome达成收购OpenRouter的协议

Stripe关注的重点,已经不仅局限于向客户收取款项的那一瞬间,而是进一步延伸到了此前发生的AI用量与成本。这与Anthropic正在招聘的计费、定价及营收系统业务产生了部分重叠。

在这一领域,很难简单地一刀切,断定哪项功能必须采购、哪项功能必须自研。即便同样是计量(metering)功能,选择也会因客户规模、合约复杂度、研发人力以及外部产品的支持范围而有所不同。

功能考量外部服务时的关注点考量自主研发时的关注点
支付处理支持的国家与地区、支付方式、费率、扣款成功率对接并运营多支付渠道的能力
用量统计吞吐量、准确性、延迟、原始数据访问权限仅本公司适用的特殊统计规则
资费与合约管理折扣、预付、按量付费等条件的支持范围定价实验与针对不同客户的例外规则频次
使用权限合约变更与实际服务权限的联动实时额度限制与服务中断条件
反欺诈来自外部支付网络的信息产品使用记录与各账户之间的关联

即便客户选择自主研发部分功能,依然可以继续使用外部的支付与计费服务。招聘公告与现有客户案例并存这一事实本身并不矛盾,它所展现的,是交给外部服务的边界可能会发生变化。

这绝不仅仅是省下手续费那么简单

区分计费系统功能的示意图

随着营收与交易规模的扩大,哪怕极小的费率差异也可能演变成巨额成本。因此,审视外部服务成本是一件很自然的事。然而,将年化营收乘以某个随意设定的费率算出的金额,并不是实际支付的成本。支付方式、合同专属折扣、所使用的产品不同,最终的费用都会有所差异。

自研系统则需要付出另一种代价。招聘与维持工程师团队、对接税务与会计系统、修复故障以及应对客户问询都需要投入资源。此外,还必须考虑到计费出错时的退款成本以及随之而来的信任损失。

计费系统绝非准确搭建一次便可一劳永逸。它必须能够区分费率变更前后的标准、维持历史合同条款、防止重复汇总,并能在客户提出质询时提供确凿凭据。Anthropic招聘公告之所以强调一致性验证、审计记录与运营责任,原因也正是与这些具体业务紧密相连。

单凭筹备上市或节省手续费,很难完全解释探索自研的原因。从公告中体现出的诉求来看,它横跨了产品发布速度、合同处理能力、支付成效以及营收数据的准确性等多个维度。

Oswarld视角

看到这条新闻,我重新思考了软件公司在决定“外部采购什么”与“自主研发什么”时的判断标准。我尤其认为,决定向客户收取多少费用的规则本身就是产品的一部分

每月收取固定费用的方案,与用量、折扣、额度因客户而异的方案,所需的计算方式截然不同。即使将计费配置委托给外部产品,公司也必须能够解释清楚该配置会给我们的客户带来怎样的结果。

随着用量激增和合同复杂度上升,哪怕仅有一个条件不受支持,也可能阻碍定价实验的推进。我认为自主研发的理由正是由此而生。不仅要考虑使用外部产品的成本,还必须权衡无法及时推出理想计费方案所带来的隐性代价。

在韩国本土的 SaaS 与 AI 服务中,也能看到将支付托付给 PG(支付网关)、在自有数据库中统计用量的架构。这种设计本身并无不足。关键在于统计是否准确,以及即使计费规则发生变化,能否依然复现计费依据。

当智能体自动重复执行任务时,单个用户的消耗量可能会在短时间内激增。因此,不仅要明确计量的具体指标,还必须与定价政策一并确定何时应用限额以及在何种条件下暂停服务。

当客户对账单金额提出异议时,仅罗列调用记录往往不足以给出充分的解释。公司需要能够展示在某项操作中应用了哪条计费规则,以及折扣和抵扣额是如何计算出来的。无论这些依据是由自有代码生成还是从外部系统获取,公司都必须能够自行核对并向客户解释清楚。

如果 读者 您正在运营按量计费或抵扣额度方案,不妨确认一下是否能够基于最初的使用记录,将任意一位客户的账单重新推导计算一遍。在这个过程中,哪些环节可以委托外部、哪些环节必须由内部直接掌控,界限会变得更加清晰。

💬 您当前服务的用量与账单金额是在哪里计算的?在尝试调整定价方案时,是否也曾遇到过系统层面的限制?欢迎留言分享。