Anthropic

Octafuse Gateway：幫 Agent 管好多模型入口

2026 年 7 月 31 日

Octafuse 團隊把重點放在 Agent 工作流，而唔係只做一個轉發請求的薄層。Octafuse Gateway 屬於可自託管開源 AI gateway，處理的是多供應商模型、圖像、語音轉寫同 Agent Tools 分散管理的問題，特別適合已經有多組 API Key、不同模型來源，甚至自建服務要一齊協調的團隊。

它最有價值的地方，在於把「接得通」進一步做成「管得住」。同類項目常見重點是模型代理與相容 API，Octafuse Gateway 另外加強了路由、故障轉移、預算、審計、三賬本計費，同埋公開能力目錄，令 Agent 可以透過統一入口發現同調用資源，而管理者亦可以追蹤成本與用量。

部署方向，支援 Cloudflare Workers + D1，以及 Docker 配合 Postgres / MySQL 自託管；Node.js 20+ 亦是明確要求。原始資料未展示完整安裝步驟，但有 operator 文件、Admin 管理界面、Playground 同 Simulator，反映它不是只給開發者讀 API 文件，亦有一套管理與聯調介面可用。

兼容 OpenAI Chat Completions、Anthropic Messages、Gemini、OpenAI Images 與 OpenAI Audio Transcriptions API
可集中管理 Provider API Key、RPM / TPM、並發、熔斷狀態與剩餘容量調度
內置 Provider 與模型導入模板，減少逐個端點手動維護
提供 /v1/tools/* 接入 Agent Tools，現有 web-search、web-fetch、web-deep-search
有 Playground、Simulator、審計與成本觀察能力，方便排查路由與計費設定

它強調的是可靠調度與營運控制，而非單一模型跑分。對需要向內部團隊、客戶或不同項目發放獨立 API Key 的環境，這種以資源治理為核心的取向，比單純聚合模型端點更完整，但相對也代表配置面會更廣，較適合已有多模型、多使用者或多成本中心需求的團隊。

GitHub

Categories: 開源, Gemini, OpenAI, Agentic, API, Anthropic, 框架

Anthropic Opus 提示詞外流反映了什麼

2026 年 7 月 27 日

想知道大型語言模型點解會用某種語氣答你、點樣處理敏感內容，最直接的方法之一，就是看它背後的 system prompt。這個 GitHub 項目整理了疑似來自 Anthropic Opus 的提示詞內容，重點不在功能展示，而在於把模型行為規則攤開，讓人看到回應風格、安全邊界與工具使用指令可能如何被設定。

對開發者、提示詞研究者同內容工作者來說，這類資料最有價值的地方，在於它把平時只能靠輸出結果推測的設計思路，變成可以直接閱讀的文字線索。你可以更清楚理解模型點樣被要求保持語氣一致、避開高風險內容，或者在多步驟任務中遵守某些優先次序，但同時要留意這類「leaked prompts」未必完整，也未必反映最新版本。

幫助觀察 Anthropic 對模型人格、語氣與安全規則的安排
適合研究 system prompt、AI alignment 同提示詞工程的人參考
能作為分析模型輸出風格的輔助材料，而唔係正式技術文件
內容真確性、時效性與完整度都需要保留判斷

它和一般產品介紹最大的分別，是你見到的不是功能清單，而是控制模型行為的內部文字結構。這種資料未必能直接提升效果，卻很適合用來拆解 AI 產品點樣把品牌語氣、風險控制同任務規則包進同一套提示詞框架。

從使用角度看，這份內容較適合拿來做觀察、比對同研究，不應視為官方文件或穩定接口。對關心 Anthropic、AI 安全同提示詞設計的人而言，它提供了一個少見的切入口，去理解模型輸出背後不只是能力，仲有大量預先寫好的約束。

項目主頁

Categories: Agentic, 安全, 提示詞, Anthropic, Skill 技能

OpenWorker – Andrew Ng 開發桌面 AI 龍蝦

2026 年 7 月 26 日

對好多打工仔嚟講，最大嘅困擾唔係 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

Watch this video on YouTube

佢亦內建 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

ActiveVision 點出視覺推理真空帶

2026 年 7 月 26 日

ActiveVision — An Exam for Active Observers. Vision is a loop, not a glance.

不少視覺題目唔係靠一眼辨認，而係要沿住線追、逐區域數、一步步核對先答得到；ActiveVision 正正針對呢種落差而來。作為一個 benchmark，它集中測試 iterative visual reasoning，處理的是模型看得到畫面，但未必能持續整理觀察過程的問題。

現有多模態模型常見做法是對單張圖作一次性判讀，再配合 chain-of-thought 直接作答；作者認為這種 single-glance 範式，對需要反覆掃描、追蹤順序與維持中間狀態的題型特別吃力。ActiveVision 因此設計了 17 個任務，並用 deterministic program 生成場景，再以 photorealistic 方式重繪，令畫面自然之餘仍保留可驗證結構。

數字相當直接：人類表現為 96.1%，前沿模型在官方無工具評測下最高約 10.6%，差距接近 9 倍。網站亦列出 agent 版本的 tool-use ablation，像 Claude Code 與 Codex 接入工具後，分數明顯高過純 chain-of-thought，表示問題未必只是「看不懂圖」，而是缺少可逐步外化與操作的解題流程。

收錄 17 個任務，重點放在 distributed scanning 與 sequential traversal 一類逐步觀察題
官方評測涵蓋 Claude、GPT、Gemini，亦提供 agent ablation 腳本
數據集可經 Hugging Face 下載，評測程式以 Python 為主
同一靜態圖片也能迫使模型做多步推理，唔靠影片輸入撐起難度

整個 GitHub 項目比較像研究與評測基建，而唔係即用型產品：你需要先下載數據集、配置對應供應商 API，然後用 repo 內的 eval 腳本跑結果。對做多模態模型評測、Agentic 工作流、或者想驗證 Computer-use agents、CUAs 式外部工具協作價值的團隊，它提供了一個很尖銳的檢查點：模型是否真的會「觀察」，還是只會對影像作高階猜測。

項目主頁 · GitHub · Paper

Categories: 開源, Gemini, OpenAI, Agentic, API, Python, 多模態模型, Anthropic, Dataset 數據集

RIPO 直指 LLM 強化學習探索崩塌

2026 年 7 月 26 日

訓練 LLM 做長鏈推理時，最麻煩的不只是算力，而是策略很容易愈學愈保守，最後卡在少數高機率答案附近。RIPO 屬於一個面向 LLM 強化學習的演算法研究項目，針對的正是 PPO-Clip 在後訓練階段常見的 exploration collapse，想解決罕見但關鍵動作愈來愈難被探索到的問題。

作者沒有沿用「再補幾個 heuristic」的路線，而是直接指出舊範式的核心錯位：PPO-Clip 以 Euclidean metric 量度 policy discrepancy，但 policy 本身更貼近一個 Riemannian manifold。呢個幾何不一致會令低機率區域更新過份保守、高機率區域又過份進取，最後令探索能力收縮；Riemannian Isometric Policy Optimization（RIPO）則改為追求等距的 policy update，嘗試同時守住 exploration 與 exploitation 的平衡。

論文描述中，RIPO 另一個重點是 bias-variance trade-off 較理想，令優化過程更穩定。成效方面，它在七個 competition-level benchmarks 上都優於既有 LLM RL algorithms，當中對 GRPO 在 AIME24 的提升最高可達 60%；這類結果相當吸引，但仍然要留意 benchmark 與訓練設置是否能完整轉移到你手上的模型與資料。

核心批評很明確：PPO-Clip 的幾何假設不適合 policy update
方法重心不是加獎勵技巧，而是重寫策略更新的度量方式
對數學推理、長時序決策這類要靠探索找到解法的訓練場景較有價值
成績亮眼，但更適合有能力重跑 benchmark 與訓練流程的研究團隊驗證

從提供的 GitHub 資訊看，儲存庫描述混入了 verl 這個 RL training library 的內容，因此閱讀與部署前要先分清：RIPO 是演算法與論文方向，verl 則較像承載 LLM RL 訓練流程的開源基建。較合理的理解方式，是把 RIPO 視為可整合進現有 LLM RL framework 的新策略更新方法；真正落地通常要配合既有訓練庫、GPU 叢集配置，以及像 GRPO、PPO 一類後訓練 dataflow 一起測試。

GitHub · Paper

Categories: 開源, 字節跳動, OpenAI, 庫, 模型訓練, Anthropic, 清華大學, 框架, Dataset 數據集

DocOps 直擊文件代理真功夫

2026 年 7 月 26 日

改 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, Dataset 數據集, Skill 技能, 百度

PalmClaw 把手機變成可落地 AI 助理

2026 年 7 月 17 日

想在手機上跑 AI 助理，最大問題通常唔係模型夠唔夠聰明，而係行動流程太依賴點擊介面、太多步，又難清楚限制每次操作。PalmClaw 選擇唔跟 GUI 自動化嗰條路走，而係做成一個原生 Android 代理框架，直接在裝置內管理 session、memory、skills、tools 同 agent loop，處理的是「手機可唔可以自己成為代理執行環境」呢個問題。

同類做法很多會把手機當成一個要被點擊、滑動、輸入的目標畫面，PalmClaw則把裝置能力包裝成有明確參數同結構化結果的 device tools。呢個取向的好處很直接：動作邊界更清楚，執行鏈更短，亦較少受介面改版影響；代價是它偏向整合系統能力與通道，而唔係模擬人手操作所有 App 畫面。

安裝理解上亦算直接，項目已提供 APK，重點不是先搭 server，而是把代理本身部署到 Android。應用程式內可管理設定、工具同 channels，並連接 Telegram、Discord、Slack、Feishu、Email、WeCom 等通道；資料與硬件存取留在本機，較適合在意私隱、想減少雲端依賴的個人用戶，或者要做流動工作流驗證的小團隊。

原生 Android 代理框架，重點在裝置內執行而非遙控手機介面
沿用 OpenClaw 啟發，但定位更貼近直接 mobile deployment
提供 APK，可在手機內完成設定、工具管理與通道連接
論文數據提到，相比最強基線有 11.5% 相對任務成功率提升，完成時間減少 94.9%
相關脈絡包括 OpenClaw，以及以 Large Language Model（LLM）agent 為核心的 session、memory、skills、tools 架構

PalmClaw最值得留意的地方，在於它把手機代理由「會操作畫面」改成「直接調用裝置能力」。對想把 AI 助理放進日常通訊與個人裝置流程的人來說，這種 local-first、明確工具邊界的設計，比純粹追求花巧自動化更接近可長期使用的方向；現階段平台重心明確落在 Android，跨平台與生態覆蓋仍要看後續發展。

項目主頁 · GitHub · Paper

Categories: 開源, 香港, 香港理工大學, Gemini, Agentic, Discord, Anthropic, OpenClaw, Skill 技能

Qwen3.6 全新的動態 NVFP4 量化器

2026 年 7 月 10 日

想喺自己電腦上跑到規模較大的多模態模型，最大卡位通常唔係功能，而係記憶體同速度。Qwen3.6 屬於阿里巴巴的新一代多模態 hybrid-thinking 模型系列，重點在於用相對可控的硬件需求，處理 agentic coding、vision 同 chat 等工作。

現有資料提到兩個主力型號：Qwen3.6-27B 同 35B-A3B。前者可在約 18GB 記憶體配置下運行，後者約需 22GB 至 23GB 左右，並支援 256K context 及 201 種語言。對想喺本地做長內容理解、跨語言對話，或者配合工具調用工作流的人來說，這個取向幾實用。

相比只講「可量化、可本地跑」的常見做法，Unsloth 這邊更著重點樣揀到速度與準確度較平衡的版本。Qwen3.6 GGUFs 採用 Unsloth Dynamic 2.0，會按真實使用資料做 calibration，並把重要 layers upcast；另外新推出的 NVFP4 quants 主打在 GPU 上帶來約 2.5 倍更快速度，MTP 則標示可把 inference 再加快 1.4 至 2.2 倍，同時不犧牲準確度。

適合本地部署多模態模型，兼顧編碼、視覺與對話
27B、35B-A3B 記憶體需求相對克制，較易在個人設備起步
GGUF 格式配合 Unsloth Dynamic 2.0，重點是量化後仍保持可用表現
NVFP4 與 MTP 主要改善推理速度，幫助減少等待時間

使用上仍有幾點要留意：總可用記憶體最好高於下載的量化模型大小，否則雖然可經 llama.cpp 用 SSD/HDD offloading 繼續運行，但推理會慢得多；文件亦明確提醒不要使用 CUDA 13.2，以免輸出異常。整體來看，這不是單純把 Qwen3.6 搬到本地，而是把「跑得動、跑得快、精度仍可接受」這幾個取捨整理得更清楚。

所引用的模型列表：Qwen3.6-27B、Qwen3.6-35B-A3B。

項目主頁 · 模型

Categories: 開源, 阿里巴巴, Qwen, NVIDIA, Agentic, API, MCP, Medical醫學, Python, 多模態模型, 模型, 教學, 編程, Anthropic, OpenClaw

UniClawBench 點樣測主動式代理

2026 年 7 月 10 日

比起只問模型識唔識答，UniClawBench更在意代理能否一路做、一路修正，直到完成整個工作流。它屬於benchmark 項目，針對 proactive AI agents 在真實工具、瀏覽器、檔案處理與桌面 GUI 任務中的完成能力，補足傳統單步評測難以反映連續操作表現的缺口。

現有做法常把 agent evaluation 壓縮成靜態問答、固定軌跡重播，或者只看最後答案；作者明確改用 three-role closed-loop evaluation framework，將 executor、hidden answer supervisor 同 public user simulator 分開。呢個設計的重點，是同時檢查代理點樣行動、途中有冇偏離、收到回饋後能否繼續修正，而唔係只計一次輸出啱唔啱。

公開版本提供 400 個雙語任務，英文與中文各 200 個，覆蓋 Skill Usage、Exploration、Long Context、Multimodal、Cross Platform 五類能力。部署思路亦算清晰：倉庫已放入 packaged task resources、Docker-based runtimes、distributed dispatch scripts，同埋可檢視 leaderboard、trace、artifacts 與 timeline 的 WebUI；要跑測試，核心其實是先填好 executor、Codex provider 同 API keys 相關設定檔，再用它的執行環境批次評估。

用 three-role 閉環評測取代一次性答題
任務同時涉及 browser、files、GUI apps 與其他工具
400 個雙語任務，較易檢查跨語言穩定性
WebUI 可回看 traces、artifacts 同示範流程

從補充資料看，作者想指出的取向幾鮮明：framework choice 對能力表現的影響，往往比 model choice 更大，而 long-context 與 multimodal 仍是主要瓶頸。相關模型與組合亦有列出，例如 GPT-5.4、Claude Opus-4.8、Kimi-2.6，並配合 OpenClaw、EDICT、Nanobot 等框架比較；對研究 agent system、企業內部自動化流程，或者想建立較完整評測流水線的團隊，這個項目的參考價值高過單純看排行榜。

項目主頁 · GitHub · Paper

Categories: 開源, 香港大學, OpenAI, Agentic, API, 多模態模型, Anthropic, OpenClaw, 框架, Dataset 數據集, Skill 技能

IdeasHaveGenomes：用血統追蹤科研點子

2026 年 7 月 10 日

只會搵相似論文，已經唔足夠判斷 AI scientist 是否真係理解研究想法。IdeasHaveGenomes 把科學點子當成有 lineage 的對象去看，屬於 benchmark／數據集類型的項目，針對的正是 Auto Research 入面最難驗證的一環：模型能否講清楚一個 idea 由邊度嚟、點樣修補舊限制，最後點解值得延伸。

現有做法好多時集中在 related paper retrieval、proposal writing，或者用開放式生成結果做人手印象分。作者認為呢種範式捉唔到 inheritance tracing 同 evolutionary reasoning，所以提出 IdeaGene-Bench（IG-Bench），把任務分成封閉式測試 IG-Exam，同埋用 Population-Evolution Score（PES）評分的 IG-Arena，前者問理解是否精準，後者先看生成內容有冇 lineage 根據。

項目的可取之處，在於它唔只問「像不像新點子」，而係追問 Heredity、Variation、Selection 有冇成立。資料規模亦算完整，包括 1,961 條 golden lineage traces、1,085 個 Idea Genome objects、920 筆 GenomeDiff records，覆蓋 10 個 scientific domains；IG-Exam 進一步拆成 42 類 task、1,029 個 closed-form instances，適合做可重覆比較。

IG-Exam 主要測 abstraction、inheritance tracing、evolutionary reasoning、lineage verification
IG-Arena 針對開放式提案生成，用 PES 檢查血統延續與變化是否合理
項目可用 OpenAI-compatible API 跑 smoke test 或完整評測，不一定綁死單一模型
現有結果反映難度高，最佳 IG-Exam exact accuracy 只有 27.3%，最佳 T4 verification 為 17.4%
榜單涵蓋 GPT、Claude、Qwen、Gemini、DeepSeek，以及 AI Scientist v2、Codex、Claude Code 等系統

部署理解上，這不是拿來直接替代研究助手的成品工具，而是用來測試模型或 agent workflow 是否真的具備「科研點子血統推理」能力。較適合做 AI scientist、research agent、proposal generation pipeline 的團隊評測基準；想比較不同模型、judge 組合，或者檢查生成提案有冇沿住正確 lineage 發展，這個項目比一般文字基準更有辨識度。

項目主頁 · GitHub · Paper

Categories: 開源, Qwen, 微軟, Gemini, DeepSeek, OpenAI, Agentic, API, Anthropic, 中國, 框架, Dataset 數據集

Page 1 of 4

1 2 3 4 Next »