为什么 API 应该只对成功收费——HTTP 200 计费的理由
大多数 API 对每一次可计费调用都收费。AI Agent 会不断对不稳定的上游服务发起重试——这意味着传统的「一律收费」模型实际上是在对「韧性」征税。本文阐述只对 HTTP 200 计费的理由，以及它如何改变你设计 Agent 的方式。
一句话总结
- •AI Agent 在面对瞬时故障（5xx、超时、限流）时会合理地重试。在「一律收费」的计费下，每一次重试都是一笔真实费用——把一个 99.5% 可用率的上游，在那糟糕的 0.5% 期间变成 5 倍的成本惩罚。
- •「只对 HTTP 200 收费」让服务方的激励与客户的利益对齐：服务方去修不稳定，客户不为此买单。
- •它还解锁了一批设计模式——激进的重试预算、乐观预取、冗余调用——这些在「一律收费」下成本高得无法接受。
- •大多数服务方不这么做，是因为他们的老旧基础设施把计量绑在了上游调用上、而非绑在响应上。这本是计费系统的局限，却被包装成了策略。
我们想鼓励的那种行为
AI Agent 是一种全新的 API 客户端。它们不是 2015 年那种谨慎的企业集成——后者捕获一个错误就给值班工程师发封邮件。它们是这样的循环：一旦出错，就睡一会儿再试——有时五次或十次——而且根本不把结果呈给人看。这种循环的全部意义就在于：瞬时故障对最终用户应当是不可见的。
这是个很棒的模式。它能造出有韧性的产品，把公共互联网那一团糟的现实对用户藏了起来。麻烦在于，API 的计费模型是在一个「重试既罕见又昂贵、默认就该被劝退」的年代定下的。它至今仍那样运作。每一次重试都是一笔可计费调用，无论它是否返回了任何东西。
具体来说：一个调用 99.5% 可用率 API、在瞬时故障时最多重试五次的 Agent，会在那糟糕的 0.5% 期间产生最多 5 倍的调用——以及 5 倍的账单。Agent 做的是对的事。买单的却是客户，为上游的不稳定买单。
更简单的替代方案
只对 HTTP 200 收费。具体说，只对一个带有文档化响应形态的成功响应收费。其余一切——调用方错误的 4xx、我们错误的 5xx、超时、限流、部分但格式错误的响应——一律免费。
这听起来像个小改动。其实不是。它改变了双方在经济上的理性选择：
- 服务方现在有了修复不稳定的直接财务动机。每一个抽风的 503 都是一笔流失的销售，而不是一顿免费午餐。我们发现，采用「只对成功收费」是把可靠性工作拉到路线图最顶端的最大单一推力——当你正在白白放弃那些调用的收入时，没有哪种表格戏法能把宕机粉饰成无所谓。
- 客户可以把重试预算定得很激进。当瞬时故障的最坏情况是一次付费调用（最终那次成功）而不是六次（每次尝试各付一次）时，一个 5 次重试、指数退避的循环简直是顺理成章。
- 市场可以按「每次成功调用多少钱」而非「每次尝试多少钱」来比较 API。这才是正确的计量单位。如果两家 API 都标榜「每次调用 $0.001」，但一家可用率 99.9%、另一家 95%，那么在「一律收费」下用户可见成本相差 5 倍，而在「只对成功收费」下恰好相差 0%。买家该选哪家一目了然——而「只对成功收费」让这一点变得可见。
它如何改变你构建 Agent 的方式
1. 重试预算变成免费的
在「一律收费」计费下，瞬时故障处理器的合理重试预算大致是 1–2 次——超过这个数，反复失败的成本就开始变得要紧。而在「只对成功收费」下，预算就是「用户能等多久就重试多久」。我们经常看到带 5 次重试、指数退避、加抖动（jitter）模式的 Agent 循环——这在传统计费下会是鲁莽之举。
2. 乐观预取变得便宜
有一种在「一律收费」下成本高到无法接受的模式：趁用户还在打字时，就投机性地发起一次搜索调用，赌预测的查询是对的。如果预测错了，就把结果扔掉。在「只对成功收费」下这很便宜，因为被取消 / 未使用的调用返回成功、但你丢弃响应——于是你为可预测性和低延迟支付一笔小小的溢价。而在「一律收费」下，每一次预测错误都是一笔付费调用，这让这套启发式贵到不值得上线。
3. 冗余调用成为一种可靠性手段
有时最便宜的可靠性策略是：向两个不同的 API 同时发两个请求，谁先返回就用谁，把慢的那个丢掉。在「一律收费」下这会让你的账单翻倍。在「只对成功收费」下，被丢弃的那次调用是免费的（你没用它的响应，就没为它付钱）。一下子，那些原本只是昂贵抽象的对冲（hedging）策略，就变得切实可行了。
「成功」必须意味着什么
这个模型只有在「成功」毫不含糊时才成立。我们对它的定义很紧：
- 带文档化响应 schema 的 HTTP 200——计费。
- HTTP 200 但响应体里包着一个错误——不计费（这正是会击穿整个模型的那个漏洞）。
- HTTP 4xx——不计费。这包括 401（鉴权）、402（credit 不足）、422（校验），以及某些情况下的 404（未找到）。
- HTTP 5xx——不计费。
- HTTP 429（限流）——不计费。
- 到达我们边缘节点之前的网络错误 / 超时——不计费。
对于批量端点（例如一次调用里含 25 个 URL 的 URL Extract），只要有任意 URL 成功，整次调用就算一次 HTTP 200，按逐 URL 费率计费。逐 URL 的 status 字段告诉调用方哪些 URL 失败了。活儿干了，所以计费。
为什么大多数服务方不这么做
三个原因，按各自的分量排序：
- 计费基础设施。标准做法是在 API 网关处计量，那时还不知道响应结果。网关向 Kafka 发出一个可计费事件，计费系统汇总它，账单寄出。要把计量改成在上游服务以某个状态码作答之后才触发，要么 (a) 把网关耦合到后端健康状态（制造出新的故障模式），要么 (b) 写一条对账流水线，对失败调用做事后退款。两者都是实打实的工程活儿。
- 习惯。这个模式是被可靠的后端定下来的——Twilio、AWS、Stripe。当你的上游处在 99.99% 可用率时，它运作良好。而封装 LLM、爬网页或调用慢速数据合作方的 API 可靠得多有限，但计费模式是从那个可靠的年代继承下来的，从未更新过。
- 收入。「一律收费」纯粹就是更多的钱。大多数服务方还没必要在这个维度上竞争，因为大多数客户还不是 Agent 流量，而同步的人类用户对偶发失败的容忍度，远高于他们对啃一份计费模型的容忍度。
第一条是真正的工程问题。第二和第三条是惯性。随着 Agent 流量成为 API 消费的主体，两者都会让步——而趋势线显示，这对大多数公共 API 来说将在 18 个月内发生。
作为买家该看什么
如果你在为 Agent 工作负载评估数据 API，有三个该直接问的问题：
- 「你们是只对 HTTP 200 收费，还是对每一次可计费尝试都收费？」——要的是直截了当的回答。别接受「一般是」或「视套餐而定」。
- 「HTTP 207 / 部分成功怎么计费？」——这能把那个「漏洞式」回答逼出来。
- 「你们公布的可用率是多少，如果没达到，SLA 退款机制是什么？」——「只对成功收费」是个强信号，但它不能替代一份真正的 SLA。两者都该具备。
这指向的那个转变
AI Agent 正在改变它们所触及的每一个 API 的单位经济学。为 Agent 时代设计的 API 看上去就是不一样——更简单的形态、可预测的 schema、对机器友好的鉴权、透明的定价——它们的计费模型看上去也不一样。「只对成功收费」是其中较简单的一个转变。更难的那个还在前方：当没有任何单一一方拥有完整调用路径时，多步骤的 Agent 工作流该如何跨服务方定价。
眼下，对那些你能要求的服务方，就要求「只对成功收费」。构建能利用这一点的 Agent。而当你在挑选 API 时，按「每次成功调用多少钱」而非「每次尝试多少钱」来算这笔账。
常见问题
「只对成功收费」会不会诱使服务方把成功误判为失败？
理论上会，但反向的压力更强：开发者是按真实世界的「每次有用调用花多少钱」来比较 API 的，而这恰恰是「只对成功收费」所衡量的。一家偷偷把成功重新归类为失败的服务方，几天之内就会面对一支愤怒的客服队列和一串公开差评。这个市场足够小，会自我纠偏。
如果我的调用部分成功——比如批量 extract 中 25 个 URL 里有 2 个失败——怎么办？
有两种合理模型。(a) 只要有任意 URL 成功，整次调用就是 HTTP 200；逐 URL 的失败在逐 URL 状态里报告。活儿干了，所以计费。(b) 部分成功用 HTTP 207（multi-status）——每个 URL 单独计费。我们选了 (a)，因为它让定价可预测：Agent 知道一次成功的 HTTP 200 意味着最坏情况就是公布的 credit 成本。(b) 更「公平」，但更难做预算。
什么算作失败？
我们的规则：明显是调用方过错的 HTTP 4xx（请求体格式错误、缺少鉴权、credit 不足）不收费。HTTP 5xx 永不收费——那是我们的问题。我们这一侧的网络错误和超时永不收费。限流（429）永不收费。唯一收费的，是带有公布响应形态的 HTTP 200。
为什么大多数服务方对每一次调用都收费？
三个原因，多半是历史遗留。(1) 老旧计费系统在 API 网关处计量，那时还不知道响应结果。把计费改成事后随响应状态触发并不简单。(2) 这个模式是 Twilio 和 AWS 在后端可靠的年代定下的；而封装 LLM 或爬网页的 API 可靠得多有限，于是那个假设就不成立了。(3) 这更赚钱。前两条是借口；第三条是真相。
有没有「一律收费」更合理的情况？
当一次调用确实在每次被发起时都消耗一笔固定成本、无论结果如何——例如硬件外呼（已发出的 SMS）、在边界处原子化的变更（DNS 更新），或者一个其后端分不清「我们试过但失败了」和「我们做了但你没注意到」的服务。对于读取型数据 API 和搜索 API，这个模型并不适用。
本文涉及的 API
Sarah Choy 是 API Pick 的 CEO，专注于为 AI Agent 与 LLM 工作流构建可用于生产的 API。