Kimi Code CLI：从 Kimi CLI 演进而来的终端 AI 编码 Agent

一句话判断

如果你今天只打算读一篇 MoonshotAI 的终端 agent 文章，应该读 Kimi Code CLI，而不是单独读旧版 Kimi CLI。前者已经是主线产品；后者更像这条产品线的上一代形态，真正留下来的价值是它较早把 Shell Mode、ACP 和 MCP 这三条路线跑通了。

先把名字讲清

Kimi CLI 和 Kimi Code CLI 不是两条平行产品线，而是同一条路线的前后两代。

上游 README 对这件事说得很直接：Kimi CLI 正在演进为 Kimi Code CLI，安装 Kimi Code 后会自动迁移配置和会话。这一点决定了选型顺序：新用户直接从 Kimi Code 开始，老用户理解 Kimi CLI 则主要是为了看清这条路线怎么演变过来。

系统地图

把这条产品线拆开看，最容易混淆的是“终端本体”“编辑器集成”“工具扩展”“自动化编排”其实不是一回事：

这样看就更清楚了：Kimi CLI 的价值在于把几条关键能力先打通；Kimi Code CLI 的价值在于把它们收束成一个更完整的终端编码产品。

这条路线真正解决了什么

MoonshotAI 这两代产品想解决的，不是“再做一个会写代码的聊天框”，而是把开发者在终端里最常发生的三类动作放回一个连续上下文里：

1. 读写代码。
2. 执行命令。
3. 调用外部工具与系统。

很多同类工具也能做到前两项，但它们往往把“聊天”“执行命令”“接 IDE”“接外部工具”做成分散入口。Kimi 这条路线比较鲜明的一点，是一直在把这些能力收束成终端里的同一工作流，而不是让你在插件、浏览器、配置文件和 shell 之间来回跳。

Kimi CLI 留下了什么

旧版 Kimi CLI 之所以值得保留在这篇文章里，不是因为它还是首选，而是因为它把几条后来仍然重要的能力先做成了清晰产品特征。

1. Shell Mode：它首先证明了“agent 和 shell 可以不分家”

Kimi CLI 支持按 Ctrl-X 切到 shell command mode，在同一个会话里直接跑命令，再把结果喂回 agent 上下文。这个设计当时很抓人，因为它不是把终端当聊天背景，而是把终端命令本身变成 agent 工作流的一部分。

这套模式也有边界：官方文档明确写了 cd 这类 built-in shell 命令暂不支持。所以它更像“把常见命令执行接进 agent”，而不是完全替代你的日常 shell。

2. ACP：它很早就押注“agent 应该服务化接入 IDE”

Kimi CLI 是较早原生支持 ACP（Agent Client Protocol）的终端 agent 之一。它的意义不是“也能连编辑器”，而是把 agent 进程和 IDE UI 解耦了：编辑器只负责面板和交互，真正的 agent runtime 跑在外部 CLI 进程里。

这条路线后来在 Kimi Code CLI 上没有被放弃，反而继续保留成正式能力。对于 Zed、JetBrains 这类 ACP 兼容环境，这仍然是 MoonshotAI 方案里很关键的一环。

3. MCP：它先把工具接入做成一等公民

Kimi CLI 阶段已经把 kimi mcp 子命令做得很完整，覆盖 stdio、streamable HTTP 和带 OAuth 的 HTTP server，还支持 --mcp-config-file 这种 ad-hoc 配置。换句话说，它不是“支持一下 MCP”，而是很早就把 MCP 当成正式扩展层。

到了 Kimi Code CLI，这条线的重点从“命令可配”进一步变成“对话里就能配”。这就是 /mcp-config 的意义：不是新增协议能力，而是把原来偏工程师的 JSON 和命令行配置前移成对话式操作。

Kimi Code CLI 为什么更值得现在读

如果说 Kimi CLI 的关键词是“把路打通”，那 Kimi Code CLI 的关键词就是“把路铺平”。它比前代更像一个已经成型的终端 AI 编码产品，差异主要集中在下面几件事。

1. 单二进制分发，降低环境门槛

# macOS / Linux
curl -fsSL https://code.kimi.com/kimi-code/install.sh | bash

# Windows (PowerShell)
irm https://code.kimi.com/kimi-code/install.ps1 | iex

这不是单纯追求“少打一条命令”。对服务器、容器、CI runner 这类环境来说，不依赖 Node.js 或 Python 运行时，本身就是很实际的部署优势。

安装后验证：

kimi --version

2. 自研 TUI，让终端不只是命令宿主

Kimi Code CLI README 强调毫秒级启动和自研 TUI。这里最值得注意的不是“界面更好看”，而是它把长会话、审批、工具调用、扩展入口都压进终端原生交互里。这个方向和“在 shell 里顺手加一个 AI 命令”不是一回事，它更接近把终端做成 agent 的主场。

3. 子代理把复杂任务切出主线程

内置 coder、explore、plan 子代理，意味着它不只是在一个上下文里硬撑所有任务，而是允许把探索、规划、编码拆进隔离上下文里并行处理。对于复杂仓库，这是比“回复更聪明”更重要的工程能力，因为它直接影响主线程上下文是否会被污染。

