這項由Adobe Research、Intel Labs、Manycore Tech Inc、Adobe、NVIDIA、ETH Zurich以及Imperial College London聯合開展的研究，以預印本形式於2026年7月7日發布在arXiv平台，論文編號為arXiv:2607.06701。感興趣的讀者可通過該編號在arXiv上查閱完整原文。
**遊戲引擎里的"遙控困境"**
假設你是一位機器人研究員，想讓AI學會在城市街道上安全行駛。現實世界太危險，真車太昂貴，於是你打算用電腦里的虛擬城市來訓練AI。這個虛擬城市畫面精美、車水馬龍，幾乎和現實沒什麼區別——問題是，你沒辦法用Python（一種流行的編程語言，可以理解為研究人員的"工作語言"）靈活地控制這個虛擬世界，就好像你擁有一台頂級遊戲機，卻找不到對應的遙控器。
這個困境並不是少數研究者才有的煩惱。近年來，虛擬仿真環境已經成為AI研究的核心基礎設施，從讓AI學會下圍棋到訓練無人機飛行、再到開發自動駕駛汽車，都少不了高質量的虛擬世界。在這些虛擬世界裡，用遊戲引擎構建的場景因為畫面逼真、物理效果準確而備受青睞。虛幻引擎（Unreal Engine，簡稱UE）就是其中最耀眼的一款：它完全開源、畫面頂尖，連好萊塢特效和頂級3A遊戲都在用它。
然而，現有的基於虛幻引擎的仿真工具有三個讓研究者頭疼的老毛病。第一，能通過Python控制的功能太少，往往只有幾百個固定接口，就像一台遙控器上只有三四個按鈕，大部分功能根本按不到。第二，把虛擬世界裡渲染好的高清圖像傳回Python程序的速度極慢——有些工具慢到比直接在遊戲裡看畫面慢了二三十倍，相當於你在遊戲裡能流暢看4K電影，但把電影截圖傳給AI時卻要等上半分鐘。第三，這些工具大多是"一體化大塊頭"，和特定項目深度綁定，很難嵌入到現有的研究項目里，也很難把外部資產導入進去。
正是為了解決這三個痛點，來自多家頂尖機構的研究團隊聯手打造了SPEAR——一個面向光真實（Photorealistic）具身AI研究的仿真平台。
一、SPEAR究竟是什麼：那把"萬能遙控器"
SPEAR的核心是一個Python庫，可以連接到任何用虛幻引擎開發的應用程式，並通過一套模組化插件架構對其進行編程控制。用一個比喻來說：虛幻引擎就像一台功能無比強大的專業級錄音棚，而現有的仿真工具只給你提供了幾個簡單旋鈕，SPEAR則相當於把整個錄音棚的所有推子、按鍵、效果器全部接上了一塊全功能調音台，讓你從Python端就能精細操控每一個細節。
SPEAR之所以能做到這一點，關鍵在於它直接對接了虛幻引擎的"反射系統"（Reflection System）。所謂反射系統，可以理解為虛幻引擎內部的一張"功能總目錄"——引擎里幾乎所有的類、函數、變量都登記在這張目錄里，只要你知道名字，就能在運行時動態查找和調用。SPEAR通過一套專門的C++接口把這張目錄暴露給Python，讓Python代碼能用字符串（也就是文字名稱）來查找類、調用函數、讀寫變量，完全不需要為每一個功能手寫專屬的轉接代碼。
得益於這個設計，SPEAR一口氣向Python暴露了超過14,000個獨特的虛幻引擎函數，以及超過53,000個虛幻引擎屬性變量。這相當於現有同類工具的十倍以上。與此同時，SPEAR自身的代碼量非常克制，全部Python和C++代碼合計約27,000行，遠少於AirSim的14萬行和CARLA的15萬行。在同類工具中，UnrealCV+雖然也能訪問部分虛幻引擎內部功能（約747個函數和8,721個變量），但它的代碼量也只有11,000行左右，而SPEAR在暴露超出它約二十倍功能量的同時，代碼體積也只有其約兩倍多，足見設計的精煉。
二、編程模型：像寫普通Python代碼一樣控制虛擬世界
SPEAR最讓開發者感到親切的地方，是它的編程體驗極其自然。考慮這樣一個場景：你想在虛擬室內場景里生成一組坐標軸模型，把它放到某個位置，然後把它放大四倍，最後查詢它的位置。在SPEAR里，這整個過程就像這樣——先獲取一個遊戲對象，調用`spawn_actor`生成它，調用`SetActorScale3D`縮放它，再訪問`RootComponent`根組件並獲取其位置。這些操作寫起來就像調用Python的普通函數和屬性一樣，完全沒有額外的包裝或註冊步驟。
這種體驗背後有一套精心設計的"事務"（Transaction）機制。在SPEAR里，對虛幻引擎的操作被組織成一幀一幀的"事務單元"，每個事務單元由`begin_frame`上下文和`end_frame`上下文組成，分別對應一幀的開始和結束時刻。用戶只需要在Python里用`with begin_frame():`和`with end_frame():`兩個代碼塊把操作包起來，就相當於告訴引擎"這些事情在同一幀的開始做，那些事情在這幀的結束做"。引擎保證同一事務內的所有操作都在同一幀內完成，並且按照Python代碼的順序依次執行，沒有歧義。
另一個極為實用的設計是"異步操作"。默認情況下，每次調用虛幻引擎函數，Python都要等待引擎真正執行完畢才能繼續，這就像你每發一條簡訊都要等對方回復了才能發下一條。SPEAR為每一個函數都提供了一個異步版本（在函數名前加`async.`前綴），調用異步版本時Python不等待引擎，而是立刻拿到一個"未來對象"（Future），繼續做其他事情，等到真正需要結果時再從這個未來對象里取值。如果結果還沒準備好，取值時才會等待。這種機制類似於網購時下單後拿到一張快遞單號，你不用守在門口等，快遞到了再去取就行。
通過合理使用異步操作，Python線程和引擎的遊戲線程可以完全並行運行，彼此不互相阻塞，從而讓整個系統以接近引擎原生速度運行。為了防止Python線程跑得太快把引擎遠遠甩在後面，系統會在同時有超過一個未完成事務時，讓Python在進入下一個`begin_frame`之前稍作等待，確保兩者的進度不過分偏離。
SPEAR的編程模型還有一個非常重要的特性：擴展極其容易。如果你寫了一段C++代碼，想讓它能從Python端訪問，只需要在函數或變量旁邊加上`UFUNCTION`或`UPROPERTY`註解，虛幻引擎就會自動把它納入反射系統，SPEAR就會自動把它暴露給Python——不需要改動任何SPEAR的代碼，不需要額外的註冊步驟。這對研究者來說意味著極大的靈活性。
三、速度的秘密：圖像傳輸比現有工具快十倍以上
在具身AI研究中，仿真平台需要頻繁地把渲染好的圖像傳給Python程序，讓AI"看"到虛擬世界裡發生的事情。這個傳輸過程的速度，直接決定了訓練和實驗的效率。
SPEAR為此專門設計了一套高性能相機傳感器，能以1920×1080（全高清）解析度每秒渲染73幀圖像，並直接寫入用戶的NumPy數組（一種Python里常用的數據容器），整個過程不需要額外的數據複製。這個速度是同類虛幻引擎插件中的佼佼者，比當時主流的同類工具快了一個數量級（約9至21倍）。
這個成績是怎麼做到的？關鍵在於兩個技術：異步通信和進程間共享內存。異步通信前面已經提到，它讓Python不用乾等引擎渲染完成。共享內存則是更底層的加速手段：傳統做法是引擎把圖像數據從GPU顯存複製到內存，再通過網路或管道傳給Python程序，這個過程要複製多次。SPEAR改用了作業系統級別的"共享內存區域"，讓引擎和Python程序直接共享同一塊內存，渲染好的圖像數據從GPU卸載到這塊內存後，Python程序直接讀取，完全跳過了中間的複製環節，就像兩個人共用同一塊白板，省去了互相抄寫的麻煩。
此外，SPEAR的相機傳感器還支持"渲染延遲"（Rendering Latency）配置：允許用戶以犧牲一點時效性（即接受圖像比當前幀晚一到兩幀才到手）為代價，換取更高的吞吐量。配置為0幀延遲時，吞吐率約為56幀/秒；配置為1幀延遲時升至約65幀/秒；配置為2幀延遲時可以達到約73幀/秒。這種設計給了用戶根據實際需求靈活權衡的空間。
研究團隊做了詳細的橫向對比實驗。在與UnrealCV+的對比中，他們在完全相同的虛幻引擎項目、相同場景、相同項目設置下分別運行兩個插件，SPEAR在0幀延遲配置下幀率為56幀/秒，而UnrealCV+僅有3.5幀/秒，相差約16倍。在與AirSim和CARLA的對比中，為了公平比較，研究團隊特意將三個平台的"無Python通信時的獨立渲染幀率"調整到接近一致（SPEAR約89幀/秒，CARLA約90幀/秒，AirSim約93幀/秒），確保任何差異都來自通信開銷而非渲染質量。結果是：在0幀延遲條件下，SPEAR達到32幀/秒，AirSim只有2.6幀/秒，SPEAR約快12倍；在2幀延遲條件下，SPEAR達到37幀/秒，CARLA約33幀/秒，SPEAR仍領先約10%。
四、不只是速度：前所未有的地面真值圖像模態
SPEAR的相機傳感器不僅快，還"看得多"。除了普通的美感圖像（即我們平常看到的彩色照片式渲染圖）之外，SPEAR還能渲染多種"地面真值圖像模態"（Ground Truth Image Modalities）——這些是研究者用來訓練和評估AI的特殊圖像，包含普通照片看不到的資訊層。
具體來說，SPEAR能輸出的圖像類型覆蓋了深度圖（每個像素到相機的距離）、表面法線圖（每個點的表面朝向方向）、實例ID圖和語義ID圖（標註每個像素屬於哪個物體或物體類別）、材質ID圖（標註每個點的材質類型），以及一套非漫反射本徵圖像分解（Non-Diffuse Intrinsic Image Decomposition）——這是把圖像中的光照、材質、反射等成分分開的技術。此外還有物理基礎著色參數（Physically Based Shading Parameters），這些參數描述了每個表面材質的物理屬性，比如粗糙度、金屬度等。
值得特別提及的是，這套非漫反射本徵圖像分解在現有任何基於虛幻引擎的仿真器中都找不到，是SPEAR獨有的能力。研究團隊指出，SPEAR的相機傳感器能輸出Hypersim數據集（Adobe Research此前發布的一個著名室內場景合成數據集）中的全部圖像模態，同時在此基礎上增加了新的模態。
五、靈活得出人意料：那些無法用其他工具完成的事
SPEAR的高度可編程性帶來了什麼？研究團隊通過一系列實例展示了它的邊界在哪裡——或者說，展示了它幾乎沒有邊界。
第一類應用是控制多種具身智能
體。研究團隊用SPEAR控制了Epic Games多個樣例項目中的六種不同智能體：CitySample項目里的行人和汽車、StackOBot項目里的飛行機器人、CropoutSample項目里資源採集遊戲中的多個智能體、GameAnimationSample項目里的一個具有跑酷能力的人類角色和一隻四足機器人。每種智能體的動作空間完全不同——開車、走路、飛行、奔跑跳躍——而SPEAR用同一套編程接口駕馭了它們全部，這在其他任何現有仿真工具中都無法實現。
第二類應用是操控虛幻引擎的程序化內容生成（PCG）系統。在Epic Games的ElectricDreams樣例項目中，研究團隊用SPEAR控制了場景里一個巨大的岩石結構的位置，讓它從左移到右。神奇的是，引擎的程序化系統會自動根據岩石位置調整周邊所有細節——水面繞著岩石流動，木頭自動出現並與附近結構相連，整個場景始終保持和諧自洽。研究團隊還用同一套接口控制了場景天光的朝向來模擬一天中不同時刻的光照變化。所有這些操作，都是通過幾行Python代碼完成的。
第三類應用是與MuJoCo物理仿真器的聯合仿真（Co-simulation）。MuJoCo是一款專注於精確物理計算的仿真引擎，常用於機器人研究。研究團隊建立了一個實時橋接系統：用戶在MuJoCo的默認交互界面里操控場景（比如給一把椅子施加一個力），與此同時，SPEAR持續讀取MuJoCo場景的狀態，並實時更新對應虛幻引擎場景里物體的位置和姿態，使兩個仿真世界保持同步。整套協同仿真的邏輯同樣可以用SPEAR的`begin_frame`/`end_frame`編程模型乾淨地表達：在每個仿真步驟里，先禁用虛幻引擎自身的物理，循環執行MuJoCo的若干個子步驟，然後讀取MuJoCo里每個物體的位姿，通過SPEAR更新到虛幻引擎里，最後渲染觀測圖像。這種設計讓用戶可以完全自定義物理子步數，非常靈活。
第四類應用是渲染同步多視角圖像。研究團隊用SPEAR配合MetaHumans樣例項目（Epic Games推出的高精度數字人系統），在同一幀內同步渲染了同一個細節豐富的數字人角色的多個不同角度的圖像。這類同步多視角數據在面部重建、神經輻射場（NeRF）等3D重建研究中非常有價值。
第五類應用是自然語言場景編輯。研究團隊構建了一個AI編程助手系統，讓視覺-語言大模型（Vision-and-Language Model）讀取當前場景圖像，根據用戶的文字指令（如"把兩把扶手椅挪近一些但不要完全接觸"、"把地板變得儘可能亮"、"在沙發上方和扶手椅上方各放一盞明亮的聚光燈"），疊代編寫SPEAR程序並執行，完成場景修改。整套系統運行流暢，這說明SPEAR對AI編程助手非常友好，因為它的接口和普通Python無異。
六、靈活的同步策略：一套模型，涵蓋所有現有方案
SPEAR編程模型的另一個亮點是表達能力的強大：它可以用來實現現有各類仿真器中不同的時間同步策略，而每種策略都只需要幾行代碼。
AirSim採用"單步執行"模式，每次讓引擎前進一幀然後等待Python；CARLA有同步和異步兩種模式；UnrealCV+支持"批量命令"，把多個操作打包成一次請求發送；Habitat 2.0使用"雙緩衝觀測"機制，在引擎渲染下一幀時Python就可以開始處理上一幀圖像。研究團隊在論文中明確展示了如何用SPEAR的`begin_frame`/`end_frame`機制，寫出與上述每種方案功能完全等價的步驟函數（即OpenAI Gym風格的`step`函數）。此外，外部物理仿真器的聯合仿真、用戶自定義子步驟的物理更新，也都能自然地融入這套框架，不需要任何特殊處理。
這種統一性意味著，研究者不再需要為了換一種實驗策略而切換到完全不同的仿真工具，只需要調整幾行Python代碼即可。
七、系統架構：幕後的精密工程
SPEAR採用客戶端-伺服器架構：Python程序作為客戶端運行在一個進程里，虛幻引擎應用作為伺服器運行在另一個進程里（可以是同一台機器，也可以是不同機器，通過TCP/IP連接）。
伺服器端用rpclib實現（一個現代C++的遠程過程調用庫），客戶端用nanobind實現（一個高效的C++/Python綁定工具）。這套組合讓客戶端可以像調用本地C++函數一樣調用伺服器上的入口點，類型安全有保障，性能開銷極小。
伺服器在虛幻引擎內部運行在一個獨立的"伺服器線程"上，這與大多數現有插件不同——現有插件通常在遊戲主線程上響應命令，這意味著每次響應都要中斷遊戲主線程的正常執行。SPEAR的伺服器線程可以獨立響應Python命令，不需要打斷遊戲線程；當真正需要在遊戲線程上執行操作時，伺服器把任務放入兩個線程安全隊列（分別對應`begin_frame`和`end_frame`），遊戲線程在每幀的特定時刻自動排空這些隊列。
研究團隊手工實現了193個專門的伺服器入口點，用於暴露那些不在反射系統里的虛幻引擎功能（比如一些底層系統功能）以及反射系統本身。這193個入口點中編程自動生成，大幅減少了重複代碼。
對於涉及大塊數據傳輸的場景（比如渲染圖像），SPEAR引入了一套名為"SpFunction"的自定義函數機制。任何虛幻引擎對象都可以在其組件層次結構中插入一個特殊子組件，並在運行時綁定命名函數到這個組件上；這些命名函數（SpFunction）在Python端看起來和普通的反射可見函數完全一樣，但它們的輸入輸出可以是NumPy數組，而不只是JSON字符串。當SpFunction的調用到達客戶端-伺服器邊界時，NumPy數組被映射為內部的"命名數據數組"表示；如果配合共享內存使用，這個過程完全不需要數據複製。
關於類型系統，虛幻引擎對"可反射類型"有嚴格限制：只有基本類型、字符串、指向UE對象的指針、部分容器、枚舉，以及由上述類型遞歸組合的結構體，才能出現在反射函數的簽名和成員變量里。這個限制反而帶來了一個便利：反射類型都可以自動序列化和反序列化為JSON，而Python字典也可以輕鬆轉換成JSON。兩者的結構對齊，使得Python字典成為了SPEAR里傳遞函數參數和返回值的通用表示，用戶在Python里直接寫字典就能調用接受三維向量等複雜類型的UE函數。
**說到底，SPEAR在想什麼**
歸根結底，SPEAR解決了一個長期被忽視但確實很重要的工程問題：如何讓研究者用最少的代碼，對一個功能極其強大的引擎擁有最大的控制權，同時還能以接近引擎原生的速度獲取渲染數據。
它沒有把虛幻引擎包裝成一個針對某種特定AI任務設計的專用工具，而是選擇把引擎本身最完整地暴露出來，讓用戶根據自己的需要去決定要做什麼。這種"寧可讓用戶寫更多Python，也不預設用戶的目標"的設計哲學，讓SPEAR能同時服務於機器人仿真、自動駕駛、數據集生成、人臉渲染、場景編輯等看起來毫不相關的用途。
對於普通人來說，這項研究最直接的影響可能體現在：未來那些在城市裡穿行的自動駕駛汽車、在倉庫里作業的機器人、在醫院裡輔助手術的機械臂，很可能都在某個虛擬世界裡訓練了數百萬小時，而這些虛擬世界就是由SPEAR這樣的工具構建和控制的。光真實的仿真讓AI在"假世界"里學到真本事，再把這些本事帶進現實世界。
研究團隊相信，SPEAR有潛力成為電腦視覺、機器人和具身AI領域的基礎數據引擎，並在不遠的將來，成為連接網際網路規模視覺-語言大模型與虛幻引擎頂級虛擬世界的橋樑。這座橋一旦穩固，通往AI輔助內容創作、個性化娛樂和空間智能基礎研究的大門，將會向更多人敞開。
有興趣深入了解技術細節的讀者，可以通過論文編號arXiv:2607.06701在arXiv平台查閱完整原文，項目的全部代碼也在GitHub的spear-sim/spear倉庫公開，可以自由探索。
---
Q&A
Q1：SPEAR和AirSim、CARLA這些仿真器有什麼本質區別？
A：AirSim和CARLA是為特定用途（無人機/自動駕駛）定製的整體式仿真器，只開放了幾百個固定接口，和引擎深度綁定。SPEAR是一個通用Python庫加模組化插件，直接對接虛幻引擎的反射系統，暴露超過14,000個引擎函數，幾乎可以控制任何虛幻引擎項目，不局限於某類任務或場景。
Q2：SPEAR的圖像傳輸為什麼能比其他工具快十幾倍？
A：核心在於兩項技術：異步通信讓Python不用等引擎渲染完就能繼續執行；進程間共享內存讓渲染好的圖像從GPU卸載後直接寫入Python能讀的內存區域，完全跳過了傳統方式里多次數據複製的過程，圖像傳輸速度因此大幅提升，在1920×1080解析度下最高可達73幀/秒。
Q3：SPEAR暴露的那14,000多個虛幻引擎函數是怎麼維護的，會隨著引擎版本更新而失效嗎？
A：這些函數不是手工維護的列表，而是通過SPEAR直接讀取虛幻引擎反射系統的實時目錄自動獲得。只要虛幻引擎更新後某個函數仍然標註了UFUNCTION或UPROPERTY，SPEAR就會自動把它暴露給Python，不需要手動更新。新增的函數同理，天然就會出現在SPEAR可訪問的範圍里。
