Eric 老師的分享・2026-10-02 ～ 10-03

Docker Hermes Container 系統架構圖解

這是 Eric 老師 2026-10-02 分享的實機架構圖解（Windows 11 主機、Docker Desktop、Hermes Agent v0.21.5；老師說這套 Docker 版才架了兩天、功能還不多）。前四課是 10-02 的第一版講義（12 頁）；10-03 晚間老師又補充了兩份更新的圖解：v4（24 頁，第一版的更新與擴充）與 v5（20 頁，聚焦 LINE Webhook 與 NORTHWND MCP），分別放在第 05、06 課。

老師的話

目前使用 Docker 架構 Hermes 只有兩天，架構圖如附件請參考。

封面：Docker Hermes Container 系統架構圖解 — 封面（p.01）：容器運行架構、通道、排程與維運，以 Microsoft Azure 架構圖風格繪製。盤點日期為 2026-10-02 運行中容器實際檢視。

整體架構：一個容器，三個通道，一個資料 volume — 整體架構（p.02）：單一容器內整合 Dashboard、Gateway、Cron 與 Agent，對外僅本機埠與 LINE webhook，其餘皆出站連線。

課程地圖

第 01 課・p.01–03

整體與部署

先從大架構看起：一台 Windows 11 主機、一個 Docker 容器，以及如何用一份 docker-compose.yml 檔案把整個執行環境架構起來。

Docker Hermes Container 系統架構圖解

這是 Eric 老師使用 Microsoft Azure 風格整理的 Hermes Agent 架構盤點。整套系統運行在 Windows 11 主機的 Docker Desktop 上，由單一一個容器（container，也就是一個包好、彼此隔開的執行環境）承載，裡面包含管理介面 Dashboard、核心服務群與持久化資料夾 volume（容器外面、重建後還在的資料夾）。盤點基準為 2026-10-02 運行中的 Hermes Agent v0.21.5 實機狀態。

整體架構：一個容器，三個通道，一個資料 volume

這套架構最核心的特徵就是「一個容器、三個通道、一個資料 volume」。外部只有管理者的瀏覽器能打開本機埠 8000 看 Dashboard，以及 LINE 透過 HTTPS 隧道打進 8646 埠的 webhook（別的服務主動打過來通知的網址）。容器內部則由 s6-overlay（在容器裡負責把服務叫起來、掛了再拉起來的小管家）看管 Dashboard、Cron（定時排程）、Gateway 與 Agent，主動往外連線到 Ollama Cloud 模型、Gmail、新聞來源與 11 個 MCP（讓 AI 助理呼叫外部工具的標準接口）。

部署層：docker-compose.yml 一份檔案定義整個運行環境

老師透過一份 docker-compose.yml 宣告整套服務的啟動規格。映像檔採用官方的 hermes-agent:latest，並設定 restart: unless-stopped 讓 Docker Desktop 啟動時自動拉起容器。設定中將主機的 127.0.0.1:8000 轉發到容器內的 9119 Dashboard，將 127.0.0.1:8646 轉給 LINE webhook，帳號密碼與金鑰則透過 .env 檔案注入，不直接寫死在設定檔裡。

本課重點

單一容器架構：一台 Windows 11 主機跑一個 hermes 容器，結構清晰好管理。
三個通道分工：瀏覽器看儀表板、LINE 走 webhook 入口、外部服務走主動出站。
宣告式部署：一份 docker-compose.yml 搞定映像、連接埠、volume 與機密注入。

01 / 06

第 02 課・p.04–06

容器內部

鑽進容器內部探討細節：程序如何被 s6-overlay 看管、網路與連接埠如何隔離，以及狀態如何保存在 volume 中。

容器內部：s6-overlay 監督的程序樹

容器啟動時的第 1 號程序（PID 1）是 entrypoint-dispatch.sh，由它把後續工作交給 s6-overlay 建立整個服務監督樹。s6-overlay 同時看管負責網頁介面的 Dashboard 與負責通道、排程的 Gateway，讓單一容器內能穩定常駐兩大服務。服務程序以權限受限的 hermes 一般使用者身分執行，只有初始化與監督使用 root，一旦服務發生崩潰，監督器會自動重新拉起。

網路與連接埠：只有本機回環入口，其餘皆為出站連線

容器掛在獨立的 workspace_default 橋接網路上（位址 172.23.0.3），與主機上其他 Docker 專案彼此隔離。對內開放的 Dashboard（8000）與 LINE webhook（8646）都嚴格綁定在 127.0.0.1，區網上的其他電腦無法直接連入。其餘所有互動——包含連向 Ollama Cloud 推論、Gmail 收發信、新聞抓取以及呼叫外部 MCP 服務——全都是由容器主動向外發起的出站連線。

資料持久化：映像是唯讀程式碼，/opt/data 才是狀態

