跳到主要內容

osaurus：當本地 LLM 不再只是「能跑」，而是成為 macOS 的一部分

在談論本地大型語言模型（LLM）時，多數人第一時間想到的仍然是 Ollama。

它解決了「我能不能在自己電腦上跑模型」這件事。

但 osaurus 問的，是下一個問題：

如果 LLM 不是一個外掛工具，而是 macOS 的原生能力，會發生什麼事？

定位先行：osaurus 不是「另一個 Ollama」

https://github.com/dinoki-ai/osaurus

osaurus（by dinoki-ai）從一開始就沒有打算與 Ollama 正面競爭「模型數量」或「跨平台」。

它的定位非常清楚：

  • 只為 macOS

  • 只為 Apple Silicon

  • 只為「低延遲、本地、可控」的 AI 系統整合

這不是妥協，而是戰略選擇。

當多數本地 LLM 解決方案仍停留在「能跑模型」的層次時，

osaurus 直接跳到下一層 —— AI 作為作業系統能力的延伸。

為什麼它快？因為它根本不是同一個技術路線

1. 極致輕量，不是口號

  • 二進制檔案約 8MB

  • 無 Docker、無虛擬化層

  • Swift 原生開發，直接貼近系統

對比 Ollama 的體量與依賴，osaurus 幾乎是「裸跑」。

2. MLX + Apple Silicon，是硬體與軟體的正交解

osaurus 使用 Apple 的 MLX 框架，這不是單純的效能優化，而是架構選擇。

結果是什麼？

  • 在 M3 Max 上，實測回應速度比 Ollama 快約 30%

  • 記憶體使用更穩定

  • 模型載入後的系統壓力顯著降低

這種快，不是 benchmark 的快，而是「你會感覺到它在你手上」。

真正的分水嶺：MCP（Model Context Protocol）

如果只談效能，osaurus 仍然只是「更快的本地 LLM」。

但 MCP 才是它的真正殺手鐧。

MCP 解決的不是推理，而是「行動」

透過 MCP，osaurus 可以：

  • 成為 Cursor、Claude Desktop、VS Code 的後端

  • 讓 AI 直接存取本地系統能力

    • 行事曆

    • 郵件

    • Git 倉庫

    • Terminal

    • macOS 原生 App

    • 甚至 GUI 操作（Accessibility API）

這意味著一件事：

AI 不再只是回答你，而是能幫你「做事」。

從工具到工作流：osaurus-tools 的真正價值

osaurus 附帶的不是「插件」，而是一組 可被組合的行為模組：

  • Headless WebKit：瀏覽器自動化

  • Git 操作：Diff、Review、提交建議

  • macOS UI 自動化：文字 → 行為

  • 行事曆 / 任務管理

  • Emacs、開發者工具整合

這讓 AI 從「單次對話」升級為 可重複執行的工作流節點。

原生 macOS 整合，才是它最容易被低估的地方

幾個細節，卻極具指標意義：

  • Menu Bar Chat：AI 就在你系統裡，而不是瀏覽器分頁

  • Apple Foundation Models 支援

  • 與系統權限、隱私模型高度一致

這不是 UX 美化，而是一個訊號：

osaurus 並不把 macOS 當成「跑模型的地方」，

而是把 AI 當成 macOS 的一個系統層。

限制與風險：它不適合所有人

必須誠實地說：

  • ❌ 只支援 macOS（且強烈建議 Apple Silicon）

  • ❌ 專案仍在高速迭代期

  • ❌ 模型生態不如 Ollama 成熟

  • ❌ 需要適應 MLX 模型與新的管理方式（如 ~/MLXModels）

如果你要的是 Production-ready、穩定不變、跨平台 —— 那現在的 osaurus 不是答案。

那誰「應該」關注 osaurus？

非常適合你，如果你是：

  • Mac 重度使用者

  • 開發者 / 技術管理者 / Power User

  • 正在使用 Cursor、Claude Desktop

  • 對「本地 AI + 系統整合」有長期想像

  • 想把 AI 變成 工作的一部分，而不是聊天工具

