Reasonix:DeepSeek AI 編碼 agent,用 cache-first 降低長會話嘅 token 成本

Reasonix

Reasonix 是 DeepSeek 一個面向桌面及終端的 AI coding agent,核心價值唔係花巧介面,而係將長會話裡不斷累積的上下文成本壓低。它適合要一路改檔、一路試工具、一路追問模型的人,特別是團隊日常做修補、重構同埋持續迭代時,對 token 成本同回合延遲都會有明顯感受。

Reasonix 主打 cache-first loop,令 prompt 前綴保持 byte-identical,配合 DeepSeek 的 prefix cache 去提升長會話命中率。項目同時提供 CLI/TUI、桌面端、local browser UI,同埋支援 ACP-compatible editor integration,部署方式亦算直接:CLI 可用 npm 安裝,桌面版則有 macOS、Windows、Linux 套件可選。

Deepseek's ~OFFICIAL Code: RIP Claude,Codex! This is CRAZY GOOD!

Reasonix 唔係純粹包住模型嘅殼,而係圍繞工具呼叫修正、成本控制同 sandbox 權限去設計。/plan 會先要求模型規劃,再進入實作;MCP(Model Context Protocol, MCP)亦作為一等入口,方便把外部工具合入同一個 registry。這種做法較適合重視可控性、可追蹤性,亦需要長時間跑 session 的開發流程。

要留意嘅係,呢條 TypeScript 線已經進入 maintenance mode,主力開發搬去 Go rewrite,同步文件亦指向 main-v2 同 migration guide。現時更合理嘅理解方式,係將佢視為一個仍可用但已凍結方向的終端編碼 agent 版本,重點價值在 cache 效率、工具整合與成本壓縮,而唔係追求最新功能擴張。

  • 長會話下,prefix cache 命中率可維持在 90%+,輸入 token 成本可明顯下降
  • 同一套引擎可喺 CLI/TUI、桌面端、Web UI 同編輯器接入使用
  • /plan、權限控制同 workspace sandbox 一齊限制工具呼叫,取向偏向可控
  • 適合經常改碼、反覆驗證、又在意推理成本嘅個人或團隊

項目主頁 · GitHub

Categories: 開源, DeepSeek, Agentic, MCP, Linux, Mac, Vibe Coding, 編程

DeepSeek-V4-Flash-0731:輕量化 Agent 模型追上大模型

Og image

要兼顧回應速度、部署成本同 Agentic 能力,DeepSeek-V4-Flash-0731 走的是「較少啟動參數換取高效任務表現」的路線。頁面已清楚寫明它與 DeepSeek-V4-Flash-DSpark 採用相同模型結構,並且附帶 speculative decoding module,所以它不只是一般聊天模型,而是明顯朝工具使用、自動化操作與程式任務優化的版本。

它屬於 DeepSeek-V4-Flash 官方正式發布版,取代 preview 版本,並強調 agentic capabilities 有明顯提升。模型卡同時指出它的模型結構與 DeepSeek-V4-Flash-DSpark 一致,代表推理流程很可能圍繞主模型加速草稿模組來設計。

效能數字是最值得留意的部分。它在 Terminal Bench 2.1、NL2Repo、Cybergym、DeepSWE、Toolathlon-Verified、Agents’ Last Exam、AutomationBench Public 等基準上,普遍明顯高於 DeepSeek-V4-Flash(Preview),部分項目亦超過 DeepSeek-V4-Pro(Preview)。這種進步集中在 terminal 操作、程式庫理解、資安演練、軟件修復同工具鏈任務,反映它更像為 Computer-use agents、程式代理與自動化流程而調整,而不只是追求一般問答分數。

  • 與 DeepSeek-V4-Flash-DSpark 同結構,並附帶 speculative decoding module
  • 官方正式版取代 preview,重點提升 agentic capabilities
  • 多個 Agent/編碼基準明顯優於 DeepSeek-V4-Flash(Preview)
  • 啟動參數較少,但表現可與部分強勢閉源模型接近

