小白 / Xiaobai

小白 / Xiaobai

开发者 · 产品构建者

持续构建 AI 工程系统、开发者工具与长期数字资产。

关于作者与 XBSTACK →
OpenAI Outcome-Based Pricing 中文封面:AI Agent 从 Token 与算力消耗走向 Task、Verified Outcome 和 ROI 的价值链

OpenAI 开始试验“按结果收费”:AI Agent 为什么可能不再只按 Token 计费?

OpenAI CFO Sarah Friar 表示,公司正在企业 AI 中试验基于业务结果而非单纯使用量的定价。本文结合 OpenAI、Intercom、Salesforce、AWS 等一手资料,分析 AI Agent 定价为何从 Token/Usage 走向 Task、Outcome 与 ROI,以及独立开发者应如何设计成本、评测、计费和模型路由。

发布 · 2026-09-1015 分钟阅读XBSTACK 原创
#OpenAI#Outcome-Based Pricing#AI Agent#AI Pricing#AI FinOps#Usage-Based Pricing#Value-Based Pricing#AI ROI

OpenAI Outcome-Based Pricing 正在把 AI Agent 的商业讨论从“每百万 Token 多少钱”推向“任务是否完成、结果是否可验证、ROI 是否成立”。过去两年,AI 产品商业化几乎都围绕 Token 成本展开,但当 Agent 开始真正执行工作,Token 就越来越像底层成本单位,而不再是客户愿意付费的最终价值单位。

开发者比较 GPT、Claude、Gemini,往往先看 Input、Cached Input、Output 的单价;做 AI SaaS,又会继续算一次对话烧多少 Token、一个用户一个月花多少钱、缓存能省多少、能不能把简单任务路由到更便宜的模型。这个思路没有错,因为 Token 是最直接的成本单位。

但如果 AI 不再只是“回答一个问题”,而是开始完成一件工作,Token 可能就不再是最重要的商业单位了。

2026 年 9 月 9 日,Reuters 报道,OpenAI CFO Sarah Friar 在 Goldman Sachs Communacopia + Technology Conference 表示,OpenAI 正把企业 AI 推向芯片设计、生命科学、金融服务等更具体的垂直场景,并且正在试验一种更值得注意的收费方式:按照 business outcomes(业务结果),而不是单纯按照 use(使用量)定价。 她同时披露,OpenAI 企业收入从 6 月到 7 月增长 32%,高于同期整体年化收入约 20% 的增速。

这不是“OpenAI 明天就不卖 Token 了”。事实上,OpenAI 当前的 Enterprise token-based rate card 仍然明确按输入、缓存输入和输出 Token 计价,API 也没有取消 Usage-Based Pricing。

真正值得关注的是另一个变化:AI 行业开始认真讨论,客户到底应该为模型消耗付钱,还是为模型把事情做成付钱。

我的判断是,这会成为 Agent 时代最重要的商业模型变化之一。

卖 Token,本质上是在卖计算;卖结果,本质上是在卖责任。

而一旦供应商开始卖“责任”,模型、评测、工具调用、失败恢复、人工复核和计费系统都会被重新设计。

OpenAI 的信号其实早在今年 1 月就出现了

如果只看 9 月这次 CFO 发言,很容易把它理解成一次会议上的商业故事。但 OpenAI 的方向并不是突然变化。

2026 年 1 月,Sarah Friar 在 OpenAI 官方文章 A business that scales with the value of intelligence 中写得很清楚:OpenAI 目前已经拥有消费者订阅、工作场景订阅和 Usage-Based API;当 AI 进一步进入科学研究、药物发现、能源系统、金融建模时,未来可能出现 licensing、IP-based agreements 和 outcome-based pricing,让 AI 提供商分享实际创造的价值。

把 1 月和 9 月两次信息放在一起,意义就变了。

1 月还是“未来会出现新的经济模型”,9 月已经变成“在企业场景中试验按照业务结果定价”。这不代表 OpenAI 已经完成商业模式切换,但说明 Outcome-Based Pricing 已经从概念进入企业商业化实验阶段。