不適合你，如果你是：

  • Windows / Linux 使用者

  • 只想要「開箱即用、永不變動」

  • 不打算碰 MCP 或系統層整合

結語：osaurus 其實在回答一個更大的問題

osaurus 真正有趣的地方，不在於它比 Ollama 快多少。

而在於它在實驗一件事：

當 AI 不再是雲端服務，而是你電腦的一部分，

我們還會用同樣的方式思考「工具」嗎？

這條路很早、很前沿、也很不穩定。

但正因如此，它值得被關注。

如果你手上正好有一台 M 系列的 Mac，

osaurus 可能不是你「唯一」的本地 LLM，

但很可能會是你 最接近未來的一個。

留言

張貼留言

這個網誌中的熱門文章

Vibe Coding：為什麼 Junior 更快上手？Senior 要如何追趕？

現象層面（市場觀察） 最近有篇文章討論 junior & senior 開發者在 AI 時代的角色轉變，非常熱門。 身為 Cympack 產品開發團隊 ，我們也一直關注這個議題，在閱讀這篇文章時觀察到一些有趣的現象，對我們來說，這正好反映出 AI 正在改變開發生態，junior 借力 AI 快速成長、senior 則需要在 「架構思維」 與 「多 agent 協作」 中找到新定位，其中有些啟發（insight) 可以跟大家分享。 為什麼 Junior 更容易上手 vibe coding？ 心智負擔低 → Junior 沒有太多傳統 code workflow 的框架包袱 敢於嘗鮮 → Gen Z / 年輕工程師天生習慣用 prompt-based 工具、跟 LLM 互動 少「優雅程式設計」的束縛 → 不太糾結「這樣寫會不會不夠優雅」，反而 embrace 快速迭代、快速出成果 反觀 Senior： 熟悉大型系統設計 有豐富的「工程正統流程」知識（架構設計、測試策略、效能優化、設計模式） 對 AI 生成 code 的品質 / 維護性通常比較保留 部分 10+ 年資深工程師，對 prompt engineering 沒那麼熟練，還在觀望 技能面（未來的關鍵能力） Vibe coding 本質上 = prompt engineering + AI co-pilot 管理能力 能力項目 誰目前比較有優勢？ Prompt 撰寫 / AI 互動 Junior 較強（熟悉 chat-based 流程） 系統設計 / 架構把關 Senior 較強 AI 生成 code 驗證 / Bug 察覺能力 Senior 較強（能看出潛在問題） 快速疊代 / Hackathon 式開發 Junior 較強 長期維護性 / 穩定性 Senior 較強 總結 Junior 確實更快適應 vibe coding，並且更習慣以 「chat-based coding」 的工作流開發。 Senior 擁有驗證 AI 產物與系統設計的深度能力，但若不主動練習 vibe coding，長期會逐漸落後於新一波開發潮流。 就如同在 GAI 技術年會分享，希望帶給各位的感受， 『與 AI 協...
張貼留言
繼續閱讀>>

Vibe Coding 協作到自建 Dev Agent？從 Claude / Codex 到 OpenHands

