市面上的 LLM 智能體（LLM agents）排行榜大多只看模型本身的強弱，但 OpenSkillEval 卻把焦點放在技能（skill）身上，問一個很實際的問題：那些由社群熱心作者打包出來的技能，到底有沒有讓智能體的成品變得更好？為了回答這個問題，這個項目設計了一套評測流程，固定同一批任務、同一個評審模型，反覆比較「裝上技能」與「完全不裝技能」兩種情況的差異。

整套測試涵蓋 677 個案例，分屬商業、科學、健康、工程與創意五大場景，並對應五類日常常用的產出物：資料視覺化圖表、海報、簡報、分析報告，以及多頁網站。這樣的分佈能貼近真實使用智能體的場景，而不是只跑單一類型的乾淨考題。

更值得留意的是，這個項目同時記錄品質分數與成本資料，包括提示詞、生成、回快取的 token 數，以及實際耗時，方便讀者直接換算每一個技能值多少錢。從目前釋出的榜單來看，頭部模型之間的品質差距只有零點零幾分，但成本差距卻可以拉到 25 倍，凸顯「選模型」和「選技能」對整體花費的影響遠比想像中大。

論文亦點出多個值得技能作者參考的現象：熱門下載的技能未必穩定勝過無技能基準，而技能帶來的增益高度取決於底層模型與智能體框架的搭配方式。

重點摘要：

• 固定任務、變動技能：以對照方式隔離技能本身的真實貢獻。
• 五類任務、677 個案例：涵蓋圖表、海報、簡報、報告、網頁設計等常見產出。
• 品質與成本並列：同時記錄 token 與耗時，方便換算性價比。
• 適合技能作者、智能體開發者，以及需要評估部署成本的團隊。
• 相關模型包括 Claude Opus 4.6、GPT-5.5 與 Claude Sonnet 4.6 等前沿選擇。

GitHub： https://github.com/ALEX-nlp/OpenSkillEval

項目： https://yingjiahao14.github.io/OpenSkillEval-Web/

minWM 的定位很清楚：它不是再提供一個新模型，而是把建立 video world model 的整條流程拆開，讓人由 bidirectional T2V（Text-to-Video）或 TI2V（Text-and-Image-to-Video）基礎模型，一步步轉成 action-conditioned video world model。對剛接觸這個領域的人來說，這種完整路線比只放權重或單段程式碼更有幫助。

這項目重點不是「裝完即用」，而是按它提供的資料處理、訓練、蒸餾與推理流程逐段走。項目公開了 data → training → inference 的全流程，並提供 example data、runnable scripts、Claude Skills 與新手知識整理，方便你先跟一次標準流程，再按自己需要改 backbone、資料分佈或控制方式。

它要解決的問題，在於高質影片生成模型未必等同可互動的 world model。要做到低延遲、可因果 rollout、可回應鏡頭軌跡等操作，背後需要 camera control、autoregressive training、few-step distillation 及 streaming inference 等整套機制；minWM 正是把這些環節模組化，並用 Causal Forcing、Causal Forcing++、Teacher Forcing 與 asymmetric DMD 串連起來。

• 支援 4-step DMD inference，並提到 multi-GPU sequence parallelism
• 可用 pose strings 或 JSON 檔控制 camera trajectory
• 提供 debug-world-model，整理 loss NaN、jitter、camera drift 等常見失敗模式
• 提供 integrate-new-backbone，示範怎樣接入新的 video DiT
• 參考 backbone 包括 Wan2.1-T2V-1.3B、HY1.5-TI2V-8B，亦提到 HY Action2V、HY TI2V、Wan Action2V

項目的新意在於它同時處理「怎樣訓練」與「怎樣改造」。除了支援不同 backbone 與 condition injection 方式，也把團隊累積的排錯經驗與 Claude 協作流程寫進項目，令研究者或工程人員不只看到結果，還能理解常見錯誤從哪裡出現。

它的目標是 real-time interactive video world models，並附有對 camera trajectory quality、controllability training steps、minimal batch-size requirements 的實驗分析。不過公開資訊較偏向框架與流程，若你想比較單一模型跑分，這個項目更適合當作建立、重現及擴展 World Model 的工作底座。

GitHub： https://github.com/shengshu-ai/minWM

OmniRetrieval 想處理的，是資料散落在不同系統時的查詢麻煩。一般檢索工具多數只懂一種來源，但這個項目會先理解自然語言問題，再挑選合適知識來源，為各來源生成對應查詢，最後合併結果。

使用這個項目時，核心流程分成 route、generate、execute、select 四步：先選來源，再寫出來源原生查詢，之後執行，最後從多份結果中挑出較合適的證據。對非研究用途讀者來說，可把它理解成一個「跨系統問答協調層」，放在文字語料、SQL、SPARQL、Cypher 之上。

