用行為地圖看懂 Agent Harness

Hero image preview

想理解 coding agent 點樣真正執行、點樣做安全檢查,或者想改成自己團隊用得上的流程,卡位通常唔在於缺少文件,而在於行為分散喺大量程式碼之中。Harness Handbook 就是針對 agent harness 的整理方法,把「某個行為點樣發生」變成可導航、可核對、可修改的路徑。

它處理的是行為同實作之間斷開的問題。像「刪除檔案前會否先詢問」這類問題,往往涉及多個 implementation sites,不是搜 delete、permission、confirm 就能直接還原全貌。Harness Handbook 以 behavior-level manual 方式重組這些零散位置,讓人可以由問題出發,一步步找到對應的 behavior units、相關程式碼證據,以及可能受影響的修改位置。

  • 把分散程式碼整理成可閱讀的 behavior map
  • 每個行為步驟都連到可驗證的 code evidence
  • 支援理解、審核與修改共用同一套入口
  • 著重 human in the loop,方便持續檢查系統變化

這種做法同一般 code index 或關鍵字搜尋的差異,在於它不是單純列出檔案,而是直接對應「系統會點做」。對開發者、維護大型 agent 項目的人,或者要審視安全邏輯的團隊,都會比較實用;連 coding agents 也可借這份 Handbook 更準確找到相關程式碼。

資料顯示,項目還提供 Handbook Studio,將這套 behavior map 變成可操作的入口。現階段重點不在推出另一個模型,而是為複雜 agent harness 建立一層可解釋、可審核的結構,令系統隨版本演進時,仍然保留清晰的行為脈絡。

項目主頁

Categories: 開源, 騰訊, Agentic, Vibe Coding, 編程, 框架

KnowAct-GUIClaw 跨平台 GUI 代理

GUIClaw

要代理跨桌面、Android、iOS 同 HarmonyOS 幫你做事,最易失手的位通常唔係單一步驟,而係多個 App 之間點樣接續執行。KnowAct-GUIClaw屬於 Agentic 自動化框架/工具,核心處理的是長流程 GUI automation:由理解意圖、揀路徑、執行操作,到把經驗寫回記憶與技能庫,令之後的任務唔使每次由零開始。

同類 GUI agent 常見做法,是把畫面理解同動作決策綁成單次 observe-reason-act 迴圈;作者認為這種固定範式一遇上跨 App、跨系統流程,就容易缺少任務分解、歷史經驗同可重用技能。KnowAct-GUIClaw改用 Know–Route–Act–Reflect,前面先整理證據與路由,後面再把軌跡蒸餾成 memory 同 skills,取向明顯偏向「愈用愈熟手」而唔係單次回答最聰明。

部署上有兩條路:一條是完整 host,配合 nanobot webui、gateway 同 agent 去跑;另一條是獨立 guiclaw 工具,讓其他 host、腳本或終端直接調用。GUI automation 會改變裝置狀態,驗證任務應先用 dry-run,同時用測試裝置或測試帳號,這點對企業內部流程、自動測試、數碼助理場景尤其重要。

  • 支援 desktop、Android、iOS、HarmonyOS,重點係跨平台一致流程
  • 以 memory store 同 skill store 補強長流程任務,而唔只靠即場推理
  • 在 MobileWorld benchmark 取得 64.1%,頁面稱超過多個 open agent frameworks 及部分 closed agents
  • 對不同底模有泛化效果:Kimi-2.6 提升 8.5%,Qwen3.5-35B-A3B 提升 16.2%

受惠最大的,會是要處理重複 GUI 流程的團隊,例如行動裝置測試、跨 App 任務編排、個人助理型代理開發。不過它的價值未必只在榜單,而係把 GUI agent 從「會操作畫面」推向「會累積經驗再操作畫面」。

項目主頁 · GitHub · Paper

Categories: 開源, Agentic, 工具, Dataset 數據集, Skill 技能

MonkeyOCRv2 文件通用 OCR 底座

overview

文件 AI 最麻煩的地方,在於文字辨識、版面解析、文件理解、公式辨識,甚至竄改檢測,很多時都要拆成幾個模型串起來。MonkeyOCRv2 把自己放在視覺文字基礎模型的位置,核心不是只追單一 OCR 指標,而是想用同一個 encoder 同時覆蓋多語言文件 parsing、understanding、text recognition、formula recognition 以至 scene text detection。

