DeepSeek Anthropic API 端点：api.deepseek.com/anthropic 路由风险

如果你的团队在代码层面使用 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 端点。

路由团队决策框架：

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 行为，一旦补齐，该端点覆盖的工作负载范围将大幅扩展。