ComfyUI_MiniMaxH3_Director:一次過生成多段影片的導演台

想做長片、多段生成又唔想逐段接節點,這個項目把 MiniMax H3 的分鏡、取樣和輸出收在同一個 ComfyUI 工作流核心。

MiniMaxH3Director 工作流截图

做長影片時,最麻煩往往唔係單段生成,而係分鏡、續接、音畫輸出要分開處理。AIMixer/ComfyUI_MiniMaxH3_Director 針對的正是這個卡位:它屬於 ComfyUI 的影片生成節點插件,將 MiniMax H3 的多段規劃、條件編碼、採樣解碼和匯出合併成一個導演台,讓長視頻與多段音視頻生成流程集中管理。

它的價值不只在於把功能堆在一起,而是把幾種常見工作流放進同一個操作面。無論是 t2v、i2v、fl2v、r2v、v2v 還是 rv2v,都可沿用同一套時間軸邏輯;當中首尾幀、參考素材組、源片改寫和選擇性重跑都已經整理好,對需要反覆改段落、補鏡頭或保留原聲的創作者會實用得多。

安裝方式也算直接,前提是 ComfyUI 要升級到 v0.30.0 或以上,並已具備官方 MiniMax H3 支援。之後可用 ComfyUI Manager 透過 Git URL 安裝,或手動放進 custom_nodes,再按需要補上 scenedetectopencv-python-headlessimageio-ffmpeg 這些依賴;模型權重與示例工作流則需另外下載。要留意的是,CLIP Loader 的 type 必須設為 minimax,而 fl2va / ref2va UNET 亦要按任務類型配對。

跟一般把多個節點逐個串起來的做法相比,這個項目明顯偏向把影片導演流程封裝成一個較完整的工作台,代價是你仍然要跟官方 MiniMax H3 節點規格保持一致,並理解不同模式背後用的是 MiniMaxH3ImageToVideoMiniMaxH3ReferenceToVideoMiniMaxH3SigmaShiftKSampler 與 AV 分離解碼鏈路。重點放在長片分段銜接、段間運動延續與原生立體聲輸出,較適合已經在 ComfyUI 內做影片生成、希望減少手動接線和重複操作的團隊。

  • 把多段時間軸、生成、解碼、匯出收進單一節點
  • 支援 t2v、i2v、fl2v、r2v、v2v、rv2v 多種模式
  • 可做選擇性重跑,未勾選片段可用快取或原片填補
  • 依賴官方 MiniMax H3 節點,環境版本與模型配對要設好
  • 原生輸出立體聲音頻,適合長片與多段音視頻工作流

GitHub

Categories: 開源, ComfyUI, MiniMax

MiniMax H3 人像寫實 LoRA,強化近鏡表情與電影感

基於 MiniMax H3 的人像寫實 LoRA,重點唔係加花巧風格,而係令面部、皮膚同鏡頭動態更自然可信。

Og image

近鏡人像、多人同框對話、手部動作呢類鏡頭,最容易暴露影片生成模型嘅細節破綻。呢個 Hugging Face 項目明確係基於 MiniMaxAI/MiniMax-H3 嘅 LoRA adapter,針對真人角色畫面再微調,重點放喺面部穩定度、皮膚質感、微表情同帶少少手持感嘅電影式運鏡,亦保留 MiniMax H3 原生同步音訊能力。

頁面提供嘅核心資訊相當集中:它屬於 text-to-video,授權採用 minimax-h3-community-license,主要檔案是 h3-realism-people-t2v.safetensors。使用方法唔複雜,要先喺 prompt 開頭加入 trigger word r34l1sm,再透過 fal 的 MiniMax H3 LoRA 端點掛載,範例 scale 係 1.0;想保留多啲 base model 原本味道,可以降到 0.6 至 0.8。