它採取的路線很明確:不像部分做法會按任務各自訓練小模型,MonkeyOCRv2 強調 fine-grained text modeling、cross-task representation learning 同 cross-lingual generalization,等於先把「文字作為視覺內容」這件事學得更深,再把能力分流到不同文件任務。這種取向的好處,是同一套底座較適合研究團隊或產品團隊整合工作流;代價則是現有資訊仍以模型發布為主,完整效能對比與部署細節還要結合論文與 checkpoint 再判斷。

現階段最值得留意的,是項目已不只放出單一模型名稱,而是分成幾條較清晰的能力線。 MonkeyOCRv2 vision encoder,以及面向 multilingual document parsing 的 MonkeyOCRv2-Parsing、面向 efficient document understanding 的 MonkeyOCRv2-Und,並提供 Hugging Face 與 ModelScope checkpoint,代表測試方式大致會圍繞下載權重後,按任務接入 parsing、recognition 或 understanding 流程,而不是單純打開一個聊天介面就完成。

  • 涵蓋 OCR、文件理解、公式辨識、竄改檢測、重疊文字分割等多類任務
  • 提供 MonkeyOCRv2-S、MonkeyOCRv2-B、MonkeyOCRv2-AS,不同 backbone 對應不同場景
  • S、B 版本偏向 Recognition / Parsing / Understanding,AS 版本偏向 Detection / Segmentation
  • 已公開 Demo、Hugging Face 集合與 MonkeyDocv2 數據集線索,方便交叉驗證

從現有公開資訊看,這個項目較適合做 Document AI、智能審核、票據與表單處理,也適合想比較 dots.mocr、PaddleOCR-VL、Qwen3-VL 這類路線差異的人。它未必是最輕量的選擇,但「一個編碼器橫跨多任務與多語言」這個方向,對需要長期維護文件工作流的項目有相當吸引力。

GitHub · Paper

Categories: 開源, Qwen, OpenAI, Medical醫學, 多模態模型, 影像處理, 模型, 框架, Dataset 數據集

RINO 用圖像編輯統一視覺任務

RINO unifies vision under a single RGB interface: one frozen image editor, driven by a task-specific prompt, handles est

與其為每個視覺任務各自接駁 head、decoder 或 adapter,RINO 選擇更激進的路線:全部改寫成 RGB In, RGB Out。它屬於一個以 PyTorch 實作的研究型評測與實驗項目,核心問題是檢查單一凍結式 image editor,能否同時處理視覺理解與條件生成,而毋須為深度、segmentation、pose 之類任務另建模組。

這個定位帶來的吸引力很直接:流程統一、介面統一、後端也能互換。項目目前接上三個開源 image-edit 模型作為黑盒後端,包括 Qwen-Image-Edit、FireRed-Image-Edit 與 LongCat-Image-Edit;任務目錄結構一致,每個 task 都有獨立 evaluate 程式與 output 結果,方便逐項跑 benchmark,比起各任務各寫一套推理邏輯,整理與比較都省事得多。

但它的取捨同樣明顯。RINO 並沒有訓練新模型,也不做 fine-tuning,而是堅持用 released weights 直接測 zero-shot 表現;好處是比較乾淨,較能反映 image editor 本身的泛化能力,限制則是上限會被原生編輯模型綁住,對結構化輸出是否穩定、是否容易受 prompt 與渲染方式影響,仍要按任務逐個看。

  • 重點不是追求單一任務最佳成績,而是測試「同一個 RGB 介面」能否橫跨多類視覺工作
  • 三個後端可互換:Qwen-Image-Edit、FireRed-Image-Edit、LongCat-Image-Edit
  • 採用 copied official metric code 評分,數字理論上較容易與既有文獻對齊
  • 部署理解不複雜:安裝依賴後,按 task 準備 dataset,再選 BACKEND 與對應 MODEL 便可執行評測

較適合留意這個項目的,會是想研究 unified vision 介面、比較不同 image editor 泛化力,或者想把多個 benchmark 收攏到同一工作流的團隊。現有資訊未列出完整成績表,但它已清楚交代評測方法、資料夾規格與模型來源;作為研究驗證平台,價值在於提出一套可重覆比較的做法,而不是即刻取代每類任務的專用模型。

項目主頁 · GitHub

Categories: 開源, Qwen, Image, Python, 多模態模型, 影像處理, 模型, 模型訓練, Dataset 數據集

AMID 把醫學影像建模流程交畀代理協作

AMID logo

醫學影像建模最麻煩的位,往往唔係只係揀網絡,而係每個任務都有唔同資料形態、指標、切分規則同提交要求。AMID把呢個痛點拉到枱面:它屬於一個 autonomous multi-agent framework,目標唔係產生一段建議文字,而係交出可訓練、可推理、可驗證、可提交的完整模型產物。

