最近我真的開始養 AI 員工了
前一陣子，我先把 Hermes Agent 架在另一個雲端環境，目標不是單純拿它聊天，而是想把它變成一個 Project Operator
可以自己讀專案文件、研究、整理、查核，再把真正需要我決定的事情丟回來
結果光是第一次把環境養好，我就踩了不少坑 😂
Server、persistent storage、登入驗證、GitHub 權限、環境變數、重啟後設定有沒有留下來……
每一件單獨看都不算太難，但加在一起，就是會一直冒出「為什麼又不能用了」的那種麻煩
剛好 Cloudways 後來推出了 Managed AI Agents，而且直接支援 Hermes
所以我決定再養第二隻
這篇先不比較 Cloudways 跟其他平台誰比較好，也不先下「Managed 一定比較省事」的結論
我只記錄一件事
如果今天從零開始，在 Cloudways 上部署一個 Hermes Agent，到可以使用 OpenAI Codex、GPT-5.6 Sol，再接上 GitHub，實際要做哪些事？
先說目前的結果
從按下 Deploy 到 Hermes instance 可以開啟，我這次大約等了 2～3 分鐘
而且我後來發現一件原本沒預期到的事
Cloudways 部署頁雖然會顯示 OpenAI API Key 欄位，但 Hermes 不一定要用 OpenAI API Key
我實際測試後，可以直接使用 Hermes 原生支援的 OpenAI Codex OAuth
也就是用自己的 ChatGPT / Codex 訂閱登入
這對本來就有 ChatGPT / Codex 訂閱的人滿重要
如果你還不太確定 Hermes 跟一般聊天 AI、n8n 這類 Workflow 到底差在哪，可以先看我之前整理的這篇：
👉 n8n、ChatGPT、Hermes 差在哪？其實是三個不同層級
如果你想先從「AI Agent 為什麼開始像 AI 員工」理解，也可以看：
👉 AI Agent 是什麼？為什麼它開始像一個 AI 員工
Cloudways Managed AI Agents 是什麼？
Cloudways 現在除了原本的網站主機，也多了一個 Managed AI Agents 區域
目前可以直接部署包含 Hermes 在內的 AI Agent
跟自己租一台 VPS 最大的差別，是底層 server provisioning、Agent deployment、SSL 等基礎環境由 Cloudways 處理
如果需要進階操作，仍然保留 SSH / Terminal access
對我來說，這次真正想驗證的不是「能不能裝」
Hermes 自己架當然裝得起來
我比較在意的是
到底能不能少顧一點 server
Step 1：進入 Cloudways Managed AI Agents
登入 Cloudways 後，我一開始其實找了一下入口 😂
因為原本 Cloudways 後台比較容易讓人先看到 Servers、Applications 那些傳統主機功能
現在 Managed AI Agents 的入口是在左側的 Cloudways AI
進去後會看到 Managed AI Agents → Launch your Agent
Step 2：選 Hermes、名稱與 Region
建立頁面會先要求：
- Instance Name
- Agent
- Region
我這次選的是：
Agent：Hermes
Region：Singapore
因為我人在台灣，所以直接選新加坡
Instance Name 則只要取一個自己看得懂的名稱就可以
我這次是拿它當第二個 Hermes sandbox，之後會跟原本那隻做 controlled comparison
所以這裡先不碰 production，也不把原本的 Hermes 搬過來
Step 3：先用 Scout 2GB 測試
下一步是選 instance size
我這次先選最小的 Scout：
- 1 vCPU
- 2GB RAM
- 50GB SSD
- 2TB Bandwidth
我部署當下，Cloudways 畫面顯示的是 US$4.99 / 月
這是我 2026 年 9 月實際測試當下看到的價格，不代表之後一定還是這個價格
所以如果你自己要開，還是以結帳頁當下顯示的金額為準
我先從 2GB 開始的原因很簡單
先確認 Hermes 正常跑不跑得動，再決定要不要加規格
現在還沒必要一開始就把機器開很大
Step 4：LLM API Key 可以先不填
這裡是我原本差點誤會的地方
部署畫面會看到：
Choose an AI provider and add your API key
下面有 OpenAI、Anthropic、Gemini、OpenRouter 等選項
第一眼很容易以為：
所以我要另外準備 OpenAI API Key？
但這一步其實是 Optional
所以我這次：
完全沒有填 LLM API Key
直接接受 Terms & Conditions 後部署
這點很重要，因為後面我會改走 Hermes 自己原生支援的 Codex OAuth
Step 5：實測大約 2～3 分鐘部署完成
按下 Deploy Agent 後，Cloudways 開始顯示：
Creating Instance…
我實際大概等了 2～3 分鐘
接著 Agent 就變成可以 Open Agent 的狀態
至少第一次建立這段確實很省事
我沒有：
- SSH 進去裝 Hermes
- 自己裝 Docker
- 自己處理 SSL
- 自己建立 Hermes runtime
按完 Deploy，就是等它生出來
Step 6：第一次 Open Agent 會要求 Hermes Password
部署完成後，Cloudways 會出現 Open Agent
第一次點進 Hermes Web UI 時，我看到的是 Password 登入頁
這個 Password 不是 Cloudways 帳號密碼
回到 Cloudways 的 Agent 詳細頁面，可以看到：
Agent Details → Password
複製這裡的密碼，再回 Hermes 登入即可
同一頁還會看到另一組：
SSH Credentials
裡面包含：
- Username
- IP Address
- Port
- Password
要注意：
Hermes Web UI Password 跟 SSH Password 是兩件事
不要混在一起
Step 7：先不要急著 Add LLM Key
登入 Hermes 後，第一次會看到 First Run 畫面
因為前面沒有設定 LLM，所以 Hermes 會提醒還沒有 Provider
Cloudways 自己的介面也會提醒 Agent 需要 LLM 才能真正處理工作
但我這次沒有回頭填 OpenAI API Key
因為我本來就有 ChatGPT / Codex 訂閱
所以我真正想測的是：
Cloudways 裡面的 Hermes，能不能直接使用 Hermes 原生的 OpenAI Codex OAuth？
答案是可以
Step 8：SSH 進 Cloudways Hermes
回到 Cloudways Agent 詳細頁，在 SSH Credentials 區域可以看到完整的 SSH 連線資料
Cloudways 也會直接提供 SSH command
我用 Mac Terminal 連線
第一次連線確認 fingerprint，再輸入 SSH Password，就成功進入 Cloudways 幫我建立好的 Debian 環境
登入後我第一個做的不是亂改設定，而是：
hermes status這時 Hermes 顯示：
- Model：not set
- Provider：Auto
- OpenAI Codex：not logged in
- GitHub：not set
而且最關鍵的是，它直接告訴我 OpenAI Codex OAuth 是原生存在的
Step 9：用 ChatGPT / Codex 訂閱登入 Hermes
接著執行：
hermes model選擇 OpenAI Codex
Hermes 會啟動自己的 device login，並提示：
- 打開 OpenAI Codex device login 網頁
- 輸入畫面上的 device code
- 使用自己的 OpenAI 帳號完成授權
這個登入是 Hermes 自己的 session
畫面也直接寫明不會影響 Codex CLI 或 VS Code
我完成授權後，Hermes 顯示：
Login successful!
所以這次 Cloudways Hermes：
沒有使用 OpenAI API Key
我使用的是：
ChatGPT / Codex Subscription → OpenAI Codex OAuth
這也是我覺得這次測試最值得特別記下來的地方
Step 10：選 GPT-5.6 Sol
Codex 登入成功後，Hermes 會列出目前可以使用的模型
我這次選：
gpt-5.6-sol
Reasoning Effort 則選：
medium
原因不是因為這一定是所有人最好的設定
而是我另一台 Hermes baseline 本來就是這組設定
後面要做 Cloudways vs 另一個 hosting 的 controlled test 時，我希望盡量減少模型差異
最後 Hermes 顯示：
Login successful!
Default model set to: gpt-5.6-sol (via OpenAI Codex)
Reasoning effort set to: medium
Step 11：設定 GitHub
因為我的 Hermes 不是只拿來聊天
我要它讀 private repo、專案 authority、research、handoff，所以還需要 GitHub credential
我使用的是 GitHub Fine-grained Personal Access Token，而且只開放 Hermes 真正需要碰的 repositories
這裡有一個安全細節
我不想把 PAT 直接打進 shell command，留在 command history
所以我先用：
read -s GITHUB_TOKEN貼入 token
read -s 不會把輸入內容顯示在 Terminal 上
接著：
export GITHUB_TOKEN
hermes config set GITHUB_TOKEN "$GITHUB_TOKEN"
unset GITHUB_TOKEN最後再跑：
hermes status我看到：
GitHub ✓
而且在 unset shell variable 後仍然存在
代表不是只活在目前 Terminal session
最後怎麼確認 Hermes 設定成功？
我目前最簡單的驗收方式就是：
hermes status最後我確認：
Model：gpt-5.6-sol
Provider：ChatGPT or Codex Subscription
OpenAI Codex：logged in
GitHub：✓
到這裡，我把它視為：
Cloudways Hermes 的 infrastructure + model auth + GitHub credential 已經 Ready
但還不是完整的 Project Operator
後面我還會繼續測：
- private repo 實際讀取
- Operator Skill
- restart 後 Codex OAuth 還在不在
- GitHub credential persistence
- new session recovery
- 真正跑一個 Project 時會不會一直叫我救火
Cloudways 部署 Hermes，現在我的第一印象
先強調：
這還不是 Cloudways vs 其他平台的最終評價
我現在只完成 setup
但單看部署這一段，確實比我第一次自己養 Hermes 乾淨很多
我這次基本流程是：
選 Hermes → 選 Singapore → 選 Scout → Deploy → 等 2～3 分鐘 → 登入 Web UI → SSH → Codex OAuth → GitHub
我沒有自己處理：
- Docker
- SSL
- Hermes 安裝
- server user provisioning
- Web UI deployment
但「比較好部署」跟「比較適合長期跑 Hermes」是兩回事
所以我接下來會保留原本那隻 Hermes 當 baseline，再讓 Cloudways 這隻跑同一個真實 Project
我要看的不是 benchmark 快幾秒
而是：
哪一隻比較少叫老闆回來救火？
這才是我真正想知道的
等兩邊都實際工作一段時間，我再整理完整比較
Cloudways Managed Hermes 適合誰？
目前只根據 setup 經驗，我會先把它理解成：
如果你想玩 Hermes，但看到 VPS、Docker、SSL、server maintenance 就已經不想開始，Managed hosting 的確有它的價值
反過來，如果你本來就很熟 Linux、Docker、VPS，而且希望完全控制環境，那 Managed 的價值就要看後面的穩定性、維護成本與價格差異
我自己現在還不急著選邊
第二隻才剛出生
先讓它上班再說 😂
如果你是從 AI Agent 這條線一路看到這裡，這兩篇可以一起看：