定价
Agent 产品的定价难点，不只是“token 会产生成本”。更本质的问题是：一次任务的成本、价值和失败风险都随用户行为变化。定价要把这种不确定性包装成客户愿意购买、供应方也能承受的结构。
因此，定价不是成本模型的重复，而是三件事的设计：
- 客户为什么愿意付费。
- 供应方承担哪些成本和失败风险。
- 当使用量、模型价格或任务复杂度变化时，双方如何分担。
SaaS 定价为什么会失真
传统 SaaS 席位费默认边际成本很低。重度用户通常更有价值，因为他们增加留存和扩张机会，却不会显著增加服务成本。
Agent 产品不同。重度使用可能代表高价值，也可能代表高成本、低成功率、反复重试和人工审核。只用固定 seat 月费，会把全部使用风险放到供应方身上；只用纯按量计费，又会把预算不确定性全部推给客户。
好的 Agent 定价要同时解决三类风险：
| 风险 | 如果不处理会怎样 |
|---|---|
| 使用量风险 | 少数重度用户吃掉毛利 |
| 成功风险 | 客户为失败任务付费会损害信任 |
| 价格漂移风险 | 模型、缓存、区域、运行时价格变化导致合同口径失真 |
三种基础模型
订阅制
客户支付固定月费，套餐内包含一定任务量或预算。
适合：任务范围清楚、使用量相对可预测、客户需要预算确定性、销售需要简单报价。
风险：如果没有上限，重度用户可能压缩毛利；如果上限太紧，用户会觉得“订阅却不能用”。
按量制
客户按任务、token、运行时、成功结果或某种业务单位付费。
适合：任务复杂度差异大、客户能接受对账、产品更像 API / 基础设施，或者价值和使用量强相关。
风险：客户害怕账单波动；如果计费单位太技术化，非工程买方很难理解。
混合制
基础订阅提供预算确定性，超额部分按量计费或进入更高 tier。
适合：多数 Agent 应用产品，尤其是既要简单采购、又要覆盖重度使用的场景。
风险：如果超量规则不透明，客户会觉得被“偷偷加钱”；如果超量太宽，供应方仍然承担过多风险。
详细取舍见 订阅、按量与混合。
计费单位要接近客户价值
不要默认把 token 暴露给客户。Token 是内部成本单位，不一定是客户的价值单位。
常见选择：
| 计费单位 | 客户理解度 | 供应方风险 |
|---|---|---|
| Seat | 高 | 高，需强预算控制 |
| 成功任务 | 高 | 中，需要明确成功定义 |
| 使用量 / token | 低到中 | 低，成本传导直接 |
| 工作流包 | 高 | 中，适合垂直场景 |
| 已验证价值 | 高，但需要校准 | 中到高，核算复杂 |
越接近客户价值，越容易销售；越接近内部成本，越容易控制毛利。定价设计就是在这两端之间取平衡。
Tier 的作用
Tier 不是简单功能开关。对 Agent 产品来说，tier 通常包装四类差异：
- 可运行多少任务或预算。
- 默认使用什么模型路由。
- 能访问哪些工具、连接器和执行环境。
- 超额之后如何处理。
Tier 的详细设计放在 Tier 设计。这一页只强调一点：tier 应该让客户理解“升级后能完成更多、更难或更可靠的工作”，而不是只看到一堆功能清单。
价格漂移
模型和基础设施价格会变化，新模型也可能改变同一任务的 token 用量、步骤数和成功率。合同里如果写死过细的模型价格，后续维护会很困难。
更稳妥的做法是：
- 对客户承诺可理解的额度，例如任务量、成功结果、预算池或工作流包。
- 对内保留可更新的成本模型，用当前官方价格、模型路由和历史使用数据重算毛利。
- 对企业合同明确超量、模型升级、区域要求、托管运行时和人工审核的计费边界。