InferNews

EngiWorld 把工程代理接入真實軟件工作流

2026 年 10 月 1 日

EngiWorld 不只測試代理人能否操作介面，更檢查它能否交付合乎工程規範的成果。

EngiWorld task examples and engineering software coverage

代理人要在 CAD、CAE、CAM、BIM、EDA 和 3D 視覺化軟件中完成工作，難點不只是點擊按鈕，而是要維持幾何、物理條件及跨軟件流程的正確性。EngiWorld 屬於工程代理人評測基準，實際處理的是「能否由指令一路產出可驗證工程成果」這個問題。

項目收錄 1,301 個專家編寫任務，涵蓋 26 個軟件平台、6 個工程領域及 6 類任務，支援 GUI 和 CLI。評測會檢查最終及中間工程文件的幾何有效性、物理可行性和規則符合度，數值設計任務亦會按規格達成程度連續計分，而非只分成功或失敗。

提供完整任務、驗證器及 GUI/CLI 評測執行環境
主實驗採用 300 個任務，清單位於 task/splits/main-300.txt
本地環境以 Linux、Docker 及虛擬機器執行，預設每個環境使用 4 個 CPU 和 16 GB RAM
七個前沿模型中，最高 EngiScore 只有 44.3；多軟件嘗試成功率為 3.6%

同類 Computer-use agents 評測多集中於一般桌面操作，EngiWorld 把判斷標準推到可交付的工程 artifact，因此更能揭示模型在長流程、跨軟件依賴及專業規範上的不足。代價是執行門檻較高：需要 x86_64 Linux、Python 3.10、Docker Engine 和環境映像，沒有 /dev/kvm 時亦可運行，但軟件模擬會較慢。

研究團隊、工程軟件開發商，以及想比較 GUI agent、CLI agent 或多模態模型能力的團隊，都可以用它重現測試並保存評測結果。它目前更適合作為嚴格的研究及模型比較工具，而非即插即用的生產自動化方案；最高分數與多軟件成功率反映，代理人距離穩定完成專業工程流程仍有明顯距離。

項目主頁 · GitHub

Categories: 開源, 北京大學, 清華大學, Agentic, 模型, 多模態模型, 軟件, 工具, 3D, Python, Dataset 數據集

VoxMem 測試音訊模型的記憶盲點

2026 年 10 月 1 日

VoxMem 不只測模型記得講過甚麼，還檢查能否辨認說話者、語氣與背景聲音，直面多輪語音記憶的缺口。

當語音助手要回想幾次對話之前的內容，答案未必藏在文字轉錄稿內：誰說過一句話、當時的語氣，以及背景傳來甚麼聲音，同樣可能決定答案。VoxMem 屬於語音記憶評測基準，透過多次會話測試 Large Audio Language Models（LALMs）能否保留及運用這些非文字資訊。

項目把測試拆成兩條軸線：需要找回的聲音證據包括 speech semantics、speaker identity、paralinguistic cues 和 environmental sound；記憶操作則涵蓋 information extraction（IE）、multi-session reasoning（MSR）、temporal evolution tracking（TET）及 answer refusal（AR）。這個安排比只問模型能否找回一句原話更接近長期語音助手的工作情境。

VoxMem 提供 3,196 個評測實例，涵蓋 34,743 段、共 177小時的語音會話，並固定問題及證據，只改變8K、16K、32K 和 64K tokens的上下文長度。測試者可從 GitHub 項目取得程式碼，再配合 Hugging Face上的資料集重現評測；Python 3.9 或以上是已列出的基本環境，但不同 LALM仍可能需要各自的模型存取設定。

結果指出，15個 LALMs 在 32K 上下文下沒有模型達到 40% 整體準確率；模型記住文字內容的能力明顯高於辨認說話者、語氣及環境聲音，而且歷史越長，差距越大。這令VoxMem 更適合用來找出語音記憶系統的失效位置，而非單純作為模型排名工具。

