Tier 设计

Agent 产品 tier 的本质是模型预算与任务量上限的分层——四条设计原则、典型 tier 结构、超量行为设计。

Tier（套餐）在传统 SaaS 里是”功能多少 + seat 数”的组合。Agent 产品的 tier 本质不同——核心维度是模型预算与任务量上限，功能差异是次要的。

原因：agent 产品的体验质量与单次推理用什么模型直接相关——Haiku 跑同样任务比 Opus 慢 / 准确率低 / 完成率低。Tier 等于”分配给用户每月多少 token 配额 + 走什么模型”。功能开关（BUA、MCP、自定义 subagent）只是表面差异。

四条设计原则

1. Token 上限是硬性的，金额上限是软性的

理由参见 economics/controls-and-roi。Token 是产品语义层稳定单位；金额随模型涨跌漂移。Tier 配额应当以 token 计量、对内核算时再折算金额。

2. Tier 之间应该有 4-10× 的预算跳跃

Tier 容量每级跳 ~7× log-scale 视觉 · 等像素步长 = 等倍数跳跃 · 设计成指数 Free 30 任务/月 ×6.7 Lite 200 任务/月 ×7.5 Pro 1,500 任务/月 ×6.7 Ultra 10,000 任务/月 Enterprise tier 自定义不在图中 · 5-8× 每级是 SaaS tier 设计的经验区间

跳跃太小（< 3×）用户感觉”升级没意义”；跳跃太大（> 15×）用户在 tier 之间没有适配档位，要么大幅升级要么不升级。SaaS 经验值是 5-8× 区间。

Tier月任务量典型范围跳跃倍数
Free10-50—
Lite50-3006×
Pro300-2,0007×
Ultra2,000-15,0007×

3. 默认模型与 tier 解耦的取舍

两种思路：

思路 A：tier 锁定默认模型——Lite 只能用 Haiku、Pro 默认 Sonnet、Ultra 默认 Opus。

  • 优点：成本可控；防止 Lite 用户跑 Opus 任务把账单打爆
  • 缺点：用户感觉”被限制”——明明任务简单也得用 Pro 才能选 Sonnet

思路 B：tier 决定预算，模型用户自选——任何 tier 都能选任意模型，但 Opus 任务消耗 token 配额更快。

  • 优点：用户掌控感强；高质量需求场景可临时升级
  • 缺点：成本核算更复杂；用户教育成本高（要理解”为什么我刚才跑了一个 Opus 任务月度配额掉了 5%”）

业界趋势是从 A 向 B 迁移——客户更接受”按用量消耗”而非”功能门槛”。但 B 要求用量界面足够透明（见 economics/controls-and-roi 的”用户层用量可见性”）。

4. 超量行为必须显式设计

订阅期内用户突破 tier 上限时的产品行为，是 tier 设计中最容易遗漏却最影响留存的环节。三种典型策略：

策略用户体验商业影响适用场景
硬中断”本月配额用完，下月恢复或立即升级”现金流稳定；可能丢失高活跃用户Free / Lite 防滥用；预算敏感的小客户
软降级自动切换到更便宜模型继续运行毛利保护；用户可能不察觉质量下降Pro 中等使用量的用户
自动按量超额超出部分按 token 实时计费，下月账单合并扣款客户惊讶风险；财务流程复杂大客户 / 企业合同 / 已签混合制

最差的设计：超量后不通知、继续无限制运行、月底账单变成原来 10 倍。这是按量定价类产品最常见的客户流失原因。

典型 tier 结构示例

以一个面向中小企业的 agent 产品为例：

┌─────────┬──────────────┬───────────────┬─────────────────────┐
│ Tier    │ 月费          │ 月任务量上限   │ 超量行为             │
├─────────┼──────────────┼───────────────┼─────────────────────┤
│ Free    │ $0           │ 30 任务        │ 硬中断              │
│ Lite    │ $19          │ 200 任务       │ 软降级到 Haiku       │
│ Pro     │ $79          │ 1,500 任务     │ 按量超额 $0.05/任务  │
│ Ultra   │ $299         │ 10,000 任务    │ 按量超额 $0.03/任务  │
│ Enterp. │ Custom       │ Custom         │ 合同约定             │
└─────────┴──────────────┴───────────────┴─────────────────────┘

（合成示例。）

注意几个细节：

  • 超量单价递减：Ultra 的 $0.03 比 Pro 的 $0.05 低——大客户超量是预期行为而非异常，定价应鼓励而非惩罚
  • Enterprise tier 不写数字：大客户合同永远是 case-by-case，不公开 Enterprise tier 的具体数字反而强化销售对话的灵活性
  • Free tier 必须存在但严格限：30 任务 / 月足以让用户试用 + 推广，不足以构成滥用入口

Tier 数量

3-5 个 tier 是经验区间：

  • 少于 3 个：客户感觉只能”全有或全无”，转化漏斗窄
  • 多于 5 个：决策疲劳，客户选择困难，销售对话变长
  • 4 个是中位推荐：Free / Lite / Pro / Ultra 已覆盖大多数客户细分

跨语言 / 跨市场可能需要不同 tier 结构——中国客户对低价 tier 更敏感、企业市场对 Enterprise 期待自定义。早期不需要做地区差异，市场进入后再分。

与其他章节的衔接

这页有帮助吗？
在 GitHub 编辑