同類 LoRA 最大分別,往往唔係畫面變得幾誇張,而係同一個 prompt、同一個 seed 之下,能否穩定改善人物可信度。呢個項目用 before/after 方式展示 19 組對照,強調唯一變數係 adapter 本身,連 trigger word 兩邊都有加,目的係證明提升主要來自微調權重,而唔係提示詞技巧。頁面亦講明它係前作 MiniMax-H3-Realism-LoRA 嘅後繼版本,並且改用更大、更加聚焦人物題材嘅資料集重新訓練。

  • 基礎模型:MiniMaxAI/MiniMax-H3,關係標記為 adapter
  • 主要用途:強化寫實人物、近鏡面部、群眾、手部與紀錄片感鏡頭
  • 主要檔案:h3-realism-people-t2v.safetensors
  • 推薦控制:trigger word r34l1sm,LoRA scale 以 1.0 為預設,可降至 0.6-0.8

要留意,項目本質上係影片生成用嘅 LoRA,唔係可直接本地量化部署嘅通用文字模型。換句話講,它嘅價值更接近一個針對 MiniMax H3 補強人物鏡頭表現嘅專用適配器,而唔係完整獨立模型;使用場景亦明顯偏向 fal 平台上的 text-to-video 工作流。

模型

Categories: 開源, AI productions, 視頻模型, Video, Audio, MiniMax

WeClawArena:當多個 AI Agent 共用工作流,誰來守住邊界

這個項目把多個個人 AI Agent 放在同一個沙盒裡合作做任務,再刻意注入攻擊,檢視它們會否洩密或越權。它想回答的是:當 Agent 開始互相呼叫,安全性該怎麼量度。

WeClawArena and its bargaining, bidding, travel, SWE-Workspace, clinical, and trading domains

當 AI Agent 不再是單兵作戰,而是要在共享任務裡交換訊息、互相呼叫工具,真正的風險往往不在模型本身,而在邊界有沒有人守。WeClawArena 是一個開源基準與可審計的運行沙盒,它模擬每個「人類擁有者」各自帶著一個 Agent、私有資源、角色專屬工具與本地規則,再讓這些 Agent 一起完成跨擁有者的任務。沙盒會全程記錄訊息、工具呼叫、資源操作與治理決策,方便事後追查誰在什麼時候越了界。

與一般針對單一 Agent 的安全測試不同,這個項目刻意把「協作失敗」與「攻擊成功」拆開評估。它在六個領域共 124 個基礎任務、620 個變體上,加入無攻擊組作對照,並針對協作、安全、私隱、治理四類攻擊條件各自打分,得出任務成功率(TSR)與攻擊成功率(ASR)兩組指標。Bargaining、Bidding、Travel、SWE-Workspace、Clinical、Trading 這幾個場景覆蓋了採購談判、軟件工程協作、臨床團隊、投資俱樂部投票等高利害情境。

對從事 Agent 安全研究、紅隊測試,或要部署多 Agent 協作流程的團隊,這套沙盒提供了一個可重現、可審計的環境。從 README 與 HF Papers 頁面可見,作者 Prince Zizhuang Wang 等人已把論文、數據集與 v2.0.0 版本代碼同步公開,採用 Apache-2.0 授權代碼、CC BY-NC 4.0 授權數據。

重點摘要:

  • 邊界為核心:每個 Agent 只看得到自己擁有者的資源與工具,跨邊界行為會被記錄與計分。
  • 雙軌評估:任務成功率(TSR)與攻擊成功率(ASR)分開計算,避免「任務完成」掩蓋「已被入侵」。
  • 四類攻擊條件:協作、安全、私隱、治理各有一組匹配變體,可針對性分析 Agent 弱點。
  • 六個領域 620 變體:涵蓋商業談判、SWE 流程、臨床、投資等高風險協作情境。
  • 可審計沙盒:peer 訊息、工具呼叫、決策路徑都有跡可循,方便事後歸因。

項目主頁 · GitHub

Categories: 開源, Agentic, 安全, Skill 技能

ConCor-1:一句標註都唔使畀,自動搵出圖文對應

ConCor-1 將視覺語言定位反轉成雙向概念對應,唔使預先指明想搵乜字句,畀一張圖同一段文字就會自動判定邊啲文字對應邊個物件。

Bidirectional concept correspondence: a caption, a referring expression and a category list all produce the same output

