生来就能听 ChatGPT、Claude 和 Gemini 的指挥

"这个产品只跑在某一家供应商的模型上"的时代很短暂。RakuAI 被构建成让任何模型——ChatGPT、Claude、Gemini,或是你的模型——都能实时驱动一个 AR 体验。带上最好的模型来,运行时已经准备好了。

如今大多数与云端 LLM 集成的游戏引擎,做法都是你能想到的那种。一个模型被塞进编辑器里,变成一个聊天面板。你在聊天面板里打字。面板写出一些内容或一些代码。运行时对这一切发生过完全不知情,只是稍后运行那份生成出来的产物。

Raku 做的不是这个。Raku 被构建成能把云端 LLM 当作一个运行时层面的关切来接受指挥,而不是一种创作上的便利。这个周末的工作,把这一点明确了下来。

这次落地了什么

这个周末,运行时里一共有一百一十八次提交。头条内容:

• 一个 XRAssistantService,把云端 LLM 的响应作为一等运行时功能接入语音管线
• 带多档性能优化的眼动追踪注视点渲染
• 一个 OpenXR XR_EXT_eye_gaze_interaction provider
• 面向 XR 运行时的手部追踪和手势识别
• 带 71 个关节骨架的全身追踪
• 眼动追踪基础设施中的注视点检测和停留计时器
• 高分辨率透视、深度感知和光照估计
• 一条带宿主服务器和延迟监控的 Wi-Fi 7 渲染卸载管线
• 一条用于实时多人 AR 姿态和状态同步的低延迟增量通道
• 面向 Android XR 的亚毫米级锚点服务
• 面向没有 Android XR 技术栈的 Android 设备的 ARCore 传感器桥接
• 一个多层 HUD 合成器和叠加层 API
• 用于场景理解的 AR Surface Demo 和 Room Visualizer 示例

其中有几项是值得单独说说的头条内容。Wi-Fi 7 渲染卸载管线是一项。XRAssistantService 是另一项。两者都是形状上适合合作的工程。

XRAssistantService 究竟是为了什么

XRAssistantService 是我们迄今为止交付过的、最干净的一块”合作伙伴诱饵”工程。它的形状是这样的:

这个运行时有一条语音管线。用户说话。语音转文本在设备本地以低延迟运行。文本流入助手服务。助手服务把文本交给一个云端 LLM。云端 LLM 流式返回代表意图的 token:根据用户所说的内容,这个 AR 体验接下来该做什么。运行时解析这条流,把它转化为飞行中的运行时动作。响应的文本转语音也是流式的。

我想让构建者和实验室注意到的一点是,LLM 并不是每个用户回合只被调用一次。语音管线可以在一个回合中持续向模型流式发送 token(在有正确后端支持的前提下),模型也可以持续产出意图,让运行时不断地据此行动。这才是”把云端 LLM 当作运行时层面的关切来接受指挥”真正的含义。这不是把一个聊天机器人贴进 AR 体验里。而是运行时把模型的意图流,当作与用户注视同等优先级的一种控制输入。

这个接口在设计上是模型无关的。ChatGPT 能驱动它。Claude 能驱动它。Gemini 能驱动它。一个小型的设备端模型也能驱动它。任何能产出符合 assistant-service 协议的意图 token 流的东西,都能驱动它。我们这个周末构建的这块东西,是任何此类模型与运行时其余部分之间的集成层。

如果你在其中某一家实验室,并且正在读这篇文章:这正是我们想和你聊的那种集成。我们不想要一种特殊的合作方式,让你的模型成为这个引擎唯一能对话的模型。我们想要你的模型成为这个引擎能对话的最好的模型,因为这个集成是开放的,而你的模型产出的体验会比其他任何模型产出的体验都更好。

Wi-Fi 7 渲染卸载管线

这是另一块形状上适合合作的工程。AR 眼镜有一个热包络。这个热包络很小。这个热包络内的计算包络,比某些体验想要渲染的内容要小。传统的答案是在体验上做妥协。Wi-Fi 7 的答案是把部分帧渲染放到一个通过有线连接的计算盒子上(一台手机、一个腰包设备、同一个房间里的一台台式机),然后把结果流式传输过来。

这个周末,这条卸载渲染管线端到端地落地了。宿主服务器可以运行在任何地方。眼镜上的运行时通过 Wi-Fi 7 与宿主对话。帧延迟受到监控,当链路出现波动时(它一定会),运行时可以优雅地降级到本地渲染。

这对合作伙伴为什么重要:这意味着一个硬件合作伙伴不必把一块桌面级 GPU 塞进眼镜里,就能交付一份桌面级的体验。计算可以放在计算最便宜的地方。真正重要的是那条链路。我们正围绕这条链路来构建这个运行时。

OpenXR 的脚手架

这个周末的一大批提交,都是为了 OpenXR 一致性服务的。XR_EXT_eye_gaze_interaction。手部追踪。面向 ARKit 和 ARCore 的 provider 模式。OpenXR 在这个代码库里之所以重要,是因为它是我们希望这个引擎能够跨硬件合作伙伴移植的那一层。如果一个硬件合作伙伴交付了一个符合 OpenXR 一致性的运行时,这个引擎就能交付在它上面。我们这个月构建的这些接口,刻意站在标准这一边,而不是特定厂商这一边,因为这才是这个引擎保持中立的方式。

诚实地说说还没做完的部分

这个周末有几样东西是以 WIP(进行中)状态落地的。手部追踪的那个 PR 具体来说接线还不完整。有一个 PoseStabilizer 的链接错误,我们正在后续修复。眼动追踪已经有了注视点检测,但与应用层的停留计时器集成还没完成。全身追踪已经进去了,但手势识别部分还需要更多样本。

我想把这一点说清楚,因为智能体驱动开发工作的模式就是,很多 WIP 会在同一周落地,而这些 WIP 会在 PR 标题里被明确标注出来。如果你读这个周末的提交日志,在几个地方看到”[WIP]”,那是故意的。完整的交付物会在接下来两周内陆续到位。

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

如果你是一家正在构建下一个主力模型的 AI 实验室,并且你在意一个把你的模型输出当作仿真步进上的控制输入来对待的 AR 运行时,来找我聊聊。XRAssistantService 集成层将在 2025 年 11 月随这个引擎一起交付,并会在年底前成为一个稳定的可接入接口。

如果你是一家硬件合作伙伴,正在构建搭载 Wi-Fi 7 和外部计算方案的 AR 眼镜,这条卸载渲染管线正是为你的硬件量身定做的负载。这个运行时已经为此准备好了。

如果你是一名开发者,正在思考这个引擎将让你构建出什么样的体验,答案已经开始在提交日志里显现出来。能在用户说到一半时就做出响应的语音驱动 AR 体验是可以实现的。带亚毫米级锚定的实时多人 AR 是可以实现的。无论哪种体验需要什么样的算力,都可以放在眼镜上,或者放在有线连接的那一端,取决于你的体验需要什么。

一百一十八次提交,大周末。周日晚上的引擎,和周六打开笔记本电脑时相比,已经不一样了。