• 同時測試聲音證據與記憶操作，涵蓋15個有效組合
• 以多會話歷史取代單一錄音，檢查跨場景整合能力
• 包含證據不足時拒絕回答，能檢視模型是否過度猜測
• 非文字聲音資訊在長上下文下明顯較難保留

研究語音代理、會話記憶、音訊模型或長上下文系統的團隊，能用這套基準分辨問題究竟出在聲音理解、跨會話推理、狀態追蹤，還是拒答判斷。資料採用 CC BY-NC 4.0，程式碼則使用MIT授權，商業產品整合前仍要獨立檢查資料使用條件。

項目主頁 · GitHub · 數據集

Categories: 開源, 模型, Audio, 工具, Python, 語音, Dataset 數據集

HybridCUA 讓 Agent 懂得何時用命令列

2026 年 10 月 1 日

浙江大學、北京大學與清華大學團隊，讓 Computer-use agents 在 GUI 操作與 CLI 指令之間作出選擇，減少冗長點擊流程及連鎖錯誤。

浙江大學、北京大學與清華大學的研究團隊，將 CUA (Computer-use agents) 從單靠滑鼠鍵盤操作，帶到 GUI 與 command line interface（CLI）協作的工作方式。HybridCUA 屬於訓練框架及模型項目，處理的是代理知道可以用 shell 之後，仍未能判斷何時使用、如何使用的問題。

連串的 GUI 操作可以由一條命令取代，但 CLI 暴露給未受訓練的代理，反而令 OSWorld 準確率下降 2.5 至 11.5 個百分點。HybridCUA-8K 收集 GUI only、CLI only，以及交錯使用兩者的軌跡，再配合 supervised fine-tuning 和 CLI-aware rewards，訓練 HybridCUA-9B 選擇較合適的操作方式。

HybridCUA pipeline: (a) scalable generation of GUI-only, CLI-only and interleaved trajectories plus annotated RLVR tasks

• HybridCUA-9B 在 OSWorld 達到 53.6%，較基礎模型高 14.8 個百分點
• 平均每項任務使用 14.0 步，並可轉移至 OSWorld-MCP 及 Windows
• HybridCUA-8K 包含 5K 條混合軌跡及 3K 個已驗證 RLVR 任務
• CLI reward 分為 trajectory level 與 step level，分別鼓勵成功完成及減少失敗指令成本

儲存庫以 env_infra、online-rl 和 site 分開環境平台、GRPO 訓練流程及項目網站；前兩者透過 HTTP 的 /v1/sessions 協作，訓練器毋須自行啟動 VM 或容器。README 提供安裝腳本及 GPU、nvcc、Ray 等環境要求，但模型仍標示為 coming soon，因此目前較適合研究 Computer-use agents、GUI automation 或跨平台代理訓練的團隊閱讀資料集與訓練架構。

結果在 WindowsAgentArena 提升 4.0 個百分點，OSWorld-MCP 達 47.1%，Windows 達 36.0%，顯示 GUI 加 CLI 的方法具備一定跨平台能力；不過項目仍依賴複雜的分散式訓練環境，未提供即時可下載模型，距離一般使用者直接安裝仍有距離。

項目主頁 · GitHub · 模型

Categories: 開源, 北京大學, 清華大學, Agentic, MCP, 模型訓練, 庫, Dataset 數據集

OpenAI dots：讓 AI 代理持續推進複雜工作

2026 年 9 月 30 日

OpenAI 將 dots 設計成可持續工作的 AI 代理，協助處理跨應用程式的任務，同時保留人員審批權。

OpenAI 把 dots 交由 GPT‑6 Astra 驅動，定位成能長時間代辦工作的 AI 代理，處理項目跟進、應用程式操作和日常行政等容易中斷的工作。它擁有獨立雲端電腦，可按目標持續工作，亦會透過使用者回饋逐步掌握偏好與工作標準。

