跳到主要内容
Router One
返回博客

Dify、Flowise、Langflow、n8n 横评：低代码 LLM 应用搭建工具共用一把网关 Key

发布作者Router One 团队方法说明
DifyFlowiseLangflown8n开发工具横向对比指南

四个可视化的 LLM 应用搭建工具，同一个问题：把模型调用改走 Router One 之后，到底变了什么？工具本身没有变：Dify 搭应用和知识库，Flowise 把 LangChain JS 节点连成流程，Langflow 在画布上连接各种组件，n8n 运行业务工作流，AI Agent 只是其中一个节点。变的是底下那次请求：一把 sk- Key，/models 里的精确模型 ID，以及每次模型调用在 Dashboard → Logs 里的一条 Trace，含模型、tokens、费用、延迟、状态和 request_id。网关负责模型调用，流程仍由搭建工具运行。

一句话结论。Dify：OpenAI-API-compatible 供应商，每个模型一条，API endpoint 字段填带 /v1 的 base URL。Flowise：OpenAI Custom Model 节点，Model Name 可手填，Base Path 在 Additional Parameters 里。Langflow：Settings → Model Providers → OpenAI Compatible，模型从 /v1/models 发现。n8n：OpenAI 凭证的 Base URL；GPT 和 DeepSeek 系列以外的 ID，还要在 OpenAI Chat Model 节点上关掉 Use Responses API。

对照表

工具运行位置怎样指向网关实际协议模型 ID 怎么填留在工具侧的部分
DifyDify Cloud，或 Docker Compose 自托管（在 http://localhost/install 初始化）Model Provider → OpenAI-API-compatible：Model Name、API endpoint https://api.router.one/v1、API KeyChat Completions；API Type 字段可以改选 Responses手填，每个模型一条供应商配置应用、工作流节点、Agent 策略、知识库、应用 API
Flowisenpm（npx flowise start）或 Docker Compose；http://localhost:3000OpenAI API 凭证 + OpenAI Custom Model 节点：Model Name、Base Path https://api.router.one/v1Chat Completions；LangChain 会在三种情况下改发 /v1/responsesOpenAI Custom Model 上手填；默认 OpenAI 节点是固定下拉链、Agent 循环、记忆、Document Stores、Prediction API
Langflowuv pip install langflow、Langflow Desktop 或 Docker；http://127.0.0.1:7860Settings → Model Providers → OpenAI Compatible：Base URL https://api.router.one/v1、API KeyChat Completions从 GET /v1/models 发现，按模型启用；Model Name Override 可手填 ID组件、Agent 循环与工具、流程 API 和 MCP server
n8nn8n 官方云服务，或 Docker 自托管；编辑器在 http://localhost:5678Credentials → OpenAI：API Key、Base URL https://api.router.one/v1，再在 OpenAI Chat Model 节点上选用当前版本的 OpenAI Chat Model 节点默认发 Responses；关掉 Use Responses API 后发 Chat CompletionsFrom List（从凭证的 /models 路径加载）或 ID（手填）触发器与 webhook、工作流节点、AI Agent 循环、工具和记忆子节点

Chat Completions 是四者的共同点：/v1/chat/completions 服务目录里的所有聊天模型（GPT、Claude、Gemini、Grok 和 DeepSeek 系列），所以同一个 anthropic/claude-sonnet-5（连同前缀）在四个工具里都能用。/v1/responses 只对当前上架的 GPT 系列和 DeepSeek ID 原生提供；其他 ID 发到那里会收到 HTTP 400，消息里写着 must be called via。四个工具里有两个会在你没有要求的情况下走到这个端点。Flowise 是通过 LangChain，有文档可查的三种情况：在默认 OpenAI 节点上选了 Reasoning Summary，在 Agentflow V2 的 Agent 节点上勾选了 OpenAI Built-in Tools，或者模型名里包含 codex 或 gpt-5.2-pro。n8n 则是默认如此：新加的 OpenAI Chat Model 节点，Use Responses API 默认是打开的。各端点服务哪些模型，见 OpenAI 兼容 API。最后一列是边界：里面没有一项跑在网关上。

Dify：OpenAI-API-compatible 供应商，每个模型一条

在 Dify 的模型供应商列表里选 OpenAI-API-compatible：Dify 接入指南写的路径是 Settings → Model Provider，Dify 当前的官方文档写的是 Integrations → Model Provider，在那里安装该供应商，再点 Add Model。每个模型单独一条，添加后就能在应用、LLM 节点和 Agent 节点里选用。

# Dify → Settings → Model Provider → OpenAI-API-compatible
Model Name:    <exact-model-id-from-/models>
API endpoint:  https://api.router.one/v1
API Key:       sk-your-router-one-key

