最近社群上很常看到一種畫面。
十幾台 Mac mini 疊在架子上，網路線、電源線插滿，看起來很像以前的礦場。差別是它們沒有在算 Bitcoin，裡面跑的是開源常駐 Agent 框架、Hermes、AI 助手 Code，或各種自己組的 Agent worker。
今年 9 月，Hermes 官方整理的使用案例裡，就收錄了一家韓國 AI 公司 Sionic：他們買了一批 Mac mini，讓數十個 Hermes Agent 分別跑在開發、DevOps、AI 研究、策略與 BD。另一邊，也有人乾脆把 Mac mini 做成 24 小時不關機的 AI 助手 Code 主機，手機在外面就能看它繼續跑工作。
看到這種照片，第一個問題通常是：
幹嘛不用一台很大的主機就好？
第二個問題則是 Apple 10 月 2 日自己丟出來的：
macOS 接下來要把 Full Disk Access 管得更嚴，這些無螢幕、整天自己跑的 Agent 主機會不會被卡住？
先講結論：會有影響，但不會一刀把 Mac mini 農場打死。
差別在這些 Agent 到底拿 Mac mini 做什麼。
Mac mini 農場多半不是拿來「合體算一顆大模型」
先把一個很容易誤會的地方拆掉。
十台 Mac mini 放在一起，不代表它們的 Unified Memory 會自動合成一大池，然後一起跑一顆超大模型。
真的要做 distributed inference，還是需要特別的分散式軟體、網路與模型切分。社群上大部分看起來像礦場的 Agent farm，其實比較接近：
一台機器，負責一批獨立工作；很多台一起平行跑。
Elegant Software Solutions 公開過一套 12-node Mac mini farm，配置是 2 台 orchestrator 加 10 台 worker。它們處理的是軟體開發工作流：任務分派、寫程式、測試、Git 操作、錯誤恢復，各台有自己的工作狀態。
這個架構其實比較像小型公司。
主管不需要把十二個人的腦袋接在一起，他只要讓十二個人同時做不同事情。
Agent farm 也是這樣。
為什麼偏偏是 Mac mini？
如果 Agent 背後呼叫的是 AI 助手、GPT、Gemini 這類雲端模型，本機通常不是算力主角。
模型在雲端算，Mac mini 負責的是另外一堆很「雜」的工作：
跑 shell、改檔案、Git、瀏覽器、排程、MCP、登入網站、收發訊息、跑測試、留著 session，然後 24 小時在線。
9 月 30 日一篇 Mac mini 24/7 Agent 主機設定文章 就講得很直接：如果 Agent 主要呼叫雲端模型，16GB 的基礎版 Mac mini 已經夠當 host。真正麻煩的是斷電、重開機、登入、權限和 macOS 更新後，它還能不能自己活回來。
這也是 Mac mini 很適合這種工作的原因。
它小、安靜、省電，不會像筆電一樣被主人闔上蓋子帶走；而且它跑的是完整 macOS。
後面這點很重要。
你如果需要 Messages、Shortcuts、AppleScript、Xcode、iOS build/signing，或者真的要操作 Mac 上的 App，Linux VPS 很難完全取代它。
一個專門把 AI 助手 Code 放在 headless Mac mini 上跑的公開設定甚至把整台機器的角色寫得很清楚：它就是一台專門給 Agent 用、透過 tailnet 和 SSH 遠端管理的 Mac。
這種機器已經不是傳統「個人電腦」的用法了。
人平常根本不坐在它前面。
還有一個原因：大家開始在意「一個 Agent 爆掉，不要拖整間公司下水」
一台 Mac 當然可以跑很多 Agent。
Hermes 官方收錄的另一個案例，就有 17 人的新創把多個 Hermes profile 放在同一台實體機器上。所以「一個 Agent 一台 Mac mini」從來不是技術規定。
那為什麼還有人喜歡一排一排買？
隔離是其中一個很實際的理由。
不同 worker 可以有不同的 macOS 使用者、瀏覽器狀態、憑證、專案資料、登入帳號與權限。某一台被 Agent 搞壞、磁碟塞滿、瀏覽器 session 死掉，甚至要整台重灌，其他 worker 還在跑。
對長時間自主工作來說，這種隔離比多幾個 benchmark 分數有感多了。
當然，社群照片裡也一定有一部分是炫技。
很多工作一台 Mac mini 開幾個 worker 就做得完；如果只是呼叫雲端 API，買十二台不一定比容器、VM 或便宜的雲端主機划算。
所以看到「Mac mini 農場」不能一律解讀成算力需求爆炸。
有的是容量，有的是隔離，有的是 Apple 生態需求，也有的是單純想把 Agent 工廠拍得很帥。
Apple 10 月 2 日到底改了什麼？
Apple 10 月 2 日發布 Full Disk Access 新說明，這次很罕見地直接點名 AI agents。
Apple 的意思是，Full Disk Access 原本是為備份軟體這類特殊用途準備的，但現在有軟體拿它去讀整台 Mac 上的檔案、郵件、訊息，甚至瀏覽紀錄。
Agent 愈來愈能自己做事之後，這種權限的風險更大。
所以 Apple 說，接下來會加更多控制，而且使用者如果真的要給這種等級的權限，必須有 very explicit user action。
目前 Apple 還沒有把最後實作細節全部公布。
這點很重要。
現在能確定的是：Apple 想讓 Full Disk Access 更難被軟體順手拿到。
不能直接推論成「未來每台 Mac 每天都會跳視窗」，也不能說所有 headless Agent 都會壞掉。
哪種 Mac mini 農場影響最小？
如果你的 Agent 大部分工作都在一個指定的專案資料夾裡：
寫程式、跑測試、Git commit、呼叫 API、SSH 到其他機器、收 queue、寫資料庫、透過 MCP 操作有明確 API 的服務。
這類影響其實不大。
它根本不需要把整顆硬碟翻一遍。
同樣地，本地 LLM inference 幾乎跟 Full Disk Access 是兩回事。模型權重放在指定目錄，runtime 讀自己的檔案，Apple 收緊全碟存取並不會突然讓 MLX、Ollama 或 LM Studio 不能跑。
所以如果那一排 Mac mini 主要是 coding worker 或 inference worker，我不會太擔心。
真正麻煩的是「像人一樣什麼都碰」的 Agent
影響比較大的，是個人助理型 Agent。
它想看 Mail、Messages、瀏覽紀錄、整個 Documents、其他 App 的資料，再用 GUI 幫你點東西。
這種 Agent 很容易碰到 macOS 的 TCC 權限系統：Full Disk Access、Accessibility、Automation、Apple Events，各管不同事情。
Apple 現在特別要收緊的是 Full Disk Access。
所以一個常駐 Agent 或 Hermes instance 如果原本的玩法是：
「第一次裝好，權限全部打開，之後這台 Mac mini 丟進櫃子裡半年不要理它。」
這種模式未來最值得注意。
一台還好。
如果你有 30 台 headless Mac mini，而且每次系統升級、Agent 換 binary 或權限模型改動，都要有人進去做一次明確確認，維運成本會直接放大。
農場真正怕的往往不是某一個任務多跑三秒。
是同一個人工動作突然要做三十次。
企業農場還有 MDM 這條路，但也不是完全零人化
Apple 現在就有 Privacy Preferences Policy Control，讓受管理的 Mac 可以透過裝置管理服務設定各種隱私權限。
macOS 27 又往前走一步。
Apple 在今年 WWDC 的 App 管理更新 裡加入新的 Privacy 設定，IT 可以替受監管裝置準備好 App 權限的預設值，第一次啟動時用一個整合畫面讓使用者確認。
這其實很符合 Apple 的方向：
企業可以管理，但使用者還是要知道自己放了哪些權限出去。
所以對幾十台、幾百台的正式 Agent fleet 來說，未來可能會愈來愈需要 MDM，而不是靠工程師一台一台手動進 System Settings。
只是 Apple 10 月 2 日的新 Full Disk Access 控制最後會怎麼跟這套管理機制整合，目前官方還沒講完。
現在說「MDM 一定可以完全自動開 FDA」還太早。
有趣的是，Apple 收緊權限不一定會讓大家離開 Mac mini
聽到這裡，很容易覺得 Agent farm 應該乾脆搬去 Linux。
有些 workload 的確會。
純 coding worker、網頁工作、API 任務，本來就可以跑 container、VM 或便宜 VPS。對這種工作，Linux 通常更好自動化。
但另外一群人選 Mac mini，買的剛好就是 macOS。
他們要 iMessage、Shortcuts、Xcode、AppleScript、本機瀏覽器與 Apple 生態的登入狀態。
這群人不會因為多一個權限確認就全部搬家。
比較可能發生的是架構開始分流：
跟 Apple 生態有關的工作留在 Mac。
純 web、coding、資料處理的 worker 搬到 Linux、VM 或雲端。
高風險的 browser / computer-use 工作放進隔離環境。
Mac mini 從「什麼都給它做」變成一個有明確工作邊界的節點。
其實這反而比較健康。
如果你自己在架 Agent，現在最值得先改的是權限觀念
我不會因為 Apple 這則公告，就叫人不要買 Mac mini 當 Agent host。
我反而會先做幾件很無聊，但之後很省事的事。
每個重要 Agent 用獨立帳號或至少獨立工作目錄；能用 API 就不要靠亂翻 App 資料；沒有必要就不要開 Full Disk Access；遠端管理保留一條可靠的 SSH / tailnet 路徑；機器一多，就開始用 MDM 思考，不要把三十台 Mac 當三十台家用電腦管理。
因為 Apple 現在針對的，就是「軟體拿到一個遠超過工作需要的總開關」。
Agent 世界最後大概也會走到同一個方向。
不是「給它整台電腦」，而是清楚告訴它：
你可以碰這些資料。
可以做這些動作。
其他東西不要碰。
所以，那排 Mac mini 會不會被影響？
如果它們只是跑 AI 助手 Code、Hermes coding worker、本地模型、Git、API 和排程：
大多數不會有什麼大事。
如果它們是完全無人值守、又大量依賴 Mail、Messages、瀏覽紀錄、GUI automation 和 Full Disk Access 的個人助理：
會，而且農場規模愈大，權限確認這種小摩擦愈痛。
但我現在反而不覺得這會讓 Mac mini Agent farm 消失。
它比較像逼大家把 2026 年初那種「先全部權限打開再說」的玩法，慢慢改成正常的系統工程。
照片還是會很像礦場。
只是下一階段比的，可能不再是誰桌上堆最多 Mac mini。
而是那一排機器半夜沒有人顧的時候，到底還能不能安全地把事情做完。
參考資料
- Apple Developer｜Updates to Full Disk Access in macOS｜2026-10-02
- SideMini｜Set up a Mac mini to run AI agents around the clock｜2026-09-30
- NousResearch / Hermes Agent｜User Stories：Sionic Mac Mini farm｜2026-09-05
- timche｜mac-mini：headless Apple Silicon Mac for AI 助手 Code
- Elegant Software Solutions｜Mac Mini Farm Orchestration: Distributed Agent Patterns｜2026-06-05
https://www.elegantsoftwaresolutions.com/blog/building-the-crew-mac-mini-farm-orchestration-patterns
- Apple Support｜Privacy Preferences Policy Control device management payload settings
- Apple Support 台灣｜WWDC26 App 管理更新｜2026-06-08
- Apple Support｜Controlling app access to files in macOS