这段时间总有人来问我同一个问题Claude Code 和 Codex 到底怎么配配完之后怎么才能接上 DeepSeek 这类第三方模型一个是 Anthropic 官方的终端编程助手一个是 OpenAI 官方的命令行 Agent两个工具我都从零开始折腾过中间踩了不少坑配置文件和报错信息也看了个遍。这篇指南就从官方安装、登录开始讲再到接第三方模型的完整配置方法最后把几个高频报错的排查链路拆开揉碎希望能帮刚入手的朋友省下几天的摸索时间。1. 两个工具到底各管什么先想清楚你的真实需求1.1 定位差异Claude Code 偏向结对编程Codex 偏向自主 AgentClaude Code 是 Anthropic 推出的终端工具核心玩法是在命令行里和 AI 结对编程。你让它读代码库、生成新文件、跑测试、解释报错它都有对应的动作。它默认走的是 Claude 系列模型上下文窗口大处理多文件变更和长上下文的时候表现比较稳所以很多人在做跨文件重构时喜欢用它。Codex 则是 OpenAI 的 CLI 产品工作方式更像一个 Agent 编排器。给它在终端里丢一个任务它会自己规划步骤、执行命令、读输出、再修正直到任务完成。官方定位就是命令行里帮你干活的全能 Agent。和 IDE 插件相比这类 CLI 工具的优点是环境隔离简单、日志直观、适合脚本化调用你可以在 CI 里、定时任务里直接跑。两者不是非此即彼的关系实际使用中很多人两台机子各装一个。我的经验是需要精细控制每步改动时优先 Claude Code需要丢一个任务让它自己跑完时优先 Codex。1.2 为什么有人放着官方模型不用非要接第三方模型先给新手解释一个核心概念Claude Code 和 Codex 本质上都是API 客户端。也就是说它们负责处理你输入的任务、调用模型、展示结果真正做推理的是背后的模型服务。既然只是客户端那就存在一种可能——更换模型服务地址。官方模型确实好用但很多人会遇到这几个问题一是订阅费用和配额限制长时间批量任务跑下来成本不低二是企业内部有合规要求不能直接用某些外部服务三是有些人想用开源模型或国产模型做实验对比。以 DeepSeek 为例它的 API 价格相比官方模型有明显优势OpenAI 兼容接口也做得比较成熟于是就成了很多人接入第三方模型的首选。接第三方模型的本质就是改两个参数API 基地址Base URL和模型名。工具本身不知道也不关心模型跑在谁家服务器上只要你给的接口格式兼容、密钥有效、模型名真实存在它就能正常跑起来。2. 官方链路装好、登好、跑通你的第一条命令2.1 安装前的环境检查清单在动手之前我建议先花十分钟做一次环境检查很多坑都是在这里埋下的。Node.js 版本Claude Code 和 Codex 都是 npm 包需要 Node.js 18 以上建议直接用 Node 20 的 LTS 版本。命令行里用node -v确认版本太低的话先升级再装。Git两个工具在读取代码库、生成 diff 的场景都要调用 Git机器上最好先装好 Git 并配好用户信息。终端工具Windows 上强烈建议用 Windows TerminalmacOS 直接用自带的终端就可以了Ubuntu 桌面版同理。账号与密钥Claude Code 需要 Claude 账号或 Anthropic API KeyCodex 需要 OpenAI 账号或对应的 API Key建议提前登录一次网页版确认账号状态正常。npm 源如果你在安装时反复超时或下载失败先检查当前 npm registry 配的是不是国内镜像源配错源会导致包拉不下来。这是网络源配置问题和工具本身无关。2.2 Claude Code 安装与登录两种认证方式都踩一遍Claude Code 的安装命令很简单npm install -g anthropic-ai/claude-code装完先验证版本claude --version能打印出版本号就说明装成功了。然后再启动登录流程claude第一次运行会引导你走浏览器授权。它会给你一个链接打开后在浏览器里确认登录然后回终端继续。整个过程大概两分钟。如果你有 Anthropic 的 API Key也可以跳过浏览器授权直接设置环境变量export ANTHROPIC_API_KEYsk-ant-你的密钥之后运行claude就会自动走 API Key 模式。这里有一个容易混淆的点浏览器登录模式走的是 Claude 账号的订阅计费API Key 模式走的是按量计费两者在费用和配额上逻辑完全不同别指望用订阅账号的 key 去填 API Key 模式。登录成功后直接在终端里输入一句帮我看看当前目录下的项目结构如果它能正确读目录、列出文件就说明链路通了。如果长时间挂在等待上多半是网络环境的问题先确认当前环境是否能正常访问官方 API。2.3 Codex 安装与登录auth token 的坑提前避Codex 的安装同样是一行命令npm install -g openai/codex安装完检查版本codex --version登录方式有两种。第一种走 ChatGPT 账号codex login浏览器授权流程和 Claude Code 很接近。第二种是环境变量 API Keyexport OPENAI_API_KEYsk-你的密钥环境变量设置后Codex 会优先使用环境变量里的密钥而不是之前登录过的账号 token。很多人遇到codex auth token is unavailable的报错就是因为登录过旧账号又设置了新的环境变量两个来源冲突了。登录完成后跑一条简单任务验证codex exec 输出一段自我介绍能正常打印内容就说明环境没问题。Codex 桌面版同样有官方安装包Windows 和 macOS 都有安装后会自动读取用户目录下的 Codex 配置和 CLI 共用一套配置。3. 接第三方模型Base URL 与模型名的真正玩法3.1 一条环境变量打通管理的原理第三方接入之所以可行是因为这些 CLI 在设计时就留了配置口子。OpenAI 系列的 CLI 通常会读OPENAI_BASE_URL和OPENAI_API_KEYAnthropic 系列的 CLI 会读ANTHROPIC_BASE_URL和ANTHROPIC_API_KEY。你把基地址指向第三方服务的 API 端点把密钥换成第三方服务的密钥再把模型名换成目标模型工具连的就不再是官方模型而是你指定的供应商了。这里要注意一个关键细节接口格式的兼容性。OpenAI 的 CLI 希望请求和响应遵循 OpenAI 的 chat completions 或 responses 格式Anthropic 的 CLI 则按 Messages API 格式说话。如果模型服务商提供的是同格式 API接上就能跑格式不一致就得靠网关或转换层来翻译协议。3.2 Codex 接 DeepSeek 的实操步骤Codex 接 DeepSeek 相对简单因为 DeepSeek 提供了 OpenAI 兼容的 API。操作分为三步。第一步去 DeepSeek 开放平台申请 API Key得到一个以sk-开头的密钥。这个 Key 对应的是按量计费账号充少量金额就能跑大量测试任务。第二步配置环境变量。终端里执行export OPENAI_BASE_URLhttps://api.deepseek.com export OPENAI_API_KEYsk-你的DeepSeek密钥第三步运行任务时指定模型名。DeepSeek 有两个模型 IDdeepseek-chat对应通用对话模型deepseek-reasoner对应推理增强模型。测试命令codex exec --model deepseek-chat 用 Python 写一个快速排序带测试用例实测下来deepseek-chat的速度很快处理常规脚本和文档类任务完全够用复杂算法题或排查深层 bug 时deepseek-reasoner虽然慢一些但推理过程更充分结果整体更可靠。如果你不想每次敲--model参数可以在 Codex 的配置文件中预设一个 provider。Codex 支持在配置里定义多个模型供应商每个 provider 有自己的 API 地址、密钥环境变量名和默认模型。这样切模型就从一个供应商切换成另一个供应商而不是每次去改环境变量。3.3 Claude Code 接 DeepSeek协议转换层这道坎绕不开Claude Code 接 DeepSeek 比 Codex 麻烦原因在于格式不匹配Claude Code 原生只认 Anthropic 的 Messages API 格式而 DeepSeek 提供的是 OpenAI 兼容的 chat completions 格式。如果你直接把ANTHROPIC_BASE_URL指向 DeepSeek 的地址CLI 大概率会报请求格式错误或解析失败。解决办法是加一层协议转换网关。常见的做法是使用开源的中转网关项目例如 claude-code-router 这类工具把它跑在本地监听一个本地端口然后设置export ANTHROPIC_BASE_URLhttp://127.0.0.1:端口号 export ANTHROPIC_API_KEYsk-你的DeepSeek密钥这个思路不要被网关两个字吓到它的工作内容其实就三件事把 Anthropic 格式的请求重写成 OpenAI 格式转发给 DeepSeek把 DeepSeek 返回的响应翻译回 Anthropic 格式把流式输出重新包装。你在终端里看到的交互体验和官方模型基本一致只是背后跑的是 DeepSeek。但我不建议把这种方案当成完美平替。工具调用tool calls、流式事件类型、system prompt 结构这些细节在不同协议间转换时总会有不兼容的误差。我实测时遇到过Claude Code 调用工具时网关把请求转过去后 DeepSeek 理解偏了导致工具参数传错。所以如果你要长期在 Claude Code 中使用第三方模型最好先只做代码生成、解释、重构这类轻任务涉及大量工具调用的复杂任务留到官方模型再跑。3.4 ccswitch 统一管理多套第三方配置当你既有官方模型又有第三方模型时手动改环境变量就很痛苦而且容易漏改。我的做法是引入 ccswitch 这个开源配置切换工具来管理。它的核心思路是profile 化。每个 profile 保存一组完整配置供应商名称、API 基地址、API Key 对应的环境变量名、默认模型名、以及该供应商使用的配置文件名。切换时它会把对应 profile 的内容写入工具实际读取的配置文件或环境变量文件这样你就不用自己记得谁是谁。我实际用下来的流程是这样的首次配置时在 ccswitch 里添加一个DeepSeek 接 Codex的 profile填好地址和模型 ID再添加一个官方 Codex的 profile。平时切供应商只需要在 ccswitch 里选一下当前要用的 profile然后新开的终端就会自动生效。Claude Code 和 Codex 两边都能管不用在不同工具的命令行参数之间来回跳。有一点要特别提醒ccswitch 这类工具只负责配置切换不负责协议转换。如果你的目标模型 API 格式和工具原生格式不一致你仍然需要单独跑一个协议转换网关。也就是说Codex 接 DeepSeek 用 ccswitch 就够了但 Claude Code 接 DeepSeek 还得先配好本地网关再把网关地址填进 profile 里。4. 高频报错的完整排查链路不看日志就动手的人最容易翻车4.1 cc switch local proxy failed while handling codex endpoint /responses这条报错我在切换 Codex 配置时遇到过报错字面意思是ccswitch 里配置的本地代理在处理 Codex 的/responses端点时失败了。出现概率最高的场景是你给 Codex 配了一个本地转发服务但该服务没启动或者地址写错或者端口被别的程序占了。我的排查顺序是先看你配置里的 base_url 指向哪。如果指向http://127.0.0.1:8000就先确认 8000 端口上有没有程序在监听Linux/macOS 用lsof -i :8000Windows 用netstat -ano | findstr 8000。终端里直接拿 curl 打一下这个服务看它会不会正常响应。如果 curl 都连不上说明网关没启动去把本地网关服务跑起来再说。如果服务在跑但 Codex 仍报错检查 base_url 的 scheme。http和https写反请求会打到错误的协议端口上服务端根本没收到。检查 base_url 是否多写了路径段。Codex 会把 base_url 和/responses拼接如果你在地址末尾多写了一个/v1实际请求就变成了/v1/responses接口不对自然报错。我遇到的根因就是端口被占。当时有个旧的网关进程没退出占用 8000 端口新起的网关监听在 8001而配置文件里写的还是 8000。杀掉旧进程、改对端口号后问题直接消失。4.2 codex auth token is unavailable登录态说没就没这条报错通常发生在三种情况登录 token 过期环境变量里没有OPENAI_API_KEYccswitch 切换配置时把 Codex 的认证文件路径弄乱了。排查思路也是从简到繁先看当前环境变量是否设置了OPENAI_API_KEY。如果设置了Codex 一定会用这个 key而不是之前登录过的账号 token。此时 key 无效就会报 auth unavailable。执行codex logout然后重新codex login。这一步能解决绝大多数 token 过期问题。检查~/.codex目录下的 auth 文件是否存在、权限是否正确。如果你用 sudo 跑过 codex可能把配置文件的属主弄混乱了普通用户模式下就会读不到 token。如果之前用过 ccswitch切换 profile 后重新看一眼当前生效的配置认证文件路径是否被覆盖成了别的供应商的内容。4.3 model is not supported配置里的模型名踩了雷报错内容类似the gpt-5.6-sol model is not supported when using codex本质就是Codex 不认识你配置的模型名。这类问题跟工具本身没关系纯粹是配置映射错误。排查方式只有一个去模型供应商那边查真实的模型 ID。比如 DeepSeek 的模型 ID 是deepseek-chat和deepseek-reasoner你填deepseek-chat-v3这种自创名字服务端当然不认。官方模型同理模型名必须是当前工具版本支持的 ID不要去猜。我建议在配置第三方模型时先在供应商官网的 API 文档里把模型 ID 列表复制出来再填进配置。不要用听起来像的版本号比如第三方接口文档里写的是deepseek-chat你配置里写deepseek-v3看起来差不多但实际完全不通。4.4 区域可用性提示这一类提示怎么理解才不踩线启动 Claude Code 时如果看到 Claude Code might not be available in your country 之类的提示意思是当前所在区域的网络环境不在官方服务条款的支持范围内。这类提示的处理原则只有一个以官方支持的地区和官方文档为准不要用任何非官方手段去绕过限制。我能给的建议是先确认自己的账号类型和企业渠道是否符合官方支持范围确认当前使用的网络环境满足官方服务条款的要求如果确实不符合就在符合支持范围的环境里操作或者改用其他官方认可的渠道。合规永远是第一位为省事去走灰产通道出了问题得不偿失。5. 日常使用心得这些设置让我效率翻倍也让我少亏了不少钱5.1 项目说明文件是 AI 的上岗培训手册Claude Code 会读取项目里的CLAUDE.mdCodex 会读取AGENTS.md。很多新手忽略这一点AI 一上来就对项目一无所知生成的代码风格乱七八糟。我的建议是花十分钟在项目根目录写一份说明文件内容包含项目架构、启动命令、测试命令、代码风格约定。实测下来写清楚之后 AI 的代码质量提升非常明显。一个基础模板可以是# 项目说明 ## 技术栈 - 语言Python 3.11 - 框架FastAPI ## 常用命令 - 启动uvicorn app.main:app --reload - 测试pytest -x -q ## 规范 - 类型注解必须写 - API 错误统一返回 {code, message}这样 AI 每次在终端里帮你改代码时都能参照这个岗前培训不会自己发挥。5.2 配额与费用管理别让一次误操作烧光预算接入第三方模型不代表没有成本只是计费方变了。我的习惯是在 Codex 和 Claude Code 的交互设置里关闭自动确认让 AI 每次执行 shell 命令前都先问我一遍。这样它批量修改文件时你能及时叫停避免一次误操作产生大量 token 消耗。另外长时间任务尽量在终端里加超时控制别让一个 agent 任务无限跑下去。CLI 工具本身不一定有超时上限你自己可以在外部用超时命令或定时器保护。5.3 我自己的分工习惯官方模型和第三方模型各干各的活折腾了一圈之后我的日常分工是架构设计、跨文件重构、复杂 bug 排查这些高价值任务用官方模型写文档、补注释、批量生成简单脚本这类重复性任务用 DeepSeek 第三方模型。切换用 ccswitch 一键完成省心不少。最后再分享一个实在的经验接第三方模型时别贪全流程都换。我始终保留一个官方模型的 profile遇到诡异的不兼容问题时就切回官方模型对照实验。如果同一个任务官方模型跑得通、第三方模型跑不通问题大概率出在配置或协议转换层这样排查范围能缩小一大半。