OpenAI 收购 Astral,uv/ruff/ty 何去何从

深度Simon Willison2026年3月19日4 分钟阅读
OpenAI 收购 Astral,uv/ruff/ty 何去何从
OpenAI 宣布收购 Python 工具链公司 Astral,后者开发的 uv、ruff、ty 已成为 Python 生态的关键基础设施。这笔交易背后,既有技术整合的考量,也暗含与 Anthropic 的竞争博弈。

今早的大新闻:Astral 宣布加入 OpenAI,OpenAI 也确认了收购 Astral。Astral 是 uv、ruff 和 ty 这三款 Python 生态关键开源项目的背后公司。我有些想法。

OpenAI 和 Astral 的官方说法

Astral 团队将并入 OpenAI 的 Codex 团队。

Charlie Marsh 在 Astral 的博客中写道:

开源是我们影响力的核心,也是我们一切工作的中心。根据我们的理念和 OpenAI 的公告,交易完成后,OpenAI 将继续支持我们的开源工具。我们将一如既往地与社区一起公开构建,为更广泛的 Python 生态系统服务。

加入 Codex 团队后,我们将继续构建开源工具,探索它们与 Codex 更无缝协作的方式,并扩大我们的视野,更广泛地思考软件开发的未来。

OpenAI 的公告则略有不同(重点是我加的):

作为我们开发者优先理念的一部分,交易完成后,OpenAI 计划支持 Astral 的开源产品。通过将 Astral 的工具和工程专长引入 OpenAI,我们将加速 Codex 的工作,并扩展 AI 在整个软件开发生命周期中的作用。

这消息有点令人困惑。Codex CLI 是一个 Rust 应用,而 Astral 拥有业内顶尖的 Rust 工程师——光是 BurntSushi(Rust regex、ripgrep、jiff 的作者)可能就值回收购价了!

所以,这到底是为了人才还是产品?我猜两者都有,但根据过去的经验,产品+人才的收购,后来可能变成只留人才。

uv 是关键

Astral 的项目中,影响最大的是 uv。如果你还不熟悉它,uv 是目前解决 Python 环境管理问题最令人信服的方案,这张经典的 XKCD 漫画最能说明问题:

xkcd comic showing a tangled, chaotic flowchart of Python environment paths and installations. Nodes include "PIP", "EASY_INSTALL", "$PYTHONPATH", "ANACONDA PYTHON", "ANOTHER PIP??", "HOMEBREW PYTHON (2.7)", "OS PYTHON", "HOMEBREW PYTHON (3.6)", "PYTHON.ORG BINARY (2.6)", and "(MISC FOLDERS OWNED BY ROOT)" connected by a mess of overlapping arrows. A stick figure with a "?" stands at the top left. Paths at the bottom include "/usr/local/Cellar", "/usr/local/opt", "/usr/local/lib/python3.6", "/usr/local/lib/python2.7", "/python/", "/newenv/", "$PATH", "????", and "/(A BUNCH OF PATHS WITH "FRAMEWORKS" IN THEM SOMEWHERE)/". Caption reads: "MY PYTHON ENVIRONMENT HAS BECOME SO DEGRADED THAT MY LAPTOP HAS BEEN DECLARED A SUPERFUND SITE."

python 切换到 uv run,大部分问题就消失了。过去两年我一直在用它,它已经成为我工作流中不可或缺的一部分。

不止我一个人这样。根据 PyPI Stats 的数据,上个月 uv 的下载量超过了 1.26 亿次!自 2024 年 2 月发布以来,短短两年,它已成为运行 Python 代码最流行的工具之一。

Ruff 和 ty

Astral 的另外两个重要项目是 ruff(一个 Python 代码检查器和格式化工具)和 ty(一个快速的 Python 类型检查器)。

这些工具提供了很好的开发者体验,但它们的“承重”程度不如 uv。

不过,它们与 Codex 这样的编码智能体工具很契合——让智能体访问快速的代码检查和类型检查工具,有助于提高其生成代码的质量。

我不太确定将它们直接集成到编码智能体内部,而不是告诉智能体何时运行它们,是否会有显著区别,也许只是我想象力不够。

pyx 怎么办?

自从 uv 开始流行,Python 社区就一直担心一家 VC 支持的公司掌握 Python 关键基础设施带来的战略风险。我在 2024 年 9 月详细写过关于这些讨论的文章。

当时的讨论集中在 Astral 的商业计划上,这个计划在 2025 年 8 月他们宣布 pyx(面向组织的私有 PyPI 风格包注册表)时开始成形。

我不太确定 pyx 在 OpenAI 内部是否合理,而且值得注意的是,Astral 和 OpenAI 的公告帖中都没有提到它。

竞争态势

