InferNews

ActWorld 讓世界模型學懂互動

Share to X
Og image

ActWorld 是一個 Interactive World Model，目標是把「可四處觀看的世界」推進到「可以即時操作的世界」。以往不少世界模型主要支援移動、轉向、環視等導航動作，對場景中的物件互動支援有限；這個項目則加入中途操作物件的能力，例如拾取、搬運、放置，令同一次 rollout 不只是在場景中行走。

這個項目想處理兩個核心問題：一是缺少高質素的人與物件互動數據，二是模型容易忘記早前發生、但會影響之後物件狀態的關鍵畫面。為此，團隊建立了 100K interaction video dataset，並以 chain-of-thought reasoning 產生 per-chunk captions；同時提出 hierarchical action-aware memory 和 persistent memory bank，讓模型按互動重要性保留歷史資訊，減少 action-forgetting。

使用時，讀者可先從項目頁面的 Paper、Code、Video 和 Comparisons 了解能力範圍。從內容描述判斷，ActWorld 適合研究 Interactive World Model、Computer-use agents（CUAs）相關模擬環境、機械人互動、或需要長時序場景生成與控制的團隊參考。

  • 在單一模型內同時處理 long-horizon navigation 與 object interaction
  • 透過 100K interaction video dataset 補足互動數據不足
  • 用 hierarchical action-aware memory 保留較重要的互動歷史
  • 以 persistent memory bank 追蹤事件更新與物件身份

按頁面說明，實驗結果顯示它在不犧牲 viewpoint control 的情況下，interaction fidelity 明顯優於只做導航的 baseline。現階段公開資訊以研究展示為主，若想深入理解效果，最應留意 Comparisons 及論文中的評測設定與限制。

項目： https://interactwm.github.io/ActWorld/

Categories: 開源, 騰訊, Agentic, Video, AI productions, 多模態模型, 模型, 世界模型, Dataset 數據集

Dataset：EgoCS-400K 補足遊戲世界模型數據缺口

Share to X
EgoCS-400K dataset overview

現有做法多數依賴 captioned videos、機械人數據，或模擬器軌跡來訓練 World Models，但前者缺少可執行動作與可靠狀態，後者又常受成本、場景規模或真人互動不足限制。EgoCS-400K 就是針對這個缺口而設的 Dataset 數據集，用公開的 Counter-Strike / CS2 demo 重建第一身視角，將影片、控制輸入、遊戲狀態與語言描述同步整理。

這個項目最核心的價值，不只是「有很多影片」，而是把 replay-grounded 資料做到 tick-level telemetry 對齊。資料同時包含 keyboard/mouse inputs、atomic actions、protected action chains、DP-based temporal segments，以及 multi-grained video-language captions，令模型不只看到畫面，還能追蹤玩家當下做了甚麼、為何畫面會變。

官方資料顯示，它涵蓋超過 400,000 段 first-person videos、10,000 小時以上 gameplay、1,000 多場比賽、40,000 rounds、13 張地圖，規模相當大。它支援的任務亦很明確，包括 action-conditioned future prediction、state- and event-aware scene rollout、replay-grounded captioning，以及 agent egocentric action understanding。

想了解內容，可先用公開 viewer 直接查看樣本，再按需要處理影片；若要生成 VLM captions，才需要 API key。較適合研究 World Models、Gaming Agent、Computer-use agents（CUAs）相鄰方向、影片理解，或想研究人類決策與視角變化如何連動的開發者。

  • 類型屬於 Dataset 數據集，主要解決互動式 World Models 缺乏高質素「影片-動作-狀態-語言」對齊資料的問題
  • 舊範式依賴 web video、robotics data 或 simulator traces，各自欠缺狀態、規模或真人軌跡
  • 辨識度最高的設計，是 replay-grounded、tick-level telemetry 與多粒度標註放在同一條時間線
  • 適合做未來畫面預測、事件感知生成、第一身動作理解與 captioning 研究
  • 相關方向與模型包括 World Models、vision-language-action models、video generation models、Gaming Agent