以往做視覺語言定位,多數流程都要你先講明想搵邊句字,模型再喺圖入面指出對應區域。ConCor-1 索性反轉呢個做法:畀一張圖同一段文字,無論係完整描述、指代表達,定係一列類別名,模型都會自己判斷邊段文字同圖入面邊個物件對得上,然後一次過畀齊文字遮罩、實例遮罩同對應分數。研究團隊由華盛頓大學、Allen Institute for AI 同 Meta FAIR 組成,模型基於預訓練視覺語言模型,再加上一組可學習嘅 bridge tokens 嚟代表候選對應。

呢種設計最大嘅實用價值,係省卻前置標註嘅工序。當你手上得一段長 caption 或者一大串類別名,傳統方法往往要逐句拆開再分批餵入,ConCor-1 直接當作一次對應預測處理,文字分割、影像分割、跨模態對齊三件事一齊做。佢將 phrase grounding、referring expression 同 open-vocabulary detection 收納成同一格式,等訓練同評測可以用統一數據集比較。

ConCor-1 喺長 caption 數據集上將 correspondence F1 提升 48%,喺零樣本 LVIS、即用大類別清單當文字輸入嘅場景亦提升 29%。Hugging Face 上已有模型權重、數據、Space Demo,源代碼以 Apache 2.0 發佈。對做細粒度理解、自動化標註,或者想整合長描述入視覺流程嘅團隊,呢個框架值得留意;想自行重現訓練嘅人就要再等等,現階段主要提供推論程式碼同評測即將推出。

重點摘要

  • 雙向概念對應:毋須預先指明文字,直接輸出文字遮罩、實例遮罩同對應分數
  • 統一格式:將 phrase grounding、referring expression、open-vocabulary detection 收成單一預測任務
  • 基於 bridge tokens:喺預訓練視覺語言模型上加可學習 token 代表候選對應
  • 顯著提升:長 caption F1 提升 48%,零樣本 LVIS F1 提升 29%
  • 開源配套:模型權重、數據、Space Demo 同推論程式碼已於 Hugging Face 同 GitHub 公開

適合需要從圖文配對中抽取結構化對應、做自動化標註、或研究視覺語言定位框架嘅讀者。ConCor-1 將文字分割、影像分割同跨模態對齊壓成單一任務,特別適合處理長描述或大類別清單等場景。

項目主頁 · GitHub · 模型

Categories: 開源, 模型, 視覺模型, 多模態模型, Meta, Dataset 數據集

RynnValue 用秒估計機械人完成時間

它不只判斷機械人有冇做對,仲會估計距離完成仲差幾多秒。呢種時間式價值訊號,令強化學習獎勵設計變得直接得多。

RynnValue overview

機械人操作最難的不只是識別動作成敗,而是要持續知道距離完成指令仲有幾遠。RynnValue 就是針對呢個空缺而來的模型項目:它把機械人影片連同文字指令一齊讀入,逐格預測剩餘完成時間,並輸出自然語言分析,讓進度估計、失敗偵測與 VLA(vision-language-action)policy 的獎勵建構可以共用同一套訊號。

它和常見進度分數或偏好標註做法的分野很清楚。RynnValue 不靠人工標出「較好」軌跡,也不把進度硬壓成 0 到 1,而是直接學習 goal-conditioned cost-to-go 的物理時間;標籤來自時間戳,配合子任務切分與 cutoff relabeling,於是能擴展到 7,000 多小時、約 300 萬段 instruction-conditioned clips 的異質機械人資料。這個取捨帶來的好處是可擴展,代價則是模型必須更好地處理長尾任務時長與不同視角、不同 embodiment 的差異。

RynnValue 連同完整工具鏈一併提供。你可以把它理解成一套由 HuggingFace 相容模型、影片推理示範,到 reward-model benchmark 與強化學習介面都包起來的研究型工具組;當中 RynnValue 建基於 RynnBrain,實作在 Qwen3-VL architecture 之上,除了預測 absolute 與 relative temporal value,亦會生成影片描述,並判斷 instruction–video 是否匹配、任務是否成功。

  • 核心能力是把「距離完成尚餘幾多秒」變成稠密 value signal
  • 訓練毋須 preference 或 progress annotations,較易放大量異質資料
  • 8B 版本在 RBM-EVAL-OOD 的平均 Kendall’s τₐ 達 0.675,高於文中對照的 fully preference-supervised 方法 0.655
  • 可直接接到 reward shaping,用作 policy ranking、evaluation 與 reinforcement learning critic