Dots 可經由插件連接超過 4,000 個應用程式，並在 ChatGPT、Slack 或 Teams 內使用。使用者可以直接提問、提供意見，或透過語音通話討論工作；在需要發送郵件、建立文件或執行其他操作時，系統會配合權限設定及審批流程，讓人員保留控制權。

OpenAI 分享的場景包括調查 Slack 中的程式錯誤、把新設計轉成可運作的應用程式，以及協助團隊追蹤規劃週期。早期測試者的 dot 亦曾發現漏開發票，準備文件後待使用者批准才寄出，反映它處理的是持續跟進而非單次問答。

目前 dots 正逐步向 Pro、Business Premium 和 Enterprise 計劃推出，完整的安裝步驟、收費細節及市場名單未有在提供的資料中交代。可先留意以下能力與限制：

以 GPT‑6 Astra 為核心，配備獨立雲端電腦
透過插件連接超過 4,000 個應用程式
支援 ChatGPT、Slack、Teams 及語音互動
可根據回饋學習偏好，持續推進工作
權限、操作檢視和審批機制仍由人員掌控

項目主頁

Categories: Agentic, OpenAI, 語音

NVIDIA LongLive 把長片生成推向即時互動

2026 年 9 月 30 日

NVIDIA 將三階段長片生成研究整合到同一個項目，涵蓋即時互動、量化推理及可重用蒸餾能力。

NVIDIA 開發團隊把長片生成帶入即時互動、低精度推理和跨模型重用場景。LongLive 屬於開源影片生成研究項目，處理長時間生成容易變慢、下游模型需要重複蒸餾，以及互動控制成本偏高等問題。

項目分成三代，並各自放在獨立目錄，附有程式碼、文件和模型權重。LongLive 1.0 聚焦即時互動長片生成；LongLive 2.0 以 NVFP4 量化和 sequence parallelism 加速訓練及服務；LongLive-Plug 則把 few-step、CFG 和 long-context 能力蒸餾成可重用 LoRA，讓同一模型家族的下游模型減少重新訓練。

LongLive 2.0 支援 T2V/I2V AR training、multi-shot 或 single-shot videos，以及 NVFP4 inference、NVFP4 KV Cache 和 TorchAO FP8 PTQ inference，取捨是需要配合量化及平行化基礎設施。

LongLive-Plug：一次蒸餾能力，再在同一 backbone family 的下游模型重用
LongLive 2.0：以 NVFP4、BF16 和 sequence parallelism 支援長片訓練及推理
LongLive 1.0：讓使用者輸入提示詞後即時觀看並逐步控制長片生成
DreamForge-World 0.1：加入 residual action pathway，面向低算力、即時可控 world modeling

研究展示包括互動示範、長片 rollout 和不同 backbone family 的配對例子，但提供資料未載有可直接比較的統一 benchmark 分數。具備 NVIDIA GPU、需要研究影片生成系統，或希望在 Wan2.1、Wan2.2、MiniMax-H3 等模型家族上重用蒸餾能力的團隊，較容易找到合適切入點；一般使用者則要先接受它偏研究項目，操作細節仍取決於所選目錄。

項目主頁 · GitHub · 模型

Categories: 開源, AI productions, 模型, 模型訓練, NVIDIA, Video, 提示詞, 語音, Dataset 數據集, MiniMax, LoRA

WorldLine 讓機械人先看見動作後果

2026 年 9 月 30 日

WorldLine 把機械人動作轉成影像及空間訊號，預測場景如何變化，再協助評估策略及規劃操作。

Repository image for Zhengsh123/WorldLine

機械人要搬動物件前，WorldLine 可以先在視覺模擬中預測動作會如何改變場景，減少每次都依賴實體試錯。它屬於面向機械人操作的世界模型及視覺模擬器，處理的是「控制指令如何造成可觀察結果」這個核心問題，而不是按照任務文字生成畫面。

WorldLine 先用超過10,000小時的無動作標註機械人影片學習機械人與物件的互動，再把末端執行器的位置、深度、方向及夾爪狀態投影到經校準的相機視角。這些 image-space actions 成為不同機械人之間的共同介面；另外超過2,000小時、涵蓋10多種 embodiments 的動作軌跡，負責把通用 dynamics 對應到個別控制方式。