如果你只想找一般遊戲影片數據，EgoCS-400K 可能顯得偏研究型；但若你在意動作如何驅動畫面與事件，這個項目的資料結構明顯比普通影片庫更有分析價值。它未必直接等於完整訓練方案，但作為高對齊、高時間解析度的基礎數據，定位相當清晰。

GitHub： https://github.com/EgoCS-400K/Dataset

Paper： https://arxiv.org/pdf/2606.18180

Categories: 開源, Agentic, API, Video, IDE, 動畫, 多模態模型, 庫, 模型訓練, Robotic, 世界模型, 香港城市大學, Dataset 數據集

SeeQ 讓 VLM 學識自己出視覺問題

Share to X
Cover Figure overview

現有 Vision-Language Models（VLMs）多數按「被動答題」範式訓練：人類或外部模型先提供問題，模型再學習回答。論文認為這種 fixed inputs 做法受制於靜態資料分佈，Visual Question Generation（VQG）亦容易卡在標註成本高、題目深度不足這兩個瓶頸，所以 SeeQ 提出 Self-Evolving Visual Questioner，用同一個 VLM 同時做 proposer 與 filter，自動從未標註圖片生產更難、更貼近畫面內容的問題。

這個項目屬於框架兼研究型工具，重點不是再做一個普通題庫，而是建立完整流水線：先生成 seed questions，再反覆改寫，提升 visual search、context 與 spatial reasoning 要求，之後再由模型自行過濾。作者同時加入 exploration diversity 控制，目標是避免訓練一路收窄，最後只剩單一風格題目。

如果你想試，較合理的做法是先準備圖片對應的 JSON 輸入，再分開看 generation 與 evaluation 兩部分輸出。倉庫內沒有附模型權重、數據集與快取，評測亦會用到 image-capable OpenAI evaluator 與 Qwen embedding models，所以較適合已經有 VLM 環境、想驗證自動出題流程的研究者或多模態團隊。

  • 以未標註圖片開始，自動生成、改寫、過濾視覺問題
  • 保留 Agentic evaluation，從 visual search、evidence coverage、context、spatial reasoning 評分
  • 另用 Qwen embedding models 檢查整體多樣性，不只看單題質素
  • 強調 zero external supervision，不依賴人工標註或 GPT-4V 這類外部 teacher models

創新點在於它不單止用 VLM 產生問題，還把「提問能力」當成可自我增強的訓練訊號，並且把 questioner 與 answerer 兩種模式一起考慮。按論文說法，這套方法在多個 backbone VLMs 上都能提升問題質素，亦把自動出題的難度邊界推高；同樣預算下，比直接用靜態來源資料訓練更有效，而模型的 answerer 能力亦未有明顯犧牲。

相關模型與元件方面，倉庫內容顯示生成流程可配合 Qwen2.5 3B 類型設定，評測會用 OpenAI 的可看圖評估器，以及 Qwen embedding models。若你關心多模態訓練、合成數據、或想建立能自己發問再自我改良的 Agentic workflow，SeeQ 的方法論比單純看分數更有參考價值。

GitHub： https://github.com/tianyi-lab/SeeQ

Paper： https://arxiv.org/pdf/2606.13929

Categories: 阿里巴巴, Qwen, OpenAI, Agentic, Image, 工具, AI productions, Embedding, IDE, Python, RAG, 多模態模型, 庫, 模型, 模型訓練, 視覺模型, 框架, Dataset 數據集

TVEdit：文字與點拖軌跡合一的圖片編輯項目

Share to X
TV-Edit Gradio demo

TVEdit 是一個圖像編輯項目，目標是解決「只靠文字講意思，或者只靠拖點講位置」都不夠準的問題。以往文字指令較易表達語意，但難控制空間；點拖軌跡可以指位置，卻容易令語意變得含糊，所以作者把兩者合併成 Text-Vision Co-Instructed Image Editing。

