成本与配额治理：多租户预算、熔断与降级路由

先分清两件事：省钱和管钱

省钱是优化单价——换更小的模型、压缩上下文、用缓存。管钱是控制总量——谁能花多少、花超了怎么办。

多数团队只做第一件，因为它的收益立刻可见；但出事往往是第二件。一个租户把配额吃光、一次批量任务把月度预算打穿，这类问题省钱技巧一点都挡不住。

为什么 Agent 的成本比普通服务难管

三个结构性差异。

方差大。 同一个接口，一次调用的成本可能差两个数量级——输入长度、步数、工具返回的体积都不固定。普通服务按 QPS 就能估成本，Agent 不能。

成本发生在决策之后。 入口处无法预知这次任务要花多少，因为花多少取决于模型选了哪条路径、调了几次工具。

多租户下无法事后归因。 如果没有在入口打标签，账单出来你只知道"这个月花了多少"，不知道"哪个租户、哪个功能花的"。

三层：计量、预算、熔断

顺序不能反。

第一层，计量。 按租户、功能、模型三个维度聚合 token 与调用次数。关键点不是聚合，是归因标签必须在入口就带上——任务进入系统时打上租户与功能标识，一路透传到每一次模型调用和工具调用。事后补标签是不可能的。

第二层，预算。 日额度与月额度，各配两档阈值：软阈值告警、硬阈值拒绝。软阈值给人反应时间，硬阈值是止损。

第三层，熔断。 这层最容易被做成"超了就报错"。但报错等于把用户挡在门外，体验极差。更好的做法是降级。

降级路由：四个档位，按"对结果影响最小"排序

超预算之后的降级，不是一刀切换小模型。我倾向于按这个顺序动：

第一档，缓存复用。 查有没有相同或高度相似的请求最近处理过。这档对结果影响最小，因为它本来就在返回同一个答案。

第二档，压缩上下文。 砍历史、减检索片段。影响是可能丢细节，但主路径通常还在。

第三档，换小模型。 只对低风险步骤换——分类、抽取、格式整理这类。关键的判断步骤不要换。

第四档，减少步数。 跳过可选步骤（比如"额外再核实一次"）。这会降低质量，但能保住完成率。

顺序的原则是：先动用户感知不到的，最后动影响结果正确性的。很多实现直接跳到第三档，结果是小模型把复杂问题答错了，返工成本比省下的钱高得多。

方差治理：事前上限比事后预算有效

预算是滞后的——花完了才知道超了。要控制方差，得靠事前的上限：

• 单次调用的输入 token 上限
• 单步的输出 token 上限
• 单个任务的最大步数
• 单个任务的累计成本上限（到上限就强制收尾，而不是继续）

第三条最有用。绝大多数成本失控不是单次调用贵，是任务停不下来——循环、反复检索、工具一直返回不完整的答案。

所以"最大步数"这个参数，比"月度预算告警"能更早地拦住问题。

多租户：三种配额隔离，各有代价

硬隔离。 每个租户独立配额，互不影响。代价是资源利用率低，小租户的额度闲置。

共享池加优先级。 所有租户共用一个池子，按优先级抢占。利用率高，代价是大租户可能挤死小租户。

按比例分配。 每租户一个权重，超出部分可以借用未被使用的额度。这是折中，代价是实现复杂，而且"借用"的回收策略要想清楚。

选择依据是业务形态：租户之间是否真的平等、有没有大客户、峰值是否同步。这个选择在架构早期就要定，后期改动成本很高。

计量精度的几个坑

缓存命中的部分怎么算。 命中的 token 单价更低。按标准价计费，租户会被多收；按实收算，又和对外报价对不上。

工具调用的往返 token。 工具返回的内容会进入上下文，这部分也要算——它往往占总成本的大头，而且不在你的直接控制下。

重试的重复计费。 失败重试会产生额外调用，这些成本算执行方还是请求方？多数系统默认算请求方，但如果是系统自身故障导致的，理应算平台侧。

这三个如果不区分，账单会长期对不上，而且没人能解释差在哪。

一个反对意见

不建议给租户设"余额"式的钱包（预付费扣减）。

Agent 的典型任务是长任务、多步。余额模型会在"任务跑到一半"时打断，用户既没拿到结果，钱也已经扣了，体验极差。而且退款、补偿的流程会非常麻烦。

更合理的做法是速率加日额度：限制每分钟的任务数和每天的总消耗，超了排队或降级，而不是直接拒绝。余额制适合短平快的 API 计费，不适合 Agent。

落地顺序

1. 先在入口打上租户与功能标签，把计量跑通。这步不做，后面全都做不准。
2. 加事前上限：单次输入、单步输出、最大步数、单任务成本上限。
3. 加日额度与软、硬两级阈值。
4. 做降级路由的四档，按顺序生效。
5. 最后再谈多租户配额隔离策略——那时你已经有了真实数据，能算清该分多少。

收尾

成本治理的目标不是把账压到最低，而是让成本变成一件可预期、可归因、可降级的事。

可预期靠事前上限，可归因靠入口标签，可降级靠那四个档位。三样齐了，你才敢在月初告诉业务方"这个月能跑多少量"。

同系列：

• Context 装配架构：上下文预算、分层压缩与缓存复用 https://cloud.tencent.com.cn/developer/article/2753689
• Agent 评测体系架构 https://cloud.tencent.com.cn/developer/article/2750538
• Agent 可观测性：Trace / Span 语义约定与任务回放 https://cloud.tencent.com.cn/developer/article/2757125
• 工具层治理：Schema 版本、权限边界与破坏性操作的闸门 https://cloud.tencent.com.cn/developer/article/2759896