EdgeBench 用 134 個長任務量度智能體成長

模型識幾多,未必等於學得幾快。EdgeBench想回答的,是智能體在真實環境中隨時間互動後,能力會怎樣上升。

ligo gw

跑一次就評分的基準,通常只能看出模型本身已經識乜;EdgeBench關注的是另一件事:當智能體放進接近真實工作的環境,連續做十幾個鐘、接收回饋再反覆修正,它究竟會唔會愈做愈好。這是一個研究 environment learning 的 benchmark,核心問題不是單次答對率,而是學習曲線能否反映長時間互動後的能力變化。

它把 134 個任務分成六大類,包括科學與機器學習、系統與軟件工程、組合最佳化、知識工作、形式數學同遊戲,而且每個任務最少運行 12 小時,部分延伸到 72 小時以上。這個設計接近真實工作流,因為智能體需要面對 build logs、test failures、objective values、simulator traces、實驗誤差等回饋,而唔係只靠一次生成結果交卷。

同常見 benchmark 相比,EdgeBench的差異在於它量度「隨經驗累積而改善」的能力。研究者指出,多個模型在 134 個任務上的整體表現,都可用 log-sigmoid function 擬合,R²約為 0.997 至 0.999,表示 environment interaction time 與表現提升之間有相當穩定的關係。這令它不只是一張排行榜,也是一個用來觀察 scaling laws of environment learning 的分析工具。

  • 覆蓋 134 個真實世界長時任務,重點放在學習速度與上限
  • 任務橫跨科學、編程、最佳化、知識工作、數學與遊戲
  • 每項任務持續 12 小時以上,部分超過 72 小時
  • 回饋訊號來自接近真實工作的執行環境,而非單次靜態題目
  • 整體學習曲線可用 log-sigmoid function 高精度擬合

這套 benchmark 對做 Agentic 項目、長流程自動化、程式代理與研究型智能體的人最有參考價值,因為它直接呈現模型在長時間任務中的耐力、修正能力與邊做邊學的幅度。現有資料集中在 benchmark 設計、任務結構、資料集與分析結果,未提供具體安裝步驟或完整使用流程;能確定的是,這個項目由 ByteDance Seed 發表,並附有 Paper、GitHub 與 Dataset 入口。

項目主頁 · GitHub · Paper

Categories: 開源, 字節跳動, Agentic, 模型訓練, DeepSeek, 框架, 軟件, 編程, Anthropic, Dataset 數據集

LLM-as-a-Verifier 點樣重寫代理評分

當代理唔只要答得啱,仲要一步步做得穩,粗略打分已經唔夠。LLM-as-a-Verifier把評估拆細,令挑選、追蹤同訓練都更有依據。

LLM-as-a-Verifier

代理系統最常見的瓶頸,唔係生成唔到答案,而係你難以知道它每一步到底做得幾好。LLM-as-a-Verifier屬於開源框架,針對的正是呢個問題:它唔只為最終結果打一次分,而係用更細緻的方式為候選答案、行動步驟同任務準則提供可量化回饋。

現有做法不少仍然依賴單次判斷、粗粒度分數,或者只看最終成敗;作者認為呢種固定範式會忽略不確定性,亦難以支援 progress tracking 同 reinforcement learning。LLM-as-a-Verifier改用三個核心設計重組驗證流程:score granularity、repeated evaluation 同 criteria decomposition,並且直接對 LLM score tokens 的完整 logprob distribution 取期望值,而唔係只取單一輸出。

呢個取向令它同一般 judge-style 評分器有明顯分野。它重點唔在於產生一句評語,而係產生可反覆比較、可分解、可累積的 fine-grained feedback,所以可以用於 Best-of-N selection、pairwise compare,同埋逐步追蹤代理行為變化。README 亦展示了 Python 套件 llm-verifier 的基本用法;安裝方式有提供,但更完整的部署細節主要放在官方文件,而某些流程亦需要 VERTEX_API_KEY 或可回傳 logprobs 的 OpenAI-compatible server。

  • 支援任何 modality 的驗證框架,定位比單一 benchmark judge 更廣
  • 方法核心是細粒度評分、重複驗證、按 criteria 拆解準則
  • 可直接用於 selection、compare、track,同時連到 reinforcement learning
  • 官方列出 Terminal-Bench V2、SWE-Bench Verified、MedAgentBench、RoboRewardBench 等結果
  • 相關模型與服務包括 Qwen/Qwen3.5-9B、Qwen3-8B、Gemini 2.5 Pro,以及 OpenAI-compatible server

