Ornith 35B 真正有趣的地方，不是「小模型打敗大模型」這句話本身，而是它把本地 AI 編程 Agent 這條路線重新推到桌面上：我們是不是可以把一部分 coding agent 能力，從雲端 API 搬回自己的機器？
這個問題很現實。雲端工具反應快、整合好，但 token 成本、隱私、企業程式碼外流、模型選擇權，始終卡在開發者心裡。本地模型則剛好反過來：你要自己處理硬體、速度、部署與穩定性，但換來的是成本可控、資料留在本地，以及比較完整的架構控制權。
Ornith 1.0 前一篇已經整理過核心定位，這篇換個角度：如果把 Ornith 35B 接進 Hermes 這類 Agent 工作流，它應該放在哪裡？是主控模型、任務 worker，還是只適合做某些短程工具任務？
內容目錄
先講結論：35B 有想像空間，但不要把 benchmark 當保證書
Ornith 35B 的吸引力在於，它不是 397B 那種多 GPU 伺服器級模型，也不是 9B 那種比較像入門測試的輕量模型。35B 落在一個很微妙的位置：高階個人工作站有機會跑，能力又足以進入 coding agent 測試。
官方數據裡，Ornith 35B 在 Terminal-Bench 2.1 拿到 64.2，SWE-bench Verified 拿到 75.6。397B 更高，Terminal-Bench 2.1 為 77.5，SWE-bench Verified 為 82.4。這些分數很漂亮，但漂亮不等於放進你的專案就穩。
| 模型 | Terminal-Bench 2.1 | SWE-bench Verified | 適合觀察的方向 |
|---|---|---|---|
| Ornith-1.0-9B | 43.1 | 69.4 | 低成本本地測試、短程 worker |
| Ornith-1.0-35B | 64.2 | 75.6 | 本地 coding agent 實驗主力 |
| Ornith-1.0-397B | 77.5 | 82.4 | 企業級或多 GPU 私有部署 |
這也是為什麼我不想把它寫成「35B 擊敗雲端大模型」這種單線結論。更準確的說法是：Ornith 35B 在某些 agentic coding benchmark 和視覺/前端生成任務上很值得測，但長程任務和大型 codebase 仍要小心。
Self-Scaffolding RL 到底改變了什麼？
一般 coding agent 常見的架構，是人類工程師先寫好 harness：
什麼時候讀檔、什麼時候跑 command、失敗怎麼 retry、怎麼記憶、怎麼驗證。模型很聰明，但它通常只是被放進這套流程裡填空。
Ornith 1.0 的 Self-Scaffolding RL 想走的是另一條路：
讓模型不只學 solution rollout，也學會產生任務 scaffold。換句話說，它不只是演員，也開始學會改劇本，任務跑得好，解法和引導解法的 scaffold 都一起被獎勵；任務跑得差，兩者都會被調整。
這和 前一篇 Ornith 1.0 介紹裡談到的「先搭工作台，再開始解題」是同一件事。對開發者來說，重點不是模型多會補 code，而是它能不能在遇到限制、錯誤、缺資料時，重新安排自己的工作流程。
Hermes 的位置：還是 harness，但已經比較動態
Hermes 在這裡比較像運行時的動態編排層。它仍然是 harness，但不是傳統那種完全寫死的腳本；它可以在任務過程中調整步驟、改工具、補資料，讓 agent 比較像真的在做一件工作，而不是只照著固定模板回答。
把 Ornith 35B 接進 Hermes 的想像是：Hermes 負責任務框架、工具調用和流程管理，Ornith 35B 負責本地推理、程式生成、局部 debug 與前端/視覺任務。這樣的分工，比「讓 35B 一個模型主控所有事情」更合理。
站上之前有兩篇 Hermes 相關內容可以放在一起看：
Hermes Agent 完整實測 和 Hermes Agent WebUI。如果 Hermes 是工作台，Ornith 35B 就是可以被放進工作台裡的一顆本地引擎。
實測起來
Ornith 的幻覺率仍然偏高，很多 fine-tune 模型 benchmark 強，但長程任務容易歇菜；更穩的方式可能是官方模型搭配優化過的 Jinja template 來跑長程任務。
小模型非常適合做 worker，處理葉節點任務，用完即毀；但如果拿它當整個系統的主控，很可能是用錯地方，可以當作 Ornith 35B 的導入原則。
- 短程、明確、可驗證的任務，可以交給 35B worker。
- 長程規劃、多輪重構、跨大型 codebase 的任務，先不要完全放權。
- 需要主控決策時，最好搭配更強模型或更嚴格的 Hermes/harness。
- 所有結果要能重跑、能測試、能看 log，不要只看模型自我回報。
這裡的核心不是「小模型沒用」，而是小模型要放對位置，主控、規劃、長上下文記憶是白領工作；批次修小 bug、生成局部元件、跑固定格式分析，反而是本地 35B 很適合切進去的地方。
本地部署的價值：不是零成本，而是可控成本
本地跑 Ornith 35B 很容易被包裝成「零 token 成本」。這句話只說對一半。雲端 token 成本下降了，但你換成了硬體成本、電費、散熱、維護、模型部署和速度瓶頸。
真正的優勢是可控。你知道模型跑在哪裡，知道資料是否離開內網，知道長任務不會因為 token 計費一路燒上去。對需要保護程式碼或內部文件的團隊，這比單純省錢更重要。
如果你本來就在研究本地 AI 開發環境，可以延伸看 Claude Code 搭配 LM Studio 與 Ollama 的零 API 成本環境，以及 Mac Studio 跑大型模型的 VRAM 調整。Ornith 35B 的問題，最後仍然會回到你的硬體、記憶體和任務型態。
我會怎麼把 Ornith 35B 放進 Hermes？
我不會一開始就讓 Ornith 35B 當整個 Hermes 系統的最高決策者。比較合理的導入方式，是先讓它做 worker。
- 先挑 5 到 10 個固定任務，例如小型前端元件、局部 bug 修復、測試補齊、簡單重構。
- 每個任務都要有明確驗證方式，例如單元測試、Playwright 截圖、lint、build。
- Hermes 負責任務切分、重試策略、log 收集和失敗回報。
- Ornith 35B 只處理其中一段，不直接改全專案、不直接做不可逆決策。
- 連續跑幾輪，看錯誤類型是否固定，再決定要不要擴大權限。
這樣的測法比較慢，但比較接近真實工程，AI Agent 的能力不是靠一個漂亮 demo 決定，而是看它能不能在可重複、可驗證、可回滾的流程裡穩定工作。
Ornith 35B 是值得測的本地引擎，不是萬能主控
Ornith 35B 最好的位置，暫時不是取代 Claude Code、Codex 或雲端大模型，而是進入 Hermes 這類 agent 工作流，成為一顆可控、可替換、可驗證的本地推理引擎。
它的優點很清楚：成本可控、資料留在本地、前端與視覺任務有亮點、自我 debug 的思路值得追。它的風險也很清楚：benchmark 不能直接代表長程任務，幻覺與錯誤累積仍然存在，小模型放錯位置會把整個 agent 工作流拖垮。
所以我會把 Ornith 35B 放進觀察名單，但會用 worker 的方式開始，而不是把整個系統交給它。這條路如果走通，本地 AI 編程的價值就不是「省 token」而已，而是開發者重新拿回 AI 架構控制權。
近期留言