它的重點不在把所有資料硬轉成同一格式，而是保留各種來源原本的表達能力。這種做法能保住關聯式資料庫的 schema、RDF knowledge graph 的 ontology，以及 property graph 的圖結構查詢能力，避免統一格式後反而損失資訊。

• 支援四類來源：free-form text、SQL、SPARQL、Cypher
• 基準涵蓋 13 個資料集、309 個 distinct knowledge bases
• 可量度 source selection accuracy，以及 query formulation 的 exact match 與 token-level F1
• 提供 LLM provider 選擇，文中可見 openai 與本地 vllm 設定
• 相關資料集包括 BEIR、Spider、BIRD、LC-QuAD 2.0、QALD-10、SimpleQuestions、Text2Cypher

表現方面，來源資料指出 OmniRetrieval 在跨來源基準上超越 single-source baselines，但不同模型、資料預處理和外部執行環境都會影響結果。從項目結構看，它較適合研究 heterogeneous knowledge retrieval、企業內多資料源問答，或想測試 Large Language Model 如何生成 SQL、SPARQL、Cypher 的開發者。至於模型，項目至少提到 openai 預設骨幹與可本地運行的 vllm，示例亦出現 Qwen/Qwen3.5-4B。

GitHub： https://github.com/JinheonBaek/OmniRetrieval

UI-KOBE 是一個面向手機圖形介面代理的項目，核心做法是先探索 Android app，再把畫面與操作路徑整理成狀態轉移圖。對非研究背景的讀者來說，可以把它理解成先替代理畫好地圖，之後代理就不用每一步都盲撞。

動手使用這個項目，需要先備好 Python 3.10、uv、Android SDK、adb、emulator，以及已安裝目標 app 的 Android Virtual Device，另外還要提供 VLM 服務憑證。它依賴 AITK，並可把產生的圖拿去配合 AITK 或 Android World 使用，所以較適合已經有 Android 自動化或代理測試流程的人。

這個項目解決的問題很明確：手機代理在 app 內工作時，容易因畫面變化、按鈕位置或流程分支而迷路。UI-KOBE 會先開啟 app、觀察畫面、選擇探索動作，再記錄結果；每個 app 狀態成為圖節點，能把狀態改變的操作變成邊，之後執行階段可先匹配當前畫面，再從附近路徑選下一步，必要時也可用 free-form fallback action 補位。

• 先建立 UI knowledge graph，再交給下游代理導航
• 可接到 AITK 與 Android World 代理流程
• 依靠 state-transition graphs 減少盲目點擊與重複探索
• 內含 explore、audit_graph、plot_graph 等腳本，方便檢查圖內容

從設計看，UI-KOBE 的創新點不在單一模型，而在把探索與執行拆成兩段：先累積 app 結構知識，再於 runtime 重用。儲存庫亦提到 UI-KOBE v2 runtime 會載入圖、比對當前畫面節點，再根據圖邊決策；這種做法在多步驟 app 任務中，理論上比純即時決策更穩。

就用途而言，這個項目很適合研究 Computer-use agents（CUAs）、mobile GUI agents、Android 任務代理。

GitHub： https://github.com/YuxiangChai/UI-KOBE

AsyncTool 是一個基準測試項目，重點不在教模型怎樣調用工具，而是檢查它在多個任務同時進行、而 Function Calling 回應又有延遲時，會否亂了節奏。一般工具使用測試多數假設結果即時返回，但這個項目刻意加入等待時間，看看代理能否先處理其他不相依的步驟。

AsyncTool 主要是透過儲存庫內的 runner 與評估腳本，將模型接到模擬工具環境，再比較它在同步與非同步情境下的表現。同時可配合 OpenRouter API 的 deepseek/deepseek-chat-v3.1:free，亦可接本地 vLLM endpoint 上的 Qwen/Qwen2.5-7B-Instruct，對想測試不同部署方式的人算是方便。

AsyncTool 把「等工具結果時應否轉做別的事」變成可量化問題。它不單看工具有沒有調對，還會檢查代理是否記得任務狀態、能否遵守步驟依賴、何時切換任務，以及最後能否完整完成整個流程。

• 核心焦點是 asynchronous tool calling，不是假設工具即時回應
• 評分分成 step-level、sub-task-level、task-level 三層
• 會觀察 task switching 時機，而非只計切換次數
• 內含 benchmark data、tool executors、evaluation scripts

項目顯示不少模型在同步設定下尚可，但遇上非同步延遲後，成功率會明顯下跌。這反映問題未必在於模型不懂用工具，而是它未必擅長長時間追蹤依賴關係和維持多項目狀態。

這項目適合研究 LLM-based agents、agentic workflow、工具調用編排的人，也適合想替自家代理流程做壓力測試的團隊。若你關心的不是單一步驟答對，而是代理在繁忙環境下能否穩定完成工作，AsyncTool 的測試角度相當有參考價值。

項目由中國科學技術大學及多倫多大學合作

GitHub： https://github.com/StoKou/repo-asynctool