公开两个月,幕后积累多年

大多数所谓"AI 原生"的引擎,不过是在编辑器里塞进一个聊天面板。RakuAI 把模型当作每一帧的控制输入——两个月过去,这个论点交付的是代码,不是幻灯片。

这个周六的计划是放慢下来,好好思考。整个周末只有三次提交,这是自从我开始写公开日志以来最低的一次。智能体被我故意调得更冷静一些;我的注意力放在架构上,而不是交付新代码上。代码库在这个周末结束时,大致回到了它开始时的状态,而这正是我这类工作该有的正确状态。

两个月前的今天,这个公开的运行时仓库还只是一份空白的 README。而引擎本身以及它背后的专利资产,则可以追溯到更早以前。值得写下来的周末,是那种作者能够停下来盘点的周末。所以这就是本文要做的事。

今天,这个引擎究竟是什么

如果要我用一段话向没有一路跟读的人描述 Raku,这段描述会是这样的:

一个用 C++ 编写、通过稳定的 C API 暴露出来的跨平台 AR 运行时,带有 Unity 和 Unreal 的 SDK 绑定。它主要面向 AR 眼镜,并运行在当下可获得的任何硬件上(目前正在为 Meta Quest 的透视模式上线,同时有桌面端和移动端的预览版本)。它从底层设计之初,就建立在”AI 是运行时层面的关切,而不是编辑器的功能”这一假设之上。支持亚毫米级锚定。在标准存在的地方,以 OpenXR 作为一致性目标。这个代码库由开发团队里的自主编码智能体构建,通过一个公开的 issue 队列推进工作。

在第一天,这段话还只是一句充满抱负的使命宣言。而现在,它是对仓库里实际内容的描述。

过去两个月里让我感到意外的事

三件事。

智能体驱动的工作流,扩展得比我预期的要好。 一开始我担心自主智能体会产出这样一种代码库:每个 PR 单独看都能用,合并多了却会糊成一团。这种糊成一团的情况并没有发生。两个月时的这个代码库,比我从人类团队手里接手过的、运作了两年的代码库还要连贯。原因在于我每个周末都在写的那套纪律(更小的队列、更早的评审、多供应商配对以保证评审的独立性、把文档当作输入)。这些纪律确实管用。

硬件转向的代价,比我担心的要小。 十月初把产品目标从 AR1+ 转到 AR2 Gen1,是一个我纠结了好几天的决定,因为看起来代价会很大。实际的代价只是几个 PR(一次彻底的重命名扫荡,一次文档梳理)。代价之所以小,是因为早期就建立起来的模块化架构。不需要知道设备类别边界的子系统,根本不需要改动。需要知道的那些,则通过它们定义良好的表面干净利落地做了改动。这就是提前把架构画出来带来的红利。

合作伙伴的对话,比我计划的更早发生了。 我原本以为整年剩下的时间会处于”先造引擎,再交付一个演示,然后才开始合作伙伴对话”的模式。而实际的顺序是”先造引擎,在推进过程中就展开合作伙伴对话,让这些对话影响接下来该造什么,然后交付符合这些对话需求的演示”。NTT QONOQ。Meta。接下来的几家我暂时还不点名。眼下这些对话比演示本身更犀利,这是个不错的处境。

架构在哪些地方已经稳定下来

一份简短的清单,列出那些我不再预期会重新考虑的架构决策:

• 运行时是 C++,通过稳定的 C API 暴露出来。其他语言的绑定叠在 C API 之上,而不是直接叠在 C++ 之上。
• SDK 从第一天起就是多绑定的。Unity 和 Unreal 是一等公民。Godot 在路线图上。Web 原生也在路线图上。C API 才是瓶颈,绑定不是。
• 子系统都是 DLL。每一个都有一个公共表面;任何子系统内部都不会伸手进入另一个子系统的内部。这些表面都是经过评审的 PR。
• AI 是运行时层面的关切,而不是编辑器的功能。存在于引擎里的 AI 工作,运行在每一帧的仿真步进上。存在于引擎里的云端 LLM 工作,在运行时接入语音管线。两者都不是创作工具里的一个面板。
• 在标准适用的地方,OpenXR 就是标准。特定厂商的代码放在特性开关和 provider 模式背后。采纳一个新的符合 OpenXR 一致性的设备目标,只是一层特定厂商的胶水代码,而不是运行时重写。
• 开发流程在设计上就是多供应商的。写某段代码的模型,不能是评审这段代码的模型。目前在某个角色上表现最好的实验室,就担任那个角色,直到有另一家实验室做得更好。

我预计仍然会重新考虑的地方:

• 设备端推理和云端 LLM 意图之间的确切分工。随着 TFLite 相关工作的成熟,以及云端 LLM 接口被真正的合作伙伴使用得更多,这条界线会变得更清晰。目前的划分是暂定的。
• 体验定义文件格式的形状。骨架已经搭好,模式(schema)还会演进。我预计在这个格式稳定之前,至少还会有一次主版本号的跃升。
• 多人 AR 的状态同步该放在哪里。我们今天有一个低延迟的增量通道。长期而言,正确答案是点对点网状结构、托管的权威服务器,还是某种混合方案,目前尚未定论。十二月将交付的双人演示会为这个决定提供依据。

通往十二月生产就绪的路

我一直在悄悄瞄准一个十二月的里程碑:引擎”生产就绪,可供合作伙伴在其之上构建认真的演示”。这不是一次公开发布。这是一个内部门槛——达到这个门槛,我才愿意邀请合作伙伴团队开始基于这个运行时构建,而不用先提醒他们半打尚未打磨的粗糙之处。

要跨过这道门槛,还需要发生以下这些事:

• 运行时的 AI 子系统(行为树、导航网格、群体仿真、感知系统、决策树)。目前在设计文档中已经搭出骨架;实现将在十二月和一月的第一个周末落地。
• Windows MSVC 构建的干净程度。自十月以来,我实际上还没有在 Visual Studio 2026 下真正构建过这个运行时。我很确定这会是一场硬仗。等我做的时候会写出来。
• 一个规范化的示例包,通过 Unity 和 Unreal 两种绑定,端到端地演示一个不平凡的 AR 体验,并接入语音管线和云端 LLM。
• 一条用于向现场设备分发模型更新的联邦同步路径。加密这部分需要达到生产级别,而不是占位级别。
• 运行时更新器。我们需要能够把一个新构建推送给合作伙伴的开发套件,并让它干净地安装上去。

这就是清单。六周时间来完成它。十二月的提交量会很高。

我希望构建者和合作伙伴从这篇文章里带走什么

如果你已经读了这份公开日志两个月,你就已经实时看到了这个引擎是如何拼装起来的。节奏很快;纪律是真实的;架构决策都有记录。这就是构建这个引擎所用的工程文化,也是你在它之上构建时会共事的那种工程文化。

如果你是一个正在考虑要不要展开一场认真对话的合作伙伴:眼下这些对话比演示更犀利,而这是故意的。比起先造一个演示,再事后想办法让它去适配你的需求,我更愿意先听听你的产品究竟需要什么,让这些需求来塑造接下来要造的东西。塑造十二月交付内容的窗口,会一直开放到十一月底。

如果你是一个在等待稳定性的开发者:稳定性是十二月的交付物。这个引擎今天仍处于足够活跃的演进之中,我还不建议在它之上构建认真的依赖代码。从今天算起两个月后,这个建议会不一样。

安静的周六。两个月了。下周末回去继续搭建。