Agent 的经济账：从按 token 到按结果的计费演进

Agent 的收费问题，为什么还没有标准答案

传统软件的计费模式都很成熟：SaaS 按席位，云资源按用量。Agent（能自主多步执行任务的 AI 服务）夹在中间，两头都不完全适用——它既不是「按人头使用的工具」，也不是「可精确计量的资源」：一次简单查询和一次复杂排障，消耗可能差出一个数量级。怎么收费是行业正在解的题，本文只做机制分析，不引用具体公司报价，从成本侧的结构说起。

成本侧：一次任务要烧多少 token

Agent 的成本结构与单轮对话完全不同。单轮对话是一次模型调用；一次 Agent 任务是「理解任务 → 调用工具 → 观察结果 → 再调用模型」的循环，中途还有失败重试。token 消耗天然数倍于单轮对话，而且非线性增长：上下文越长，每一轮要重新处理的内容越多——第 N 轮调用的输入包含前 N-1 轮的全部积累，任务执行得越拖沓、重试越多，成本爬得越陡。工具执行本身不烧 token，但失败的工具调用会诱导模型继续尝试，间接放大消耗。一个常见的反直觉现象是：任务本身并不难，但中间步骤走偏了一两次，来回纠正的消耗就远超正解本身。

计费模式谱系

把能观察到的模式摆在一起看：

四种模式对应四种风险分配：token 转售把成本波动风险全给用户，订阅把风险全给供应商，结果计价试图让双方各担一半——这正是它难做的原因。

按结果计价：引力方向，落地难点

行业共识的方向是按任务或结果计价——用户买的本来就不是 token，而是「事情办成了」。难点有三。其一，结果难定义：「邮件写好了」和「邮件发出且对方满意」是两种完成。其二，验收有争议空间，需要可验证的任务完成标准——这与本站 Agent 评测入门讨论的是同一件事：没有客观的验收标准，计价就退化成扯皮。其三，失败重试的成本由谁承担：模型试了五次才成功，这五次的算力钱是供应商消化还是转嫁用户，直接决定这门生意的毛利。

毛利结构：被模型成本挤压的生意

按结果计价的产品，毛利等于「任务报价减去全链路模型成本」，而模型成本是被动的：供应商调价、用户任务变难，毛利立刻波动。这解释了两个常见现象。一是模型降价对 Agent 产品是直接的重大利好——任务报价不变、底层成本下降，毛利空间自动扩大（本站价格战一文讨论的正是这条传导链）。二是越来越多团队把自托管开源模型当成本对冲手段：高频、标准的子任务用自家部署的模型跑，把最贵的闭源 API 调用留给真正需要的环节。

买方的三个评估问题

采购 Agent 服务时，比起看演示，更该问清三件事。一，失败率多少：什么比例的任务会失败，失败由谁认定。二，单任务全成本多少：含重试与人工修正的端到端成本，而不是演示场景的均值。三，换模型时价格怎么传导：底层模型升级或降价，任务报价是自动跟着调，还是单向刚性。另要留意合同里对「完成」的定义是否与你的业务口径一致——口径差一点，结算时的争议就大一片。三问背后是同一件事：把「不确定性」从合同里挤出来。

收尾：给不确定性定价

Agent 商业模式的本质难题，是给「模型会出错」定价。传统软件的错误率低到可以忽略，合同里不必写；Agent 的失败是常态变量，计费模式就是风险分配方案——按 token 转售是用户全担，订阅是供应商全担，结果计价是博弈着分。谁先把失败率测准、把验收标准写清、把风险分配设计得让双方都愿意签，谁就先跑通这门生意。