真正重要的数字不是总量
单个运营者每年六位数的 token 支出，并不是一个值得庆祝的里程碑。它是一个信号，说明系统已经发展到了任何人都无法再用混合平均值来理解它的程度。一旦工作负载达到这种规模，真正有意思的工程问题就不再是 agent 拥有多少自主性，而是有多大比例的流量被路由到了正确的模型层级，以及这个比例是被测量出来的还是被假设出来的。
想一想在这个支出水平上，单用户 agent 集群实际上是什么样子。大多数调用都很便宜：简短的分类步骤、tool call 参数构造、retrieval 重排序、对即将被丢弃的 tool 响应做摘要。一小部分长尾调用则很昂贵：长程规划、针对失败测试的代码修复、需要模型在上下文中同时持有相互冲突证据的多文档综合。这两类调用之间的比例才是设计变量。如果便宜的调用被送到了昂贵的层级，预算就会膨胀，却没有任何相应的质量提升。如果昂贵的调用被送到了便宜的层级，预算看起来健康，而困难任务却在悄悄失败。
混合平均值把这两种失败都掩盖了。每次请求的平均成本无法告诉你集群是否过度配置，因为少量非常昂贵的正确调用和大量非常昂贵的不必要调用会产生相同的均值。你需要的是按任务划分的成本分布：已完成任务的支出形态，按任务类别拆分。一个头部很薄、尾部很重的分布，说明系统在正常运转——便宜的工作交给便宜的模型，困难的工作被升级处理。一个完全没有尾部的分布则很可疑。它通常意味着困难任务并没有被便宜地解决；它们被丢弃、截断，或在完成之前就被放弃了，而支出曲线只统计了返回的调用。
已完成与已尝试之间的这一区别，正是大多数 token 仪表盘失效的地方。它们报告每次请求的 token 数，因为这是 API 返回的内容。而支配你预算的数字是每个已完成任务的 token 数，两者之间的差距就是失败的成本。
路由是一个带延迟预算的分类器
在一个构建良好的集群中，每个请求都会在昂贵调用开始之前经过一个廉价的预分类器。这个分类器回答一个问题：这个任务需要哪个模型层级？它运行在一个小模型、一个规则层，或是对照一组带标签的历史任务做轻量级 embedding 比较之上。它的职责是以足够低的成本做出路由决策，使决策本身不会成为一项单独的开支。
分类器既有成本预算，也有延迟预算。如果预分类增加了用户能感知到的往返次数，运营者就会禁用它，默认把所有请求都路由到大模型。这是路由策略最常见的死法：不是死于糟糕的分类，而是死于延迟——延迟让正确的路径变得太慢，以至于无法保留。
误路由有两个方向，而且它们并不对称。
- 向上误路由是一个成本事件。一个本可以由小模型处理的任务被送到了大模型。质量没问题；预算吸收了这次错误。通过把任务在更便宜的层级上重放，可以低成本地事后检测出这类错误。
- 向下误路由是一个质量事件。一个需要大模型的任务，从小模型那里得到了一个自信、看似合理、却是错误的答案。这类错误检测成本很高，因为失败是无声的，而且当 agent 基于错误输出采取行动时，它们会不断累积。
两者需要分开的指标。单一的“路由准确率”数字，会让一个从不升级的集群看起来和一个正确升级的集群一样好。把向上误路由率作为成本比率来追踪，把向下误路由率作为任务失败率来追踪，永远不要把两者平均成一个数字。
分类器本身必须在 agent 所看到的同一任务分布上进行评估。这正是会衰减的部分。一个在上一季度流量上训练的分类器，会随着工作负载的变化而漂移——新工具、新文档类型、新用户意图。这种漂移在总支出中是不可见的，因为总量会因其他原因持续变动。实际的解决办法是：保留一份近期真实流量的留出切片，按计划通过分类器重放，并将路由决策与昂贵层级本会产生的输出进行比较。这种重放是衡量策略是否仍然成立的唯一诚实手段。关于 agent evaluation 和成本感知部署的相关工作持续强调分布匹配的测试优于基准分数，这是正确的直觉——基准告诉你分类器能够分类，而不是它分类的是你的流量。
需要埋点监测什么
在这种规模下，集群的埋点监测有三条不可妥协的原则。
记录每个已完成任务的 token，而不是每次请求的 token。 为每次运行打上完成状态标签，只对达到已定义终止状态的运行汇总支出。未完成的运行——超时、tool 循环、被放弃的计划——才是昂贵的那些，而它们会从每次请求的平均值中消失，因为每一次单独的调用看起来都正常。一次在十二个步骤中消耗了大量上下文然后失败的运行，是系统中最昂贵的单个对象，而大多数仪表盘看不到它。
追踪升级率。 一次运行在任务中途从小模型切换到大模型的频率有多高？升级是让激进的向下路由站得住脚的安全阀。低升级率伴随高向下误路由率，意味着阀门卡住了。高升级率意味着预分类器判断不足，集群为两次尝试付费，而一次就够。这个比率本身是一个路由健康信号，而不是一个要最小化的成本。
把缓存命中率当作路由输入。 prompt 缓存通常被归入基础设施优化，与模型选择分开。它不应该被这样对待。如果一个任务类别在其稳定前缀上有很高的缓存命中率，大模型的有效成本就会下降，路由阈值就应该移动。一个忽略缓存状态的策略，恰恰会在昂贵层级已经因复用而打折的工作负载上，过度路由到便宜层级。把命中率纳入路由决策，而不是纳入月度报告。
规则
一个你无法按任务类别拆解的预算，就是一个你无法在评审中为之辩护的预算。当有人问为什么支出是这个数字时，“agent 很忙”不是一个答案。“已完成任务的百分之六十是 B 类，运行在小层级上，成本稳定；尾部是 D 类规划运行，这里是该尾部的升级率和向下误路由率”——这才是一个答案。
运营规则很短：按任务类别路由，按完成情况把关，每月审计尾部。
- 按任务类别路由。 明确定义类别，把每个类别映射到一个层级，并持续用近期流量评估分类器。
- 按完成情况把关。 只统计已完成的运行的支出。失败成本是一个路由信号，而不是开销。
- 每月审计尾部。 把最昂贵的已完成任务在更便宜的层级上重放。每一个在重放中存活下来的任务都是一次向上误路由，其总量就是你可以获得的修正空间的大小。
诚实的权衡是：这套机制消耗工程时间，并在每次调用之前增加一个带延迟的组件。一个把所有请求都路由到一个大模型的团队会交付得更快，而且对于小工作负载，会花费更少的注意力。这种权衡在某个节点之后就不再站得住脚——大约在单个运营者的支出达到六位数的时候。不是因为金额在绝对值上很大，而是因为在这种规模下，系统拥有足够的任务多样性，单一层级对其中大部分任务而言可证明是错误的。预算不是炫耀的资本。它是一项策略，而策略是可以被审计的。