为什么按席位定价会搞垮AI Agent SaaS（以及什么模式才管用）

上个月，我意识到自己的AI Agent产品正在亏钱。

客户A：3个用户，按每人每月29美元收费，月收入87美元。实际服务成本：2美元。
客户B：1个用户，月收入29美元。实际成本：30美元。
客户C：2个用户，月收入58美元。实际成本：200美元。

我每个月在客户C身上净亏143美元。

按席位定价（Per-Seat Pricing）对于Agent产品来说，就是毒药。

---

核心问题：成本与席位无关

传统的SaaS成本结构是这样的：

• 雇一个技术支持工程师 → 能服务50个客户
• 租一台服务器 → 能跑500个客户
• 随着规模扩大，每个客户的成本是下降的

按席位定价之所以一直管用，是因为软件的成本和用户数量是正相关的。你加一个用户，数据库连接多一条，存储多几M，带宽多一点点，边际成本非常稳定。

但AI Agent彻底打破了这种模式。

成本与人数完全脱钩了。

一个Agent帮团队里十个人跑简单的查询，每个月可能只要5美元的成本。另一个Agent只服务一个人，但做的是复杂的分析，每个月可能烧掉500美元。

那个只有一个席位的客户，消耗的毛利可能比十个席位的客户还多。而按席位定价，收的钱恰恰是反过来的——人多交钱多，人少交钱少，完全不管实际消耗。

这不是定价策略的问题，这是定价逻辑的根本性错位。

---

为什么这个问题现在特别严重

三个因素同时爆发，让AI Agent市场撞上了这堵墙：

1. LLM成本极度不稳定

一个Agent为了回答一个问题，可能调用50个不同的LLM工具。用的模型不同、问题复杂度不同、Agent的策略不同，推理成本可以从0.1美元跳到50美元。你不可能用一个固定的月费去吸收这种波动。

想象你开了一家自助餐厅，按人头收费，结果有人进来吃了一碗米饭，有人进来吃了十斤和牛。你撑不过一个月。

2. Agent行为不可预测

你永远没法提前知道一个Agent会触发多少次LLM调用。客户上传一个数据集，问了一个问题，你的Agent突然生成了10个并发线程，每个线程又调了100次API。你事先完全无法预估。

按席位定价，你没有任何办法收回这部分成本。

3. 客户已经被按用量付费教育过了

每个人都在用AWS、Anthropic、OpenAI，都是按用量付费。客户已经习惯了“我用多少付多少”的模式。你跟他说“每人每月29美元，Agent调用不限量”，他第一反应不是觉得划算，而是觉得你在藏着什么。

---

框架：六种真正适合Agent的定价模型

我花了一个月研究其他创业者是怎么解决这个问题的。以下六种定价模型，随便挑一个都比按席位强。

模型1：按Token收费

每消耗一个Token就计费。

# 简化示例
response = client.chat.completions.create(
    model="gpt-4",
    ...
)
tokens_used = response.usage.prompt_tokens + response.usage.completion_tokens
customer_bill += tokens_used * 0.000001  # 每千Token 0.001美元

优点：透明。客户完全理解“我用多少付多少”。
缺点：账单波动大。客户不知道自己每个月要花多少钱。
最适合：开发者工具，或者客户已经习惯按API用量付费的场景。

模型2：按工具调用收费

每次Agent执行一个动作（数据库查询、API调用、LLM调用）就收一次费。

def run_agent_action(tool_name, args):
    result = tool.call(args)
    customer_monthly_calls += 1
    customer_bill += 0.01  # 每次调用0.01美元
    return result

优点：简单易懂。鼓励Agent设计得更高效——调用越少越便宜。
缺点：不同工具调用的成本差异很大。调一次Stripe API和调一次LLM，成本天差地别。
最适合：工作流自动化、任务完成类场景，尤其是Agent自主性驱动型产品。

模型3：按任务收费

不管内部多复杂，一个逻辑任务只收一次钱。

def complete_customer_request(request):
    # 内部可能调了50次LLM、20次工具
    result = agent.run(request)
    # 但只收一次
    customer_monthly_tasks += 1
    customer_bill += 1.00  # 每个任务1美元
    return result

优点：客户最喜欢这个。“做一件事花1美元”，清晰明了。
缺点：你要承担所有成本波动。有的任务成本0.5美元，有的50美元，你必须清楚自己的利润率。
最适合：托管服务、固定范围的工作。

