先确认：这是客户端迁移，不是只换一个二进制文件

Kimi CLI 1.50.0 的发布说明加入了面向弃用的更新流程和迁移到 Kimi Code 的入口。它意味着旧 CLI 用户不应只执行一次升级命令，然后假设历史工作流会自然继承。

真正需要迁移的是四层内容：

  1. 人在终端里使用的命令和登录入口。
  2. 项目级规则、模型和 provider 配置。
  3. CI、定时任务或 shell 脚本中的非交互调用。
  4. MCP、权限策略和环境变量等外部依赖。

只要其中一层仍指向旧 CLI，团队就可能遇到“本地能跑、自动化不跑”或“新客户端没有读到旧配置”的问题。

先做盘点，再点迁移

开始前，在仓库、用户目录和自动化配置中搜索旧调用。Windows PowerShell 可以先执行：

PowerShell
rg -n --hidden --glob '!node_modules' '(^|\s)kimi(\s|$)|kimi-cli|KIMI_' . $HOME\.config 2>$null

macOS 或 Linux：

Bash
rg -n --hidden --glob '!node_modules' '(^|\s)kimi(\s|$)|kimi-cli|KIMI_' . ~/.config 2>/dev/null

重点记录下面几类位置：

位置迁移时要确认什么
shell alias / profilekimi 是否仍解析为旧路径；脚本是否写死旧绝对路径。
项目规则AGENTS.md、CLAUDE.md 或团队文档是否引用旧命令和配置目录。
CI 与定时任务是否使用 -p、管道输入、无 TTY 环境或机器账号。
环境变量Key、Base URL、模型名和 provider 是否由新客户端读取。
MCP 配置Server 地址、OAuth 状态、允许的工具和本地存储路径。

把盘点结果存成一张迁移清单。不要只依赖终端历史，因为 CI、远程开发机和其他成员的 profile 往往不在当前机器上。

第一步：确认新旧命令到底指向哪里

迁移前后都应确认实际可执行文件，而不是只看版本字符串：

PowerShell
Get-Command kimi -All
kimi --version

macOS 或 Linux：

Bash
command -v -a kimi
kimi --version

如果结果有多个路径，先处理 shell alias、PATH 顺序或包管理器留下的旧 shim。否则你可能已经安装 Kimi Code，却仍在执行旧 Kimi CLI。

验证标准是：新开一个终端后，交互命令和脚本环境都解析到预期的 Kimi Code 可执行文件。仅在当前 shell 手动执行成功，不算完成。

第二步：不要盲拷配置，先确认配置优先级

Kimi Code 的 provider、模型、权限和项目设置可能同时来自环境变量、用户配置和项目配置。迁移时最危险的做法是把旧目录整体复制过去，再让新客户端猜哪些字段有效。

按下面顺序逐项验证：

  1. 先只保留最小的登录或 provider 配置。
  2. 启动 Kimi Code，确认实际模型和 provider。
  3. 再加入项目级规则。
  4. 最后恢复 MCP 和权限模式。

每加一层都执行一个无副作用的探针，例如只让 Agent 读取当前目录并报告模型、可用工具和配置来源。这样一旦配置被覆盖，能马上定位到具体层级。

如果使用环境变量提供 Key，不要只检查变量存在。现有 Kimi Code 的 -p 凭据问题表明，非交互入口可能与交互会话读取不同的 provider 配置。必须分别验证交互终端和自动化命令。

第三步：先迁移非交互脚本

对个人使用者，交互会话失败通常能马上发现；对团队来说，真正容易漏掉的是 CI、cron、hooks 和批处理脚本。

为每个非交互入口运行一个最小 smoke test：

Bash
kimi -p '只读取当前目录的文件名，不要修改文件；输出当前使用的模型和可用工具数量。'

命令形式以你安装版本的帮助信息为准。关键不是这一句 prompt，而是验证该入口能：

  • 找到认证凭据。
  • 解析到期望模型。
  • 读取项目规则。
  • 在无 TTY 条件下结束。
  • 不请求超出预期的权限。

将 stdout、stderr、退出码、版本和配置来源写入 CI 工件。出现问题时，provider 没有凭据、权限等待和模型不一致才能区分开来。

第四步：MCP 和权限要重新验收