過去一年，越來越多工程師開始 把 AI 真正帶進工作流程 。從一開始用 ChatGPT、Claude 來問語法問題，到後來很多人愛上 Cursor，直接在編輯器裡讓 AI 幫忙改 code、補 test case、甚至自動整理 PR。這樣的開發體驗，已經大大改變了我們寫程式的方式。 更現實的是，在很多企業內部、政府單位、或涉及機密資料的專案裡， 其實根本不能直接用 Cursor 或雲端 LLM 工具。   畢竟這些服務通常會把資料傳到雲端模型做處理，萬一專案裡有未公開的技術、敏感客戶資料，或是受限於法規 （像金融、醫療、政府標案） ，直接用雲端 AI 工具就會踩 紅線 。  因此，許多團隊反而更希望 「自己架一套 Dev Agent」 ，可以在內網執行，資料完全掌握在自己手上，該整合的內部工具、該讀的私有 repo、該串的 CI/CD pipeline，全部客製化、安全可控。 這時候，像 OpenHands 這樣的開源 Dev Agent 框架就特別有價值。它的出發點不是單純的 AI 助手，而是讓你能夠打造出一個真的可以跑在自己環境裡、可以理解整個開發流程的 AI 工程師。從建置到部署，從 CLI 操作到瀏覽器查詢， 從多檔案編輯到自動測試，全部都能自己完成，甚至還能針對不同專案調整專屬的工作流。 對很多開始探索 AI 協作開發的團隊來說，這是一條 從 「AI 幫你寫一段程式」，走向「AI 幫你解決一整個任務」 的進化路徑。而且，還是在可控、可自定義、安全的環境裡完成的。 🧩 主要概述 OpenHands 是由 All‑Hands AI 開發的開源「軟體開發代理人平台」，能模仿人類工程師從建立程式、修改程式碼、執行指令，到瀏覽網頁、呼叫 API……等一整套開發流程 它提供雲端（OpenHands Cloud）與本地 Docker 運行版本，用戶能配置 LLM（如 Claude、OpenAI、Gemini…) 📚 核心特性與怎麼使用 代理人的工具能力 支援代碼編輯、命令行、執行環境、網頁瀏覽、API 呼叫—接近人類開發者完整技能。其中 OpenHands Cloud 版本提供 $50 試用額度讓大家方便使用，又或者如果自己本機有 docker 的話，可以自己Local 版本透過 Docker 自架環境。 ...
張貼留言
繼續閱讀>>

Google Gemini 全端 AI Agent 快速入門 - 打造「思考」的 AI 助理

一套從搜尋、反思到輸出的全端 AI 代理人範例，讓你看懂什麼叫 Research Agent 在 AI 工具百家爭鳴的今天，大家都在問一個問題： 「我能不能不只問 AI 答案，而是讓它像一位助理一樣，有流程、有反思、還有出處，真正幫我完成一件事？」 Google 最近釋出了一個相當具有指標意義的開源專案 gemini-fullstack-langgraph-quickstart ，正是為了解這個問題而誕生。 這套系統到底是什麼？ 這個範例不是傳統 Chatbot，而是展示一個完整的 AI research agent ： 它會根據使用者的提問，自動發想搜尋關鍵字、查資料、整合重點，最後給出答案還附上引用來源。背後的邏輯設計得非常扎實，不只是能跑，更是具備可讀性、可擴展性與可商用性。 它的流程大致如下：  1. 使用者輸入問題（例如：「抖音是否影響台灣選舉？」）  2. Gemini LLM 幫你想出關鍵字（不只是照抄問題）  3. 呼叫 Google Search API 抓資料   4. LangGraph 控制流程 → 判斷資料夠不夠 → 若不足，自動補查  5. 整合最終答案，並產生 citation（來源說明） 你可以想像這就像一位實習助理幫你寫報告， 不只輸出一段內容，而是會 去查、會判斷、會補資料，而且說明「我為什麼這樣說」 。 LangGraph 是什麼角色？ LangGraph 就是整個 Agent 背後的控制系統 。 用白話講，它幫你定義 AI 每一步要幹嘛、遇到什麼狀況該走哪條路、要不要反思、要不要再查，甚至可以定義條件邏輯與資料流動。 這就不像寫一個單純的 Chat API，而是比較像「把一個流程圖變成可以跑的程式」。 對工程師來說，它提供了從 prompt 到流程控制的設計彈性；對產品設計來說，它讓 AI 有了 「多步驟任務執行」 的能力。 技術架構與使用方式 這整套系統是 Fullstack 架構，前後端都幫你整好了，技術選型也非常實用：   前端：Vite + React + TailwindCSS + Shadcn UI  後端：FastAPI + LangGraph...
張貼留言
繼續閱讀>>