企业官网建设流程全解析

Claude Code Router 接入 Kimi CLI：创建 Agent Profile、暴露可切换模型并统一走网关路由

【免费下载链接】claude-code-routerOne local control plane for every AI agent: route across models, fuse new capabilities, orchestrate tools, and stay fully in control.项目地址: https://gitcode.com/GitHub_Trending/cl/claude-code-router

Kimi CLI 是 Moonshot（月之暗面）推出的终端编码 Agent。在 Claude Code Router（下文简称 CCR）中，它被限定为CLI-only且始终只在 "Only opened from CCR"（仅从 CCR 打开）作用域下运行，因此可以把它当作一个纯终端接入点：将 Kimi CLI 路由到 CCR 任意已配置的 Provider 或 Fusion 模型、在/model菜单中暴露多个可切换模型，以及运行相互隔离的多套 Kimi CLI 会话。读完本文，你将掌握在 CCR Agent Config 中为 Kimi CLI 创建 Profile、使用ccr-app/ccr启动、并在 Request logs 中验证请求走通网关的完整方法，同时理解 CCR 是如何在源码层面识别、导入并复用本机 Kimi CLI 的凭据与模型列表的。

本文基于仓库文档 Kimi CLI setup and configuration 展开，并结合核心源码补充底层机制。

适用场景与固定的两种模式

Kimi CLI 在 CCR 中的定位与 Claude Code、Codex 等并不相同：它没有 App 桌面形态，也不支持“系统默认”作用域。文档明确说明 Kimi CLI 在 CCR 中具备两个固定属性：

• CLI only：只存在终端启动入口，没有 GUI 启动按钮；
• Only opened from CCR：只有从 CCR 发起的会话才会被路由到网关，普通方式启动的 Kimi CLI 不会被套用 CCR 配置。

这两个字段在 Agent 配置界面中不可编辑。这一约束也在源码中得到了印证：在 launch-core.ts 的buildKimiLaunchPlan中，若传入的启动表面不是"cli"，会直接抛出Kimi CLI profiles only support CLI opening.错误，随后生成的是指向 CCR 配置目录下bin/ccr-kimi-cli-wrapper-<slug>包装脚本的启动计划。

因此，Kimi CLI 配置页主要适合以下三类需求：

1. 把 Kimi CLI 的请求路由到任意 CCR Provider（例如无需购买 Kimi 订阅，改用其他渠道）或 Fusion 合成模型；
2. 暴露一个默认模型加多个可切换模型，在 Kimi CLI 内用/model随时切换；
3. 通过多套 Profile 运行互相独立的 Kimi CLI 会话（如「工作」与「个人」）。

如果你刚开始使用 CCR，请先完成 Provider 与模型的配置再回来操作。参见仓库内的配置总览与使用指南索引对应章节。

前置条件

在创建 Kimi CLI Profile 前，需满足文档列出的三项条件：

1. CCR Desktop 正在运行，且已配置至少一个 Provider + 模型（这是后续 Kimi 默认模型与可用模型的来源）；
2. 本机已安装 Kimi CLI，且kimi命令位于PATH中；
3. 你正处于Agent Config页面，并准备点击Add profile。

关于第 2 点的“安装在 PATH 上”，源码给出了更精确的探测顺序：在 kimi.ts 的kimiCliCandidates中，CCR 会依次尝试CCR_KIMI_BIN/KIMI_BIN显式指定的路径、~/.kimi-code/bin（或KIMI_CODE_HOME指定的存储目录）下的kimi可执行文件，最后回退到PATH上的kimi。也就是说，若你的 Kimi CLI 安装位置较特殊，也可以用环境变量精确指定，而不仅是依赖PATH。

创建 Profile 的五个步骤

在 Agent Config 页面完成以下操作：

1. 点击Add profile，在 Agent 列表中选择Kimi CLI；
2. 填写Config name，例如Kimi - Work；
3. 选择Kimi model（默认模型）以及一个或多个Available models（可用模型）；
4. 高级环境变量设置保持为空，除非你有特殊的本地环境需求；
5. 点击Save，然后从 Profile 卡片上复制启动命令执行。