現有通用 MLE agent 往往沿用比較粗略的搜尋與試錯範式,先提方案、再寫碼、再靠結果反覆修補;作者認為放到醫學影像場景,呢種做法容易忽略資料條件、驗證協議同提交格式。AMID改用 Data-Conditioned Method Planning,先按任務資料與可運行資源整理出可執行的 method lanes,再用 Verification-Guided Two-Stage Optimization 由早期廣泛探索,轉去後期集中追蹤有潛力路線,同時持續檢查 metric computation、validation protocol 同 prediction artifacts。

呢種取向的差異,在於它把「做得出分數」同「流程可核對」放埋一齊處理。對醫療 AI 團隊、挑戰賽參賽者,或者要同時管理 2D 影像、3D volumes、segmentation masks、class labels 等異質資料的人,AMID的吸引力在於減少人手串接流程的時間;代價是它目前仍以技術報告與任務解法報告為主,README亦寫明 source code 尚未釋出,暫時未到可以直接部署測試的階段。

效能方面,AMID用 ReX-MLE 的 20 個 medical imaging challenge tasks 做基準,比較對象包括一般用途 MLE systems,同時拿 human-designed challenge solutions 作參照。作者指出它整體表現優於被評測的通用系統,部分任務接近或追平人手設計方案;現階段較適合把它理解成一套清晰的方法論與工作流藍圖,而唔係即裝即跑的開源工具。

  • 核心定位係 autonomous multi-agent framework,處理醫學影像模型開發與驗證交付
  • 主要方法包括 Data-Conditioned Method Planning 同 Verification-Guided Two-Stage Optimization
  • 輸出唔止模型建議,仲包括 training code、inference code、weights、prediction files 同 audit trail
  • 基準測試來自 ReX-MLE 的 20 個任務,整體表現優於通用 MLE systems
  • 目前已公開 technical report 同 20 份 solution reports,source code 尚未發布

相關模型與系統脈絡方面,AMID直接對比的是 general-purpose MLE systems,同時以 human-designed challenge solutions 作為高水位參考。它未有把重點放在單一 backbone 或某個固定醫學影像模型,而是把多代理規劃、優化與驗證流程包成可重複的方法,呢點比單次調參工具更值得留意。

GitHub · Paper

Categories: 開源, 香港, 香港中文大學, 微軟, Agentic, Image, 3D, Medical醫學, 多模態模型, 影像處理, 模型訓練, 框架, Dataset 數據集

MuScriptor 把多樂器轉譜拉近可用水位

MuScriptor logo

聽住一段完整歌曲,直接整理出可編輯的 MIDI,本來最易卡住嘅位係多樂器同時出現之後,音色、失真同重疊頻段會令轉譜結果迅速走樣。MuScriptor 針對嘅正正係呢種情況:它屬於開源音樂轉譜模型,目標係將真實世界嘅多樂器錄音轉成符號化樂譜,而唔係只喺單一樂器或合成資料上做得好睇。

舊一代 Automatic Music Transcription 往往依賴大量 synthetic training data,代表性做法如 MT3,喺合成測試集成績可以唔錯,但一落到真實混音音樂就容易失準。MuScriptor 嘗試修正呢個範式,先分析 synthetic data pre-training 嘅作用,再結合真實音訊 fine-tuning,同時加入 reinforcement learning 做 post-training,重點唔係追求實驗室式乾淨訊號,而係提升跨曲風、多樂器錄音嘅泛化能力。

對一般創作者、編曲人、音樂研究者同需要把歌曲快速轉成 MIDI 工作流嘅團隊來講,呢個項目吸引力幾直接。它提供 web UI 同 CLI 兩種方式,本地可先用 uvx muscriptor serve 背後嘅介面理解效果,亦可以用命令列批次處理;首次執行前要有 HuggingFace 帳戶並接受模型授權,權重會下載後快取,本地網頁服務預設只開喺 127.0.0.1,改成 --host 0.0.0.0 就可以喺區域網路存取。

  • 已公開 smallmediumlarge 三個模型,分別為 103M、307M、1.4B 參數
  • small 較適合 CPU-only 環境,medium 係預設速度與準確度平衡,large 追求更高準確率但更重
  • 模型架構採用 transformer decoder only
  • 支援 instrument presence conditioning,用來控制轉譜時聚焦邊類樂器
  • 播放功能唔係單純示意,而係透過完整 SoundFont synthesizer SpessaSynth 回播

