一条连接，把你选定的 Router One 模型接入 Open WebUI

把 Open WebUI 配置到 Router One base URL

在已运行的实例里打开 管理员面板 → 设置 → 外部连接，在「管理 OpenAI 接口连接」处点 + 号添加连接。URL 填 base URL，恰好一个 /v1。Key 填你的 Router One Key，会以 Bearer token 发送。「连接类型」保持「外部」，「提供商」保持「默认」。「接口类型」保持 Chat Completions，每次对话都是发往 /v1/chat/completions 的 POST，这个端点服务目录里的全部对话模型。在「模型 ID」里用 + 号逐个添加希望用户看到的目录精确 ID（见下一节）。「模型 ID 前缀」可选。「验证连接」会带着 Key 请求 GET /v1/models，成功时提示「已验证服务器连接」；保存本身不做任何测试，所以先验证、再保存。全新的 Docker 部署也可以在首次启动时用环境变量写入同一条连接：

URL

https://api.router.one/v1

# Open WebUI → Admin Panel → Settings → Connections → Manage OpenAI API Connections → +
URL:              https://api.router.one/v1
Key:              sk-your-router-one-key
Connection Type:  External        API Type: Chat Completions
Model IDs:        anthropic/claude-sonnet-5, openai/gpt-5.6-sol, google/gemini-3.7-flash, deepseek-v4.1-flash

# Or seed the connection on the first launch (ConfigVar: later env changes are ignored):
docker run -d -p 3000:8080 -v open-webui:/app/backend/data \
  -e OPENAI_API_BASE_URL=https://api.router.one/v1 \
  -e OPENAI_API_KEY=sk-your-router-one-key \
  -e WEBUI_SECRET_KEY=<output of: openssl rand -hex 32> \
  --name open-webui --restart always ghcr.io/open-webui/open-webui:main

用「模型 ID」白名单决定用户能看到哪些模型

「模型 ID」留空时，Open WebUI 会列出 GET /v1/models 返回的全部内容，而 Router One 返回的是整个目录：包括 azure/、aws/、vertex/ 这类渠道 ID，也包括没法回答聊天消息的图像生成模型（gpt-image-2、gpt-image-2.5-flare、gpt-image-2.5-sunburst、gemini-3-pro-image-preview、gemini-3.1-flash-image-preview、grok-imagine-image、grok-imagine-image-quality）。往白名单里添加 ID 会替换自动获取的列表：Open WebUI 不再为这条连接请求 /models，只显示你填写的 ID。实用的做法是列几个对话模型，例如 anthropic/claude-sonnet-5、anthropic/claude-haiku-4.5、openai/gpt-5.6-sol、openai/gpt-6-sol、google/gemini-3.7-flash、deepseek-v4.1-flash 和 grok-4.7。用目录里的精确 ID 还能避开 Open WebUI v0.11.4 的一处改写：对以 o 加数字开头、或以 gpt- 加 5 及以上版本号开头的裸名称，它会把 max_tokens 改名为 max_completion_tokens，并用 developer 角色发送系统提示词；openai/gpt-5.6-sol 这类带厂商前缀的 ID 则原样发送。「模型 ID 前缀」只改变选择器里的显示：Open WebUI 用一个点把它和每个 ID 连起来（前缀填 ro 会显示成 ro.anthropic/claude-sonnet-5），发请求前再去掉，所以除非两条连接列出了相同的 ID，否则留空即可。

任务模型：每条消息背后的请求

Open WebUI 会在每次对话周围发一些后台小请求：给新对话起标题、打标签、生成追问建议，用到知识库检索和联网搜索时还会改写检索词。默认情况下它们都用用户当前对话的模型，所以在旗舰模型上，一条消息可能在控制台 → 日志里对应三四条记录，每条都按该模型的单价计费。在 管理员面板 → 设置 → 界面 的「任务」部分，把「外部任务模型」设为速度快、不带推理、单价低的 ID，例如 anthropic/claude-haiku-4.5；除本地连接之外的所有模型都用「外部任务模型」，Router One 也在其中。标题生成自带 1,000 个输出 token 的上限，而标签、追问和检索词请求本身没有输出上限。「任务模型参数」会给所有后台请求统一设置参数，而且只要设置了任何一项，标题的内置上限就不再生效，所以记得带上 max_tokens，例如 {"max_tokens": 1000}。用不到的任务可以在「生成」下面关掉：标题生成、标签生成、追问生成默认开启，输入框内容自动补全默认关闭。对应的环境变量是 TASK_MODEL_EXTERNAL、TASK_MODEL_PARAMS、ENABLE_TITLE_GENERATION、ENABLE_TAGS_GENERATION、ENABLE_FOLLOW_UP_GENERATION 和 ENABLE_AUTOCOMPLETE_GENERATION。