更重要的是,它发生在 OpenAI 企业业务增长快于整体业务的阶段。企业客户与普通消费者最大的不同,是采购负责人最终必须回答一个很现实的问题:

这笔 AI 预算到底换来了什么?

例如,一个团队向财务部门汇报“这个月用了多少亿 Token”,这个数字本身几乎不能说明业务价值。

如果换成“客服 Agent 实际解决了多少问题、人工升级率下降了多少”,意义就完全不同。

同样,“代码 Agent 花了多少 Token”也不是结果;“它交付了多少可合并补丁,其中多少通过测试并被接受”,才开始接近结果。

这就是为什么 Agent 越成熟,Token 和客户价值之间的距离反而越明显。

AI Agent 三层经济模型:底层 Token/Compute Economics、中层 Task/Agent Economics、上层 Outcome/Business Economics

Token 是成本单位,但从来不是价值单位

传统云计算按 CPU、Storage、Bandwidth 收费很自然,因为客户本来就在购买基础设施资源。LLM API 沿用了类似逻辑:模型处理了多少 Token,就收多少费用。

但 AI Agent 正在把软件从“工具”推向“执行者”。

一个客服 Agent 的价值,不是生成了多少文字,而是有没有解决问题;一个财务 Agent 的价值,不是读了多少页 PDF,而是有没有把发票核对正确;一个 Coding Agent 的价值,也不是调用模型多少次,而是有没有交付可用代码。

因此,只看 Token 单价会出现一个很典型的错觉。

假设两个 Agent 都在处理同一种任务:

指标Agent AAgent B
单次任务 AI 成本0.03 美元0.12 美元
任务成功率45%96%
100 次任务成本3 美元12 美元
成功任务数4596
每个成功结果成本0.067 美元0.125 美元

只看到这里,A 似乎仍然更便宜。但如果 A 的失败任务需要人工返工,每次人工处理成本 1 美元,那么经济模型马上改变:55 次失败会额外产生 55 美元人工成本,而 B 只有约 4 次失败。

真正应该计算的是:

Cost per Verified Outcome
= (Model Cost
 + Tool Cost
 + Infrastructure Cost
 + Retry Cost
 + Failed-run Cost
 + Human Review / Rework Cost)
÷ Verified Successful Outcomes

这也是我认为 AI FinOps 下一阶段最需要改变的地方。

过去我们盯的是:

Token Cost
→ Cache Hit Rate
→ Cost per Request
→ Provider Spend

接下来应该变成:

Agent Cost
→ Task Success Rate
→ Cost per Verified Outcome
→ Business Value
→ ROI
→ Model Routing

便宜模型并不等于便宜结果。昂贵模型也不等于高 ROI。真正应该优化的是“完成一个可验证结果,需要付出多少总成本”。

这已经不是理论:Intercom 和 Salesforce 都在寻找新的“计价原子”

OpenAI 的变化之所以值得写,不是因为 OpenAI 第一个想到 Outcome-Based Pricing,而是因为越来越多 Agent 产品已经在实践“不要只按底层计算收费”。

Intercom 的 Fin AI Agent 现在直接把 outcome 作为计费单位。它不是按照一场对话里调用了多少次模型收费,而是定义 Resolution、Procedure handoff、Disqualification、Qualification 等结果,再按照结果计价。Intercom 甚至明确规定:一次 conversation 即使 Fin 执行多个动作,也只针对符合定义的 outcome 计费一次。

这件事很重要,因为“结果”不再只是市场宣传词,而被写进了 Billing(计费)规则。

Salesforce 的 Agentforce Pricing 则展示了另一个方向:它同时保留用户许可、Conversation 等模式,又通过 Flex Credits 按 Agent 完成的 Action 计量。Action 仍然不是最终商业结果,但相比 Token,它已经离客户实际购买的工作更近一步。