4. 视频输入和插件生态把场景做宽了

视频输入是一个不太常见但很有辨识度的能力。它说明 Kimi Code CLI 不只面向纯文本代码改写，还在尝试吸收 demo、录屏、界面操作这类传统终端工具难处理的输入。

插件生态和信任级别展示，则说明团队想把 skills、MCP server、data source 当成分发层来经营，而不是只做本体功能。

5. 生命周期 hooks 让它能接进团队流程

生命周期 hooks 的价值在于：你可以在关键节点插入自己的本地命令，用来做审批、审计、通知或安全拦截。这样一来，Kimi Code CLI 就不仅是一个“个人助手”，也可能成为团队自动化流程里的一个执行节点。

快速开始

cd your-project
kimi

首次启动时在 TUI 内运行 /login，选择 Kimi Code OAuth 或 Moonshot AI Open Platform API key 完成认证。

一次典型任务怎么流过这条系统

如果你把这两代产品线连起来看，一次典型工作流大致会是这样：

1. 你在项目目录里启动 kimi，先用终端会话进入主线程。
2. 如果要接 IDE，就让 Zed 或 JetBrains 通过 kimi acp 把会话挂进 agent 面板。
3. 如果任务要调用外部工具，就接入 MCP server；旧版更偏 kimi mcp 命令，新版更偏 /mcp-config 对话。
4. 当主线程任务变复杂时，再把探索、规划或编码拆给子代理。
5. 如果团队需要审批或审计，再在生命周期 hooks 上挂自己的命令。

这个流转说明，Kimi 的重点从来不是单一功能点，而是把终端、IDE、工具生态和流程编排组织成一个连续执行面。

MCP 原生支持

Kimi Code CLI 对 Model Context Protocol（MCP）的支持不是"能配置 JSON 就行"的层面，而是做成了对话式管理：

/mcp-config

在聊天中直接添加、编辑、认证 MCP 服务器，不需要手动编辑 JSON 文件。这对于不熟悉 MCP 配置格式的开发者来说是一个显著的易用性提升。

编辑器集成（ACP）

通过 Agent Client Protocol（ACP），Kimi Code CLI 可以被 Zed、JetBrains 等 IDE 直接驱动：

// Zed 配置示例
{
  "agent_servers": {
    "Kimi Code CLI": {
      "type": "custom",
      "command": "kimi",
      "args": ["acp"],
      "env": {}
    }
  }
}

kimi acp 子命令让 agent 会话通过 stdio 与编辑器通信，无需额外登录。

这段配置背后的判断是：如果你的主要工作场景已经在 Zed 或 JetBrains 里，ACP 比“单独开一个聊天窗口”更合理，因为它保留了外部 CLI 进程的能力边界，又不牺牲 IDE 内的使用体验。

插件生态

支持从 marketplace 或任意 GitHub 仓库安装 skills、MCP 服务器和数据源。每个安装的信任级别会在界面中明确标注——这对于安全意识较强的开发者来说是一个值得关注的设计细节。

生命周期钩子

可以在 agent 执行流程的关键节点插入本地命令：审查高风险工具调用、记录审计日志、触发桌面通知、连接自定义自动化。这让 Kimi Code CLI 不只是一个工具，而是一个可以被编排的自动化节点。

技术取舍分析

适用边界

适合谁

• 在终端环境中工作的开发者，希望有一个低延迟的 AI 编码助手
• 在服务器/容器/CI 等无 GUI 环境中需要 AI agent 能力
• 使用 Zed/JetBrains 并希望集成终端 agent 的开发者
• 对 MCP、插件、hooks 这类扩展层有明确需求的团队或重度用户

不太适合谁

• 依赖深度 IDE 集成（如内联 diff 预览、语义跳转）的场景——TUI 有表达力边界
• 只想要一个纯文本问答助手、并不打算使用 tool calling、MCP 或终端命令的人
• 对 MoonshotAI 默认模型路线没有兴趣、同时又不想额外配置兼容 provider 的用户

采用顺序建议

如果你准备实际试用，这个顺序最省时间：

1. 直接安装 Kimi Code CLI，不必从旧版 Kimi CLI 起步。
2. 首次启动后在 TUI 里执行 /login 完成认证。
3. 先用一个真实项目目录跑一次基础任务，感受终端主线程是否顺手。
4. 再用 /mcp-config 接一个你真正会用到的 MCP server，而不是为了“体验 MCP”而堆配置。
5. 如果你本来就在 Zed 或 JetBrains 里工作，再接 kimi acp，把 CLI 会话带进编辑器。
6. 只有当你需要理解旧文档、迁移旧安装，或者特别想体验 Ctrl-X 的 Shell Mode 时，再回看 Kimi CLI 资料。

阅读路径

• GitHub 仓库 — 当前主线源码与文档
• 官方文档 — 安装、配置、ACP 与扩展说明
• 中文 README — 中文文档
• Kimi CLI 仓库 — 查看旧版 Shell Mode、kimi mcp 与迁移说明