企业接入的大模型越多，真正难管的往往不再是“能否调用”，而是一次请求该走哪个模型、工具身份如何传递、预算超限何时拦截、流式输出怎样审查。LiteLLM在北京时间7月29日发布1.94.0，发布清单汇集253个PR，把复杂度路由、MCP授权、流式护栏和成本审计同时推进。它更像一次AI网关控制面的集中整修，而不是简单增加几个模型适配器。

三点看懂：路由、身份与预算开始共享上下文

自适应路由不只选模型，还要保持会话一致

多模型网关常用分类器判断任务难度，再把简单请求送往低成本模型、复杂请求交给高能力模型。问题在于分类边界会抖动：同一会话中的相邻请求可能被分到不同层级，提示缓存、工具状态和回答风格随之失去连续性。1.94.0允许在复杂度层级内随机选择多个部署，用“软下限”避免低估任务，并默认启用会话亲和，让后续请求尽量沿用已经选定的路线。

管理员还可以设置由用户触发的升级关键词，并把路由插件写入代理配置。这样一来，“请用更强模型复核”之类的明确意图不必完全依赖分类器猜测，企业也能在模型选择前加入地区、合规、成本或容量规则。新版命令行加入lite up与lite down，可让Claude Code等客户端经由本地代理转发，但这只降低接入门槛，并不自动证明路由决策更准确。

MCP授权、护栏和费用审计被拉进同一条链

MCP工具接入最容易出现的不是“没有OAuth”，而是发现、登录、刷新、缓存和实际调用分别走了不同路径。新版为动态客户端注册加入交互式SSO，刷新凭据由客户端封装持有；授权服务器发现以发行者为锚点，降低错误服务器混入授权流程的风险。系统也会限制每用户令牌缓存不超过令牌自身有效期，并在聚合多个MCP服务器时返回逐服务器结果，避免一个失败被包装成全部成功。

输出控制同样从“请求前扫描”向执行中移动。通用护栏可以对流式文本做转换，Bedrock护栏新增只检测、不调用资源动作的模式，查询感知压缩可在长上下文进入模型前削减无关内容。日志侧则开始隐藏工具调用参数、记录用户和团队预算、补记客户端中断前已经产生的费用；团队密钥对用户预算的执行被标为行为变化，可能直接改变现有请求是否被拒绝。

这些能力的共同价值，是把模型调用、工具身份、安全判断和计费结果放回一条可追踪链路。对平台团队而言，排障不再只问“上游模型返回了什么”，还要能回答路由为什么选择该部署、工具令牌从哪里取得、护栏在哪一步修改内容、费用最终归到哪个用户和团队。

253个PR不是无风险升级，先用真实租户流量回归

253个PR包含功能、修复、测试、界面重构与依赖升级，不能等同于253项面向用户的新能力。发布清单也没有给出统一吞吐、延迟或成本基准，复杂度路由能否省钱取决于分类质量、模型价差、缓存命中和任务回退率。MCP身份流新增多个状态后，旧客户端、反向代理和自定义令牌存储是否兼容，同样需要在各自环境验证。

生产升级应至少覆盖四组场景：同一会话跨多轮时的模型粘性；团队密钥下用户预算的预留、拒绝与重置；MCP令牌过期、发现失败和多服务器部分失败；流式输出被护栏修改或客户端中断后的日志与计费。容器镜像已经提供签名校验路径，但供应链可验证不代表运行配置安全，密钥掩码、日志脱敏和自定义插件仍需单独审计。

ATYUN编辑判断：LiteLLM 1.94.0最重要的变化，是AI网关开始从“统一API转换器”走向会话级控制面。路由、身份、护栏和预算如果各自独立，智能体链路越长，故障越难解释；把它们放进同一上下文，才有机会形成可审计的生产闭环。下一步更值得观察的不是适配模型数量，而是自适应路由的误判成本、跨工具身份的可恢复性，以及这些新增控制是否能在高并发下保持低延迟。