多协议支持实战：用 LiteLLM 让一个模型同时讲 OpenAI、Responses 和 Anthropic 三种“方言”并接入 TaoToken

1. 为什么需要给一个模型配三种“方言”你可能遇到过这种局面本地跑着一个模型OpenAI 兼容接口用得好好的结果想接 Claude Code它张口就要 Anthropic Messages 协议换 Codex CLI它又只认 OpenAI Responses 协议。模型只有一个客户端却各说各话总不能给每个客户端单独部署一套服务。LiteLLM 的定位就是这层“协议翻译官”。它对外同时暴露 OpenAI Chat Completions、OpenAI Responses、Anthropic Messages 三种接口风格对内统一转成 OpenAI 兼容请求打到你的模型端点。本文把上游换成 TaoToken 的 API 通道这样你不需要本地显卡也能让同一个模型按三种方言被调用并且返回结构各自正确。适合谁看手里有只认某一种协议的客户端Claude Code、Codex CLI、原生 Anthropic SDK又想统一走一个 Key、一个模型名的开发者。读完你能拿到一份可复制的 config.yaml、三条路由的 curl 验证命令以及几个我实际踩过的版本坑。核心检索词先摆出来LiteLLM 多协议、OpenAI Responses、Anthropic Messages、TaoToken 接入。下面从架构落点讲起。2. TaoToken 前置Key、API 地址与模型名TaoToken 在这里扮演的是上游模型通道。LiteLLM 不直接连模型而是把请求转发到 TaoToken 的 API 地址由它完成鉴权和模型调度。你需要准备三样东西。第一是 API Key。到控制台的 API Keys 页面创建形如sk-开头的一串字符。这个 Key 同时会作为 LiteLLM 的 master_key客户端拿它来鉴权。第二是 API 地址。TaoToken 的 API 根地址是https://taotoken.net/apiOpenAI 兼容端点在它后面加/v1也就是https://taotoken.net/api/v1。Anthropic 风格请求也走同一个根LiteLLM 会自动处理路径差异。第三是模型名。在模型对话页面能看到当前可用的模型标识比如claude-sonnet-4-5这类。你在 config.yaml 里把它写成openai/模型名前缀告诉 LiteLLM 用 OpenAI 兼容方式去请求。提示Key 不要写死在配置文件里用os.environ/从环境变量读避免提交到仓库泄露。控制台里可以随时轮换 Key。如果你还没建 Key先去 API Keys 页面生成一个想先确认模型能不能通可以在模型对话页面直接发一条消息试试。这两步做完再往下配 LiteLLM能省掉一半排障时间。3. 可复制配置config.yaml 骨架与三种协议路由先装 LiteLLM。建议用独立虚拟环境避免污染系统 Python。python3 -m venv ~/litellm-venv ~/litellm-venv/bin/pip install -i https://pypi.tuna.tsinghua.edu.cn/simple \ litellm[proxy] fastapi0.115.12 sse-starlette2.2.1这里锁了两个版本原因在排障章节展开。装完写配置文件~/litellm_config.yamlmodel_list: - model_name: claude-sonnet-4-5 litellm_params: model: openai/claude-sonnet-4-5 api_base: https://taotoken.net/api/v1 api_key: os.environ/TAOTOKEN_API_KEY - model_name: gpt-4o-mini litellm_params: model: openai/gpt-4o-mini api_base: https://taotoken.net/api/v1 api_key: os.environ/TAOTOKEN_API_KEY general_settings: master_key: os.environ/TAOTOKEN_API_KEY litellm_settings: drop_params: truemodel_name是对外暴露的名字客户端请求里写它litellm_params.model里的openai/前缀表示用 OpenAI 兼容协议转发api_base指向 TaoToken。drop_params: true让 LiteLLM 丢弃后端不认识的参数而不是直接报错接不同客户端时很关键。启动代理export TAOTOKEN_API_KEYsk-你的key ~/litellm-venv/bin/litellm --config ~/litellm_config.yaml \ --host 0.0.0.0 --port 8090启动后 LiteLLM 默认在 8090 端口同时提供三套路由/v1/chat/completionsOpenAI Chat、/v1/responsesResponses、/v1/messagesAnthropic Messages。Anthropic 客户端习惯把路径写成/anthropic/v1/messages如果你前面挂了 nginx可以用前缀剥离把/anthropic/去掉再转发到 8090LiteLLM 本身只认/v1/messages。三种协议的路由对照如下协议客户端请求路径LiteLLM 内部路径返回结构OpenAI Chat/v1/chat/completions同左choices[].messageOpenAI Responses/v1/responses同左output[]事件流Anthropic Messages/v1/messages同左content[]块4. 验证请求三条 curl 与返回结构配置完别急着接客户端先用 curl 把三条路径各打一遍确认返回结构正确。OpenAI Chat Completionscurl https://你的域名/v1/chat/completions \ -H Authorization: Bearer $TAOTOKEN_API_KEY \ -H Content-Type: application/json \ -d { model: claude-sonnet-4-5, messages: [{role: user, content: 用一句话说明什么是协议翻译}] }返回里应该有choices[0].message.content这是标准 OpenAI 结构。OpenAI Responsescurl https://你的域名/v1/responses \ -H Authorization: Bearer $TAOTOKEN_API_KEY \ -H Content-Type: application/json \ -d { model: claude-sonnet-4-5, input: 用一句话说明什么是协议翻译 }注意 Responses 协议用的是input而不是messages。返回是output数组流式时能看到response.created、response.output_text.delta这类事件。Anthropic Messagescurl https://你的域名/v1/messages \ -H x-api-key: $TAOTOKEN_API_KEY \ -H anthropic-version: 2023-06-01 \ -H Content-Type: application/json \ -d { model: claude-sonnet-4-5, max_tokens: 1024, messages: [{role: user, content: 用一句话说明什么是协议翻译}] }Anthropic 用x-api-key头而不是 Bearer返回是content[]块数组每块有type字段。max_tokens是必填项别漏。三条都返回 200 且结构对得上说明多协议适配层通了。实测下来同一把 Key、同一个模型名三种方言都能正常出结果。5. 本篇常见错排查启动即 ImportError提示找不到get_flat_dependant。这是 LiteLLM 与新版 fastapi 不兼容。新版 fastapi 移除了这个内部函数而 LiteLLM 还在引用。锁fastapi0.115.12即可。锁了 fastapi 后 SSE 流式异常。旧 fastapi 会把 starlette 拉到较低版本而新版 sse-starlette 要求更高版本 starlette两者冲突。再锁sse-starlette2.2.1对齐流式就正常了。Anthropic 请求返回 500 而不是 401。无 Key 或 Key 错误时LiteLLM 在 Anthropic 路由上可能返回 500 而非标准的 401。这是它的行为特点不代表配置错。检查 Key 是否正确即可。Anthropic 返回 content 为空数组。多半是max_tokens给太小。模型把预算全花在思考内容上可见输出被挤没了。客户端给到 1024 以上通常正常。Responses 请求报参数错误。检查是不是把messages写成了input的反面——Responses 用inputChat 用messages两者不能混。客户端连不上但 curl 能通。大概率是路径前缀问题。Anthropic 客户端默认拼/v1/messages如果你在 nginx 上做了/anthropic/前缀要确认剥离规则生效否则请求打到错误路径。6. 客户端接入与后续Claude Code 走 Anthropic 协议ANTHROPIC_BASE_URLhttps://你的域名 \ ANTHROPIC_AUTH_TOKEN$TAOTOKEN_API_KEY \ ANTHROPIC_MODELclaude-sonnet-4-5 \ claudeCodex CLI 走 Responses 协议OPENAI_BASE_URLhttps://你的域名/v1 \ OPENAI_API_KEY$TAOTOKEN_API_KEY \ codex -m claude-sonnet-4-5原生 Anthropic SDKimport anthropic client anthropic.Anthropic( base_urlhttps://你的域名, api_keysk-你的key, ) resp client.messages.create( modelclaude-sonnet-4-5, max_tokens1024, messages[{role: user, content: hi}], ) print(resp.content)一个实用建议如果客户端本身支持多种协议优先走原生 Chat Completions少一层翻译思考内容无损。Anthropic 和 Responses 入口是留给那些只认单一协议的客户端的。长期跑编码任务或 Agent 的话可以了解下 Coding Plan它针对高频调用场景做了额度优化。接入过程中遇到鉴权或路由问题接入文档里有更细的路径说明想先验证模型效果模型对话页面可以直接试。Key 管理和轮换在控制台的 API Keys 页面完成。配置本身不复杂坑主要集中在依赖版本和路径前缀两处。把这两点处理掉一个模型讲三种方言就是一份 config.yaml 的事。