Kimi 弃 Python 投 TS,Agent 语言之争大幕升起

各位 AI 环球笔记的读者朋友们大家好。

如果你做 AI Agent ，最近大概率刷到了两条推文——MaxForAI 说"SB 才在 Agent 里用 Python"， ZinkLu 说"SB 才在 Agent 里用 TypeScript"。同一天，同一个话题，两派创始人隔着屏幕互怼，各引一套完整论证。

但这还不是最狠的。

真正让我盯着屏幕来回看了三遍的，是月之暗面（ Kimi ）团队 4 月 1 日在 GitHub 上开的那个 PR 。

标题就一句话：

"kimicli 用 python 是彻底的失败 立刻重构为 ts"

298 个文件， 61519 行新增，只删了 2 行——不是"改代码"，是整碗端了重做。从 Python 到 Bun + TypeScript + React Ink ， 166 个 TS 源文件， 3.8 万行新代码，一气呵成。一个月后， 5 月 22 日， Kimi 为此专门建了一个新仓库叫 kimi-code ， TypeScript 占比 97.8%。

不是愚人节玩笑。是认真的。

一张 PR 截图，两个仓库

先还原一下发生了什么。

今年 4 月 1 日，月之暗面工程师 @Yuandiaodiaodiao 提交了一个 Pull Request ，目标是把 kimi-cli （一个终端 AI 编码 agent ）从 Python 迁移到 TypeScript 。

搁一般团队，这种迁移通常是渐进式的：保留 Python 核心，新模块用 TS 写，花半年慢慢过渡。 Kimi 不。他们直接开了一个平行的完整重写——旧代码不动，新代码从零写起，然后在 SWE-bench 上做了一次面对面 PK 。

结果：

能力几乎打平。但 TS 版零 infra 错误。五个在 Python 版运行中悄无声息崩掉的单元， TS 版跑完了。对于要长时间运转的 Agent 而言，这组对比本身就说明了很多问题。

有意思的是这个 PR 最终没有被合并。 4 月 9 日之后它就停在那里——open 状态， mergeable 显示"unstable"。到了 5 月 22 日，月之暗面直接在独立仓库下建了 kimi-code ， TypeScript 97.8%。原仓库 kimi-cli （ Python 78.1%）继续保留， 8.8k 星，仍在发布新版本。

两条线并行着。像一场还没结束的接力赛。

Python vs TS ，五轮对决

真正让这个事件出圈的，不是 Kimi 一家公司的迁移决定，而是同一天在 X 上引爆的一场大辩论。

TS 派（ MaxForAI ， 965 赞， 24.9 万浏览） 和 Python 派（ ZinkLu ， 169 赞， 10.7 万浏览），各自采访了"一个非常牛逼的 Agent 团队"，得出了完全相反的结论。

逐条拆开看，这场对决的精彩程度远超预期。

第一轮： Agent 到底在哪里跑？

TS 派说： Agent 最终在产品里。不管你做的是 Chat 界面、 IDE 扩展还是 Slack Bot ， TS 天然离前端近。前 TS 后 TS ， tool schema 中间共用一套类型，不用担心字段名大小写错了 Agent 直接死给你看。

Python 派说： Agent 最终在后端。模型服务、数据管道、向量检索、离线批处理， Python 才是主子。你用 TS 的话，模型 Py 、数据处理 Py 、后端 Node 、前端 JS——一份 schema 手写四遍。

嗯——两边说的都对。问题在于你做的 Agent 是什么类型的。

第二轮：异步重要还是稳定重要？

TS 派强调 Agent 不是一次请求一次应答那么简单。边想边输出、边调工具、边等用户确认、边处理取消和重试——TS/Node 在事件驱动和 stream 场景下天生就顺。

Python 派则反问： Agent 产品真正容易炸的地方是"异步"吗？不，是逻辑错、数据转换错、模型输出结构变了、环境依赖炸了。 Python 在稳定性和回溯力上更可靠。 pytest 、 tenacity 、 multiprocessing ，都是久经考验的东西。

第三轮：类型系统，到底要紧不要紧？

