私有化 AI 自動化的核心課題，在於協同本地算力與雲端頂級模型的混合雲地 AI 部署。CyberQ 近期實戰了以 QNAP NAS 的 Container Station 為常駐基地，部署代理人終端機多工器 Herdr 與自主代理人 Hermes Agent，串接本地 NVIDIA DGX Spark（GB10）推論節點與 Claude Code、Codex CLI、Gemini CLI 等訂閱制雲端代理人，並針對每個元件的實際能力給出可落地的操作方式與取捨建議。
先釐清各元件的真實定位
CyberQ 實測時，有留意到網路上不少文章將 Herdr 描述為「多模型路由框架」，此說法需要調整，直接照做會設定不出來。依官方文件與第三方評測，各元件的實際角色如下。
| 元件 | 實際定位 | 關鍵能力 | 來源 |
|---|---|---|---|
| Herdr | 代理人專用終端機多工器（tmux 的代理人強化版），Rust 單一執行檔 | 會話存活與重連、代理人狀態側欄（blocked、working、done、idle）、Unix socket API 供程式化調度、git worktree 整合 | herdr.dev、github.com/ogulcancelik/herdr |
| Hermes Agent | Nous Research 於 2026 年 2 月釋出的開源自架代理人，MIT 授權 | 跨會話持久記憶、自建技能、cron 排程、Telegram 與 Slack 等訊息閘道、支援任何 OpenAI 相容端點 | github.com/NousResearch/hermes-agent |
| DGX Spark（GB10） | 本地推論節點，Blackwell 架構、128GB 統一記憶體 | 以 vLLM 或 llama.cpp 提供 OpenAI 相容 API，零 API 費用、資料不出網 | NVIDIA 官方規格 |
| Claude Code、Codex CLI、Gemini CLI | 訂閱制 CLI 代理人，各自以帳號登入 | 高階推理、程式碼生成，在 Herdr 的 pane 內以互動或無頭模式執行 | 各家官方文件 |
| LiteLLM（或同類閘道） | 模型路由與稽核層，本文補上的必要元件 | 統一 OpenAI 相容入口、依模型名稱路由至本地或雲端、集中日誌、金鑰隔離 | litellm.ai |
重點在於 Herdr 不經手任何 API 金鑰，也不做提示詞路由。路由與過濾必須交給閘道層或 Hermes 的模型設定，Herdr 只負責讓所有代理人活在同一個可觀測、可程式化的終端機環境裡。
推薦實作的四層架構
CyberQ 建議，實作方式有使用容器工作站、虛擬機工作站等方式進行，擇一即可。選容器的好處是省下記憶體，其一體性來自「/share/Container/agent-hub/ 這一個目錄就是全部」，包括 compose、Dockerfile、config、.env、volume 掛載點。備份它、複製到另一台 NAS、docker compose up -d 就還原。這比 VM 映像檔更好搬，也更好 diff。
以下只是其中一個部署方式的架構圖範例 :
儲存與常駐層（QNAP NAS）
Container Station 執行一個長駐的 agent-hub 容器，內含 Herdr 伺服器、Hermes Agent 與各家 CLI 代理人。NAS 同時以 NFS 提供模型庫與工作目錄，並集中保存日誌。
會話與調度層（Herdr）
所有代理人在 Herdr 的 pane 內執行，狀態透過側欄與 socket API 對外揭露。斷線、關閉筆電、SSH 中斷都不影響代理人繼續工作。
路由與稽核層（LiteLLM）
所有地端模型呼叫統一打向 NAS 上的 LiteLLM 端點，由模型名稱決定流向，並在此層落日誌與遮蔽敏感欄位。
推論層
DGX Spark 以 vLLM 提供本地開源模型，雲端訂閱代理人則各自透過官方通道連線。
實作步驟
步驟一、建立 agent-hub 容器
在 Container Station 以自訂 Dockerfile 建置映像。以下為設定檔範例，請依據你的環境修改必要的設定。
# Dockerfile FROM ubuntu:24.04 ENV DEBIAN_FRONTEND=noninteractive RUN apt-get update && apt-get install -y \ curl git ca-certificates openssh-client \ python3 python3-pip python3-venv \ nodejs npm tini \ && rm -rf /var/lib/apt/lists/* # Herdr（官方安裝腳本，單一 Rust 執行檔） RUN curl -fsSL https://herdr.dev/install.sh | sh ENV PATH=”/root/.local/bin:${PATH}” # 各家 CLI 代理人 RUN npm install -g @anthropic-ai/claude-code @openai/codex @google/gemini-cli # Hermes Agent（安裝指令以官方 repo README 為準） # RUN curl -fsSL <hermes 官方安裝腳本網址> | sh WORKDIR /workspace ENTRYPOINT [“/usr/bin/tini”, “–“] CMD [“sleep”, “infinity”]
DOCKERFILE
# docker-compose.yml services: agent-hub: build: . container_name: agent-hub hostname: agent-hub restart: unless-stopped environment: # 容器內執行的代理人需標註身分，Herdr 才能正確偵測狀態 – HERDR_AGENT=hermes – OPENAI_BASE_URL=http://litellm:4000/v1 – OPENAI_API_KEY=sk-local-gateway volumes: – /share/AgentHub/workspace:/workspace – /share/AgentHub/state:/root/.local/share – /share/AgentHub/logs:/var/log/agents networks: – agentnet litellm: image: ghcr.io/berriai/litellm:main-stable container_name: litellm restart: unless-stopped command: [“–config”, “/etc/litellm/config.yaml”, “–port”, “4000”] env_file: – ./secrets.env volumes: – ./litellm-config.yaml:/etc/litellm/config.yaml:ro – /share/AgentHub/logs/litellm:/var/log/litellm networks: – agentnet networks: agentnet: driver: bridge
日常操作只需兩個指令。
# 進入 Herdr 工作區（TUI，離開時 ctrl+b q 即可 detach，代理人持續執行）
docker exec -it agent-hub herdr
# 為常用代理人安裝深度整合，取得精確語意狀態
docker exec -it agent-hub sh -c \ “herdr integration install claude && \ herdr integration install codex && \ herdr integration install hermes”
步驟二、DGX Spark 端啟動 vLLM
在 Spark 節點以 OpenAI 相容模式提供服務。模型與量化格式依實際需求替換。
vllm serve deepseek-ai/DeepSeek-V4-Flash \ –host 0.0.0.0 –port 8000 \ –max-model-len 65536 \ –gpu-memory-utilization 0.90 \ –served-model-name local-flash
NAS 與 Spark 之間建議走 10GbE 以上的直連或獨立 VLAN。模型檔若放在 NAS 的 NFS 模型庫，冷啟動載入速度受網路頻寬影響，大型模型建議改放 Spark 本機 NVMe，NAS 作版本備份、放不下或替換用、實用的模型。如果是雙機 GB10，那模型放 NAS 即可，忍受慢一點的載入速度，但雙機可共用 QNAP NAS 上的 NFS 磁區中模型權重檔案。
步驟三、LiteLLM 路由設定
這一層取代負責「路由與過濾」職責。以下為設定檔範例，請依據你的環境修改必要的設定。
# litellm-config.yaml
model_list:
# 本地推論，敏感任務唯一出口
– model_name: local-flash
litellm_params:
model: openai/local-flash
api_base: http://192.168.100.2:8000/v1
api_key: “none”
# 雲端模型，僅供已分級為可外送的任務
– model_name: claude-frontier
litellm_params:
model: anthropic/claude-sonnet-5
api_key: os.environ/ANTHROPIC_API_KEY
– model_name: gemini-flash
litellm_params:
model: gemini/gemini-3.7-flash
api_key: os.environ/GEMINI_API_KEY
litellm_settings:
drop_params: true
json_logs: true
# 送出前遮蔽常見敏感樣式（金鑰、內網路徑等），規則依組織需求擴充
callbacks: [“presidio”]
general_settings:
master_key: sk-local-gateway
Hermes 與自製腳本一律以 local-flash 或 claude-frontier 這類邏輯名稱呼叫模型，敏感等級的路由決策就固定在這份設定檔中，稽核時只需看一個地方。
步驟四、以 Herdr socket API 串自動化
Herdr 的 CLI 即 socket API 的包裝，任何 CLI 能做的事腳本都能做。以下範例讓 NAS 收到檔案事件後，開一個 pane 交給 Claude Code 處理，並等待完成。
#!/bin/sh # on-file-event.sh，由 QNAP 排程或 inotify 觸發 TASK_DIR=”/workspace/incoming/$1″ herdr workspace create review herdr pane spawn –workspace review \ — claude -p “審查 ${TASK_DIR} 內的程式碼變更，輸出報告至 ${TASK_DIR}/report.md” herdr wait –workspace review –state done cp “${TASK_DIR}/report.md” /var/log/agents/reports/
Hermes 端則利用其 cron 與技能系統承接例行任務，先呼叫 local-flash 做初步分析，判定需要更強推理時再改用雲端模型名稱重送，形成「本地優先、雲端升級」的兩段式流程。
以下是 herdy 同時監看四個 AI 代理人的畫面。
登入雲端 AI 代理人時，很多都要在雲端去設定用 device code 來登入，才有辦法在終端機中登入輸入使用，以下是 codex 在 openai 自己帳號中要設定這一條。
隱私邊界：哪些是可驗證的，哪些只是宣稱
去識別化與資料分級不能依賴代理人自律，要在網路與閘道層強制執行。
擋得住的
Hermes 與自製腳本的模型呼叫。它們的 OPENAI_BASE_URL 就是閘道，遮罩規則統一在 guardrails: 套用，不散落在各代理人的提示詞裡。敏感任務的 Hermes 設定檔只填本地模型名稱，該容器所屬網段在防火牆封鎖對外 443，物理上斷絕外送可能。
擋不住的
Claude Code、Codex CLI、Gemini CLI 的流量。它們走各家官方通道，不經 LiteLLM，閘道看不到也記不到。要控管只能另外做 egress 白名單，而白名單只能限制「連得到哪個網域」，管不到送出去的內容。
日誌的價值在於不可竄改
LiteLLM 的 json 日誌、herdr 的會話紀錄與 Hermes 的執行歷程全部落在 NAS 持久化目錄。這正是這類方案用 NAS 的最大優點——所有紀錄都有跡可循。搭配 QNAP ZFS 上的 WORM，定期同步到不可銷毀的目錄，合規條件會有實質提升。
優缺點與適用性評估
優點
常駐性
代理人活在 NAS 容器內的 Herdr 會話中，關筆電、斷 SSH 都不中斷，重開容器後會話可還原。
可觀測性
Herdr 側欄一眼看出哪個代理人卡住等輸入、哪個已完成待審，這是 tmux 加腳本難以複製的體驗。
成本結構清楚
本地推論零 API 費用，雲端走既有訂閱，LiteLLM 日誌又能量化各模型用量。
合規友善
路由決策集中於單一設定檔，日誌集中於 NAS，對 ITGC 或 ISO 27001 稽核而言證據鏈完整。
自動化天花板高
socket API 讓代理人之間可以互相開 pane、讀輸出、等待狀態，能組出領頭代理人分派多倉庫任務的進階玩法。
缺點與風險
Herdr 不含路由與過濾，需自行架設閘道層，整體元件數與維運面積比「單一框架」的想像更大。
訂閱制 CLI 代理人在無頭容器內的首次登入流程繁瑣，OAuth 裝置授權需人工介入，帳號憑證的持久化與輪替要另行設計。
容器內偵測有前提，代理人需正確設定 HERDR_AGENT 環境變數，且 pane 內不可再套 tmux，否則狀態偵測失效。
Herdr 屬 TUI 工具，日常需 attach 進終端機操作，對偏好 Web 介面的團隊有適應成本。
NFS 載入大型模型是明確瓶頸，未規劃直連網路或本機 NVMe 快取時，冷啟動時間會抵銷本地推論的延遲優勢。
專案因為比較新要多留意更新，Herdr 於 2026 年 3 月釋出，版本迭代快，生產環境導入前應鎖定版本並自行驗證升級路徑。
適用情境判斷
CyberQ 建議，同時跑兩個以上代理人、有私有資料不可外送的需求、且團隊具備容器與網路維運能力時，此架構的投資報酬最高。若只用單一雲端代理人處理公開資料，直接在工作機執行即可，不需要這套堆疊。
參考來源
Herdr 官方網站與文件 https://herdr.dev
Herdr GitHub repo https://github.com/ogulcancelik/herdr
Hermes Agent 官方網站 https://hermes-agent.org
Hermes Agent GitHub repo https://github.com/NousResearch/hermes-agent
LiteLLM 文件 https://docs.litellm.ai
