这两天我过得有点分裂浏览器标签页在 Qwen 和 DeepSeek 之间来回切一个 Kimi 网页版蹲着看超长报告本地 Ollama 窗口挂在后台慢慢拉模型而 Claude Desktop 反而像个高级摆设。当你在同一个项目里反复比较各家模型时最难受的往往不是模型本体的差距而是入口太乱上下文散得到处都是。后来我花了两天时间去折腾 Ollama想把 Qwen、DeepSeek、Kimi 都收进 Claude Desktop 统一管理结果第一回合几乎全灭真正跑通的路线反而是绕了一圈回到了我最初就在用的 API 方式用一层协议转换网关把三家模型接进 Claude 的桌面生态。这篇文章就是这次完整折腾过程的记录包括 Ollama 卡在哪、为什么放弃、以及最终配置步骤和后续踩到的一堆坑。1. 是什么让我非要把 Qwen、DeepSeek、Kimi 全塞进同一个桌面端1.1 我的痛点每个任务都要换一个聊天窗口我平时的工作流大概是这样的中文文档润色优先开 Qwen因为它在中文表达上更顺需要算一笔复杂成本或做逻辑推理就切 DeepSeekR1 的 reasoning 过程确实清晰遇到几十页的 PDF、几万行日志分析就开 Kimi长上下文读取是我的刚需真要动代码工程又回 Claude。每个模型都有自己的强项这是好事但代价是信息孤岛。A 窗口里分析的结论无法直接拖到 B 窗口继续加工每换一次窗口就要重新粘一遍背景资料还要手动控制 token 成本。对于我这种喜欢把文档、代码、上下文全部集中在一个工作台的人来说这种“模型间搬运工”的状态非常低效。当时在社区看到有人讨论 Claude Desktop 能不能当统一入口我立刻来兴趣了。Claude 桌面端的交互比浏览器网页版舒服太多支持长会话记录、能直接拖文件进去、有代码执行和 artifacts 机制、还能挂 MCP 工具服务。如果我能在同一个界面上按任务自由切换 Qwen、DeepSeek、Kimi那上下文可以共享项目资料也不用每个模型单独投喂一遍这种体验才是真正想要的。1.2 Claude Desktop 值得当总入口吗先不谈那些概念单说实际能用的部分。Claude Desktop 以及它配套的 Code 环境本身是针对智能体工作流设计的。桌面端的优势不光是界面好看更重要的是它以“项目”为单位组织会话文件、代码片段、工具调用结果都会留在上下文里方便反复迭代。另一个优点是它对工具协议的支持比较成熟。很多类似客户端只支持普通聊天Claude 这边可以直接定义工具给模型调用这也是为什么最终我选择“桌面端 网关 各家模型 API”的组合而不是在网页版之间跳来跳去。不过要说清楚上述能力有一大半绑在 Claude 自家的协议上第三方模型进来后并不保证全部功能一致。所以这篇文章适合的不是普通聊天用户而是愿意折腾配置、手里已经有各家 API key、并且能接受“部分高级能力会失效”的开发者或重度用户。1.3 适合这样玩的人群与前提先泼个冷水如果你只是想找个本地模型跑聊天那 Claude Desktop 这套方案对你是多余的直接开 Ollama 的网页界面反而更快。如果你想对齐的是我这种场景日常写报告用 Qwen、做逻辑推理用 DeepSeek、喂长文档用 Kimi、偶尔回到 Claude 做正经代码工程那把这个模型矩阵集中到一个客户端才有意义。前提条件有三条第一你已经在对应平台注册并开通了 API 额度第二你能接受第三方模型在部分工具调用上不如 Claude 原生稳定第三你只是在个人开发测试环境里跑不是在生产环境里做高并发业务。我后面讲的配置步骤也都建立在这个前提下。2. 第一次尝试 Ollama 本地路线从期待到吃灰的复盘2.1 为什么第一反应是 Ollama一开始我天然倾向 Ollama因为它最接近“免费 私有 一次部署无限用”。Qwen 有开源权重DeepSeek 有开源版本Kimi 虽然官方不开源但社区里也有类似量级的替代品可以跑。再加上手里正好有一张 24GB 显存的卡理论上跑个 Qwen 3 8B、量化版 DeepSeek-R1 都不是问题。那几天热搜词里也一堆“ollama 安装 qwen”“ollama 本地部署 deepseek”给我的错觉是这条路已经很成熟了。结果实际情况远没有那些教程视频拍得顺利。Ollama 本身下载安装倒是快但后续最大的阻碍不是“能不能跑”而是“怎么让 Claude Desktop 认它”。这条路我一共卡了三个大坑。2.2 卡点一模型包太大默认源拉取慢到怀疑人生第一个坑实在且心烦模型体积太大了。ollama pull 一个 qwen3:8b看起来只有 4.7GB 左右但默认源有时几千 KB 每秒都不到中途连接一断就要重来等的我一度以为死锁了。后来大模型圈的朋友教我先在环境变量里把 OLLAMA_BASE_URL 指到国内可用的镜像源我用的是当时社区口碑还不错的镜像站再用ollama pull qwen3:8b就能把速度拉起来。顺带把 OLLAMA_MODELS 环境变量也改了因为默认模型目录在系统盘几个模型一拉就十几 GBC 盘直接告急。实际命令类似# macOS / Linux 示例 export OLLAMA_BASE_URLhttps://你的镜像源地址 export OLLAMA_MODELS/data/ollama/models # 再重启 ollama serve ollama pull qwen3:8b下载问题解决了可这只是开场热身。真正麻烦的还在后面因为 Ollama 服务起来之后Claude Desktop 根本不知道怎么跟它通信。2.3 卡点二Claude 的 Messages 协议和 Ollama 的 API 协议根本不是一回事这是我要重点讲清楚的一个坑也是整个 Ollama 路线失败的根本原因。Claude 客户端和 Claude 官方模型之间走的是 Anthropic 的 Messages API请求体结构、鉴权方式、流式返回格式都是 Anthropic 自己的一套。而 Ollama 对外提供的是/v1/chat/completions这类 OpenAI 风格接口也兼容/api/chat。两边协议不通用Claude Desktop 内部默认只会往 Anthropic Messages 格式的端点发请求。你可以把这个想象成客户端只知道 USB-C 协议Ollama 只提供 Lightning 口两边没有转接头硬插是插不进去的。很多人搜“claude code cc switch ollama”能找到一堆讨论其实那些讨论里的 cc-switch 只是帮你切配置文件的工具它本身不承担协议翻译所以只装 cc-switch 并不能让 Ollama 被 Claude Desktop 直接认出来。我当时试过在桌面端设置文件里强改 Endpoint 指向本机的 Ollama 地址结果是请求能发出去但 Ollama 收到后完全不认识直接返回错误格式。有人说可以自己在本地起一个协议转换服务那又是一套开发工程。到这一步本地路线的复杂度已经超过了我的预期。2.4 卡点三强行跑通也撑不住本地模型带不动智能体会话为了不死心我还是想办法用开源网关把 Ollama 的协议翻译成了 Claude 格式结果暴露了第三个问题本地模型根本扛不住 Claude 桌面的真实请求负载。Claude Desktop 这类智能体客户端不是简单发一句话就结束的。它会拼上很长的系统提示词附带一套复杂的工具定义每条消息可能都带历史上下文。我实测 Qwen 3 8B 在普通聊天时反应流畅但一旦挂到 Claude 桌面上单个请求可能吃掉几千甚至上万 token 的指令和工具 schema小模型的上下文预算瞬间被挤占输出质量明显下降。27B 级别模型稍好一些但生成速度又跟不上一个多步骤任务要等很久完全失去了智能体工具该有的即时反馈感。DeepSeek 本地量化版也类似在没有工具调用的时候还行一旦涉及多轮工具调用推理速度直接让人想砸键盘。到最后我意识到Ollama 本身没有问题它适合的是 OpenAI 风格客户端里的简单对话场景硬把它塞进 Claude 的智能体工作流属于功能错配。2.5 阶段性结论Ollama 给我留下的价值虽然 Ollama 路线最终没有成为主力但它并非白折腾。我用它验证了一个重要结论模型能不能进 Claude Desktop核心不看模型本地跑得多快而看协议层能不能对齐。这个结论让我直接转向了另一条我更熟的路线——各家模型厂商的商业 API。毕竟 DeepSeek、Qwen、Kimi 本来就是模型厂商API 服务稳定、上下文窗口够大、工具调用是服务器端实现的跟本地小模型完全不是一个体验级别。回到 API 路线就是把硬骨头交给平台我只管在桌面端做接入配置。3. 真正跑通的方式商业 API Anthropic 兼容网关3.1 一个关键转折点我要的是“能用”不是“本地”从 Ollama 受挫后我反复问自己一个问题我到底是要“本地部署”这个仪式感还是要“在 Claude Desktop 里顺利调用这些模型”这个结果答案是后者。如果只是为了在 Ollama 里跑开源模型那跟 Claude Desktop 根本没有关系。如果是为了让 DeepSeek、Qwen、Kimi 能出现在我的统一工作台里那就应该用它们最稳定、最省事的开放 API。把模型托管给厂商我不需要准备显卡不需要管理模型文件也不需要担心服务重启后上下文丢失。于是整个方案变成了Claude Desktop/Claude Code 作为前端本地跑一个轻量级协议转换网关负责把 Anthropic Messages 格式翻译成各家 API 能懂的 OpenAI 风格格式再路由到 DeepSeek、Qwen、Kimi 的官方接口。这样一个架构既能保留 Claude 桌面端的交互能力又能在三家模型之间自由切换。3.2 三家 API 的基本信息与开通要点DeepSeek、Qwen阿里云百炼、KimiMoonshot这三家平台的 API 都是 OpenAI 兼容格式也就是说一旦网关把 Anthropic 格式翻译成 OpenAI 风格后面的请求就可以统一发给任意一家。模型平台官方接口风格常见模型标识我实际关注的场景DeepSeekOpenAI 兼容deepseek-chat / deepseek-reasoner代码推理、逻辑分析、数学计算Qwen / 阿里云百炼OpenAI 兼容qwen-plus / qwen-max / qwen-turbo中文写作、信息提炼、批量总结Kimi / MoonshotOpenAI 兼容kimi-k2 / moonshot-v1-8k/32k/128k 等超长文档、多文件分析开通 API 时有一点容易被忽略尽量用同一个手机号或账号体系把三个平台都认证好否则后面写配置时才发现 key 没权限来回切换账号很麻烦。另外每家平台的模型标识会随版本更新变化我建议你在配置前先去官网文档确认最新的 model 名称不要死抄博客里的。比如 DeepSeek 的 deepseek-chat 背后指向哪个版本阿里百炼的 qwen-plus 跟 qwen-max 定价差多少Kimi 新推出的 k2 是否支持函数调用这些都要以官方为准。3.3 网关选型为什么不是硬改 Base URL 就行很多人会问DeepSeek、Qwen、Kimi 不都提供 OpenAI 兼容接口吗那 Claude Desktop 能不能直接把 Base URL 改成它们的地址答案是不能因为协议还是不一致。Claude Desktop 默认发出去的是 Anthropic Messages 格式而三家平台接收的是 OpenAI Chat Completions 格式请求体里的 messages、system、tools 字段都不同。你直接把 Base URL 换成api.deepseek.com服务端根本不认这个路径。所以中间必须有一个协议转换层常见做法就是跑一个本地网关接收 Anthropic 格式翻译后再转发给目标平台。我对比了几个常见方案方案上手难度协议转换多供应商切换适合人群手动设置环境变量低不支持不支持只想试试一个模型的人cc-switch低不支持支持快速切换配置有现成 Anthropic 兼容端点的人claude-code-router 等开源网关中支持支持需要接入 DeepSeek/Qwen/Kimi 的核心用户LiteLLM Proxy中高支持支持需要统一计费、复杂路由的团队看到“cc-switch ollama”那个热搜词的时候我猜很多人也跟我一样先以为是 cc-switch 能直接解决所有问题。其实 cc-switch 更多像配置管家它负责在多个配置之间快速切换真正承担协议翻译的还是网关层。所以我最后的架构是桌面端配置指向本机网关网关里配置三家平台的 API key 和模型路由规则。3.4 为什么选择本机网关而不是云端服务我见过有人直接把请求发到公网聚合服务然后再转发给各家模型。这种方案确实省事但我个人比较谨慎API key、对话内容、文件内容都要经过第三方服务器对隐私要求高的工作流不合适。本机网关则不同它跑在 127.0.0.1所有敏感数据只在本机和对应模型厂商之间传递不经过额外中间人。而且本机网关可以完全由我控制想加哪家供应商、调整模型映射规则、查看请求日志都很方便。局域网内其他设备如果要连也可以绑定到局域网 IP但默认我建议只监听本地回环地址。4. 从配置到跑通完整实操过程还原4.1 准备阶段要做的事我的运行环境是 macOS理论上 Windows/Linux 也差不多。需要的工具Claude Desktop 客户端以及可选的 Claude Code 命令行工具Node.js 运行环境用来跑开源网关三个平台各自的 API key第一步当然是先把三家平台的 key 拿到。创建 key 的时候建议在平台后台把 key 的权限和额度限制都设好防止跑测试时额度被刷爆。DeepSeek 和阿里云百炼在 key 管理页面都有余额预警设置Kimi 那边也建议先充少量额度。然后我来本地起一个网关服务。以我用的开源网关为例它会读取一个config.yaml文件里面记录供应商信息并监听一个本地端口比如 3456。不同网关的字段写法会有差异但思路都是配置三块内容监听端口、上游供应商、模型映射关系。4.2 一份最小可用的配置文件思路下面是一个参考思路实际字段以你选择的网关项目模板为准# gateway config 示例不要直接照抄字段 server: host: 127.0.0.1 port: 3456 providers: deepseek: base_url: https://api.deepseek.com api_key: 你的_deepseek_key models: - deepseek-chat qwen: base_url: https://dashscope.aliyuncs.com/compatible-mode/v1 api_key: 你的_dashscope_key models: - qwen-max - qwen-plus kimi: base_url: https://api.moonshot.cn/v1 api_key: 你的_moonshot_key models: - kimi-k2 router: default_model: qwen-max rules: - pattern: deepseek model: deepseek-chat - pattern: kimi model: kimi-k2配置文件的核心是“模型映射”。Claude 桌面端每次请求都会带一个模型名比如 claude-sonnet-4-xxx网关可以把这类模型名映射到目标厂商的实际模型。你也可以不关心原始模型名而是让网关按关键词路由比如提示词里带“#deepseek”就走 DeepSeek带“#kimi”就走 Kimi。我自己测试下来觉得关键词路由更直观不用每次改配置。4.3 让 Claude Desktop/Claude Code 指向本机网关启动网关后打开 Claude Code 或桌面端对应的设置入口。一般只要能配置环境变量的位置都可以这样做export ANTHROPIC_BASE_URLhttp://127.0.0.1:3456 export ANTHROPIC_AUTH_TOKEN任意占位字符串 export ANTHROPIC_MODELqwen-max注意 ANTHROPIC_AUTH_TOKEN 这里只要填一个非空占位字符串即可因为真正的鉴权由网关拿着去请求上游厂商。如果客户端里有图形化设置项也可以把 Base URL 填成http://127.0.0.1:3456。如果你已经装了 cc-switch也可以把上面这组配置保存成一个供应商方案下次往 DeepSeek 切就点一下按钮往 Qwen 切再点一下按钮不需要每次手动改环境变量。这一步“第一次其实也折腾了一会因为有些版本的环境变量名带下划线不带横线具体命名要看官方文档”。4.4 首次验证怎么知道真的切过去了配置好之后先不要急着跑复杂任务。我习惯用一个固定 prompt 做探针“请用一句话介绍你自己并说明你当前最擅长什么。”然后观察返回结果以及网关日志里的路由记录。网关日志会显示请求从 127.0.0.1 进来转发到了哪个上游地址。如果显示去向api.deepseek.com那说明走的是 DeepSeek如果去向dashscope.aliyuncs.com那就是 Qwen以此类推。这一步很关键因为有不少人配置完发现回复速度很慢排查半天才意识到请求根本没走本地网关而是走了 Claude 官方。我第一次跑通的时候在同一个桌面会话里连续问了三个问题分别用不同关键词命中了三家模型。那种感觉确实爽一个工作台、三种模型、互相能看到我投喂的文件内容不用再切来切去。4.5 跑通之后我做的第一轮实测第一轮我分别测试了三个典型任务场景走的模型实际表现改写一段产品文案要求语气更正式qwen-max中文表达稳定基本没出现英文夹杂解一道概率题并要求展示推导过程deepseek-chat步骤清晰逻辑链完整总结一份 500 页 PDF 的目录和关键章节kimi-k2长上下文处理表现优秀没有中途忘记前文这轮实测让我确认只要 protocol gateway 层正常Claude Desktop 确实可以轻松调度这三家模型。但测试范围扩大后我也发现了一些只有实际高频使用才会暴露的问题尤其是上下文压缩、工具调用和计费差异这些放在下一节细说。5. 跑起来之后的细坑上下文压缩、工具调用和计费5.1 上下文截断和“压缩上下文”问题的真相Claude Desktop 有个原生功能叫上下文压缩或会话自动摘要当会话超过模型上下文窗口时客户端会把早期内容做摘要压缩。很多人问“claude desktop 如何设置压缩上下文”设置本身不复杂就在会话行为或模型配置选项里调整阈值。但接入第三方模型后这个功能的可靠性会打折。原因是 Claude 原生的压缩逻辑是为 Claude 模型的上下文窗口和 tokenizer 设计的。当你切到 Qwen 或 DeepSeek 时客户端对当前模型上下文上限的感知来自你填的配置如果你不手动指定它可能沿用 Claude 的默认值导致实际模型窗口还没到阈值客户端就以为还很宽裕结果请求发过去上游直接报 context length exceeded。解决办法是在接入第三方模型时把网关或客户端配置里的上下文上限调低。比如 Kimi 长窗口虽然大但 qwen-turbo 的上下文就没那么宽你要按目标模型的实际能力手动设一个保守值。压缩功能可以开但要意识到它压缩出来的摘要对中文和代码的还原度没有官方模型那么好。5.2 工具调用能力在每家模型上完全不一样Claude Desktop 的优势之一在于智能体工作流也就是模型能调用工具、操作文件、访问 MCP 服务。但这个优势高度依赖模型对 function calling 的支持程度。把第三方模型接进来后我必须面对一个现实不是每个模型都能把 Claude 格式的 tools 理解到位。实测中 Qwen 的新版模型在工具调用上表现最好基本能理解工具定义并按格式返回参数DeepSeek 的普通对话模型表现也不错但推理模型更适合只读场景让它带工具执行时偶尔会犹豫不决或返回非法格式Kimi 超长上下文是强项但在工具调用场景要看具体版本有些模型默认不支持函数调用需要选对型号或关掉工具再试。我的经验是如果任务依赖代码执行、文件读写这类强工具链最稳的还是切回 Claude 官方模型。DeepSeek、Qwen、Kimi 更适合定位成“内容生成助手”而不是“完全自主的 Agent”。5.3 计费差异别被每百万 token 的低价迷惑各家模型定价策略差异很大。只看官方页面上的 per million token 价格很容易做出错误选择。因为第三方模型进入 Claude 桌面端后每次请求都会携带比较长的系统提示和工具定义这部分输入 token 会重复计费。我的估算方式是按照实际单次请求来算一个包含工具定义的中等请求输入可能就有 2000 到 5000 token如果每次会话有 20 轮交互输入 token 总量就会被放得很大。所以批量简单总结用 qwen-turbo 这类低价小模型逻辑推理和代码问题可以给 deepseek-chat必要时用 deepseek-reasoner海量长文档分析优先 Kimi因为长上下文一次读完比切片多次调用更省一旦涉及复杂多步骤工具调用直接切回 Claude不要在第三方模型上硬省那点钱否则时间成本会吞掉 API 费用优势5.4 参数兼容性是隐藏的麻烦各大模型 API 虽然都自称 OpenAI 兼容细节上却有不少差异。Claude 格式里有 temperature、top_p、max_tokens 这些常规参数有些模型还可能支持 reasoning_effort、thinking 这类扩展参数。网关在翻译参数时如果原样解析容易导致上游报错尤其遇到未知字段时会直接 400。我在网关配置里做了一件事把不认识的参数全部过滤掉只保留 messages、model、max_tokens、temperature、stream 这些通用字段。这样当然会牺牲一部分高级控制能力但换来了稳定不会跑一会就断。对普通用户来说稳定比参数精细调优重要得多。6. 我在“放弃本地模型”之后的真实体会折腾完这一圈我最想说的是Ollama 是个好工具但它不是 Claude Desktop 的官方模型供应商。硬把本地模型塞进智能体客户端等于让家用轿车去跑 F1 赛道能开但体验和效率都达不到预期。而回到 DeepSeek、Qwen、Kimi 的官方 API才是把模型矩阵接入 Claude 桌面的正确姿势也是标题里那个“回归”的本意。那天跑通之后我删掉了 Ollama 里几个占了几十 GB 的模型文件留了一个轻量的 qwen3:8b 给其他 OpenAI 兼容客户端用。在 Claude Desktop 这边我保留了三套配置默认 Claude 官方模型、网关里的 deepseek-chat、网关里的 qwen-max/kimi-k2。切换成本已经降到十几秒比之前开三个网页再手动搬运上下文高效太多。如果你也打算照这个思路试我再分享一个小技巧让网关日志在返回头里标记实际命中的模型名否则你聊着聊着根本不知道当前是哪个模型在回复。我就发生过一次页面显示的是 Qwen实际上因为上次没切干净一直走的是 DeepSeek关键是我还盯着它输出的中文分析了半天。选型也好配置也好说到底就是为了让工具为工作流服务而不是为了“本地运行”这个想法本身牺牲效率。这套链路不适合所有人但对需要在多个模型间频繁切换的重度用户来说绝对值得一试。照着上面的网关配置思路先小成本跑通一个模型再逐步加供应商你会感觉一个全新的统一工作台慢慢在眼前搭起来了。