TS 派的观点很直接： Agent 系统里大量 JSON 在飞来飞去——tool input/output 、 agent state 、 message format——TS 可以把这些东西提前卡住，编译期就能发现错误。

Python 派认为恰恰相反：动态类型才是保险。你有结构化日志、序列化和各种异常处理兜底，静态类型反而碍手碍脚。当模型输出结构变了， TS 也防不住——因为变的是 LLM 的 JSON 格式，不是代码里的类型定义。

第四轮： runtime 生态的争夺

TS 派说 Agent runtime 要接的东西太多——网页、后台、 Electron 、浏览器插件、 VS Code 扩展、 serverless——找不出第二个语言像 TS 一样在这些场景里生态统一。

Python 派说 Agent runtime 要接的东西更多——数据管道、 AI 推理、 iOS/Android SDK 、硬件设备、边缘盒、 Jupyter 、 Gradio——Python 才是真正的通用系统语言，特别是在 AI 基础设施层面。

第五轮： AI 应用到底是什么工程？

这是最核心的一轮。没有对错，只有选择。

TS 派说： AI 应用早不是模型问题了。 LLM API 、 tool calling 、 vector store 、 browser automation 、 workflow 、 UI 、 billing 、 auth——这是产品工程。互联网产品的主语长期是 JS/TS 。

Python 派说：当 AI 应用深入数据层，你真以为这些东西和模型没关系？训练数据构建、检索增强生成策略、评估体系——这是数据工程，主语长期是 Python 。

两边的 Founder 最后其实走到了一样的结论上——分层的思路：哪层离模型近就用 Python ，哪层离产品近就用 TS 。只是他们各自认为哪一层是核心层，完全相反。

表面是语言之争，背后是路线之变

Kimi 的案例放在这个背景下看，就有意思了。

Claude Code （ Anthropic ）从第一天就是 TypeScript 写的。在它成为 AI 编程 agent 领域事实标杆之后，后来者面对一个现实问题：你要和它对标，要么在架构层面跟着它走，要么在同样的话题上用完全不同的技术栈做一遍。

Kimi 选择了前者。

这不是一个"Python 不行"的故事，是一个产品路线决定了技术栈的故事。 kimi-code 全面对标 Claude Code 的架构设计——Plannig Mode 、 Emacs 快捷键、 React Ink 的 TUI 、甚至自定义 Hooks 的生命周期设计——全盘接受之后，技术栈的转换就成了必然结果。

说得直白点：如果 Claude Code 当初是用 Python 写的，今天 Kimi 可能也会跟着用 Python 。

这无关语言优劣。这是生态位的锁定效应。

做 Agent 的到底该怎么选？

聊点实用的。 Kimi 这个案例不是让你学它，是让你想清楚自己的生态位。

几个参考框架：

选 TS 的场景：你在做面向终端用户的 Agent 产品。有界面、有交互、有插件、有多人协作。你的目标是产品体验，不是模型能力本身。

选 Python 的场景：你在做面向数据管线的 Agent 框架。检索增强生成是核心、 Agent 编排是核心、模型微调是核心。你的护城河在数据闭环，不在交互体验。

全都要的场景：就像两位 Founder 最后说的一样——两层架构。 TS 做产品层+Agent 编排， Python 做模型层+数据层。但不是所有团队都有余力维持两条线的工程协同。

——不对，这个答案其实也是说给中小团队听的。大厂可以用两条线，独立开发者最好做出选择。因为没有哪个周末项目能同时维护好 TS 和 Python 两个栈的 CI ，凌晨两点出了 bug 你还得想起来两边的测试用例分别怎么写。

回到 Kimi 。它的 PR 里写的不是"Python 不行"，是"kimicli 用 python 是彻底的失败"。意思是：在这个产品、这个团队、这个时间点上， Python 选错了。不是你们选错了——是我们选错了。

这句话的诚实，比那条 PR 本身更值钱。

Kimi 从 Python 叛逃到 TS ，这事本身就说明了一点： Agent 开发还没有"标准答案"。连月之暗面这样的团队，也是试了才知道。你正在纠结的，恰好是这个行业没有定论的地方——这本身就有意思，对吧？

AI 环球笔记，专注全球 AI 行业深度观察。