
AI Agent代码智能体人工智能大模型CLI【免费下载链接】kimi-codeKimi Code CLI — The Starting Point for Next-Gen Agents项目地址https://gitcode.com/gh_mirrors/ki/kimi-code点击查看免费下载Kimi Code CLI 从 Python/uv 底层全面迁移至 Node.js 后moonshot-ai/migration-legacy包承担了将旧版 kimi-cli 数据配置、MCP、技能与会话历史无损导入新版的重任。本文基于 CHANGELOG.md 与官方迁移指南结合 migration-legacy 源码 逐层拆解其检测、迁移、幂等与容错机制帮助你理解kimi migrate背后发生了什么以及在多主目录、损坏数据等边界场景下如何安全迁移。迁移的背景为什么要迁移Kimi Code CLI 已完成一次重大底层升级从 Python/uv 技术栈整体迁移到 Node.js带来更简单的安装方式无需配置 Python 环境、更快的启动速度和全新的终端界面。旧版 kimi-cli 将逐渐停止维护因此官方建议尽快升级并将旧数据一并迁入新版。迁移包的目标非常聚焦把~/.kimi/下的 kimi-cli 数据迁移到~/.kimi-code/见 package.json 的 description 字段。旧数据与新版数据分属两个独立目录迁移过程不会改动或删除~/.kimi/下的任何旧数据kimi-cli 仍可照常使用两者互不影响。两种迁移方式首次启动自动检测装好 kimi-code 之后第一次运行kimi时它会自动检测~/.kimi/下是否存在 kimi-cli 的数据。一旦检测到就会弹出迁移提示你可以选择立即迁移稍后再说不再提示写入跳过标记后续不再打扰手动运行迁移命令你也可以随时手动运行迁移kimi migrate执行后会弹出交互式范围选择你可以选择是否同时迁移聊天会话Config only只迁移配置不迁移历史会话Config N sessions配置与全部本地会话一并迁移。迁移结束后会显示结果摘要你可以从摘要中直观看到各数据项的迁移数量与需要手动处理的告警。迁移流程的完整编排runMigration()是迁移的执行入口run-migration.ts它会按照MigrationScope决定的范围依序执行 6 个独立步骤步骤对应模块迁移内容配置steps/config.tsconfig.toml、tui.toml、hooks、device_idMCPsteps/mcp.tsMCP server 配置输入历史steps/user-history.ts命令行输入历史技能steps/skills.ts~/.kimi/skills/中的用户技能会话sessions/index.ts聊天会话逐条转换计划文件steps/plans.ts~/.kimi/plans/下的计划文件迁移开始与结束时都会记录 ISO 时间戳startedAt/completedAt并在每步完成后通过onProgress回调输出进度信息config done、mcp done等。迁移报告与错误日志每次迁移完成后系统会将完整报告序列化写入~/.kimi-code/migration-report.json对应 types.ts 中的MigrationReport以追加方式把本次运行的会话失败明细写入migration-errors.log——这是一个跨多次运行的追加式记录即使用户重试多次也能用一份日志覆盖全部重试尝试方便排查与分享。迁移的检测机制detectMigration()detect.ts在迁移前扫描源目录产出MigrationPlan它决定了迁移提示如何呈现、能迁移什么配置检测读取源目录的config.toml支持 TOML 与 JSON 两种旧格式判断是否存在MCP 检测检查mcp.json是否存在并额外扫描其中的mcpServers识别使用auth oauth的服务器列入迁移后需重新授权清单OAuth 凭证检测扫描~/.kimi/credentials/*.json结合旧配置中 providers 的oauth引用推导出迁移后需要重新执行/login的登录名列表技能与计划检测检查~/.kimi/skills/与~/.kimi/plans/是否含条目插件检测列出~/.kimi/plugins/下的插件名kimi-cli 插件不在迁移范围内仅作提示会话检测读取kimi.json中的work_dirs通过 oldMd5BucketName 反向映射出每个 MD5 会话桶对应的真实工作目录再对每个桶内的会话执行classifyLegacySession分类。会话分类每个旧会话都会被分类sessions/classify.tsreal真实可迁移的会话进入候选列表placeholder/empty占位或空会话直接跳过并计数malformed上下文缺失或不可读的会话不会被静默跳过而是被记录为sessionScanFailures在迁移结果中明确报告。从源码结构看detect.tskaos_md5形式的非本地 kaos 桶无法被本地 Kimi Code 运行时表示会被跳过并计入bucketsSkippedNonlocalKaos而其他任何无法映射的桶都被视为用户数据丢失风险必须保持可见并报告这正是 CHANGELOG 0.1.16 所强调的报告损坏或无法映射的会话而非静默跳过。配置迁移的精细处理配置迁移是最复杂的一步涉及旧格式到新 schema 的逐字段转换steps/config.ts。目标文件的三态处理迁移器读取目标config.toml后决定采用哪种写入模式overwrite覆盖目标文件不存在或内容等于默认模板通过 stub-detect.ts 的isTuiStubOrMissing判断时直接写入迁移结果merge合并目标已有用户配置且可解析时采用增量合并——只补充目标缺少的键/provider/model若同名条目双方值不同则保留目标值并记录冲突configConflicts目标值永远不会被覆盖mergeConfigsibling旁路文件目标文件存在但无法解析时迁移结果写入config.migrated-from-kimi-cli.toml旁路文件避免破坏用户现有配置并在结果界面提示用户手动合并。关键字段映射配置迁移中有一批映射与过滤规则其中 CHANGELOG 明确记录了两项修复default_yolo→default_permission_mode0.1.4 修复旧版 kimi-cli 的default_yolo键曾被错误映射到已废弃的yolo字段现已修正为映射到新版正确的default_permission_mode。当default_yolo true时迁移结果写入default_permission_mode yoloconfig.ts。废弃 flag 不再带入0.1.13 修复迁移时不再把过时的 legacyloop、background、plan、yolo等实验性 flag 带入迁移后的配置文件。源码中对应TOP_LEVEL_KEYS_TO_DROP new Set([plan_mode, yolo])且loop_control与background仅保留reserved_context_size、max_running_tasks、keep_alive_on_exit等有效字段config.tsexperimental块也只保留在新版 flag 注册表 中登记的布尔 flag。Provider 与 Model 的类型迁移旧 provider 类型映射openai_legacy → openai、google_genai → google-genai、gemini → google-genaiLEGACY_PROVIDER_TYPE_MAPSchema 校验每个 provider 必须通过新版 ProviderConfigSchema 校验且type必须属于支持集合anthropic、openai、kimi、google-genai、openai_responses、vertexai每个 model 须通过ModelRecordSchema否则计入droppedProviders/droppedModels引用完整性model 的 provider 若被丢弃、或与目标 config 中同名 provider 冲突该 model 也会被丢弃——避免迁移后 model 静默跑在错误端点/凭证上reasoning_key 下推provider 上的reasoning_key会被删除并注入到引用该 provider 且未显式设置reasoning_key的 model 上default_model 校验default_model若指向迁移后不存在的 model被丢弃、陈旧或从未存在则一并丢弃防止下次创建会话时因悬空别名而失败。tui.toml 拆分与 hooks 处理旧配置中的theme与default_editor属于 TUI 配置会被拆分写入tui.tomltheme仅接受dark/light/auto枚举其余值丢弃以防整文件校验失败若目标tui.toml已被用户修改则写入tui.migrated-from-kimi-cli.toml旁路文件hooks 按新版 HookDefSchema 逐条校验合法条目直接通过新旧 hook 结构一致非法条目计入droppedHooksdevice_id遥测身份标识仅在目标目录没有自己的device_id时从旧目录复制目标已启动过一次则保留其自身标识copyDeviceId。会话迁移幂等、自愈与故障报告迁移顺序与进度会话迁移按wire_mtime合并状态中的wire_mtime缺省时回退到wire.jsonl或 context 文件的 mtime从新到旧排序让用户最常看的最新会话先完成迁移每处理一个会话都会通过onSessionProgress(done, total)回调更新进度sessions/index.ts。幂等与自愈迁移支持重复运行已经迁移过的会话不会被重复导入。其实现机制是单会话迁移器migrateOneSession检测目标会话目录是否已存在返回migrated或already-migratedensureSessionIndexEntry是幂等的——即使目标目录被删除后残留了过期的索引行重新迁移同一会话也不会追加第二行sessions/index.ts若上一次运行在写入会话目录后、追加索引前崩溃重跑会通过幂等的索引补写实现自愈——会话恢复可被按 id 打开的能力sessions/index.ts。多主目录支持与标记文件CHANGELOG 0.1.16 的核心变更保持 legacy 迁移在多个 Kimi home 之间幂等。迁移器通过migratedMarker标记文件marker.ts记录已完成迁移的目标路径首次成功迁移写入标记包含version: 1、first_migrated_at、last_migrated_at、migrator_version、target_path与target_paths数组后续迁移同一源目录到不同目标目录例如不同的KIMI_CODE_HOME时通过appendMarkerRun把新目标路径追加进target_pathsshouldSuppressMigration据此判断这个源 这个目标是否已完成迁移避免对已迁移组合反复弹窗目标目录的路径比较在 Windows 上做了大小写归一化与绝对路径解析sameTargetPath标记写入是尽力而为的数据与报告已落盘完整标记写入失败不会导致迁移失败也不会中断健康的重复迁移run-migration.ts。故障报告而非静默跳过0.1.16 的另一核心变更对损坏或无法映射的会话报告而非静默跳过。会话汇总SessionsSummarytypes.ts提供了一组完整计数器与明细sessionsFailed迁移失败的会话及其原因如桶不可读、会话上下文缺失、索引追加失败等sessionsConflicts目标目录已存在同名会话导致的冲突列表sessionsSkippedPlaceholder/sessionsSkippedEmpty占位与空会话计数bucketsSkippedNonlocalKaos/bucketsSkippedNoWorkdirFound无法映射的桶计数。重要只要所选范围内还有未解决项——未迁移/不可检查的会话、目标冲突、或存在但无法解析的旧配置/MCP 文件——迁移器就不会写完成标记从而保留后续重试机会run-migration.ts。失败的会话会写入migration-errors.log并在结果界面呈现用户可以据此决定手动处理还是重跑。不会被迁移的内容重要边界迁移范围是经过刻意设计的以下内容不会被迁移迁移完成后需要在新版中手动处理数据原因与处理方式OAuth 登录凭证刷新令牌会在服务端轮换复制旧凭证会导致两个安装实例竞争刷新、先后登录失效。迁移后需在 kimi-code 中重新执行/loginMCP 服务授权需要重新授权结果界面会列出需要重新授权的 OAuth MCP 服务器清单kimi-cli 插件不在迁移范围内仅作为检测提示出现非本地 kaos 会话桶无法被本地 Kimi Code 运行时表示跳过并计数技能迁移0.1.2 引入的技能迁移会将用户技能从~/.kimi/skills/迁移到~/.kimi-code/skills/首次启动迁移时执行已存在的目标技能会被保留即目标优先、不覆盖。MigrationPlan.skillsSourceHome允许调用方自定义技能源目录默认指向~/.kimi/skills/。计划文件的说明~/.kimi/plans/下的计划文件会被纯复制到目标plans目录copied/skippedExisting计数但复制结果不接入新版 plan mode仅作为普通文件保留供用户自行复用或删除——迁移完成界面会给出明确提示run-migration.ts。迁移后会话标识从 kimi-cli 导入的会话会带上[imported]标记方便你与新建会话区分每个导入会话还会通过ensureSessionIndexEntry写入会话索引确保可按ses_uuid恢复打开。版本演进一览CHANGELOG 记录了该包从 0.1.2 到 0.1.16 的关键行为演进0.1.2新增用户技能迁移~/.kimi/skills/→~/.kimi-code/skills/保留已存在目标技能0.1.4修复default_yolo映射目标从废弃的yolo字段改为default_permission_mode0.1.13迁移后的配置不再携带过时的 legacy loop、background、plan、yolo 与未知实验性 flag0.1.16迁移在多个 Kimi home 之间保持幂等损坏或无法映射的会话被明确报告而非静默跳过。其余版本0.1.30.1.15均为依赖moonshot-ai/agent-core的同步更新不涉及迁移逻辑本身的变更。相关测试与验证仓库为迁移逻辑提供了完整的测试覆盖test/包括integration.test.ts端到端迁移集成测试resume.integration.test.ts重复迁移/恢复场景幂等性验证golden.test.ts金样本对比测试detect.test.ts、marker.test.ts检测与标记文件行为验证kimi-cli-schema.test.ts旧kimi.jsonschema 解析验证paths.test.ts源/目标路径解析验证sessions/ 目录下针对会话分类、转换与迁移的专项测试。如需深入理解迁移实现细节可从 migration-legacy 源码入口 开始依次阅读 detect.ts、run-migration.ts、steps/config.ts 与 sessions/index.ts。官方迁移指南参见 docs/zh/guides/migration.md 与 docs/en/guides/migration.md。赞分享AI Agent代码智能体人工智能大模型CLI【免费下载链接】kimi-codeKimi Code CLI — The Starting Point for Next-Gen Agents项目地址https://gitcode.com/gh_mirrors/ki/kimi-code点击查看免费下载相关推荐Kimi Code 迁移指南从 kimi-cliPython/uv平滑升级到 Node.js 版Kimi Code 迁移指南从 kimi cliPython/uv平滑升级到 Node.js 版 本篇指南围绕 迁移文档 https://link.gitAI Agent代码智能体人工智能大模型CLIKimi Code CLI 破坏性变更与迁移完全指南从 ensoul 到 kimi-cli 的升级路线图Kimi Code CLI 破坏性变更与迁移完全指南从 ensoul 到 kimi cli 的升级路线图 本篇指南以官方发布说明 docs/en/releas人工智能AI Agent代码智能体交互助手CLI工具调用从 kimi-cli 迁移到 Kimi Code CLI一条命令迁移配置、MCP 与会话历史全指南从 kimi cli 迁移到 Kimi Code CLI一条命令迁移配置、MCP 与会话历史全指南 Kimi Code CLI 已完成从 Python/uvAI Agent代码智能体人工智能大模型CLI上一篇SwiftyDropbox PKCE授权流程详解更安全的Token管理方案下一篇Jellium Desktop用户账户管理添加、删除与编辑用户的完整指南创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考