你的团队可能已经遇到这些症状：Claude Code 或 Codex 想接本地模型，却要重复修改环境变量；多个供应商共用一套 API，预算、密钥和故障回退却没有统一边界。
最快解法是：企业治理优先选 LiteLLM；编码 Agent 转接本地或开放模型、验证类型化路由时再评估 Switchyard，已有生产网关不要因为项目新颖就直接迁移。
先按团队任务确定候选
本文适合维护企业 LLM Gateway 的平台工程师、需要为 Claude Code 或 Codex 转接其他模型的开发团队，以及正在评估模型路由和成本治理方案的技术决策者。
截至 2026 年 8 月 13 日，本文功能判断以 Switchyard 和 LiteLLM 的官方仓库、官方文档为准。Switchyard 官方仓库当前明确标注为快速演进的实验性项目，并提醒暂不适合生产环境；这不是对代码质量的简单否定，而是你在评估核心网关时必须计入的运维风险。相关信息可核对 Switchyard 官方仓库 与 LiteLLM 官方文档。
两者的定位并不完全相同：
- LiteLLM 更像企业统一 API 层，重点是多供应商接入、鉴权、虚拟密钥、预算、限流、成本统计和通用网关能力。
- Switchyard 更像面向 LLM 流量和编码 Agent 的路由代理，重点是 OpenAI Chat、Anthropic Messages、OpenAI Responses 之间的转换，以及随机路由、分类路由和阶段路由。
因此，这不是简单的功能数量比较，而是看你要解决的是企业接入治理问题，还是Agent 请求如何选择模型的问题。
先核对协议兼容，避免客户端迁移变成业务改造
协议转换是第一道门槛。Switchyard 官方资料明确列出 3 类客户端入口：OpenAI Chat Completions、Anthropic Messages 和 OpenAI Responses，并说明它可以让编码 Agent 保持原生 API 形状，再把请求转发给 vLLM、NVIDIA NIM、Ollama 或其他 OpenAI 兼容端点。详细范围可查看 Switchyard 入门文档。
这对 Claude Code 或 Codex 的意义很直接：你可以优先修改 base_url、模型名和凭证来源，而不是在每个 Agent 项目里重新实现消息格式转换。不过，Switchyard 官方文档也提示，后端格式最好显式设置；如果把 Anthropic 模型误配成 OpenAI Chat 格式，请求可能成功，但某些原生能力，例如 cache_control，可能无法保留。
LiteLLM 的设计更偏向“统一使用 OpenAI 风格输入输出”。官方文档列出它可以把请求转换到 /chat/completions、/responses、嵌入、图像、音频和批处理等端点，并提供统一响应、异常映射和流式调用能力。LiteLLM 的 /responses 文档还说明，该端点可为多个供应商提供回退、负载均衡、成本跟踪和日志能力，但具体字段仍需按模型和供应商验证。
客户端迁移时应这样判断：
- 如果现有应用已经大量使用 OpenAI SDK，LiteLLM 通常更容易作为统一
base_url接入。 - 如果你的主要客户端是 Claude Code、Codex，并且必须保留 Anthropic 或 Responses 的请求形状，Switchyard 的入口设计更贴近这个场景。
- 如果应用依赖工具调用、流式输出、推理字段或供应商特有参数，不要只测普通文本问答，必须逐项回放真实请求。
再拆开路由与故障切换，不要把“会选模型”当成高可用
Switchyard 的路由表达能力是它最有辨识度的部分。官方文档列出随机路由、LLM 分类器路由、基于工具结果和错误信号的 Stage-Router，以及可自定义的路由算法；Stage-Router 还可以在上下文窗口溢出时按配置回退到另一个目标。
这适合编码 Agent，因为 Agent 的请求不是均匀的：探索代码库、处理工具错误和复杂推理，可能需要更强模型；机械改文件、生成测试和格式化，则可以交给成本更低的模型。Switchyard 的阶段路由正是围绕这种 Agent 运行过程设计的。
但企业生产环境更关心另一组问题：
- 供应商返回
429时是否跨部署重试； - 单一模型的多个部署是否能负载均衡；
- 回退后是否保持相同的工具调用语义；
- 路由判断失败时是否有确定的默认模型；
- 多轮对话是否固定到同一路由，避免上下文和缓存失效。
LiteLLM 官方文档明确提供跨部署的重试与回退逻辑，并将代理定位为集中式网关，支持多模型和多部署接入。(LiteLLM 故障回退文档) 这类确定性故障保护，通常比“让一个分类器临时决定去哪台模型”更适合作为企业网关的基础层。
当你的首要指标是稳定接入时，应该偏向哪一侧？ 如果重点是请求能否按业务规则稳定地走到可用供应商，优先 LiteLLM；如果重点是编码 Agent 能否根据任务阶段在强弱模型之间切换，再把 Switchyard 放入旁路实验。
把预算、虚拟密钥和权限单独验收
企业网关最容易被低估的成本，不是代理进程本身，而是治理缺口。没有项目级预算时，一个自动化 Agent 可能持续重试；没有团队级密钥时，供应商凭证会散落在多个仓库和开发机；没有用量归属时，财务只能看到总账单，看不到哪个项目消耗异常。
LiteLLM 官方文档把以下能力直接列为 Proxy Server 的重点：
- 集中式身份验证与授权；
- 按项目或用户进行多租户成本追踪；
- 虚拟密钥；
- 支出和预算管理；
- 速率限制；
- 日志与外部可观测性回调。
LiteLLM 的快速入门配置还展示了 master_key 和 database_url 等网关配置项，这意味着你部署时不能只考虑一个 Python 进程，还要评估密钥、用量和配置数据如何持久化。(LiteLLM Proxy 快速入门)
Switchyard 当前官方公开文档重点放在路由配置、凭证、Agent 启动器、请求统计和 Prometheus 指标上；在我核对到的官方资料中，未见与 LiteLLM 同等明确的虚拟密钥、项目预算、团队角色和多租户支出管理说明。这里不能推断它“未来不会支持”，但在当前选择上，你应把这些能力视为需要外部组件补齐或自行开发，而不是默认已经具备。
⚠️ 经验提醒：官方资料未声明的企业能力，不要用“配置文件里能写模型”来推断。模型路由、身份治理和财务审计属于不同层，前者存在并不代表后两者已经解决。
多团队预算管理更适合放在哪一层？ 如果你需要项目密钥、团队归属、支出统计和预算限制，LiteLLM 的官方能力边界更清楚；如果你只是做单团队的 Agent 路由实验，则不必为了预算功能引入复杂治理层，但生产化前仍需补齐审计和权限设计。
再检查日志和审计边界，尤其是 Agent 输入输出
可观测性不能只看“服务是否返回 200”。你至少要记录请求延迟、供应商、模型别名、输入输出 Token、重试次数、回退原因、路由决策和最终成本。
Switchyard 官方仓库明确提到 Prometheus 指标覆盖请求、错误、延迟、Token 和路由开销；其文档也提供按模型和 tier 汇总的统计接口。这足以支持路由实验和成本趋势分析，但你仍需确认指标是否满足企业审计、用户归属和长期报表要求。
LiteLLM 则提供日志回调、成本追踪、用量和延迟统计，并支持对接外部观测系统。官方文档同时给出了 Proxy 的鉴权、日志、成本追踪和限流入口。(LiteLLM 可观测性文档)
这里有一个容易遗漏的限制：Agent 请求可能包含源代码、终端输出、内部 URL、访问令牌或客户数据。无论选哪一个代理，你都需要在上线前决定：
- 是否记录完整 Prompt 和响应；
- 是否只记录元数据，不保存正文；
- 脱敏发生在代理前还是日志回调中；
- 谁能查询团队级请求日志；
- 失败重试时，敏感内容是否会再次发送给另一家供应商。
如果这些问题没有书面答案，先不要把生产代码库接入统一日志。
按部署方式估算长期运维，而不是只看安装命令
Switchyard 的上手路径相对清晰：官方文档要求 Python 3.12 或更高版本，支持 macOS、Linux 和 Windows，并提供安装、配置、服务模式、Agent 启动器和嵌入式 Python 运行方式。但它的快速迭代意味着你需要固定版本、锁定路由配置、维护回归请求集，并为 API 变化准备回滚方案。
LiteLLM 同样可以通过 Python 包、CLI 或容器部署。官方快速入门展示了代理容器、配置文件、数据库连接和 OpenAI 兼容客户端接入方式。(LiteLLM 部署文档) 它的优势是企业网关能力更集中，代价是依赖项和配置面更大：数据库、密钥、日志、限流和高可用都需要纳入值班手册。
你的上线验收至少分为 5 步：
- 固定两套代理版本，并保存完整配置和依赖锁文件。
- 用 OpenAI Chat、Anthropic Messages、Responses 以及流式工具调用分别回放真实请求。
- 人工制造
401、429、超时、上下文溢出和供应商不可用，确认重试与回退结果。 - 为每个团队创建独立凭证或项目标识，验证预算、速率限制和日志归属。
- 连续观察一段非生产流量，核对模型选择、Token、成本、延迟和错误日志，再决定是否承接主流量。
用条件分支做最终选择
你可以直接按下面的决策条件执行，不需要先争论哪个项目“更先进”。
- 若你需要多供应商统一接入、虚拟密钥、项目预算、团队用量统计和权限边界，则选 LiteLLM。
- 若你已经有稳定的 LiteLLM 生产系统，且当前没有明确的协议、路由或 Agent 接入缺口，则继续使用 LiteLLM，不迁移。
- 若你的重点是让 Claude Code 或 Codex 接入本地模型、开放模型或自建推理端点，则旁路评估 Switchyard。
- 若你要研究随机路由、分类器路由或 Stage-Router 这类类型化流程，则用真实请求回放验证 Switchyard，但不要直接让它接管核心网关。
- 若你需要长期审计、预算封顶、团队权限和稳定运维，却没有额外平台工程资源，则回退到 LiteLLM。
- 若你只需要单模型透传，而且客户端和后端协议完全一致，则两者都可能过重，直接使用现有供应商兼容层更简单。
Switchyard 是否适合直接接管现有网关？ 在编码 Agent 的局部转接场景中，它可能承担一部分代理职责；在企业统一 API、预算治理和多团队管理场景中，当前公开官方资料不足以支持整体替换判断。更稳妥的做法是让 Switchyard 先作为旁路路由器存在，而不是直接替换主入口。
已有 LiteLLM 系统是否值得立即迁移？ 如果当前生产系统能够满足协议转换、供应商回退、预算、虚拟密钥和审计要求，就没有足够理由仅凭项目热度迁移。只有当真实请求回放证明 Switchyard 在你的编码 Agent、开放模型或阶段路由场景中解决了明确缺口，迁移讨论才有实际依据。
给企业团队的迁移结论
如果你正在建设第一套企业 LLM Gateway，LiteLLM 更适合作为主候选，因为它直接覆盖多供应商接入、鉴权、预算、限流、成本和可观测性这些平台团队必须维护的边界。
如果你正在解决编码 Agent 接入本地模型的问题，Switchyard 值得做一次受控验证，尤其是你希望保留客户端原生协议，并尝试按 Agent 阶段选择强弱模型。但请把“路由实验有效”与“企业网关已经成熟”分开验收。
现实中，当前方案通常有两类缺点：直接让每个应用分别接供应商，会造成凭证分散、预算不可归属和故障处理重复；直接在本地工作站运行实验，又容易受到环境差异、端口暴露、后台进程和团队协作限制。你可以先通过 Macstripe 帮助中心了解远程环境的连接与使用边界，再按验证周期选择临时或持续的 Mac 算力，用独立环境承载旁路代理、真实请求回放和日志检查，而不干扰现有生产网关。需要直接准备测试环境时，可查看 Macstripe 配置订单。
最后更新于 2026 年 8 月 13 日；协议、路由、鉴权、预算、存储和部署判断已根据 Switchyard 与 LiteLLM 官方资料核实。任一项目发布重大版本或改变配置方式后，都应重新执行同一套对比和旁路验收。
