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

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-routerKimi 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 配置页主要适合以下三类需求把 Kimi CLI 的请求路由到任意 CCR Provider例如无需购买 Kimi 订阅改用其他渠道或 Fusion 合成模型暴露一个默认模型加多个可切换模型在 Kimi CLI 内用/model随时切换通过多套 Profile 运行互相独立的 Kimi CLI 会话如「工作」与「个人」。如果你刚开始使用 CCR请先完成 Provider 与模型的配置再回来操作。参见仓库内的配置总览与使用指南索引对应章节。前置条件在创建 Kimi CLI Profile 前需满足文档列出的三项条件CCR Desktop 正在运行且已配置至少一个 Provider 模型这是后续 Kimi 默认模型与可用模型的来源本机已安装 Kimi CLI且kimi命令位于PATH中你正处于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 页面完成以下操作点击Add profile在 Agent 列表中选择Kimi CLI填写Config name例如Kimi - Work选择Kimi model默认模型以及一个或多个Available models可用模型高级环境变量设置保持为空除非你有特殊的本地环境需求点击Save然后从 Profile 卡片上复制启动命令执行。保存后CCR 会为这套配置生成独立的 Kimi CLI 启动入口。需要注意的是默认模型与至少一个可用模型是必填项——如果两者缺失Profile 将无法保存详见文末“常见问题”。配置字段参考与逐项解析Kimi CLI Profile 的字段比 Claude Code 精简许多——因为作用域Only opened from CCR与入口模式CLI only被固定。文档给出的字段说明如下字段如何设置作用Agent选择Kimi CLI在 CCR 中创建 Kimi CLI 启动入口。Config name自由文本例如Kimi - Work标识该 Profile。桌面端命令使用ccr-app nameCLI 命令使用ccr name。Enabled开关关闭后该 Profile 不生效也不会作为启动入口被提供。Kimi model一个 Provider 模型或 Fusion 模型默认模型至少需要一个模型。Available models一个或多个 Provider / Fusion 模型可从 Kimi CLI 的/model菜单切换的模型默认模型总是被包含其中。Environment variables键值对行可选的高级覆盖项常规使用保持为空。Config name 与命令名的关系Config name 不只是显示名它直接决定启动命令的引号参数。仓库内存在两套启动命令入口桌面端命令名ccr-app定义于 launch-service.ts 的desktopCliCommandNameCLI 命令名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 URLhttps://api.kimi.com/coding/v1与https://api.moonshot.ai/v1以及默认模型kimi-for-coding对应 Provider 预置可参见 providers/presets/kimi-coding。底层机制CCR 如何识别与复用 Kimi CLIKimi CLI 的所有请求都要经过 CCR 网关providers、routing、Fusion其核心依赖 CCR 对 Kimi 本地状态的两类读取配置解析readKimiConfiguredProviders()用内置的轻量 TOML 解析器kimi.ts读取 Kimi 的config.toml仅关注type kimi的 provider 段支持从api_key、env.KIMI_API_KEY或[providers.*.oauth]提取凭据信息OAuth 凭据维护若走 OAuthCCR 会读取~/.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 配置。多实例一套会话一个 ProfileKimi CLI 是纯会话式的编码工具不同任务往往需要不同的默认模型与模型集合。文档给出的做法很直接当你希望使用不同的默认模型或不同的模型组时就创建多套 Kimi CLI Profile。例如Kimi - Work默认kimi-for-coding可用列表加一个更大的推理模型Kimi - Personal默认换成另一 Provider 的模型可用列表保留 12 个廉价模型。由于每套 Profile 在 launch-core.ts 中都会生成带独立 slug 的包装脚本ccr-kimi-cli-wrapper-slug多套 Profile 之间相互独立、互不覆盖你可以同时运行多个互不干扰的 Kimi CLI 会话。验证链路是否打通创建并启动后按文档给出的四步验证运行桌面端复制的ccr-app命令或 CLI 的ccr命令启动 Kimi CLI在 Kimi CLI 中发送一条消息确认能收到回复打开 CCR 的Request logs确认该请求确实经过了 CCR 网关并留意它最终命中了哪个 Provider/模型执行/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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考