最近开发者圈传得最凶的一句话，是「kimi-cli 用 Python 是彻底的失败，立刻重构为 TS」。配的图是 Kimi 把自家命令行工具从 Python 推翻、重写成 TypeScript 的截图，不少人转发时都带着一句「连 Python 都保不住了」。
作为一个天天和 Node、TypeScript 打交道的人，我对那句狠话兴趣不大，更想知道一件事：它到底换成了什么技术栈？我把新仓库从头到尾翻了一遍，连 package.json 都对着看了一遍。结论比那句口号有意思得多，里面还藏着一个不少人都传错的细节。
先把两件事拆开：一个梗，一个真重写
网上流传的那张截图，其实把两件事并到了一起。
第一件是那条狠话的出处。它不是月之暗面发的官方公告，而是 kimi-cli 仓库里一个 PR（#1707）的描述标题。这个 PR 有几个容易被忽略的点：
-
作者是普通社区账号 ：GitHub 上的关联身份是
NONE，不是月之暗面的人。 -
开 PR 的日期是 4 月 1 日：愚人节当天提交，标题那句话本身就带着玩梗的味道。
-
到现在还挂着没合并：状态一直是 Open，没进主分支。
但这个 PR 也不全是玩笑，作者是真把活干了，三百来个文件、几万行代码，还附了一组 SWE-bench 对比。用的技术栈是 Bun + React Ink，全套押在 Bun 上。
第二件才是真正落地的产品。月之暗面 5 月 22 日新建了 kimi-code 仓库，5 月底一口气连发了 0.2 到 0.4 几个版本。老的 kimi-cli（Python 版，攒了八千七百多 star）README 顶部已经挂上提示：项目接下来由 kimi-code 接手，装新版会自动把配置和会话搬过去，Python 版逐步停更。
两件事时间差了一个多月，技术栈也不是一套。把社区那个愚人节 PR 的方案安到官方头上，是这次传播里最大的误会。
扒开 package.json：这是一套很「Node」的栈
先看一眼仓库根目录就有底了：pnpm-lock.yaml、pnpm-workspace.yaml、.nvmrc 一应俱全，右下角 Languages 写着 TypeScript 97.4%。一个标准的 pnpm + Node 的 TS monorepo，跟那个愚人节 PR 押的 Bun 不是一条路。
直接看官方 kimi-code 里 CLI 应用的依赖，前端和 Node 开发者会觉得每一个都眼熟：
go
"dependencies": {
"@earendil-works/pi-tui": "^0.74.0",
"commander": "^13.1.0",
"zod": "^4.3.6",
"chalk": "^5.4.1",
"cli-highlight": "^2.1.11",
"smol-toml": "^1.6.1",
"@mariozechner/clipboard": "^0.3.2",
"semver": "^7.7.4"
}对照 Python 版那一套，这就是一次很标准的同类替换：命令行解析从 Typer 换成 commander，数据校验从 Pydantic 换成 zod，配置文件用 smol-toml 读 TOML，终端高亮交给 cli-highlight 和 chalk。没有什么生僻库，全是当下 TS 项目的常规选型。
工程链路这边，几乎就是 2026 年 TS 工程的标准答案：
-
包管理 ：pnpm 10 的 monorepo，
apps/放 CLI，packages/放可复用模块。 -
构建 ：用
tsdown打包，TypeScript 直接上到了 6.0。 -
静态检查 ：
oxlint，而且开了 type-aware 模式，配合oxlint-tsgolint做类型相关的检查。 -
测试 ：
vitest，覆盖率走 v8。 -
版本与发布 ：
changesets管版本号和 changelog，simple-git-hooks+lint-staged卡提交，sherif、publint、arethetypeswrong做 monorepo 的依赖和打包体检。
换句话说，平时写 TS 库的人，把这套配置原样搬到自己项目里都不违和。一个大模型团队的旗舰命令行工具，骨架和我们平时发的 npm 包没有本质区别。
终端界面用的是 pi-tui，不是 React Ink
这是传错的重灾区，得专门说一句。
先放一张 kimi-code 跑起来的样子，欢迎面板、会话信息、对话区、底部状态栏，能看到模型是 kimi-code/kimi-for-coding，状态栏右下角还实时显示 context 占用，长会话里这块信息挺实用。
那个愚人节 PR 用的是 React Ink ，也就是用 React 那套 reconciler 来渲染终端 UI。但官方 kimi-code 用的是 **@earendil-works/pi-tui**，README 的致谢里专门感谢了 pi-tui 的作者。
pi-tui 来自 earendil-works 的 pi-mono 仓库，是一个专门给终端 Agent 做的 TUI 库。它和 React Ink 是两条不同的路：Ink 胜在能直接复用 React 的心智模型和生态，但渲染链路更重；pi-tui 更像是为「长时间、跑命令、刷大量输出」的 Agent 会话量身做的轻量方案。
社区里也有人点出，与其各家从零造 harness，不如直接复用 pi 这一套底座，把精力留给模型本身。Kimi 这次选 pi-tui，多少印证了这个方向。所以官方的终端层不是 Ink，看到「Kimi 基于 React Ink 重写」的说法，可以直接划掉了。
「无需 Node 环境」，却是用 Node 写的
kimi-code 的 README 里有句很拧巴的话：装的时候「不需要 Node.js」，但仓库的 engines 又写着 node >=24.15。这俩怎么同时成立？
答案藏在它的 native 构建脚本里：
go
"build": "tsdown",
"build:native:sea": "node scripts/native/build.mjs --profile=local",
"build:native:release": "node scripts/native/build.mjs --profile=release",
"package:native": "node scripts/native/package.mjs"它先用 tsdown 把整个 CLI 打成一个 bundle，再走 Node SEA（Single Executable Applications，单可执行文件）把运行时和代码一起塞进一个二进制。最终用户下载到的是一个独立可执行程序，机器上不用预装 Node、不用配 PATH，也不会和全局模块打架。开发者需要 Node 24 和 pnpm，是因为那是构建这台「打包机」的环境，跟用户拿到的成品是两码事。
这其实是 CLI 工具一直头疼的老问题：怎么让用户「装一个命令行软件」而不是「先装一个语言运行时」。Bun 的答案是 bun build --compile，Claude Code 走的就是这条路，把代码连同 Bun 运行时一起编译成原生二进制，跑起来彻底脱离 Node。Node 这边的答案，是这两年逐渐成熟的 SEA。Kimi 押了后者。
benchmark 其实没涨，重写图的是工程
很多人下意识觉得，重写一遍是为了让 Agent 更聪明。但那个 PR 自己附的 SWE-bench Verified 数据（都跑 kimi-k2.5 模型，500 道题）说的是另一回事：
| 指标 | kimi-cli（Python） | kimi-cli-ts（TypeScript） |
|---|---|---|
| Resolved | 325 / 496（65.5%） | 317 / 500（63.4%） |
两边基本打平，Python 版甚至还略高一点。换语言并没有让解题能力变强。这次重写真正图的，是分发体验、冷启动速度、终端交互这些工程层面的事，跟模型能力没关系。把这点说清楚，免得有人误以为「TS 写的 Agent 就更聪明」。
写在最后
把镜头拉远看，这两年顺手的终端编程 Agent，真正收敛的是语言：清一色用 TypeScript 写核心，配一套打磨过的 TUI。分叉的反而是运行时，Claude Code 走 Bun，Gemini CLI 还是 Node 加一个 JS bundle，Kimi 这次选了 Node + SEA。Bun 这条路 Claude Code 已经验证可行，Kimi 却挑了更稳的那条，考虑到 Bun 如今归了 Anthropic，这个选择就更耐人寻味。
对前端和 Node 开发者来说，这是个挺实在的信号。commander、zod、一个终端 UI 库、pnpm monorepo、SEA（或 bun --compile）单文件打包，这些你本来就会的东西，凑齐了就是一个 Agent harness 的雏形。挡在前面的从来不是语言，而是模型，以及工具调用、上下文管理、审批这些 harness 逻辑要怎么设计。
一年前聊「AI 基础设施」，默认是 Python 的主场。现在终端这一层，已经基本是 TypeScript 的地盘，至于底下跑 Node 还是 Bun，反倒成了各家自己的工程选择。那句愚人节的玩笑话，话糙，但它点破的趋势是真的。