表現上,項目聲稱在多個 agentic benchmarks 達到 state-of-the-art,包括 Terminal-Bench V2 86.5%、SWE-Bench Verified 78.2%、RoboRewardBench 87.4%、MedAgentBench 73.3%,亦提到在 LIBERO 配合 SAC 微調 pi 0 policy 時,sample efficiency 約高 1.8 倍。呢類數字反映它較適合研究團隊、代理平台開發者,同埋想將評估訊號接入訓練迴路的人;單純只想要一個最終分數的團隊,未必需要用到它整套驗證尺度。

項目主頁 · GitHub · Paper

Categories: 開源, Agentic, Qwen, NVIDIA, OpenAI, Gemini, Medical醫學, Python, Anthropic, Dataset 數據集

Wan Streamer v0.2 提升實時視頻對話畫質

想做會講話、會望向場景嘅即時 AI 角色,畫面清晰度同延遲通常要二揀一。Wan Streamer v0.2 嘗試保住低延遲,同時把視訊互動提升到更自然可用。

Wan Streamer framework

做即時音視頻互動時,最麻煩往往唔係模型識唔識回應,而係畫面一清晰,延遲就容易升高。Wan Streamer v0.2 屬於原生流式 audio-visual interaction model,針對呢個取捨下手:把輸出由 192×336 提升到 640×368,仍維持 25 fps,同時把模型側延遲控制在約 200 ms。

它延續 v0.1 的做法,將文字、音訊、影片放在同一條 causal timeline,用單一 Transformer 協調,並以 block-causal attention 處理串流互動。重點唔係換掉整個架構,而係在低延遲預算不變下,令畫面由近景視像通話,擴展到更有場景感的中景 agent,連姿勢、視線、手部同附近物件都更易看清。

為咗撐起更高解析度而唔增加可見等待時間,v0.2 把高成本 latent 生成路徑移到 Ulysses-style context-parallel performer;另一邊的 thinker 仍留在單 GPU,負責流式感知、狀態更新、KV 建構同最終解碼。呢種分工代表項目唔係單靠堆硬件換速度,而係重新安排推理拓撲,把重負載部分放到更適合並行處理的位置。

  • 輸出解析度由 192×336 提升到 640×368
  • 幀率維持 25 fps,模型側延遲約 200 ms
  • 支援 scene-grounded mid-shot agents,而唔只係近景通話畫面
  • 保留單一 Transformer 的 native-streaming formulation
  • 以 thinker + performer 分工處理低延遲與高成本生成

呢個項目最適合想做即時數字人、互動客服、教學導覽或直播型 agent 的團隊,因為使用者會直接感受到畫面資訊量增加,但對話節奏未必因此變慢。現有資料主要強調架構升級同延遲維持,更完整畫質穩定性、部署成本與長時間使用表現,仍要配合論文與示範一齊判斷。

項目主頁 · Paper

Categories: 阿里巴巴, Agentic, 多模態模型, Video, Audio

微軟 ResearchStudio:AI 助你研究你的方案

微軟開源一套研究輔助技能組,覆蓋從模糊方向到論文發表的全流程,並以 ICLR、ICML、NeurIPS 論文集訓練出可追溯的構思模式。

logo

ResearchStudio 的核心任務是把大型語言模型(Large Language Model, LLM)變成研究流程中的協作角色,從構思、文獻搜尋到成稿後的展示素材皆涵蓋在內。它由兩個互補的子項目組成:ResearchStudio-Idea 處理「論文前」階段,協助將尚未成形的研究方向轉化為可辯護的構想;ResearchStudio-Reel 則處理「論文後」階段,把已完成的 PDF 轉成海報、旁白影片、雙語部落格文章及互動式摘要頁面。

傳統的 LLM 輔助構思多半只停留在「生成候選題目」這一層,研究人員仍須自行補上文獻脈絡、辨識瓶頸、區隔既有方案並評估風險。ResearchStudio-Idea 對此提出的修正做法,是從 2021 至 2025 年間 ICLR、ICML、NeurIPS 共 1,947 篇論文中歸納出 31 個反覆出現的構思子模式,再收斂成 15 個可重用的構思模式(ideation patterns),每張模式卡都附帶研究脈絡、瓶頸類型、差異化策略、支援先例與常見失敗模式。這樣的設計讓 IdeaSpark 能以「證據整備度評估 → 脈絡重建 → 瓶頸辨識 → 模式選擇 → 候選生成 → 衝突檢索 → 結果導向稽核」七個步驟,把抽象模式轉化為可追溯的研究提案。