這項目的做法是用一個文本與視覺指令配對資料集來訓練，資料超過 23K 筆，來源與動態影片有關。再配合 TV-Edit 框架，把拖曳或點選等視覺指令轉成更有語意的控制表示，然後接到預訓練編輯骨幹上，例如 Qwen-Image-Edit。

它能同時處理「想改成什麼」與「要改到哪裡」，而不是只偏重其中一邊。作者另外建立了 TV-Edit-Bench，專門看語意忠實度、空間對齊同畫面一致性，這比一般只看最終效果的做法更能反映模型有沒有真正聽懂指令。

先載入 Qwen-Image-Edit，再配 TV-Edit 權重，之後在 Gradio 介面上上傳圖片、畫出軌跡、輸入文字指令，再調 CFG 同步數生成結果。若有加速 LoRA，步數可以大幅減少，適合想快速試驗互動式編輯的人。

  • 結合文字語意與點拖軌跡，令空間控制更細
  • 用 23K+ 配對資料補足跨模態指令訓練
  • TV-Edit-Bench 同時看語意、位置、畫面一致性
  • 目前已提供推理程式、模型權重同網頁示範
  • 適合做互動式圖片編輯、研究評測或模型整合

GitHub： https://github.com/PolyU-VCLab/TVEdit

Paper： https://arxiv.org/pdf/2606.16767

Categories: 開源, 阿里巴巴, Qwen, 香港理工大學, Agentic, MCP, Image, RAG, 影像模型, 影像處理, 模型, 模型訓練, 視覺模型, 框架

LoopCoder：只多跑一輪，成效反而更好

Share to X
Only Loop Once: gain–cost trade-off in Parallel Loop Transformers

LoopCoder-v2 是一個基於 Parallel Loop Transformers（PLT）的程式碼模型系列，目標是解決「推理步數愈多，成本與表現未必同步上升」的問題。傳統 Looped Transformers 會透過重複共享區塊去增加 latent computation，但每多一輪都會拉高延遲和 KV-cache 記憶體；PLT 則用 Cross-Loop Position Offsets（CLP）和 Shared-KV Gated Sliding-Window Attention（G-SWA）把成本壓低，讓迴圈數變成可以調整的設計參數。

這個項目直接拆解「多跑幾輪到底值不值得」。作者用 gain–cost 角度分析 loop count：額外一輪可以帶來表示更新，但 CLP 也會引入位置不匹配的成本；兩邊一對比，就能解釋為何 LoopCoder-v2 在很多情況下是兩輪最好，而不是愈多愈好。這種分析方式比單看分數更有參考價值，因為它把效果升降和內部機制連在一起。

從結果看，LoopCoder-v2 的 7B 版本在多個程式相關測試都有明顯改善，尤其是 SWE-bench Verified 由 43.0 升到 64.4，Multi-SWE 由 14.0 升到 31.0，Terminal-Bench 亦有提升。相反，三輪或四輪時分數明顯回落，表示這個項目不是單純靠「加更多計算」換表現，而是存在一個較清晰的最佳點。作者亦用 hidden-state dynamics、attention evolution 和 output distribution shift 去佐證第二輪帶來主要增益，之後的輪次多數只會增加冗餘。

如果你想找的是可直接跑的模型，這個項目提供了 Hugging Face 上的 7B 權重，能透過 Transformers 載入後做文本生成或程式碼任務測試。適合關注 code generation、code reasoning、agentic software engineering、tool-use 的人，也適合想研究 test-time compute scaling、模型推理效率，或想比較 loop count 對表現影響的讀者。

  • 主要類型是模型研究項目，同時包含評測與推理分析
  • 核心結論是：兩輪通常是最佳平衡點，三輪以上可能反而拖低表現
  • CLP 令平行迴圈可行，G-SWA 則把 KV-cache 成本維持在近乎固定水平
  • 7B 版本在 SWE-bench Verified、Multi-SWE、Terminal-Bench、BFCL 等測試都有較完整結果
  • 適合用來分析程式碼模型、代理式任務，以及測試階段算力分配

