凌晨三点，你的AI产品突然开始丢对话历史。用户刚聊到一半，上下文没了。你查日志：没报错，没超限，一切正常。问题藏在更深的地方——你换了模型供应商，而两个模型对"这段话有多长"的理解，差了20%。

这是做多模型路由的开发者迟早会踩的坑。表面看，上下文管理就是数token、超了截、没过继续。实际跑起来，OpenAI、Anthropic、Google、Cohere、xAI各家有自己的"计数器"，同样的文本，token数能差出10%到20%甚至更多。

这意味着什么？一段对话在模型A的上下文窗口里绰绰有余，换到模型B可能就悄悄溢出了。同样的prompt发给OpenAI算1,200 token，发给Claude可能是1,450。这个缺口，足以让你的产品在最不该出错的时候崩溃。

故障往往发生在边界处。当你中途切换供应商，新模型必须吞下完整的前文。如果你的上下文管理是按上一个模型的tokenizer校准的，新模型看到的上下文可能已经达到或超过上限——在它还没回应任何新内容之前。

三种常见的崩法：

静默截断。 新模型收到被截断的历史，却没有任何报错。用户发现AI"失忆"了，但你查不到原因。

伪超限。 你的系统按旧模型算没超，新模型一算超了，直接拒收或抛异常。

成本失控。 为保险起见大幅预留buffer，结果该保留的关键上下文被提前砍掉，对话质量断崖下跌。

直觉告诉你：维护一个"统一token估算"，加个宽裕的安全边际。但问题是，这个边际得看供应商、模型版本、内容类型——代码和散文的切分方式完全不同。为一个场景校准的边际，要么在另一个场景太紧导致故障，要么太松导致不必要的截断。

靠谱的做多模型上下文管理，必须让token计数跟着供应商走。不是维护单一估算，而是按实际目标模型的方式测量每个prompt。这意味着：你的路由层要知道下一站是谁，用谁的tokenizer，按谁的规则数。

更深一层：有些团队试图用"字符数÷4"这种粗糙换算。在单一场景或许能蒙混过关，一旦跨模型、跨语言、混代码，误差会指数级放大。中文的token密度和英文差3-4倍，emoji可能占1个也可能占4个，这还没算各家特殊token的处理差异。

如果你正在做多模型路由，现在就检查：你的上下文管理是模型无关的，还是模型感知的？当用户第7次切换模型时，历史记录还能完整保留吗？

这个问题不会自己消失。它只会在凌晨三点，用一次无声的上下文丢失，提醒你它的存在。