AWS 在其 Agentic AI Economics 指南中,也把 outcome-based pricing 单独作为 Agentic AI 的经济模型讨论,核心逻辑同样是让成本更直接地与可衡量结果连接,并把更多执行风险从采购方转移到供应商。

所以市场目前并不是从 Token 一步跳到“收入分成”,而是在寻找一套新的计价层级:

Token
↓
Request / Credit
↓
Conversation
↓
Action / Task
↓
Verified Outcome
↓
Business Value / Revenue Share

越往下,越接近客户真正关心的价值;但越往下,供应商承担的风险也越大。

AI 定价从 Token Usage、Task Action、Verified Outcome 演进到 Business Value 的价值链

Outcome-Based Pricing 真正难的不是定价,而是“什么叫成功”

很多人看到按结果收费,第一反应会是:那以后 AI SaaS 直接按成功任务收钱不就行了?

没这么简单。

真正的难题是:谁来定义成功,谁来验证成功,成功和 AI 到底有没有因果关系。

客服是相对容易的场景。用户的问题解决后,在一定时间内没有继续追问、没有重新打开工单,可以作为一个近似 Resolution。Intercom 的模式就是建立在这种可验证事件之上。

但换到销售场景,问题马上复杂。

Agent 帮你筛选了一个 Lead,三个月后客户签约,这笔收入应该全部算 Agent 的 Outcome 吗?如果销售人员后来跟进了 17 次呢?如果客户本来就会购买呢?

再换到 Coding Agent:提交 PR 算成功,测试通过算成功,Merge 算成功,还是上线 7 天没有事故才算成功?

因此,Outcome Pricing 最终一定会逼着产品建立一个以前经常被当成“工程辅助设施”的系统:Outcome Verification Layer(结果验证层)。

它至少要回答:

任务开始了吗?
→ Agent 实际做了什么?
→ 是否满足预先定义的成功条件?
→ 是否需要人工确认?
→ 结果是否在观察期内被撤销 / 重开?
→ 成功来自 Agent、人工还是外部条件?
→ 最终是否允许计费?

这意味着 Agent Evaluation(评测)不再只是研发团队跑 Benchmark 的工具。

评测系统会逐渐变成计费系统的一部分。

Outcome Verification Layer 结果验证层:用户任务经过 Agent 执行、成功标准校验、归因和人工复核后形成可计费结果

这是我认为很多开发者现在还没有意识到的一点。

一旦按结果收费,失败成本就从“客户问题”变成“你的毛利问题”

Usage-Based Pricing 有一个对供应商非常舒服的地方:模型失败了,Token 也已经消耗,费用通常仍然产生。

Outcome-Based Pricing 则完全不同。

如果合同约定“成功解决问题才收费”,Agent 为一个问题调用模型 20 次、搜索 8 次、调用 6 个工具,最后还是转人工,客户可能不会为这个 Outcome 付钱。

但你的成本已经发生了。

这会把 AI 产品的竞争从“谁有更便宜的模型”变成:

谁能用更低的总成本,稳定地把结果做成。

因此以下几个指标会直接进入毛利模型:

Task Success Rate
First-pass Success Rate
Retry Rate
Escalation Rate
Human Review Rate
Failed-task Cost
Cost per Verified Outcome
Outcome Reopen / Reversal Rate
Gross Margin per Outcome

过去一个 5% 的成功率差异可能只是产品体验问题;未来如果你按结果收费,它可能直接变成利润差异。

这也是为什么模型路由不能再简单写成:

简单问题 → 最便宜模型
复杂问题 → 最贵模型

更合理的目标应该是:

选择使 Expected Cost per Verified Outcome 最低的模型 / 工作流

如果一个更贵的模型显著减少重试、工具误调用和人工返工,它可能拥有更好的单位经济性。

对独立开发者来说,别急着“按结果分成”,先把一个结果定义清楚

大厂谈 Outcome-Based Pricing,很容易让独立开发者产生一个冲动:我的 AI 产品是不是也应该立刻改成“成功才收费”?