这个 URL 字段在旧版供应商插件里的名称是 API endpoint URL，在当前版本里是 API Base URL（按 0.0.66 核对）；两者填的都是带 /v1 的 base URL，插件会在后面拼接 /chat/completions。API Type 保持 Chat Completions API。Function Call Type 默认是 Not Support，这时 Dify 不会发送 tools 数组，所以把支持工具调用的模型接到 Agent 节点之前，先把它改成 Tool Call。

最常见的第一个报错。 保存一条配置时，Dify 会发一次很小的 ping 聊天请求，所以填错的值当场就会报 Credentials validation failed with status code，后面跟着状态码和网关的响应体：/v1 缺失或写了两遍是 404 not_found，Key 不对是 401 AUTH_INVALID_API_KEY。保存成功的那一次，已经是 Dashboard → Logs 里的一行。指南：Dify 接入 Router One。

Flowise：用 OpenAI Custom Model 节点，不用默认的 OpenAI 节点

Flowise 的两个 OpenAI 节点封装的都是 LangChain JS 的 ChatOpenAI 类。默认 OpenAI 节点的 Model Name 是不能手填的下拉框，选项来自 Flowise 的 models.json，里面是不带前缀的 OpenAI 模型名，放不下目录 ID。OpenAI Custom Model 节点（Flowise 3.1 之前名为 ChatOpenAI Custom）的 Model Name 是文本框。先在 Credentials → Add Credential → OpenAI API 里把 Key 存成凭证，再填节点：

# Flowise 3.1.x canvas → Add Nodes → Chat Models → OpenAI Custom Model
# （3.0.x 和官方文档里名为 ChatOpenAI Custom，字段写作 BasePath / BaseOptions）
Connect Credential:  存有 sk-your-router-one-key 的 OpenAI API 凭证
Model Name:          <exact-model-id-from-/models>
Temperature:         0.9
# Additional Parameters
Streaming:           on
Max Tokens:          （可选）
Timeout:             （可选，单位毫秒）
Base Path:           https://api.router.one/v1
Base Options:        （留空）

同一个节点可以接在 Chatflow 的链、Tool Agent、Agentflow V2 的节点和 Custom Assistant 上。它既没有 Reasoning Summary，也不会出现 OpenAI Built-in Tools，所以一直走 Chat Completions。

最常见的第一个报错。 一个被标成 MODEL_NOT_FOUND 的 404，消息末尾带着 Troubleshooting URL: https://docs.langchain.com/oss/javascript/langchain/errors/MODEL_NOT_FOUND/。LangChain 会把所有 HTTP 404 都这样标记，所以要看链接前面那段文字：Base Path 只填 https://api.router.one 时，网关返回 404 not_found，消息里直接说明 base URL 需要以 /v1 结尾。Base Path 留空时，SDK 会回退到 https://api.openai.com/v1，Dashboard → Logs 里不会有任何记录。指南：Flowise 接入 Router One。

Langflow：一个 OpenAI Compatible 供应商，模型从 /v1/models 发现

从 Langflow 1.11 起，模型接入是整个实例统一配置一次。点 Save 时，Langflow 会带着 Key（Bearer）请求 /v1/models 来验证这一对值，然后把发现的模型列在 Language Models 和 Embedding Models 下。

# Langflow 1.12 → profile icon → Settings → Model Providers → OpenAI Compatible
Base URL:  https://api.router.one/v1
API Key:   sk-your-router-one-key
# Save → Langflow 探测 /v1/models 并列出目录里的模型
# Language Models:   只启用要用的聊天模型 ID
# Embedding Models:  全部保持关闭（网关没有 /v1/embeddings）

# 在流程里: Language Model（或 Agent）→ Language Model 字段
Provider:  OpenAI Compatible
Model:     <exact-model-id-from-/models>

1.12 会自动补上缺少的 /v1，1.11.x 不会。容器环境可以从 OPENAI_COMPATIBLE_BASE_URL 和 OPENAI_COMPATIBLE_API_KEY 读取同样两个值。备选路径是内置的 OpenAI 组件：OpenAI API Base 填带 /v1 的地址，Model Name 下拉框可以直接输入 ID。

最常见的第一个报错。 保存供应商时失败，报错是几条固定消息之一。Authentication failed for the OpenAI-compatible endpoint. Check OPENAI_COMPATIBLE_API_KEY. 表示探测拿到了 401 或 403。The OpenAI-compatible endpoint at … returned HTTP 404 for …/models. Check that the base URL points to an OpenAI-compatible API. 表示路径不对，常见的是写成了 /v1/v1。如果保存成功但下拉里找不到某个模型，先看开关：Langflow 只把发现的前五个 ID 标为默认。指南：Langflow 接入 Router One。

n8n：OpenAI 凭证的 Base URL，加上模型节点上的一个开关

