周末原型升级生产后遗留LLM系统如何迁移到AI网关

周末原型只靠一个模型、一个提供商和环境变量里的单个 API key 就能跑通。生产后，供应商宕机就等于系统宕机，所有重试逻辑必须自己写，花销直到发票才知道，智能体工具调用也只能随意拼接。这篇文章把这套遗留栈迁移到开源企业 AI 网关 Bifrost，并给出实际迁移的原始输出。

单一 API key 把系统可用性完全绑定一个提供商

早期支持型 Copilot 往往从周末快速验证开始。开发者只接入一家模型提供商，把 API key 塞进环境变量，几行代码就能让原型跑起来。这种方式在演示阶段足够轻量，但进入生产环境后立刻暴露致命问题。

一旦该提供商出现服务中断，整个应用就跟着不可用。国内大模型落地时，这种单一依赖尤其突出。不少团队初期只接通一家云服务商的接口，追求快速上线，却在后续业务扩张中遭遇频繁的区域性故障或限流。信号显示，供应商的可用性直接等于系统的可用性，没有任何缓冲层。

更麻烦的是，国内合规要求往往需要多地域、多厂商备份。单一 API key 架构下，切换提供商意味着大规模重写调用逻辑。团队不得不维护多套认证代码，增加出错概率。原型阶段看不见的绑定，在生产流量上来后变成持续运维负担。实际案例中，某金融客服系统因依赖单一境外模型提供商，在网络波动时连续数小时无法响应，最终被迫紧急增加备用通道，却付出了双倍的集成成本。

这种弱点还延伸到错误处理。所有超时、限流、认证失败都必须在应用代码里手动捕捉。开发者把精力耗在基础设施健壮性上，而不是业务逻辑本身。国内团队普遍反映，早期原型代码在生产中被反复打补丁，最终形成难以维护的遗留系统。

重试逻辑和工具调用从应用层剥离到网关层

遗留 LLM 基础设施的另一个常见痛点是，所有重试机制都由应用代码承担。信号明确指出，每一次重试都是开发者自己写的逻辑。这导致代码里充斥着指数退避、熔断器和各种边缘情况处理，维护成本高昂。

AI Gateway 的核心价值之一就是把这些通用能力下沉。Bifrost 这类网关在中间层统一实现重试、负载均衡和故障转移。应用侧只需发起一次调用，网关负责与下游模型提供商的可靠交互。这直接减轻了业务团队的负担，让他们可以专注在 prompt 工程和 Agent 行为上。

工具调用（tool-use）的情况类似。早期 Agent 往往在应用层硬编码工具描述和解析逻辑，信号描述为“agents bolt tool-use on however they can”。这种随意拼接的方式容易出现格式不兼容、解析失败等问题。迁移到网关后，Bifrost 可以统一管理工具注册、调用路由和结果回填，减少应用代码中的胶水逻辑。

国内大模型落地过程中，这一点特别实用。很多团队同时使用多家国产模型，它们的 tool calling 格式和参数规范存在差异。网关层做一次适配，就能让上层应用保持统一接口，避免每次新增模型都重写 Agent 代码。实际迁移中，开发者把原来散落在各个服务里的重试函数和工具解析器删除，替换为指向网关的简单 HTTP 调用，代码量显著下降。

花销从发票后置变成实时可见的成本控制

遗留系统中，花费情况直到收到提供商发票才清晰。信号直接指出“spend is a mystery until the invoice”。这在国内团队预算管理中造成很大被动。很多企业按季度或月度结算，当发现超支时已经来不及调整。

引入 AI Gateway 后，成本数据可以在请求层面实时采集和展示。网关记录每次调用的 token 消耗、模型单价和实际金额，团队可以设置预算阈值、按部门或项目做分摊，甚至在超预算时自动切换到更便宜的模型。

对国内落地场景而言，这一点意义重大。当前大模型调用费用仍是主要成本项，尤其在高并发客服、代码生成等场景下。实时可见让财务和工程团队能共同制定策略，比如在非高峰期路由到性价比更高的国产模型，或对低优先级请求启用更小的模型。某互联网公司迁移后发现，之前无法区分不同业务线的花费，迁移后能精确到每个功能模块的日消耗，及时关闭了几个低效实验项目。

这种转变也改变了采购模式。从按年大额预付转向按实际使用付费，减少资金占用。网关还能提供异常消费告警，避免单个用户或测试账号意外产生高额账单。整体来看，成本控制从事后审计变成事前预防，显著提升了 LLM 应用的财务可控性。