套件內另外兩個獨立技能 Paper-Search 與 Scoop-Check 分別負責多源文獻搜尋與新穎性碰撞檢查,讓構思過程中對「現有方法如何做」與「作者為何不同」這類對比能即時取得佐證。和坊間通用寫作助手相比,ResearchStudio 的差異在於把會議投稿結果(包含口頭報告、高引用子集與被拒稿件)當作訓練素材,使生成的構想能對照真實的審稿標準。技能以 Claude Code 與 Codex 為執行環境,透過 install.sh 即可建立符號連結並完成環境配置。

適合的對象包括需要快速整理文獻的研究生、準備投稿 ML 會議的團隊,以及希望把既有論文包裝成海報或短片的學術機構。對會議投稿文化熟悉的讀者會更容易判斷模式卡的適用邊界;而非 ML 領域的使用者則可借鏡其「以證據為基礎的構思流程」這套方法論。兩篇 arXiv 論文(Idea: 2607.04439、Reel: 2607.04438)分別詳述技術細節與評估方式,值得在採用前先行閱讀。

重點摘要:

  • 全流程覆蓋:從模糊研究方向到論文發表後素材生成,由 Idea 與 Reel 兩個子項目分工處理。
  • 基於會議資料的模式庫:以 1,947 篇 ICLR、ICML、NeurIPS 論文歸納出 15 個可重用的構思模式。
  • 可追溯的構思步驟:七階段工作流程將抽象模式轉為具備文獻佐證的研究提案。
  • 獨立技能模組化:Paper-Search 與 Scoop-Check 可單獨用於文獻搜尋與新穎性檢查。
  • 依賴 Claude Code 與 Codex:需在這兩種 AI 編碼環境中執行,門檻偏向熟悉 LLM 工具鏈的研究者。

項目主頁 · GitHub · Paper

Categories: 開源, Agentic, 微軟, 框架, Dataset 數據集

open-design:本地優先的開源設計工具

open-design 是一款本地優先的桌面應用,讓 AI 編碼代理直接生成設計稿、頁面與多媒體內容。

Og image

open-design 是一款本地優先(local-first)的開源桌面應用程式,主打讓 AI 編碼代理(coding agent)直接充當設計引擎,協助用戶快速產出原型設計(prototypes)、登陸頁面(landing pages)、儀表板(dashboards)、投影片、圖片甚至影片等各種多媒體素材,並輸出真實可用的檔案。這個項目的定位是 Claude Design 的開源替代方案,強調在桌面環境中本地執行,無需依賴雲端服務即可完成設計工作。

與傳統的設計工具相比,open-design 的最大差異在於將 AI 編碼代理作為核心驅動力,用戶可以透過自然語言指令讓代理直接生成設計內容,省去手動拖拽元件的繁瑣流程。從 GitHub 上的數據可見,該項目已獲得超過 7.5 萬顆星及 8 千多次 fork,社群關注度相當高,顯示開源社群對本地化 AI 設計工具的強烈需求。

這個項目最適合需要快速產出網頁原型或行銷素材的開發者、設計師及內容創作者。對於重視資料隱私、希望在本地環境完成設計工作的人來說,local-first 的架構尤為吸引。開發者亦可將其整合到現有的編碼工作流中,讓 AI 代理同時負責程式碼與設計兩個層面。

以下是這個項目的重點摘要:

  • 屬於本地優先的開源桌面應用,定位為 Claude Design 的替代方案
  • 核心功能是讓 AI 編碼代理生成設計稿、頁面、儀表板及多媒體內容
  • 強調本地執行,無需依賴雲端服務,保障資料私隱
  • 適用於開發者、設計師及內容創作者快速產出原型與行銷素材
  • 社群關注度高,GitHub 上已累積超過 7.5 萬顆星

由於該項目仍處於活躍開發階段,功能成熟度與跨平台支援等細節尚未完全明朗,建議有興趣的使用者持續關注其更新進度。

項目主頁

以下是該網頁主要內容(麻省理工學院電子工程與計算機科學系 MIT EECS 的訪談文章)的繁體中文翻譯:

