前言最近我一直在做一件事既然Codex CLI已经可以通过LiteLLM接入Azure GPT-5.4那能不能进一步把Claude Code也打通让两套 CLI 共用同一层代理、同一组模型别名、同一套启动方式更重要的是这个过程不能只做到“能聊”而是要尽量保留 Claude Code 的工程能力比如代码读取、编辑、搜索以及可用的 MCP 工具。最终结果是可以而且不需要长期维护一层自建的 Anthropic shim。Claude Code 直接走 LiteLLM 的 Anthropic-compatible/v1/messages即可。真正的难点不在模型而在工具 schema 的兼容性治理。一、先说结论最终落地方案是什么先把结论放前面方便只想看结果的同学快速判断这套方案是否值得继续看下去。最终我们打通的是这样一条链路Codex CLI ─┐ ├─ LiteLLM Proxy :4000 ── Azure OpenAI GPT-5.4 Claude Code ──┘对应关系如下Codex CLI继续走 OpenAI 兼容入口Claude Code改为直连 LiteLLM 的 Anthropic-compatible/v1/messages统一模型别名为gpt54Claude Code 不再加载全量 MCP而是采用工具白名单 MCP 白名单一句话总结就是Codex 和 Claude 可以共用一个 LiteLLMGPT-5.4 作为统一模型中枢Claude Code 的核心内置工具可用真正需要处理的是少量不兼容的 MCP。没必要长期维护一层自建协议网关Claude Code 能接 Azure GPT-5.4重点不是模型兼容而是工具兼容白名单治理比“全量兼容”更适合作为第一阶段落地方案二、为什么要把 Codex CLI 和 Claude Code 放到同一条链路里这么做的核心目的不只是“图省事”而是为了把日常 AI 开发环境真正统一起来。统一之后你能得到几个很现实的收益模型治理统一客户端不再各配各的模型和 Key统一交给 LiteLLM切换成本更低以后想换模型优先改 LiteLLM 配置而不是分别改 Codex / Claude启动方式统一无论用 Codex 还是 Claude心智都变成“先起代理再起客户端”环境可迁移换电脑后只要恢复一套配置就能把整套链路带回来这背后其实是在做一件很工程化的事把“多个 AI CLI 多个模型供应商 多套协议入口”收束成一层统一代理。这也是我这次实践里真正觉得有价值的地方。三、一开始为什么会走弯路最开始最自然的想法是自己在 Claude Code 和 LiteLLM 中间再加一层 Anthropic-compatible GatewayClaude Code ↓ 自建 Anthropic-compatible Gateway ↓ LiteLLM ↓ Azure GPT-5.4从直觉上看这个思路很合理Claude Code 说 Anthropic 风格协议LiteLLM 再帮我们转给 Azure中间有不兼容的地方就自己补一层而且这条路短期内确实能跑通。当时做了一个最小原型services/claude-gateway.mjsPOST /v1/messagesPOST /v1/messages/count_tokensSSE 文本流转发这个原型用curl是能打通的所以一开始很容易让人误以为方向对了继续补细节就行。但问题在于“能跑通”不等于“适合长期维护”。真正接入 Claude Code CLI 之后很快就会发现这条路的问题Claude Code 并不会因为几个猜测性的环境变量就稳定切换到你自建的 shim即便短期能用长期也要自己维护一整套 Anthropic 兼容细节这些细节不只是普通 HTTP 转发还包括headersSSE 事件格式错误结构count_tokenstool use / tool resultLiteLLM 本身已经具备多协议代理能力再叠一层长期 shim只会让链路越来越复杂所以回头看这条路的问题不是“完全走不通”而是它更适合技术验证不适合作为长期方案。四、真正更稳的方案让 Claude Code 直接连 LiteLLM 的/v1/messages后面我调整思路直接对 LiteLLM 发起 Anthropic 风格请求验证它自己的/v1/messages能不能承接 Claude 风格消息。测试命令大致如下curl http://127.0.0.1:4000/v1/messages \ -H Content-Type: application/json \ -H x-api-key: sk-proxy \ -H anthropic-version: 2023-06-01 \ -d { model: gpt54, max_tokens: 128, messages: [ {role: user, content: reply with only: litellm-ok} ] }结果直接返回litellm-ok这一步其实就是整个方案的转折点。它证明了两件事LiteLLM 本身已经能暴露 Anthropic-compatible/v1/messagesClaude Code 理论上没必要再经过一层自建长期网关也就是说真正更合理的链路应该是Claude Code ↓ LiteLLM /v1/messages ↓ Azure GPT-5.4从工程角度说这个调整非常关键。因为一旦走这条路后面要解决的问题就从“协议伪装”变成了“协议内的具体兼容项”复杂度会下降很多。一句话概括就是不是再造一层 Anthropic API而是直接复用 LiteLLM 已有的 Anthropic-compatible 能力。五、统一代理层架构Codex 走 OpenAIClaude 走 Anthropic把思路理顺之后整个架构就很清晰了Codex CLI -- LiteLLM OpenAI-compatible /v1 -- Azure OpenAI GPT-5.4 Claude Code -- LiteLLM Anthropic-compatible /v1/messages -- Azure OpenAI GPT-5.4可以把这几层理解成下面这样层级职责说明Codex CLIOpenAI 风格客户端通过base_urlhttp://127.0.0.1:4000/v1访问 LiteLLMClaude CodeAnthropic 风格客户端通过ANTHROPIC_BASE_URLhttp://127.0.0.1:4000访问 LiteLLMLiteLLM多协议统一代理层同时暴露 OpenAI 兼容入口和 Anthropic-compatible/v1/messagesAzure OpenAI实际推理服务最终执行gpt-5.4这套架构最大的价值是客户端协议差异保留在客户端这一层模型路由和供应商接入收敛到 LiteLLM后续扩模型时优先改代理层不动客户端层这会让整套环境越来越稳定而不是越来越碎片化。六、LiteLLM 的模型配置怎么统一核心配置我放在~/litellm_config.yaml通过模型别名把底层供应商细节藏起来。示例配置如下general_settings: master_key: sk-proxy litellm_settings: drop_params: true model_list: - model_name: gpt54 litellm_params: model: openai/gpt-5.4 api_base: https://你的azure资源.openai.azure.com/openai/v1 api_key: 你的Azure_Key - model_name: gemini litellm_params: model: gemini/gemini-3.1-pro-preview api_key: 你的Gemini_Key这里有三个关键点1. 用模型别名统一客户端配置gpt54是统一模型别名。这意味着Codex 调的是gpt54Claude Code 调的也是gpt54底层到底是 Azure、OpenAI 还是别的供应商不让客户端关心2.drop_params: true很重要这项配置的价值在多客户端接入时非常明显。因为不同客户端会带上不同参数而底层模型供应商未必全部支持。开启drop_params: true后LiteLLM 会尽量过滤掉后端不支持的字段减少因为协议差异导致的 4xx。3. LiteLLM 成为真正的“模型路由层”从这一步开始模型选择就不再分散在各个客户端里了而是统一收敛到 LiteLLM。这对后续扩展很有帮助比如增加新的模型供应商调整模型默认值给不同团队做不同模型别名统一统计和治理调用方式七、真正的阻塞点不是模型而是工具 schema当 Claude Code 真正通过 LiteLLM 打到 Azure GPT-5.4 之后我遇到的第一个关键报错是Invalid schema for function mcp__pencil__get_style_guide_tags object schema missing properties invalid_function_parameters这个错误非常有信息量因为它说明Claude Code 到 LiteLLM 的链路已经通了LiteLLM 到 Azure GPT-5.4 的模型调用也通了真正失败的不是“模型不行”而是工具定义的 schema 在这条函数调用链路上不兼容这一点很容易被误判。很多人看到 Claude Code 调用失败第一反应会以为是不是 Claude Code 不能接 Azure是不是 LiteLLM 的 Anthropic 兼容有问题是不是消息格式有坑但实际排查到这里结论反而很清楚主链路已经通了真正的阻塞点转移到了工具 schema。八、为什么工具 schema 会成为问题Claude Code 默认会自动附带两类工具内置工具BashEditReadWriteGrepGlob等等本地 MCP server 暴露出来的工具问题就出在第二类。某些 MCP server 的 JSON Schema在 Anthropic 原生链路里没有问题但进入 Azure / OpenAI 这类函数参数校验更严格的链路后会出现兼容失败。所以到这里问题的本质就从“Claude Code 能不能迁移”变成了“Claude Code 的哪些工具能迁移”“哪些 MCP server 需要隔离”“哪些高价值 MCP 值得单独做 schema 兼容层”这一步很重要因为它意味着策略要变。不是追求一上来全量无损迁移而是先收敛到稳定可用的最小集合。这也是后来白名单策略的出发点。九、工具能力的真实边界哪些能用哪些要隔离为了把问题收敛清楚我把 Claude Code 的能力拆成三层逐步验证。1. 无工具、纯推理模式可用在禁用工具、禁用 MCP 的情况下Claude Code 可以成功返回claude-litellm-ok这一步说明GPT-5.4 作为 Claude Code 的推理模型是成立的主路径没有问题问题并不在“Claude Code 接 Azure GPT-5.4 这件事本身”2. Claude Code 核心内置工具可用经过白名单验证以下内置工具可以稳定使用BashEditReadWriteGlobGrepLSMultiEditNotebookReadNotebookEditWebFetchWebSearch这意味着 Claude Code 在这条链路下并没有退化成一个“只能问答”的工具而是仍然保留了相当重要的工程能力。3. MCP部分可用当前验证结果是可保留playwright需要隔离pencil所以最终的工程形态其实可以概括成Claude Code GPT-5.4 内置工具白名单 白名单 MCPplaywright - 问题 MCPpencil这个结果非常关键。因为它说明我们拿到的不是一个“残缺版 Claude Code”而是一个已经能进入真实工程工作流的版本。十、最终可落地的运行方式把协议和工具问题都收敛之后整个方案就能落到日常使用方式上了。1. LiteLLM 启动脚本统一脚本scripts/start-litellm.sh我给它做了一个最短命令入口llm2. Claude Code 启动脚本统一脚本scripts/cc-gpt54.sh最短命令Claude_new这个脚本会自动完成几件事指向ANTHROPIC_BASE_URLhttp://127.0.0.1:4000使用ANTHROPIC_MODELgpt54保留内置工具白名单严格只加载.claude/mcp-gpt54.json3. Codex 启动方式Codex 这边保持原有习惯即可codex codex -m gpt54 codex -m gemini我同样给它做了一个更省事的入口codex_new十一、统一后的使用心智真的会顺手很多这套方案最终最让我满意的不只是“打通了”而是它把日常使用方式也统一了。现在实际操作很简单终端 1启动代理llm终端 2启动客户端如果你要用 Codexcodex_new如果你要用 Claude CodeClaude_new到这一步整个环境的心智模型已经非常清晰同一个 LiteLLM同一个模型别名gpt54同一个 Azure GPT-5.4不同的只是你想用 Codex 还是 Claude Code 作为前端 CLI这种统一感在日常开发里其实非常重要。因为当你切客户端时你不会再有“我是不是还要换一套配置”的负担。十二、为什么还要再抽一个ai-cli-kit当脚本、配置、白名单文件越来越多之后我很快意识到一个问题如果这些东西都散落在业务仓库里下一次换电脑时还是得重新回忆一遍。所以后面我把核心能力抽成了一个更适合复用的目录形态packages/ai-cli-kit/ bin/ templates/ docs/这样做的目标很明确未来可以单独放成一个 GitHub 仓库换电脑后只需要拉这个仓库填入自己的 Azure / Gemini / Anthropic Key一键生成llm/codex_new/Claude_new一键生成~/litellm_config.yaml、~/.claude/settings.json和白名单 MCP 配置换句话说真正想做的不是“这台电脑终于配好了”而是把一次人工调试沉淀成一套可复制、可迁移、可恢复的工具化方案。这对长期使用来说比单次跑通更有价值。十三、Phase 1 实际完成了什么目前第一阶段已经落地的内容如下验证 Codex 通过 LiteLLM 使用 Azure GPT-5.4验证 LiteLLM 的/v1/messagesAnthropic 兼容入口可用验证 Claude Code 通过 LiteLLM 使用 Azure GPT-5.4验证无工具模式可用验证核心内置工具白名单可用确认pencilMCP 是主要 schema 阻塞项产出.claude/mcp-gpt54.json白名单配置产出llm / codex_new / Claude_new三个极简命令抽离packages/ai-cli-kit作为外部仓库基础骨架这意味着第一阶段的目标已经不是“证明可行”而是进入了“可持续使用”的状态。十四、当前边界与下一步怎么做当然这套方案现在也不是完全终态它还有清晰的边界。当前已经实现的部分GPT-5.4 已经成功作为 Codex / Claude 的统一模型中枢Claude Code 的核心内置工具已经保留Playwright MCP 已经可以继续使用问题被收敛到少数不兼容 MCP而不是整个平台不可用当前还没完全解决的部分还没有做到“全量 MCP 无损迁移”还没有为每个 MCP server 自动做 schema sanitizer下一步更正确的方向在我看来接下来真正值得做的不是继续堆复杂网关而是逐个审计 MCP server 的 schema将不兼容的 server 加入隔离名单对高价值 MCP 单独补兼容层将packages/ai-cli-kit独立成外部仓库支持一键初始化环境这条路线的好处是复杂度是可控增长的。你不会因为追求“一次性全兼容”把系统重新拖回高复杂度状态。十五、总结这次实践真正解决了什么这次实践的价值不只是“又多写了几个脚本”而是把一个看似很乱的问题收束成了一套稳定范式一个 LiteLLM 一组模型别名 两类 CLI 客户端 一套统一启动方式 一套逐步扩展的工具白名单治理策略对于 Codex 来说LiteLLM 是 OpenAI 兼容代理。对于 Claude Code 来说LiteLLM 是 Anthropic-compatible 网关。对于 Azure GPT-5.4 来说它成为了两边共享的统一推理核心。而从工程管理视角看最重要的成果其实是这句这套方案开始摆脱“靠记忆手调”的状态进化成了一个可迁移、可复制、可在下一台电脑上一键恢复的工具化方案。如果你也在折腾多 AI CLI、多模型供应商、多协议入口的统一接入希望这篇文章能帮你少走一点弯路。因为很多时候真正的问题不在于“模型能不能接”而在于协议要不要自己维护工具链该不该全量放开哪些问题应该靠治理而不是靠继续堆中间层把这几个问题想清楚方案就会变得简单很多。当前仓库地址GitHubhttps://github.com/17713679014/ai-cli-kit