1. Codex 接 DeepSeek 后插件失效的真实场景很多人第一次把 Codex 的模型从默认通道切到 DeepSeek是在 CC Switch 里改完路由、重启客户端然后发现对话能通、代码能补但插件面板是灰的或者点进去提示找不到模型。这个现象在本地已经装好 CC Switch 的开发者里非常普遍尤其是想让 Codex 走 DeepSeek 又不想丢掉插件调用能力的人。先说清楚这三者各自是什么。Codex 是本地编码客户端负责把你在编辑器里的补全、对话、Agent 任务发出去DeepSeek 是模型服务负责真正生成内容CC Switch 是配置切换器它把 Codex 原本写死的服务地址和密钥替换成你指定的入口。插件功能则是 Codex 侧的一套扩展机制它需要知道当前用的是什么模型、走的是哪个 Base URL才能把请求正确转发出去。问题就出在这里CC Switch 改的是 Codex 的 settings但插件有自己的一套读取逻辑。如果你只改了主配置插件读到的还是旧地址于是出现「主对话正常、插件报错」的割裂状态。我实测下来最常见的表现是插件调用时返回 401或者日志里出现local proxy failed再或者流式响应里reading choices直接抛异常。这篇笔记面向的是已经装好 CC Switch、想让 Codex 走 DeepSeek 并保留插件调用的开发者。我会把 settings 里 Base URL 和 Key 的可复制改法写清楚把插件开关的检查项列全最后用一次最小对话请求验证配置是否真的生效、插件是否可用。你不需要重新装一遍 Codex也不需要动系统环境变量改的就是那几个配置文件。核心检索词先摆出来Codex 接 DeepSeek 用 CC Switch 改 settings 保留插件这是一套本地配置落地的完整动作。适合谁适合本地已经有 Codex、已经装了 CC Switch、手里有可用 API Key、并且希望插件继续工作的开发者。不适合谁不适合想从零装环境的人那属于另一条路径。在动手之前你需要确认三件事Codex 能正常启动、CC Switch 能打开并识别到 Codex 配置、你有一个可用的模型服务入口和密钥。这三件事缺一个后面的步骤都会卡住。下面进入具体操作。2. TaoToken 前置准备与 CC Switch 配置入口定位在改 settings 之前先把服务入口和密钥准备好。TaoToken 的 API 地址是https://taotoken.net/api这个地址不加任何查询参数直接作为 Base URL 使用。密钥在控制台的 API Keys 页面生成生成后复制保存后面要填进配置文件。这里要强调一个容易踩的坑Base URL 和 Key 必须成对出现且要和 CC Switch 里选中的配置项一致。很多人只改了 Key 没改 URL或者改了 URL 但 CC Switch 里还留着旧的 profile结果请求发到了错误的地方。CC Switch 的本质是管理多套 profile每套 profile 包含 Base URL、Key、Model ID 三个字段切换 profile 就是切换这三个值。先定位 CC Switch 的配置入口。打开 CC Switch 后你会看到它列出了当前支持的客户端找到 Codex 那一项。点进去之后通常会有「路由设置」或「配置管理」之类的入口。不同版本的 CC Switch 界面略有差异但核心字段是一样的Base URL、API Key、Model ID。把这三项填成你要用的值。Model ID 这一项要特别注意。DeepSeek 的模型名在不同通道下写法可能不同你要填的是服务端实际接受的模型标识。如果你不确定可以先在模型对话页面发一条测试消息确认模型名可用再填进 CC Switch。填错模型名的典型报错是model not found或invalid model这类错误不会在 CC Switch 里提示只会在 Codex 发请求时暴露。CC Switch 改完之后它会把配置写入 Codex 的 settings 文件。这个文件的位置取决于你的操作系统和 Codex 版本常见路径在用户目录下的配置文件夹里。你可以用 CC Switch 的「打开配置文件」功能直接跳转避免手动找路径找错。找到文件后先备份一份再动手改。备份这一步别省。我见过有人改完配置后 Codex 起不来又没备份只能重装。备份就是复制一份原文件改个后缀存着出问题直接还原。配置入口定位清楚后下一步就是写具体的 settings 片段。这里要提醒CC Switch 的图形界面改的是它自己管理的 profile而 Codex 实际读取的是 settings 文件。两者要一致否则会出现「CC Switch 显示已切换、Codex 实际没生效」的情况。最稳妥的做法是图形界面改一遍再打开 settings 文件核对一遍。3. 可复制 settings 配置片段与插件开关检查这一节是全文的核心直接给可复制的配置。Codex 的 settings 通常是 JSON 或 TOML 格式取决于版本。下面给一份 JSON 结构的示例字段名和路径按你本地实际文件调整不要照抄路径。{ model: deepseek-chat, base_url: https://taotoken.net/api, api_key: sk-你的密钥, provider: { name: taotoken, base_url: https://taotoken.net/api, api_key: sk-你的密钥 }, plugins: { enabled: true, use_provider_config: true } }这份片段里base_url和provider.base_url都指向同一个地址这是为了兼容 Codex 主流程和插件流程两套读取逻辑。plugins.enabled打开插件总开关plugins.use_provider_config让插件复用 provider 的地址和密钥而不是去读旧的默认值。这两个字段是插件能否工作的关键。如果你本地是 TOML 格式等价写法如下model deepseek-chat base_url https://taotoken.net/api api_key sk-你的密钥 [provider] name taotoken base_url https://taotoken.net/api api_key sk-你的密钥 [plugins] enabled true use_provider_config true改完之后插件开关的检查项有三条。第一条确认plugins.enabled为 true有些版本默认是 false装完插件也不会自动打开。第二条确认plugins.use_provider_config为 true否则插件会去读一个独立的旧地址导致 401。第三条确认 provider 段的 base_url 和顶层 base_url 一致不一致时以 provider 段为准但顶层不一致会让主对话和插件走不同通道排查起来很麻烦。还有一个隐藏检查项Codex 的插件目录里可能有一份独立的配置文件它缓存了旧的 Base URL。改完主 settings 后如果插件仍报错去插件目录找config.json或settings.json把里面的 base_url 也改成https://taotoken.net/api。这一步很多人漏掉导致改了半天没效果。配置改完后重启 CC Switch 和 Codex。重启顺序是先关 Codex再关 CC Switch然后先开 CC Switch 让它加载 profile再开 Codex。顺序反了可能出现 CC Switch 覆盖 Codex 配置的情况。关于密钥安全不要把真实密钥提交到任何公开仓库也不要在截图里露出完整密钥。本地配置文件权限设成仅当前用户可读。如果你要把配置分享给别人把密钥字段替换成占位符。配置片段给完了下面进入验证环节。验证的目标是确认两件事主对话能通、插件能调。这两件事要分开验证因为它们的读取路径不同。4. 最小对话请求验证与插件调用结果确认验证分两步走。第一步验证主对话第二步验证插件调用。先做主对话因为它是基础主对话不通插件肯定不通。主对话验证用一个最小请求。打开 Codex 的对话窗口输入一句简单的话比如「用一句话说明什么是递归」。发送后观察返回。正常情况应该几秒内返回内容且内容来自 DeepSeek。如果返回 401说明 Key 不对或没生效如果返回local proxy failed说明 Base URL 不可达或格式错误如果返回里出现reading choices相关异常说明响应结构不符合预期通常是模型名或通道不匹配。你也可以用命令行直接验证绕过 Codex 界面确认服务入口本身可用curl -X POST https://taotoken.net/api/v1/chat/completions \ -H Content-Type: application/json \ -H Authorization: Bearer sk-你的密钥 \ -d { model: deepseek-chat, messages: [{role: user, content: 用一句话说明什么是递归}] }这条命令返回正常 JSON说明 Base URL、Key、Model ID 三者都对。返回 401 查 Key返回 404 查路径返回模型相关错误查 Model ID。命令行通了Codex 主对话基本就没问题。第二步验证插件。在 Codex 里触发一次插件调用具体触发方式取决于你装的插件类型。常见的是在编辑器里选中一段代码调用插件的解释或重构功能。观察插件面板是否返回结果。如果插件面板一直转圈或报错回到上一节的检查项重点看plugins.use_provider_config和插件目录里的独立配置。插件验证通过的标准是插件返回的内容和主对话返回的内容来自同一个模型通道且没有报错。你可以对比两次返回的风格和延迟如果插件明显走了另一条通道延迟和风格会不一致。验证过程中如果失败先别急着改配置先看日志。Codex 和 CC Switch 通常都有日志输出日志里会写明请求发到了哪个地址、返回了什么状态码。日志比界面提示准确得多。找到日志里的实际请求地址和你要配的地址对比不一致就说明配置没生效。验证通过后建议把这次可用的配置片段存一份到安全的地方下次换机器或重装时直接复用。配置这东西调通一次就记下来比每次重新试快得多。5. 本篇常见报错排查对照这一节把常见报错和对应原因列清楚方便你对照排查。报错信息以实际日志为准下面给的是典型形态。401 Unauthorized。最常见的原因是 Key 没填对或没生效。检查三处settings 里的 api_key、CC Switch profile 里的 Key、插件独立配置里的 Key。三处要一致。还有一种情况是 Key 前后有空格复制时带进去了肉眼看不出来删掉重填。local proxy failed。这个报错说明请求发不出去通常是 Base URL 写错或网络不可达。检查 base_url 是否为https://taotoken.net/api注意不要多加/v1或结尾斜杠路径拼接由客户端负责。如果你本地有网络策略限制确认该地址可访问。reading choices 相关异常。这个报错出现在解析响应阶段说明返回的 JSON 结构里没有预期的 choices 字段。原因通常是模型名不对服务端返回了错误结构。检查 Model ID 是否为服务端接受的名称可以先用上一节的 curl 命令确认。OAuth 相关报错。如果你在配置里混用了 OAuth 流程和 API Key 流程会出现这类冲突。Codex 的某些版本支持 OAuth 登录但走 DeepSeek 通道时应该用 API Key。检查配置里是否残留 OAuth 字段有就删掉统一用 api_key。插件面板灰显或提示未配置。这是插件没读到 provider 配置的表现。检查plugins.enabled和plugins.use_provider_config两个字段再检查插件目录的独立配置。三者都对了重启 Codex。模型返回内容但插件不工作。说明主通道通了插件通道没通。重点查插件目录的独立配置和use_provider_config字段。有些插件版本不读主配置必须单独配。改完配置不生效。九成是没重启或者重启顺序不对。先关 Codex再关 CC Switch先开 CC Switch再开 Codex。顺序对了还不生效检查是否有多个 Codex 实例在跑旧实例会占用旧配置。配置被覆盖。CC Switch 在启动时可能重写 Codex 的 settings。如果你手动改了 settings又被 CC Switch 覆盖说明 CC Switch 里的 profile 还是旧值。改 CC Switch 里的 profile而不是只改 settings 文件。排查的核心思路是先确认请求发到了哪里再确认返回了什么。日志里这两个信息都有。不要凭界面提示猜界面提示往往滞后或不准确。6. 长期编码场景的配置固化与入口选择配置调通只是第一步长期用下去要考虑固化和入口选择。固化指的是把可用配置存好、版本管理好避免每次环境变动都重新调。入口选择指的是根据使用场景选合适的接入方式。如果你主要是日常编码、补全、对话用 API Keys 加接入文档的方式就够了。API Keys 页面生成密钥接入文档里有各客户端的配置示例照着填即可。这种方式适合个人开发者和小团队配置简单排查直接。如果你要跑长期编码任务或 Agent 流程考虑 Coding Plan。它面向的是持续调用场景配置一次可以长期用不用频繁换 Key。对于需要稳定通道的自动化任务这种方式更省心。如果你只是想先验证模型效果不确定要不要长期用先去模型对话页面发几条消息确认返回质量和延迟符合预期再决定要不要写进 Codex 配置。这样避免配了半天发现模型不合适。配置固化方面建议把可用的 settings 片段存成一个模板文件密钥字段用占位符。换机器时复制模板填入新密钥即可。模板里把 base_url、model、plugins 三个段都保留这样插件配置不会丢。还有一个实用技巧给不同的使用场景建不同的 CC Switch profile。比如一个 profile 用于日常对话一个用于 Agent 任务切换时只改 profile不用手动改 settings。CC Switch 的多 profile 管理就是为这个场景设计的。最后提醒一点配置文件和密钥都属于敏感信息不要放进公开仓库不要截图外发。本地做好权限控制定期轮换密钥。配置调通后把这次的操作步骤记下来下次遇到类似问题可以直接复用排查思路。整套流程走下来核心就是三件事Base URL 填对、Key 填对、插件开关打开。这三件事做到Codex 走 DeepSeek 并保留插件调用就能稳定工作。剩下的就是根据你的使用场景选合适的入口把配置固化下来长期用。
1. Codex 接 DeepSeek 后插件失效的真实场景很多人第一次把 Codex 的模型从默认通道切到 DeepSeek是在 CC Switch 里改完路由、重启客户端然后发现对话能通、代码能补但插件面板是灰的或者点进去提示找不到模型。这个现象在本地已经装好 CC Switch 的开发者里非常普遍尤其是想让 Codex 走 DeepSeek 又不想丢掉插件调用能力的人。先说清楚这三者各自是什么。Codex 是本地编码客户端负责把你在编辑器里的补全、对话、Agent 任务发出去DeepSeek 是模型服务负责真正生成内容CC Switch 是配置切换器它把 Codex 原本写死的服务地址和密钥替换成你指定的入口。插件功能则是 Codex 侧的一套扩展机制它需要知道当前用的是什么模型、走的是哪个 Base URL才能把请求正确转发出去。问题就出在这里CC Switch 改的是 Codex 的 settings但插件有自己的一套读取逻辑。如果你只改了主配置插件读到的还是旧地址于是出现「主对话正常、插件报错」的割裂状态。我实测下来最常见的表现是插件调用时返回 401或者日志里出现local proxy failed再或者流式响应里reading choices直接抛异常。这篇笔记面向的是已经装好 CC Switch、想让 Codex 走 DeepSeek 并保留插件调用的开发者。我会把 settings 里 Base URL 和 Key 的可复制改法写清楚把插件开关的检查项列全最后用一次最小对话请求验证配置是否真的生效、插件是否可用。你不需要重新装一遍 Codex也不需要动系统环境变量改的就是那几个配置文件。核心检索词先摆出来Codex 接 DeepSeek 用 CC Switch 改 settings 保留插件这是一套本地配置落地的完整动作。适合谁适合本地已经有 Codex、已经装了 CC Switch、手里有可用 API Key、并且希望插件继续工作的开发者。不适合谁不适合想从零装环境的人那属于另一条路径。在动手之前你需要确认三件事Codex 能正常启动、CC Switch 能打开并识别到 Codex 配置、你有一个可用的模型服务入口和密钥。这三件事缺一个后面的步骤都会卡住。下面进入具体操作。2. TaoToken 前置准备与 CC Switch 配置入口定位在改 settings 之前先把服务入口和密钥准备好。TaoToken 的 API 地址是https://taotoken.net/api这个地址不加任何查询参数直接作为 Base URL 使用。密钥在控制台的 API Keys 页面生成生成后复制保存后面要填进配置文件。这里要强调一个容易踩的坑Base URL 和 Key 必须成对出现且要和 CC Switch 里选中的配置项一致。很多人只改了 Key 没改 URL或者改了 URL 但 CC Switch 里还留着旧的 profile结果请求发到了错误的地方。CC Switch 的本质是管理多套 profile每套 profile 包含 Base URL、Key、Model ID 三个字段切换 profile 就是切换这三个值。先定位 CC Switch 的配置入口。打开 CC Switch 后你会看到它列出了当前支持的客户端找到 Codex 那一项。点进去之后通常会有「路由设置」或「配置管理」之类的入口。不同版本的 CC Switch 界面略有差异但核心字段是一样的Base URL、API Key、Model ID。把这三项填成你要用的值。Model ID 这一项要特别注意。DeepSeek 的模型名在不同通道下写法可能不同你要填的是服务端实际接受的模型标识。如果你不确定可以先在模型对话页面发一条测试消息确认模型名可用再填进 CC Switch。填错模型名的典型报错是model not found或invalid model这类错误不会在 CC Switch 里提示只会在 Codex 发请求时暴露。CC Switch 改完之后它会把配置写入 Codex 的 settings 文件。这个文件的位置取决于你的操作系统和 Codex 版本常见路径在用户目录下的配置文件夹里。你可以用 CC Switch 的「打开配置文件」功能直接跳转避免手动找路径找错。找到文件后先备份一份再动手改。备份这一步别省。我见过有人改完配置后 Codex 起不来又没备份只能重装。备份就是复制一份原文件改个后缀存着出问题直接还原。配置入口定位清楚后下一步就是写具体的 settings 片段。这里要提醒CC Switch 的图形界面改的是它自己管理的 profile而 Codex 实际读取的是 settings 文件。两者要一致否则会出现「CC Switch 显示已切换、Codex 实际没生效」的情况。最稳妥的做法是图形界面改一遍再打开 settings 文件核对一遍。3. 可复制 settings 配置片段与插件开关检查这一节是全文的核心直接给可复制的配置。Codex 的 settings 通常是 JSON 或 TOML 格式取决于版本。下面给一份 JSON 结构的示例字段名和路径按你本地实际文件调整不要照抄路径。{ model: deepseek-chat, base_url: https://taotoken.net/api, api_key: sk-你的密钥, provider: { name: taotoken, base_url: https://taotoken.net/api, api_key: sk-你的密钥 }, plugins: { enabled: true, use_provider_config: true } }这份片段里base_url和provider.base_url都指向同一个地址这是为了兼容 Codex 主流程和插件流程两套读取逻辑。plugins.enabled打开插件总开关plugins.use_provider_config让插件复用 provider 的地址和密钥而不是去读旧的默认值。这两个字段是插件能否工作的关键。如果你本地是 TOML 格式等价写法如下model deepseek-chat base_url https://taotoken.net/api api_key sk-你的密钥 [provider] name taotoken base_url https://taotoken.net/api api_key sk-你的密钥 [plugins] enabled true use_provider_config true改完之后插件开关的检查项有三条。第一条确认plugins.enabled为 true有些版本默认是 false装完插件也不会自动打开。第二条确认plugins.use_provider_config为 true否则插件会去读一个独立的旧地址导致 401。第三条确认 provider 段的 base_url 和顶层 base_url 一致不一致时以 provider 段为准但顶层不一致会让主对话和插件走不同通道排查起来很麻烦。还有一个隐藏检查项Codex 的插件目录里可能有一份独立的配置文件它缓存了旧的 Base URL。改完主 settings 后如果插件仍报错去插件目录找config.json或settings.json把里面的 base_url 也改成https://taotoken.net/api。这一步很多人漏掉导致改了半天没效果。配置改完后重启 CC Switch 和 Codex。重启顺序是先关 Codex再关 CC Switch然后先开 CC Switch 让它加载 profile再开 Codex。顺序反了可能出现 CC Switch 覆盖 Codex 配置的情况。关于密钥安全不要把真实密钥提交到任何公开仓库也不要在截图里露出完整密钥。本地配置文件权限设成仅当前用户可读。如果你要把配置分享给别人把密钥字段替换成占位符。配置片段给完了下面进入验证环节。验证的目标是确认两件事主对话能通、插件能调。这两件事要分开验证因为它们的读取路径不同。4. 最小对话请求验证与插件调用结果确认验证分两步走。第一步验证主对话第二步验证插件调用。先做主对话因为它是基础主对话不通插件肯定不通。主对话验证用一个最小请求。打开 Codex 的对话窗口输入一句简单的话比如「用一句话说明什么是递归」。发送后观察返回。正常情况应该几秒内返回内容且内容来自 DeepSeek。如果返回 401说明 Key 不对或没生效如果返回local proxy failed说明 Base URL 不可达或格式错误如果返回里出现reading choices相关异常说明响应结构不符合预期通常是模型名或通道不匹配。你也可以用命令行直接验证绕过 Codex 界面确认服务入口本身可用curl -X POST https://taotoken.net/api/v1/chat/completions \ -H Content-Type: application/json \ -H Authorization: Bearer sk-你的密钥 \ -d { model: deepseek-chat, messages: [{role: user, content: 用一句话说明什么是递归}] }这条命令返回正常 JSON说明 Base URL、Key、Model ID 三者都对。返回 401 查 Key返回 404 查路径返回模型相关错误查 Model ID。命令行通了Codex 主对话基本就没问题。第二步验证插件。在 Codex 里触发一次插件调用具体触发方式取决于你装的插件类型。常见的是在编辑器里选中一段代码调用插件的解释或重构功能。观察插件面板是否返回结果。如果插件面板一直转圈或报错回到上一节的检查项重点看plugins.use_provider_config和插件目录里的独立配置。插件验证通过的标准是插件返回的内容和主对话返回的内容来自同一个模型通道且没有报错。你可以对比两次返回的风格和延迟如果插件明显走了另一条通道延迟和风格会不一致。验证过程中如果失败先别急着改配置先看日志。Codex 和 CC Switch 通常都有日志输出日志里会写明请求发到了哪个地址、返回了什么状态码。日志比界面提示准确得多。找到日志里的实际请求地址和你要配的地址对比不一致就说明配置没生效。验证通过后建议把这次可用的配置片段存一份到安全的地方下次换机器或重装时直接复用。配置这东西调通一次就记下来比每次重新试快得多。5. 本篇常见报错排查对照这一节把常见报错和对应原因列清楚方便你对照排查。报错信息以实际日志为准下面给的是典型形态。401 Unauthorized。最常见的原因是 Key 没填对或没生效。检查三处settings 里的 api_key、CC Switch profile 里的 Key、插件独立配置里的 Key。三处要一致。还有一种情况是 Key 前后有空格复制时带进去了肉眼看不出来删掉重填。local proxy failed。这个报错说明请求发不出去通常是 Base URL 写错或网络不可达。检查 base_url 是否为https://taotoken.net/api注意不要多加/v1或结尾斜杠路径拼接由客户端负责。如果你本地有网络策略限制确认该地址可访问。reading choices 相关异常。这个报错出现在解析响应阶段说明返回的 JSON 结构里没有预期的 choices 字段。原因通常是模型名不对服务端返回了错误结构。检查 Model ID 是否为服务端接受的名称可以先用上一节的 curl 命令确认。OAuth 相关报错。如果你在配置里混用了 OAuth 流程和 API Key 流程会出现这类冲突。Codex 的某些版本支持 OAuth 登录但走 DeepSeek 通道时应该用 API Key。检查配置里是否残留 OAuth 字段有就删掉统一用 api_key。插件面板灰显或提示未配置。这是插件没读到 provider 配置的表现。检查plugins.enabled和plugins.use_provider_config两个字段再检查插件目录的独立配置。三者都对了重启 Codex。模型返回内容但插件不工作。说明主通道通了插件通道没通。重点查插件目录的独立配置和use_provider_config字段。有些插件版本不读主配置必须单独配。改完配置不生效。九成是没重启或者重启顺序不对。先关 Codex再关 CC Switch先开 CC Switch再开 Codex。顺序对了还不生效检查是否有多个 Codex 实例在跑旧实例会占用旧配置。配置被覆盖。CC Switch 在启动时可能重写 Codex 的 settings。如果你手动改了 settings又被 CC Switch 覆盖说明 CC Switch 里的 profile 还是旧值。改 CC Switch 里的 profile而不是只改 settings 文件。排查的核心思路是先确认请求发到了哪里再确认返回了什么。日志里这两个信息都有。不要凭界面提示猜界面提示往往滞后或不准确。6. 长期编码场景的配置固化与入口选择配置调通只是第一步长期用下去要考虑固化和入口选择。固化指的是把可用配置存好、版本管理好避免每次环境变动都重新调。入口选择指的是根据使用场景选合适的接入方式。如果你主要是日常编码、补全、对话用 API Keys 加接入文档的方式就够了。API Keys 页面生成密钥接入文档里有各客户端的配置示例照着填即可。这种方式适合个人开发者和小团队配置简单排查直接。如果你要跑长期编码任务或 Agent 流程考虑 Coding Plan。它面向的是持续调用场景配置一次可以长期用不用频繁换 Key。对于需要稳定通道的自动化任务这种方式更省心。如果你只是想先验证模型效果不确定要不要长期用先去模型对话页面发几条消息确认返回质量和延迟符合预期再决定要不要写进 Codex 配置。这样避免配了半天发现模型不合适。配置固化方面建议把可用的 settings 片段存成一个模板文件密钥字段用占位符。换机器时复制模板填入新密钥即可。模板里把 base_url、model、plugins 三个段都保留这样插件配置不会丢。还有一个实用技巧给不同的使用场景建不同的 CC Switch profile。比如一个 profile 用于日常对话一个用于 Agent 任务切换时只改 profile不用手动改 settings。CC Switch 的多 profile 管理就是为这个场景设计的。最后提醒一点配置文件和密钥都属于敏感信息不要放进公开仓库不要截图外发。本地做好权限控制定期轮换密钥。配置调通后把这次的操作步骤记下来下次遇到类似问题可以直接复用排查思路。整套流程走下来核心就是三件事Base URL 填对、Key 填对、插件开关打开。这三件事做到Codex 走 DeepSeek 并保留插件调用就能稳定工作。剩下的就是根据你的使用场景选合适的入口把配置固化下来长期用。