(more…)
Categories: 開源, Agentic, MCP, Vibe Coding, 編程, 安全, Skill 技能

LlamaIndex legal-kb:用代理工具重新定義法律文件檢索

LlamaIndex 開源 legal-kb 參考應用,將 Index v2 檢索封裝成 retrieve、find、read、grep 四種工具,供代理靈活查詢法律文件。

Og image

legal-kb 是 LlamaIndex 在 GitHub 上發佈的開源參考應用,定位為法律文件知識庫,並非函式庫。它採用 LlamaIndex Index v2(LlamaParse Platform)作為底層索引引擎,示範一種稱為 Retrieval Harness 的代理式檢索模式,讓 AI 代理以工具呼叫方式查詢文件。

與傳統單次嵌入搜尋不同,這個項目讓代理在每次提問時,能像工程師操作檔案系統那樣,自行組合多種檢索方式。系統提供四個工具:retrieve 執行混合語意搜尋並可選擇重新排序;findFiles 依檔名或子字串搜尋文件;readFile 讀取指定檔案的原始內容;grepFile 用正則表達式在檔案內搜尋特定模式。四個工具都對應 Index v2 的檢索 API。

運作流程是用戶登入後建立項目,上傳文件會自動在背景解析並建立 LlamaCloud Index v2,每個項目對應一個託管索引。聊天代理在對話中即時查詢該索引,由代理決定呼叫哪些工具、依照什麼順序執行,逐步收斂到答案。

由於工具設計貼近通用檔案操作,開發者可以將 Retrieval Harness 接入自己的代理,處理大量且持續更新的文件集合。法律研究、合規審查、文件審計等工作流會較受惠。

重點摘要:
– 開源參考應用,示範 Retrieval Harness 代理檢索模式
– 四個工具:retrieve(混合語意搜尋)、findFiles(檔名搜尋)、readFile(讀取檔案)、grepFile(正則搜尋)
– 每個項目自動對應 LlamaCloud Index v2 託管索引
– 文件上傳後於背景自動解析與索引
– 工具通用,可接入自訂代理處理大型動態文件庫

項目主頁

Categories: 開源, Agentic, Embedding, API, 庫

人工智慧代理工具選擇完整指南

當 agent 可用的工具從五個增加到四十個以上,模型會出現「工具幻覺」(tool hallucination) 現象。AI Agent 工具越多反而越易選錯?本文介紹六種縮窄選擇範圍的實用方法。

Og image

這是一篇關於 AI Agent 工具選擇策略的技術教學文章,主要用於解釋 agent 系統在工具數量增加時為何會出現準確度下降,以及如何在規模擴展時維持工具選擇的可靠性與效率。

當 agent 可用的工具從五個增加到四十個以上,模型會出現「工具幻覺」(tool hallucination) 現象,選錯工具的機率大幅上升,響應速度亦隨之下降。文章指出,這個問題的根本原因不在模型能力不足,而是模型在選擇前看到的候選範圍太廣。

文章提出六種實用技術來縮窄模型選擇前的可見範圍,包括門控 (gating)、檢索 (retrieval)、路由 (routing) 與規劃 (planning)。這些方法的核心思路是在模型做決定之前,先用結構化方式過濾掉不相關的工具,從而降低選擇負擔。

與其動輒升級模型規模,更聰明的方式是控制模型「看見什麼」。同時,亦建議建立後備邏輯 (fallback logic) 與基準測試框架 (benchmark harness),以便量度各項修正措施是否真的有效。

這項指南最適合正在設計或維護企業級 AI Agent 的開發者,特別是那些工具庫

項目主頁

Categories: Agentic, 教學


NL2SQL 如何走向企業級數據智能體

這項文章整理 NL2SQL 由語義解析到智能體化的演進重點,說明它點樣由「寫 SQL」變成「理解業務查數」。

Og image

這是一篇介紹 NL2SQL(Natural Language to SQL)與 Text2SQL 技術演進的技術文章。它主要說明系統如何把自然語言查詢轉成可執行、可驗證,而且符合業務語義的 SQL,而不只是做文字層面的翻譯。

文章指出,NL2SQL 真正處理的是「業務語言」與「資料庫結構」之間的落差。使用者問的是模糊的商業問題,系統卻要完成查詢意圖理解、表與欄位定位、JOIN 路徑規劃、SQL 校驗、執行與結果驗證,所以它同時牽涉 NLP、資料庫、程式生成、資訊檢索與系統工程。

