ThreeRT：为云端沙盒 coding agent 打造的轻量 3D 渲染基础设施

实际上，ThreeRT 最早就是设计用来改善 coding agent 在云端沙盒环境中游戏创作效果的 infra。

现在很多创作者做出的游戏极其惊艳，但它们基本都强依赖安装了 claude code、Blender、UE 等软件且带有强 GPU 的本地环境，硬件价格和环境配给复杂度都不菲。如果直接挪到 CF worker 级别的 serverless 环境中，效果会差很多。

这里最大问题有两个。首先，如果沙盒里没有 GPU，那么 agent 创作中的抓帧会回退到软渲染，给 shader 随便加点料就容易卡死，更不要说有些 agent 还喜欢批量抓帧了。我觉得这或许是 agent 写不好 WebGPU 的根源，因为传统的 RL 沙盒环境可能无法提供足够好的 framebuffer readback 反馈，改 shader 哪里写错一点直接黑屏就没意思了对吧。而 three.js 至少为简单场景封装调优过，更开箱即用友好一些不容易炸。

其次，如果直接暴力上 GPU 机器，那么为每位用户提供独占云端实例的成本会极高，且其中 UE 不仅体积庞大冷启动极慢，稳定性也相当差，同样是卡死大户，且还有潜在许可证问题。这些都让我认为基于传统图形引擎，无法实现 3D 内容创作的民主化。

所以，ThreeRT 最初是针对这些痛点设计的一个适合提供 serverless GPU 渲染服务的渲染器。我希望 3D 内容创作的 agent loop 跑在 CF worker 上，抓帧时直接 RPC 请求部署到类似 Modal 上的 ThreeRT 渲染服务即可。只不过在将优化这种架构的性能的过程中，我发现 Opus 已经超出预期地做到了实时全路径追踪（UE 的 Lumen 还是混合了光栅化和光追的架构，非常庞大而复杂），于是我们决定将这部分先抽离出来开源。

在 ThreeRT 架构路线中，业务逻辑几乎完全不需要考虑 WebGPU 的管线配置，只需要定义好场景，光照直接被渲染器解决，把这个事情交给我们在主干持续维护调优即可。

在这种技术路线设计下，相比现在 UE 编辑器 100GB 的体量，ThreeRT 的 macOS 客户端只有 30MB。当然了你也可以说人家一整个引擎和大编辑器来对比渲染器不公平是吧？我只想说蓝图都已经被 UE 官方淘汰了，我们以后真的还需要传统编辑器吗？适应 Fable 级生产力的新的编辑器形态应该是怎样的？一切才刚刚开始而已，也欢迎在 GitHub 上关注我们的进展！