Claude Desktop 终于能接第三方 API 了

产品更新

Claude Desktop 近期开放自定义 API 端点配置,用户可将请求转发至第三方或本地模型服务,但子代理模型硬编码、Windows 兼容性等问题仍待解决。

Anthropic 的桌面客户端 Claude Desktop 最近悄悄解锁了一个开发者等了很久的能力——自定义 API 端点。简单说,你现在可以把 Claude Desktop 的请求转发到任意兼容 Anthropic Messages 协议的后端,不管是第三方 API 聚合平台、自建代理,还是跑在本地的模型服务。

这不是一个大张旗鼓的官方发布,更像是能力的静默开放。消息最先在 Linux.do 社区发酵,开发者们迅速开始折腾配置、踩坑、分享经验。但正因为不是正式 feature launch,坑也不少。

到底改了什么

此前,Claude Desktop 是一个相当"封闭"的客户端。它绑定 Anthropic 官方 API,用户要么走订阅(Pro/Team),要么用官方 API Key,没有第三条路。想用第三方渠道的便宜额度?想接自己部署的模型?对不起,Claude Desktop 不支持。

现在的变化是:Claude Desktop 开始尊重 ANTHROPIC_BASE_URL 这个环境变量了。

这意味着你可以把 API 请求的目标地址从 https://api.anthropic.com 改成任何你想要的端点。配合 ANTHROPIC_AUTH_TOKEN 设置对应的密钥,Claude Desktop 就会把所有模型调用请求发到你指定的地方。

这个机制和 Claude Code(Anthropic 的命令行编程工具)是一脉相承的。Claude Code 早就支持通过环境变量配置自定义端点,走的是所谓的「LLM Gateway」模式。现在 Desktop 端跟上了,逻辑一致。

Claude Desktop 自定义 API 配置流程示意图,展示环境变量设置与请求转发路径

怎么配置

配置方式因操作系统而异,核心就是设置两个环境变量。

在 macOS 上,最直接的方式是在终端中设置环境变量后启动 Claude Desktop:

# 设置自定义 API 端点
export ANTHROPIC_BASE_URL=https://your-api-provider.com
export ANTHROPIC_AUTH_TOKEN=your-api-key-here

# 从终端启动 Claude Desktop(macOS)
open -a "Claude"

如果你希望每次启动都生效,可以把这两行写进 ~/.zshrc~/.bash_profile

对于需要持久化配置的场景,也可以通过 launchctl 设置环境变量:

launchctl setenv ANTHROPIC_BASE_URL https://your-api-provider.com
launchctl setenv ANTHROPIC_AUTH_TOKEN your-api-key-here

还有一种方式是直接修改 Claude Desktop 的配置文件。在 macOS 上,配置文件通常位于:

~/Library/Application Support/Claude/config.json

部分开发者反馈,在配置文件中可以通过类似以下结构指定自定义端点:

{
  "apiBaseUrl": "https://your-api-provider.com",
  "apiKey": "your-api-key-here"
}

但需要注意,这个配置文件的 schema 并没有被 Anthropic 官方文档化,不同版本之间可能存在差异。环境变量的方式目前是最可靠的。

实际用起来怎么样

先说能跑通的部分。

如果你的第三方 API 服务完整兼容 Anthropic Messages 协议(/v1/messages 端点),基本的对话功能是没问题的。发消息、收回复、流式输出,都能正常工作。对于日常使用 Claude Desktop 做文本处理、写作辅助、代码讨论的用户来说,体验和直连官方 API 几乎没有区别。

国内不少 API 聚合平台都兼容 Anthropic 协议,配置好之后可以直连使用,省去了挂代理的麻烦。像 OpenAI Hub 这类聚合平台本身就支持 Claude 系列模型的 Anthropic 协议转发,配置起来比较顺畅。

但坑也是真实存在的,而且有些还挺致命。

坑一:子代理模型硬编码

这是目前社区反馈最集中的问题。当你在 Claude Desktop 中使用涉及子代理(sub-agent)调用的功能时,客户端会尝试去请求一些硬编码的模型名称,比如 claude-haiku-4-5-20251001