模型4：按成果收费

只在Agent交付价值时才收费。

• “每个合格线索5美元”
• “每次完成集成50美元”
• “每成功同步一个项目2美元”

优点：完美对齐。客户赢了你才赢。
缺点：你需要定义并验证“成功”。运营成本高。你要承担100%的成本波动。
最适合：高信任度的合作关系，或者有清晰可衡量成果的场景。

模型5：混合模式（席位+用量）

收一个基础的按用户月费，超过部分额外收费。

“每人每月29美元，包含500万Token。超出部分每100万Token收0.30美元。”

优点：企业客户熟悉这种模式。有稳定的基础收入。
缺点：需要清晰沟通，容易让客户困惑。你仍然要承担超额部分的波动。
最适合：从按席位定价迁移过来的产品，或者团队使用量差异较大的情况。

模型6：订阅分级（完全不追踪用量）

放弃用量追踪，直接按功能分级收费。

• 免费版：基础Agent，1个集成
• 29美元/月：高级Agent，5个集成
• 99美元/月：无限集成，API访问

优点：实现最简单。客户喜欢可预测性。
缺点：你要承担所有成本波动。如果你不了解自己的成本结构，风险极高。
最适合：只有在你对成本有非常严格的控制力时才用。

---

怎么选

问自己几个问题：

• 我了解客户的Agent工作负载吗？ → 按任务收费或按成果收费
• 客户用量差异很大吗？ → 按Token或按工具调用收费
• 客户已经理解LLM定价吗？ → 按Token收费
• 我想要最简单的实现？ → 订阅分级或按任务收费
• 我是否想和客户的成功对齐？ → 按成果收费

我自己选了按工具调用收费。客户理解“每月操作次数”这个概念。它鼓励设计更高效的Agent。而且它能和LLM成本波动解耦。

---

更难的问题：免费版

免费版既是吸引客户的手段，也是成本中心。

糟糕的免费版：无限免费，指望用户自己转化。
结果：用户不转化，你破产。

好的免费版：有清晰的边界。用户用1-2周就会碰到限制。升级变成自然而然的选择。

怎么设计免费版的规模：

1. 算清楚服务一个免费用户的实际成本：
   （LLM调用次数）×（每次调用的Token数）×（每Token成本）+（分摊到每个用户的基础设施成本）

2. 了解你的客户获取成本（CAC）：开发者产品大约50美元。

3. 算回本周期：假设每个付费用户每月贡献27美元毛利，两个月就是54美元，覆盖CAC。

4. 把免费版设计成用户大概在7-14天内碰到限制。

# 示例：如果典型用户每周消耗0.5美元
# 你的免费版预算大约是3-6美元
# 用户会在6-12周内用完
# 你需要在第8周左右让他们转化

class FreeTierManager:
    monthly_token_limit = 10_000_000  # 典型用户大约一周用完
    
    def can_run(self, customer_id):
        usage = get_monthly_usage(customer_id)
        if usage.tokens > self.monthly_token_limit:
            raise QuotaExceeded("升级才能继续使用")
        return True

---

超额：惊喜账单问题

超额是不可避免的。客户的Agent跑得比你预期的快。你的工作就是确保他们在碰到超额之前就理解规则。

几个关键规则：

1. 实时显示用量。“你已经用了800万Token中的800万。按当前速度，本月你将产生50美元的超额费用。”

2. 软限制加硬限制。用量达到计划的80%时发警告。达到100%时降速，客户必须确认才能继续超额使用。

3. 定价要明显展示。不要藏在角落里。

4. 让客户预购超额额度。比如“提前购买50美元的超额缓冲”。

---

退款：Agent死循环和意外账单

有时候Agent会陷入死循环。10秒内调用了1万次LLM。客户被收了500美元。

客户完全有理由要求退款。别在这件事上为难他们。

设置自动退款触发条件（不需要人工审核）：

• 单次用量超过日均用量的10倍
• 单小时用量超过月计划的50%
• 60秒内超过1000次调用

---

真正的教训

定价对于Agent SaaS来说，不是一次性决定。它是一个持续校准的过程。

你需要持续追踪这些数据：

• 每个客户的服务成本
• 每个客户分层的利润率
• 免费版转化率
• 按原因分类的流失率

如果你在亏钱，不要想着调一下价格就能解决。重新思考你的定价模型。因为按席位收费这件事，从一开始就不该用在Agent产品上。