这笔交易的一个有趣之处在于,它可能如何影响 Anthropic 和 OpenAI 之间的竞争。

两家公司在 2025 年大部分时间都专注于提升模型的编码能力,导致了 2025 年 11 月的拐点,那时编码智能体从“经常有用”变成了软件开发“几乎不可或缺”的工具。

Anthropic 的 Claude Code 和 OpenAI 的 Codex 之间的竞争非常激烈。那些每月 200 美元的订阅费加起来是每年数十亿美元的收入,对这些非常需要资金的公司来说至关重要。

Anthropic 在 2025 年 12 月收购了 Bun JavaScript 运行时,这笔收购在形式上与收购 Astral 有些相似。

Bun 已经是 Claude Code 的核心组件,那笔收购看起来主要是为了确保一个关键依赖项得到积极维护。此后,得益于 Bun 的 Jarred Sumner 的努力,Claude Code 的性能显著提升。

这笔交易的一个糟糕版本是,如果 OpenAI 开始利用其对 uv 的所有权,在与 Anthropic 的竞争中作为筹码。

Astral 低调的 A 轮和 B 轮融资

Astral 公告中有一个细节引起了我的注意,在感谢团队、投资者和社区的部分:

其次,感谢我们的投资者,特别是领投我们种子轮和 A 轮的 Accel 的 Casey Aylward,以及领投我们 B 轮的 Andreessen Horowitz 的 Jennifer Li。作为一名首次创业的技术型 solo 创始人,你们对我的信任远超我对自己的信心,我永远不会忘记这一点。

据我所知,A 轮和 B 轮融资此前都没有公开宣布过——我只找到关于 2023 年 4 月原始种子轮的报道。

这些投资者现在大概可以用他们在 Astral 的股份换取 OpenAI 的一部分。我很好奇他们对 Astral 出售的决定有多大影响力。

分叉是可行的退路吗?

Armin Ronacher 开发了 Rye,后来被 Astral 接管并 effectively 与 uv 合并。他在 2024 年 8 月写过关于 VC 支持的公司拥有关键开源基础设施所涉及的风险,并说了以下的话(重点是我加的):

然而,看过代码和 uv 的所作所为后,即使在最糟糕的未来,这也是一个非常容易分叉和维护的东西。我相信,即使 Astral 关闭或在许可方面做出极其可疑的事情,社区的情况也会比 uv 存在之前更好。

Astral 的 Douglas Creager 今天在 Hacker News 上强调了这一点:

我只能说,现在,我们承诺以与以前相同水平的努力、关怀和关注细节来维护我们的开源工具。这次收购不会改变这一点。没有人能保证几年后动机、激励和决策会如何变化。但这就是为什么我们通过宽松许可为工具注入了可选性。这使得最坏情况下的应对方案是“分叉并继续前进”,而不是“软件永远消失”。

我喜欢并信任 Astral 团队,我乐观地认为他们的项目在新家会得到良好维护。

OpenAI 在收购和维护开源项目方面还没有太多记录。不过,过去三个月他们进行了一系列收购,拿下了 Promptfoo 和 OpenClaw(算是吧,他们聘用了创始人 Peter Steinberger,并将 OpenClaw 剥离到一个基金会),还有闭源的 LaTeX 平台 Crixet(现为 Prism)。

如果 uv 和其他 Astral 项目真的出了问题,我们就能看到分叉退出策略到底有多可信。

本文编译自 Thoughts on OpenAI acquiring Astral and uv/ruff/ty,版权归原作者所有。

觉得有用?分享给更多人

获取每周 AI 工具精选

工具推荐、实战教程和生态洞察,每周更新。

相关文章

Simon Willison 正在重构 LLM Python 库的抽象层,以支持服务器端工具执行等新功能。他利用 Claude Code 分析了四大 LLM 提供商的客户端库,生成了用于测试的 curl 命令和 JSON 输出。这些调研材料已开源,旨在帮助设计更通用的 API 抽象。

深度Simon Willison·4月5日·1 分钟

智能体技能——包含程序性知识和可执行资源的结构化包,供智能体在推理时动态加载——已成为增强 LLM 智能体的可靠机制。然而,推理时技能增强存在根本性限制:检索噪声引入无关指导,注入的技能内容带来大量 token 开销,而模型从未真正习得它所遵循的知识。我们提出一个问题:技能是否可以被内化到模型参数中,使其在无需任何运行时技能检索的情况下实现零样本自主行为?我们提出 Skill0,一个专为技能内化设计的上下文强化学习框架。Skill0 引入了一种训练时课程,从提供完整技能上下文开始,逐步撤除。技能按类别离线分组,并与交互历史一起渲染为紧凑的视觉上下文,教授模型工具调用和多轮任务完成。动态课程机制…

深度·4月5日·17 分钟

评论