DeepSeek 正式支持 Anthropic API 格式：新双协议端点对路由层意味着什么

如果你的团队在代码层面使用 Anthropic SDK——不只是 Claude Code，而是所有基于 import anthropic 构建的项目——DeepSeek 新推出的 Anthropic 兼容端点将改变你的 provider 切换决策路径。你不再需要 OpenAI 兼容包装器或中间翻译层，就能将 Anthropic 格式请求路由到 DeepSeek V4 模型。该端点已正式上线并完整文档化。

发生了什么

DeepSeek 正式新增对 Anthropic API 消息格式的支持，访问地址为：

https://api.deepseek.com/anthropic

使用标准 Anthropic Python SDK，你现在可以直接指向 deepseek-v4-pro 或 deepseek-v4-flash：

import anthropic

client = anthropic.Anthropic(
    base_url="https://api.deepseek.com/anthropic",
    api_key="<你的 DeepSeek API Key>"
)

message = client.messages.create(
    model="deepseek-v4-pro",
    max_tokens=1000,
    system="You are a helpful assistant.",
    messages=[{"role": "user", "content": "Hello"}]
)

DeepSeek 随端点发布了完整字段兼容性矩阵，核心能力与差距如下：

支持：

• content 为字符串或 type="text" 数组——完全支持
• type="thinking"——支持（extended thinking 可用）
• type="tool_use"——完全支持（id、input、name）
• type="tool_result"——完全支持

静默忽略：

• cache_control——所有内容类型均被忽略
• citations——被忽略
• tool_result 上的 is_error——被忽略

不支持：

• type="image"——不支持
• type="document"——不支持
• type="search_result"、type="web_search_tool_result"——不支持
• type="server_tool_use"——不支持
• type="mcp_tool_use"、type="mcp_tool_result"——不支持
• type="code_execution_tool_result"——不支持
• type="container_upload"——不支持

有一个关键路由行为需要特别注意：如果你传入不被识别的模型名称，DeepSeek 会静默将其映射到 deepseek-v4-flash，而不是返回错误。这个静默 fallback 行为对运营层有重要影响。

为什么这对 AI 工程团队很重要

在这个端点出现之前，使用 Anthropic SDK 的团队想要切换 provider 有两条路：把 SDK 层改写为 OpenAI 格式，或者使用动态翻译代理。两种方案都会带来摩擦和潜在的兼容性问题。新端点消除了 Anthropic 格式路径上的翻译问题。

对于 Claude Code 用户而言，DeepSeek 早期指南中的环境变量写法（ANTHROPIC_BASE_URL=https://api.deepseek.com/anthropic）现在指向一个官方文档化、明确支持的端点，而不再是未文档化的兼容 shim。兼容性矩阵精确告诉你哪些功能可用、哪些不可用。

对于 Anthropic 原生代码库，这个端点意味着你可以在不迁移 SDK 的情况下评估 DeepSeek V4 模型。设置 base_url 和 api_key，其余代码不变，对照兼容矩阵观察实际行为。

成本账算法发生了显著变化。 仅使用文本内容、工具调用和 extended thinking 的 claude-3-sonnet 工作负载，大概率可以在不改代码的情况下路由至 DeepSeek V4 Pro，成本大幅降低。延迟和质量表现有差异，但对于那些特定内容类型，API 层面是兼容的。

路由与运营视角

字段兼容矩阵是这次发布中运营价值最高的文档。它定义了一个精确路由决策边界——不是简单的兼容/不兼容二元判断，而是路由网关需要理解的逐字段兼容性映射。

对于在 Anthropic 格式流量前运行路由网关的团队，有三个问题必须重点关注：

1. 静默模型 fallback 是路由安全隐患。 如果你的网关将未知模型字符串（例如版本化别名 claude-3-5-sonnet-20241022）不加改写地透传给 DeepSeek Anthropic 端点，DeepSeek 会静默使用 deepseek-v4-flash——更便宜、更快的模型——且响应中不会有任何提示。你的计费记录会显示 flash 用量，但你的应用期望的是 pro 级别质量。这产生了一个极难通过观测发现的静默质量衰退。

正确做法： 路由至该端点前，始终显式设置 DeepSeek 模型 ID（deepseek-v4-pro 或 deepseek-v4-flash），绝不透传 Anthropic 模型别名。

2. cache_control 被静默忽略。 如果你的应用依赖 Anthropic 提示词缓存来控制长系统提示或重复上下文的成本，该缓存在 DeepSeek 端点上不生效——但也不会报错。你将按 token 计费而无缓存收益。严重依赖提示词缓存的团队在将此类工作负载路由至该端点时，必须重新核算成本差异。

3. MCP 工具调用和 server tools 不支持。 随着 Agent 工作流向 MCP 原生工具架构演进，这成为一个重要的路由约束。如果你的 Agent 使用 mcp_tool_use 或 server_tool_use 内容块，这些请求必须保留在 Anthropic 端点上。路由运营决策：为 MCP 密集型 Agent 会话打标签，阻止它们被重路由至 DeepSeek Anthropic 端点。

路由团队决策框架：

| 工作负载类型 | 与 DeepSeek Anthropic 端点兼容？ | |---|---| | 纯文本 + 工具调用 | ✅ 兼容——直接可用 | | Extended thinking（type="thinking"） | ✅ 支持 | | 图片输入（type="image"） | ❌ 不支持 | | 提示词缓存（cache_control） | ⚠️ 静默忽略——无报错，无收益 | | MCP 工具（mcp_tool_use） | ❌ 不支持 | | 传入未知模型名称 | ⚠️ 静默 fallback 至 v4-flash | | Anthropic 模型别名（如 claude-3-5-sonnet-*） | ⚠️ 必须改写模型 ID |

TheRouter 用户应关注或尝试的事项

如果你正在运营一个处理 Anthropic 格式流量的路由网关，这里的规律直接适用于你的路由策略配置：

• 转发至 DeepSeek Anthropic 端点前重写模型 ID：始终映射到明确的 DeepSeek 模型 ID，不要透传 Anthropic 别名。
• 为 MCP Agent 会话单独打标签并路由：MCP 工具调用必须保留在 Anthropic 端点；纯文本或工具调用会话可以路由至 DeepSeek。
• 在请求管道中监控 cache_control 使用情况：如果提示词缓存是你应用的成本控制手段，在将那些请求路由至 DeepSeek 时需重新核算成本。
• 用你自己的工作负载组合验证，再把生产流量切换过去：在移动预算前，先对工具调用密集型和 extended thinking 工作负载运行评估，确认质量达标。

关注 DeepSeek Anthropic API 文档的后续更新——尤其是 type="image" 支持和 cache_control 行为，一旦补齐，该端点覆盖的工作负载范围将大幅扩展。