开发者正在抛弃 Python，但 LLM 没有

如果你也在关注 agent 生态的技术趋势，可以先点个关注，我会持续写这类判断和真实使用观察。

过去一年，技术圈的风向很明确：前端全面 TypeScript，基础设施用 Rust 重写，AI 应用层也在往 TS 迁移。Python 看起来像是上一代 AI 热潮留下的遗产——训练模型的时候确实还离不开它，但到了应用层，谁还想写 Python？

但我最近注意到一件事。

我让 Claude 帮我写个脚本，它生成什么？Python。让它调个 API，Python。让 agent 做数据分析、处理文件、跑自动化任务，还是 Python。

我没指定语言。是 LLM 自己选的。

开发者在抛弃 Python，但 LLM 在拥抱它。这背后有一个被低估的事实：Python 不只是开发者喜欢的语言，它是 LLM 输出准确率最高的编程语言之一。

当写代码的主体从人变成 LLM，这件事的意义比大多数人想的要大。

为什么 LLM 天然选择 Python

先说训练数据。

GitHub 上公开的代码，Python 常年占比前三。LLM 训练的时候，见过最多的代码就是 Python。见得多，写得准，这是最朴素的道理。

再说语法。Python 的语法噪音少——没有大括号，没有分号，缩进就是结构。对人来说这是"优雅"，对 LLM 来说这是"不容易生成错误的 token"。大括号多了少了、分号漏了，这些在 C++ 和 Java 里是常见 bug，在 Python 里根本不存在。

然后是库生态。读文件、调 API、处理 JSON、分析数据——Python 每一项都有成熟的标准方案。LLM 不需要在十种写法里选一种，大部分情况下就一种主流写法，生成出来就能跑。

结果很直接：LLM 写 Python 的可执行率，明显高于 C++、Java、Rust。

这不是 Python 的营销话术。这是大模型代码生成 benchmark 里反复验证过的结论。

关键转变：谁在写代码

过去二十年，编程语言的设计方向是"对人友好"。

Python 的缩进语法、简洁表达、丰富的语法糖，都是为了让人写起来舒服、读起来清楚。

但现在情况变了。

Agent 的工作方式是：收到任务 → 生成代码 → 执行 → 看结果 → 迭代。在这个循环里，写代码的不是人，是 LLM。人只看结果。

Python 从"开发语言"变成了 agent 的"手脚"。Agent 通过生成和执行 Python 来操作世界——读写文件、调用服务、处理数据、完成任务。

这个转变意味着，Python 生态的优化方向需要调整。不是"人写起来更爽"，而是"LLM 生成得更准、执行得更快"。

Agent 时代的 Python 应该往哪走

有几个具体的方向已经在发生。

类型提示不是给人看的

Python 的 type hints 过去被很多人当作"可选的装饰"。但我观察到，在 agent 时代，类型提示是 LLM 理解函数接口的关键信号。

同理，docstring 的重要性也在上升。LLM 靠 docstring 理解一个库怎么用。写得清楚的 docstring，等于给 LLM 一份调用说明书。

API 设计也要变。命名一致、参数少、返回值结构清晰——这些原则过去是"好的代码规范"，现在是"LLM 能不能正确调用你的库"的决定因素。

执行效率成了硬指标

Agent 执行任务的时候，经常需要：创建一个临时环境、装几个包、跑一段脚本、拿到结果、销毁环境。这个循环可能一天发生几十次。

传统的 pip + virtualenv 太慢了。创建环境要十几秒，装包要几十秒，agent 等不起。

uv 的出现解决了这个问题。它把包管理和环境创建从分钟级压缩到秒级。对人来说这是"快了一点"，对 agent 来说这是"从不可用变成可用"。

沙箱也是刚需。LLM 生成的代码不能在宿主机上裸跑，agent 需要安全的执行环境。Pydantic 团队做的 Monty 就是冲着这个来的——用 Rust 写的 Python 解释器，冷启动 6 微秒，默认不能访问文件系统、网络和环境变量，除非宿主程序明确授权。

Monty 的思路和传统沙箱正好相反：不是从完整的 Python 运行时往下减，而是从零开始，需要什么能力就开放什么能力。这种设计天然适合 agent 场景——LLM 生成一段代码，扔进 Monty 跑，拿到结果，不用担心它把系统搞坏。

工具库的设计逻辑要变

我自己踩过一个坑：tqdm。

tqdm 是个好库，人跑脚本的时候看到进度条会安心。但 agent 不看进度条。对 agent 来说，tqdm 往 stderr 刷的那些 \r 和 ANSI 转义字符就是噪音，干扰它解析执行结果。

还有交互式确认。很多 CLI 工具喜欢问你"Are you sure? (y/n)"。人可以打个 y 回车，agent 直接卡死——它不知道该往 stdin 写什么，也不知道自己被卡住了。

但问题是，你不能因为 agent 不需要就把这些功能删了。tqdm 和交互式确认对人来说依然有用。

正确的做法可能是保持兼容：给 agent 一个安静模式，或者在检测到非 TTY 环境时自动关掉进度条和交互确认。返回结构化的结果（JSON），让错误信息机器可读。人用的时候还是原来那个库，agent 调的时候也不会翻车。

关键在于：LLM 训练数据里学过怎么调你的库。你改了接口，LLM 就写不准了。兼容性是 agent 友好的前提。

Python 的护城河变了

Python 在 agent 时代的护城河，不是"开发者喜欢"，而是"LLM 写得准"。

训练数据的优势、语法的低噪音、库生态的成熟度——这些过去是 Python 对人友好的结果，现在变成了 Python 对 LLM 友好的原因。

但这个优势不是永远的。如果 Python 生态不有意识地往 LLM 友好方向发展，其他语言迟早会追上来。

谁先把自己的库做成"LLM 调用友好"，谁就在 agent 生态里占住位置。

Python 的未来，是 LLM 的工具语言。

如果这篇文章帮你换了个角度看 Python 的定位，欢迎点个赞，也可以转给正在做 agent 开发的朋友。

留言区聊聊：你有没有什么让 LLM 把 Python 写得更准的小技巧？比如怎么让它正确调用一个它没见过的新库？