n8n 的 OpenAI 凭证自带 Base URL 字段，默认值是 api.openai.com，可以填任何 OpenAI 兼容端点。打开 Credentials → Add credential → OpenAI，或在 OpenAI / AI Agent 节点的凭证下拉里新建：

# n8n → Credentials → Add credential → OpenAI
API Key:   sk-your-router-one-key
Base URL:  https://api.router.one/v1
# Organization ID: 留空
# 在节点里: 选择这份凭证，Model 填 <exact-model-id-from-/models>

OpenAI Chat Model 节点是 AI Agent 使用的子节点，它的 Model 有两种填法：From List，从凭证的 /models 路径加载；或 ID，手动输入。同一个节点上还有 Use Responses API，在当前节点版本里默认打开（按 n8n 2.39.8 核对），发出的是 POST /v1/responses；关掉之后，节点发 Chat Completions。

最常见的第一个报错。 Use Responses API 还开着的时候填了 Claude、Gemini 或 Grok 的 ID，会收到消息里写着 must be called via 的 HTTP 400。把这个开关关掉即可，base URL 没有问题。其他节点也可以复用这份凭证，但文本生成、Responses 请求和文件操作各有兼容性要求，每个节点所选的操作和实际 API 路径都要核对。指南：n8n 接入 Router One。

Embeddings 和知识库留在别处

Router One 没有 /v1/embeddings，也没有 rerank 端点。每个工具的检索功能都需要把 embedding 模型放在别的供应商或本地模型上，只有聊天或 Agent 节点指向网关。

  • Dify：知识库用 Embedding Model 建索引和检索，Rerank Model 负责给检索结果重新排序；两者都是 Default Models 里单独的设置项，不要指向 Router One。
  • Flowise：Document Stores 和向量库节点调用的是单独的 Embeddings 节点。OpenAI Embedding 和 OpenAI Custom Embedding 各有自己的 Base Path，不能指向 Router One；Ollama Embedding 在本地运行。
  • Langflow：/v1/models 不带能力信息，所以发现的每个 ID 也会出现在 Embedding Models 下。全部保持关闭；选中其中一个，Langflow 就会去调 /v1/embeddings。
  • n8n：Embeddings OpenAI 子节点用的是同一种 OpenAI 凭证类型，Base URL 也一样。给它另建一份 OpenAI 凭证，指向提供 embeddings 的供应商。

检索发生在工具内部，最终只有带着检索片段的提示词会到达网关。知识库类应用的边界也一样：RAGFlow、FastGPT 和 AnythingLLM。

一次工作流运行是很多次请求

Agent 每拿到一次工具结果就会再调一次模型（见工具调用），所以向流程发一条消息，很少只对应一次请求。每个工具都有循环上限：

  • Dify：Agent 节点的 Maximum Iterations，在官方 Agent 策略插件里默认是 3。
  • Flowise：Tool Agent 的 Max Iterations 默认留空，即 15；Agentflow V2 的 Agent 节点没有迭代次数字段。LangChain 会重试失败的调用，最多 6 次，但不重试 400、401、402、403 和 404。
  • Langflow：Agent 的 Max Iterations 默认是 15 次模型调用。在全局供应商这条路径上，底层的 OpenAI 客户端重试 2 次；内置 OpenAI 组件要求 5 次。
  • n8n：AI Agent 的 Max Iterations 默认是 10，OpenAI Chat Model 节点的 Max Retries 默认是 2。

这些都不是消费上限，每一次到达网关的尝试都是独立的请求、Trace 和费用。真正的上限是 Key 上的 maxSpend：触及之后网关返回 HTTP 402（见错误码），钱包余额和其他 Key 不受影响。在 Dashboard → API Keys 里给每个实例单独建一把 Key；凭证按节点选择的工具（Flowise 和 n8n）还可以每个工作流一把。核账在 Dashboard → Logs 里按 request_id 进行（见成本追踪）：按时间窗和精确模型过滤，把这些行和那次运行对上。被工具中途断开的流式请求会记为 HTTP 499 client_cancelled。

每个工具还有自己的 API，它们都不是网关的 /v1：Flowise 的 Prediction API（POST /api/v1/prediction/:id，用 Flowise 的 API Key），Langflow 的 POST /api/v1/run/<flow-id>（x-api-key 头里放 Langflow API Key；它也以 sk- 开头，两把 Key 要标清楚），Dify 的应用 API（Bearer 方式的应用 Key，Dify Cloud 上是 https://api.dify.ai/v1），以及 n8n 的 Webhook URL。Router One 的 Key 不会用在这些地方。

怎么选

