打造自己的多機 AI Agent 控制中心：從 Herdr、ntfy 到 Google 遠端桌面
一開始，是看到 DHH 和 Tobi Lütke 怎麼管理 AI Agents
這整件事情，一開始其實不是因為我想架一個通知伺服器。
真正的起點，是我看到 DHH 和 Tobi Lütke 使用 Herdr 管理多個 AI Agents。這讓我開始思考：當 Claude Code、Codex 分散在不同電腦上長時間工作時，人到底應該怎麼管理它們？
我的工作方式也正逐漸往多機、多 Agent 發展。Windows PC 上可能同時跑 Claude Code 與 Codex，另一台 Windows PC 處理不同專案，Mac mini 也有自己的 Claude Code 與 Codex。這些機器不一定登入相同帳號，也不一定處理相同類型的工作。
AI Agent 最大的價值之一，就是我不必一直坐在它旁邊。把工單交出去，它可以自己讀檔、修改、測試、修正，再繼續往下做。
但機器一多，很快就出現一個新的問題：我怎麼知道哪一個 Agent 現在正在等我？
多 Agent 之後，人反而變成了監控程式
單獨使用 Claude Code 或 Codex 時，這個問題其實不明顯。Terminal 就在眼前，Agent 問問題，我直接回答即可。
但如果同時有三台、四台電腦工作，情況很容易變成：我去看 PC1，它還在跑；再去看 PC2，它也還在跑；最後打開 Mac mini，才發現 Codex 半小時前就停在一個問題等我回答。
這其實很荒謬。
本來使用 AI Agent 是希望減少人在電腦前等待的時間，結果 Agent 一多，我反而開始不停巡視每一台機器。如果未來變成五台電腦，每台又同時跑 Claude Code 與 Codex，人很快就會變成整套 Agent 系統裡最忙的監控程式。
所以看到 Herdr 之後，我第一個想法就是：這是不是正好可以解決這個問題？
研究 Herdr：方向很對，但不是我最需要的東西
Herdr 吸引我的地方，是它真的以「同時管理很多 Coding Agents」為核心來設計。它可以把不同 Terminal 裡的 Claude Code、Codex 等 session 集中起來，讓使用者知道哪些 Agent 正在工作、哪些被阻塞、哪些已經完成。
如果一個人坐在桌機前，同時操作很多 Agent，這樣的設計很合理。我也研究過多機 Herdr：每一台 Windows PC、Mac 各自保留自己的 Claude Code／Codex 帳號與 session，再由一個控制中心集中觀看和操作。
不同電腦登入不同 Claude Code 或 Codex 帳號，其實不是問題，因為 Herdr 管理的是 Terminal session，而不是 AI 服務本身的帳號。
但研究一陣子之後，我開始發現，我真正最迫切的需求好像不是「集中看所有 Agent」。
如果 Agent 正常工作，我根本不想看它。它正在讀檔案、修改程式、跑測試、建立文件，這些事情都不需要我。
我真正需要知道的只有幾種狀態：需要我回答、需要批准、發生錯誤，或工作已經完成。
換句話說，我不是想要「隨時看到所有 Agent」，而是：只有 Agent 需要我的時候才叫我。
Herdr 比較像 Control Center，而我當時最缺的是 Notification System。
方向就從這裡開始改變。
ntfy：真正符合需求的工具
研究之後，我找到 ntfy。
它的概念非常簡單：程式只要送出一個 HTTP Request，就可以讓手機 App 收到 Push Notification。這非常適合 AI Agent，因為 Claude Code 與 Codex 本身就有事件 Hook。
也就是說，Agent 可以在真正發生 Ask、權限請求、Stop 等事件的那一刻，直接通知外部程式。
我不需要 OCR Terminal、不需要解析畫面文字、不需要不停 polling，也不用每幾秒抓一次螢幕判斷 Agent 是不是卡住。
整條通知管線最後可以簡化成：Agent → Hook → ntfy → 手機。
剛好我有自己的 VPS 和網域
ntfy 本身有公共服務可以直接使用，但想到這套東西之後會變成我長期使用的 Agent 基礎設施，我開始考慮：既然我本來就有自己的 VPS 和網域，為什麼不直接自己架？
這樣通知系統可以完全掌握在自己手上，而且這件事情本身又剛好很適合交給 AI Agent 做。
於是出現一個很有趣的情況：我開始叫 AI Agent 幫我建一套「管理 AI Agent」的系統。
我的 VPS 是 Windows Server，而且原本就有 IIS。最後的設計並不是自己再寫一套 ASP.NET 通知程式，而是讓 IIS 單純處理 HTTPS、SSL、Reverse Proxy 與 WebSocket，後端真正跑的是 ntfy。
ntfy 本身以 Windows Service 執行，而且 backend 只監聽本機 loopback，不直接把服務 port 暴露到 Internet。
權限也拆開：Agent 使用的 publisher 帳號只能發送通知，手機使用的 reader 帳號只能讀取通知，匿名存取則封鎖。
最後再完整驗證 HTTPS、WebSocket、ACL、Publish、Read 與 Anonymous Deny。全部通過之後，第一條真正重要的管線就完成了。
Claude Code 與 Codex 都接上 Hook
接下來是在每台 Agent 電腦裝 Hook。
一開始我曾經想過，是不是要區分 Claude 帳號 A、Claude 帳號 B、不同 Codex 帳號，後來發現這些資訊根本不重要。
真正有用的是三件事：哪一台電腦、哪一個工作目錄、是哪一個 Agent。
所以手機上的通知只需要像這樣：
- PC-A / Case-A / Claude 等你回答
- Mac-mini / bosianli.com / Codex 本輪完成
- PC-B / website / Claude 權限請求
一眼就知道要去哪一台電腦、處理哪一個專案。
Claude 或 Codex 登入哪個帳號，完全不需要出現在通知裡。
接下來才是真正的問題：通知來了，我怎麼操作？
Push Notification 解決後，第二個問題自然出現。
假設手機告訴我：「PC3 / Case-A/ Claude 等你回答。」
那我要怎麼回答它？
如果人就在 PC3 前面，很簡單。但如果我人在其他地方，甚至只拿著手機呢？
我當然也可以透過手機的 Claude / ChatGPT Codex 處理，但如果處理多個不同帳號登入的 Claude Code，總不能帶好幾台手機吧？
於是我又回到 Herdr 這條線上。
為什麼最後沒有使用 Herdr
Herdr 的 Agent 管理方向其實很好，但我的使用習慣有一個非常重要的條件：我不希望拿手機操作 Terminal。
SSH → TUI → 選 session → 進 Terminal → 操作 Claude，技術上完全可行，但這不是我想要的手機體驗。
我希望手機上是正常的圖形介面，可以點、滑、放大、輸入，而且必要時還能處理 Agent 之外的事情。
我也研究過 Herdr Web UI / PWA 類型的方案。這確實更接近我要的形式，但又出現另一個問題：如果一個 Web Control Center 可以控制所有電腦上的 Agent，那它本身就會變成一個非常高權限的入口。
當然可以用 Tailscale、Token、Device Pairing、ACL、SSH Key 等方式把安全性做得很好，但做到這裡時，我開始重新問自己：我是不是為了解決一個已經有成熟工具能解決的問題，又重新架了一整套平台？
因為我本來就已經非常習慣一個工具：Google 遠端桌面（Chrome Remote Desktop）。
我本來就習慣用手機控制電腦
我平常就會用手機上的 Google 遠端桌面 App 操作自己的電腦，所以「手機遠端控制電腦」這件事情，本來就不需要重新學。
問題只剩下：能不能讓其中一台 Windows PC 成為控制中心，再從這台電腦進其他 Agent 電腦？
答案是可以。
Windows 對 Windows，本來就有非常成熟的 RDP。因此一台 Windows 主控 PC 可以直接透過 RDP 連其他 Windows Agent PC。
手機只要先透過 Google 遠端桌面連進 Windows 主控 PC，就能看到這些 RDP session，也能操作那些電腦上的 Claude Code、Codex 與其他應用程式。
這時整個系統已經非常接近我要的樣子，唯一剩下 Mac mini。
Windows 控 Mac：一開始選 VNC
macOS 本來就有 Screen Sharing，所以最直覺的設計是 Windows 主控 PC 使用 VNC Client 連 Mac mini。
我選了免費的 TigerVNC。實際測試後，畫面、滑鼠、鍵盤與基本操作都沒有問題，而且因為 Windows 與 Mac mini 在同一個區域網路，延遲也不算特別嚴重。
一開始看起來很好，直到我開始打中文。
TigerVNC 最後敗在「注音輸入法」
Windows → TigerVNC → macOS Screen Sharing 的情況下，我沒辦法正常使用自己習慣的注音輸入法。
對某些 Server 維護用途來說，這可能不是大問題。但我的 Mac mini 是拿來做 Codex、Claude Code、WordPress、Chrome、文章處理與網站內容，也就是會大量輸入中文。
如果注音不能正常工作，那它就不適合成為日常遠端桌面。
所以 TigerVNC 最後被淘汰。
不是因為 VNC 連不上，而是因為一個實際每天都會遇到的小問題，讓整個使用體驗無法接受。
這也是整次摸索過程裡很典型的一件事：架構圖看起來正確，不代表真正使用時適合。
Google 遠端桌面解決了問題
後來 Mac mini 也改成 Google 遠端桌面。
結果我真正需要的功能都正常：中文注音、鍵盤、滑鼠、GUI、Chrome、Finder、Codex、Claude Code 都能正常操作，而且手機本來就可以直接連 Mac mini。
於是最後我乾脆接受一個看起來沒那麼「漂亮」、但實際很好用的設計：Windows 主控 PC 透過 Google 遠端桌面控制 Mac mini。
甚至接受「遠端裡再遠端」
如果人在外面，要從手機透過主控 PC 操作 Mac，路徑其實是：手機 → Google 遠端桌面 → Windows 主控 PC → Google 遠端桌面 → Mac mini。
也就是 Remote Desktop 裡面又 Remote Desktop。
理論上當然不是最漂亮的方案。畫面會經過兩次傳輸，延遲也一定高於直接連線。
但我的主要工作不是遊戲、影片剪輯或高幀率畫面，而是 Agent、文字、Terminal、WordPress、瀏覽器與 Finder。對這些用途來說，這個代價是可以接受的。
如果真的要長時間操作 Mac，我還可以直接從手機的 Google 遠端桌面 App 連 Mac mini，不必繞過 Windows 主控 PC。
所以最後保留兩條路：平常集中管理時，手機先進主控 PC；需要長時間操作 Mac 時，手機直接進 Mac mini。
最終完成的架構
目前整套系統可以分成兩個很清楚的部分。
第一部分是通知系統：Windows / Mac 上的 Claude Code 與 Codex 透過 Hook，把需要回答、完成、權限等事件送到私人 ntfy Server，再推播到手機。
第二部分是控制系統：手機透過 Google 遠端桌面連 Windows 主控 PC；Windows 主控 PC 再透過 RDP 進 Windows Agent PC，透過 Google 遠端桌面進 Mac mini。必要時，手機也能直接連 Mac mini。
整個流程最後變得很簡單
平常 Claude Code / Codex 自己工作，我不用一直看。
需要我的時候，Hook 把事件送到 ntfy，手機震動。我看到通知裡的電腦名稱、工作目錄與 Agent 類型，就知道該去哪裡。
接著用手機進 Google 遠端桌面，必要時再從主控 PC 進對應機器，回答問題或批准權限。處理完後退出遠端，Agent 繼續跑。
這樣就結束了。
從模仿別人的工作流，到做出適合自己的版本
回頭看，整件事最有意思的地方就是：最初是因為看到 DHH 與 Tobi Lütke 使用 Herdr 管理 AI Agents，所以我的第一個方向也是「我要不要也做一個 Herdr Control Center？」
但真正研究和實際測試之後，最後得到的答案完全不同。
我真正重視的是手機 Push、手機 GUI、中文輸入、完整桌面控制，以及我已經習慣的操作方式，而不是統一 Terminal UI。
於是最後留下來的是 ntfy + Hook + RDP + Google 遠端桌面，反而沒有 Herdr。
這並不是 Herdr 不好，而是：別人的最佳工作流，不一定是自己的最佳工作流。
AI Agent 也參與了整套系統的建置
另外一個有趣的地方是，這套「用來管理 AI Agent 的系統」，很多部分本身也是 AI Agent 幫我建起來的。
例如 IIS + ntfy Server 工單、Windows Service、Reverse Proxy、ACL、WebSocket 驗證、Claude Code Hook、Codex Hook、Windows / macOS 安裝腳本、測試與 rollback。
我沒有把每一台機器都手動一步一步設定，而是先把需求整理成工單，再交給 Claude Code 或 Codex 執行。
過程中遇到 PowerShell 相容性問題，也不是重頭手動修，而是把錯誤回報、修正工單，再重新執行。
這讓我越來越確定一件事：未來很多「安裝軟體」的概念，可能會開始改變。
以前是下載 installer → Next → Next → Finish。
現在則可能變成：下載一包工單 → 交給 AI Agent → Agent 檢查環境 → 施工 → 測試 → 失敗就 rollback → 交付完整系統。
而且這個安裝包不是固定的 binary。它可以讀懂你的環境、修改設定、避開現有服務，甚至根據需求產生不同版本。
這可能才是 AI Agent 對軟體使用方式真正有趣的影響之一。
我現在對「多 Agent 工作流」的理解
做完之後，我反而不太在意畫面上能不能同時看到十個 Agent。
因為如果十個 Agent 都正常工作，我根本不需要看到它們。
真正需要我注意的，可能只有 Agent 3 需要回答、Agent 7 失敗、Agent 9 完成。
所以我現在認為，多 Agent 系統真正重要的第一層不是 Dashboard，而是 Attention Routing：哪一個 Agent 真的需要人的注意？
讓電腦先把這件事情過濾好，只有真正需要人的時候，人才介入。
最後
現在整條管線已經接好了：Claude Code / Codex → Hook → ntfy → 手機通知；需要介入時，再從手機進 Google 遠端桌面 → Windows 主控 PC → RDP / Google 遠端桌面 → 對應 Agent 電腦。
它不是一個非常華麗的新平台，大部分元件甚至都是早就存在的成熟工具。
真正新的只是：把它們按照 AI Agent 的工作方式重新接起來。
我現在不用再去問：「Claude 做到哪裡了？」也不用每十分鐘巡一次不同的電腦。
正常的時候，我根本不用管它。
有事情，它會自己來找我。
這才是我目前覺得真正符合 Agent 概念的工作方式。