為免模型偷看序列位置去猜進度,作者加入 temporal-order shuffling、random temporal sampling,以及 value-isolation attention;消融結果亦顯示這些設計不是裝飾,拿走後指標會明顯下跌。再進一步,它把輸出的 value 轉成 potential-based shaping reward,在雙臂 Franka 的真實機械人學習中,無論 online 定 offline 都比最強 reward-model baseline 有更高成功率。

最受惠的會是做機械人操作、VLA 訓練、reward modeling 與 embodied AI 評測的團隊,尤其想減少人手標註成本、又需要跨資料來源泛化能力的人。限制同樣存在:這類時間距離訊號雖然比二元成敗更細緻,但對任務切分、影片品質與觀測覆蓋仍然敏感,而且它目前聚焦於 robot manipulation,不代表可直接外推到所有 agent 場景。

項目主頁 · GitHub · 模型

Categories: 開源, 阿里巴巴, Agentic, 視覺模型, 多模態模型, 模型訓練, Qwen, Video, VLA, Robotic, Dataset 數據集

Ouroboros 把 AI 代理變成「自我演化」

它不只會接任務,還會記住自己做過什麼,甚至改寫自己。對想長期運行 AI agent 的團隊,呢種設計幾有吸引力。

Terminal-Bench 2.1: Ouroboros against Claude Code, Codex CLI, Cursor CLI, and Hermes on matched models, with a same-harn

一次性完成指令的 AI agent 已經不少見,但能夠跨任務、跨重啟保留身份、記憶同歷史,仲可以持續修改自己運行方式的並不多。Ouroboros 屬於開源通用型 AI agent,處理的是長週期工作會斷線、失憶,同埋難以持續改進代理本身的問題。

它不是單純能開多個 specialist agents,而是保留「同一個負責任主體」去協調研究、建構、驗證同審查。呢種做法對外部程式碼項目、需要長時間追蹤證據的工作流特別有用;代價是系統野心很大,對使用者來說亦意味要接受一個會動到自身程式碼、prompt、tools 甚至 dependencies 的代理。

Ouroboros 可當原生桌面程式使用,也可走 headless CLI,Windows x64 同多種 Linux 發行版都有發佈版本。執行期會把 repository、durable memory、history 同介面留在本機,模型推理則可接駁你自行設定的遠端 API,或者用本地 GGUF 模型,對想保留資料控制權的人較有吸引力。

  • 開源通用型 AI agent,重點在持續身份、durable memory 與自我修改
  • 可協調一組 specialist agents,但最終責任仍由單一 root agent 承擔
  • 支援桌面 app 與 CLI,適合長時間運行或接手外部程式碼項目
  • 本機保存記憶與歷史,模型可用遠端 API 或本地 GGUF 格式在本地執行推理
  • 官方列出 Terminal-Bench 2.1、OSWorld-Verified、CL-Bench 的 self-reported 成績

Ouroboros 公開了在 Terminal-Bench 2.1、OSWorld-Verified 同 CL-Bench 的 self-reported 結果,並以 matched model 或公開排行榜對照 Codex、Claude Code、Cursor、Hermes。呢類數字有參考價值,但仍要留意它屬自報結果;較可取的是,項目同時強調 traces、evidence 同可重現性,顯示它想把重點放在可檢查的過程,而不只是最終分數。

整體來看,Ouroboros 適合研究型開發者、想建立長記憶 agent 的團隊,以至需要代理長期接手軟件工作流的人。它吸引人的地方在於把 agent 由「一次性助手」推向「可延續個體」,但同時也把風險一併帶進來:自我演化愈強,愈需要清楚邊界、驗證流程同責任歸屬。

項目主頁 · GitHub

Categories: 開源, Agentic, API, IDE, Mac, Linux, Dataset 數據集

Meta Muse Glimmer:為本地多模態代理而生