部署資訊方面,內容只提供一則討論帖,提到可用兩台 DGX Spark 配合 ghcr.io/bjk110/vllm-spark:unholy-fusion-prod-ready 作最少設定部署;但模型頁面片段未列出上下文長度、GGUF 格式量化檔、mmproj、檔案大小、chat template 注意事項或 v2 檔名變更,因此不能推斷 llama.cpp、Ollama、LM Studio 的支援細節,也不能提供 Q4_K_M 一類量化建議。現有資料較適合把它理解成一個偏向高效率 Agent 任務的 DeepSeek 模型發布,而不是本地 GGUF 部署導向的模型。

模型

Categories: 開源, DeepSeek, Agentic, LLaMa, Ollama, 模型

DeepSeek-V4-Flash 公測版重點更新

Og image

想用同一個 API 入口處理寫碼、自動化操作同工具調用,2026-07-31 呢次更新最值得留意。DeepSeek-V4-Flash 正式版已經開放 API 公測,調用方式維持不變,只要把模型名稱設為 deepseek-v4-flash,就可以切換到最新版本,對現有接入項目來講改動相對少。

今次更新的重點唔係介面改版,而係 Agent 能力明顯加強。官方列出的 Terminal Bench 2.1、NL2Repo、Cybergym、DeepSWE、Toolathlon verified 同 Automation Bench (Public) 等基準分數,都指向同一件事:V4-Flash 針對 Coding Agent、終端操作、工具使用同全棧開發場景做咗強化,而且公開測試成績已經高過 V4-Pro-Preview。

技術上,DeepSeek-V4-Flash-0731 的模型結構、尺寸都同 DeepSeek-V4-Flash-Preview 一致,更新集中在後訓練,意味住提升主要來自調整模型行為,而唔係換咗一個更大架構。它同時原生支援 Responses API 格式,亦有針對 Codex 做適配,對已經圍繞 API 建立 Agent 工作流的團隊會更易接入。

幾個重點可以直接整理如下:
deepseek-v4-flash 已可直接使用正式版 API 公測
– API 調用方式不變,現有項目遷移成本較低
– Agent 能力是今次更新核心,涵蓋 coding、terminal 同 tool use
– Responses API 已原生支援,並針對 Codex 做咗適配
– 今次只更新 V4-Flash API,DeepSeek-V4-Pro API 以及 APP/WEB 端模型未有改動

使用上亦要留意邊界。現有資料有提供模型名、相容格式同基準測試結果,但未見更完整的安裝步驟、下載方式或者端到端接入流程;另外,官方亦講明今次並未更新 DeepSeek-V4-Pro API。對想盡快把 Agent 能力接入現有產品的人,V4-Flash 呢次公測比較像一次低改動、偏向工作流升級的更新。

項目主頁

Categories: DeepSeek, Agentic, API, 工具, Vibe Coding, 模型, 編程

Galahad:12B 凍結模型零解碼作答的工業經驗

Repository image for corbenicai/galahad-bench

這套 Galahad 系統背後的關注點很直接:今天要提升語言模型,就要重訓練,每次都得重新生成答案,既貴又隨機。他們選擇反向操作——模型參數完全凍結,只在旁邊持續累積已驗證的解題記憶。同一個 12B 模型,對於已處理過的題目家族,直接命中記憶中的求解器,整數級精確一致,每次結果都完全相同,而且生成 token 數為零;對於新題目,則照常從零推理解答。系統聲稱在 180 個全新題目、橫跨九個題目家族上,讓四個來自不同供應商、架構各異的開源模型全部拿到 180/180,並且每次回答都不耗任何生成 token。

這個做法最值得留意的,是它對「記憶」一詞的重新定義。系統內部存的是可被獨立外部 oracle 自動驗證的執行式解題結果,不是用相似度檢索找出來的近似片段。作者在特別批評了業界慣用的近似向量相似度檢索:在一個 4,500 條已驗證答案的庫上,這種方法有 94.3% 機率選錯項目,而精確定址則零錯誤。換句話說,對於可驗證、可執行的知識,相似度近似檢索不是表現稍差,而是幾乎不可用,精確定位是必須的設計前提,不是可選偏好。

對於要部署閉環計算、形式化證明、程式碼執行這類可驗證任務的團隊,這套思路很有吸引力:記憶檢索耗時約 1.4 微秒,完整重用流程 6 至 23 毫秒,每次重用只耗 36 毫瓦時電力,相對於一次性求解兼驗證所需的 81.1 瓦時,節能差距明顯。模型本身不重新訓練,能力靠記憶累積,這對想控制運算開支、又需要可重現輸出的場景,例如 CI 中的程式生成或單元測試,是務實的取捨。

