OpenXR 是骨架，雙鏈路無線電是神經

如果什麼都自己打造，你會晚一年出貨，而且說著一種生態系裡沒有任何東西聽得懂的語言。RakuAI 走的是另一條路：在 OpenXR 合適的地方站上標準的肩膀，而在標準尚未到位的地方——例如會自動切換的雙無線電連線——親手打造困難的部分。

在為 AR 眼鏡打造引擎時，最大的誘惑就是什麼都自己來。自己做姿態 API。自己做圖形繫結。自己做輸入模型。自己做控制器抽象層。這其中每一個決定都意味著四十小時的代理工作，再加上四十小時的人工審查。累積起來就是一年的心血，換來一個生態系裡沒有任何東西能與之對話的引擎。

我選擇走另一條路。凡是存在合適標準的地方，引擎就採用標準。OpenXR 是最具代表性的例子。這個週末，執行環境長出了它兩個月來一直需要的 OpenXR 骨幹。

OpenXR 方面落地了什麼

大部分的重頭戲都在這個週末陸續落地：

• OpenXR 圖形 API 繫結，含工作階段與交換鏈管理
• OpenXR 影格生命週期整合，含裝置遺失處理
• OpenXR 動作同步與視圖定位操作
• OpenXR 擴充支援：XR_FB_passthrough、XR_FB_foveation 與 XR_EXT_hand_tracking
• 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 跟上時（工作小組確實正在其中一些領域積極推進），我們就採用標準並淘汰自己的版本。

這就是我希望引擎維持的模式。標準存在之處就採用。標準缺席之處就自己打造。標準跟上之時，隨時準備採用。

遙測與 stub 完整性

這個週末還悄悄落地了一件事：結構化 JSON／OTLP 日誌與 OpenTelemetry 整合。這種管線工程不會有自己的發布公告，但正是它讓我們能回答「延遲預算花到哪裡去了」這個問題，而不必每次都手動在程式碼裡埋測量點。遙測管線現在已經接通每一個子系統，Phase 1 產出的儀表板是真實的。

同樣在這個週末：一個文件 PR 認真檢視了程式碼庫中的 stub 實作，把每一個分類為「其實是有用的測試工具」或「其實是一個洞」。有用的那些被重新命名並寫進文件。是洞的那些被列入追蹤。這份分類工作是代理們自己撰寫並落地的。這是一件小事。但也正是這種小事，放著不管太久，就會演變成一場嚴重的爛攤子。

我希望開發者與合作夥伴從中看到什麼

如果你是 OpenXR 工作小組的成員，這個引擎正在以標準的良好公民之姿被打造。擴充合適之處我們就採用。我們的實作發現相容性問題時，我們會回報錯誤。在標準尚未跟上的領域，我們會公開我們所打造的東西，而且我們寧願推動標準化，也不願維護一個分支。

如果你是硬體夥伴，而你的裝置符合 OpenXR 標準，那麼這個週末過後，引擎距離在你的裝置上執行又近了一步。剩下的工作是廠商特定的黏合層。我們很樂意一起完成這些工作。

如果你正在研發眼鏡與運算端之間的下一代鏈路技術（Wi-Fi 7+、自由空間光通訊、毫米波，任何技術都行），鏈路管理器抽象層就是你要接入的那一層。上層的執行環境不需要知道你是哪一種無線電。下層的執行環境會把你抽象掉。

整個週末九十八個提交。引擎長出了骨幹和神經。忙了漫長的兩天後，週日深夜闔上筆電的感覺真好。