Claude Desktop 接入 DeepSeek V4，卡住的不是推理，而是 provider discovery

这次测试最早的动因，其实不是“我想折腾一个新配置”，而是一个很实际的使用焦虑。最近一段时间，我在 Codex 上的 Token 消耗比较大，每次接近限额时都会明显感觉到不踏实。也正因为如此，我开始更认真地看有没有别的高能力模型，能够接进自己已经习惯的 Agent 工作流里，至少先做一轮可行性验证。

与此同时，网上关于 DeepSeek V4 代码能力的讨论也越来越多。我原本就想找一个时间试一下，看它到底是不是适合进入日常 coding workflow。再往前推一步，这个念头之所以变得更强，还因为我一直比较认同罗福莉提过的一种判断：在很多任务里，决定最终效果的，不只是模型单点能力有多强，Agent 框架本身也会把模型的可用性放大。换句话说，一个能力并非绝对顶尖的模型，如果进了合适的 Agent 容器，也可能打出接近顶级模型的工作效果。

正是在这种背景下，我又看到了那篇介绍如何把 DeepSeek V4 接进 Claude Desktop 的文章。几股因素叠在一起，这次对比测试才真正发生。

很多人会把“第三方模型接入 Claude Desktop”理解成一个很轻的配置动作：填一个兼容端点，填一个 key，剩下的只是模型能力问题。但我这次实际跑下来，真正先卡住的根本不是推理能力，而是 Claude Desktop 在推理之前那一层 provider discovery。

换句话说，问题不是 DeepSeek 不能回答问题，而是 Claude Desktop 先要把它识别成一个合格的 inference provider。这两件事听上去很像，工程上却不是同一个问题。

这也是为什么这篇文章不想写成一篇“配置教程”或者“脚本安利”。它更像一次很典型的接入排错案例：当一个第三方模型要接进另一个厂商已经做好的 Agent 容器时，真正先要处理的，往往不是模型本身，而是宿主在入口层有哪些默认预期。

如果先用一句话概括正文，它其实只讲三件事：我为什么会去测这条接入路径；官方 Anthropic-compatible endpoint 为什么会失败在 discovery 层；以及为什么轻量本地代理比重型一键接管更适合作为第一步验证。

一、先说那篇启发我的参考文章

这轮尝试真正被触发，是因为我先看到了一篇讲 DeepSeek V4 接入 Claude 路线的经验文章。那篇文章最有价值的地方，不是“给了一个脚本”，而是它把一个更实际的问题摆到了台面上：第三方模型接进 Agent，难点不只在推理本身，还在兼容层。

如果简单概括那篇文章给我的启发，大概有两层。第一，DeepSeek V4 值得认真试，不只是因为模型本身强，而是因为它可能进入真实工作流。第二，接入 Agent 时，真正决定成败的常常不是“模型会不会答”，而是协议、gateway、thinking 控制和 discovery 这些中间层到底对不对得上。

也正因为如此，我后面写这篇文章时，不想把重点放在“某个脚本很好用”，而是想把这次测试里真正有判断价值的部分写清楚。

二、动因与第一次直连接入尝试

这次测试不是从“做代理”开始的，而是从“先按最自然的官方路径试一遍”开始的。

也正因为如此，我一开始没有预设必须上代理。我先做的，是最自然的一步：直接用 DeepSeek 官方提供的 Anthropic-compatible endpoint 去接 Claude Desktop。

从操作上看，这个入口本身也很直接，就是从 Claude Desktop 的 Developer 菜单进入第三方推理配置。

当时在 Claude Desktop 的 Configure third-party inference 页面里，我填写的是：

• Inference provider: Gateway
• Gateway base URL: https://api.deepseek.com/anthropic
• Gateway API key: DeepSeek key
• Gateway auth scheme: bearer

下面这张图就是当时的直连配置界面。它很重要，因为它能把“我到底填了什么”这件事直接固定下来，也能让后面关于失败层级的判断更可信。

这一段很重要，因为它说明这次结论不是“我先入为主觉得官方路径不行”，而是我先按看上去最顺手、也最符合“兼容端点”直觉的方式走了一遍。

三、直连为什么会失败

