通过 OpenAI 供应商把 MaxKB 接到 Router One

把 MaxKB 配置到 Router One base URL

打开「模型」，选择 OpenAI 供应商添加模型。「模型名称」是显示标签，「基础模型」才是发给 API 的 ID。在「基础模型」中输入 /models 里当前可用的完整聊天模型 ID，保留厂商前缀，即使预设下拉列表没有也可以手动输入。「模型类型」选「大语言模型」，API URL 填 https://api.router.one/v1；官方文档也把这个字段叫「API 域名」。API Key 填专用 Router One Key。这个供应商使用 Chat Completions 客户端，因此 API URL 后面不要再加 /chat/completions。保存成功后，在简易智能体的 AI 模型或 AI 对话节点中选用新建模型。

# MaxKB → 模型 / Models → OpenAI → 添加模型 / Add model
模型名称 / Model name:      Router One chat
模型类型 / Model type:      大语言模型 / LLM
基础模型 / Base model:      <exact-model-id-from-/models>
API URL:                    https://api.router.one/v1
API Key:                    sk-your-router-one-key

# 保存后，在智能体中选用这个模型 / Select this model in your agent after saving
# 向量模型另配 / Configure the knowledge-base embedding model separately

两个名称，只有一个是真正的模型 ID

模型名称方便你在 MaxKB 中区分资源，改名不会改变网关实际调用的模型。「基础模型」是可输入的下拉框，不是从 Router One 拉取的目录。v2.10.6-lts 适配器把它直接作为 model 参数发送，不去掉厂商前缀。供应商名称 OpenAI 选择的是兼容协议，不要求必须使用 OpenAI 系列模型；从 Router One 详情页选择支持 Chat Completions 的 ID 即可。

保存时会真实调用模型验证

v2.10.6-lts 的凭据验证器会用一句问候调用所选模型，因此最终用户尚未聊天，保存测试就可能产生 token 用量。该版本 OpenAI 大语言模型的参数表单默认提供 temperature 0.7 和最大输出 8192 tokens；这是 MaxKB 默认值，不是 Router One 的推荐参数，也不是上下文窗口。若错误点名 temperature 或输出 token 参数，先在「高级设置」或「模型参数设置」中删除或调整不支持的参数，再重试。保留完整错误；换 Key 或修改 base URL 不能解决模型对某个参数的拒绝。

把知识检索与模型计费分开核对

知识库需要单独选择向量模型。让它使用本地模型或其他供应商：Router One 不提供 embeddings 或 reranking 端点。大语言模型验证成功，不代表文档索引已通过验证。「问题优化」、知识库文档的「生成问题」和 AI 对话节点都可能在最终回答之外增加模型调用。使用设了 maxSpend 的专用 Key，先用一份小文档验证，再在 Dashboard → Logs 按时间、模型和 request_id 核对请求。MaxKB 的对话历史和 token 估算不是网关结算记录。

MaxKB 该填哪个模型 ID？

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

MaxKB 用的是哪种 API 协议？

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

在 trace 里验证 MaxKB 的调用

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

常见问题