先講結論。這篇不是「盤點兩個新模型」的媒體稿，而是想解一個技術判斷題：
2026 年 6 月，兩個都基於 Qwen3.5-9B 、都掛 Apache 2.0、都在同月開源的模型，H Company 的 Holo 3.1 跟 Empero AI 的 Qwythos-9B ，我到底該用哪一個？
實測跑過兩週後，我的答案變成：兩個都要。它們不是同一條賽道上的競爭者，而是同一台本地 Claude Computer Use 的左手跟右手——一個是眼睛加雙手，一個是大腦加嘴巴。這篇就是把「為什麼」跟「怎麼做」拆給你看。
為什麼今年開源社群長得越來越像 Qwen3.5 生態圈
先鋪一下背景，這件事比模型本身更有意思。
過去半年，開源社群幾乎所有值得注意的專門化模型都往同一個基座靠：Qwen3.5。原因不神秘——Qwen3.5 提供了 0.8B 到 397B 的完整 dense/MoE 家族、原生 262k 脈絡、hybrid GDN+Attention 架構、以及真正商用友好的 Apache 2.0 授權。這在 Llama 4 的社群授權還有 700M MAU 上限、Gemma 有自訂條款的環境下，幾乎沒得挑。
於是我們看到的畫面是：Qwen 團隊把「作業系統」造好，其他實驗室在上面裝專用軟體。Holo 3.1 是「電腦操作」這個 app，Qwythos-9B 是「Claude 級推理」這個 app。兩個 app 都不重造輪子，都拿 Qwen3.5 當 kernel。這個現象跟去年 Llama 3 一枝獨秀時完全不同——基座之爭已經結束，戰場搬到後訓練專門化了。
理解這一點之後，同月出兩個 Qwen3.5 微調模型就不是巧合，而是常態。而能不能組合起來，才是判斷開源生態成熟度的真正指標。
Holo 3.1：把螢幕看懂、把滑鼠鍵盤打通
Holo 3.1 是 H Company 於 2026 年 6 月 2 日發布的 Computer-Use Agent VLM 家族。它做的事情很純粹：吃一張螢幕截圖 + 一個自然語言目標，吐出「下一步要點哪、打什麼、滾多少」。
家族尺寸從 0.8B 一路開到 35B-A3B MoE，跟 Qwen3.5 一一對應。旗艦款 35B-A3B 依社群拆解（對應 Qwen3.5-35B-A3B）大約是 256 個 experts、top-8 routing，激活參數只有 3B——白話就是「35B 級的能力，但推理速度接近 3B」。這對本地部署是天大的好消息，VRAM 帳單走總參數（Q4 大約 21GB），算力帳單走激活參數，24GB 的 RTX 4090 剛好塞得下。
真正拉開跟 Holo 3 差距的是三件事：
- 手機加進來了。AndroidWorld 從 67% 直接跳到 79.3%，4B/9B 也從 58% 拉到 71%
- Native function-calling。之前是 prompt 硬擠 JSON，現在是原生工具呼叫協議，跟任何 ReAct 框架能直接兼容
- 量化 checkpoint 三件套：NVFP4 給 DGX Spark、FP8 給 H100、Q4 GGUF 給消費硬體跟 Apple Silicon
我在自己 DGX Spark + NVFP4 + vLLM 環境下實測，35B-A3B 的 agent step time 從 FP8 baseline 的 6.8 秒直接砍到 3.3 秒（用 OSWorld 任務子集，10 步平均）。跟 H Company 官方 blog 揭露的 ~2× 端對端加速數字對得起來。這已經不是優化，是換引擎，夭壽。
放在整個 Computer-Use 賽道看，Holo3.1 的定位大概是：單一開源模型級別逼近人類基準。AndroidWorld 人類基準 80.0%，Holo 拿 79.3%；OSWorld-Verified 人類基準 72.4%，Holo 大約也逼到 80% 附近的水位。跟 ByteDance 的 UI-TARS-2 （OSWorld 47.5% / AndroidWorld 73.3%）相比，Holo 在同尺寸級別領先明顯。
但注意「單一模型」這四個字。H Company 自家的 Surfer 2 agent 系統把 OSWorld 拉到 60.1%、AndroidWorld 拉到 87.1%（見 Surfer 2 論文 arXiv 2510.19949 ），那是「Holo 當模型 + agent 框架」的組合結果。Holo 3.1 提供的是最強的零件，不是完整方案。這件事等下講雙引擎的時候會回來。
Qwythos-9B：把 Claude 的推理鏈灌進 9B
Qwythos-9B（全名 empero-ai/Qwythos-9B-Claude-Mythos-5-1M）是 Empero AI 在同月釋出的推理模型。它跟 Holo 3.1 用同一顆基座——Qwen3.5-9B——但完全不做 Computer-Use。
它做的是把 Claude Mythos 5 跟 Claude Fable 5 的推理鏈路徑，用 500M+ tokens 的 trace 資料，全參數 SFT 灌進一顆能跑在筆電上的 9B 模型。訓練用了兩階段課程學習：先廣泛推理語料，再聚焦 agentic + coding，用 bf16 + paged AdamW 8-bit + chunked NLL assistant-only loss。
技術亮點三個：
- 1,048,576 token context：從 Qwen3.5 原生 262k 用 YaRN factor=4 直接擴到 1M。消費硬體開 32k~128k 較實際，48GB A6000 才能吃到接近全窗
- 原生 function-calling：官方 tool-use test 拿 7/7，且答案帶真實來源引用
- 深度無審查：官方 model card 明講「engage seriously with cybersecurity, red-teaming, pharmacology, clinical medicine」。這是把雙面刃
跟 Qwen3.5-9B base 相比，Qwythos-9B 在 MMLU 上 +34.3，GSM8K strict-match +30.0（flexible-extract 口徑則是 +19，官方 model card 兩個都給了，我這裡取 strict 是為了避免 extraction 誤差干擾）。這差距不像是同尺寸 fine-tune 該有的，比較像「9B 皮、Claude 骨」。
它適合的場景是那些要讀很多、想很深、講很久的活：長文件分析、整個 codebase 一次讀進 context、多步 agent 工作流、需要 Python executor 驗證的長推理。不適合的場景也很清楚：想要輕鬆閒聊、沒有 GPU、不想處理 <think> 區塊、面對消費者的產品——因為它會直接回答那些多數對齊模型會拒絕的問題，安全層要自己補。
為什麼兩個放一起，就變成 Claude Computer Use
看到這裡應該有感覺了。Holo 3.1 缺什麼？思考深度。Qwythos-9B 缺什麼？眼睛跟手。
這不是巧合。Computer-Use Agent 的兩大瓶頸就是這兩個：
- 看不清螢幕：早期 Claude Computer Use 常在 GUI 邊界判斷失誤，Anthropic 內部承認純 LLM+screenshot 的 grounding 有天花板
- 想不夠深：純 Vision-Language Model 為了 UI grounding 犧牲了長脈絡與深度推理，這是 UI-TARS 系列在複雜跨應用任務會卡住的主因
Holo 3.1 把 grounding 這面推到接近人類；Qwythos-9B 把 reasoning 這面推到接近 Claude。你把它們串成一個雙引擎 agent loop，就在自己電腦上組出了功能等價於 Claude Computer Use 的完整堆疊，而且完全離線。
架構長這樣：
使用者自然語言目標
↓
Qwythos-9B（高階規劃 + 1M context，讀歷史操作/文件/規格）
↓ function_call
Holo 3.1（低階執行 + 螢幕理解，決定像素座標動作）
↓ action
Sandbox / OS（執行動作 → 新截圖）
↑ 回到 Holo，狀態摘要回到 Qwythos
↓ 迴圈直到完成
最終結果 → 使用者
分工邏輯很簡單：Qwythos 收「目標 + 完整歷史脈絡 + 上次截圖的文字描述」→ 輸出「下一步計畫 + 要 Holo 執行的 tool_call」。Holo 收「這個 tool_call + 當前截圖」→ 輸出「像素座標動作」。動作執行完，新截圖回到 Holo，狀態摘要回到 Qwythos。
一台 24GB VRAM 的 RTX 4090，可以同時裝 Qwythos-9B Q4 GGUF（約 5.6GB）+ Holo-3.1-9B Q4 GGUF（約 6GB），剩下 12GB 留給兩顆的 KV cache。或者 M3 Max 64GB 統一記憶體全跑起來，一台筆電就是完整推理 rig。
OpenClaw：兩個模型碰上生態圈的巧遇
理論組合聽起來很美，實務要怎麼把兩個 llama-server 綁進同一個 agent 框架？答案是 OpenClaw ，一個由 Peter Steinberger 在 2025 年底開源的本地優先 agent runtime，社群成長很誇張——推出 24 小時內就衝破 9000 星，到 2026 年 Q1 已經是六位數等級的專案。
有趣的是，兩個模型跟 OpenClaw 的關係並不對稱：
| 模型 | OpenClaw 整合 | 證據 |
|---|---|---|
| Holo 3.1 | 有專門部署教學 | KnightLi 部落格 Holo 3.1 Local Deployment Guide 手把手教你用 openclaw skills install agent-browser 把 Holo 掛進 gateway（該站點會導向自訂 port，若瀏覽器擋下請手動信任） |
| Qwythos-9B | 沒專屬教學但通用可行 | 官方文件只講 vLLM / SGLang / Transformers / Ollama。因為 OpenClaw 支援任何 OpenAI 相容端點，Qwythos 可以透過 Ollama provider 間接接上 |
差距在哪？Holo 3.1 是 GUI 專職模型，跟 OpenClaw 的 agent-browser skill 幾乎是零距離的天生一對——它就是為了 browser/desktop 操作而生。而 Qwythos 定位是「推理 + tool use」文字模型，OpenClaw 社群還沒有為它做專案，但它拿 7/7 tool-use test 加上 function-calling 支援，是 OpenClaw primary model 的優質候選。
換句話說，Holo 是已被 OpenClaw 生態圈收編的模型，Qwythos 是可以但還沒被收編的模型。有沒有覺得這缺口剛好是給你的機會？
實作：把兩個模型掛進同一個 OpenClaw
前置條件講在前面：
- macOS / Linux / Windows（我在 M3 Max 64GB 跟 Ubuntu + RTX 4090 上都測過）
- llama.cpp 或 Ollama 至少一個
- OpenClaw（Homebrew 或官方 installer）
- Chrome（如果要跑 browser skill）
第一步：用 llama.cpp 起 Holo 3.1 的 server
從 Hugging Face 抓 Hcompany/Holo-3.1-9B-GGUF 的主檔跟 mmproj 視覺投影檔，這裡 mmproj 常被漏掉，漏了就沒有視覺輸入。
llama-server \
-m ./models/holo-3.1-9b.q4_k_m.gguf \
--mmproj ./models/holo-3.1-9b-mmproj.f16.gguf \
-ngl 999 -c 8192 -fa \
--temp 0.2 --top-p 0.9 \
--host 127.0.0.1 --port 8081
第二步：用 Ollama 起 Qwythos
ollama run hf.co/empero-ai/Qwythos-9B-Claude-Mythos-5-1M-GGUF:Q4_K_M
Q4_K_M 檔案約 5.2GB，跑起來一顆 8GB VRAM 就夠。Ollama 預設會開 http://localhost:11434 的 OpenAI 相容端點。
第三步：讓 OpenClaw 認識這兩顆模型
編輯 ~/.openclaw/config.json（不同版本路徑可能略異，用 openclaw config path 確認）：
{
"agents": {
"defaults": {
"model": { "primary": "ollama/qwythos-9b" }
}
},
"models": {
"providers": {
"ollama": {
"baseUrl": "http://localhost:11434",
"apiKey": "ollama-local",
"api": "openai-completions",
"timeoutSeconds": 300,
"models": [
{
"id": "hf.co/empero-ai/Qwythos-9B-Claude-Mythos-5-1M-GGUF:Q4_K_M",
"name": "Qwythos-9B",
"reasoning": true,
"input": ["text"],
"contextWindow": 131072,
"maxTokens": 8192
}
]
},
"holo-local": {
"baseUrl": "http://127.0.0.1:8081/v1",
"apiKey": "sk-local",
"api": "openai-completions",
"timeoutSeconds": 120,
"models": [
{
"id": "holo-3.1-9b",
"name": "Holo 3.1 9B (Vision)",
"reasoning": false,
"input": ["text", "image"],
"contextWindow": 32768,
"maxTokens": 2048
}
]
}
}
}
}
Qwythos 當 primary（負責思考跟規劃），Holo 當 vision 專用 provider（負責螢幕跟動作）。context window 我先給 131k 是保守值，硬體允許再拉。
第四步：裝 browser skill，把 Holo 綁上去
openclaw skills install agent-browser
openclaw doctor
openclaw gateway restart
agent-browser 這個 skill 會自動下載 Playwright + Chromium。裝完後可以在 skill 設定裡指定「vision model 用 holo-local/holo-3.1-9b」，這樣主 agent（Qwythos）就會把螢幕理解任務外派給 Holo endpoint。
第五步：試一個真實任務
在 OpenClaw chat 輸入：
「打開 hcompany.ai/holo3.1，找出 Holo 3.1 的 4B 模型在 AndroidWorld 的分數，
把來源 URL 一起回給我。」
會看到 Qwythos 先規劃步驟（<think> 區塊會冒出來），呼叫 browser skill 開頁，Holo 看截圖決定要往哪 scroll、要點哪個連結，資料回到 Qwythos 整理成有引用的答案。這就是本地版 Claude Computer Use 的最小可行迴圈。
踩過的坑跟一定要記的事
實測兩週，踩到的雷整理如下。
坑一：Holo 3.1 各尺寸授權沒完全確認
只有 0.8B 我親眼看到 Apache 2.0 明確標示。4B / 9B / 35B-A3B 的 Hugging Face model card 我建議每一顆都自己去確認一次，特別是打算商業部署的話。H Company 上一代 Holo1.5 是「3B 掛 Qwen license、7B 掛 Apache 2.0、72B 掛 research-only」的分級模式，Holo 3.1 不保證統一。
坑二：Qwythos 的 <think> 區塊
如果你把 Qwythos 接到使用者可見的 UI，<think>...</think> 會直接被吐出來，用戶會看到一大坨推理過程。正確做法是在 gateway 層過濾掉，或者把 reasoning 顯示切成摺疊區塊。
坑三：1M context 不代表消費硬體吃得下
Qwythos 的 config 寫 max_position_embeddings: 1048576，但 KV cache 會爆。8GB VRAM 建議只開 32k，24GB 開 128k，48GB 才有機會逼近全窗。不要看到 1M 就無腦塞整個 codebase，會 OOM。
坑四：Holo 3.1 GGUF 漏掉 mmproj
llama.cpp 的視覺模型要主檔 + mmproj 兩個檔一起載入。只載主檔，模型會啟動成功但看不見圖，這是最常見的初學者陷阱。
坑五：Qwythos 未審查是雙面刃
它是刻意 uncensored 的模型，你在自己實驗室跑當然沒問題，但只要要 serve 給外部使用者、或者接到公司內部系統，應用層 guardrail 必須自己補。Empero 的 model card 已經寫清楚這點，別假裝沒看到。
坑六：OpenClaw 對 tool_choice 的預設
OpenClaw gateway 預設 tool_choice: "auto"。Qwythos 因為每回合都會走推理再決定要不要呼叫工具，通常 auto 剛好；但如果你想強制每回合都用工具（例如純 agent workflow），要在 config 手動蓋成 "required"：
"agents": {
"defaults": {
"models": {
"ollama/qwythos-9b": {
"params": { "extra_body": { "tool_choice": "required" } }
}
}
}
}
誰該做、誰別做
不是每個人都需要組這個雙引擎。用途對應建議是這樣：
| 情境 | 建議 |
|---|---|
| 想試試「本地 Claude 助理操作我電腦」 | 雙引擎全套上，M3 Max 或 24GB VRAM 起步 |
| 只想跑 browser 自動化，不需要深度推理 | Holo 3.1 4B / 9B 單獨用就好，Qwythos 是浪費 |
| 只想讀 codebase / 論文，不操作電腦 | Qwythos-9B 單獨用，Holo 是浪費 |
| 想做無審查資安研究 | Qwythos + Docker sandbox，Holo 選配 |
| 面對消費者的產品 | 兩個都不建議直接用，未審查跟企業對齊差距太大 |
| 資源極少（8GB 以下） | Holo-3.1-0.8B 單引擎，Qwythos 最小也是 9B |
| 想要極致速度 | 別用 Qwythos，<think> 會拖 UX，改用 Holo + 更輕的規劃模型 |
結語：開源社群的成熟度訊號
我覺得 Holo 3.1 跟 Qwythos-9B 最值得記住的不是任何一個 benchmark 數字，而是它們同月由不同團隊獨立發布，卻能無縫組合這件事。
過去我們談開源 AI 生態，常常是「這個模型跟那個框架不相容」「這家的 tokenizer 跟那家不合」的碎片化狀態。而現在因為 Qwen3.5 這個共同底座、Apache 2.0 這個共同授權、OpenAI-compatible API 這個共同介面，你可以把兩個素不相識實驗室的模型，在同一個 gateway 裡兜成一個完整產品。
這個能兜起來的能力，本身就是開源社群長大的訊號。
如果你正在做本地 AI agent 相關的東西，這個週末花兩小時把 Holo + Qwythos + OpenClaw 這條線走一次，會比讀十篇 benchmark 分析更有感。硬體剛好 24GB VRAM 或 M3 級筆電的話，你已經比 90% 的 API 使用者更接近「AI 真的在幫我做事」這件事的本質。
參考資料
- Holo3.1 官方發布頁 · H Company
- Hcompany/Holo-3.1-35B-A3B · Hugging Face
- Hcompany/Holo-3.1-9B · Hugging Face
- Hcompany/Holo-3.1-35B-A3B-GGUF · Hugging Face
- empero-ai/Qwythos-9B-Claude-Mythos-5-1M · Hugging Face
- Qwythos-9B Review · Dr. Shouke Wei · Medium
- Holo 3.1 Local Deployment with OpenClaw · KnightLi Blog
- How to Use Qwythos-9B: vLLM, SGLang, and Transformers · KnightLi Blog
- OpenClaw Local Models Documentation
- Best Models for OpenClaw · DeepInfra Blog
- Surfer-H Meets Holo1 · arXiv 2506.02865（Holo1 世代，WebVoyager 基準）
- Surfer 2 · arXiv 2510.19949（Holo + agent 框架的組合分數來源）
- OSWorld-Human Benchmark · arXiv 2506.16042
- ByteDance UI-TARS 對比 · VentureBeat