直连之后，Claude Desktop 没有通过 provider setup。继续往里看，拿到的关键信息不是一句模糊的“配置失败”，而是一条很具体的错误：

先从界面上看，最直接的信号就是 Claude Desktop 在侧边栏和主界面里都提示 Your provider setup needs a fix。这类提示很容易让人第一反应是“是不是我字段没填对”，但这次真正重要的是，继续往下追之后，能把错误层级定位得更细。

```text

message: Gateway returned HTTP 404

httpStatus: 404

requestUrl: https://api.deepseek.com/anthropic/v1/models

endpoint: https://api.deepseek.com/

```

这条报错的价值非常大，因为它基本把失败层级直接点出来了。

第一，Claude Desktop 在真正发消息之前，会先走一轮模型发现，也就是先请求 /v1/models。第二，失败发生在这一步，而不是发生在真正的文本生成阶段。第三，这说明当前问题并不是 key 错了、余额不足、模型本身不能推理，而是 DeepSeek 这条官方 Anthropic-compatible endpoint 虽然可以承担推理请求，却没有完整满足 Claude Desktop 在 provider discovery 上的预期。

这也是这次测试里最值得澄清的一点。很多人看到“Anthropic-compatible”这几个字，会下意识把它理解成“凡是 Anthropic 系产品都应该能原生接”。但兼容推理接口，不等于兼容每个宿主在接入前额外加上的发现、鉴权、CORS 和 gateway 约定。Claude Desktop 要的，不只是“你会不会回答”；它先要确认“你是不是一个它认识的 provider”。

四、为什么我后来没有直接吃下整套一键接管

后面我确实引入了一个开源项目：deepseek-claude-setup。但它对我真正有用的地方，不是“一键接入 Claude Code 和 Codex”，而是它暴露出了一个更关键的工程事实：它的本地代理层实现了 Claude Desktop 期待的 /v1/models。

这个判断很重要，因为它改变了我后面的动作。

如果目标是“尽快把系统里所有 AI 入口都接管掉”，那当然可以直接吃下一整套脚本，包括改 ~/.claude/settings.json、改 ~/.codex/config.toml、常驻代理，甚至把默认模型路由一起改掉。但如果目标是先验证失败点在哪里、最小可行路径是什么，那种重方案反而会一下子引入太多变量。

我后来选的不是“整套拿来”，而是只抽取其中最薄的一层：本地代理能力。

这一步的意义，不是图省几次点击，而是把问题收窄。我要先验证的是：

1. Claude Desktop 是不是卡在 discovery；
2. 只要补上 discovery 兼容层，整条链路能不能通；
3. 在不大改全局配置的前提下，能不能先做出一个最小复现。

对第一步验证来说，这比“一键接管所有配置”更合适。因为你每少改一处全局状态，后面就更容易知道到底是哪一层真的解决了问题。

五、轻量本地代理到底补上了什么

这里最容易被写偏。轻量代理真正解决的，不是“省得手填参数”，也不是“本地跑起来更高级”，而是它补上了一层 Claude Desktop 想要、但官方兼容端点没有直接提供完整体验的 gateway 兼容面。

更具体地说，这层桥接至少做了三件事：

• 对 Claude Desktop 提供 GET /v1/models
• 对 Claude Desktop 提供 POST /v1/messages
• 处理 OPTIONS 和浏览器式的 CORS 预期

然后再把真正的请求继续转发到：

https://api.deepseek.com/anthropic

也就是说，代理不是新的模型服务，它只是一个很薄的本地桥。它做的事情更像“翻译门禁规则”，而不是重造推理引擎。

这也是为什么我觉得“桥接”这个视角比“脚本”更值得写。很多第三方模型接入别家 Agent 的问题，并不是模型不行，而是它住进了一个不是为它设计的房子。它会说话，不代表它已经符合这套房子的门牌、门禁和物业接口。这个时候，先加一层薄薄的本地 bridge，往往比直接大规模改造整栋系统更稳。

六、为什么轻量桥接更适合做第一步验证

这一步其实是方法判断，不只是工程判断。

如果你的目标是生产环境长期使用，后面当然还要看更多问题，比如模型选择、thinking 控制、默认路由、稳定性、日志、常驻代理方式，甚至是不是要把 Claude Code 和 Codex 一起纳入。但如果你还处在“先确认这条路到底通不通”的阶段，第一步最应该追求的不是功能最多，而是变量最少。

