企业官网建设流程全解析

Kimi CLI 的架构蓝图：从 Ensoul 到 AI-shell 的演进与 KLIP 提案机制

【免费下载链接】kimi-cliKimi Code CLI is your next CLI agent.项目地址: https://gitcode.com/GitHub_Trending/ki/kimi-cli

本文基于仓库中的 klip-0-klip.md 展开。Kimi CLI 并非凭空诞生：它脱胎于 2025 年 9 月的一个 side project「Ensoul」，在演化过程中沉淀出以「Kosong」为核心的 agent 内核，并最终确立了「面向大众的 GUI agent、面向程序员的 AI-shell、面向程序员的 IDE 集成 agent」三种产品形态。阅读本文，你将理解 Kimi CLI 的架构分层（内核 / UI 形态 / 可扩展性）、Kosong 与 KimiSoul 的职责划分，以及 KLIP（Kimi CLI Improvement Proposal）提案机制如何支撑这个项目以可扩展的方式持续演进。

Kimi CLI 的前世今生：从 Ensoul 到 AI-shell

Kimi CLI 起源于 2025 年 9 月 1 日晚上开始的一个 side project——「Ensoul」。Ensoul 是一个命令行程序，它的核心功能是：

1. 加载指定的 agent 文件（其中包含 system prompt 和要启用的 mshtools 中的 tool list）；
2. 进入 REPL 接收用户 prompt；
3. 对用户 prompt 运行 agent loop。

项目取名「Ensoul」（赋予灵魂）是因为这个过程很像在给一个「死的」agent 文件「赋予灵魂」，让它「活起来」——这正是 Kimi CLI 内核延续至今的核心抽象：一个 agent 文件 + 一个 agent loop = 一个活着的智能体。

YAMAHA 与 Kosong 的沉淀

Ensoul 最初的目标是让不懂代码的 PM 能够利用当时的内部 agent 开发框架「YAMAHA」（全称Yet Another Moonshot Agent, Hallucination Avoided）。YAMAHA 本身是更早的、专用于跑 GAIA benchmark 的「YAMA」的重写版，重写后发展成了一个更为通用的 agent 开发框架，提供「ChatProvider」「Message」「Context」「Tool」「Toolset」等 agent 构建单元。

当 Ensoul 逐渐取代 YAMAHA 的位置，进而演变成 Kimi CLI 时，YAMAHA 中最通用的那部分沉淀到了Kosong。Kosong 在马来语中意为「空」，如此命名是希望它只提供「机制」、不提供「策略」——它不含有任何「实际的东西」，却又什么都蕴含了。这个哲学直接体现在 packages/kosong/src/kosong/init.py 的模块说明中：

Kosong is an LLM abstraction layer designed for modern AI agent applications. It unifies message structures, asynchronous tool orchestration, and pluggable chat providers so you can build agents with ease and avoid vendor lock-in.

从今天的源码结构看，Kosong 包含四大部分：

其中最为关键的是step函数——它是 agent 开发的核心原语。从源码看，kosong.step的语义是：基于给定上下文只生成一次LLM 响应，期间实时把流式消息分片推送给on_message_part回调，工具调用交给toolset异步处理，最终返回一个StepResult（携带生成的Message、token 用量、工具调用列表及可await的工具结果 future）。StepResult还附带trace_id（来自响应头的x-trace-id），供上层做链路追踪。

正是 Kosong 的存在，使得 Kimi CLI 的核心 agent loop——「KimiSoul」的实现只需要约 400 行 Python 代码。这句话可以在 src/kimi_cli/soul/kimisoul.py 中得到印证：KimiSoul 类自身聚焦于「一轮 turn 的生命周期管理」（通知投递、动态注入、历史归一化、带重试的 LLM 调用、工具执行、上下文增长、结果判定），而底层每一步的 LLM 调用与工具编排，则直接委托给kosong.step。

为什么叫 Kimi CLI

