你的试用版提供了“每天 100 次生成”。你的定价团队模拟了一个感兴趣的用户花一周时间进行体验。但第一个将智能体（agent）指向端点的试用者，在 70 秒内就用完了当天的配额，19 分钟内用完了每周配额，并在第二天午餐前耗尽了季度的推理预算。没有人收到警报，因为唯一设置的警报只在试用用户转化为付费用户时才会触发。
试用限制在制定时并没有错。它们针对的是不再适用于当前典型用户的用法分布。在六个月前的定价审查与今天早上的新用户注册之间，用户群体已经从点击按钮的人类转向了不知疲倦的程序。仪表盘上的数字不再代表你设定它们时的含义。
你统计的单位是错误的
行业内几乎所有的试用上限都是按请求、生成次数或会话来计算的。当每个单位都受限于人类的耐心时，这些单位是有意义的：一个人每小时只能发起有限的操作，且每个操作在后端成本上大致稳定。这个单位是支出的可用代理指标，因为“一次生成”与一美元推理成本之间的关系在数量级内是稳定的。
这种稳定性已经不复存在。现在的“一次生成”可能是一个成本仅为几分之一美分的单次补全，也可能是一个包含 50 个步骤的智能体循环——它检索四个文档、调用三个工具、生成一千个 token 的计划、执行计划、观察结果、重新规划，最后产生一个一万个 token 长的答案。两者都被计为一次生成。来自生产部署的报告显示，对于五步循环，智能体路径的成本大约是对话的三倍；在 50 步时，倍数超过 30 倍；在 200 步时，倍数达到 100 倍。你用旧单位计算的“每天 100 次生成”试用上限，现在是一张无法约束实际支出出现两个数量级波动的空支票。
解决方法是按你实际支付的单位来设定上限。消耗的 token 数、调用的工具次数、执行的检索操作以及占用的计算秒数，都是随成本等比例变动的计量单位。虽然对非技术背景的试用者解释这种计费方式更难，但另一种选择是向 CFO 解释预算超支——因为没人设置席位级限制，CFO 会看到那些关于公司意外向单一供应商支付 5 亿美元的新闻报道。
故障模式是无人察觉的分布偏移
如果你在三年前绘制一份每位试用者支出的直方图，它会有一个长尾，但形状清晰可辨：众数接近于零（注册后从未回访的人），中间有一个小起伏（活跃的评估者），以及一个由重度用户组成的细长尾部。尾部的宽度决定了你每个注册用户需要预算多少。容量规划之所以有效，是因为分布是稳定的。
现在的分布在零处有同样的众数，有同样的中间起伏，但尾部已经脱离了主体。少数试用者现在的消耗量被你的计费模型视为异常值，但实际上它们属于一个独立的集群：每分钟执行数千次操作、持续数小时，且仅在配额限制时才停止的程序化用户。运行大规模集群团队的报告是一致的：前 5% 的用户通常消耗了 50% 到 70% 的推理支出，而且这个比例在没有任何人干预的情况下每季度都在增长。
危险不在于这种分布的存在，而在于安全系统是针对旧形状设计的。“每用户软上限”的大小是为了容纳人类分布的长尾，但与程序化分布的长尾相比，前者微不足道。“异常检测器”被调整为标记前 1% 的用户，这意味着它现在会标记程序化集群中的所有人，由于没人能处理这么多警报，最终导致没人处理任何警报。反欺诈团队对“滥用”的定义早于智能体的出现，并不符合一个合法但昂贵的智能体用户的行为特征。
日上限不是周上限，两者都不是真正的限制
常见的试用设计是将日上限与没有周或季度上限相结合。隐含的假设是，达到日上限的人类会去睡觉，直到明天才回来，因此日上限也大约等于周上限。这个假设对人类成立。但在许多部署中，一个在早上 7:01 达到日上限的智能体，会在下一个配额窗口开启时立即重试，并在另外 70 秒内耗尽第二天的配额。连续七天如此，就是每周预算。连续九十天如此，就是季度预算。这不需要任何特殊的滥用，只需要一个会重置的配额窗口。
缓解措施是分层上限：设置一个用于短期爆发控制的日上限；一个小于七倍日上限的周上限（因为连续七天满额运行本身就是一种异常）；以及一个季度防滥用上限（除了你现在正防御的特定故障模式外，没人会触发它）。每一层都捕捉不同形态的过度消耗。每一层也很容易被遗忘，因为显示每日用量的仪表盘很少会显示滚动窗口，而滚动窗口能揭示某个试用者在第三天就已经达到了周上限的 95%。
第二项准则是将上限设为 token 上限而非请求上限，并分别计算缓存 token、输入 token、输出 token 和工具调用 token，使上限与账单匹配。供应商的账单是分项列出的，试用上限也应如此。否则，一个试用者在“每次生成”中消耗了百倍于预期的 token 量（因为每次生成调用了五个工具），而仪表盘显示 100 次生成，账单显示一万美元，填补这一缺口的唯一方式就只有事故复盘了。
你未曾构建的检测面
有趣的试用者并不是那些以人类速度消耗配额的人。真正有趣的是那些访问模式揭示出其背后是程序的试用者：请求频率恰好处于 API 允许的上限，在速率限制窗口过期的那一刻精准重试，工具调用的模式是人类绝不会输入的。这些模式在几分钟内就能从访问日志中检测出来，但前提是你在关注。大多数团队并没有在关注。
识别循环状访问模式的行为指纹分析与认证层的欺诈检测是完全不同的学科。其信号包括请求间的时间间隔分布、请求形态熵、空闲与活跃比例，以及该试用者的流量与同一周注册的其他试用者流量之间的互相关性。一个采用固定退避策略进行重试的程序与一个点击刷新的人在时间直方图上看起来截然不同，而且这种差异对于大多数明显的混淆手段都具有鲁棒性。
产品层面的问题是，一旦检测到这种模式该怎么办。将试用者踢出服务是错误的；他们中许多人正是你想要的客户，他们正在针对涉及自动化的真实用例评估你的产品。将其路由到不同的试用层级——一个拥有不同配额结构、转化后价格不同且速率限制上限不同的“智能体试用（agent trial）”SKU——才是既能捕捉价值又不会产生亏损的做法。限制不应该是无形的。被明确告知“你显然是在通过程序使用，这里是智能体试用途径”的试用者，其转化率高于那些配额被默默耗尽的试用者。
配额耗尽是一种用户体验，而不仅仅是一个开关
当试用者达到上限时，接下来的十分钟决定了他们是转化、流失，还是发起账单纠纷。这里主要有三种失败模式。第一种是静默配额：API 仅仅返回错误，试用者得出产品已损坏的结论。第二种是敌对配额：API 在没有任何预警的情况下返回账单页重定向，试用者得出产品是陷阱的结论。第三种是失控配额：上限在数据库层强制执行但存在延迟，在强制措施生效前，试用者的智能体消耗的资源远超名义上的上限。
行之有效的模式是优雅且透明的封顶：清晰的错误消息说明上限、配额重置的预估时间、定价可预测的升级路径，以及针对高价值试用者的宽限期（即呼叫人工审核员而非仅由代码执行）。宽限期是反直觉的部分。即将转化的试用者几乎总是那些触达上限的人；将触达上限视为积极信号而非滥用信号，能够扭转转化的经济效益。那些不打算转化的试用者在触达上限后会消失，这正是正确的结果。
失控配额是三者中最危险的，而且它是结构性的。大多数上限强制执行的逻辑是“检查使用表，决定是否允许请求，增加使用表”。在高频率的程序化负载下，检查和增加之间的间隙是一个窗口，试用者可以在其中发出数百个请求，由于增加操作尚未提交，这些请求都能通过检查。解决方法是在网关层使用内存中的令牌桶抽象来强制执行上限，并将数据库作为较慢的记录系统。学到这一教训的团队通常是从某个试用者产生的四位数账单中得到的教训。
政治层面才是修复停滞的地方
增长团队的考核指标是注册增速。基础设施团队的考核指标是可用性和单位成本。定价团队的考核指标是转化率。这些指标都不会受到那些只消耗推理预算而不转化的试用者的影响；这部分成本被吸收在了一个未出现在这三个团队仪表板上的项目里。试用滥用问题处于无人负责的状态，这就是为什么在每个利益相关者都听说过它之后，问题依然长期得不到解决的原因。
解决方案是结构性的。试用成本应该分配给其指标受试用影响的团队（通常是增长团队），而控制上限结构的团队应该是当上限设置错误时承担损失的团队。定价团队审查试用经济效益的频率应与审查付费层级经济效益的频率一致，且审查应包括长尾试用者的单个注册成本，而不仅仅是中位数。基础设施团队应在发布每个客户的成本仪表板的同时，发布每个试用者的成本仪表板，并设置相同的告警阈值。开启正确会议的问题不是“我们如何停止滥用”，而是“哪个团队负责试用的单位经济效益”。
免费试用是一种定价产物，它是针对一种已不再是众数用户的使用分布进行校准的。它的每一个组成部分——计数的单位、强制执行的上限、实施的检测、提供的配额耗尽体验——都是针对一群已经被取代的人群设计的。修补单个环节只能捕捉到单个失败模式；唯一持久的解决方法是承认这种产物已经过时，并针对实际注册的人群重新设计它。
做得好的团队将试用视为一种具有自身单位经济效益、自身 SLO 和专门负责人的计费产品，而不是一个恰好调用了推理 API 的营销小组件。没能做到的团队将以 2025 年每个团队都经历过的方式发现这种失败模式：通过一个更新速度比工程团队发布修复方案还快的账单仪表板。
会员专享
余下内容仅对会员开放。
会员可读完整内容 —— 每一个公开发布的观点背后，那些框架、决策与推理的全貌。
- —完整文章，包含未公开存档的部分
- —可落地的工作框架，附带权衡与决策依据
- —新文章抢先看，先于公开发布
随时取消 · 一次订阅，畅读全部
