OpenXR 是骨架,双链路无线电是神经

如果什么都自己造,你会晚一年交付,而且说的是一种别的任何东西都听不懂的语言。RakuAI 走的是另一条路:在 OpenXR 合适的地方站在它上面,把难啃的部分——比如一个能自我切换的双无线电外接链路——留给标准还没到达的地方自己去工程实现。

在为 AR 眼镜构建引擎时,一种诱惑是什么都自己造。造自己的姿态 API。造自己的图形绑定。造自己的输入模型。造自己的控制器抽象。这些决定中的每一个,都是四十小时的智能体工作量,外加另外四十小时的人工评审。累积起来就是一年的努力,以及一个生态系统里没有任何其他东西能听懂它语言的引擎。

我走的是另一条路。在存在一个适合这个用例的标准的地方,这个引擎就采纳这个标准。OpenXR 是头条例子。这个周末,运行时长出了它两个月来一直需要的 OpenXR 骨干。

这次在 OpenXR 上落地了什么

这个周末,大部分繁重的工作都落地了:

• 带会话和交换链管理的 OpenXR 图形 API 绑定
• 带设备丢失处理的 OpenXR 帧生命周期集成
• OpenXR 动作同步和视图定位操作
• 对 XR_FB_passthrough、XR_FB_foveation 和 XR_EXT_hand_tracking 的 OpenXR 扩展支持
• OpenXR 合成图层管理器和动作空间

如果你把这些 PR 标题连起来读,它们听起来像是一份供应商一致性检查清单——因为它们本来就是。重点在于,任何交付了符合 OpenXR 一致性的运行时的硬件合作伙伴的任何设备,现在都成了 Raku 的一个可行目标,因为引擎中与设备对话的那部分,说的正是设备运行时所说的那种协议。

这项工作的大部分由智能体完成。这个周末落地的这些 PR 异常干净,因为 OpenXR 是一个有良好规范的标准,有已发布的头文件和一套可运行的测试套件。智能体读头文件,读规范章节,写实现,跑一致性测试,而 PR 要么绿要么红,没什么歧义。这正是自主编码智能体最擅长的那类工作。

双模 RF / 光学链路管理器

这个周末另一块大工程是双模链路管理器。这是一个 Raku 特有的东西,而不是标准层面的东西。

场景是这样的:带外接计算设备的 AR 眼镜。这个外接设备有时是手机,有时是腰包,有时是台式机。眼镜和外接设备之间的链路今天是 Wi-Fi 7,而在某些设备目标上,明天可能会是自由空间光学链路。运行时不能假设只有一种链路技术,它必须能够切换。

这个周末落地的链路管理器就是处理这个的。运行时同时打开一条 RF 链路,以及(在支持的地方)一条光学链路。它监控每条链路上的延迟和吞吐量。它把流量转移到表现更好的那条链路上,并在某条链路劣化时回退到另一条。这次切换对上层应用来说是无感知的。

这是那种你真的没办法事后补建的子系统。如果你等到第二种链路技术出现之后才去构建这个抽象层,你会花三个月的时间去拆解第一种链路技术偷偷塞进上层每一层的假设。我们是先构建了这个抽象层。现在,无论硬件合作伙伴选择哪种链路技术,运行时都已经准备好了。

OpenXR 扩展及其不足之处

给正在读这篇文章的 OpenXR 从业者一点具体说明。我们这个周末新增支持的 XR_FB_passthrough 和 XR_FB_foveation 扩展,正是我们想要达到的注视点渲染和透视质量标准所需要的,而手部追踪扩展 XR_EXT_hand_tracking 也正是跨厂商手部追踪接口所需要的那个。

而这个扩展集里缺失的、我们正在为之构建专有代码的,是亚毫米级锚定(今年秋天早些时候提到的书法用例)、我们想要的那种时间尺度上的低延迟多人姿态同步,以及让模型层能够每一帧参与场景推理的 AI 运行时钩子。这些都是 OpenXR 尚未标准化的领域,我们的引擎目前正在交付自己的接口。我们的意图是,当 OpenXR 赶上来的时候(工作组里确实有一些正在进行的相关工作),我们就采纳这个标准,并弃用我们自己的实现。

这正是我希望这个引擎能够保持的模式。在标准存在的地方采纳标准。在标准不存在的地方自己构建。在标准赶上来的时候,做好再次采纳的准备。

遥测和存根完整性

这个周末落地了一件更安静的事:结构化的 JSON / OTLP 日志记录,集成了 OpenTelemetry。这是那种不会有自己专属公告的管线工作,但正是它让我们能够回答”延迟预算都花到哪里去了”这个问题,而不必每次都手动给代码打点。遥测管线现在已经接通到每一个子系统,Phase 1 产出的那些仪表盘都是真实的。

同样在这个周末:一个文档 PR 认真审视了代码库中的存根实现,把每一个都归类为”其实是一个有用的测试工具”或者”其实是一个漏洞”。有用的那些被重新命名并写好了文档。漏洞则被记录追踪起来。这项分类工作是智能体自己写并落地的。这是件小事,但也是那种如果长期被忽视,就会变成严重烂摊子的小事。

我希望构建者和合作伙伴从中得到什么

如果你是 OpenXR 工作组的成员,这个引擎正被构建成这个标准的一个良好公民。我们在合适的地方采纳扩展。当我们的实现发现一致性缺陷时,我们会提交一致性 bug 报告。在标准还没赶上来的地方,我们会公布我们自己构建的东西,而且比起维护一个分叉,我们更愿意去标准化。

如果你是一家硬件合作伙伴,你的设备符合 OpenXR 一致性,那么这个引擎这个周末比上个周末更接近于能运行在你的设备上了。剩下的工作是特定厂商的胶水代码。我们很乐意一起来做这部分工作。

如果你正在开发眼镜与外接设备之间下一代链路技术(Wi-Fi 7+、自由空间光学、毫米波,任何技术),这个链路管理器抽象层就是可以接入的那一层。上层的运行时不需要知道你是哪种无线电,下层的运行时会为你做好抽象。

整个周末九十八次提交。引擎长出了一副骨架和一根神经。经过漫长的两天,周日晚上合上笔记本电脑的感觉很好。