Kimi 有個「賦予靈魂」的神秘項目，它的故事全都開源了

今天，《人物》雜志發表了一篇報道：

文章中提到，Kimi 這群人，很會起名字，起名字的時候很有品味。

在 2025 年的 9 月，公司內部啟動了一個小項目，名為「Ensoul」（賦予靈魂）。

根據 APPSO 了解，Ensoul 的出現，最初是為了讓不懂代碼的產品經理也可以利用內部的 agent 開發框架。

這個框架，名叫「YAMAHA」。

其底層，包含 LLM 抽象層和 Agent 開發原語等關鍵要素，則被命名為「Kosong」，馬來語言中的「空」——空即是色，色即是空。它不含有任何「實際的東西」，卻又什么都有。

Ensoul、YAMAHA、Kosong……它們演化為了 Kimi CLI。

是的，Kimi CLI，在 Claude Code 之外，最優秀、先進、好用的智能體交互工具之一，目前以命令行形式存在。

作為中國人工智能開源軍團中的主將之一，月之暗面的許多產物，包括模型、算法、工具、架構等，都是開源的。

巧合的是，Kimi CLI 的誕生故事，以及它可能將會前往的方向，同樣也在月之暗面的開源倉庫中。

這個故事，是 KLIP——Kimi CLI 進化行動綱領的第零章。

故事原作者是 Kimi CLI 的主創之一，阿西/Richard Chein/@stdrc。

APPSO 認為，對于那些想要復刻出一個 CLI 編程工具，乃至于對智能體代理交互有研究興趣的人們來說——閱讀這個故事，以及整個 KLIP 的更多章節，或許會比胡亂解讀 Claude Code 泄露代碼更有意義。

今天，我們就來回顧 Kimi CLI 的前世今生：

我們自作主張，加入了更多換行、加粗，以便閱讀核心信息。

原文地址：

https://github.com/MoonshotAI/kimi-cli/blob/main/klips/klip-0-klip.md

Kimi CLI 的前世今生Kimi CLI 起源于 2025 年 9 月 1 日晚上開始的一個 side project——「Ensoul」。Ensoul 是一個命令行程序，功能是加載指定的 agent 文件（其中包含 system prompt 和要啟用的 mshtools 中的 tool list），進入 REPL 接收用戶 prompt，對用戶 prompt 運行 agent loop。（注：REPLRead-Eval-Print Loop讀取-求值-輸出-循環，它是許多編程語言提供的一種交互式編程環境。如 Claude Code、Kimi 等 CLI 版本，可以理解為一種 REPL。）項目名字叫「Ensoul」是因為這個過程很像在給一個「死的」agent 文件「賦予靈魂」，讓它「活起來」。

Ensoul 最初的目標，是讓不懂代碼的 PM 能夠利用當時已有的內部 agent 開發框架——「YAMAHA」。

YAMAHA 是硬湊出來的名字，全稱是「Yet Another Moonshot Agent, Hallucination Avoided」（又一個月之暗面智能體，避免幻覺），它是更早已存在的專用于跑 GAIA benchmark 的「YAMA」的重寫版。

重寫后的 YAMAHA 發展成了一個更為通用的 agent 開發框架，提供一些 agent 的構建單元，比如「ChatProvider」「Message」「Context」「Tool」「Toolset」——「Kosong」即脫胎于此。

Kosong 在馬來語的意思是「空」，如此命名是希望它只提供「機制」，不提供「策略」，它不含有任何「實際的東西」，卻又什么都蘊含了?！缚占词巧?，色即是空」。

當 Ensoul 逐漸取代 YAMAHA 的位置，又進而演變成 Kimi CLI 時，YAMAHA 中最通用的那部分東西，沉淀到了 Kosong。

現在的 Kosong 包含 LLM 抽象層和 agent 開發原語（其中最為關鍵的是step函數），是 Kimi CLI 最關鍵的基石。它的存在使得 Kimi CLI 的核心 agent loop——「KimiSoul」的實現只需要 400 行 Python 代碼。

現在回到 Kimi CLI。

CLI 的全稱是「Command Line Interface」，是所有運行在終端的命令行界面程序的統稱，類似于所有圖形界面的程序都稱為「GUI」程序，所有運行在瀏覽器的程序都稱為「Web」程序。

當意識到 Ensoul「就是」Kimi CLI 時，我們把命令的名字改成了kimi。

它從一開始就不只是一個 coding agent，而是運行在命令行界面的 Kimi 智能助理，人們應該期待它可以做任何事，以命令行界面的形式。

那么它應該長什么樣？

「沒有人想在終端里用聊天界面」是我們的早期共識。在 Claude Code 之前，人們只會在終端里用 shell，以及用 shell 運行其他命令行程序，如npmpythonrclone；而一般大眾則更是從來沒有打開過終端。

