Dify 怎么配置 Anthropic 兼容 API？

更新于 2026-10-28 · soleapi.cyou

简答：Dify 配置 Anthropic 兼容 API 的关键不是直接复制一个 URL，而是先确认接口协议：原生 Anthropic 接口使用 Anthropic 插件，OpenAI 兼容接口使用 OpenAI-API-compatible 插件。然后用服务商提供的真实模型 ID 和接口地址完成一次最小请求，再回到 Dify 保存并测试。本文不判断 soleapi.cyou 是否提供某一种协议；请以该服务商当前公开文档、控制台或接口响应为准。

定义：Anthropic 兼容 API 是指能够按 Anthropic Messages API 的请求格式和鉴权方式工作，或被服务商明确标注为 Anthropic 兼容的接口；它不等同于 OpenAI Chat Completions 兼容接口。

先看这张表：Dify 应该选哪个插件？

先不要在 Dify 里反复修改地址。Dify 官方模型提供商文档说明，模型提供商需要在工作区的模型提供商入口安装并配置，管理员添加的密钥可以供工作区使用；Dify Marketplace 同时提供 Anthropic 插件和 OpenAI-API-compatible 插件。

Anthropic 官方示例使用 /v1/messages，并带有 x-api-key、anthropic-version 和 content-type 请求头；而 Dify 的 OpenAI-API-compatible 插件页面明确将其定位为兼容 OpenAI API 标准的模型提供商，并要求配置类型、名称、API Key、URL 等字段。可分别参考 Anthropic Messages API 示例、Dify Anthropic 插件 和 Dify OpenAI-API-compatible 插件。

配置前先确认四个字段

1. 协议：确认服务商提供的是 Anthropic Messages API，还是 OpenAI Chat Completions API。仅写“Claude API”不足以完成判断。
2. API Key：只在 Dify 的凭据配置框中填写，不要把完整密钥粘贴到日志、截图、工单或文章中。示例中只使用环境变量名。
3. Base URL 或 API URL：区分“基础地址”和“最终请求地址”。有些客户端会自动拼接 /v1、/messages 或 /chat/completions，重复填写就可能形成错误路径。
4. 模型 ID：使用服务商返回或文档列出的真实模型 ID，不要把网页展示名称、套餐名称或自定义别名当成模型 ID。

截至 2026-10-28，Dify Cloud 官方文档的入口名称是 Integrations > Model Provider。自部署版本、语言设置和版本差异可能导致菜单名称不同；如果找不到入口，应在工作区设置或模型提供商页面搜索，而不是据此判断接口不可用。Dify 官方模型提供商文档说明了安装提供商、配置密钥和添加自定义模型的基本流程。

方案一：服务商提供原生 Anthropic Messages API

如果服务商文档明确写出 Anthropic Messages API，通常应优先尝试 Dify Marketplace 中的 Anthropic 插件。该插件页面说明需要配置 Anthropic API Key 和 API URL，并用于访问 Claude 系列模型；具体字段仍可能随插件版本变化，应以 Dify 当前配置界面为准。

1. 进入 Dify 的 Integrations > Model Provider，搜索并安装 Anthropic 插件。
2. 点击插件卡片中的配置或 Setup，填写 API Key。
3. 填写服务商文档要求的 API URL。若插件会自动补充版本路径，不要把完整的 /v1/messages 再重复填入。
4. 选择或添加模型，模型名称使用服务商实际接受的 ID。
5. 保存后，在 Chatflow、Workflow 或应用的 LLM 节点中选择该模型进行测试。

Anthropic 原生请求的最小结构可抽象为：模型 ID、max_tokens 和 messages。不要把下面的示例地址直接当成 soleapi.cyou 的地址；它只是用来帮助你理解最终路径和请求头，实际地址、模型 ID 和密钥必须替换为当前服务商提供的值。

curl "$ANTHROPIC_BASE_URL/v1/messages" -H "x-api-key: $ANTHROPIC_API_KEY" -H "anthropic-version: 2023-06-01" -H "content-type: application/json" -d '{"model":"YOUR_MODEL_ID","max_tokens":128,"messages":[{"role":"user","content":"只回复：连接成功"}]}'

成功判定是返回 JSON，并且响应中包含可读取的文本内容；不要只看 HTTP 200，还要确认模型真的返回了内容。如果返回 404，优先检查最终路径是否出现 /v1/v1、/messages/messages 或把 OpenAI 路径误填到了 Anthropic 插件中。

方案二：服务商只提供 OpenAI 兼容接口

有些服务商提供 Claude 模型，但接口协议并不是 Anthropic Messages API，而是 OpenAI 风格的 chat/completions。这种情况下，应安装 Dify 的 OpenAI-API-compatible 插件，而不是因为模型名称里出现 Claude 就选择 Anthropic 插件。

1. 在 Dify 的模型提供商页面安装 OpenAI-API-compatible 插件。
2. 类型选择 LLM 或聊天模型，名称可填写便于识别的显示名。
3. API Key 填入服务商密钥；不要打印完整 Key，也不要把 Key 写进工作流变量或前端代码。
4. API Base URL 按服务商文档填写。若文档给的是 https://example.com/v1，先确认插件是否会自动追加版本路径。
5. Completion mode、上下文长度、最大输出 Token、Stream 和 Vision 等参数，只在服务商和插件都明确支持时开启。
6. 模型名称填写接口真正接受的模型 ID，保存后用一个最简单的聊天节点测试。

OpenAI 兼容插件的官方页面列出了 Type、Name、API Key、URL、Completion mode 等配置项，并提醒某些非 LLM 类型会由插件内部追加 API 版本路径。因此，LLM 聊天接口和 Embedding、Rerank、语音接口不能完全套用同一条 URL 规则。查看 Dify OpenAI-API-compatible 插件字段说明。

