DeepAI Paper API 中转站,DeepAI Agent 接入,代码 Agent 教程,客户端接入,错误排查 Claude Code 接入 DeepAI API 中转站:ANTHROPIC_BASE_URL 与 /v1/messages 怎么配置

Claude Code 接入 DeepAI API 中转站:ANTHROPIC_BASE_URL 与 /v1/messages 怎么配置

Claude Code 是很多开发者日常写代码、改仓库、跑命令的终端 Agent。把它接入 DeepAI API 中转站 这类 LLM Gateway 时,最容易踩的坑不是“有没有自定义 Base URL”,而是“这个 Base URL 到底暴露的是 Anthropic API 格式,还是 OpenAI-compatible 格式”。Claude Code 走的是 Anthropic Messages 协议,核心路径是 /v1/messages,不能直接拿 /v1/chat/completions 当作目标端点。

Claude Code 接入 DeepAI API 中转站 ANTHROPIC_BASE_URL 与 v1 messages 配置排查图
ANTHROPIC_BASE_URL 用于 LLM Gateway,目标必须能处理 Anthropic 格式的 /v1/messages

问题背景:自定义 Claude API Endpoint 的真实含义

这个话题来自 Claude Code Issue #216。用户希望 Claude Code 支持自定义 Claude API endpoint,这样企业网络、代理服务或自建 LLM Gateway 才能继续使用 Claude Code。Issue 评论里维护者后来明确说明:Claude Code 可以使用 HTTP_PROXYHTTPS_PROXYANTHROPIC_BASE_URL,但它们不是一回事。

简单说,HTTP_PROXY / HTTPS_PROXY 是网络代理,负责把请求通过公司代理服务器转发出去;ANTHROPIC_BASE_URL 是 LLM Gateway 地址,Claude Code 会把 Anthropic API 请求发到这里。官方 LLM Gateway 文档也把网关价值总结为集中鉴权、使用量追踪、成本控制、审计日志和模型路由,这正是 DeepAI API 中转站这类服务的核心价值。

关键区别:Anthropic 格式不是 OpenAI-compatible 格式

Issue #216 后续评论里还有一个非常关键的确认:Claude Code 目前不能直接使用 OpenAI-compatible API。维护者说明,ANTHROPIC_BASE_URL 应该指向一个托管 Anthropic API 格式 endpoint 的地址,也就是能处理 /v1/messages 的网关。如果你的中转站只暴露 /v1/chat/completions,Claude Code 直接接上去通常会出现 404、API Connection Error、模型找不到或请求体格式不匹配。

# 错误理解:把 OpenAI-compatible 接口当成 Claude Code endpoint
https://api.deepai.wang/v1/chat/completions
# 正确方向:确认网关是否提供 Anthropic Messages 格式
POST https://api.deepai.wang/v1/messages

实际配置时,ANTHROPIC_BASE_URL 应该填“能够承载 /v1/messages 的网关基地址”。不同网关的路径设计可能不同:有的统一入口是根地址,有的需要填写某个 pass-through 前缀。最稳的方法是先用 curl 测试你的 DeepAI API 中转站是否能响应 Anthropic Messages 请求,再写入 Claude Code。

DeepAI API 中转站接入示例

如果你的 DeepAI API 中转站已经开放 Anthropic-compatible / Claude Messages 路由,可以按下面思路配置。注意不要把真实 Key 写进团队文档或 Git 仓库。

export ANTHROPIC_BASE_URL="https://api.deepai.wang"
export ANTHROPIC_AUTH_TOKEN="YOUR_DEEPAI_KEY"

如果中转站的 Anthropic 路由有前缀,则把 ANTHROPIC_BASE_URL 改成该前缀。例如某些 LLM Gateway 会用 /anthropic 作为 pass-through endpoint。判断标准只有一个:Claude Code 最终发出的 /v1/messages 请求能被中转站正确接收。

curl https://api.deepai.wang/v1/messages \
  -H "Content-Type: application/json" \
  -H "x-api-key: YOUR_DEEPAI_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -d '{
    "model": "your-claude-compatible-model",
    "max_tokens": 256,
    "messages": [
      {"role": "user", "content": "用一句话说明 Claude Code 接入中转站的价值"}
    ]
  }'

如果 curl 能返回 Anthropic Messages 格式响应,而 Claude Code 仍失败,再排查环境变量优先级、认证头、模型名映射和本地 settings.json。反过来,如果 curl 都返回 404 或路径不匹配,就说明当前中转站还没有暴露 Claude Code 需要的 Anthropic API 格式。

OAuth 订阅被 ANTHROPIC_BASE_URL 覆盖的问题

另一个值得放进排查清单的问题来自 Claude Code Issue #23022。用户同时拥有 Max / Pro 订阅 OAuth 凭据,又在 settings.json 或环境变量里保留了自定义 ANTHROPIC_BASE_URL。结果 Claude Code 静默使用自定义 URL,而不是官方 Anthropic API,最终出现 404 “model not found” 或显示 API Usage Billing 等混乱状态。

