多模型Agent在真实业务里最大的麻烦不是模型本身，而是调用路径分散。OpenAI、Anthropic、本地vLLM、Azure OpenAI各自有一套鉴权头、请求体和错误码，Agent代码里经常塞满条件判断和重试逻辑。把这些差异收口到一个统一API网关，业务侧只和标准OpenAI接口打交道，是更可控的做法。LiteLLM正好承担这个角色，它既是一个Python库，也能作为独立代理服务器运行，把多模型调用集中管理起来。

本文假设你已经有一个需要调用多个厂商模型的Agent项目，并且希望把模型切换、容灾、限流从业务代码里剥离出来。接下来会从核心能力、部署方式、模型组路由以及Agent动态切换几个角度完整说明落地思路。

一、LiteLLM网关解决了哪些具体问题

先把LiteLLM定位清楚。它不是一个模型训练框架，也不是编排工具，而是一个代理层。你在Agent里不再直接保存OpenAI、Anthropic等厂商的密钥，而是把请求发给LiteLLM网关，由网关根据模型名找到对应厂商、完成鉴权、发送请求并解析响应。对上层来说，所有模型都长得像OpenAI的Chat Completions接口。

这样做有三点直接收益。第一是统一协议，接入新模型只改网关配置，不改业务代码。第二是集中治理，密钥、速率限制、预算上限、日志记录都在一个地方控制。第三是故障转移，某个模型超时或者触发限流，网关可以自动切换备用模型，Agent无需感知。尤其在多模型Agent里，任务可能从代码生成切到长文档总结再到工具调用，不同任务适合不同模型，集中路由比在Agent内部写切换逻辑清晰得多。

LiteLLM支持100多种模型，包括OpenAI、Anthropic、Gemini、Azure OpenAI、Bedrock、Hugging Face以及本地vLLM、Ollama等。它还提供OpenAI兼容的/v1/chat/completions、/v1/embeddings、/v1/completions等端点，因此现有的openai Python客户端几乎可以零成本接入。

二、快速部署一个LiteLLM网关

最常用的部署方式是使用pip安装LiteLLM并启动代理服务。你需要一个Python 3.9以上环境，执行以下命令即可完成基础安装。

pip install 'litellm[proxy]'

安装完成后，准备一个YAML配置文件。这个文件是网关的核心，里面列出模型清单和路由策略。下面给出一份最小配置，包含OpenAI的gpt-4o和Anthropic的claude-sonnet两个模型。

model_list:
  - model_name: gpt-4o
    litellm_params:
      model: openai/gpt-4o
      api_key: os.environ/OPENAI_API_KEY
  - model_name: claude-sonnet
    litellm_params:
      model: anthropic/claude-sonnet-4-20250514
      api_key: os.environ/ANTHROPIC_API_KEY

配置中model_name是网关对外暴露的模型名，业务侧调用时使用这个名字。litellm_params.model指定真实厂商模型标识，前缀openai/或anthropic/用来告诉LiteLLM走哪个适配器。api_key写成os.environ/OPENAI_API_KEY表示从环境变量读取，不要明文写入配置文件。启动前先设置对应的环境变量。

然后启动网关：

litellm --config config.yaml --port 4000

服务起来后，访问http://127.0.0.1:4000可以看到简单状态页。用curl或Python客户端即可测试。下面用openai库测试刚配置的模型。

from openai import OpenAI
client = OpenAI(
    base_url="http://127.0.0.1:4000/v1",
    api_key="sk-litellm-gateway"
)
response = client.chat.completions.create(
    model="gpt-4o",
    messages=[
        {"role": "system", "content": "你是自动化运维助手"},
        {"role": "user", "content": "检查服务器负载并给出建议"}
    ],
    temperature=0.3
)
print(response.choices[0].message.content)

注意base_url要指向网关的/v1路径，api_key可以随便填，除非你在网关配置里额外设置了虚拟密钥校验。对于内网调试，这样最简单。生产环境建议通过LiteLLM的密钥管理功能给每个业务方分配独立key。

三、用模型组和路由策略管理多模型调用

单个模型接入后，真正体现网关价值的是模型组。模型组把多个模型放在一个逻辑名称下，调用方只关心model为某个组名，由网关决定这次请求落到哪一个模型。LiteLLM支持多种路由策略，包括简单轮询、随机、按用量加权、基于延迟等。

例如你可以把gpt-4o、claude-sonnet和一个本地部署的qwen3放在同一组，使用usage-based-routing-v2按token成本和可用性动态平衡。配置如下。