四个工具通过同一个端点到达同一份模型目录，所以看的是模型调用周围的东西。

  • 要交付的是一个应用，选 Dify：每个发布的应用同时就是一个 REST API，知识库也是产品的一部分。
  • 习惯按 LangChain JS 的组件来搭建，又想要 Node.js 方式安装，选 Flowise。
  • 用 Python，希望模型接入在整个实例里只配置一次，流程还能通过它的 API 或 MCP server 调用，选 Langflow。
  • 模型调用只是一条更大的业务工作流里的一步，周围还有触发器、webhook 和各种应用节点，选 n8n。

想用代码自己写循环，见 OpenAI Agents SDK、Claude Agent SDK、Pydantic AI、CrewAI 横评。全部接入指南在 /integrations。

常见问题

四个工具发给网关的请求一样吗？ 基本一样。Dify、Flowise 的 OpenAI Custom Model 节点和 Langflow 默认发 Chat Completions；n8n 当前版本的 OpenAI Chat Model 节点默认用 Responses API，关掉 Use Responses API 之后才发 Chat Completions。/v1/chat/completions 服务目录里的所有聊天模型，而 /v1/responses 只对当前上架的 GPT 系列和 DeepSeek ID 原生提供。

精确的模型 ID 在每个工具里填在哪里？ Dify：一条供应商配置的 Model Name，每个模型一条。Flowise：OpenAI Custom Model 节点的 Model Name 文本框。Langflow：从 /v1/models 发现的列表里选，或填 Model Name Override。n8n：OpenAI Chat Model 节点的 Model 字段，From List 或 ID。无论哪种，厂商前缀都要保留。

这些工具里的知识库能用 Router One 做 embeddings 吗？ 不能。Router One 没有 /v1/embeddings 和 rerank 端点，所以 embedding 模型要放在别的供应商或本地模型上，只把聊天或 Agent 节点指向网关。

一把 Key 能同时接四个工具吗？ 能。本文每份配置都接受同一把 Router One Key，调用使用同一个钱包。分开的 Key 让每个实例各有自己的 maxSpend 上限，循环的 Agent 会在自己的上限处停下并返回 HTTP 402，花不掉另一个工具要用的钱。

相关权威页面

这篇文章归入「LLM API 网关与路由」主题，以下页面作为商业页、配置文档、证据页和信任事实源。

商业主页面Router One API 网关承接统一模型调用、路由、fallback、预算和观测的产品首页。API 文档Router One API 文档OpenAI 兼容端点、CLI 配置和模型调用示例。证据页智能路由方法论路由信号、模型与请求 ID，以及客户侧 trace 的字段边界。对比页OpenRouter 替代方案专业对比全球模型目录与中国友好路由、支付能力的差异。信任页可引用事实表面向搜索爬虫、AI 答案引擎和客户的稳定事实源。数据留存数据留存政策prompt/completion 留存边界和请求元数据政策。网关页面统一 LLM API 网关一个 OpenAI 兼容端点接入整个模型目录，含路由、fallback 与预算控制。路由页面智能模型路由候选排序如何使用延迟、公示成本与可靠性信号。故障转移页面LLM 供应商故障转移什么样的请求才符合在另一条健康供应商路由上重试的条件。可观测页面逐请求 Trace 日志每个请求的模型与请求 ID、Token、延迟、状态与报错。兼容性页面OpenAI 兼容端点沿用 OpenAI SDK，只改 base URL 即可触达各个模型系列。成本追踪页面LLM 成本追踪按 Key、按模型、按请求的花费归因，配合硬性消费上限。转售方页面在 Router One 上搭你自己的 API 服务带消费上限的客户 Key、按 Key 的用量归因，以及明确的「不提供」清单。客户端接入SDK 与客户端配置指南把任意编程 agent、SDK、聊天客户端或 LLM 应用平台指向同一个端点，每个都有专属指南。模型对比模型价格与上下文两两对比每百万 token 单价、上下文窗口与能力，渲染自实时模型目录。

相关阅读

Goose、OpenCode、Qwen Code、Aider 横评：开源编程 agent 共用一把网关 Key

Goose、OpenCode、Qwen Code、Aider 接入 Router One 对照：各自用哪个变量或配置指向网关、走哪种协议、哪些能力留在工具侧，一把 Key、每次请求一条 Trace。

查看

OpenAI Agents SDK、Claude Agent SDK、Pydantic AI、CrewAI 横评：一把网关 Key 全接入

五个 Agent SDK 接入 Router One 对照：各自用哪个类或环境变量指向网关、走哪种协议、能调哪些模型系列，一把 Key、每次调用一条 Trace。

查看

GitHub Copilot BYOK vs Continue vs Cline：VS Code 一把 Key 全接入

VS Code 三个可自带 Key 的扩展对比：GitHub Copilot BYOK、Continue、Cline 的开源许可、配置方式、实际协议、工具调用与国内直连，并用一把 Router One Key 同时接入三者。

查看