GitHub： https://github.com/CSJianYang/LoopCoder

Paper： https://arxiv.org/pdf/2606.18023

Categories: 開源, Agentic, 軟件, 工具, AI productions, Python, RAG, 模型, 編程, 框架

OKF：令 AI 與人都看得懂的知識庫

Share to X
Og image

Google Cloud 介紹的 Open Knowledge Format（OKF），核心目標不是再做一個新的知識平台，而是訂立一種開放格式，讓團隊把內部知識整理成 AI 系統與人都能共同使用的內容。文章指出，愈來愈多 foundation models 被用來建立 agentic systems，但模型能否給出可靠答案，往往取決於是否拿到正確而完整的背景資料，而這些資料在企業內通常散落於多個位置。

這個項目解決資料共享與知識整理長期碎片化的問題。例如資料表結構、指標定義、事故處理流程、API 停用通知，常分佈在 metadata catalog、wiki、共用硬碟、程式註解，甚至只是少數資深工程師的腦海中。當 AI agent 要回答業務或技術問題時，往往要從彼此不兼容的系統重新拼湊脈絡，令每個團隊都要重複處理同一類整合工作。

OKF 的做法相當務實。OKF v0.1 以 markdown 檔案目錄作為知識載體，配合 YAML frontmatter 存放少量可查詢欄位，例如 type、title、description、resource、tags 和 timestamp。這代表內容本身可以在一般編輯器閱讀、可放進 GitHub、可由搜尋工具索引，也可以像普通檔案一樣打包、放進 git repository 或掛載到不同檔案系統，不需要額外 runtime、SDK 或複雜壓縮機制。

Google's OKF - The New Way to Structure Your Knowledge for Agents

Google 把這個方向描述為把近年常見的「LLM-wiki pattern」正式化。若團隊本身已經在用 Obsidian、Notion、Hugo，或以 AGENTS.md、CLAUDE.md 這類慣例檔案協助 agent 工作，理解 OKF 會較容易，因為它保留了 markdown、frontmatter、交叉連結這些熟悉做法，再補上最少但重要的共通規則。重點在於不同來源建立的知識庫，之後有機會被不同 agent 或工具直接讀取，而不用逐次重做轉換。

  • 以開放格式整理知識，減少被單一供應商工具鎖定
  • 採用 markdown 加 YAML frontmatter，門檻較低，方便版本管理
  • 適合把資料定義、流程文件、系統脈絡交給 agent 與團隊共用
  • 重點不是新增服務，而是建立可攜、可互通的知識表示方式

這個項目特別適合已經開始建立 AI agent、資料團隊知識庫或內部文件流程的組織。對資料分析、資料平台、工程團隊來說，它的價值在於把原本零散且難搬移的內容，變成較容易維護和重用的知識資產。文章未提供量化性能數據或基準測試，因此現階段較適合把 OKF 看成一個標準化方向：先用簡單文件結構統一知識，再逐步改善 AI 系統取得脈絡的能力。

項目： https://cloud.google.com/blog/products/data-analytics/how-the-open-knowledge-format-can-improve-data-sharing/

Categories: Google, Agentic

Ponytail：幫 AI Agent 減少大量的程式碼

Share to X
Ponytail, the lazy senior dev

Ponytail 是一個針對 AI Agent 的工具型項目，核心作用不是取代模型，而是替模型加上一套固定判斷規則，令它在寫程式前先問自己：這段東西是否真的需要存在、標準函式庫能否處理、平台本身有沒有現成功能。它想解決的問題很直接，就是不少 AI Agent 會把簡單任務寫得太重，順手加框架、包裝層、額外抽象，最後程式碼變多、回應變慢，成本也上升。

這個項目已相當成熟。它把「少寫不是偷懶，而是保留必要部分」變成一條清晰階梯：先跳過不需要的東西，再優先用 stdlib、原生平台功能、已安裝依賴，最後才自己寫最少可行實作。這種設計對 AI Agent 特別有效，因為模型常見問題不是完全不懂，而是太願意補很多你未必需要的東西。Ponytail 等於把資深工程師那種「先刪再寫」的習慣，包成可重複套用的規則。

