Langflow 接入统一 API:任意版本都有路径

先说结论:版本决定走哪条路

1.11 发行线上,Langflow 有原生答案:Settings、Model Providers、OpenAI Compatible。填 base URL(kkaiapi 填 https://api.kkaiapi.com/v1)和 Key,Langflow 会从端点的 /v1/models 路由实时发现能提供的模型,列进所有流程的模型选择器里,Agent 组件也包括在内。 更早的版本没有通用供应商这个槽位,当时统一的供应商只有 OpenAI、Google、IBM watsonx、Ollama。能用的两条路径是 vLLM 内置组件——名字里带 vLLM,实际是个通用的 OpenAI 兼容客户端,自带 api_base、api_key、model_name 字段——和 OPENAI_API_BASE 环境变量,后者会整体改写基于 langchain 的 OpenAI 组件。两条路径下面都有讲,各自都有一个坑。

Base URL:  https://api.kkaiapi.com/v1
API Key:   sk-你的kkaiapi密钥

模型从 /v1/models 实时发现
自动出现在流程的模型选择器里

变了什么,以及为什么旧教程说法不一致

Langflow(GitHub 上的 langflow-ai,约 15.2 万星标)是可视化 Agent 与 RAG 编排里最主流的工具,它长期以来的一个明显缺口就是没有通用的 OpenAI 兼容端点。用户从很早就在要求一个自定义 base URL,一个给 OpenAI Compatible 供应商选项的功能请求被提出后,社区积累出各种变通方案:改组件代码、借用 LiteLLM 内置组件、把本地模型组件挪用来干这事。 那个请求最终关闭是因为功能上线了。实现这个功能的 pull request 合并进了 release-1.11.0 发行线,在 Settings 里注册供应商,接受一个必填的 base URL 和一个可选的 Key,用真实的错误信息校验凭据,从端点实时发现模型,底层复用已有的 ChatOpenAI 和 OpenAIEmbeddings 类,不是另起一个新客户端。 实际后果是:早期写的指南描述的 Langflow 已经和当前版本对不上了,而按较新版本写的指南又假设了很多自部署安装还没升级到的版本。先确认自己的版本,这一页剩下的内容都建立在这个基础上。

1.11 上的原生路径:配一次,全流程复用

打开 Settings,进 Model Providers,选 OpenAI Compatible。这个供应商接受两个值,一个必填的 base URL 和一个可选的 API Key,保存时会对端点做一次实时校验:URL 错、认证失败、host 不可达,各自产生不同的报错,而不是静默失败。保存之后,端点提供的模型会出现在模型选择器里,一个流程的 Language Model 或 Agent 组件选 claude-sonnet-4-6 或 deepseek-v4-pro,和选一个官方 ID 一样方便。 这正是功能请求当初想要的"配一次到处用"的形状:端点定义在工作区级别,每个流程复用它,而不是每个组件各自拷贝一份 URL 和 Key。模型发现还意味着新的目录 ID 出现时,完全不用碰 Langflow。 如果 Settings 里没有 OpenAI Compatible 这一项,说明安装的版本早于这个功能。升级是干净的解法;这周升不了的话,下一节是两个变通方案的照实说明,它们在当前版本上也照样能用。

curl -s https://api.kkaiapi.com/v1/models \
  -H "Authorization: Bearer $KKAIAPI_KEY" | head -50

旧版本的路径,以及各自的坑

vLLM 组件是按流程配置的路径。它活在 vLLM 内置组件包里,但底层是基于 ChatOpenAI 的通用 OpenAI 兼容客户端:api_base 接受包含 /v1 的完整端点地址(它文档里的默认值是 http://localhost:8000/v1,注意这个后缀),api_key 接受网关 Key,model_name 接受任意目录 ID 的纯字符串。它的 Language Model 输出接进 Agent 等由 LLM 驱动的组件,这就是在 1.11 之前的 Langflow 上把一个 Claude ID 放到 Agent 背后的办法。坑在于重复:URL 和 Key 是每个组件实例各自维护的,一个流程多的工作区会有很多份拷贝,轮换一次 Key 意味着挨个改。 OPENAI_API_BASE 是全局路径。Langflow 的 OpenAI 组件底层基于 langchain-openai,没有显式设 base 时会读这个变量,所以在启动 Langflow 之前导出它,能在不改任何界面的情况下把这些组件整体指向网关。坑在于影响范围:它会挪动进程里每一个 OpenAI 风格的组件,Embedding 也包括在内,一个悄悄指向了不提供其 Embedding ID 的端点的 OpenAI Embeddings 组件,会在离改动很远的检索环节报错。只有打算让整个实例都经网关走的时候才用它,不要为了一个流程就这么干。 还值得知道:一些组件参数默认在可视化编辑器里是隐藏的,只在组件的检查面板里出现,这里提到的好几个字段就在那里。

api_base:   https://api.kkaiapi.com/v1   (保留 /v1)
api_key:    sk-你的kkaiapi密钥
model_name: claude-sonnet-4-6

output: Language Model -> 接到 Agent 组件

主力模型价格

价格按 kkaiapi 中文区实时价格计算,单位 ¥/1M tokens(输入/输出)。

选流程和 Agent 用的模型

每个候选都经同一个 Key 计费,kkaiapi 控制台按模型拆分的用量会给你跑的每一次实验定价,这很适合 Langflow 在画布上边改边试的工作方式。

• Agent 组件做工具调用循环,循环质量就是模型质量。claude-sonnet-4-6 和 gpt-5.5 能撑住多步计划,弱一点的 ID 会掉链子,表现得像流程 bug
• 高频的流程步骤(分类、抽取、路由节点)该放快速 ID。claude-haiku-4-5-20251001 和 deepseek-v4-flash 能防止一个繁忙的流程把花费集中在管线搬运上
• 摄入整篇文档的长上下文步骤,值得在自己的管线里测一下 gemini-3.1-pro-preview
• 流程是一条链,一个慢模型会拖住整次运行。Langflow 里每个节点的延迟比聊天客户端里更要紧,这更倾向于在输出是给机器读的地方全用快速 ID
• 1.11 的供应商级发现让对比两个模型变成改一个选择器再重跑,所以在自己的流程上测,不要照搬通用跑分

Langflow 专属的翻车点

版本不匹配是最大的坑。用 1.11 时代的指南对着 1.10 的安装,最后停在一个 Settings 页面,没有 OpenAI Compatible 这一项;用旧版指南对着当前版本,又会陷进这个功能本该让你省掉的变通方案里。跟着教程走之前先确认版本。 /v1 的约定因入口而异。vLLM 组件的 api_base 要求带上后缀,它的 localhost 默认值就是证据。1.11 的供应商会规范化输入的 URL,但在更旧的组件级字段里填裸 host 不带路径,客户端拼接 /chat/completions 之后会 404。 环境变量挪动的比你想的多。OPENAI_API_BASE 会跟着挪动 Embedding 组件,一个检索流程的 Embedding 器解析不了自己的模型时,会在检索这一步报错,不是在配置这一步。如果换环境变量之后检索坏了,原因就在这。 pre-1.11 版本上,按组件配置会漂移。两个不同天配置的流程可能指向不同的端点或带着过期的 Key,症状是一个流程能跑、它的兄弟流程却挂了。1.11 的供应商级配置存在的原因,正是因为这类漂移在旧版本上很常见。

谁会把 Langflow 接到一个网关上

• 想在同一个画布里选 Claude、GPT、Gemini、DeepSeek、不想为每家厂商各开一个供应商账号的流程搭建者
• 标准化到 1.11 供应商级配置的团队:一个工作区级别的 base URL 和 Key,在一处轮换,被每个流程使用
• 在升级窗口到来之前,用 vLLM 组件在旧版本上把旗舰 ID 放到 Agent 组件背后的自部署用户
• 按流程步骤对比模型的搭建者,每个候选是一次选择器改动,用量日志给对比定价
• 拿不到某家厂商官方支付渠道的开发者,充值即用不需要海外卡

验证接入与排查首次流程运行

先证明网关这一半没问题:上面的 curl 应该列出打算选用的每一个 ID。1.11 上,供应商自己的校验之后能覆盖多数其余情况,因为它在保存时就能区分是 URL 错、Key 错还是 host 不可达。 旧版本上,按入口分别排查。一个组件报模型不存在,是 model_name 里的 ID 拼错了,拿 /v1/models 的列表核对。每次请求都 404,是 api_base 里丢了 /v1。401 说明那个具体组件上的 Key 字段有误或者是空的,因为配置是按组件的,该检查报错的那个组件,而不是昨天配置的那个。如果一个检索流程在改了环境变量之后坏了,先取消设置 OPENAI_API_BASE,把端点重新收回到组件级别。 流程跑起来之后,kkaiapi 控制台会显示每次请求的模型、token 数和花费。可视化搭建工具很容易让人忘记每个节点都是一次计费的 API 调用,用量日志是流程真实的单次运行成本变成一个能读出来的数字的地方。

curl -s https://api.kkaiapi.com/v1/chat/completions \
  -H "Authorization: Bearer $KKAIAPI_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"claude-sonnet-4-6",
       "messages":[{"role":"user","content":"ping"}]}'

常见问题