但限制也要看清楚:作者指出在公開基準的從零推理上,前沿模型依然遠勝任何 12B;Galahad 的強處是對「已被系統解決並驗證過」的題目家族做到零成本重用,不等於通用智能提升。負面控制也排除了另一種解釋——把記憶清空,系統一道也解不出來,這進一步確認能力確實來自記憶層,不是模型本身突然變聰明。對於想關注的是開源權重能否落地到工業管道的讀者,這份來自 Corbenic AI 的工業經驗報告值得留意,因為它把「訓練之外如何持續累積能力」這條路寫成了可量化的章節。

  • 模型凍結,能力改由外部已驗證記憶承擔,180 題零 token 滿分
  • 精確定址取代向量相似度檢索,在 4,500 條庫上錯誤率 94.3% 對 0%
  • 重用耗時 6–23 毫秒、每次 36 毫瓦時,對比一次性求解 81.1 瓦時
  • 開源模型架構無關:四個不同 dense 與 MoE 模型皆達 180/180
  • GitHub 目前僅放測試頁占位,引擎源碼尚未公開釋出

GitHub · Paper

Categories: 開源, Qwen, Gemini, DeepSeek, 框架, Dataset 數據集

FinanceComplexQA 點評:金融長文件問答基準

Finance-ComplexQA at a Glance

金融問答最容易失真的位置,不是模型識唔識術語,而是它會否真正在整份參考文件入面推理、比對同計數。FinanceComplexQA屬於數據集/Benchmark,焦點不是背答案,而是檢驗 LLMs 和 agents 能否根據完整 reference documents 回答複雜金融問題。

它修正了只靠 parametric knowledge 或抽取單一段落的評測範式。作者把重點放在 document-grounded complex financial QA,要求答案同問題及原始文件一致,並涵蓋 multi-hop reasoning、numerical calculation、comparison、implicit inference、planning、summarization 同 evidence-grounded verification,對 RAG、Agentic workflow 同長文本閱讀能力都有參考價值。

資料結構本身亦有取捨。FinComplexQA-Pro 收錄 2,026 組獨立 QA,按語言、金融場景與任務分類組織;同一題會以 scene_categories 與 task_categories 兩種視角出現,所以總記錄視圖有 4,052 筆。另有 overall 提供 agent_answer、agent_thinking 及 LLM-as-a-judge 分數,但這些分數只適合做診斷訊號,不能當 ground truth。

  • 支援中文與英文,但兩個子集覆蓋的文件領域不同,schema 亦不完全一致
  • 較適合逐個子目錄讀取 JSONL,而不是一開始合併全部資料
  • 可用 exact match、數值容差、F1、semantic similarity 等方法比對輸出
  • 附有 Reference_documents,方便追查 PDF 與 LaTeX 原文證據

部署和測試的理解方式相當直接:資料主要在 Hugging Face 發佈,研究團隊可先挑單一語言、單一 task category 載入,再把模型輸出對照 gold answer 或文件證據做評估。它較受惠於做金融 RAG、長文件 QA、Agent 評測或雙語研究的團隊;要留意的是金融事實具時效性,而且項目已明確標示僅供研究與評估,不應延伸成投資、會計、法律或財務建議。

項目主頁 · GitHub · Paper

Categories: 開源, 微軟, DeepSeek, Agentic, RAG, 多模態模型, 中國, Dataset 數據集

OpenWorker – Andrew Ng 開發桌面 AI 龍蝦

How OpenWorker works

對好多打工仔嚟講,最大嘅困擾唔係 AI 唔夠聰明,而係佢只識得「答問題」而唔識得「做完件事」。OpenWorker 嘅切入點正正喺呢度:佢定位係一個會跑喺你電腦上面嘅 AI 同事,可以幫你整理 calendar、寫 follow-up email、甚至自動出一份 customer brief,最後畀你一份可以直接開嚟用嘅文件,唔係一串對話。