保存后，CCR 会为这套配置生成独立的 Kimi CLI 启动入口。需要注意的是，默认模型与至少一个可用模型是必填项——如果两者缺失，Profile 将无法保存（详见文末“常见问题”）。

配置字段参考与逐项解析

Kimi CLI Profile 的字段比 Claude Code 精简许多——因为作用域（Only opened from CCR）与入口模式（CLI only）被固定。文档给出的字段说明如下：

Config name 与命令名的关系

Config name 不只是显示名，它直接决定启动命令的引号参数。仓库内存在两套启动命令入口：

• 桌面端命令名ccr-app定义于 launch-service.ts 的desktopCliCommandName；
• CLI 命令名ccr定义于 cli.ts 的defaultCliCommandName。

二者会解析你传入的 Profile 名称/ID，找到对应配置后按buildKimiLaunchPlan生成的包装脚本启动 Kimi CLI。因此起一个有辨识度的 Config name（如Kimi - Work）可以让你在多个会话间快速定位。

默认模型与可用模型

• Kimi model（默认模型）：决定会话启动时使用的模型，必须是 CCR 能服务的Provider/model或 Fusion 模型；
• Available models（可用模型）：决定/model菜单中出现哪些可切换模型，默认模型始终在列。

这些模型的底层来源值得展开：CCR 的 Kimi 集成属于“本地 Agent Provider”体系。在 kimi.ts 的kimiCandidates()中，CCR 会去读取本机 Kimi CLI 的config.toml（默认位于~/.kimi-code/config.toml，可通过KIMI_CODE_HOME覆盖，见 kimiStorageRoot），解析[providers.*]、[models.*]段以及根级default_model，从而还原出 Kimi 侧配置过的 provider、模型与显示名。若检测到有效的 API Key 或 OAuth 凭据，CCR 会提示「Click Import to add it as a gateway provider」，将其作为网关 Provider 导入；反之则标记为locked并提示先在 Kimi CLI 内执行/login。

也就是说，“模型列表”最终会被换算成 CCR 网关可服务的模型集合（含 Fusion 模型），再通过网关下发给 Kimi CLI 的/model菜单。相关预置的默认服务地址与模型在仓库中也有迹可循，如 kimi.ts 中定义的两个 Base URL（https://api.kimi.com/coding/v1与https://api.moonshot.ai/v1）以及默认模型kimi-for-coding，对应 Provider 预置可参见 providers/presets/kimi-coding。

底层机制：CCR 如何识别与复用 Kimi CLI

Kimi CLI 的所有请求都要经过 CCR 网关（providers、routing、Fusion），其核心依赖 CCR 对 Kimi 本地状态的两类读取：

