在 AIRI 中配置 Xiaomi MiMo 聊天模型：从 API Key 到 Consciousness 模块的完整实操

• 人工智能
• AI Agent
• MCP 服务
• 工具调用
• GUI 自动化
• 语音
• 数字人
• 交互助手

本文围绕 AIRI 官方手册中的 Xiaomi MiMo 聊天模型配置页展开，覆盖获取 API Key、在设置中填写 Base URL 与 API Key、通过内置校验与 Ping API 验证连通性，以及在 Consciousness 模块中选定模型并启用的完整流程。读完本篇，你可以独立完成 MiMo 聊天服务的接入，并结合 provider 定义源码 与 OpenAI 兼容校验器实现 理解每一项校验背后实际发起的请求，从而在排查失败时有据可依。

MiMo 在 AIRI 中的定位

Xiaomi MiMo 在 AIRI 中提供聊天模型（chat 任务），并有独立的 TTS 与 STT 服务商页面。如果你希望在同一 MiMo 账户下同时使用聊天和音频能力，可以分别配置这三个页面：

• 聊天（本文主题）：Xiaomi MiMo (Chat)
• 语音合成：Xiaomi MiMo (TTS)
• 语音识别：Xiaomi MiMo (Transcription)

在源码侧，聊天 provider 定义于 providerMimo，并与 TTS、STT 两个音频 provider 一起注册到便携 provider 列表中（providers/index.ts）。其定义的关键元数据包括：

• id: 'mimo'，order: 4，名称展示为 "Xiaomi MiMo"（i18n 标题与描述见 settings.yaml 中mimo: title: Xiaomi MiMo）；
• tasks: ['chat']，表明该 provider 只承担聊天生成任务；
• capabilities: { chat: { reasoning: { modes: ['enabled', 'disabled'] } } }，表明它支持在请求级别开关推理（reasoning）模式；
• 图标使用i-simple-icons:xiaomi。

第一步：获取 API Key

1. 登录小米 MiMo 平台（platform.xiaomimimo.com），创建一个 API Key。
2. 妥善保存该 Key。

API Key 安全提示（与原文档一致）：不要将 API Key 提交到仓库、包含在截图中，或分享给任何人。

第二步：在 AIRI 中配置

1. 打开Settings → Providers → Chat → Xiaomi MiMo，填写API Key。
2. Base URL 保持默认值https://api.xiaomimimo.com/v1/，除非服务商提供了其他地址。

这两个字段对应 provider 配置中的 zod schema（mimo/index.ts）：

const mimoConfigSchema = z.object({ apiKey: z .string('API Key'), baseUrl: z .string('Base URL') .optional() .default('https://api.xiaomimimo.com/v1/'), })

可以注意到的实现细节：

• apiKey是必填字段；baseUrl可选，缺省时自动落到默认的https://api.xiaomimimo.com/v1/，所以 UI 中即使不手动填写也能正常请求；
• UI 侧apiKey字段以type: 'password'呈现，并有本地化的 label、description、placeholder（createProviderConfig）；
• validationRequiredWhen(config)返回!!config.apiKey?.trim()——只有当 API Key 非空时，配置状态才会进入"待自动验证"流程，空配置不会被反复触发网络检查（mimo/index.ts）。

第三步：验证配置：三层校验各做了什么

手册中提到：AIRI 会在你编辑配置时自动验证；若出现Ping API按钮，可用它发起一次真实的请求测试。对应到源码，MiMo 通过createOpenAICompatibleValidators组合了三个运行时检查项（mimo/index.ts）：

validators: { ...createOpenAICompatibleValidators({ checks: [ProviderValidationCheck.Connectivity, ProviderValidationCheck.ModelList, ProviderValidationCheck.ChatCompletions], }), },

这三项检查在 openai-compatible.ts 中实现，行为如下：

1. 配置检查（check-config）

不发请求，只做静态校验：

• API Key 不能为空（除非显式配置了skipApiKeyCheck）；
• Base URL 不能为空，且必须是能通过new URL()解析的绝对地址，否则分别报API key is required.或Base URL is invalid. It must be an absolute URL.（openai-compatible.ts）。

2. 连通性检查（Connectivity）

向{baseUrl}/models发起一次带Authorization: Bearer <apiKey>请求头的 GET，超时时间为 10 秒：

• 仅当响应状态码 ≥ 500 时判定为服务端错误并标记失败；
• 网络层抛错（超时、DNS、代理拦截等）也会记录为连通性失败，错误信息来自errorMessageFrom(e)（openai-compatible.ts）。

这就是"网络是否连通、API Key 格式是否被服务端接受"的最轻探测。

3. 模型列表检查（ModelList）

通过listModels拉取模型目录，要求返回列表非空，否则报Model list check failed: no models found。拉取逻辑优先使用 provider 的listModels扩展方法，否则回退到基于baseUrl + apiKey的标准 OpenAI 兼容GET /models调用（openai-compatible.ts）。