OpenWorker 由 Andrew Ng(吳恩達)相關團隊推出,引擎建基於佢哋自己開發嘅 Python 開源庫 aisuite,呢個庫提供統一嘅 chat-completions API 以及支援工具調用(tool calling)、MCP 等功能。簡單講,OpenWorker 唔係從零寫起嘅 wrapper,而係將 aisuite 包成一個真正面向桌面用戶嘅應用,並且喺原本 aisuite 倉庫入面開發咗一段時間之後,先搬出嚟獨立成 repo。

目前支援 macOS(Apple Silicon)以及 Windows 10/11,用家可以貼上自己嘅 API key 去用 OpenAI、Anthropic、Google Gemini、DeepSeek、Kimi、Qwen、Mistral 等模型,亦可以經 Ollama 完全本地跑開源模型。所有嘢都喺本機行,只有用家授權嘅 model call 或者連接工具先會接觸到網絡。對於注重私隱或者公司政策唔畀數據出 cloud 嘅人,呢個係一個幾實際嘅選擇。

OPENWORKER: The Free AI Desktop Agent That Isn't Locked to One Model

佢亦內建 25+ 個整合,包括 GitHub、Slack、Jira、Notion、Linear、HubSpot、Outlook、Gmail、Google Calendar 等,亦支援任何可以經 MCP(Model Context Protocol)接駁到嘅工具。最令筆者欣賞嘅係佢嘅審批機制:寫訊息、發送郵件、執行 shell 指令呢類「對外有影響」嘅動作,全部都要先經你確認先至會執行,唔會自己靜靜雞撳掣。

以下係幾個用家會比較關心嘅重點:

  • 定位係桌面 AI 同事,目標係交到「成品」而唔止係聊天回覆,例如 HTML brief、Markdown 報告、排好嘅 calendar 更新等。
  • 完全開源、MIT 授權,由 Andrew Ng 團隊開發,引擎建基於佢哋嘅 aisuite 開源庫。
  • 模型自選,支援多間主流 cloud provider,亦可以經 Ollama 完全本地執行開源模型。
  • 重視私隱,對話、token、API key 都儲喺本機 secret store,唔需要登入亦可以用。
  • MCP + 審批機制,所有對外動作(發訊息、執行指令)都會先問過你先做,減低「AI 自行撳掣」嘅風險。

如果你係一個人或者小型團隊,想搵一個可以幫你「跑手」而唔係淨係「傾偈」嘅 AI 工具,又唔想將公司敏感資料送去閉源服務,OpenWorker 算係一個值得試嘅選擇。佢而家仲喺 open beta,官方表示會自動更新、不斷執吓啲 bugs,畀用家提交 issue。適合想認真將 AI 融入日常工作流、對私隱同可控性有要求嘅人。

項目主頁 · GitHub

Categories: 開源, Qwen, Google, Gemini, DeepSeek, OpenAI, API, MCP, 工具, Mac, Ollama, Python, Anthropic, 蘋果, Kimi

Trace 用可驗證資料重做視覺推理訓練

trace mark

很多視覺推理資料集都只交付圖片同答案,模型答啱咗,未必代表推理過程真係站得住腳。Trace把重點放在可驗證 post-training:它屬於一個資料集兼生成環境,針對的問題是怎樣穩定產生 grounded visual-reasoning 任務,並且讓答案、標註與驗證流程互相對得上。

它採用一條很清晰的生成路線:domain → scene grammar → task program。現有做法常見是先有人手整理題目,或者由圖像與文字鬆散配對,再用最終答案做監督;Trace則用 deterministic seed 先建立 semantic scene state,再由 task program 從同一個狀態推導 typed answer、verifier state,最後才渲染圖片與提示。這種 shared-state 設計的分別,在於題目不是「生成完再補標註」,而是從源頭就把圖像、問題、答案同 execution trace 綁定。

對研究團隊來說,這個取向很有吸引力,因為它同時照顧訓練、檢查同重播。每個例子除了 image、prompt、typed answer,還有 image-space annotation、verifier metadata 同 execution trace;對想做 RLVR、後訓練驗證,或者想分析模型到底錯在觀察、計算還是規則理解的人,資料密度比一般 benchmark 高得多。

  • 收錄 11 個 visual domains、277 個 scene grammars、1,000 個任務
  • 已公開 66,000 個 generated examples,亦提供 Hugging Face dataset 與模型檢查點
  • 驗證不只看最終答案,還保留 verifier state 與 replayable execution trace
  • 以 Qwen2.5-VL-3B、Qwen2.5-VL-7B 做 post-training,兩個尺度都有明顯提升