这对接入 DeepAI API 中转站的团队也很重要:如果你正在测试中转站,就显式保留 ANTHROPIC_BASE_URL 和中转站 Key;如果你想切回 Claude.ai 订阅或官方 API,就清理掉自定义 URL,并重新登录。不要让旧环境变量留在 shell profile、CI 配置或 ~/.claude/settings.json 里。

排查步骤:从路径到认证逐层确认

  1. 确认你的 DeepAI API 中转站是否提供 Anthropic Messages 格式的 /v1/messages,而不只是 OpenAI-compatible 的 /v1/chat/completions
  2. 用 curl 直接测试 /v1/messages,确认路径、认证头、模型名和响应格式都正确。
  3. 在 Claude Code 运行环境中检查 ANTHROPIC_BASE_URLANTHROPIC_AUTH_TOKENANTHROPIC_API_KEY 是否冲突。
  4. 不要把 HTTPS_PROXY 当成 LLM Gateway。代理只转发网络流量,不会把 OpenAI 请求体转换成 Anthropic Messages。
  5. 如果使用订阅 OAuth,检查是否有残留 ANTHROPIC_BASE_URL 覆盖了官方 API 调用。

常见坑位

  • 把 OpenAI-compatible 当作 Claude-compatible:Claude Code 需要 Anthropic Messages 格式,不能直接吃 /v1/chat/completions
  • Base URL 多写路径:如果网关基地址会自动拼接 /v1/messages,不要再手动写到更深路径;具体以 curl 实测为准。
  • 认证头不匹配:Anthropic Messages 通常使用 x-api-keyanthropic-version,而某些网关也支持 Authorization,要看中转站实现。
  • 模型名未映射:Claude Code 请求的模型名要能被 DeepAI API 中转站映射到真实上游模型。
  • 旧环境变量残留:测试本地 LLM 后忘记清理 ANTHROPIC_BASE_URL,会让官方订阅请求被发到错误网关。

DeepAI API 中转站的 SEO 和产品价值

从 SEO 角度看,“Claude Code 自定义 endpoint”“ANTHROPIC_BASE_URL 不生效”“Claude Code /v1/messages 404”“LLM Gateway 和 HTTP Proxy 区别”都是很强的长尾关键词。真正搜索这些词的用户,通常已经在企业网络、团队中转站或多模型路由里遇到了具体问题。文章要给他们的不是泛泛介绍,而是可执行的路径验证、环境变量检查和中转站日志排查。

从产品角度看,DeepAI API 中转站如果同时支持 OpenAI-compatible 和 Anthropic-compatible 路由,就能覆盖 Cherry Studio、Dify、n8n、OpenClaw、Claude Code 等不同客户端。关键是文档必须把协议边界写清楚:OpenAI 客户端走 /v1/chat/completions,Claude Code 走 Anthropic Messages 格式,Embedding 和图像模型又有各自路径。边界清楚,用户排查成本就会低很多。

参考资料

总结

Claude Code 接入 DeepAI API 中转站时,先确认协议:ANTHROPIC_BASE_URL 需要的是能处理 Anthropic Messages /v1/messages 的 LLM Gateway,而不是普通 OpenAI-compatible /v1/chat/completions。用 curl 验证路径和认证,再配置 Claude Code 环境变量;如果要切回官方订阅,记得清理残留 ANTHROPIC_BASE_URL。把协议、路径、认证和模型映射分开排查,Claude Code 的中转站接入会稳定得多。

Related Post

Codex cli deepai responses api missing reasoning item.png

Codex CLI 接入 DeepAI API 中转站:Responses API 缺 reasoning item 导致第二轮 400Codex CLI 接入 DeepAI API 中转站:Responses API 缺 reasoning item 导致第二轮 400

Codex CLI 通过自定义 Responses API Provider 或 Azure/中转站调用 GPT-5 Codex 时,如果第一轮成功、第二轮报 message missing reasoning item,通常是 response item 与 reasoning item 没有被完整保存和回放。本文结合 openai/codex Issue #6375、#5990 与 PR #3528,整理 DeepAI API 中转站场景下的排查与修复方法。

Dify deepai openai compatible localhost connection refused.png

Dify 接入 DeepAI API 中转站:OpenAI-API-compatible 的 localhost 连接失败排查Dify 接入 DeepAI API 中转站:OpenAI-API-compatible 的 localhost 连接失败排查

Dify 通过 OpenAI-API-compatible 接入 LiteLLM、DeepAI API 中转站或本地代理时,curl 本机可用但 Dify 校验报 localhost connection refused,通常是网络可达性问题。本文结合 Dify Issue #4460 整理 Cloud、Docker、自托管场景下的 Base URL 排查方法。

Claude code deepai mcp empty params serialization.png

Claude Code 接入 DeepAI API 中转站:MCP 工具参数变成空对象 {} 的排查Claude Code 接入 DeepAI API 中转站:MCP 工具参数变成空对象 {} 的排查

Claude Code 使用 MCP 工具时,如果工具被调用但 MCP Server 收到的 arguments 变成 {},不要只排查 API 中转站。本文结合 anthropics/claude-code Issue #3966,讲清如何区分 DeepAI API 中转站请求、模型 tool use、Claude Code MCP 参数序列化和 MCP Server schema 四个层面。