如果你想試它，先找幾類容易被模型寫得過火的小任務，例如日期輸入、debounce、rate limiter、簡單驗證或 CSV 處理。倉庫資料顯示，它支援 Claude Code、Codex、GitHub Copilot CLI、Gemini CLI、OpenCode、OpenClaw 等多種環境，亦即它不是綁死單一平台，而是瞄準「那些 AI Agent」的日常編碼流程。對於經常要用 Agent 產生前端小功能、工具腳本、日常後端邏輯的人，這類規則比再換一個新模型更實際。

在 Claude API 的基準測試中，官方列出每項任務程式碼可減少 80% 至 94%，延遲快 3 至 6 倍，成本下降 42% 至 75%。不過這些結果有清楚前提，只能代表特定模型與提示方式下的中位數表現，並非所有模型都一定受惠；倉庫亦明言像 GPT-5.5 這類較簡潔的推理模型，規則注入與思考步驟本身可能抵消節省效果。這種寫法反而增加可信度，因為它沒有把 benchmark 包裝成放諸四海皆準的勝利宣言。

  • 重點不是生成更多程式，而是限制 AI Agent 只寫任務真正需要的部分
  • 支援多個 Agent 宿主，包括 Claude Code、Codex、Gemini CLI、OpenClaw 等
  • 提供 /ponytail-review、/ponytail-audit、/ponytail-debt 等指令，方便檢查過度工程化
  • benchmark 數據亮眼，但倉庫已提醒不同模型、提示長度與回合數會影響結果
  • 適合經常叫 AI Agent 寫工具碼、介面小功能、重複邏輯的人

Ponytail 的創新在於它把工程判斷流程產品化，讓 AI Agent 先經過一道「有沒有更省、更原生、更少依賴」的篩選。這令它比較像一個行為約束層，而不是新模型或框架。相關模型與環境方面，倉庫內容直接提到 Claude 的 Haiku、Sonnet、Opus，也提到 GPT-5.5，並覆蓋 Codex、Gemini CLI、Antigravity CLI、GitHub Copilot CLI 等代理工具鏈。若你想要的不是更花巧的生成能力，而是更穩定地避免 AI Agent 過度設計，這個項目有很明確的價值；若你的工作本身需要大量自訂架構與長鏈依賴，它未必會永遠選出你最喜歡的答案，但至少會迫使模型先證明「為何需要寫那麼多」。

GitHub： https://github.com/DietrichGebert/ponytail

Categories: 開源, 微軟, Gemini, OpenAI, Agentic, API, 工具, AI productions, IDE, 庫, 模型, Anthropic, OpenClaw, 框架, Skill 技能

Memento：把長片段角色一致性補回來

Share to X
Teaser

Memento 是一個影片生成框架，重點解決長篇、多鏡頭故事影片中角色外觀容易前後不一致的問題。傳統做法多半只顧下一段鏡頭看起來合理，Memento 則把「能否從記憶重建角色」當成身份是否被保留的檢查方式。

它的做法是把全局故事描述、每個 shot 的文字提示，連同歷史記憶一起送入生成流程，逐鏡頭自回歸地產生影片。使用時可準備對應格式的 JSON 故事腳本，再配合提供的權重與基礎模型做推理；項目也支援訓練與輸出完整影片。

GitHub： https://github.com/ernie-research/Memento

項目： https://ernie-research.github.io/Memento/

Categories: 開源, Agentic, Video, 庫, 模型, 模型訓練, 視頻模型, 框架, 百度

PhoneHarness：重新量度手機代理能力

Share to X
PhoneHarness CLI status demo

PhoneHarness 是一個混合動作的手機代理評測框架與基準，解決只靠 GUI 點按去評分、卻量不到真實副作用的問題。論文指出，手機任務往往需要在 GUI、CLI 與 structured tools 之間切換，單看最後畫面會漏掉很多關鍵步驟。