Muse Glimmer 30B 針對本地部署而設,把圖文理解和代理式操作放在同一個模型裡。它同時提供 BF16、GGUF 與 ExecuTorch 版本,方便不同裝置取用。

Meta

Muse Glimmer 30B 屬於多模態 agentic model,重點放在本地部署時的可用性。對需要在自己裝置上處理圖文輸入、又想保留代理式工作流的用戶來說,這種設計比只提供單一格式的模型更實用,因為可以按硬件環境選擇合適版本。

Meta 這次一口氣放出多種包裝,包括 BF16 權重、GGUF k-quants、ExecuTorch builds,還有一個較細的 assistant 版本。這代表它不是只面向單一推理環境,而是嘗試覆蓋桌面、本地推理引擎,以及流動裝置部署等不同需求。

從現有資訊看,Muse Glimmer 的核心價值在於把多模態能力和本地執行的彈性結合起來。GGUF 版本方便在本地執行推理,ExecuTorch 版本則指向更輕量的裝置端部署;對想控制資料流向、減少依賴雲端服務的工作流,會更有吸引力。

  • 支援多模態輸入,適合圖文混合任務
  • 針對 local deployment 設計,部署選擇較多
  • 提供 BF16、GGUF k-quants、ExecuTorch 等不同格式
  • 有 30B 主模型與較小的 3B assistant 版本
  • 適合需要本地推理、裝置端或代理式工作流的場景

現時公開資料較集中在模型包裝與部署形式。就定位而言,它更像是一個面向實用部署的多模態模型系列,而不是只靠單一規格吸引注意的發佈。

項目主頁 · 模型

Categories: 開源, Agentic, 模型, 視覺模型, 多模態模型, API, Image, LLaMa, 安全, Meta

MiniMax H3 Turbo:4 步加速的影音生成 LoRA

MiniMax H3 的 ComfyUI 加速 LoRA,把 10 秒影片生成壓到固定 4 步。它適合要在速度、畫質和可控性之間取平衡的 T2V 與 I2V 工作流。

Og image

MiniMax H3 Turbo 走的是 ComfyUI 用途的加速路線,核心價值在於把 MiniMax H3 的文本生成影片(Text-to-Video, T2V)和圖像轉影片(Image-to-Video, I2V)流程固定到 4-step Euler 推理。它不是獨立模型,而是要配合 Comfy-Org/MiniMax-H3 的 BF16 base model 使用;頁面未提供更完整的 base model 參數規模或訓練細節,所以不能再往下猜。

這種設計的取捨很直接:步數少,生成時間通常更短,但對動作細節和穩定性的容錯也會更窄。頁面列出的比較都在同一個 BF16 base model、同一輸入與 10 秒、約 0.9MP 解析度條件下做,LoRA strength 固定 1.0;不同場景下,時間大概落在 174 到 190 秒之間,速度提升存在,但不是壓倒性。

重點摘要:
– 支援 T2V 與 I2V,I2V 走第一幀路徑,亦可用最後一幀收尾
– 固定 4-step Euler,重點是縮短推理流程而非擴大模型能力
– 需要配對 Comfy-Org/MiniMax-H3 的 BF16 base model
– 頁面未列出 GGUF、mmproj、上下文長度或量化檔案資訊
– 與 lightx2v LoRA 的比較屬同級加速方案,差距主要體現在時間與輸出取向

從檔案描述看,這個項目是 LoRA,不是完整 diffusion checkpoint,所以它的定位比較像「推理策略補丁」而不是全新模型。頁面也沒有提供 llama.cpp、Ollama 或 LM Studio 的支援資訊,顯示它主要面向 ComfyUI 工作流,而不是通用本地推理框架。

檔案命名上,頁面強調這是 v2 類型的更新版本脈絡;因此可確認的只有它圍繞 H3 的 joint audio-video diffusion path,並以固定 4 步作為加速契約。若要和原始 base model 比,差別不在功能範圍,而在於把生成速度和步數控制收緊,換取更快的工作流回饋。

模型

Categories: 開源, ComfyUI, 數字人, 視覺模型, 視頻模型, Video, Image, Audio, MiniMax

Hermes WebUI 把代理搬到瀏覽器

