空間智能是最近幾年大模型討論里被頻繁提到但評估方式仍然混亂的能力維度。人類判斷一個模型是否理解“桌子左邊”“杯子前方”不會要求它輸出一組坐標而是看它能否在真實或模擬環境中做出正確布局。浙江大學研究團隊提出的一種 Agentic 空間認知評估框架正是順著這個思路讓生成式模型把空間理解“畫”出來而不是強迫 LLM 在文本里輸出數值坐標。這個轉變看起來只是從數值輸出變成圖像輸出背后卻涉及任務定義、動作空間、評估指標和 Agent 循環設計的一系列調整。這篇文章會圍繞這個框架思路拆解它的設計動機、核心模塊、一個簡化版原型實現以及落地時容易踩的坑。適合關注多模態大模型、具身智能、模型評估和 Agent 開發的同學閱讀。1. 為什么“輸出坐標”這條評估路徑走不遠1.1 LLM 用文本表達空間時的信息瓶頸大語言模型本質上是把文本 token 序列映射成下一個 token 的概率分布。即使最強的 LLM也只能在它學過的文本分布里“猜測”坐標數字。對于“把杯子放在桌子右側 50 厘米處”這個問題模型可能會回答“(154, 320)”但它并不具備連續幾何推理能力它只是在文本統計規律里找到了一個看起來合理的數值。問題在于空間場景往往是連續的、關系型的。兩把椅子之間的“中間位置”不是一個唯一坐標而是一條線段一個物體“在另一個物體前方”取決于觀察角度、朝向和基準線。LLM 如果只能輸出坐標就必須把一組連續變化的空間關系壓縮成若干個離散數字。這種壓縮會丟失大量空間語義比如“離桌子很近但沒碰到”和“在桌子正前方 10 厘米”在坐標上可能只有很小的差異但語義差別很大。因此如果想要評估一個模型是不是具備空間智能應該給它一種更適合表達空間結構的方式——圖像、布局、拓撲關系而不是坐標數值。生成式模型擅長從語義描述生成視覺結構正好可以在空間認知評估中充當“輸出通道”。1.2 坐標輸出評估的五個具體問題即使不考慮 LLM 的能力極限強迫模型輸出坐標來評估空間認知工程上也非常別扭。以下五個問題在實際項目里最容易遇到。問題典型表現產生的原因數值精度不穩定模型多次嘗試同一任務坐標相差很大LLM 生成數字只靠文本概率缺少規約和驗證坐標基準難對齊模型認為的“左上角”和評估方實現的“左上角”不一致沒有統一坐標系、縮放比例和原點定義空間關系無法直接體現坐標正確但擺放后互相遮擋、重疊坐標本身不包含物體尺寸、方向和碰撞約束評估粒度粗糙答案只能判對或錯無法判斷“接近正確”坐標距離閾值需要人工拍腦袋且不同任務語義不一致場景擴展性差換一張地圖或換一種任務定義坐標體系就要重做坐標本質上是任務相關的局部編碼不具備通用性這幾點不是某個模型的問題而是評估設計的問題。如果我們考核的重點是空間關系理解就應該給模型一個能夠自然表達關系的輸出空間。坐標不是關系坐標只是從關系推導出來的一種結果。1.3 生成式輸出把空間認知拉回可視世界生成式模型有一個特點它可以把一個描述性的語義空間轉換成一個可被人類和算法反復查看的視覺空間。例如讓模型“畫”出桌子右側有一個杯子生成的圖像即便不是真實照片也能直觀反映出左右關系、遮擋關系、遠近尺度。這種做法的本質是改變評估接口。舊接口模型輸出坐標評估器解析數字。新接口模型輸出動作或語義元素生成式模型渲染成場景評估器觀察場景。把空間認知評估從“數字比較”變成“場景生成與場景理解”能同時測兩種能力模型是否理解了空間語義以及模型是否能把自己的理解轉換成可執行的空間結構。它也更接近人類認知心理實驗中常用的“擺放任務”設計。2. Agentic 空間認知評估框架的設計思路2.1 整體流程不是讓模型直接回答而是讓模型在環境中“做”傳統評估是一次性問答給定問題取模型回答和標準答案比較。Agentic 評估則不同它把評估過程設計成一個多步交互閉環。框架的核心流程可以概括為五步任務管理器生成自然語言空間任務例如“請把藍色方塊放到紅色圓形上方”。Agent 接收任務和當前場景狀態輸出一個動作指令而不是直接輸出最終答案。生成式模型或空間模擬器執行該動作將場景狀態更新并渲染成圖像或結構化場景圖。評估器檢查執行后的場景是否滿足任務要求并反饋給 Agent。Agent 根據反饋繼續嘗試直到滿足終止條件。這個流程的關鍵在于空間任務不是靠一次完整答案來判定而是靠一系列動作和中間結果來評估。這種范式天然適合 Agentic AI 的測試場景因為 Agent 的每一步決策都可能影響最終布局。偽代碼形式的整體流程如下def run_evaluation(task, agent, renderer, evaluator, max_steps5): state renderer.empty_state() for step in range(max_steps): action agent.generate_action(task, state.to_prompt()) state renderer.apply_action(state, action) scene renderer.render(state) is_done, score, feedback evaluator.evaluate(task, state, scene) if is_done: return {solved: True, score: score, steps: step 1, scene: scene} return {solved: False, score: score, steps: max_steps, scene: scene}在這個循環里Agent 不一定要是 LLM它可以是任何能輸出動作的模型生成式模型在這里也不是為了“畫得好看”而是把不可直接觀察的空間狀態變成可評估的視覺產物。2.2 四個核心模塊任何 Agentic 空間認知評估框架都可以拆成四個模塊任務管理器、Agent、渲染器、評估器。任務管理器負責構造任務集合。空間任務至少包括三類關系擺放A 在 B 的右側、路徑規劃從起點走到終點并避開障礙、布局完成在限定區域內安排多個物體。在實際項目中任務管理器應該輸出結構化任務描述而不能只給一句話因為機器解析“把球放到桌子的左邊”時需要知道“桌子”有哪些候選實體、坐標系是什么、成功條件是什么。Agent 是待評估模型。它可以接收文本狀態描述也可以接收渲染后的圖像。在框架原型里通常先讓 Agent 輸出文本動作后續再擴展為直接輸出圖像操作。這里最大的設計約束是動作空間。如果動作空間仍然是“輸出坐標”那就又回到了起點。推薦的做法是讓 Agent 輸出語義動作例如“move table left”或“place cube above circle”再由渲染器執行這些語義動作。渲染器把動作變成空間狀態。最輕量的方式是使用規則模擬器物體用矩形框表示關系由幾何計算決定。更接近前沿的方式是調用擴散模型生成圖片例如用 Stable Diffusion 或 ComfyUI 工作流生成一張包含指定物體的場景圖。渲染器不一定需要和 LLM 在同一臺機器上兩者可以通過 API 解耦但如果是在本地開發要注意顯存、端口和工作流版本。評估器負責判斷最終狀態是否滿足任務要求。它可以由規則計算、視覺模型識別或人工復核組成。規則計算速度快、可解釋性強適合作為 ground truth視覺模型識別適合處理圖像中的遮擋和模糊場景人工復核適合小樣本評測。生產環境一般建議三層結合不能只依賴單一定性判斷。2.3 為什么“Agentic”是這種評估方式的必要條件空間認知不是一次作答可以測完的。一個模型能正確回答“杯子在桌子右邊”不代表它能在沒有桌子的情況下自己規劃出一個新杯子放在合適位置更不代表它能通過多步操作調整布局。使用 Agentic 方式可以讓模型在嘗試過程中暴露更多信息模型第一次動作是否正確。模型能否理解反饋并修正錯誤。模型面對開放空間時能否自主選擇穩定路徑。模型是否會在多余動作中破壞已有的正確布局。這些信息在一次性問答評估里全部丟失。Agentic 評估的價值不只是“多給模型幾次機會”而是把空間認知從靜態知識測試變成動態決策測試。Agentic AI 當前的一個核心挑戰就是如何在長周期任務中保持目標一致性空間認知評估正好提供了一個非常適合檢驗 Agent 規劃能力的環境。3. 從零搭建一個最小原型這一節實現一個簡化版的原型。它不追求真實擴散模型渲染而是用一個規則渲染器先把框架跑通。真實項目里可以把 renderer 替換成 ComfyUI 或 Stable Diffusion 后端但原型階段的重點是驗證動作接口和評估邏輯。3.1 環境準備原型使用 Python 3.9核心依賴只有 Pillow 和 numpy。如果后續要接入真實生成式模型再按需要安裝 diffusers、torch 或請求 ComfyUI API。python -m venv .venv source .venv/bin/activate pip install pillow numpy這里不把 PyTorch 作為前置依賴因為框架的價值在于評估邏輯不在于具體生成器。生產環境如果要接視覺生成模型通常需要單獨部署一臺帶 GPU 的推理服務Agent 進程和渲染服務可以通過 HTTP 通信。也就是說LLM 和 ComfyUI 不要求必須在同一臺電腦上但你需要約定好圖片輸入輸出的格式和任務回調地址。3.2 定義空間場景和渲染器場景用一組矩形物體表示。每個物體有名稱、類別、位置、尺寸和顏色。渲染器把物體繪制成一張 256x256 的圖片用于后續可視化。from dataclasses import dataclass, field from typing import List, Dict dataclass class SceneObject: name: str category: str x: int 0 y: int 0 width: int 30 height: int 30 color: str blue dataclass class Scene: width: int 256 height: int 256 objects: List[SceneObject] field(default_factorylist) def to_prompt(self) - str: lines [] for obj in self.objects: lines.append(f{obj.name}({obj.category}): at {obj.x},{obj.y}) return \n.join(lines)渲染器可以先用 Pillow 畫矩形框后續再替換成真實圖片生成模型。from PIL import Image, ImageDraw def render_scene(scene: Scene) - Image.Image: img Image.new(RGB, (scene.width, scene.height), white) draw ImageDraw.Draw(img) for obj in scene.objects: x0 obj.x - obj.width // 2 y0 obj.y - obj.height // 2 x1 x0 obj.width y1 y0 obj.height draw.rectangle([x0, y0, x1, y1], fillobj.color, outlineblack) return img這個階段只做基礎繪制不做透視、遮擋和光照。評估邏輯必須能脫離視覺效果獨立工作否則生成器的畫風會影響評估結果。3.3 給 Agent 定義一套不依賴坐標的動作接口為了讓評估框架嚴格避免“通過坐標作答”Agent 的動作接口只提供語義操作。示例動作集合包括place、move、remove。下面是一個動作格式action { action: place, object: cup, category: cup, relation_target: table, relation: to_the_right_of, distance: medium }注意這里沒有 x/y 坐標。Agent 只需要描述“在什么位置放什么物體、相對誰是什么關系”坐標由渲染器依據規則計算。這樣設計的原因很簡單如果 Agent 仍然輸出坐標那么生成式模型只是變成了一個后處理畫圖工具模型的空間認知仍然停留在數字猜測階段。下面是一個簡化的關系位置求解函數演示渲染器如何把語義關系轉換為坐標def resolve_position(scene: Scene, target_name: str, relation: str, distance: str): target next(obj for obj in scene.objects if obj.name target_name) delta 40 if distance medium else 60 if relation to_the_right_of: return target.x delta, target.y if relation to_the_left_of: return target.x - delta, target.y if relation above: return target.x, target.y - delta if relation below: return target.x, target.y delta raise ValueError(funsupported relation: {relation})實際框架中關系計算會更復雜比如需要考慮物體尺寸、邊界、朝向和多個約束條件。但核心原則一致Agent 產生語義意圖坐標是環境層解析的產物。3.4 評估器實現評估器檢查最終場景中物體之間的關系是否滿足任務要求。這里用結構化關系檢查作為 ground truth而不是直接讓視覺模型判斷。def evaluate_scene(scene: Scene, task: dict) - tuple[bool, float, str]: required task[target] relation required[relation] target_name required[target_object] obj_name required[object] try: obj next(o for o in scene.objects if o.name obj_name) target next(o for o in scene.objects if o.name target_name) except StopIteration: return False, 0.0, missing object or target obj_center (obj.x, obj.y) target_center (target.x, target.y) distance_threshold 60 if relation to_the_right_of: ok obj_center[0] target_center[0] distance_threshold success_score 1.0 if ok else 0.2 feedback right relation if ok else not enough to the right elif relation above: ok obj_center[1] target_center[1] - distance_threshold success_score 1.0 if ok else 0.2 feedback above relation if ok else not high enough else: ok False success_score 0.0 feedback frelation {relation} not implemented return ok, success_score, feedback評估器要返回三個值是否完成、獎勵分數、反饋文本。Agent 的下一次動作可以依賴反饋文本進行修正。3.5 主流程和運行結果主流程把 Agent、渲染器、評估器串起來。下面的 Agent 是一個模擬實現假設它能調用任意 LLM 的對話補全接口但在原型里用固定邏輯代替。def mock_agent_action(task, scene_text, feedback): # 實際項目中這里調用 LLM輸入 task scene_text feedback輸出結構化動作 return { action: place, object: cup, category: cup, relation_target: table, relation: to_the_right_of, distance: medium, } def run(task, max_steps3): scene Scene() scene.objects.append(SceneObject(nametable, categorytable, x120, y128, width60, height20, colorbrown)) feedback for step in range(max_steps): action mock_agent_action(task, scene.to_prompt(), feedback) if action[action] place: ox, oy resolve_position(scene, action[relation_target], action[relation], action[distance]) scene.objects.append(SceneObject(nameaction[object], categorycup, xox, yoy, colorgray)) done, score, feedback evaluate_scene(scene, task) if done: img render_scene(scene) img.save(fresult_step_{step}.png) return {solved: True, steps: step 1, score: score, scene: scene} return {solved: False, steps: max_steps, score: score, scene: scene} task {target: {object: cup, target_object: table, relation: to_the_right_of}} result run(task) print(solved:, result[solved], score:, result[score], steps:, result[steps])運行后的預期結果中solved為 True場景渲染圖片里桌子的右側會出現一個灰色矩形杯表示關系滿足。4. 評估指標和關鍵參數設計4.1 動作空間設計原則Agentic 空間評估最容易被忽略的是動作空間。設計動作空間時有三個原則第一動作必須是語義級的不能是像素級或坐標級。例如“place object A to the right of B”是好的動作而“set A.x 140, A.y 128”不是。后者會繞回坐標評估。第二動作集合必須覆蓋常見空間任務的原子操作。至少包含放置、移動、刪除、旋轉和縮放。否則 Agent 無法完成復雜任務。第三動作必須可回滾。多步任務中Agent 可能把一個物體放錯位置之后必須允許它重新移動或刪除否則評估只能測一次擺放能力測不了修正能力。常見動作空間如下動作參數說明placeobject, relation_target, relation, distance生成一個新物體并放置在目標相對位置moveobject, relation_target, relation, distance移動已有物體到新關系位置removeobject刪除已有物體rotateobject, angle旋轉物體測試朝向理解set_constraintobject, min_distance_to, value設置空間約束適合復雜布局任務4.2 評估指標評估指標不能只看“最終有沒有成功”還要看過程質量。建議記錄以下幾類指標。指標計算方式關注點任務成功率完成任務次數 / 總測試次數空間語義理解是否足夠準確平均步數成功任務使用的總步數 / 成功任務數Agent 是否高效是否反復試錯動作合法率合法動作次數 / 總動作次數是否輸出越界、目標缺失等非法動作關系準確率滿足目標關系數量 / 全部目標關系數量多約束任務下逐項拆解能力場景一致性多次運行同一任務的布局 IoU 或距離標準差模型是否穩定還是靠隨機猜修正成功率第一次錯誤后第二次是否修正是否具備利用反饋調整的能力其中“修正成功率”是 Agentic 評估獨有的指標傳統坐標問答無法測試。這個指標能反映模型的空間推理是否具有閉環能力。4.3 關鍵參數表原型實現中有幾個影響評估結果的關鍵參數需要根據任務復雜度設置。參數默認值影響調大影響調小影響max_steps5最大嘗試步數容忍更多試錯但可能隱藏低效策略更容易失敗嚴格測試一次性決策能力distance_threshold60關系判斷容差更寬松容易誤判為“在右側”更嚴格但可能因坐標解析誤差而失敗render_size256渲染分辨率圖片更清晰生成成本更高節省資源但小物體可能看不清action_modesemantic動作輸出格式可擴展復雜動作限制表達空間feedback_leveltext反饋粒度模型更容易修正錯誤反饋模糊模型難以定位問題4.4 與坐標輸出評估的對比下面的對比表可以幫你快速向團隊解釋為什么新的框架值得做。維度坐標輸出評估Agentic 生成式評估輸出形式數字坐標語義動作 圖像/場景測量能力數字記憶空間語義理解和決策可解釋性坐標對錯無法解釋每一步動作可見可回放錯誤分析只能看偏差值能定位錯在哪個關系或哪一步場景擴展換地圖要重新定義坐標換任務只需改任務管理器工程復雜度低中高需要渲染器和狀態管理如果只是驗證一個模型能不能記住圖片中的大概坐標坐標輸出夠用。但如果目標是評估“空間智能”本身Agentic 生成式評估明顯更合理。5. 運行驗證與結果解讀5.1 最小驗證用例用上一節的原型跑三個任務放置把 cup 放到 table 右側。移動把 box 移到 circle 上方。多約束把 lamp 放到 desk 左邊并且離 wall 至少 40 像素。每個任務跑 10 次記錄成功率、平均步數、動作合法率。5.2 預期輸出正常通過時運行日志大概長這樣task 1: solvedTrue, steps1, score1.0, legal_rate1.0 task 2: solvedTrue, steps2, score1.0, legal_rate1.0 task 3: solvedFalse, steps5, score0.6, legal_rate0.8第三個任務失敗可能有兩個原因模型沒有輸出set_constraint動作或者約束關系解析器不支持。建議先檢查任務是否設計得過于復雜再檢查 Agent 是否理解動作空間。5.3 如何判斷模型是真正理解還是猜對一個評估框架如果只報一個成功率很容易被隨機策略干擾。要判斷模型是否真正具備空間智能至少做三個對照實驗。首先是動作空間消融。給 Agent 提供一個“隨機動作”基線如果隨機動作也能得高分說明評估器太寬松。正常情況下隨機動作成功率應該遠低于一個基礎 LLM。其次是場景干擾。同一個任務換用不同尺寸、不同初始位置成功率如果急劇下降說明模型只是在記訓練時的位置模式。最后是反事實任務。例如把“桌子右側”改成“桌子右后方”模型如果仍然只知道“右”而忽略“后”就能暴露出對方向組合的薄弱理解。5.4 學習環境與生產環境的差異原型階段用規則渲染器很容易跑通。生產中接入真實擴散模型做渲染時需要考慮幾個額外問題。第一渲染服務建議獨立部署。LLM 和 ComfyUI 不要求在同一臺電腦上可以通過 API 調用。否則生成式模型的顯存占用會影響 LLM 的批量推理。第二視覺評估不能替代結構化狀態。生成圖像可能因為畫風問題導致視覺識別失敗但結構化狀態里的物體位置是可靠的。生產環境建議始終維護一個結構化狀態表作為 ground truth視覺模型只用于額外一致性校驗。第三評估任務需要版本管理。空間任務描述、動作空間、關系解析規則都會迭代任何改動都可能讓歷史評估結果不可比。最好給每次評估打上任務版本號。6. 常見問題與排查路徑6.1 模型仍然輸出坐標而不是語義動作現象Agent 返回的動作里出現x、y字段甚至直接輸出一段帶坐標的 JSON。原因Base LLM 訓練數據里包含大量“位置信息用坐標表達”的示例模型默認沿用這種模式。如果 prompt 里沒有明確約束動作空間模型傾向于回到坐標輸出。排查方式打印 Agent 原始輸出檢查是否有坐標數字檢查 prompt 是否給定了合法的動作枚舉。解決方式在 prompt 中明確列出可用動作并給出幾個語義動作示例。更穩妥的做法是使用工具調用或結構化輸出讓模型只能選擇合法動作字段。對于不合法輸出可以直接丟棄并要求重新生成。6.2 渲染器生成的內容不穩定同一動作兩次結果不一致現象使用真實擴散模型生成圖像時同一句話生成的布局每次差異很大評估結果不穩定。原因擴散模型本質上是采樣過程隨機種子會影響結果。而且文本生成圖像模型對空間關系的表達能力有限可能導致“桌子右側的杯子”被畫成“桌子前面”。排查方式固定隨機種子比較兩次生成的差別檢查 prompt 是否包含額外位置詞查看渲染器是否對輸出圖像做了裁剪或后處理。解決方式原型階段先用規則渲染器做評估視覺模型只做二次展示如果必須用擴散模型可對生成的圖像做后處理約束比如根據語義分割結果把物體移動到目標區域。評估指標也要以結構化狀態為主。6.3 Agent 來回重復無效動作步數耗盡現象模型在多個任務上不斷輸出相同或者相近的動作分數始終停留在低分。原因反饋文本太模糊模型無法判斷應該修改哪個物體或者max_steps過大讓模型有機會試錯而不優化策略。排查方式在每一輪打印反饋文本和動作觀察模型是否根據反饋改變動作檢查動作空間是否缺少修正操作比如move和remove。解決方式增加反饋的定向性例如“cup 仍然在 table 上方需要向右移動”而不是只返回“失敗”。也可以縮短max_steps強制模型提高首步質量對于需要長期規劃的任務單獨引入規劃器模塊。6.4 評估結果和人工判斷不一致現象評估器認為任務未完成但人類看渲染圖覺得布局合理或者反過來評估器判定成功但人類明顯看出物體遮擋嚴重。原因規則評估器只檢查了物體中心點距離關系沒有檢查遮擋、邊界和碰撞或者評估器的容差過小。排查方式保存最終渲染圖片和結構化狀態逐項對照評估器的判斷條件。解決方式評估器增加“碰撞檢測”“遮擋檢測”“邊界檢查”。例如物體矩形框相交比例超過一定閾值就降低分數。另一個重要做法是加入人工復核抽樣定期檢查評估器閾值是否合理。7. 最佳實踐與擴展方向7.1 評估框架有效性檢查清單在正式使用這套框架之前建議先回答以下問題動作空間是否完全排除了坐標輸出渲染器是否維護一份結構化狀態而不是只有圖片評估器是否被隨機動作基線驗證過是否存在“只要隨機放置一個物體就能成功”的簡單任務是否考慮了遮擋、碰撞、邊界等物理約束每輪是否給 Agent 提供了可執行的反饋是否固定了任務版本和渲染器版本如果這些問題的答案有任何一個是“否”評估結果都需要打折扣。7.2 空間任務設計清單生成高質量空間任務比實現框架本身更需要經驗。設計任務時可以從下面幾個維度逐步加碼單關系 vs 多關系先測“A 在 B 右側”再測“A 在 B 右側且 C 在 A 下方”。靜態 vs 動態先測“放一個物體”再測“移動一個物體并保持其他物體不動”。絕對 vs 相對先測“物體在區域右上角”再測“物體在另一個物體前方偏左”。無遮擋 vs 有遮擋先測“兩個物體無重疊”再測“一個物體部分遮擋另一個物體時如何描述”。無歧義 vs 有歧義加入“之間”“靠近”等模糊概念測試模型是否能主動澄清或選擇合理默認值。任務庫建議按照難度分級每個級別至少 20 個任務保證評估穩定性。7.3 環境部署檢查清單如果想在生產環境接入視覺生成模型部署前檢查這些項LLM 服務和渲染服務是否通過 API 解耦兩條服務之間是否有超時、重試和降級策略生成模型是否固定了模型版本、采樣器和種子策略圖片傳輸格式是 base64 還是文件 URL大小是否可控渲染服務是否具備 GPU 資源監控和排隊機制是否保存了每輪動作、場景狀態、渲染圖片和評估日志方便回溯這里的平衡點是評估主鏈路盡量輕量重資源操作放到獨立渲染服務。不要把視覺生成模型嵌進 Agent 的主推理鏈路否則一次評估的延遲和硬件成本都會難以接受。7.4 擴展方向Agentic 空間認知評估框架有兩個自然延伸方向。第一個方向是具身智能。算法評估里“擺放杯子”可以遷移到機器人操作任務中。機器人收到語義指令后生成操作序列仿真器渲染場景或真實環境反饋傳感器數據評估器判斷是否完成任務。這種評估可以直接復用動作空間和結構化狀態設計。第二個方向是訓練數據增強。一旦評估框架穩定運行它生成的大量“任務-動作-場景-反饋”軌跡可以作為多模態模型的訓練語料。把成功和失敗的軌跡都保存下來再用 Agentic RAG 的方式在推理時檢索相似空間布局實例可以讓模型快速理解新場景。從更本質的角度看空間認知評估不應該停留在“模型能不能說出空間關系”的文本層面而應該測量“模型能不能在空間里做出正確決策”。浙大提出的這個方向核心貢獻是讓生成式模型成為空間語義的輸出媒介讓 LLM 的文本能力與空間推理能力解耦。實際落地時不需要一開始就追求真實圖像生成先把動作空間、狀態管理、關系評估器設計好再逐步接入更復雜的渲染后端會是一條更穩妥的路徑。對剛接觸這個方向的同學可以先從本文的規則渲染原型開始跑通一個任務再用自己的 LLM 替換 mock agent觀察它在多步空間任務里會暴露哪些問題。這一步做完再討論生成式圖像和更復雜的評估指標思路會清晰得多。