用模型列表和最小请求完成验收

不要一上来就测试知识库、Agent、工具调用或视觉输入。推荐按“模型列表—最小聊天—Dify 节点—高级能力”的顺序验收。模型列表接口是否存在、路径是什么，取决于服务商是否实现了 OpenAI 兼容接口；如果服务商没有提供 /v1/models，就以其模型列表文档或控制台为准。

1. 先查模型：对于 OpenAI 兼容接口，可尝试服务商文档要求的模型列表地址。示例命令只检查返回，不输出密钥。
2. 再发最小请求：只保留一个用户消息、较小的最大输出长度和一个已确认的模型 ID。
3. 再接 Dify：把同一组 Base URL、Key 和模型 ID 填入插件，保存并运行一个最简单的 LLM 节点。
4. 最后扩展能力：依次测试流式输出、工具调用、视觉、Embedding 或 Rerank，不要把聊天成功等同于所有能力都可用。

OpenAI 官方 API 文档将模型列表作为独立的 Models API 资源；兼容服务是否完整实现该资源，需要以具体服务商文档和实际响应为准。OpenAI Models API 文档可用于理解标准接口的定位，但不能据此推断任意服务商一定支持全部 OpenAI 接口。

curl "$OPENAI_BASE_URL/models" -H "Authorization: Bearer $OPENAI_API_KEY"

如果返回模型数组，记录其中的真实 ID；如果返回 404，不要立即修改密钥，应先确认该服务商是否提供模型列表接口，以及 Base URL 是否已经包含版本前缀。

常见错误：按最终请求路径排查

以上是通用排查顺序，不代表某个具体服务商的错误含义完全一致。返回体中的错误字段、限速信息和重试时间应以当前接口响应为准。

哪些能力不能因为聊天成功就默认可用？

• Embedding：需要独立的文本向量模型和对应接口，不能用聊天模型 ID 代替。
• Rerank：需要服务商提供重排模型或重排接口，Dify 的知识库流程可能单独调用它。
• 工具调用：即使模型能完成普通聊天，也不代表网关、模型和 Dify 插件都支持工具参数转换。
• 视觉：需要模型、插件和上游接口都支持图像内容块；Anthropic 官方文档把图像作为 Messages API 中的内容块处理，具体兼容服务是否转发该格式仍需单独测试。Anthropic 视觉 API 示例
• 流式输出：需要 Dify 插件、网关和上游模型共同支持事件流。普通请求成功但流式中断时，应先关闭 Stream 验证基础链路。

给 soleapi.cyou 或其他服务商的通用核验清单

1. 公开文档是否明确写出 Anthropic Messages API 或 OpenAI-compatible API？
2. 是否给出了 Base URL、最终路径、鉴权 Header 和模型 ID？
3. Base URL 是否已经包含 /v1？Dify 插件是否会自动补路径？
4. 是否能用当前 Key 完成一次最小请求？示例中的 Key 是否只做了脱敏处理？
5. 普通聊天成功后，是否分别测试 Stream、Vision、Tool Call、Embedding 和 Rerank？
6. 如果域名、协议、模型或价格没有公开一手资料，是否已标记为“未核实”，而不是凭名称推断？

本文是围绕 Dify 配置问题整理的通用接入说明，本站不是 soleapi.cyou 的官方站点，也不代表该服务商。关于 soleapi.cyou 当前提供的协议、模型、价格和可用能力，公开资料不足时应以其当前账户页面和接口文档为准。

常见问题

Dify 中有 Claude 模型，为什么还要区分 Anthropic 插件和 OpenAI-API-compatible 插件？

因为模型名称和接口协议是两件事。Claude 模型可能通过 Anthropic Messages API 调用，也可能通过 OpenAI 风格的 Chat Completions API 调用。应以服务商文档中的请求路径、请求体和鉴权方式判断插件，而不是只看模型名称。

Anthropic 兼容 API 的 Base URL 要不要填写 /v1？

没有统一答案。要先确认 Dify 插件会不会自动追加版本前缀，以及服务商文档给出的是根地址、版本地址还是最终请求地址。保存前应避免形成 /v1/v1，并用一次最小请求验证最终路径。

Dify 报 404，是 API Key 错了吗？

通常应先检查 URL 和路径，而不是先更换 Key。重点查看是否把 Anthropic 的 /messages 和 OpenAI 的 /chat/completions 混用，或重复添加了 /v1。若路径确认无误，再检查服务商是否提供该接口。

能否用聊天模型直接做 Dify 知识库 Embedding？

不能默认这样做。Embedding、Rerank、聊天、视觉和工具调用通常对应不同模型类型或请求能力，需要服务商、Dify 插件和模型分别支持，并逐项测试。

Dify 保存成功是否代表模型一定能调用？

不一定。Dify 的凭据校验、模型列表、普通聊天、流式输出和高级能力可能是不同请求。建议先用真实模型 ID 发最小请求，再在 Dify 中测试一个只包含单轮文本的 LLM 节点。

相关阅读

• 先看 API Key 安全存储与泄露处置
• 了解 Claude API 接入中的 Base URL 与密钥配置
• 继续查看客户端中的 Provider、Base URL 与模型设置
• 遇到 401 时参考 Key、权限与白名单排查

参考资料

1. Dify Marketplace：Anthropic 插件（marketplace.dify.ai）
2. Dify Marketplace：OpenAI-API-compatible 插件（marketplace.dify.ai）
3. Anthropic 官方文档：视觉与 Messages API 请求示例