轻量桥接更适合第一步验证，至少有四个原因。

第一，它把问题拆得更清楚。直连失败时，你只能看到“官方兼容端点没有直接通过 Desktop”；加上轻量桥接后，如果链路通了，你就能更有把握地判断：问题确实主要在 discovery 兼容层，而不是在 DeepSeek 推理本身。

第二，它避免过早改写全局环境。至少在这一步里，我没有必要先去动 ~/.claude/settings.json、~/.codex/config.toml，也不需要马上把默认模型路由接管掉。验证应该先做成局部，再决定要不要扩大影响面。

第三，它更适合排错。因为桥足够薄，所以一旦失败，你能更快定位是本地 gateway 没起来、是 /v1/models 没补对、还是转发链路有问题。厚重的一键方案虽然省手，但也更容易把多个层级的问题揉在一起。

第四，它更符合“先证伪，再放大”的节奏。真正稳妥的接入，不是从全局接管开始，而是先用最小 prompt 验证 discovery 和 inference 两层都通，再决定后面要不要把它纳入更长的工作流。

七、这次最小验证是怎么完成的

最后成功的路径，其实很短：

1. 启动本地代理；
2. 在 Claude Desktop 里把 Gateway base URL 改指向本地代理地址 http://127.0.0.1:17861；
3. 保持 bearer 鉴权，并继续使用 DeepSeek key；
4. 发一个最小提示词：

```text

Please reply with exactly: desktop-proxy-ok

```

收到的返回是：

```text

desktop-proxy-ok

```

这条返回值本身很简单，但它说明了两件关键的事已经同时成立。

第一，Claude Desktop 不再卡在 provider discovery。第二，通过本地桥接转发到 DeepSeek 的推理链路也已经通了。

这正是我这次最想确认的最小结论。

八、这次验证证明了什么，又没有证明什么

这次验证能证明的是：Claude Desktop 并不是完全不能接 DeepSeek V4；只是当前更稳定、也更适合作为第一步验证的路径，不是官方 Anthropic-compatible endpoint 直连，而是补一层轻量本地代理桥接。

但它没有证明另外几件常被顺手夸大的事。

它没有证明 Claude Desktop 已经“原生支持” DeepSeek。它也没有证明只要填一个官方 base URL，就能完整跑通所有 agent 行为。它更没有证明 DeepSeek 在法律场景里已经整体优于 Claude 或 OpenAI 原生模型。因为这轮测试验证的只是接入路径，不是更大的模型评测命题。

我反而觉得，这种边界感正是这篇案例值得写的地方。很多接入文章的问题，不是步骤不够详细，而是把一个局部跑通的工程结论，顺手写成了更大的能力判断。这样读者虽然更兴奋，但判断会变得不干净。

结语

这次测试之后，我对第三方模型接入 Agent 这件事有了一个更明确的感受：真正该先问的，往往不是“这个模型能不能说话”，而是“宿主在允许它开口之前，默认还会先检查什么”。

如果失败发生在 discovery 层，那最好的第一步通常不是立刻上重型接管，而是先加一层足够薄、足够局部、足够容易回退的本地 bridge。先把失败点看清，再决定要不要把它扩展成长期方案。对学习、排错和第一轮验证来说，这比一开始就追求“大而全”更有价值。

附：本文涉及的关键链接

• DeepSeek Anthropic API 兼容文档：<https://api-docs.deepseek.com/guides/anthropic_api>
• DeepSeek Models 列表接口：<https://api-docs.deepseek.com/api/list-models/>
• Anthropic 关于 Claude 第三方 inference 配置说明：<https://support.claude.com/en/articles/14680741-install-and-configure-claude-cowork-with-third-party-platforms>
• 开源项目 deepseek-claude-setup：<https://github.com/yunshu0909/deepseek-claude-setup>
• 本次触发测试的参考文章：<https://mp.weixin.qq.com/s/4G5sNwkrGSQ_epa5OgtjNQ>

说明：本文件为公众号渲染试稿，建议在浏览器中打开后复制渲染结果，再粘贴到公众号编辑器。