數字上,它在 2,000 個未見過、但由同一批 task programs 生成的新例子上,將 Qwen2.5-VL-3B 由 24.45 提升到 41.05,Qwen2.5-VL-7B 由 34.25 提升到 51.55。這些結果首先說明 Trace對同分佈泛化有幫助;首頁亦提到用 64,000 個 Trace instances 訓練後,對 24 個外部 benchmarks 的 macro-average 也有改善,但摘要資訊未列完整分項,解讀時仍要看原始報告。

Trace最適合被理解為一個用來建構可核對視覺推理訓練資料的基礎項目,而不只是另一個出題庫。它的取捨也很明確:換來高度可驗證與可重播,代價是任務分佈由 scene grammar 同 task program 明確界定,較適合研究訓練方法、評測設計同模型行為分析,未必等同自然世界的開放式視覺理解。

項目主頁 · GitHub · Paper

Categories: 開源, Qwen, DeepSeek, Image, 多模態模型, 模型訓練, Dataset 數據集

DocOps 直擊文件代理真功夫

DocOps benchmark overview

改 Excel、Word、PowerPoint 同 PDF,最難唔係生成一段合理回覆,而係交返一份可用、冇整爛結構的原生文件。DocOps屬於 benchmark 類型,針對 document-operation agents 而設,重點不是問答得分,而是檢查代理能否把文件改到指定狀態,同時保住公式、樣式、大綱、書籤與格式有效性。

現有評測常落在兩個範式:static document understanding 把文件當成唯讀材料做擷取或問答;workflow-oriented software evaluation 則把文件當成在應用程式之間流轉的附屬品。DocOps反過來把「文件本身」放回中心,用 Harbor 格式整理 210 個可執行任務,再用 deterministic artifact-level verifiers 直接驗最終檔案狀態,這種設計比只看可見文字更能捉到破壞性修改與狀態遺漏。

它的取向相當鮮明:不是追求聊天式流暢回覆,而是拆解 document manipulation 到 content、format、structure 三個維度,再按 L1 到 L4 拉開難度,涵蓋局部原子操作、同文件組合操作、單文件流程,到跨文件工作流程。對研究 agent 能否長步驟維持全局一致性的人來說,這個分層比單一總分更有診斷價值。

  • 收錄 210 個 Harbor tasks,覆蓋四種常見文件格式
  • 內建 deterministic verifiers,驗證原生檔案而非只看輸出文字
  • 提供 DocumentTools、Terminus-2、Codex、Claude Code 等 execution harnesses
  • 支援 skill-on / skill-off 評測,較易分辨工具能力與模型能力

這個 GitHub 項目已包 task、skills、harnesses 同 Docker base images,重點在重現 benchmark run,而不是單獨提供某個辦公自動化工具。現有結果亦說明門檻不低:例如 GPT-5.5 在不同 harness 的表現有明顯落差,Claude Sonnet 4.6、DeepSeek-V4-Pro 等模型亦未見接近滿分,反映文件操作代理距離穩定處理端到端工作仍有一段距離。對做 Agentic 評測、辦公自動化代理、或想比較 skill 與模型邊界的團隊而言,DocOps的參考價值很高。

項目主頁 · GitHub · Paper

Categories: 開源, Qwen, Gemini, DeepSeek, OpenAI, Agentic, 軟件, Robotic, Anthropic, Meta, 百度, Skill 技能, Dataset 數據集

UniVR:視覺推理訓練變成可控工作流

UniVR Overview

UniVR 係一個能理解我們視覺空間中的思考方式及其在統一視覺推理中的應用,它針對 Emu3.5 unified generative models 的訓練框架,處理的是視覺推理、長程規劃同結果判斷點樣一齊學。它唔係拿來直接做推理展示,而係俾你用自己的資料同獎勵訊號,去微調一個已經懂得處理圖像與文字的底座模型。

SFT(supervised fine-tuning)階段要提供統一格式的樣本:query image、textual instruction、visual reasoning trajectory;RL(reinforcement learning)階段則改成透過 HTTP reward server 送回分數。原始資料沒有提供完整安裝流程,所以目前可確定的只有要把自定義 PyTorch Dataset 接入 UniVR_SFT/train.py,以及把 reward function 換成自己的服務。