工具调用、用量、Responses 与 embeddings

从 v0.10.0 起，没有单独选择模式的对话都使用原生（Native）工具调用，依赖模型自身的函数调用能力；在原生模式下，Open WebUI 还会把联网搜索、记忆和知识库检索作为工具交给模型调用。优先选模型详情页列出了工具调用的 ID；其他 ID 在挂载工具之前先测试一轮工具调用。接下来是 token 计数：Open WebUI 只有主动请求时才会显示用量，而默认关闭的「用量」能力正是让它发送 stream_options.include_usage 的开关。在 管理员面板 → 设置 → 模型 → 能力 里按模型开启，聊天界面和 Open WebUI 的统计里才会有 token 数；控制台 → 日志无论如何都会记录 tokens 和费用。「接口类型」里的 Responses 在 Open WebUI 中属于实验性功能；如果要用，就另加一条接口类型为 Responses 的连接，白名单只放 GPT 系列、DeepSeek 与 Grok 对话模型的 ID，因为 Claude 和 Gemini 的 ID 不在 /v1/responses 上提供。最后，文档和知识库需要 embeddings 引擎。Router One 没有 /v1/embeddings，所以 Open WebUI 的文档向量化请保持默认的本地模型，或交给其他供应商。

Docker：只生效一次的设置，以及固定的密钥

OPENAI_API_BASE_URL、OPENAI_API_KEY 以及大多数连接和任务设置都属于 ConfigVar：Open WebUI 在首次启动时读取它们、存进数据库，之后一直使用存下来的值。之后再改环境变量不会生效，请到管理员面板里直接改连接。ENABLE_PERSISTENT_CONFIG=False 会把优先级反过来，每次重启都以环境变量为准，但在管理员面板里做的修改到下次重启就会丢失。docker run 命令里还应该有两项。-v open-webui:/app/backend/data 把对话、用户和设置保存在命名卷里，不挂卷的话，删除容器时数据一起丢失。WEBUI_SECRET_KEY 用于签发登录令牌、加密存储的密钥；不设置时，镜像会在容器内部自动生成一个，于是重建容器（不只是重启）会让所有用户都被登出。用 openssl rand -hex 32 生成一次，之后每次运行都传同一个值。

Open WebUI 该填哪个模型 ID？

从 /models 页复制精确的模型 ID，保留大小写、连字符和版本后缀，不要用展示名称代替。打开该模型的详情页，核对支持的 API 端点、上下文窗口和工具调用等能力，再与 Open WebUI 当前选择的 provider 和功能对应。模型出现在目录里，不等于当前客户端能调用它的所有功能。建议为每个客户端或应用单独建 API Key，并设置 maxSpend 消费上限。

Open WebUI 用的是哪种 API 协议？

OpenAI 兼容描述的是接口格式，不能据此推断 Chat Completions（/v1/chat/completions）、Responses（/v1/responses）和 Anthropic Messages（/v1/messages）可以互换。先核对工具当前版本、provider 配置和实际请求路径，再查模型详情与 API 兼容性事实页。一次普通对话成功，也不能证明服务端工具、历史状态或文件编辑功能都受支持。

在请求日志里核对 Open WebUI 的调用

先在 Open WebUI 发出一次简单文本请求，再到控制台 → 日志按时间、模型和 request_id 找到这条记录，核对 Token、花费、总耗时和状态码。成功后再分别验证流式输出、工具调用和多轮历史。失败时保留实际请求路径、完整错误消息及 request_id；没有对应日志时，先查客户端配置和网络，不能仅凭客户端报错认定是网关或上游故障。

常见问题