CLI 的全称是「Command Line Interface」，是所有运行在终端的命令行界面程序的统称（类似于 GUI 之于图形界面程序、Web 之于浏览器程序）。当团队意识到 Ensoul「就是」Kimi CLI 时，命令的名字被改成了kimi。

这里有一个重要的产品定位：它从一开始就不只是一个 coding agent，而是运行在命令行界面的 Kimi 智能助理——人们应该期待它可以做任何事，只是以命令行界面的形式呈现。

三种形态的愿景：GUI、AI-shell 与 IDE 集成

「没有人想在终端里用聊天界面」是项目早期共识。团队认为，把 chat UI 放进终端（如 Claude Code 的做法）更多是出于开发速度的考量，而不是终端的天然形态。因此 Kimi CLI 在最初就确立了三种 agent 形式：

1. 面向大众的图形界面 agent；
2. 面向程序员的 AI-shell；
3. 面向程序员的 IDE 集成 agent。

Kimi CLI 的第一步，是成为 AI-shell——至少长得像个 AI-shell。这一点在 README 中体现为「Shell command mode」特性：按下Ctrl-X即可切换进入 shell 命令模式，在不离开 Kimi CLI 的情况下直接运行本地命令。

（图片说明：Kimi CLI 在终端中的交互界面，展示 Shell 模式、会话信息、模型与快捷键提示。）

内核大于形态：Print 模式、Wire 模式与 ACP

KLIP-0 强调了一个关键判断：UI 不是本质问题。无论表现为什么形态，内核是一样的。CLI 程序是一个非常理想的提供 agent 内核的形式——就像 MCP 工具最广泛的使用方式是npx+ stdio 上的 JSON-RPC 通信，Kimi CLI 在 Shell UI 之外，还提供了多种内核接入形态。

Print 模式：无交互运行

通过--print参数（配合--command或 stdin）可以无交互地运行 Kimi CLI，输出到 stdout。从 src/kimi_cli/cli/init.py 的命令行定义可以看到相关参数：--print、--input-format（如stream-json）、--output-format，以及--command/--query。仓库中的 kimi-cli-stream-json 示例 展示了如何用 Stream JSON 格式消费这种输出。

Wire 模式：可编程的 agent 事件流

Wire 模式通过 stdio 以特定格式接受用户 prompt 并推送 agent 行为事件。从 src/kimi_cli/wire/jsonrpc.py 看，Wire 协议基于 JSON-RPC 2.0，定义了JSONRPCInitializeMessage、JSONRPCReplayMessage、JSONRPCSteerMessage、JSONRPCCancelMessage、JSONRPCSetPlanModeMessage、JSONRPCEventMessage等消息类型，覆盖了初始化、回放、转向（steer）、取消、计划模式切换与事件推送等完整交互面。基于 Wire 模式，团队构建了内部的 Web UI 和正在开发的 VS Code 扩展。仓库中的 kimi-cli-wire-messages 示例 演示了如何消费这些 Wire 消息。

ACP 模式：接入任意 ACP 客户端

Kimi CLI 通过--acp参数提供 ACP 服务端（同样走 stdio 通信），支持接入任何 ACP 客户端，这使得 Kimi CLI 可以接入 JetBrains、Zed 等 IDE，也可以接入 DeepChat、Alma 等本地通用 agent 客户端。

仓库对 ACP 集成的支撑不止于协议层。在 klip-2-acpkaos.md 中，团队设计并实现了ACPKaos——一个把文件读写与终端命令重定向到 ACP 客户端的 KAOS 后端，从而让 Zed 等 ACP 客户端能够观察到 agent 的文件编辑与命令执行。对应实现位于 src/kimi_cli/acp/kaos.py：ACPKaos包装本地LocalKaos（packages/kaos/src/kaos/local.py），仅按客户端能力（read_text_file、write_text_file、terminal）覆盖readtext、writetext、exec等最小操作面，其余操作全部透传给本地后端，从而保持既有工具行为不变。