1. 配置解析：readKimiConfiguredProviders()用内置的轻量 TOML 解析器（kimi.ts）读取 Kimi 的config.toml，仅关注type == "kimi"的 provider 段，支持从api_key、env.KIMI_API_KEY或[providers.*.oauth]提取凭据信息；
2. OAuth 凭据维护：若走 OAuth，CCR 会读取~/.kimi-code/credentials/*.json中的 access/refresh token；当 token 过期时，通过auth.kimi.com/api/oauth/token以refresh_token方式自动刷新，并把新 token 以0600权限原子写回凭据文件（refreshKimiAuth）。代码还处理了“多个进程共享同一凭据文件、刷新 token 轮换导致并发失效”的场景——当刷新请求被服务端拒绝时，会重新读取磁盘上已被对端更新的新凭据以接管会话（adoptPeerRotatedKimiAuth）。

此外，为了让上游正确识别请求身份，CCR 会向 Kimi 侧上游附加User-Agent: kimi-code-cli/<version>、X-Msh-Platform、X-Msh-Device-Id等一组X-Msh-*身份头（kimiIdentityHeaders），并尽力维持一个稳定的设备 ID。理解这些机制有助于排查“Kimi 侧显示未登录/凭据失效”一类问题——通常刷新逻辑已自动处理，无需手动干预。

打开并使用 Kimi CLI

保存 Profile 后，卡片会提供两类启动命令。

桌面端（从 CCR Desktop 的 Profile 卡片复制）：

ccr-app "Kimi - Work"

纯 CLI 环境执行：

ccr "Kimi - Work"

进入 Kimi CLI 后，使用/model在默认模型与可用模型之间切换。任何一次选择都会始终经由 CCR 的 providers、routing 与 Fusion 处理——换言之，Kimi CLI 只是终端外壳，实际请求路径是“Kimi CLI → CCR 网关 → 目标 Provider/模型”。

需要注意的是，由于作用域固定为 “Only opened from CCR”，只有在上述命令（或 CCR 桌面卡片上的终端按钮）启动的 Kimi CLI 会话中，路由才会生效；绕开 CCR 直接键入kimi启动的会话不会套用这些 Profile 配置。

多实例：一套会话一个 Profile

Kimi CLI 是纯会话式的编码工具，不同任务往往需要不同的默认模型与模型集合。文档给出的做法很直接：当你希望使用不同的默认模型或不同的模型组时，就创建多套 Kimi CLI Profile。

例如：

• Kimi - Work：默认kimi-for-coding，可用列表加一个更大的推理模型；
• Kimi - Personal：默认换成另一 Provider 的模型，可用列表保留 1～2 个廉价模型。

由于每套 Profile 在 launch-core.ts 中都会生成带独立 slug 的包装脚本（ccr-kimi-cli-wrapper-<slug>），多套 Profile 之间相互独立、互不覆盖，你可以同时运行多个互不干扰的 Kimi CLI 会话。

验证链路是否打通

创建并启动后，按文档给出的四步验证：

1. 运行桌面端复制的ccr-app命令，或 CLI 的ccr命令启动 Kimi CLI；
2. 在 Kimi CLI 中发送一条消息，确认能收到回复；
3. 打开 CCR 的Request logs，确认该请求确实经过了 CCR 网关（并留意它最终命中了哪个 Provider/模型）；
4. 执行/model，确认默认模型与可用模型都已出现。

其中第 3 步是“路由是否真的生效”的最直接证据——如果日志中看不到对应请求，多半是会话并非由 CCR 启动。

常见问题排查

文档归纳了三个高频问题，结合源码可进一步明确根因与对策：

• /model为空或缺少模型：至少添加一个Available model（默认模型本身也可作为可用模型之一），并确认 CCR 中已配置 Provider + 模型。可用模型的本质是“CCR 网关可服务的模型集合”，没有 Provider 就没有可下发的模型；
• Profile 无法保存：Kimi CLI 要求同时具备默认模型与至少一个可用模型——两者都是必填项，与 Claude Code 允许留空模型不同；
• kiminot found：确认 Kimi CLI 已安装，且处于“启动 CCR Desktop 的同一个 shell 环境”的PATH中。如安装路径特殊，也可按前文所述用KIMI_BIN/CCR_KIMI_BIN显式指定（参见 kimiCliCandidates）。

小结

Kimi CLI 是 CCR 众多 Agent 接入中形态最简单也最“纯 CLI”的一种：它没有 App、没有系统默认作用域，只有“从 CCR 打开”的终端会话。你真正需要关心的，是给每套会话配好默认模型与可切换的模型集合，然后用ccr-app "<name>"（桌面）或ccr "<name>"（终端）启动。底层上，CCR 通过解析~/.kimi-code/config.toml与凭据文件来识别本机 Kimi CLI，必要时自动刷新 OAuth token，并将模型清单映射为网关可服务的 Provider/Fusion 模型，从而让 Kimi CLI 的每一次调用都完整经过 CCR 的路由与观测体系。

【免费下载链接】claude-code-routerOne local control plane for every AI agent: route across models, fuse new capabilities, orchestrate tools, and stay fully in control.项目地址: https://gitcode.com/GitHub_Trending/cl/claude-code-router