在容器世界中，映像檔本身是唯讀的，一旦容器重建或升級，容器內部的變更就會消失。因此系統將真正的狀態全部保存在名為 workspace_hermes-data 的 volume 中，掛載在容器內的 /opt/data（約 1.2 GB）。這裡面存放了設定檔 config.yaml、機密 .env、排程定義 jobs.json、自訂腳本、對話記憶與執行日誌，確保容器升級後資料依然完整。

本課重點

進程雙保險：s6-overlay 負責容器內進程自動重啟，Docker 的 restart: unless-stopped 負責容器層重啟。
進出嚴格分離：只有本機回環埠開放入站，區網完全封閉，其餘連線皆為出站連線。
狀態完全獨立：唯讀程式碼在映像層，可變資料全部收攏進 /opt/data 具名 volume。

02 / 06

第 03 課・p.07–09

通道與排程

看 Gateway 如何串聯三種連線通道，以及每天自動執行的兩大定時排程：科技新聞日報與早安打招呼。

Gateway 樞紐：三個通道已連線，推論交給雲端模型

Gateway 是整個系統的消息轉發樞紐，根據 2026-10-02 的狀態檢視，HTTP API 入口、Gmail email 與 LINE 三個通道皆已成功連線。所有對話與任務的語言模型推論都交由 Ollama Cloud 上的 glm-5.3 模型處理。設定檔中雖然列了 11 個外部 MCP 工具服務，但排程任務目前設定為停用 MCP（no_mcp），未登入的工具每 5 分鐘輸出 OAuth 警告也不會影響排程進行。

排程流程①：每天科技新聞（b71a65ee0d9c）

這是每天定時抓取科技新聞並整理寄出的自動化流程。排程在 UTC 06:00 觸發後，先執行前置腳本爬取 TechCrunch、Verge、MIT TR、Ars、HN 等來源近 48 小時新聞，再由 Agent 篩選 8 到 12 則重點並以繁體中文撰寫成報告存檔。最後透過 Gmail SMTP 送出，每天寄出 HTML 圖文信與純文字摘要兩封信到收件匣。

排程流程②：每天打招呼（4c9b336c55e5）與時區換算

排程流程②：每天打招呼與時區換算 — 圖 p.09 排程流程②——cron 0 22 * * *（UTC）＝台北每天 06:00；不需要工具，Agent 直接寫信，由 Hermes 遞送。

這是每天早晨寄送問候信的輕量排程，不使用外部工具，由 Agent 直接根據日期與季節變化撰寫 150 到 250 字的溫暖問候。排程器內部一律使用世界協調時間（UTC），因為台北時間比 UTC 快 8 小時，所以設定在 UTC 22:00 執行，剛好對應到台北時間隔天清晨的 06:00。信件撰寫完成後透過 Gmail SMTP 遞送純文字信到收件匣。

本課重點

三大通道暢通：API Server、Email、LINE 均顯示 connected 連線狀態。
科技新聞自動化：前置腳本爬蟲抓取資料，Agent 提煉重點，自動產出雙版本郵件。
時區換算陷阱：cron 排程以 UTC 為準，台北早上 06:00 必須設為前一天的 UTC 22:00。

03 / 06

第 04 課・p.10–12

安全與維運

最後梳理安全防護的信任邊界、日常維運的指令速查表，以及從這套架構帶走的核心結論。

安全與信任邊界：誰能碰到什麼

這頁梳理了從外部網際網路到容器內部 volume 的五道信任邊界，並列出已落實的控制措施與待改善項目。目前已落實連接埠只綁本機、Dashboard 密碼保護、機密存放在 volume 且限制權限、排程停用危險執行碼等機制。老師自己也在講義中註明了待改善與風險，包括 LINE 隧道需補強驗證、建議撤銷並重建信箱的應用程式密碼、映像檔宜固定版本標籤避免漂移、volume 資料應補上異地備份，以及 7 個 MCP 服務尚未登入、會持續輸出警告等。

維運速查與已知限制

這頁整理了日常維運最常用的 PowerShell 指令速查表，涵蓋啟動、查看日誌、修改設定後重啟、排程檢查與健康診斷。同時列出了五項已知限制：操作排程時一律要加 -u hermes 避免以 root 寫入檔案導致權限錯亂；修改 .env 必須重啟容器；排程失敗判定以「是否收到信」為準；排程時間必須以 UTC 換算；以及 Docker Desktop 與容器必須持續保持開機運行排程才會被觸發。

重點回顧

1個容器

2個本機埠

1個 volume

3個通道連線

2個排程 job

最後一頁用數字精簡回顧整體架構：「1 個容器、2 個本機埠、1 個 volume、3 個通道連線、2 個排程 job」。整個系統的維運核心原則在於：容器持續運行排程才會觸發；所有設定與對話記憶狀態都在 /opt/data volume 裡；對外唯一的暴露面只有需要 HTTPS 隧道的 LINE webhook。這份架構展示了在個人主機上穩定運作 AI Agent 助理的完整容器化實踐。