问题在于,你的第三方 API 提供商未必支持这个精确的模型版本号。于是你会看到这样的报错:

There's an issue with the selected model (claude-haiku-4-5-20251001). 
It may not exist or you may not have access to it.

这个问题在 Claude Code 里同样存在。有开发者在社区里提到,Claude Code 的 CLI 遇到子代理拉取失败时至少还会回退(fallback),但 Desktop 端目前的回退机制似乎不够完善。

一个可能的 workaround 是在你的 API 代理层做模型名称映射——把 claude-haiku-4-5-20251001 这类带日期戳的精确版本号映射到你实际可用的模型上。但这需要你的代理服务支持这种路由逻辑,普通用户很难自己搞定。

在 Claude Code 的 CLI 中,有开发者发现可以通过修改配置 JSON 中的模型别名来"强行注入",让子代理请求走自定义的模型。Desktop 端是否有类似的配置入口,目前还在摸索中。

坑二:Windows 支持存疑

多位 Windows 用户反馈,按照同样的环境变量配置方式操作后,打开 Claude Desktop 看到的仍然是标准的登录界面,自定义 API 配置完全没有生效。

这可能和 Windows 上环境变量的生效机制有关——Windows 的环境变量需要通过系统设置面板配置,或者在 PowerShell 中用 $env:ANTHROPIC_BASE_URL = "..." 设置后在同一会话中启动应用。但即便如此,部分用户仍然无法成功。

目前来看,macOS 是这个功能的"一等公民",Windows 端可能还需要等后续版本的适配。

坑三:官方 API 和自定义 API 无法便捷切换

这是一个体验层面的问题。一旦你配置了自定义 API 端点,Claude Desktop 的所有请求都会走这个端点。想临时切回 Anthropic 官方 API?你得去改环境变量,然后重启应用。

社区里已经有人在问:"有没有能够切换 Claude Desktop 官方和其他 API 的方法?"

目前没有。Claude Desktop 不像 Claude Code 那样有 --model 参数可以在运行时切换,也没有 UI 层面的多端点管理。这是一个很明显的产品缺口。

和 Claude Code 的对比

说到这里,有必要把 Claude Desktop 和 Claude Code 在自定义 API 这件事上做个对比,因为两者的成熟度差距不小。

Claude Code 作为命令行工具,在多模型、多端点支持上已经走得相当远了。它支持的配置维度包括:

  • ANTHROPIC_BASE_URL:自定义 API 端点
  • ANTHROPIC_AUTH_TOKEN:自定义认证密钥
  • ANTHROPIC_MODEL:指定主模型
  • ANTHROPIC_SMALL_FAST_MODEL:指定轻量模型(用于子任务)
  • API_TIMEOUT_MS:请求超时时间
  • CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC:禁用非必要流量

一个典型的 Claude Code 第三方模型配置长这样:

# 以 Fish Shell 为例
set -gx ANTHROPIC_BASE_URL https://api.deepseek.com/anthropic
set -gx ANTHROPIC_AUTH_TOKEN your-deepseek-key
set -gx API_TIMEOUT_MS 600000
set -gx ANTHROPIC_MODEL deepseek-chat
set -gx ANTHROPIC_SMALL_FAST_MODEL deepseek-chat
set -gx CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC 1

注意最后那个 CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC,它可以阻止 Claude Code 向 Anthropic 官方发送遥测和非必要请求,对于纯第三方部署场景很有用。

更进一步,社区还发展出了专门的路由工具。比如 Claude Code Router(CCR),它本质上是一个本地代理,可以根据任务类型把请求分发到不同的模型提供商:

{
  "Router": {
    "default": "deepseek,deepseek-chat",
    "background": "ollama,qwen2.5-coder:latest",
    "think": "deepseek,deepseek-reasoner",
    "longContext": "openrouter,google/gemini-2.5-pro-preview",
    "longContextThreshold": 60000,
    "webSearch": "gemini,gemini-2.5-flash"
  }
}

这种配置的意思是:普通任务走 DeepSeek,后台任务走本地 Ollama,需要深度思考的走 DeepSeek-Reasoner,长上下文走 Gemini 2.5 Pro,搜索任务走 Gemini Flash。一套组合拳下来,成本和效果都能优化。