README 给出了在 Zed / JetBrains 中接入 Kimi CLI 的 ACP 配置方式（将 Kimi CLI 配置为 ACP agent server，命令为kimi acp）：

{ "agent_servers": { "Kimi CLI": { "type": "custom", "command": "kimi", "args": ["acp"], "env": {} } } }

（图片说明：Kimi CLI 作为 ACP agent server 接入外部客户端的线程界面，支持@引用上下文与/命令。）

「我们最开始所畅想的三种形式，正在一一出现并变得可用」——这是 KLIP-0 对形态演进的总结，也与 README 中 VS Code 扩展（kimi code）、ACP 集成等特性相互印证。

从第一天就支持定制化：agent 文件、MCP、Skills 与 SDK

Kimi CLI 内核的能力不仅限于提供一个预定义好的 agent。从 Ensoul 的第一天起，它就是支持定制化的：

• agent 文件定制：像诞生第一天那样，Kimi CLI 支持通过 agent 文件定制 system prompt 和 tool list。仓库内置了default、okabe等 agent（见 src/kimi_cli/agents/），并通过--agent/--agent-file参数支持自定义；
• MCP tools：通过 Model Context Protocol 扩展能力（kimi mcp子命令、~/.kimi/mcp.json配置）；
• Skills：通过 Agent Skills 注入技能（如仓库内置的 kimi-cli-help 与 skill-creator）。

这些机制使每个用户都能以独特的方式使用 Kimi CLI。定制化体系在 klip-3-kimi-cli-user-docs.md 的文档大纲中得到了完整的规划：定制化章节涵盖 MCP、Agent Skills、Agent 与子 Agent、Print 模式、Wire 模式等主题，并逐一标注了对应的源码参考位置。

除了使用kimi命令，Kimi CLI 还可以作为 Python 依赖安装，直接使用其中模块解耦良好的 agent kernel 和 UI 组件来构建上层应用。下一步规划是对 Wire 模式做进一步封装，形成Kimi Agent SDK，使得用 Python、Node.js、Go 等语言的用户能更方便地构建 agent 应用。

Monorepo 与可复用内核的落地

「内核可复用」并非停留在理念层面。在 klip-1-kimi-cli-monorepo.md 中，团队将 Kosong 与 PyKAOS 迁入 Kimi CLI monorepo（packages/kosong与packages/kaos），通过 uv workspace 实现三包联动开发、独立发布：

• kimi-cli：纯数字 tag（如0.68）；
• kosong：kosong-0.20.0风格 tag；
• pykaos：pykaos-0.2.0风格 tag。

这样，Kosong 作为「LLM 抽象层 + agent 开发原语」既可以服务于 Kimi CLI 自身，也能独立发布供其他 agent 应用复用。仓库根目录 pyproject.toml 中的 workspace 配置（tool.uv.workspace.members与tool.uv.sources）正是这一设计的体现。

关于「Lead, don't follow」

「Lead, don't follow」是团队收到的最好的鼓励。KLIP-0 坦承，鉴于更年轻，Kimi CLI 不可避免地落后于 Claude Code、OpenCode 等优秀项目，但绝不盲目 follow 它们：Kimi CLI 所有的想法、功能都是从零开始自然发生的，所有架构都是从零思考的。其中许多部分与先驱产品不谋而合（如 Wire 模式和 ACP 非常接近，Kimi Agent SDK 与 Claude Agent SDK 架构相似），但这不影响团队从第一性原理思考事情的本质。

KLIP：让 Kimi CLI 的开发以可扩展的方式进行

Kimi CLI 内核的大厦已经初具稳定的形状，此时引入一个机制让开发以更 scalable 的方式进行，同时也是对下一代软件开发范式的探索——这就是KLIP（Kimi CLI Improvement Proposal）的由来。

为什么需要 KLIP：Code is cheap