model_list:
  - model_name: gpt-4o
    litellm_params:
      model: openai/gpt-4o
      api_key: os.environ/OPENAI_API_KEY
      rpm: 100
      tpm: 100000
  - model_name: claude-sonnet
    litellm_params:
      model: anthropic/claude-sonnet-4-20250514
      api_key: os.environ/ANTHROPIC_API_KEY
      rpm: 80
      tpm: 80000
  - model_name: qwen3-local
    litellm_params:
      model: openai/qwen3-8b
      api_base: http://127.0.0.1:8000/v1
      api_key: none
router_settings:
  routing_strategy: usage-based-routing-v2
  allowed_fails: 2
  cooldown_time: 30
  num_retries: 2
  timeout: 60

router_settings里的几个参数值得专门说明。allowed_fails表示模型连续失败多少次后进入冷却；cooldown_time是冷却秒数；num_retries是网关内部重试次数；timeout控制单次请求超时。设置为allowed_fails为2、cooldown_time为30，意思是某个模型连续两次失败后，网关会把它暂时移出可用列表，30秒后再尝试恢复。这样当gpt-4o突发限流时，Agent请求会自动转到其他模型。

模型组的另一个好处是可以按成本做路由。你可以给不同模型设置不同的成本权重，让网关优先使用价格更低的模型，高成本模型只作为兜底。这样既能控制整体费用，又不会牺牲可用性。在Agent频繁调用模型的场景里，成本控制往往比单次响应速度更关键。

四、在Agent工作流中实现动态模型切换

即使有网关做底层的自动路由，Agent有时仍然需要根据任务类型主动选择模型。比如代码生成任务希望优先Claude，长文档总结希望优先Gemini。此时可以将模型组拆得更细，或者让Agent传入不同模型组名。下面给出一段简单示例，Agent根据任务标签选择不同模型组，并保留失败重试能力。

from openai import OpenAI
client = OpenAI(
    base_url="http://127.0.0.1:4000/v1",
    api_key="sk-litellm-gateway"
)
def route_task(task_type):
    if task_type == "code":
        return "code-agent-group"
    elif task_type == "summary":
        return "summary-agent-group"
    else:
        return "general-agent-group"
def run_agent(task_type, content):
    model = route_task(task_type)
    response = client.chat.completions.create(
        model=model,
        messages=[
            {"role": "system", "content": "你是多模型Agent助手"},
            {"role": "user", "content": content}
        ]
    )
    return response.choices[0].message.content
print(run_agent("code", "写一个Python快速排序"))

这段代码把模型选择逻辑集中在一个函数里，Agent只暴露任务类型和内容。网关收到请求后，仍会在模型组内部进行负载均衡和故障转移。这样业务侧只需要关心任务与模型组的映射，不需要接触厂商SDK，也不需要在代码里保存任何厂商密钥。

如果希望更细粒度地控制，可以在LiteLLM请求里传递额外参数，例如temperature、max_tokens、response_format等，这些参数会原样透传给目标模型。对于不支持某些参数的模型，LiteLLM会做兼容处理或直接报错，你可以在配置中通过drop_params为true忽略不支持的参数，减少跨模型调用时的适配成本。

五、生产环境中的安全与可观测性

把网关放到Agent调用链里后，安全问题要重点处理。网关服务器上只保存一套厂商密钥，所有转发由网关完成。业务服务使用LiteLLM生成的虚拟密钥访问网关，这样即使某个业务侧key泄露，也只影响它自己的配额，不会暴露上游厂商密钥。配置虚拟密钥可以在启动时通过环境变量LITELLM_MASTER_KEY设置管理员密钥，再用管理接口创建。

litellm generate_key --key_name agent-service

日志和成本追踪是另一个生产必需能力。LiteLLM会把每次请求的模型、token数量、延迟、费用记录到日志或数据库中。你可以在启动参数里加--detailed_debug查看调试信息，也可以接入Prometheus、Langfuse等工具。对于多模型Agent，知道每个任务实际调用了哪个模型、花了多少钱，才能做后续优化。

最后提醒一点：网关本身也可能成为单点。如果Agent服务与网关部署在同一内网，延迟通常可以接受；但如果跨地域，建议把网关与业务服务放在同一集群，并为网关配置多副本和健康检查。LiteLLM支持通过Redis实现多实例共享路由状态，避免多个网关副本各自计算冷却和失败次数。