WorldLine 把 action grounding 分開處理，較有利於跨機械人及跨鏡頭遷移，代價是需要校準相機、動作軌跡及失敗案例。模型以 block-autoregressive 方式因果 rollout，每個區塊用四步 denoising 生成，兼顧互動速度與預測細節，但不代表能取代真實環境驗證。

用於 policy evaluation、embodied planning 及實體操作前的預測
以 image-space action 統一不同機械人的視覺控制介面
透過 multi-view、failure-enriched training 及 relational regularization 強化互動敏感度
以 few-step distillation 減少 rollout 所需計算

研究團隊包括香港科技大學、Joy Future Academy、北京大學及香港中文大學。較適合研究機械人學習、視覺規劃及模擬器的團隊先按程式碼建立推理環境，再以不同 camera view、embodiment 和失敗動作測試預測穩定性；需要即時控制的人員則應同時量度延遲、動作偏差及真實機械人的遷移落差。

項目主頁 · GitHub

Categories: 開源, 香港中文大學, 香港科技大學, 北京大學, AI productions, 模型, 視覺模型, 世界模型, 模型訓練, Video, Image, 香港, Dataset 數據集

LEGO-Anything：由單張圖片生成可編輯 3D 世界

2026 年 9 月 30 日

由一張圖片開始，coding agent 會逐步寫程式、渲染和修正，產出可查詢及編輯的 Blender 3D 場景。

由一張 RGB 圖片開始，coding agent 會自行規劃、執行 Blender 程式、渲染結果，再按視覺檢查持續修正，將參考畫面轉成可編輯、可查詢及可匯出的 3D 世界。LEGO-Anything 同時涵蓋 agentic scene reconstruction 的框架、評測基準 LEGO-Bench，以及協助分析建構過程的 LEGO-Plugin。

項目處理的核心問題，是如何讓模型不只生成一張相似圖片，而是建立具備幾何結構、鏡頭和物件狀態的可執行場景。Agent Workspace 管理產物，Action Space 提供操作，Blender Code Structure 保存可修改的場景狀態，Scene Construction Workflow 則把參考解讀、程式生成、渲染和驗證串連起來。

LEGO-Bench 收錄來自104個場景的208張圖片，涵蓋8個環境、17個主題及443項資產，並以 Indoor、Outdoor 和 Easy 至 Hard 的物件集合測試不同難度。評分同時考慮 Blender 場景是否有效、可見表面幾何重建，以及重新渲染後的色彩吻合度；無效提交或未能完成評估的案例會取得零分。

目前公開結果顯示，GPT-6-astra 在室內及戶外分別取得53.4%及39.6%的 Overall 分數，高於其他參與比較的 coding agents；戶外場景在各難度層級都較難處理，而場景有效率仍未代表幾何和視覺細節已經高度吻合。對需要可修改 Blender 資產、可重現場景或研究 Computer-use agents 3D 操作能力的工作流，這套框架提供了較完整的測試方式。

由單張圖片生成可執行的 Blender 場景
透過寫程式、渲染和驗證逐步修正結果
同時評估場景有效性、幾何重建和外觀吻合度
LEGO-Bench 涵蓋室內、戶外及多級物件難度
戶外場景和高視覺保真度仍是主要限制

項目主頁

Categories: 開源, Agentic, Image, 框架, Vibe Coding, 3D, 編程, Dataset 數據集

ComfyUI-MiniMaxH3Mod：可重用參考模組

2026 年 9 月 30 日

你可以把它理解成 MiniMax H3 的參考素材管理層，把圖像、影片和聲音整理成可重用的 RefMod。