Bifrost 开源网关的迁移路径与兼容性验证

信号中提到，这篇文章实际运行了迁移过程，并展示了原始输出。Bifrost 作为开源企业 AI 网关，提供了一条清晰的路径。

第一步是部署 Bifrost 实例，可以选择自托管或云上部署。它暴露与 OpenAI 兼容的 API 端点，因此原有代码中调用 openai 库的部分只需修改 base_url 指向网关地址，API key 换成 Bifrost 签发的密钥。

接下来配置上游提供商。在 Bifrost 的配置文件中添加多个模型提供商的凭证和路由规则。迁移过程中，开发者把原来硬编码的单个模型名称改为动态路由策略，例如根据 prompt 长度或任务类型选择不同后端。

兼容性验证主要看两点：一是响应格式是否与原有代码完全一致，二是工具调用和流式输出是否正常。信号显示，实际迁移后输出了原始日志，证明大部分调用可以做到零代码改动或极少改动。原有错误处理代码可以逐步移除，因为网关已接管大部分异常情况。

整个过程通常在一两天内完成，小型团队甚至能利用周末完成原型到生产的切换。开源特性让国内团队可以审查代码、按需修改，避免完全依赖商业产品带来的锁定风险。

多模型路由对国内大模型落地多提供商策略的支撑

国内大模型生态呈现明显的多提供商格局。既有通义、豆包、百度文心等头部模型，也有各种垂直领域的小模型。单一提供商策略已无法满足合规、多地域和成本优化的综合需求。

迁移到 Bifrost 这样的 AI Gateway 后，多模型路由成为标配。网关可以根据请求头、内容特征或策略配置把流量分发到不同后端。国内团队常用的一种做法是：敏感数据走本地部署模型，非敏感数据走云端高性能模型；高峰期自动切换到备用提供商。

这直接支撑了多提供商策略。以前切换模型需要改动大量业务代码，现在只需在网关控制台调整路由规则即可。信号中从单一提供商到企业网关的转变，正是为了解决这类实际落地难点。

合规方面，网关还能统一记录审计日志、数据流向和访问控制，满足等保和数据出境要求。某政务项目在迁移后实现了同一接口同时对接两家国产大模型，根据政策要求动态切换底层引擎，减少了重复开发工作。

多模型路由还带来性能红利。不同模型在不同任务上表现差异明显，网关可以实现智能路由，把代码生成任务发给擅长编程的模型，把对话任务发给更会聊的模型，进一步提升用户体验。

迁移后仍需重构的遗留代码边界

尽管 Bifrost 接管了大量基础设施工作，但并非所有问题都能一次性解决。信号明确指出，迁移后的遗留栈仍存在剩余弱点。

首先是业务层面的 prompt 管理和 Agent 编排逻辑。这些部分仍然紧密耦合在应用代码中，无法完全下沉到网关。团队仍需投入精力重构 prompt 版本控制、A/B 测试和效果评估流程。

其次是复杂工具链的深度集成。虽然网关能统一 tool-use，但高度定制化的企业内部工具调用逻辑可能仍需在应用侧保留适配层。信号中“agents bolt tool-use on however they can”的描述，暗示早期随意实现的工具调用在迁移后仍需逐步规范化。

另外，监控和可观测性也存在边界。网关能提供调用级指标，但端到端的业务成功率、模型输出质量评估仍依赖应用层埋点。国内团队常遇到的情况是，网关显示调用成功，但业务反馈模型回答不符合预期，这部分诊断工作无法完全交给网关。

最后是团队技能的转变。迁移后，开发者需要学习网关的配置语言、路由策略和观测仪表盘，这对纯业务团队构成一定挑战。信号展示的原始迁移输出虽然证明技术可行，但实际落地仍需结合具体业务场景做裁剪。

总体而言，迁移到 AI Gateway 是国内大模型落地的重要一步。它把基础设施问题与业务逻辑解耦，但也提醒我们，遗留系统重构是一个渐进过程，需要持续投入。Bifrost 这样的开源方案降低了门槛，却没有消除所有技术债务。团队应根据自身规模和成熟度，制定分阶段迁移计划，先解决可用性和成本可见性，再逐步优化 Agent 架构和质量控制。

参考来源

• Migrating Legacy LLM Infrastructure to an AI Gateway