Theo 如何用 AI 智能体将 TypeScript 移植到 Rust

我宣布推出 TS Rust，也叫 tsc-rs：这是由智能体构建的 TypeScript 编译器、检查器和语言服务器的 Rust 移植版。我花了几个月做实验。早期 Codex 尝试消耗了我估算价值 40 万美元的 token，却没有完成；后来的 Opus 5.5 工作在约两周内取得了更大进展。我本人没有逐行阅读这些代码。

我选择这个项目作为实验场，是因为它看起来几乎不可能。早期使用 OpenAI 模型的尝试达到了约 84% 的兼容性，但剩余的边缘情况越来越难。完成的项目已作为 npm 包提供，不过我对兼容性和速度的判断应结合实际测试范围理解。

在我的对比中，它在选定的工作负载上比 Microsoft 基于 Go 的 TypeScript 7 快约一倍，也明显快于较旧的 TypeScript 6。Bun 也推出了 Bun check，在许多情况下速度更快。我感兴趣的不只是速度：我想探索能在 JavaScript isolate 中运行的开发环境。

TypeScript 在 JavaScript 之上增加了类型系统。编译器可以把 TypeScript 源码变成浏览器和其他运行时能理解的 JavaScript，但移除类型标注和检查程序的类型是否一致是两项不同的工作。

移除 TypeScript 语法相对简单。esbuild 等工具通过原生程序处理转译、打包等工作，加快了开发循环。但快速转译本身并不能告诉你类型是否正确。

类型检查困难得多。我记得在 Twitch 时，开发服务器启动要几分钟，修改后还要等待几十秒才能看到效果。把提供代码的流程与类型检查流程分开，帮助我们大幅缩短了反馈时间。

TypeScript 的类型系统非常灵活，可以表达 JavaScript 许多不同寻常的行为；甚至有人在类型系统中实现了 Doom。在另一种语言中忠实编码这些语义很难，因为移植版必须重现 JavaScript 程序行为的众多细节。

尽管如此，Microsoft 还是为 TypeScript 原生重写选择了 Go。我虽然经常批评 Go，但认为它适合这项工作：goroutine 支持并发，语法有助于团队对照实现，而垃圾回收减少了大型移植过程中需要手动处理的内存管理。

垃圾回收可能带来暂停，影响对延迟敏感的请求，即使语言本身运行很快也是如此。对于执行长批处理的编译器，我认为偶发回收的开销可能不如对每个响应都要求严格时限的服务那样关键。实际结果仍取决于工作负载和实现。

智能体并没有从零开始做一个符合 Rust 习惯的重新设计。它以 Microsoft 的 Go 移植版为基础，做了非常忠实的翻译，甚至用 Rust 重新实现了部分 Go 标准库和运行时。直到有人提醒，我才注意到它这样做到了什么程度。

Go 实现是关键的中间步骤：Microsoft 团队已经手工把 TypeScript 的行为移植到 Go。最初的 Rust 结果比 Go 慢两到三倍，因此我又给智能体设定了至少快一倍的目标，让它们继续迭代。

标题中的成本需要背景。我估算 Opus 工作量按完整 API 价格约值 2.4 万美元，并不是 API 实际收取了 2.4 万美元。我的日志显示，六个订阅账户合计用了相当于单个账户每周额度的约 925%～983%；考虑一次免费重置，我估算约相当于 500 美元的订阅用量。这些是我的估算，并非所有用户都能复现的价格。

早期的 40 万美元指未成功实验的 token 价值，不应与后来的订阅用量估算混为一谈。这也不意味着 Microsoft 的移植工作白费了：我不认为没有 Go 版本作为起点，智能体能同样有效地完成这次 Rust 移植。

我把结果描述为接近目标 TS Go 版本的直接替代品。我和智能体检查六个已报告的问题时，认为其中一个属于 Rust 移植版，另外五个在目标版本中已经存在。这是令人鼓舞的证据，但少数 issue 报告不能证明普遍兼容。

在 T3 Code 上，我测到它比 TS Go 快约一倍，在部分检查中相对 TypeScript 6 的提升更大。这些是针对具体项目的测量，并不保证每个代码仓库都能获得相同倍数。

Effect 是一个需要额外诊断的 TypeScript 库。我把这些检查内置到了 TS Rust 中。在 T3 Code 图表里，包含 Effect 的完整检查：tsc-rs 用时 11.13 秒，TypeScript 7 加 Effect 集成用时 21.07 秒，Bun check 加单独的 Effect 检查用时 37.60 秒。图中的 TypeScript 6 插件使用不同的规则集。

在同一张图中，不包含 Effect 检查时 Bun check 更快：4.07 秒，而 tsc-rs 为 7.25 秒。我还尝试了 tRPC、Sentry、Excalidraw 和 Effect 等项目。我看到 Bun 在某些项目中报告了目标检查器没有报告的错误，同时也承认 Bun 的速度很快。

对许多用户来说，我仍会推荐 Bun check，因为我更有信心它能得到长期维护。我的移植版追求忠实兼容以及我需要的特定功能。一张基准图和少量测试仓库都不能证明任何工具在所有代码库上的表现。

我开始这个项目主要不是为了赢得速度竞赛。一个原因带点玩心：我想用看似不可能的任务测试模型能力。更重要的原因是 WebAssembly，以及在不提供传统操作系统的环境里运行 TypeScript 开发循环的可能性。

JavaScript 实现已经能在支持它的 JavaScript 运行时中运行。Go 程序也能面向 WebAssembly，但其运行时和垃圾回收器会影响包大小及行为。对我来说，Rust 的吸引力在于能够生成适合 isolate 工作流的紧凑 WASM 构建。