想在 ComfyUI 的 MiniMax H3 工作流中重用同一組人物、場景或聲音參考，不必每次重新編碼原素材。ComfyUI-MiniMaxH3Mod 是一個開源 custom node 項目，處理 RefMod 的建立、儲存、載入、組合及套用，讓圖像、影片和音訊參考可以保存成 .safetensors，再交給 Apply H3 RefMod 使用。它不會訓練 H3 權重，也不是 LoRA 或監督式概念學習工具，而是接入 H3 原生 reference-token 路徑的儲存與選擇層。

使用時需要將項目放入 custom_nodes 後重新啟動，並把標準 H3 video VAE、audio VAE 及原生 CONDITIONING 接到相應節點。項目已提供 Create H3 RefMod、Create H3 RefMod Master、Load H3 RefMods、Apply H3 RefMod 等節點；Master 可以一次處理視覺和音訊，save=False 則可只產生記憶體中的 bundle，不寫入檔案。ComfyUI Manager 可處理 safetensors、numpy 和 Pillow 等 Python 依賴，影片資料夾載入則可按需要加入 opencv-python 或 imageio。

支援圖像、影片、音訊 RefMod，並可在同一個 .safetensors bundle 儲存視覺與聲音。
encode 保留較多細節但消耗更多 reference tokens；training 先壓縮 latent，降低 token 成本，亦可能損失細節和動態。
Collect H3 RefMod Masks 可處理不同尺寸的 MASK，並按對應參考素材保留尺寸；上游裁走的像素則無法恢復。
Full Reference video sampling 會先決定因果 frame 數，避免 16 等限制直接截掉影片尾段。
Loader 和 Axis 採用按需增加的參考槽位，並可分開選擇 All、Visual 或 Audio。

它和單純把素材放在工作流內的做法不同，RefMod 會把編碼結果保存下來，之後重用時可避免重複處理來源檔案。壓縮模式適合控制 token 和生成成本，完整 encode 則較適合作為身份或細節比較的基線；兩者都不能保證只轉移指定屬性，身份、服裝、背景和構圖仍可能互相混合。項目支援最多八個參考槽位、子資料夾、外置磁碟及 extra_model_paths.yaml 登記的 RefMod 根目錄，Library 和 Config 亦能搜尋及檢視已保存內容。

可調整的 max_tokens、frame limit、視覺 budget policy 和 Refinement Steps，令項目較適合需要反覆測試參考組合的創作者、ComfyUI 工作流作者，以及要管理大量人物或場景素材的團隊。truncate 會削減畫面內容以符合 token 預算，error 則在超出預算時停止保存；這些選擇直接影響細節保留和工作流是否繼續。項目目前沒有提供可與原生完整 reference workflow 對齊的正式基準測試，Windows 是原先測試環境，Apple Silicon 只覆蓋部分預處理和 H3 VAE 檢查。

音訊支援仍是最大限制。項目可以保存及混合視覺、音訊參考，亦曾成功處理音樂參考，但目前測試未能完成 speaker-identity transfer，因此不能當作已驗證的 voice cloning 解決方案；它亦不會自動修正影音同步。API 和 node schema 仍在演變，節點名稱及輸入欄位可能隨版本調整，適合接受工作流需要維護、並願意自行測試參考強度與 token 取捨的使用者。

GitHub

Categories: 開源, ComfyUI, AI productions, 模型訓練, API, Video, Image, 影像處理, Audio, 工具, Content Creator, Clone, 庫, 語音, 音樂, 蘋果, MiniMax, LoRA

Diffusion Controller：讓模型更準確聽懂提示詞

2026 年 9 月 30 日

Diffusion Controller以輕量控制網絡改善提示詞對齊，同時保留原有影像質素與生成穩定性。

當影像模型明白你要一隻「戴太陽眼鏡的蜥蜴」，卻只生成蜥蜴，或勉強加入眼鏡後令面部變形，問題往往不在畫面是否逼真，而在提示詞要求與生成結果之間難以取得平衡。Google Research提出的 Diffusion Controller，正是針對這種提示詞對齊與影像質素互相牽制的情況而設計的輕量「steering damper」網絡。