我反而建议克制一点。

独立开发者最适合先做的,不是复杂 Revenue Share,而是找到一个同时满足四个条件的 Billable Outcome(可计费结果)

  1. 边界清楚:开始和结束事件能识别;
  2. 可以验证:不是“用户感觉效率提高了”;
  3. 与你的 Agent 强相关:不是主要由销售、市场或线下流程决定;
  4. 价值明显高于交付成本:否则结果越多亏得越多。

例如:

产品场景更好的 Outcome不好的 Outcome
客服 Agent工单解决且 72 小时内未重开“回答了一条消息”
发票 Agent发票字段通过规则校验并被财务系统接受“解析了一份 PDF”
Coding AgentPatch 通过指定测试并被人工接受“生成了代码”
数据 Agent生成的数据结果通过约束检查并进入下游任务“执行了一次 SQL”
销售 Agent符合预设标准的 Qualified Lead“发送了一封邮件”

早期商业模型也未必需要一步走到纯 Outcome。

我更看好混合模式:

基础订阅
+ 一定量 Included Usage
+ 可验证 Outcome 计费
+ 高成本任务 / 高级模型附加费

这样既能让客户的价格与价值逐渐对齐,也不会把所有模型成本波动和长尾任务风险一次性压到开发者自己身上。

Stripe 对 Intercom 定价团队的访谈也给出了类似行业判断:随着 AI Agent 越来越像“交付结果”的软件,纯 Usage-Based Pricing 与实际价值之间的脱节会越来越明显,Outcome-Based 与混合模型会得到更多试验。相关资料

AI FinOps 下一步不是“省 Token”,而是回答 ROI

我前面一直在关注 AI FinOps,是因为模型成本并不会因为 Outcome Pricing 出现就消失。恰恰相反,当客户不愿意替失败 Token 买单时,供应商内部反而要把 Token 算得更细。

只是内部和外部看的指标不同了。

对客户,你可能卖的是:

Resolved Ticket
Approved Invoice
Accepted Patch
Qualified Lead
Completed Research Task

但对内部,你必须继续拆:

Model Cost
Tool/API Cost
Vector / Storage Cost
Retry Cost
Human Review Cost
Failure Cost
Infrastructure Cost

然后把两侧接起来:

Agent Cost
→ Task
→ Verification
→ Outcome
→ Business Value
→ Revenue
→ Gross Margin / ROI

这套链路一旦建立,模型路由也会发生变化。

你不再问“GPT-A 比 GPT-B 每百万 Token 便宜多少”,而会问:

在客服退款场景里,哪个模型最终每解决一个合格问题最便宜?

在代码修复场景里,哪个模型虽然单次调用更贵,但 Merge Success Rate 更高?

哪些任务根本不值得用最强模型,哪些任务如果失败一次,返工成本比模型差价高得多?

这才是 Model Routing 真正进入商业系统后的样子。

可以把它概括成一条链:

Agent Cost → Task Success Rate → Business Outcome → ROI → 自动模型路由。

AI FinOps ROI 闭环:Agent Cost、Task Success Rate、Verified Outcome、Business Value、ROI 与 Model Routing

不是为了让架构看起来高级,而是因为最终每一次模型选择都会影响“这个结果到底赚不赚钱”。

但 Token 不会消失,至少很长时间不会

这篇文章最容易被误读成“Token Pricing 要结束了”。我不这么认为。

Token 依然是非常优秀的基础设施计量单位。对于 API、开发平台、模型供应商和大量无法定义统一业务结果的工作负载,Usage-Based Pricing 仍然简单、透明、可扩展。

真正可能发生的是计价层级分化

模型层继续按 Token 计费;Agent 平台内部把 Token、Tool、Retry、Human Cost 合并成 Task Cost;面向企业客户时,再把部分任务包装成 Action、Resolution、Verified Outcome 或更高层的商业价值。

也就是说:

底层:Token / Compute Economics
中层:Task / Agent Economics
上层:Outcome / Business Economics

