010. 從「會聊天」到「能長期運作」｜這支影片真正談的是基礎設施
Tina Huang 這支 29 分鐘影片表面上是 Hermes Agent 新手教學，但它真正有價值的地方，不是「去哪裡下載」「哪個按鈕怎麼點」，而是把一個本機 AI 助理要長期穩定運作時，背後需要的基礎設施攤開來看。
來源影片：Hermes Agent Fundamentals In 29 Minutes，Tina Huang，2026 年 7 月 20 日上傳。
她的核心訊息很直接：Hermes Agent 如果只是裝起來問幾句話，體驗和一般 chatbot 差不多；但如果硬體、模型、工具、記憶、skills、排程和訊息入口都設計好，它就會從一個聊天框變成可以被日常工作流呼叫的節點。
這也是本文想保留的編輯距離。影片本身有明顯的產品導覽與個人 workflow 展示，Tina 也會推薦她自己常用的設定；這些經驗有參考價值，但不是所有人都該照抄。真正值得帶走的是一套判斷框架：你的 agent 要住在哪裡？要用什麼模型當 driver？哪些工具可以開？哪些記憶應該長期保存？哪些任務可以排程？哪些地方必須保留人類驗收？
Hermes 的定位因此不是「比 ChatGPT 更會回答」，而是「把 LLM 接進本機與訊息平台的 agent runtime」。當任務從一次性問答變成多步驟工作流，這個差異才會變得重要。
021. Agent 先要有地方住｜硬體選擇其實是穩定性選擇
Tina 的主力環境是一台 64GB RAM、M4 chip、24/7 開機的 Mac Studio。這讓她可以在本機跑相當大的開源模型，只在需要高能力時才呼叫雲端模型。她提到，這台機器雖然購入成本高，但以她的使用量來看，長期比高度依賴雲端模型更便宜。
這個結論不能直接推給所有人，因為每個人的工作量、模型需求、電費、維護能力都不同。但它點出一個經常被忽略的事實：agent 的第一個產品問題不是模型，而是 uptime。你希望它在你傳訊息時醒著，在 cron job 到點時能跑，在背景任務排隊時不會因為筆電休眠而中斷。
影片列出四種常見選擇。第一種是強大的專用本機，例如 Mac Studio 或其他長時間開機的工作站；優點是隱私和效能，缺點是前期成本。第二種是 VPS，月費可能只要幾美元，24/7 在線，但雲端資源、隱私和模型能力需要自己評估。第三種是閒置筆電或舊電腦，成本低、資料留在本機，但穩定供電和散熱要自己處理。第四種是直接跑在日常電腦上，Tina 強烈建議用 Docker 隔離，避免 agent 的工具能力影響主系統。
這裡的工程判斷是：如果只是試用，任何一台電腦都行；如果要把它接進每天會發生的工作流，就應該把它當成一個小型服務來看。服務需要穩定執行環境、可預期資源、清楚權限邊界，以及出問題時可以重啟和觀察的方式。
032. 模型不是信仰，而是路由策略｜Provider 決定能力、成本與風險
安裝 Hermes 後，Tina 第一個看的不是外觀，而是模型選擇。桌面 app 可以連 Anthropic、OpenAI、News Portal、其他 provider，也可以接本機模型。她提到社群普遍認為 Sonnet 5 是很好的 Hermes driver，但 Anthropic API 成本可能很高；她自己的日常 driver 是本機 Qwen 3.6 35B 模型。
這段的價值不在於推薦某個單一模型，而是把模型選擇看成路由策略。Agent 任務有不同風險和成本結構：有些只是整理筆記、分類訊息、查詢資料；有些需要長上下文、複雜推理、穩定工具調用；有些牽涉隱私或本機檔案，不想送到雲端。把所有任務都丟給最貴的模型，未必是好工程；把所有任務都丟給本機模型，也可能在複雜任務上浪費時間。
比較合理的做法，是把 Hermes 視為 router：日常、低風險、可重試任務可以走本機模型；高難度規劃、重要寫作、複雜除錯才切到雲端強模型；中間則可以使用聚合 provider 取得方便的模型清單。這裡要看的指標不只是 benchmark，而是穩定性、延遲、上下文、工具調用能力、單次任務成本，以及失敗時是否容易定位。
Tina 推薦 Ollama 作為本機模型入門，因為它像模型 package manager；想要更多控制和速度，可以往 llama.cpp 走，但需要比較多終端設定。她自己的做法是讓 Hermes 協助安裝。這點也很有代表性：成熟的 agent 使用者不是永遠手動調每個工具，而是逐步讓 agent 參與自己的基礎設施建置。
043. Hermes 的能力堆疊｜Tools、Integrations、MCP、Skills、Cron 各自解不同問題
影片中最容易混在一起的部分，是 Hermes 的能力名稱：tools、integrations、MCP、skills、cron jobs。它們都讓 agent「能做更多事」，但層級不同。
Tools 是平台預先管理的工具能力，例如 web search、browser automation、image generation、file 操作等。它們是 agent 可以直接呼叫的手腳。Integrations 則把 Hermes 接到第三方服務，包含模型 provider，也包含 Discord、Telegram、WhatsApp 這類 messaging app。MCP 是更通用的工具協定，讓沒有原生 integration 的外部服務也能接進來；Tina 舉 NotebookLM MCP 作為研究與 daily brief 的例子。
Skills 則不是工具本身，而是完成一類任務的操作手冊。Tina 的示範很清楚：她先讓 Hermes 根據 bootstrap lifestyle business 條件評估商業 idea，加入評分維度、權重和 go/caution/no-go 建議，最後要求 Hermes 把這套方法做成 skill。下一次只要呼叫 business idea evaluator，agent 就能照同一套框架工作。
Cron jobs 解的是時間問題。許多任務不是人按下去才該做，而是每天、每週或固定條件出現時就該執行。Tina 的例子包括每天晚上生成隔天 daily brief 並輸出 audio、整理 Apple Notes 到 Obsidian、每晚檢查本機模型和多 agent 系統是否正常。這些都不是聊天能力，而是 agent 變成「長期服務」後才會需要的能力。
這套堆疊的順序很重要。Tools 讓 agent 能動手，integrations 讓它能接外部世界，MCP 讓工具面可擴充，skills 讓流程可重用，cron 讓流程能自動發生。少了其中任何一層，agent 都可能退回一次性助手；全部都打開但缺乏權限邊界，又會變成難以控制的自動化系統。
054. 記憶要精簡，不是貪多｜四層 memory 其實是資料治理
Tina 花了很長篇幅談 memory，這是整支影片最值得重看的部分。她說許多人用 OpenClaw、Hermes 或其他 agents 時，最後會遇到忘記事情、搜尋不到、變慢、流程壞掉。這些問題往往不是模型突然退化，而是記憶管理沒有設計好。
Hermes 預設有兩層記憶。第一層是核心 Markdown：memory.md 保存 setup 的重要資訊，user.md 保存使用者背景，soul.md 保存 agent 自己是誰。這些檔案刻意要短，因為每次都塞太多核心記憶，會讓 context 變慢也變髒。第二層是 session search，歷史對話存在 SQLite database，需要時才搜尋回來。Tina 示範詢問之前聊過的 business ideas，Hermes 透過 session search 找回過去的 micro-drama 和 AI learning app 討論。
她再加上第三層 Honcho，作為外部 memory provider。照 Tina 的說法，Honcho 會從互動中補充 implicit understanding，例如使用者習慣、專案模式、偏好和工作方式。這類資訊不一定適合手動寫進核心 Markdown，但可能在日常互動中讓 agent 更順。
第四層是 Obsidian second brain。這層和前三層最大的不同，是它同時服務人與 agent。研究筆記、專案 PRD、daily brief、決策紀錄、未來可延續的工作，都可以沉澱到 Obsidian vault。之後人可以直接閱讀，agent 也可以透過 Obsidian skill 找回來繼續工作。
這裡的編輯觀點是：memory 不該被理解成「讓模型記住越多越好」，而是一種資料治理。核心記憶放穩定、短、常用的事；歷史對話交給檢索；互動模式交給外部 provider；專案知識放進可閱讀、可維護的 vault。敏感資料、短期情緒、一次性任務細節則不該隨便進長期核心。
065. Skills 把提示變 SOP｜真正可重用的是流程，不是單句 prompt
Tina 的 business idea evaluator 範例，展示了 skills 的價值。一般 prompt 是一次性的：你今天要求 agent 用某套標準評估，它今天可能照做，明天還要重新說一次。Skill 則把任務流程寫成可重用 SOP：什麼輸入觸發它、要看哪些維度、怎麼給分、怎麼加權、輸出格式是什麼、最後如何給建議。
這對個人工作流尤其重要。很多人以為 AI 助理的關鍵是寫出一個神奇 prompt，但實務上更像建立一組小流程：研究 idea、整理筆記、保存到 Obsidian、生成 daily brief、檢查服務狀態、根據 PRD 建 MVP。每個流程都應該有輸入、輸出、驗證和失敗處理，而不是每次重新靠臨場指令。
Tina 示範把 AI learning app 的研究保存到 Obsidian，Hermes 會依照 Obsidian skill 使用 write file tool。這件事看似很小，但它說明 skill 的角色不是「讓回答更漂亮」，而是讓 agent 知道成果要落在哪裡、用什麼格式、供誰之後讀取。
這裡也要補上風險面。Skill 會引導 agent 使用工具，因此錯誤或惡意 skill 會放大副作用。若 skill 要求讀取大量私密資料、下載不明程式、關閉安全設定、或自動對外傳送內容，就不能只因為它是 Markdown 而放鬆警覺。可重用流程需要版本管理和審查，否則錯誤也會可重用。
076. 訊息平台改變使用場景｜Discord 不是外掛，是工作入口
Hermes 接 Discord、Telegram、WhatsApp 的能力，在影片裡不只是「多一個 integration」。Tina 把 Discord 當成主要操作介面：daily brief 送到指定 channel，帳單或任務狀態發通知，多 agent build 也在 Discord 裡排隊和回報。
這會改變 agent 的使用方式。終端機適合工程師，桌面 app 適合個人互動，訊息平台則適合把 agent 放進日常節奏。你可以在手機上丟任務，在群組或 channel 裡看狀態，在不同 channel 分隔 builds、alerts、research、briefs。對非工程師來說，這可能比打開 shell 更自然。
但訊息平台也讓邊界更重要。誰可以呼叫 agent？哪些 channel 的訊息能進 memory？群組裡提到的資料能不能被寫進 Obsidian？agent 什麼時候該回覆，什麼時候只要通知？如果任務會發送外部訊息、修改檔案或觸發付款，是否需要確認？
Tina 的展示偏向個人和小團隊環境，因此看起來很順。但一旦進入多人 channel，agent 就不只是工具，也是社交參與者。它需要權限、節制、可追蹤狀態和人工中斷能力。這些不是產品裝飾，而是 agent 進入真實協作後的必要設計。
087. 多 Agent 建置很迷人，但不要跳過驗收｜平行不是自動正確
影片最後的 demo 是最有吸引力的部分。Tina 在 Discord 裡要求 Hermes 為一個 Pomodoro app 起草 spec：可以輸入正在做什麼、設定時間、用視覺化倒數顯示剩餘時間，並把結果保存到 Obsidian vault。Hermes 產出 PRD 後，她回覆 yes queue it，任務進入隊列，之後 builds channel 顯示完成。
她打開成果測試：設定一分鐘，確認視窗能 always-on-top、可移動，完成後 Obsidian 裡出現紀錄。接著，她同時要求 Hermes 起草其他桌面 widget app 的 ideas，也要求把 Pomodoro app 改成 pastel 色系。這呈現了多 agent workflow 的魅力：需求、spec、排隊、實作、通知、回寫知識庫，可以在訊息平台裡串起來。
但這裡最重要的不是「AI 自己做出 app」，而是「流程被拆成可排隊、可平行、可回報、可驗收的單元」。多 agent 不是魔法，它只是把不同任務分派到不同工作者，並透過 queue 或 Kanban board 管理狀態。設計、實作、測試、修改可以平行，但最終仍需要人檢查成果是否符合需求。
這個 demo 也說明前面所有基礎設定為何重要。如果沒有穩定機器，任務跑到一半可能斷；如果 provider 不穩，agent 可能卡住；如果 skills 不清楚，成果不知道怎麼保存；如果 memory 混亂，下一次接續會找錯資料；如果訊息平台沒有邊界，通知和指令會失控。
098. 基礎設定的終點不是安裝完成｜而是可控的 AI 工作入口
把 Tina 的 29 分鐘壓縮成一句話：Hermes Agent 的價值，不在於把聊天介面換一個名字，而在於把模型、工具、記憶、排程、訊息入口和本機環境組成一個可長期演進的工作流節點。
這也是為什麼她反覆談「setup」。對 agent 來說，setup 不是一次性安裝，而是架構選擇。硬體決定能不能長期在線；provider 決定能力與成本；tools 和 integrations 決定能碰到哪些外部世界；skills 決定流程能不能重用；cron 決定任務能不能主動發生；memory 決定過去如何影響未來；Obsidian 這類 second brain 則讓知識在 agent 和人之間共享。
這套系統越強，越需要清楚的控制線。哪些任務可以自動化？哪些資料可以被記住？哪些工具需要人工確認？哪些成果要進 vault？哪些訊息只該當下回答、不該留下？這些問題比「哪個模型最聰明」更靠近真正的 agent 使用。
如果你只是偶爾問問題，普通 chatbot 已經足夠。如果你主要寫程式，coding agent 或 AI IDE 可能更直接。但如果你想把 AI 接到日常溝通、固定流程、本機知識庫和背景任務裡，Hermes 這類 runtime 就值得研究。它不是替你省掉所有判斷，而是讓你有機會把判斷沉澱成流程，讓 AI 在可控範圍內反覆執行。