它的做法是把行動路由、GUI 委派和可追蹤執行記錄放進同一個流程。當任務有明確可執行路徑時，系統會優先走 CLI 或 MCP 完成；只有必要時才交由 GUI worker 透過截圖互動，令評測更貼近真正手機工作流。

這個項目的新意在於把「能否完成」和「是否留下可驗證證據」綁在一起。JSONL traces 和 HTML viewer 令失敗可以被拆成模型推理、GUI 對齊、環境、工具或 verifier 不一致幾類，方便找出問題來源，而不是只見到一個分數。

論文中的 PhoneHarness Bench 在 annotated evaluation split 上取得 75.0% pass rate，較最強的非 PhoneHarness 設定高 12.9 個百分點。這表示它不只是測試介面操作，還在測試代理怎樣選擇動作面，對做手機自動化、裝置測試、或需要可審計流程的團隊都幾有參考價值。

  • 混合支援 GUI、CLI、MCP tools，適合手機工作流評測
  • 優先 deterministic 路由，減少不必要的畫面操作
  • 可追蹤 traces，方便定位錯誤來源
  • 適合研究 phone agents、裝置自動化與安全副作用檢查

相關模型／基準可一併留意：PhoneHarness、PhoneHarness Bench、AndroidWorld、AppAgent、Mobile-Agent-v2、MobileAgentBench、AndroidLab。

GitHub： https://github.com/PhoneHarness/PhoneHarness

項目： https://phoneharness.github.io/

Categories: 開源, Agentic, MCP, 軟件, 工具, 安全, 模型, 框架

JoyAI-VL-Interaction 把影像助手變主動

Share to X
JoyAI-VL-Interaction overview

現時多數視覺語言模型仍然沿用 turn-based 問答範式：用戶問一句，模型答一句；就算放進視像通話或直播介面，底層仍是被動回應。JoyAI-VL-Interaction 直接挑戰這個做法，改成持續觀看、按秒判斷要沉默、回應，還是把難題交給背景模型處理，目標是把 VLM 從「被問先答」推向即時互動。

這是一個多模態模型加可部署系統項目，想解決的不是普通問答，而是「畫面中的關鍵一刻不會等人發問」這個問題。技術報告提到它是 8B vision-first 模型，支援 real-time video-language interaction，並配合 time-aligned interaction data、training recipe 與完整系統，重點放在時間感、主動觸發與持續在線。

如果你想理解它是否適合自己，最容易的測試場景是把 webcam、直播畫面或監控串流接入，觀察它會否在有事件時主動開口，而不是每次都等指令。這種模式較適合直播助理、居家提醒、遠端看護、商務示範，甚至要一邊看影像一邊調用 API 或 agent 的流程。

  • 核心改動是由問答式互動，轉向 watch-and-do 式互動
  • 模型每秒自行決定沉默、回應或 delegation
  • 系統可接駁 ASR、TTS、memory、API 與其他 agent
  • 報告稱可長時間處理連續影片，延遲維持在 sub-second
  • 人工評分比較中，對 Doubao 與 Gemini 的質量與時機掌握都有明顯優勢

創新位不只在模型本身，也在整個開放堆疊一起釋出：模型、數據、訓練方法與部署系統放在同一個項目脈絡，方便研究者與開發者沿原路線延伸。相關模型與組件包括背景大模型、API、agent，以及文中對比的 Doubao、Gemini；若完整開源內容如期提供，這個項目會對即時多模態互動研究有相當高參考價值。

GitHub： https://github.com/jd-opensource/JoyAI-VL-Interaction

項目：https://joyai-vl-video-future-academy-jd.github.io/JoyAI-VL-Interaction/

Categories: 開源, 字節跳動, Gemini, OpenAI, 文字轉語音, Agentic, API, Video, Image, 工具, AI productions, IDE, 多模態模型, 模型, 模型訓練, 視頻模型, 語音
Page 5 of 14
1 … 3 4 5 6 7 … 14