客户端迁移会改变工具发现、OAuth 存储或权限提示的表面。即使 MCP Server 地址未变，也不能假定授权状态和工具范围会被安全继承。

迁移后依次检查：

  • 每个 MCP Server 是否显示为已连接。
  • 需要 OAuth 的服务是否要求重新授权。
  • 只读工具能否正常调用。
  • 写入、部署、删除等高风险工具是否仍需要人工确认。
  • 旧的 allowlist 或权限模式是否被新默认值覆盖。

先使用一个无副作用工具进行连接验证，再测试写入型工具的审批路径。不要为了“迁移一次跑通”而把危险命令加入全局自动允许。

推荐迁移顺序

1. 建立回退点

保存当前版本、可执行文件路径、有效配置文件列表和一份脱敏的环境变量名称清单。不要把 Key 写进仓库或迁移记录。

2. 在一个试点项目迁移

选择一个有项目规则、但没有生产写入权限的仓库。先完成交互会话、-p 调用和一个只读 MCP Server 的验证。

3. 对比同一任务

让旧 CLI 和 Kimi Code 各执行同一个只读任务，比较模型、工具调用次数、权限提示和退出码。差异比“回答文本像不像”更重要。

4. 更新自动化

替换固定路径、容器镜像、CI 缓存键和安装步骤。给脚本增加版本检查，避免 runner 静默回退到旧客户端。

5. 再迁移高权限项目

涉及生产环境、密钥、发布或数据库写入的项目最后迁移。先验证权限提示和审计记录，再逐步放开必要工具。

常见故障怎么分流

新客户端启动了，但仍然走旧 provider

先检查项目配置、用户配置和环境变量的覆盖顺序，再检查 shell 是否还在调用旧 shim。不要先重装，因为重装无法解释配置为何被覆盖。

交互可用，-p 报没有凭据

这是非交互配置路径没有读到 Key 或 provider 的典型表现。分别记录两条命令的环境变量名称、工作目录和配置文件来源，优先查看 Kimi Code 的非交互认证文档与版本说明。

MCP 连接成功，但 Agent 反复等待批准

这通常是权限策略的预期行为，不应通过全局允许来“修复”。确认新客户端的权限模式和工具分类，再按项目增加最小范围授权。

CI 升级后找不到命令

检查 runner 的安装步骤、PATH 和缓存。交互机上安装成功，不会自动替换 CI 容器或自托管 runner 的镜像。

迁移验收清单

  • [ ] 新终端和 CI 都解析到预期的 Kimi Code 版本。
  • [ ] 旧 kimi-cli 绝对路径和 alias 已被清理或明确保留。
  • [ ] 交互会话与 -p 非交互调用都能读取正确凭据。
  • [ ] 项目规则在试点仓库中生效。
  • [ ] MCP 的只读连接、OAuth 和高风险审批分别验证。
  • [ ] CI 保存了版本、退出码和脱敏诊断信息。
  • [ ] 高权限项目在试点通过后才迁移。
  • [ ] 出现问题时可以按记录回退到旧客户端，而不是临时关闭权限控制。

什么时候算迁移完成

迁移完成不是出现了一次欢迎页，而是交互、非交互、项目规则、MCP 和权限五条路径都能在新客户端下复现预期行为。把这份验收记录留在仓库里，下一次客户端替换或新成员接手环境时，团队不必重新猜一遍配置到底从哪里来。

参考来源

Kimi CLI 1.50.0 releaseMoonshotAI GitHubKimi CLI releasesMoonshotAI GitHub

相关文章

Kimi Code -p 报 provider 没有凭据：环境变量里的 Key 为什么没被读到智能编程 / 约 8 分钟Kimi Code 权限与计划模式变化：危险命令和无人值守任务怎么验收智能编程 / 约 8 分钟为什么 AI Agent 写代码必须有 AGENTS.md / CLAUDE.md：提高质量的 9 个关键理由智能编程 / 约 16 分钟MCP Server 安装前怎么检查 tool poisoning 风险智能编程 / 约 12 分钟

作者信息

luowj

关注 AI Coding 工具链、开发环境排障、工程发布和安全边界。文章优先基于官方文档、 真实报错、公开事件和可复现的检查步骤整理。

luowj1998@gmail.com提交文章反馈