Diffusion Controller可以接到包括 access-restricted、closed-source 模型在內的現有影像生成模型，無需改動基礎模型的核心結構，便能在生成過程中施加更精準的控制。它將原本由隨機噪聲逐步還原成影像的 denoising process，重新理解為一個連續、平滑的 control problem，讓控制訊號不必只在個別步驟中硬性修正結果。

改善文字提示與生成影像之間的 prompt alignment
以輕量 add-on network 控制現有模型，兼容 access-restricted、closed-source 模型
在提升指令符合度的同時，維持 baseline stability 和原有影像質素
將 inference-time guidance 與模型微調放入同一套分析框架
white-box 版本在所述測試中取得相對 baseline model 的 90% 勝率

過往做法通常分成兩條路線：一類是在 inference time 使用 classifier-free diffusion guidance，調整文字提示對生成過程的影響；另一類則透過 parameter-efficient adapters，例如 LoRA、reward-weighted regressions 或 policy gradients，對模型行為進行較重的微調。Diffusion Controller嘗試以統一的數學語言連接這些控制方式，減少工程師靠反覆試驗，在使用者偏好、提示詞要求和影像質素之間摸索的需要。

Google Research表示，Diffusion Controller的輕量版本表現優於用於配合人類偏好的業界標準方法；完全解鎖、可直接修改模型內部權重的 white-box 版本，則相對 baseline model 取得 90% 勝率。這些結果反映項目適合需要精準遵循文字描述、同時不希望破壞原有生成穩定性的影像工作流，但提供的內容未包括下載連結、安裝步驟或完整使用流程，讀者仍需等待論文或官方程式碼資料作進一步驗證。

項目主頁 · Paper

Categories: Google, Gemini, Image, 影像處理, 提示詞, 框架

OmniTaskonomy：令圖片生成圖片更準確

2026 年 9 月 30 日

OmniTaskonomy 以配對實驗檢驗 I2I 訓練能否改善 I2T 理解，並找出最有效的訓練次序與任務轉移關係。

I2I reconstructs the Jigsaw image, a dot moves from Visual Generation to Visual Understanding while changing color, and

同一個多模態模型既要生成圖片，又要讀懂圖片，兩種能力未必會自然互相提升。OmniTaskonomy 是一個研究型 benchmark 與資料集項目，透過 Image-to-Image（I2I）和 Image-to-Text（I2T）配對任務，測試視覺生成訓練何時能改善視覺理解。

項目沒有把生成與理解混成單一分數，而是比較六種訓練流程，包括只做 I2T、先做 I2I 再做 I2T（I2I → I2T），以及從一開始混合兩種目標。結果顯示，先以 I2I 更新與理解能力共用的權重，再進行 I2T 微調，通常比同步訓練或凍結共用權重更穩定；I2I 資料增加時，I2I → I2T 和 I2I → Mixed 的收益亦持續上升。

從 GitHub 儲存庫了解實驗流程，並配合 Hugging Face 上的 OmniTaskonomy 資料集重現配對任務。項目適合研究多模態模型訓練、視覺能力轉移及 curriculum learning 的團隊，但並非即裝即用的影像工具，重現結果仍要配合模型、訓練資源和原有設定。

幾個結果有助判斷它的研究價值：
– 定位與物件指向對 counting 的增益最大。
– 深度及 surface-normal prediction 可改善 metric 3D relation。
– 各種理解能力的 mean alignment 與 mean transfer 相關係數為 r = 0.795。
– 133 個 source–target pair 的相關係數降至 r = 0.529，反映任務之間的轉移並不一致。

Gradient alignment 主要集中在早期 pre-attention normalization layers，並與下游 transfer 呈正向關係。這讓 OmniTaskonomy 不只回答「生成能否幫助理解」，亦提供一套分析哪些生成任務值得加入訓練、哪些能力不應直接互相推論的方法。

項目主頁 · GitHub · 模型

Categories: 開源, Agentic, Image, 工具, 庫, Dataset 數據集

Page 1 of 161

1 2 3 … 161 Next »