限制亦寫得算坦白:權重受 CC BY-NC 4.0 約束;Intel Mac 要留意 PyTorch 同 Python 版本配搭。現有資料指出它訓練用到 170k 首歌,涵蓋 classical music 到 heavy metal,定位上明顯比只靠小量真實資料、再用大批合成音訊補足嘅方法更著重真實混音可用性。對需要高質多樂器 AMT 嘅人,MuScriptor 目前最值得留意嘅,係它唔再只展示「可以轉譜」,而係開始處理「轉出嚟能否進入後續編曲或分析」呢個關鍵差距。

項目主頁 · GitHub · 模型

Categories: 開源, Mac, Python, 模型, 音樂, Dataset 數據集

reasoning-blind-spots:找出 AI 推理盲點的測試集

front page new

最值得留意的矛盾,是題目對人類不算難,卻會令前沿模型露出推理短板;blind-spots-bench 屬於基準測試與資料集項目,用來檢查 AI 在抽象、文字及多模態推理題上的失誤位置。

很多模型評測偏向看總分或通用能力,這個項目把焦點放在「盲點」:模型可能懂得生成流暢答案,卻在追蹤規則、連鎖映射或跨模態線索時走錯一步。資料集已放在 Hugging Face,格式包括 parquet,規模少於 1K,較適合做針對性壓測,而不是當成大規模訓練資料。

  • 定位清楚:針對 frontier AI models 的 reasoning capabilities 做壓力測試。
  • 工作流完整:以 Inspect AI 作為 evaluation framework,並提供 scripts 重現評測。
  • 可檢查答案:grader.py 負責 Scorer/Grader/Verifier logic,solver.py 處理 Solver/Generator logic。
  • 覆蓋形式:資料包含 Image 與 Text,題型可分為 Text-only 與 Multi-to-text。

安裝與部署層面,這不像一般應用工具按幾個掣便完成任務;較合理的理解是把它接入評測流程,透過 conf/ 的 Hydra 設定、scripts/ 的重現腳本,以及 notebooks/ 的分析視覺化,對模型輸出做批量測試與比較。

結果表列出 mean@4、pass@4、out-tks 與 cost ($/100) 等指標,並可見 GLM-4.7、GLM-5、GLM-5.1、GLM-5.2 等相關模型。它較適合模型研發團隊、評測工程師、AI 產品團隊用來補足一般 benchmark 看不到的錯誤模式;若只想找聊天機械人的日常排行榜,這個項目的粒度會顯得更偏研究與診斷。

項目主頁 · GitHub · Paper

Categories: 開源, OpenAI, Image, 多模態模型, Dataset 數據集, 框架

CtrlVTON 把虛擬試穿變成可控編輯

NXN LABS

網購試衫最常見的落差,不是像不像,而是你根本無法指定件衫要點樣著。CtrlVTON 屬於影像生成與虛擬試穿項目,處理的是 Virtual try-on (VTO) 長期欠缺的可控性:同一件衫可以鬆身或貼身、束入或放出、打開或扣上,甚至改變穿著位置與疊穿方式。

現有做法多數把 VTO 當成 inpainting 問題,擅長補畫衣物,卻不容易精準跟住使用者指定的版型同位置。CtrlVTON 改用 image editing framing,再配合 segmentation mask 做 pixel-level control,重點不是單純生成得自然,而是令版面安排真正聽話。論文亦明確指出,它在服裝忠實度接近強勢 proprietary editing systems 的同時,對使用者提供的布局跟隨得更準。

支撐這套方法的另一半,是 Visual-Instance-Prompt Segmentation 與對應模型 VIP-SAM。以往常見的是 category-level visual-reference segmentation,但作者針對的是 instance-level 任務:先給你一張平拍服裝圖,再從人物穿著照片中分出同一件衣物。這一步對同類衣物干擾、遮擋,以及布料變形都更敏感,所以 VIP-SAM 會把 support features 提早注入 SAM backbone,目標是令定位更穩。

  • 把 VTO 由 inpainting 轉成 image editing,控制粒度更細
  • 用 segmentation masks 指定服裝大小、風格與身體上的位置
  • VIP-SAM 先解決「相中究竟係邊一件衫」的 instance-level 分割問題
  • 一個框架內處理 garment swapping、layering、selective switching、multi-garment composition
  • 已公開 VITON-HD-edit dataset,並有 arXiv 論文可交叉核對方法與結果

理解這個項目的較合理方式,不是把它當成即裝即用成品,而是研究型原型加資料集組合。,測試與部署會圍繞論文、GitHub 儲存庫,以及 Hugging Face 上的 VITON-HD-edit dataset 展開;較適合做可控試穿研究、電商影像流程驗證,或想比較 LoRA 式輕量微調能否取代大型封閉編輯服務的團隊。限制也很清楚:Project Page 尚未公開,README 釋出的安裝與推理細節仍不完整,現階段更適合有影像模型基礎的人先跟論文設定重現,再評估能否接入產品流程。

GitHub · Paper

Categories: 開源, Image, 影像模型, 影像處理, Dataset 數據集

LightMem-Ego:AI 眼鏡及手機的日常記憶系統

LightMem-Ego Logo

LightMem-Ego 由 Zhejiang University、South China University of Technology、Central China Normal University 與 Lenovo Group Limited 共同開發。它瞄準的是手機與 AI 眼鏡長時間接收影像、聲音後,怎樣把零散片段變成可追問的日常記憶,屬於端到端 streaming multimodal memory system。

現有多模態助理多數擅長回答當下畫面或單次對話,但要回想剛才誰講過甚麼、物件放在哪裏、一天內發生過甚麼,就需要把連續經驗累積、整理和檢索。LightMem-Ego 的做法是把第一身 visual-audio streams 對齊到同一條時間線,再分成 Current memory、Short-term memory 和 Long-term memory,查詢時按問題動態路由到合適記憶層,並用 timestamped multimodal evidence 支撐答案。

  • 工作流定位:連接 Rokid AI Glass Android app、browser frontend 和 online backend service。
  • 主要用途:object finding、conversation recall、life summarization、routine discovery 和 hands-free wearable assistance。
  • 核心取捨:不是只追求單次多模態理解,而是把輕量、持續累積和可檢索記憶放在中心。
  • 部署理解: Quick Start 與 glasses + web deployment,但提供資料未列出完整安裝指令或模型配置細節。

對可穿戴裝置開發者、個人助理產品團隊來說,這個項目的價值在於它把擷取、時間線對齊、記憶分層和問答串成一條較完整的流程。它也較適合需要測試「長時間生活脈絡」的場景,而不是只做單張圖片問答或短語音轉錄。

性能與評估資料在提供內容中仍然有限,未見具體 benchmark 數字可引用。相關模型資料只提到 multimodal large language models 的背景,包括 OpenAI 與 Gemini;未明確指定 LightMem-Ego 後端必須使用哪一個固定模型。

GitHub · Paper

Categories: 開源, Gemini, OpenAI, Agentic, Audio, 多模態模型, 語音, 中國, Dataset 數據集, 框架

ABot-N1 點樣令導航模型更穩更易懂

AMAP CV Lab

做室內外導航時,最麻煩往往不是單純避障,而是模型要同時理解語言、辨認目標,再即時走出合理路線。ABot-N1屬於 VLA(Vision-Language-Action)navigation model,焦點放在處理黑盒式策略常見的座標漂移、長尾語意理解不足,以及決策過程難以解釋的問題。

它的做法不是把所有事塞進同一個控制器,而是用 slow-fast 架構把認知與控制分開。較慢的 vision-language reasoner 會讀取歷史畫面與任務提示,產生明確的 Chain-of-Thought reasoning,並輸出 pixel goals 作為通用的影像空間錨點;較快的 action expert 再結合文字線索與 pixel guidance,持續生成 waypoint,將高層意圖接到低層移動控制。

這種設計的好處,在於同一套框架可以覆蓋多種導航任務,而不只是單一路徑跟隨。現有資料提到它支援 point-goal、POI-goal、object-goal、instruction-following 同 person-following,當中 POI-goal 需要由戶外走到實際入口,特別能反映語意理解與跨場景移動是否連得上。

  • 把 cognition 與 control 非同步拆分,減少黑盒式端到端策略的不透明問題
  • 用 dual visual-language signals 連接推理與動作,核心輸出包括 Target Pixel 與 Affordance Pixel
  • 涵蓋 point-goal、POI-goal、object-goal、instruction-following、person-following 等任務
  • 成績上錄得新 state-of-the-art,POI arrival 提升 35.0% 至 77.3%
  • 複雜室內與室外場景分別達到 95.4% 與 92.9% SR,亦同步開源新 benchmark

整體來看,ABot-N1最值得留意的不是單一指標,而是它試圖把「看得懂、講得清、走得穩」放進同一個導航模型。對做 embodied AI、robotics 或通用導航工作流的人來說,這個項目提供了一條比純黑盒控制更可分析、也更容易擴展到不同任務的路線。

項目主頁

Categories: 開源, 阿里巴巴, Image, 3D, 多模態模型, 模型, 模型訓練, 視覺模型, Robotic, VLA, Dataset 數據集

Page 9 of 66
1 7 8 9 10 11 66