想長開一個會記住上下文的 AI agent,又不想長期困在 terminal,Hermes WebUI 正好補上這個缺口。它保留 CLI 能力,同時把多裝置存取整理得更順手。

Workspace file browser with inline preview

把一個長時間運行、會累積記憶的 autonomous agent 放到瀏覽器,而且幾乎不削弱原本 CLI 操作,正是 Hermes WebUI 最值得留意的地方。它屬於 Agent 介面工具,實際處理的是 Hermes Agent 在日常使用裡不夠方便的互動問題,讓你不必只靠 terminal 或訊息 app 才能管理對話、工作區與設定。

跟不少另起一套前端堆疊的 Web 介面不同,Hermes WebUI 走得相當克制:不用 build step、不用 framework、也不用 bundler,只靠 Python 和 vanilla JS。這種取捨帶來的好處很直接,部署比較輕、維護點較少,亦更貼近原本 Hermes Agent 的運行方式;代價是它的重點明顯放在功能對齊,而不是做一個花巧的前端展示層。

介面設計本身也有明確工作流考量。三欄布局把 session、聊天區與 workspace 檔案瀏覽分開,模型、profile 同 workspace 控制則固定放在 composer footer,減少來回切換;再加上 token context ring、Hermes Control Center、voice、mobile 與主題切換,較適合需要長時間跟 agent 協作、又要隨時查看檔案與工具呼叫紀錄的人。

  • 1:1 對齊 Hermes CLI,終端可做的操作基本都能在 WebUI 完成
  • 支援 session、workspace、voice、profiles、安全設定與手機存取
  • 可用自動探索、手動啟動、SSH tunnel、Tailscale、Docker、Nix 等方式部署
  • 建基於既有 Hermes Agent 與現成模型,毋須另設一套推理環境

安裝理解上,它不是獨立 agent,而是 Hermes Agent 的瀏覽器前端,所以前提仍然是先把 Hermes 本體跑在伺服器,再用 bootstrap、start/ctl 腳本、Docker 或 Nix module 把介面掛上去。在存取方式、部署彈性與跨裝置操作一致性;對於已經在自架 AI agent、想把 CLI 工作流延伸到桌面與手機的人,這個項目的價值相當明確。

GitHub

Categories: 開源, Agentic, 框架, Python, 語音

MatrAIx-Persona-8B: 模擬現實中的人性

MatrAIx 把人性化模擬用戶搬入評估流程,讓產品在推出前先看見不同人會點互動。它特別適合做問卷、聊天、網頁同 App 測試。

Watch the MatrAIx demo on YouTube

MatrAIx 是一套以多樣化模擬用戶做核心的評估基建,目標是補足只看單一指標、卻看不到不同人實際反應的盲點。它把 persona 變成 LLM agents,分別在 Survey、AI Chatbot、Web 同 App 四種環境跑可重現的任務,適合用來看產品、介面同互動流程會點影響不同用戶。

它的做法唔係只生成幾個虛構角色,而係用 1,290 個人格維度去組合背景、心理、能力同行為,再加上依賴關係處理同 evidence-aware human grounding。這種設計令評估結果唔止係一條總分,而係可以分辨邊類用戶受影響、邊種流程出問題。

MatrAIx: Simulating the World with 8.3B Persona Agents
  • 可用於市場研究、概念測試、客服對話、網頁原型同 App 流程評估
  • 介面前有 Playground 同 visual runner,方便先睇互動再做批量測試
  • persona-agent 範例需要 Model API keys,Playground / viewer 前端只要求 Node.js 20+
  • 內文提到嘅公共 persona 資料集同評估報告,顯示它偏向研究同產品驗證兩用。

同一般只做通用 benchmark 的方法相比,MatrAIx 強調人口規模同可重現的模擬軌跡,重點唔係單次對錯,而係不同 persona 之間的差異。這對做 AI 產品、用戶研究、RL 訓練前資料收集的團隊較有價值,因為佢提供的是互動過程同行為痕跡,而唔只是結果分數。

項目主頁 · GitHub

Categories: 開源, Agentic, API, Medical醫學, Dataset 數據集

Page 22 of 92
1 20 21 22 23 24 92