和早期把 NL2SQL 視為 Seq2Seq 翻譯任務的做法相比,文中更強調執行語義等價。一段 SQL 就算語法正確,也可能選錯表、誤解指標口徑,或者在聚合粒度、過濾條件與權限範圍上出錯,因此企業場景的重點不是「生成像 SQL 的文本」,而是產出能在真實數據環境中正確運作的查詢邏輯。

  • 技術演進由規則模板、傳統語義解析、Seq2Seq,一路走到 Schema Linking、Schema-aware、Graph-based、RAG + LLM
  • 核心難點不只在生成 SQL,更在表、欄位、值與業務指標的語義映射
  • 新一代方向是 Agentic + Semantic Layer,加入檢索、規劃、校驗、修復與解釋能力
  • 固定報表場景可用模板法提升穩定性,但覆蓋率有限,難應付開放式提問

這類內容最適合數據平台、BI、自助查數與企業 AI 問答工作流的讀者閱讀。文中提供的是技術脈絡與方法拆解,暫時未見具體安裝流程、下載連結或可直接啟用 OpenClaw、OpenCode、Codex、Hermes Agent、Copilot、Pi 的後台操作資訊,因此不能延伸成相關部署教學。

項目主頁

Categories: Agentic, RAG, OpenClaw

Google A2UI 想讓 AI Agent 直接講出介面

A2UI 不是聊天模型,而是一套讓 AI agent 產生互動介面的開源格式與函式庫。它主打安全、可跨平台渲染,適合要把 agent 接入產品的人。

Gallery of A2UI components

A2UI 是一個開源框架/協定格式項目,核心是讓 AI agent 用宣告式 JSON 產生可更新的互動介面。它要解決的問題很直接:agent 不只回文字,還可以安全地把表單、卡片、按鈕等 UI 交畀前端或原生客戶端渲染。

這個項目的取向,和直接讓 LLM 輸出 HTML、JavaScript,或者在前端執行 agent 生成程式碼很不同。A2UI 把介面描述同實際元件庫分開,client 只會渲染已預先信任的元件 catalog,安全性較高,但代價是自由度受 catalog 和 renderer 能力限制,並非想畫甚麼介面都可以即時做到。

現有資料顯示,A2UI 仍屬 early stage public preview,目前生產版本為 v0.9.1,v1.0 specification 則是 release candidate。部署與理解方式上,它較像一個要接入現有產品的基礎層:agent 端輸出 A2UI JSON,client 端用對應 renderer 轉成 Flutter、Angular、Lit、Web 或其他原生 UI;官方網站有 Quickstart、Client Setup、Agent Development 同 renderer 文件,但這份資料未列出完整安裝流程,亦看不到一鍵接入 OpenClaw、OpenCode、Codex、Hermes Agent、Copilot、Pi 的管理介面整合資訊。

它的優勢,在於增量更新和跨框架可攜性。README 提到 UI 會以扁平元件清單加 ID 關聯表示,這種結構對 LLM 較友善,也方便串流更新;同一份 A2UI payload 理論上可以映射到不同客戶端。相比綁死某一個前端框架的做法,這更適合多端產品、內部工具平台,或者需要跨信任邊界把 agent 能力交到用戶手上的團隊。

重點可概括為:
– 不是模型,而是讓 agent「講 UI」的協定與函式庫
– 核心賣點是安全渲染,避免直接執行 LLM 生成程式碼
– 支援增量更新,較適合串流式互動介面
– 可對接多種前端技術,但前提是要先有 renderer 和元件 catalog
– 文件已見版本演進與示範場景,公開資料未提供明確性能跑分

性能與現有內容較著重設計理念、版本演進與示範,而不是基準測試數字,所以不宜把它理解成追求速度排行榜的項目。較可能受益的是正在做 agent 產品的前端團隊、平台工程團隊,以及需要把資料收集、任務委派、跨端 UI 呈現整合起來的企業應用;相關技術脈絡則包括 AI agents、MCP、Flutter、Angular、Lit、React、SwiftUI,以及 A2A extension。

項目主頁 · GitHub

Categories: 開源, Agentic, MCP, Google, 框架, OpenClaw

Page 21 of 35
1 … 19 20 21 22 23 … 35