还有 CC-Switch 这样的桌面可视化工具,提供图形界面来管理多套配置,一键切换不同的 API Key 和供应商。

相比之下,Claude Desktop 目前的自定义 API 支持还处于非常初级的阶段——能用,但粗糙。没有模型选择,没有路由策略,没有便捷切换,子代理还会出问题。

这件事为什么重要

表面上看,这只是一个客户端支持自定义 API 端点的小更新。但放在更大的背景下,它反映了几个值得关注的趋势。

第一,Anthropic 在逐步开放生态。Claude Desktop 一直以来都是一个"围墙花园"式的产品,用户只能用 Anthropic 的服务。现在开放自定义端点,说明 Anthropic 意识到了开发者对灵活性的需求。这和 OpenAI 的 ChatGPT 客户端形成了有趣的对比——ChatGPT 桌面端至今没有类似的自定义 API 能力。

第二,"协议兼容"正在成为 AI 基础设施的关键词。Anthropic Messages 协议(/v1/messages)和 OpenAI Chat Completions 协议(/v1/chat/completions)是目前最主流的两套 LLM API 标准。越来越多的模型提供商同时兼容这两套协议,这意味着客户端只要支持自定义端点,用户就能接入几乎任何模型。协议层面的标准化,正在让"用哪个客户端"和"用哪个模型"这两个选择彻底解耦。

第三,成本优化的需求是真实的。Claude 3.5 Sonnet 的 API 价格是每百万输入 token 3 美元、输出 15 美元,Claude 3 Opus 更贵。对于高频使用的开发者来说,通过第三方渠道获取更优惠的价格,或者在不同任务上使用不同价位的模型,是非常现实的需求。Claude Desktop 支持自定义 API,直接打开了这个可能性。

给想折腾的人几个建议

如果你打算现在就上手配置,这里有几点实用建议:

  1. 优先在 macOS 上尝试。Windows 端的兼容性问题目前还没有明确的解决方案,贸然折腾可能浪费时间。

  2. 确保你的 API 提供商支持 Anthropic Messages 协议。不是所有聚合平台都同时支持 OpenAI 格式和 Anthropic 格式,配置前先确认。如果只支持 OpenAI 格式(/v1/chat/completions),那是接不上 Claude Desktop 的。

  3. 做好子代理报错的心理准备。如果你主要用 Claude Desktop 做简单对话,问题不大。但如果你依赖 Artifacts、Projects 等高级功能,子代理模型找不到的问题可能会频繁出现。

  4. 如果你同时也用 Claude Code,建议先在 CLI 端把配置跑通,确认你的 API 提供商没有兼容性问题,再迁移到 Desktop 端。CLI 的调试信息更丰富,出了问题更容易排查。

  5. 考虑在本地搭一层代理做模型名称映射。哪怕只是一个简单的 Nginx 反向代理加上 sub_filter 做字符串替换,也能解决不少模型名称不匹配的问题。

接下来会怎样

从社区的讨论热度来看,这个功能的需求是明确的。Anthropic 大概率会在后续版本中进一步完善——至少 Windows 支持和官方/自定义 API 的切换功能应该会补上。

更值得期待的是,如果 Claude Desktop 能像 Claude Code 那样支持 ANTHROPIC_MODELANTHROPIC_SMALL_FAST_MODEL 环境变量,让用户自己指定主模型和子代理模型,那子代理硬编码的问题就迎刃而解了。

再往远了想,如果 Anthropic 在 Claude Desktop 的设置界面里直接加入多端点管理的 UI——类似 CC-Switch 做的事情——那对普通用户的友好度会上一个大台阶。毕竟不是每个人都愿意去改环境变量和配置文件。

不过话说回来,Anthropic 在这件事上的态度一直比较暧昧。自定义 API 端点本质上是在鼓励用户绕过官方付费渠道,这和 Anthropic 的商业利益是有冲突的。所以这个功能到底会被大力推广还是保持"能用但不宣传"的状态,还得观察。

对开发者来说,不管 Anthropic 官方怎么想,能自定义端点就是好事。选择权回到了用户手里,这永远是对的方向。


参考来源: