Intercom 那个客服 Agent Fin，现在是按"解决一次收 0.99 美元"计费的，没解决不收钱。Salesforce 更折腾，两年换了四种计费模型，今年 6 月干脆推出 pay-per-resolution 的 Agentforce Help Agent，一次彻底解决收 2 美元，没解决免费，7 月正式商用。OpenAI 的 CFO Sarah Friar 9 月在高盛的会上也松了口，说他们在试"按业务结果定价"，而不是按用量。

这些放一起看，信号很清楚：软件收费的那个"原子单位"，正在从"席位"变成"结果"。

席位这个单位，本来就该死了

a16z 有句话我挺认同，席位不再是软件的原子单位。道理不复杂：过去软件是给人用的工具，一个人一个账号，按人头收费天经地义。可现在 Agent 干的不是"辅助人"，是"直接把活干完"。你还按人头收，就等于在按"有多少人来围观机器干活"收费。逻辑上说不通。

数据也在往这个方向推。今年 1 月一份第三方调研，四大通用 AI 场景（客服、编程、营销、办公）里，超过 62% 的企业客户说更愿意按结果付费，比 2024 年高了 37 个百分点。有头部客服 Agent 厂商跑出来的数字更直接：按解决率付费之后，客单价是传统订阅的 2.1 倍，客户留存高了 29 个百分点。商家愿意转，客户愿意买。这不是炒概念能炒出来的。

不过"SaaS 末日"这个说法我是不太信的。年初喊了一整年，结果呢？约 75% 的美国上市软件公司还是盈利的，只是能保持 20% 以上增长的剩三成左右。真正的末日没来，来的是分化。网络安全、可观测性、垂直行业软件相对稳，横向通用应用增长承压。法律医疗这种长出 Harvey、Abridge 的，护城河是跟行业专有数据、合规系统焊死了，替换成本高。

真正难的不是定价，是"谁说了算"

看到"按结果收费"，很多人第一反应是：那简单啊，做成一件事收一笔钱不就完了。

没那么简单。

真正的坑在三件事：谁来定义成功，谁来验证成功，以及这个成功跟 AI 到底有没有因果关系。

客服场景相对好办。用户问题解决了，一段时间内没再追问、没重开工单，就近似算一次 Resolution，Intercom 的模式就建在这种可验证事件上。可换个场景立马崩。销售：Agent 帮你筛了一个 lead，三个月后客户签约了，这笔钱全算 Agent 的功劳吗？万一销售后来跟进了 17 次呢？万一这客户本来就要买呢？编程 Agent 更绕，提交 PR 算成功，还是测试通过算，还是 merge 算，还是上线 7 天没出事故才算？

我这里有个第一手的教训。前两年我们做过一个智能对账的小工具，内部用。当时也想过按"对平的笔数"来算价值，好证明它有用。结果一上线就吵起来了。业务说这笔是系统自动匹配规则命中的，跟你的 AI 没关系；AI 这边说没有我兜底你那条规则根本覆盖不到。谁也说服不了谁。最后我们放弃了"按结果计价"这套内部核算，改成老老实实记录"AI 参与了哪些笔、人工复核了哪些笔"，把因果这事摊开给人看，反而没人吵了。

所以 outcome pricing 最后一定会逼着你建一个以前被当成"工程辅助设施"的东西：结果验证层（Outcome Verification Layer）。它得能回答，任务开始了吗、Agent 实际做了什么、是否满足预先定义的成功条件。这东西一旦要跟钱挂钩，它就不再是可有可无的埋点，而是你的计费系统本身。

失败成本，从客户的账单挪到了你的毛利

还有一层很多人没意识到：按用量收费对供应商其实很舒服。模型跑失败了，token 也烧了，钱照收。按结果收费完全是另一回事，你为一个问题调了 20 次模型、搜了 8 次、调了 6 个工具，最后还是转人工，客户大概率不付这笔钱。可你的成本已经发生了。

这一下就把竞争从"谁的模型更便宜"，变成"谁能用更低的总成本，稳定地把结果做成"。于是一堆以前不看的东西直接进了毛利模型：任务成功率、一次通过率、重试率、转人工率、人工复核率。

我现在越来越觉得，做 AI 产品的 eval 和可观测性，已经不只是质量工具了，它就是你未来的财务系统。你算不清一次任务到底花了多少、成没成，就没法按结果定价，更没法定到能赚钱。

所以呢

往下两年我猜计费会沿着一条阶梯滑：Token、Request/Credit、Conversation、Action/Task、Verified Outcome、收入分成。越往下越贴近客户真正关心的价值，也越把风险压到供应商身上。大多数产品会停在 Action 或 Verified Outcome 这一层，真敢做收入分成的还是少数。

但别指望一步到位。Salesforce 自己引 451 Research 的话说，多数企业还是偏好许可证模式，对结果定价的兴趣在涨，可客户要的是可预测的预算。采购团队手里没有 outcome-based 合同的先例，法务那一关就够喝一壶。

如果你是做产品的，我的建议是别急着换定价模型，先把"结果验证层"当地基修起来。能不能说清一次任务成没成、花了多少，这件事你早晚要还。如果你是买方，按结果付费听着很爽，风险都甩给供应商了，但记得在合同里把"什么叫成功"抠死，不然到时候为一次 Resolution 的定义能扯上三个月。

写到最后我其实有点没底。这套"卖结果"的逻辑在客服这种结果清晰、可验证的场景跑得通，可一旦进到销售、进到那些因果链条又长又糊的业务里，我怀疑它会不会退化成一种更精致的扯皮。先记下来，过一年再回头翻这篇，估计有一半判断是错的。