这三层不是互相替代,而是逐渐叠加。

因此,对 OpenAI 这次信号最准确的理解,不是“OpenAI 不卖 Token 了”,而是:当 AI 从模型能力进入企业生产流程,OpenAI 也必须开始回答客户最传统、也最苛刻的商业问题——你到底创造了多少可以被验证的价值?

我认为这才是 Agent 商业化真正开始的地方

过去两年,AI 行业最热闹的是模型参数、Benchmark、上下文长度和 Token 单价。

这些东西仍然重要,但它们越来越像发动机参数。

企业最终不会因为发动机每分钟转了多少圈付费,它只关心车有没有把货送到。

Agent 也是一样。

当一个 AI 只能聊天时,我们很自然地卖“访问权”和“使用量”;当它开始替人完成客服、财务、研发、销售、研究甚至专业决策流程时,客户会越来越不满足于“模型很聪明”这件事。

他们会问:

成功率多少?

省了多少人工?

失败一次谁承担成本?

我为什么要为模型自己绕了 30 轮却没做成的任务买单?

这些问题一旦成为采购问题,AI 软件的竞争标准就变了。

所以我认为 OpenAI 这次真正值得关注的,不是又多了一种 Pricing 名词,而是它透露出一个更深的方向:

AI 正从“出售智能的使用权”,走向“对智能产生的结果负责”。

如果这个趋势继续成立,那么未来最值钱的 AI 产品,不一定是 Token 最便宜、模型参数最大、对话最流畅的那个。

更可能是那个能明确承诺一个结果、稳定完成它、证明它确实完成了,而且还能在这个结果上持续赚钱的产品。

对于独立开发者来说,这也是一个很现实的提醒:下一阶段不要只问“我接哪个模型最便宜”。

更应该问:

我的 AI 到底替用户完成了什么,而这个结果值多少钱?

继续阅读

资料来源

专题入口 / AI Agent Hub

从单个 Agent 问题继续进入完整生产体系

AI Agent 专题统一组织架构、记忆、工具调用、评测、安全、部署和多智能体协作,让每篇文章都回到明确的主题主页面。

继续阅读

返回专题 →
Context Engineering 是什么?AI Agent 如何用 Retrieval、Tool Search、Memory 降低上下文成本Context Engineering 不只是 Prompt Engineering。本文结合 Microsoft、Anthropic、Google 官方资料与 XBSTACK 本地实测,解释 Retrieval、Tool Search、MCP、Memory、Compaction 如何减少无效上下文与 AI Agent Token 成本。GPT-6 Astra API 怎么用?价格、Claude/Gemini 对比、105 万上下文与迁移GPT-6 Astra 已于 2026 年 9 月 3 日发布。本文核对 API 价格、105 万上下文、Responses API 迁移与开放状态,并结合官方同表 Benchmark 对比 Claude Fable 5.1、Gemini 3.8 Flash 的 Coding、Agent 与成本定位。Gemini 3.8 Flash vs 3.7 Flash:价格没变,Coding、Agent 和实际成本怎么选?Gemini 3.8 Flash 和 3.7 Flash 有什么区别?核对价格、1M 上下文、Thinking Level、AI 编程、AIGC、Claude/GPT 选型语境、Agent 路由、迁移和 Token 成本。Claude Fable 5.1 和 Mythos 5.1 有什么区别?价格、权限、Coding 与 Agent 怎么选Claude Fable 5.1 和 Mythos 5.1 是同一个底层模型但使用不同安全策略。本文核对 Anthropic 官方价格、开放范围、缓存成本、Coding/Agent 基准和 Mythos 访问条件,帮助开发者判断该选哪一个。

AI 工程周报

只发真正改变工程判断的变化、故障、实验和新资产。

评论与补充证据

参与讨论

问题、验证与勘误

登录后可发表评论。所有新评论先进入审核;审核期间仅评论者本人和管理员可见,通过后才公开。

登录评论 审核后公开
正在加载评论区…