4. Chat 补全探测（ChatCompletions，即 Ping API）

这是最接近真实使用的一次探测：

• 先从配置或模型列表挑一个"验证用模型"——如果配置里已有model则直接使用（"用户已配置的模型代表其协议选择"），否则取列表中第一个非 embed/tts 类模型；
• 然后以用户消息ping、max_tokens: 16发起一次generateText（源码注释解释了 16 这个下限：部分 OpenAI 兼容上游拒绝低于 16 的输出限制）；
• 结果有精细的错误分流：网络错误判为连通性失败；若 HTTP 状态为 4xx 或 2xx（chat-completions 协议下），则认为连通但补全异常；
• 同一验证会话内该探测结果会通过缓存与互斥锁共享，避免重复打爆 provider（openai-compatible.ts）。

以上检查项的枚举定义（Connectivity/ModelList/ChatCompletions）见 types.ts，每个枚举值都注明了对应的探测方式，可作为阅读校验器时的索引。

第四步：选择模型并在 Consciousness 模块启用

校验成功后，使用Select Model按钮进入Settings → Modules → Consciousness，选择 provider 和模型。这一页的实现在 consciousness.vue，值得了解的行为有：

• 切换 provider 卡片时会触发loadModelsForProvider(provider)拉取该 provider 的模型列表（consciousness.vue）；
• 选择模型调用selectModel(modelId)，更新activeModel后通过airiCardStore.updateActiveCardConsciousness({ provider, model })持久化到当前 AIRI Card——也就是说所选模型是跟随角色卡（AirI Card）生效的（consciousness.vue）；
• 当 provider 的模型列表为空且非加载中/非报错状态时，页面会给出 warning 并退化为可自由输入的手动模型 ID 输入（allow-custom的RadioCardManySelect），这正是排查章节中"手动填写精确模型 ID"的 UI 依据（consciousness.vue）。

如果 provider 不支持模型列表，页面会切换到"手动模型名"输入模式，效果相同：直接输入小米 MiMo 提供的模型 ID 即可使用。

reasoning 模式如何落到 MiMo 请求上

前面提到 MiMo 声明了reasoning: { modes: ['enabled', 'disabled'] }能力。其落地逻辑在createProvider中对 SDK 返回的 chat 请求做了一层包装（mimo/index.ts）：

createProvider(config) { const provider = createXiaomi(config.apiKey, config.baseUrl) return { ...provider, chat(model: string, options?: ChatRequestOptions) { const request = provider.chat(model) if (!options?.reasoning) return request return { ...request, thinking: { type: options.reasoning } } }, }, },

即：当 AIRI 的 Consciousness 设置里指定了 reasoning 模式时，发往 MiMo 的请求体会额外带上thinking: { type: 'enabled' | 'disabled' }字段；未指定时保持 SDK 默认请求不变。ChatRequestOptions.reasoning与ChatReasoningMode（'disabled' | 'enabled'）的类型契约见 types.ts。

排查（Troubleshooting）

与原文档一致，当 API 检查失败或模型列表无法加载时，按以下顺序排查：

1. API 检查失败：检查 API Key 是否正确、账户状态是否正常（是否欠费/被停用）、网络连接是否可达api.xiaomimimo.com。结合上文可知，Connectivity 检查失败通常意味着 DNS/代理/防火墙或 5xx 服务端错误；若连通但 Chat 探测失败，则多为 Key 有效但权限或模型不对；
2. 模型列表无法加载：确认 Base URL 保持默认值https://api.xiaomimimo.com/v1/未被改动；如果确实是自定义部署或网关地址，请确保其实现了 OpenAI 兼容的GET /models与POST /chat/completions；
3. 列表始终拉不到：在Consciousness页面使用手动模型输入，填入小米 MiMo 提供的精确模型 ID，绕过自动发现（UI 行为见 consciousness.vue）。

小结与延伸阅读

MiMo 聊天 provider 的完整接入路径是：获取 API Key → 在Providers → Chat中填写（Base URL 有默认值）→ 等待 config/connectivity/model-list/chat 四层校验通过 → 在Modules → Consciousness中选择并持久化模型，必要时手动填写模型 ID。核心实现均集中在 packages/provider-inference/src/providers/cloud/mimo/index.ts 与 packages/provider-inference/src/validators/openai-compatible.ts 两个文件中，便于对照本文逐行阅读。

如需在同一 MiMo 账户下补齐语音能力，可继续阅读仓库中的 MiMo TTS 配置文档（预设音色mimo-v2.5-tts、声音设计mimo-v2.5-tts-voicedesign、声音克隆mimo-v2.5-tts-voiceclone三种模式）与 MiMo 转写文档，其 provider 实现位于 mimo-audio/index.ts。

• 人工智能
• AI Agent
• MCP 服务
• 工具调用
• GUI 自动化
• 语音
• 数字人
• 交互助手