Dify 接入 Claude API:先选协议,再完成配置与验证
简答:Dify 接入 Claude API,优先选择与接口协议匹配的模型提供商:直连 Anthropic API 就使用 Anthropic 提供商,使用中转或路由服务则按其文档选择 OpenAI 兼容或原生 Anthropic 兼容插件。最小流程是:安装提供商 → 填写 API Key、Base URL 和模型 ID → 保存并测试 → 在应用中选择该模型。本文按 2026-11-08 核验到的官方资料整理,Dify 菜单、插件名称和字段可能随版本变化。
定义:Dify 接入 Claude API,是把 Claude 的模型凭据和接口地址配置到 Dify 的模型提供商中,使 Chatbot、Workflow 或 Agent 能调用对应模型。
先看这张表:你应该选哪种接入方式
不要先复制别人的 Base URL 或模型名称。先确认你手里的接口属于哪一种协议,再决定 Dify 中安装或配置哪个提供商。Dify 官方文档说明,模型提供商通常在工作区的模型提供商区域安装、配置,模型凭据会供该工作区的应用使用;具体入口和权限以当前 Dify 实例页面为准。可参考 Dify 模型提供商文档。
| 你的接口来源 | Dify 中的选择思路 | 通常需要填写 | 主要核验点 |
|---|---|---|---|
| Anthropic 原生 API | 安装或配置 Anthropic 模型提供商 | API Key、模型 ID;部分场景可能需要其他凭据字段 | 接口是否指向 Anthropic Messages API,Key 是否有效,模型 ID 是否仍可用 |
| 提供商明确支持 OpenAI 兼容协议 | 选择 OpenAI 兼容类模型提供商或该服务商的 Dify 插件 | API Key、Base URL、模型 ID、模型类型或 Completion mode | 服务商是否支持 Dify 使用的请求格式、流式响应和目标模型 |
| 提供商明确支持原生 Anthropic Messages API | 选择对应的原生 Anthropic 兼容插件 | API Key、API Base URL、模型名、Max Tokens 等 | 插件字段和服务端接口是否一一匹配 |
| 不清楚协议 | 先查服务商 API 文档,不要凭名称猜测 | 以文档为准 | 重点确认请求路径、认证头、响应格式和流式协议 |
关键边界:“Claude 模型”不等于“所有接口都能用 Anthropic 插件”。模型名称、Base URL 和请求协议必须来自同一个接口提供方。
第一步:在 Dify 中安装并配置模型提供商
截至 2026-11-08,Dify 官方资料显示,模型提供商通常从工作区的模型提供商区域安装;安装后点击配置或添加模型,再输入凭据。云版和自部署版的页面文字、插件安装位置以及可见字段可能不同,下面使用功能名称描述,不把某个菜单路径当成永久规则。
- 登录 Dify,打开当前工作区的模型提供商设置。若看不到入口或无法保存,先核对当前账号角色、工作区权限和 Dify 版本。
- 搜索并安装与协议匹配的提供商。官方 Anthropic 接入优先使用 Anthropic 模型提供商;兼容接口则选择对应的兼容提供商或服务商插件。
- 在配置表单中填写凭据。API Key 只粘贴密钥本身,不要把
Bearer、引号或换行一起复制;Base URL 按提供商文档填写,不能默认使用某个固定地址;模型 ID 必须是该接口实际接受的标识。 - 如果页面支持添加自定义模型,先确认模型类型是文本生成或聊天模型,再填写模型名称、上下文长度、最大输出 Token 等字段。没有证据时不要自行填写模型上下文上限。
- 保存后在 Chatbot、Workflow 或 Agent 中选择刚添加的模型,用一句短 Prompt 进行测试。
Dify 文档还提示,工作区中的模型凭据可能被多个应用使用,因此不要把生产 Key 直接放进公开工作区;建议为开发和生产分开管理密钥,并在服务商控制台设置用量或权限边界。
第二步:原生 Anthropic API 的认证与字段核验
Anthropic 官方文档显示,原生 Claude API 的 REST 地址是 https://api.anthropic.com,Messages API 的请求路径是 POST /v1/messages。当前官方认证文档把静态 API Key 的直接请求写成 Authorization: Bearer <key>,同时说明 x-api-key 仍可作为兼容的旧式认证头使用;不要据此推断每个 Dify 插件都允许你手动选择认证头。请以 Anthropic Authentication 文档和当前插件实现为准。
对于原生直连,至少核对以下项目:
- API Key:从 Claude Console 创建并安全保存。官方文档说明,密钥完整值通常只在创建时显示一次。
- 认证方式:Dify 表单一般只要求输入 Key;由提供商插件负责把凭据转换为请求头。若插件额外要求自定义字段,按插件说明填写,不要把
Authorization: Bearer整段当作 Key。 - Workspace:Anthropic 官方说明,是否需要
anthropic-workspace-id取决于密钥是否绑定到工作区以及该凭据可作用于哪些工作区。不要无条件添加占位 Workspace ID。 - 版本头:原生 HTTP 请求需要 Anthropic 版本信息;使用 Dify 提供商时通常由插件处理,若插件要求手动填写,则以它支持的版本为准。
- 模型 ID:以 Anthropic 当前模型文档、Console 或接口验证结果为准,不要把网上旧教程中的模型名直接复制。
官方 API 概览列出了 Messages API、模型列表和错误处理入口,具体请求字段可查看 Claude API overview 与 Create a Message。
第三步:用最小请求验证,而不是直接调试复杂工作流
如果 Dify 保存配置失败,先在同一台能访问接口的服务器上做最小请求。请求只验证三件事:网络可达、认证有效、模型 ID 可接受。示例中的模型 ID 必须替换为你从当前服务商文档或控制台核实到的值,不能直接照抄占位符。
Bash 示例:按条件添加 Workspace 头
export ANTHROPIC_API_KEY='替换为你的 API Key'
export CLAUDE_MODEL='替换为已核实的模型 ID'
export ANTHROPIC_WORKSPACE_ID='如果凭据要求则填写,否则留空'
headers=(-H "Authorization: Bearer ${ANTHROPIC_API_KEY}" -H "anthropic-version: 2026-10-21" -H "content-type: application/json")
if [ -n "${ANTHROPIC_WORKSPACE_ID}" ]; then headers+=(-H "anthropic-workspace-id: ${ANTHROPIC_WORKSPACE_ID}"); fi
curl -sS -X POST "https://api.anthropic.com/v1/messages" "${headers[@]}" --data "{\"model\":\"${CLAUDE_MODEL}\",\"max_tokens\":32,\"messages\":[{\"role\":\"user\",\"content\":\"Reply with OK\"}]}"
如果服务器上的 curl 不支持某些增强参数,不要先改接口配置;先使用上面的基础参数并直接查看 HTTP 状态码和响应体。
PowerShell 示例:不要使用反斜杠续行
$apiKey = "替换为你的 API Key"
$model = "替换为已核实的模型 ID"
$headers = @{ Authorization = "Bearer $apiKey"; "anthropic-version" = "2026-10-21"; "content-type" = "application/json" }
$workspaceId = ""
if ($workspaceId) { $headers["anthropic-workspace-id"] = $workspaceId }
$body = @{ model = $model; max_tokens = 32; messages = @(@{ role = "user"; content = "Reply with OK" }) } | ConvertTo-Json -Depth 5
Invoke-RestMethod -Method Post -Uri "https://api.anthropic.com/v1/messages" -Headers $headers -Body $body
成功判定不是只看 HTTP 200,还应检查响应是否包含可识别的文本内容、模型字段或请求 ID。不同 Dify 插件和兼容服务的响应结构可能不同,因此最终还要回到 Dify 的模型测试按钮验证。
错误现象—优先检查—下一步
| 现象 | 优先检查 | 下一步 |
|---|---|---|
| 401 | Key 是否复制完整、是否过期或被撤销;是否把 Bearer 前缀错误地填进 API Key 字段 | 用最小请求单独验证;若直连 Anthropic,按官方认证文档确认认证头和 Workspace 条件 |
| 403 | 当前账号、Key、工作区或接口是否有权限;Dify 当前用户是否能管理模型提供商 | 查看服务商控制台权限与 Dify 工作区角色,不要仅通过更换模型解决 |
| 404 | Base URL、路径和模型 ID 是否混用;是否把完整请求路径错误填入 Base URL | 区分“路由不存在”“模型不存在”和“权限隐藏”;逐项对照服务商文档 |
| 429 | 请求频率、并发、账户额度或服务商限速 | 查看响应头和错误体,按服务商的 Retry-After 或限速说明降低并发 |
| 超时 | Dify 容器到接口的 DNS、代理、防火墙、TLS 和出口网络 | 在 Dify 所在服务器执行最小请求,再检查容器日志;不要先增加模型参数 |
| 流式输出中断 | 插件是否支持流式、反向代理是否缓冲、网关是否设置较短超时 | 先关闭流式测试非流式响应,再逐层恢复流式和代理配置 |
| model not found | 模型 ID 是否属于当前接口,是否已下线或需要额外权限 | 以当前服务商模型列表或控制台为准;不要把模型显示名当作 API ID |
Anthropic 官方错误文档将 400、401 等错误区分为请求格式和认证问题;可查看 Claude API errors,再结合 Dify 日志中的状态码、响应体和请求时间定位。
Dify Cloud、自部署和兼容接口的边界
Dify Cloud 与自部署版都可能使用模型提供商和插件,但可安装插件、默认提供商、权限策略及界面字段不一定相同。Dify 官方文档明确提到,提供商凭据属于工作区范围,只有具备相应权限的用户才能管理;如果你的页面没有某个入口,应以当前实例显示为准,并核对管理员设置。
如果你使用的是兼容接口,优先向服务商确认四项内容:第一,Base URL 是否已经包含或不包含 /v1;第二,模型请求是 OpenAI Chat Completions、Responses,还是原生 Anthropic Messages;第三,是否支持流式、工具调用和 Dify 所需的角色格式;第四,模型 ID、限速、上下文长度和计费方式是否会变化。没有公开一手资料的项目,不要把价格、稳定性、隐私留存或“完全兼容”写成确定结论。
如果你使用 Marketplace 中的特定原生兼容插件,应只按该插件页面列出的字段配置。以 Dify Marketplace 的 Claude Proxy 页面为例,它描述的是连接到实现原生 Anthropic Messages API 的自定义代理端点;这不能代表所有 Dify 版本或所有兼容服务都使用相同字段。
配置成功后的安全检查
- 不要把 API Key 写进前端 JavaScript、公开仓库、截图或工作流文本。
- 在 Dify 工作区中只给必要人员配置权限;测试 Key 和生产 Key 分开。
- 为 Key 设置合理的过期、停用和轮换策略;发现泄露时立即在服务商控制台停用或删除。
- 记录调用时间、模型 ID、HTTP 状态码和请求 ID,但不要把完整 Key 写入日志。
- 如果经过中转或路由服务,先核对数据留存、日志用途、模型同步、限速、并发和故障联系渠道;无法核实的项目写成“需核实”。
本文是独立整理的接入指南,不代表 Dify 或 Claude 官方。品牌归属、当前插件字段和服务状态请以对应官方页面及你的实例实际内容为准。
常见问题
Dify 接入 Claude API 时,Base URL 应该填什么?
没有一个适用于所有场景的固定值。原生 Anthropic API、OpenAI 兼容服务和原生 Anthropic 兼容代理的 Base URL 规则不同;先确认协议,再按对应官方文档填写,并核对是否需要或禁止末尾的 /v1。
Dify 中 API Key 应该填写 Bearer 之前还是之后?
如果 Dify 字段名称是 API Key,通常只填写密钥本身,不要把 Bearer 一起填入。Anthropic 官方直接 HTTP 示例使用 Authorization: Bearer 认证,但具体 Dify 插件负责如何生成请求头,应以当前插件字段和文档为准。
为什么 Dify 保存 Claude 配置时提示 401?
先检查 Key 是否完整、是否已过期或撤销,以及是否把错误的认证前缀填进了 Key 字段;然后在 Dify 所在环境执行最小请求。若原生直连,还要核对 Workspace 条件和模型 ID。
Dify 报 404,是接口地址错还是模型不存在?
两者都有可能。先把 Base URL、请求路径和模型 ID 分开检查:如果路由不存在,通常是地址或协议不匹配;如果路由可达但模型不可用,则重点核对模型 ID、权限和模型生命周期。
可以直接使用网上教程里的 Claude 模型 ID 吗?
不建议。模型 ID 会随服务商、接口类型和生命周期变化,应该从当前官方模型文档、控制台或该接口的验证结果中确认;教程中的显示名不一定是 API 实际接受的 ID。
Dify Cloud 和自部署版的配置步骤完全一样吗?
不一定。两者都可能使用模型提供商和插件,但可安装插件、菜单文字、权限和字段会随版本或实例配置变化。本文给出的是通用决策和核验方法,实际操作应以当前实例页面为准。
相关阅读
- 先看 Claude Console API Key 的创建与保存方法
- 了解另一个 AI 工具配置 Claude API 的字段核验思路
- 如果遇到 429,查看限速与重试排查表
- 使用兼容接口前,先看中转服务的选择与测试清单
参考资料
- Dify 官方文档:Model Providers
- Claude Platform Docs:Authentication(platform.claude.com)
- Claude Platform Docs:API overview(platform.claude.com)
- Claude API Reference:Create a Message(platform.claude.com)
- Claude API Reference:Errors(platform.claude.com)
- Dify Marketplace:Claude Proxy(marketplace.dify.ai)