Cloudflare 正在全力确保 AI 编程智能体能够检查自己的工作成果，而不会耗尽可用的计算资源，并由此牵头开展了一项将微软 TypeScript 编译器移植到 Rust 的新工作。
但无论如何，请不要称其为"分叉"。
Cloudflare 工程总监 Christoph Nakazawa 在 X 平台上确认，该公司正在负责 tsrs 项目——这是 TypeScript 的一个 Rust 移植版本，据称速度最高可达 TypeScript 7.0 的八倍，内存占用则减少 70%。
微软自己的 TypeScript 编译器也从中受益，双方团队在保持两个实现同步的同时，共享了各自的优化成果。
"我们并没有在分叉 TypeScript——我们正在与 TypeScript 团队合作，因此 7.1 版本的速度也已经提升了约 2.5 倍，"Nakazawa 写道。
"移植而非分叉"这一表述贯穿了随之发布的博客文章，该文章由 Nakazawa 与 Cloudflare 工程师同事 Boshen Chen 和 Dimitri Mitropoulos 共同撰写，他们在文中不遗余力地说明，他们完全认为 TypeScript 应继续由微软主导。
"需要明确的是，我们并非在分叉 TypeScript。我们认为 TypeScript 团队应保持对该语言设计与方向的完全主导权。"
"需要明确的是，我们并非在分叉 TypeScript，"他们写道。"我们认为 TypeScript 团队应保持对该语言设计与方向的完全主导权。他们在引导 TypeScript 在 JavaScript 社区中普及应用的同时，一直保有长期愿景。我们不想改变这一点。"
为何选择 Rust，而微软已有 Go 版本？
TypeScript 由微软于 2012 年开发并发布，它为 JavaScript 扩展了一套类型系统，帮助开发者在应用运行之前就发现错误。然而，类型检查可能会消耗大量计算资源，尤其是在大型项目中，多个 AI 智能体可能同时在编写和验证代码。
微软在今年 7 月发布的 TypeScript 7.0 中已经解决了部分性能问题，用 Go 语言编写的编译器取代了原有的基于 JavaScript 的编译器，速度提升约十倍。
正如 The New Stack 此前报道的那样，微软曾考虑过用 Rust 进行重写，但最终认为用 Rust 重现 TypeScript 现有架构会在内存管理和兼容性方面带来重大复杂问题。
tsrs 所报告的性能提升与微软自身的 Go 实现相比颇具可比性。微软 TypeScript 首席产品经理 Daniel Rosenwasser 在 Hacker News 上一场关于该 Rust 移植版本的讨论中评论道，"很多速度提升并不仅仅取决于语言的选择，"他还补充说，"TS 7.1 变得更快更精简的部分原因……实际上来自于在 tsrs 中发现的优化方案。"
"TS 7.1 变得更快更精简的部分原因……实际上来自于在 tsrs 中发现的优化方案。"
另外，Rosenwasser 今天早些时候宣布了 TypeScript 7.1 测试版，详细介绍了其中大幅度的速度和内存优化。
对 Cloudflare 而言，Rust 的优势并不止于编译器性能，特别是它在 WebAssembly（Wasm）方面的适用性，这使得编译后的代码能够在浏览器及其他支持的环境中运行。Go 也可以编译为 Wasm，但必须携带其垃圾回收器。而 Rust 为开发者提供了更直接的内存控制能力，这使其在诸如 Cloudflare Workers 这类资源受限的环境中格外具有吸引力——在这些环境中，AI 智能体可以在隔离的沙箱内编写、检查和构建应用程序。
即便微软的 Go 编译器正变得越来越快，Nakazawa 仍坚持认为 Rust 具有持久性的优势，包括与更广泛的基于 Rust 的 JavaScript 工具生态系统（例如代码检查工具 Oxlint，它能利用 TypeScript 的类型信息来检测潜在问题）更紧密的集成。
"总体而言，TypeScript 的 Rust 移植版本更具可移植性，也更容易集成到各种环境中，"Nakazawa 告诉 The New Stack。
此举也契合了 Cloudflare 日益壮大的 JavaScript 生态系统布局。正如 The New Stack 上周报道的那样，该公司一直在组建一套广泛的 JavaScript 工具和专业能力体系，包括今年 6 月收购 VoidZero，以及最近发布的 Void——一个用于部署和管理 AI 构建应用的开源平台。
基于此，目前正是 Cloudflare 和 VoidZero 团队将 tsrs 作为 Oxc（VoidZero 的基于 Rust 的 JavaScript 工具链）的一部分进行开发，并计划将其集成到其他开发者工具中。
Owner 公司：tsrs 的起源故事
值得一提的是，tsrs 项目仅在上个月才在餐饮软件公司 Owner.com 启动，该公司 AI 开发者体验负责人 Max Schwenk 表示，他当时面对的是一个拥有 37,000 个文件的 TypeScript 后端代码库。他在周一发布的一篇博客文章中写道，微软的 Go 编译器在单线程检查时消耗了 19 GiB 内存，耗时 80 秒，这限制了能够并发工作的编程智能体数量。
由于多个智能体同时生成代码，资源需求使得每个智能体都难以独立检查自己的改动，这迫使 Owner.com 尝试使用基于云的开发环境以及其他折中方案。
"为了让编程智能体实现最大化的生产力，它需要能够以尽可能紧凑的循环来验证自己的工作成果，"Schwenk 写道。
在尝试改进 Go 编译器内存使用效率遇到瓶颈后，Schwenk 尝试了一种更为大胆的做法：使用 Anthropic 的 Claude Opus 5.5 用 Rust 重新构建编译器。他负责指导这项实验并评估结果，而将具体实现工作完全交给 AI 智能体完成。
"我没有写一行代码，"Schwenk 写道。"不是'几乎没写'，而是零行代码。"
"我没有写一行代码。不是'几乎没写'，而是零行代码。"
而成果来得相当迅速。Schwenk 表示他并行部署了超过 20 个 AI 子智能体，第二天早上醒来时就看到了一个可正常运行的类型检查器。进一步的优化将 Owner.com 在持续集成环境中的类型检查时间缩短至约 7 秒，而在十余个公开项目中，Schwenk 报告称 tsrs 的运行速度是微软最新 Go 编译器每夜构建版本的 2.5 到 5 倍，同时内存占用仅为其三分之一左右。
Rust 智能体式重写
事实上，tsrs 项目只是 AI 智能体被用于大规模 Rust 迁移工作的最新案例。正如 The New Stack 上个月报道的那样，GitHub 使用自家的 Copilot 智能体将其编程智能体运行时用 Rust 重写，而 Anthropic 此前也曾利用 Claude 智能体协助将其 Bun JavaScript 运行时从 Zig 迁移到 Rust。
此外，Meta 同样借助 AI 协助将 React 编译器移植到 Rust，而在 9 月，OpenAI 透露有两名工程师利用 Codex 和 GPT-5.5，用 Rust 重建了其 Habitat 存储服务。
但这类快速的、由 AI 辅助完成的重写也引发了一些问题：开发者该如何验证最终生成的软件是否按预期运行？对于一个 TypeScript 编译器来说，这意味着要确保它能捕捉到与微软实现版本相同的错误。Schwenk 表示，该项目使用了 TypeScript 的一致性测试，在真实项目中故意引入错误，并运行 Miri（一款用于检测 Rust 内存安全问题的工具）。这些检查已经发现了一个仅在优化构建版本中才会出现的内存漏洞。
"一个发现错误更少的更快编译器，不过是一个拥有出色营销包装的坏编译器，"Schwenk 写道。
对 Cloudflare 而言，确保这些大部分由 AI 生成代码的可靠性，仍是一项重大的工程任务。Nakazawa 表示，团队正投入大量时间审查该实现，并对照微软庞大的测试套件进行测试，同时在包括 VS Code 等大型开源项目中进行运行验证。
然而，TypeScript 大量使用了循环类型（即类型定义可以相互引用）的特性，这在应用 Rust 常规的内存安全保护机制时带来了额外的复杂性。Nakazawa 承认，团队在这一领域还有更多工作要做，才能让 tsrs 达到可以稳定发布的程度。
"这是 tsrs 正在积极改进的一个领域，我们将在稳定版发布之前解决这个问题，"他补充道。
除了验证代码本身之外，Cloudflare 还面临着让 tsrs 持续与微软官方编译器保持兼容的任务。该公司计划采用其已在 Vinext 项目中使用的 AI 辅助方法，让 Vinext 与 Next.js 保持同步——由智能体监控上游变更、检查差异并提出修复方案。目前 tsrs 中仍存在一些差异，包括诊断信息显示的顺序问题。
"微软的 TypeScript 团队仍是该语言的权威主导方。"
但当两个实现版本出现分歧时，最终该由谁来决定？根据 Cloudflare 高级工程经理 Boshen Chen 的说法，预期是 tsrs 必须遵循微软的实现版本。AI 智能体可以帮助识别不一致之处并提出修正建议，但维护者仍需对具体的工程工作负责。
"如果 tsrs 的行为与微软编译器不同，那么最初的假设应当是 tsrs 存在一个需要调查并修复的兼容性缺口，"Chen 告诉 The New Stack。"微软的 TypeScript 团队仍是该语言的权威主导方。"