KLIP-0 提出了一个重要的时代判断：Code is cheap已经成为共识。提出 pull request 已经没有成本，不需要人的思考就可以写出几百上千行代码，可以完成功能，也能通过所有测试——但这不代表价值，无脑堆砌 agent 代码只会造成不可控的屎山。

当代码本身变得没有价值时，代码架构、可扩展性、稳定性、产品决策的重要性反而更为凸显。Linus Torvalds 有句名言：「Bad programmers worry about the code. Good programmers worry about data structures and their relationships.」——当我们有了良好的数据结构和关系，功能代码会自动生长出来，这时候 agent 写的代码也会是美的。

因此，KLIP 应该强调数据结构和关系的变化，而不是逐行的代码改动。

典型工作流程：KLIP 与代码同时迭代

对于稍大的功能，Kimi CLI 的典型工作流程是六步：

1. 无脑给 agent 提出需求，看看会写出什么——可以迭代或重写，获得一个足以证明思路可行的东西；
2. 与此同时，程序员思考此功能所需的「本质修改」——即对架构、数据类、协议、模块接口的修改；
3. 程序员和 agent 共同撰写和迭代 KLIP，详细描述所有「本质修改」——应尽量使用伪代码和图示，既不空中楼阁，也不追求细化到每一行代码的变化；
4. 让其他人 review KLIP，根据反馈调整 KLIP 和 feature 分支上可能已经存在的原型代码——要保持 KLIP 更新，始终反映「本质修改」；
5. 从 KLIP 用 agent 生成具体的代码实现——代码实现也可能在迭代 KLIP 的过程中就已经成熟了，这没问题；
6. 用最少的精力 review 具体的代码变更，合并。

这个流程和过去大型软件的迭代过程非常类似，区别在于：KLIP 和代码可以同时迭代。当 KLIP 被 accept 时，代码几乎已经可用了，而不会出现（最好是不会出现）「KLIP 想得很好，但实现出来跟想象差别很大」的情况。这实际上与 Linux kernel、CPython、C++ 这类更严肃的分布式开发的超大型软件是一致的——这些项目的贡献者在提出提案时，往往已经写好了一个可以工作的原型。Agent 的辅助可以让我们更好地实践这个高标准的流程。

KLIP 在仓库中的实践

这个机制并非纸上谈兵。当前仓库的 klips/ 目录下已经沉淀了十余个 KLIP，涵盖从架构级到协议级的各类提案，且均已标注Status: Implemented：

每个 KLIP 都遵循「先有可运行原型、再写本质修改提案」的模式。以 KLIP-2 为例，提案先给出 ACPKaos 的伪代码设计（readtext/writetext/exec的最小覆盖面、能力位独立的约束、未保存缓冲区这一已知限制），再落地为 src/kimi_cli/acp/kaos.py 中约 200 行真实实现——提案中的设计决策（如 append 仅当 read+write 都支持时才走 ACP、stat/exists/is_file保持本地以规避未保存缓冲区问题）与最终代码一一对应，这正是「KLIP 反映本质修改、代码随提案生长」的实证。

结语

Kimi CLI 的架构蓝图可以概括为三层：

• 内核层：Kosong 提供 LLM 抽象与 agent 原语（generate/step），KimiSoul 以约 400 行代码实现完整的 agent loop；
• 形态层：Shell UI、Print 模式、Wire 模式、ACP 模式共享同一内核，以不同界面形态触达不同用户；
• 演进层：agent 文件、MCP、Skills、Python 依赖、Kimi Agent SDK 构成可扩展生态，KLIP 提案机制则保证了架构级演进的秩序与质量。

从 Ensoul 到 Kimi CLI，从「赋予 agent 文件灵魂」到「以命令行界面的形式做任何事」，这个项目的核心信念始终如一：内核是本质，形态是表象；好的数据结构和关系，会让 agent 写出的代码也是美的。

【免费下载链接】kimi-cliKimi Code CLI is your next CLI agent.项目地址: https://gitcode.com/GitHub_Trending/ki/kimi-cli