我还预计，在固定的测量能力水平上，推理价格会下降。我展示的 Artificial Analysis 图表比较每项智能指数任务的成本；我引用的数字是相近指数门槛下 Opus 5 为 5.86 美元、GPT-6.1 Sol 为 0.32 美元。这些基准价格只是某个时点的快照，不保证适用于所有任务或供应商。

推理只是其中一项费用。编写软件的智能体还需要一个地方运行代码、访问文件并测试修改。云端编程会话即使在等待下一次模型响应时，也可能需要虚拟机和内存；因此随着推理变便宜，执行基础设施可能占据更大的成本比例。

我以云端编程环境为例，但对于提到的服务究竟分配多少内存，我并不确定。一般性的取舍与准确数字是两回事：为多个并发会话保留隔离机器会消耗资源，而免费或打包提供的使用额度未必永远免费。

智能体习惯于使用真正的 shell、文件系统、搜索工具、Git 和原生进程。这些能力让现有开发流程很方便，但提供它们所需的隔离和计算资源也有成本。我希望为不需要整台机器的场景找到更便宜的执行层。

Cloudflare Workers 展示了一种替代方案：代码运行在 V8 isolate 中，而不是为每个工作负载提供传统的完整虚拟机。isolate 可以很轻量，但其能力和安全边界取决于宿主环境。尤其是，普通原生文件系统和任意原生进程不会自动在 isolate 中可用。

这造成了一个看似矛盾的情况：isolate 很适合托管 JavaScript，而编程智能体期待开发机器上的工具和文件。问题是，能否在隔离运行时里实现足够多的开发环境，以支持有用的工作。

just-bash 库在 JavaScript 中提供模拟 shell 和虚拟文件系统。它可以让智能体使用熟悉的命令，而不必暴露普通的宿主文件系统。不过，要构建应用，环境还需要编译和检查代码的工具；这正是支持 WASM 的 TypeScript 移植版变得有意思的地方。

在我的演示中，GPT-6.1 Sol 构建了一个应用，而智能体执行环境、虚拟文件系统和 TypeScript 工具运行在基于 V8 的环境中。演示实际运行在服务器上的 Node 里，我认为它也可以适配浏览器。模型推理本身在外部进行，不包含在我所说的本地计算中。

我报告其中一次运行使用的内存不到 216 MB，CPU 峰值约为 4%；后面的截图则显示了不同的内存读数。这些是我的演示观察值，不是普遍的资源保证。在我的对比中，包含 esbuild 的另一个版本使用了更多内存。

我关心的特点是，这个演示的工作文件系统存在内存中：我认为即使把宿主文件系统设为只读，它仍会运行。这并不等于证明它能不加修改地运行在所有 isolate 宿主上，或者支持所有原生开发工具。

为了解释潜在的节省，我画出了从硬件、操作系统到应用程序的层次，并比较机器级隔离与 V8 isolate。那张图是简化的理解模型：容器与虚拟机的实现和隔离属性不同，不能把它们当作同一种东西。

多个 isolate 可以共享一个运行时，同时保持工作负载之间的边界。与为每个小任务配置完整机器相比，这可能降低开销，但具体成本和安全保障取决于平台。浏览器标签页和数据库容器只是用来说明的例子，并不是等价的工作负载。

受限的 JavaScript 环境不能直接执行任意原生工具，也不能直接访问宿主文件系统。模拟 shell 提供部分接口，Rust 编译为 WASM 的编译器补上另一部分。我认为它最终可以运行在 Cloudflare Worker 中；视频展示的是 Node 托管演示，而不是已经完成的 Worker 部署。

经济性还取决于调度。智能体经常等待推理或网络响应，事件驱动平台可以在等待期间安排其他工作。实际计费取决于供应商规则、内存、CPU 和其他资源；等待并不普遍意味着零成本。

TS Rust 是我希望在 isolate 内实现端到端 TypeScript 开发体验所缺少的组件之一。我对它与 Lakebed 可能的联系很感兴趣，但现在不会公布细节。

移植背后的提示词并没有环境配置那么神奇。我让智能体阅读项目指南和问责记录，改进兼容性和性能，并让并行工作者独立运作。当流程不断过早停止时，我给出了更明确的目标：速度至少达到 Go 构建的两倍。

资源管理成了工作的一部分。运行会崩溃或耗尽容量，因此我调整环境，并让智能体使用更多机器。这不是写一个提示词后就无人值守地等结果；我需要观察反复出现的故障，并改变智能体的工作条件。

我的角色更像管理者：找出瓶颈，给团队提供所需资源，并避免并行工作相互干扰。环境和协调方式改善后，工作推进得更快。我的体会是，任务编排和反馈比某句聪明的提示词更重要。

自从看到 StackBlitz 这样的浏览器开发环境以来，我一直想要一个完全在 V8 中运行的端到端开发体验。以前，这些想法大多只是思想实验，或者需要找到有时间的人来实现。现在，智能体让我能更直接地尝试并观察结果。

我已经让智能体调查演示是否真的能在 Cloudflare 上运行，但录制视频时这仍有待测试。我对这些工具能尝试的事情感到兴奋，不过在大家广泛依赖这个项目之前，它仍需要独立评估和维护。

我为这个实验感到自豪，并不是因为我认为所有人都应该立刻采用这个编译器，而是因为它让我探索了一个过去似乎遥不可及的想法。最有意思的结果是能够检验大胆的想法，同时从局限和成功中学习。