和一般只做單次微調的做法相比,UniVR 的取向更偏向「先教格式,再用獎勵修正推理」。它在 RL 端用 GRPO,並配合 HybridEngine 與 Emu3.5 的 vLLM patch,強調 rollout 效率;同時保留 LoRA 同 full-parameter training,適合資源與改動幅度唔同的團隊。

  • 支援多節點 SFT,兼容 LoRA 同 full-parameter training
  • RL 端基於 verl,同 GRPO 搭配自訂 HybridEngine
  • Emu3.5 的 vLLM no-CFG parallel inference 可做到約 2 倍 throughput
  • 獎勵設計分成 format reward、global reward,同 step-level 的視覺推理約束
  • 相關模型包括 Emu3.5 同作為評分器的 Qwen3-VL-30B

較容易受惠的情境包括做視覺代理、機械臂/操作規劃、長程任務推理,或者想將現成視覺模型轉成自己工作流的團隊。它的價值在於把「資料格式、推理軌跡、獎勵判斷」串成同一條訓練路線,令視覺任務唔再只靠靜態標註去學。

項目主頁 · GitHub · Paper

Categories: 開源, Qwen, 字節跳動, Gemini, DeepSeek, OpenAI, Image, Python, 多模態模型, 模型訓練, Dataset 數據集

phone-metrics:少量標註做語音音素切分

Repository image for stephenmac7/phone-metrics

做語音分析時,最麻煩的不只是辨認講了甚麼音,還要知道每個 phone 在哪一刻開始、哪一刻結束。phone-metrics 對應的是一個語音研究項目,重點放在 phone segmentation 與 phone recognition 一起處理,目標是減少標註成本,同時保住辨識效果。

在語音處理中,有兩個核心任務: 音素分割(Phone Segmentation):找出一段話中,每個發音與下一個發音之間的「時間邊界」(例如在哪一毫秒從 [s] 轉變到 [z])。音素識別(Phone Recognition):認出這個發音到底是什麼音(類似音標)。傳統的做法: 這兩個任務通常是分開用不同的 AI 模型處理。而且,要訓練這種模型需要專家耗費大量時間(標註 1 小時的語音往往需要專家花 40 到 100 小時),成本極高。

現有做法常把 segmentation 和 recognition 分開建模,但這項工作認為兩者其實共享同一套語音結構,分開做會浪費訊號。作者改為從 self-supervised speech model(S3M)的表示中抽出 phonological feature activations,並用 SPAM(S3M-based Phonological Activation Mapping)把每個時間 frame 轉成像 voicing、nasality 這類語音特徵,再接兩個輕量、毋須 gradient descent 的 prediction heads,分別負責切分與辨識。

這個取向最值得留意的地方,是它對資料量要求很低。資料指出,少於一分鐘、而且帶 time-aligned phonetic transcriptions 的標註已可運作;同時它還能處理訓練期間未見過的 phones,對低資源語言、zero-shot phonetic analysis,甚至做跨語言比較都幾有吸引力。

  • 把 phone segmentation 與 phone recognition 聯合處理,唔再拆成兩個獨立流程
  • 依賴 self-supervised speech model(S3M)內部已有的語音結構,而唔係完全重新學起
  • SPAM 先把 frame 映射成 phonological activations,再交由兩個輕量 prediction heads 輸出結果
  • 標註需求非常低,少量 time-aligned phonetic transcriptions 已可測試方法價值
  • 已報稱在多個資料集上達到 SOTA phone segmentation,並取得穩健的 recognition 表現

部署和驗證這類項目時,較合理的理解方式不是把它當成即裝即用產品,而是研究型 pipeline:先準備語音資料與對齊好的音素標註,再接入 S3M 表示,之後檢查 segmentation 邊界與 recognition 輸出。它較適合語音研究團隊、低資源語言項目,或者想用更少標註測試新語音單位分析方法的人;若你要的是完整語音轉文字應用,它就不是直接替代 ASR 的那一路。

項目主頁 · GitHub · Paper

Categories: 開源, DeepSeek, Medical醫學, 影像處理, 語音, Dataset 數據集

Page 1 of 4
1 2 3 4