我們認為 Claude Code 把 chat UI 放到終端里完全是因為這樣開發起來最快。GUI 是需要時間的，而且需要項目有更多人力資源，終端的 chat UI 似乎是一種可以很快推出的、誰都不想要但誰都能勉強用的形式。

我們在最開始就認為，人們需要三種形式的 agent——面向大眾的圖形界面 agent、面向程序員的 AI-shell、面向程序員的 IDE 集成 agent。

Kimi CLI 的第一步，是成為 AI-shell，至少長得像個 AI-shell。

Kimi CLI 支持 shell mode，可以直接在對話中輸入 shell 命令。

但 UI 不是本質問題。無論表現為什么形態，內核是一樣的。

CLI 程序是一個非常理想的提供 agent 內核的形式。就像 MCP 工具最廣泛使用的形式是通過npx運行并在 stdio 上通過 JSON-RPC 通信，Kimi CLI 在 shell UI 之外，提供了 Print 模式和 Wire 模式，可以在 stdio 上通過特定的格式接受用戶 prompt 和推送 agent 行為事件。

基于 Wire 模式，我們有了內部的 Web UI，和正在開發的 VS Code 擴展。

（注：目前 Kimi VS Code 擴展已經開發完成。）

除此之外，我們通過 ACP 模式提供 ACP 服務端（同樣走 stdio 通信），支持接入任何 ACP 客戶端，這使得 Kimi CLI 可以接入 JetBrains 和 Zed 等 IDE，也可以接入 DeepChat、Alma 這樣的本地通用 agent 客戶端。

我們最開始所暢想的三種形式，正在一一出現并變得可用。

僅僅如此還不夠，從 Ensoul 的第一天開始，它就是支持定制化的。Kimi CLI 內核的能力不僅限于提供一個預定義好的 agent。像誕生第一天那樣，Kimi CLI 支持通過 agent 文件定制 system prompt 和 tool list。同時，我們也支持了通過 MCP tools 和 skills 擴展 Kimi CLI 的能力，使每個用戶可以以獨特的方式使用 Kimi CLI。

除了使用kimi命令，還可以把 Kimi CLI 安裝為 Python 依賴，直接使用其中模塊解耦良好的 agent kernel 和 UI 組件，構建上層應用程序。

下一步，我們將會對 Kimi CLI 的 Wire 模式做進一步封裝，形成 Kimi Agent SDK，使得用 Python、Nodejs、Go 等各種語言的用戶可以更方便地構建 agent 應用。

「Lead, don't follow」是我們收到的最好的鼓勵。

鑒于我們更年輕，不可避免地落后于 Claude Code、OpenCode 等優秀項目，但我們絕不盲目 follow 它們。Kimi CLI 所有的想法、功能都是從零開始自然發生的，所有架構都是從零思考的。

對于其中的許多部分，我們發現它與先驅產品不謀而合，比如 Wire 模式和 ACP 非常接近，Kimi Agent SDK 與 Claude Agent SDK 的架構也非常相似，但這不影響我們從第一性原理思考事情的本質。我們相信最終有一天我們可以 lead 一些事情。

KLIP: KimiCLImprovementProposal Kimi CLI 內核的大廈已經初具穩定的形狀，現在我覺得是時候引入一個機制讓 Kimi CLI 的開發以更 scalable 的方式進行，同時也是作為我們對下一代軟件開發范式的探索。

Code is cheap，這已經是所有人的共識了。提出 pull request 現在已經沒有成本，完全不需要人的思考，就可以寫出幾百上千行代碼，可以完成功能，也能通過所有測試。但這不代表價值，無腦地堆砌 agent 的代碼只會造成不可控的屎山。

當代碼本身變得沒有價值，代碼架構、可擴展性、穩定性、產品決策的重要性反而更為凸顯。這其實并不是現在才應該認識到的，Linux kernel 創始人 Linus Torvalds 有句著名的說法「Bad programmers worry about the code. Good programmers worry about data structures and their relationships.」就是這意思。

當我們有了良好的數據結構和關系，功能代碼會自動生長出來，這時候 agent 寫的代碼也會是美的。

因此，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 的輔助可以讓我們更好地實踐這個高標準的流程。

讓我們看看會發生什么。

https://github.com/MoonshotAI/kimi-cli/blob/2121c87c17fde41d5dfe63e135aaaa7c1c894976/klips/klip-0-klip.md

KLIP 行動綱領：

https://github.com/MoonshotAI/kimi-cli/tree/2121c87c17fde41d5dfe63e135aaaa7c1c894976/klips

我們正在招募伙伴

簡歷投遞郵箱hr@ifanr.com

?? 郵件標題「姓名+崗位名稱」（請隨簡歷附上項目/作品或相關鏈接）