Tier 设计 · aibuddy Docs

Tier 在传统 SaaS 里常常是“功能 + seat 数”。Agent 产品的 tier 还要承担另一件事：把不稳定的运行成本包装成客户能理解的容量和承诺。

一个好的 tier 不应该只回答“解锁了哪些功能”，还要回答：

能完成多少工作？
能完成多难的工作？
遇到超量或高风险任务时会怎样？

Tier 的四个维度

维度	说明
容量	任务量、token budget、运行时、并发数、存储或连接器额度
能力	默认模型路由、上下文长度、复杂任务处理能力
权限	工具、连接器、执行环境、团队管理、审计能力
服务	SLA、人工支持、合规要求、专属部署或数据区域

功能差异仍然重要，但如果 tier 不控制容量和超量行为，毛利会暴露在少数重度用户面前。

容量单位怎么选

不要只给客户展示 token。Token 适合内部控制，不一定适合采购理解。

常见组合：

容量单位	适合场景
任务数	工作流清晰、任务大小相对稳定
成功任务数	成功标准可定义，客户重视结果
预算池	企业客户，多种任务共享一个额度
运行时 / 会话	浏览器、沙箱或托管执行环境成本明显
token	工程/API 客户，能理解技术计费单位

实践中常用“双层表达”：客户看到任务量或预算池，系统内部用 token、模型路由和运行时做核算。

预算和模型路由

Tier 可以绑定默认模型，也可以只绑定预算。

方案	优点	风险
Tier 绑定默认模型	成本可控，解释简单	用户觉得能力被人为限制
Tier 绑定预算，模型可选	用户控制感强，适合复杂任务	需要清楚展示不同模型消耗预算的速度
自动路由	用户无需理解模型	需要可解释，否则客户不信任成本变化

更稳妥的设计是：默认自动路由，同时允许高级用户覆盖选择，并清楚说明“这会更快消耗预算”。

容量阶梯

Tier 之间需要有明显差异，否则升级没有意义；但差异太大，又会让客户卡在中间。与其追求固定倍数，不如看三个信号：

客户是否能直观看出升级后能完成更多工作。
当前 tier 是否经常触发接近上限但没有超量付费。
下一个 tier 是否让客户觉得“为少量增量被迫大幅升级”。

容量阶梯通常应随着客户成熟度逐步拉大：入门 tier 让用户试出价值，中间 tier 覆盖稳定工作流，高阶 tier 支持更复杂任务、更多团队和更强服务承诺。

超量行为

超量规则必须提前讲清楚。常见策略：

策略	适合情况	风险
硬停止	免费层、试用层、预算敏感客户	任务中断影响体验
软降级	常规任务可接受较低能力	用户可能感知质量下降
请求确认	高价值任务、企业用户	增加交互摩擦
自动超额计费	已签混合或企业合同	需要非常透明的账单
自动升级建议	用户持续接近上限	需要避免显得强推

最差的设计是：超量不提示、继续运行、月底给客户一个解释不了的大账单。

示例结构

下面是合成示例，不是建议价格：

Tier	主要承诺	典型限制	超量行为
Free	体验核心工作流	少量任务、低并发、有限工具	硬停止
Team	稳定日常任务	中等预算、标准模型路由、团队共享	请求确认或软降级
Business	高强度团队使用	更高预算、更多连接器、审计和管理	明确超额计费
Enterprise	合同化容量和服务	自定义预算、权限、合规和 SLA	合同约定

这个表的重点不是 tier 名称，而是每一级都同时说明容量、能力、权限和超量。

命名和展示

Tier 名称应让客户理解自己属于哪一类，而不是让他们猜内部成本结构。

好的展示方式：

用“每月可完成的典型任务量”解释容量。
用“适合的任务复杂度”解释能力。
用“团队、审计、权限、支持”解释企业差异。
用进度条、预警和账单预估解释超量。

避免：

把一堆模型名直接堆在价格页。
用 token 作为唯一对外额度。
把超量规则藏在服务条款里。
把 Enterprise 写成“联系我们”但不说明适合什么客户。

与其他章节的衔接

成本预算：economics/controls-and-roi
单位经济：metrics/unit-economics
定价模型选择：subscription-vs-usage

在 GitHub 编辑