如果你把 ChatGPT 或 Claude 想成「你問一句，它回一句」，Hermes Agent 比較像一個可以被配置的工作夥伴。它背後仍然需要模型，但模型不是全部。Hermes 還會處理工具、終端機、檔案、記憶、Skills、Profiles、MCP 和排程，最後才把這些東西組成一次任務的執行流程。
這個差異也帶來一個不太浪漫的前提：Hermes 能做的事情越多，你越需要知道它會在哪裡執行、讀哪些資料、是否能寫檔案，以及失敗時要怎麼停下來。只想找一個網頁聊天工具的人，不一定需要 Hermes；想把重複工作交給一個能使用工具的 Agent，才值得花時間理解它。
本文以 Hermes Agent 官方文件在 2026-09-15 的可見內容為界，整理安裝路線、模型與工具的分工、Memory 與 Skills 的差別、Profiles、MCP、Cron，以及我會如何做第一次低風險評估。文中明確標出官方已說明的功能、本文建議和目前沒有辦法替你確認的帳號與環境狀態。
文章目錄
Hermes Agent 是什麼？先講它和聊天工具差在哪
Hermes 不只是另一個聊天視窗
依 Nous Research 的官方文件，Hermes Agent 是一個可以使用工具、保存跨工作階段記憶、建立 Skills、連接 MCP Server 和執行排程的 Agent。它可以在命令列、桌面程式或訊息平台中運作，也能把真正的命令交給本機、Docker、SSH 或其他執行環境。
這裡要先把兩個概念分開。模型負責理解任務、產生下一步和回應文字；Hermes 負責提供可呼叫的工具、保存狀態、套用設定、執行命令並把結果帶回模型。模型換了，工作環境和權限不一定跟著換；反過來，工具開很多，也不表示模型就能正確使用它們。
你可以把它想成一個工作台。模型是坐在桌前做判斷的人，工具是桌上的終端機、檔案櫃和電話，Memory 是小型工作筆記，Skills 是寫好的操作手冊，Profile 則是另一間有獨立資料的辦公室。這個比喻不完美，但至少能提醒你：把工具接上去，不等於任務已經驗收。
先用五個元件看懂架構
| 元件 | 官方文件目前描述的角色 | 第一次評估要問的問題 |
|---|---|---|
| Model | 提供推理與回應能力，能搭配不同 provider 或 endpoint | 這次用哪個 provider、模型和上下文設定？ |
| Tools | 包含網路搜尋、瀏覽器、終端機、檔案、記憶與代理協作等工具集 | 任務真的需要哪些工具？其餘能不能關掉？ |
| Memory | 以 MEMORY.md 和 USER.md 保存有限的跨工作階段資訊 | 哪些資料值得長期保留？是否需要人工審核寫入？ |
| Skills | 可以按需載入的程序文件，也能由 Agent 建立或修改 | 這份 Skill 是可重用流程，還是某次任務的暫存筆記？ |
| Profile | 獨立的 Hermes home，包含設定、憑證、記憶、Sessions、Skills 和 Cron | 工作資料是否應該和個人或其他專案隔離？ |
這張表是閱讀和設計工作流程的框架，不是 Hermes 官方宣稱的品質排名。它的用途是把「Hermes 很強」拆成比較可檢查的問題。當你發現自己只會說「我想讓它自動處理」，通常就是還沒把這五個元件分開。
Hermes 和 AI Agent Harness 的關係
如果你想先理解模型、工具、狀態和驗收層怎麼拼在一起，可以延伸閱讀AI Agent Harness 是什麼？模型、工具、記憶與執行環境的差別。那篇處理的是較上位的概念；本文把 Hermes 當成一個具體產品來看。
Hermes 不是理論上「任何 Agent 都應該有的唯一標準實作」。它只是把很多執行層功能放在同一個產品裡。你因此得到較完整的工作台，也同時需要承擔更多設定和權限管理，這是功能範圍帶來的取捨。
安裝前先確認平台與執行路線
官方支援矩陣要先看，不要先貼安裝指令
Hermes 官方平台支援文件目前把 macOS Apple Silicon、Windows 10／11、Linux／WSL2 和 Docker 列在 Tier 1。Android Termux 與 Nix 是 Tier 2，官方說明它們採取較接近 best effort 的維護方式。macOS Intel，以及透過 PyPI 或 Homebrew 安裝，在目前文件中列為不支援。
這個資訊會直接改變你的安裝決定。如果你使用 Apple Silicon Mac，官方列出 Hermes Desktop 或 install.sh。如果你用 Linux、WSL2 或 Android Termux，官方列出 install.sh。Windows 原生安裝則使用 Hermes Desktop 或 install.ps1。至於你的實際帳號、CPU 架構、公司管理政策和網路限制，本文沒有辦法替你讀回，仍要在自己的機器確認。
我會把「官方支援」和「網路上有人成功」分開。社群文章可能提供額外排錯線索，但不能覆蓋官方目前標示的不支援路線。尤其是安裝工具會改變 PATH、建立使用者目錄或下載依賴，先確認平台，後面比較不會忙著修一個一開始就不該走的路線。
Desktop 和 CLI 怎麼選
如果你想先看清楚多個 Profile、工作專案和連線狀態，Hermes Desktop 的入口比較直觀。官方文件也提供 CLI-only 安裝方式，適合你想在終端機、遠端主機或腳本中使用 Hermes 的情境。這不是功能高低的排名，而是操作入口不同。
macOS、Linux、WSL2 和 Android Termux 的 CLI 安裝指令是：
curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash
Windows 原生 PowerShell 指令是：
iex (irm https://hermes-agent.nousresearch.com/install.ps1)
這兩條指令來自 Hermes 官方首頁的安裝區塊。執行遠端腳本前，我建議至少先打開官方安裝文件閱讀它會處理的目錄、依賴和平台注意事項。這是一個安全習慣，不是說指令本身一定有問題。把一段你沒讀過的腳本直接丟給高權限 shell，之後再問「它到底改了什麼」，通常已經太晚。
安裝後先做兩個檢查
完成安裝後，先確認版本與診斷結果，再連接外部工具。官方快速入門文件建議使用 hermes --version 和 hermes doctor 來確認安裝、設定、依賴和環境狀態。
我會把檢查結果留在一次安裝紀錄裡，至少包含：
- 作業系統與 CPU 架構。
hermes --version的輸出。hermes doctor是否有錯誤、警告或未設定項目。- 使用的 Profile、模型 provider 和終端機 backend。
- 這次測試的工作目錄，以及是否含有敏感資料。
官方文件列出的支援平台不代表你的這次安裝已經通過。版本能輸出，也不表示模型連線、工具權限和排程服務都正常。這些要分開測，否則最後只會得到一個很有自信的「好像可以」。
第一次設定：先把模型、工具和工作目錄分開
hermes setup --portal 是快速路線，不是所有帳號的保證
Hermes 官方首頁把 hermes setup --portal 列為最快進入可工作狀態的路線，說明它會透過一次 OAuth 設定模型，以及 Tool Gateway 裡的網路搜尋、圖片生成、TTS 和瀏覽器工具。官方工具文件另列出，這些 Tool Gateway 能力與 Nous Portal 訂閱和帳號條件有關。
所以你可以把這條指令理解成「官方提供的快速設定入口」，不要理解成「每個人都會得到相同工具」。是否能使用某個工具，還要看你的 Portal 方案、登入狀態、所在環境和當時的產品設定。文章查證的是官方文件，不是你的帳號 readback，因此實際可用工具仍標為 unknown。
如果你不使用 Nous Portal，官方也支援其他 provider 和 endpoint。這時候要自己設定模型、API 憑證與工具，設定彈性較大，初次排錯也比較多。我的建議是先選一條路線完成一個小任務，不要第一次就同時換 provider、加 MCP、開 Cron，再把錯誤歸因給「模型不夠聰明」。
先用最小工具集開始聊天
官方工具文件提供 hermes tools 查看和設定工具，並示範用 hermes chat --toolsets "web,terminal" 只開啟指定的工具集。你不一定要照這個例子把終端機打開，重點是先建立最小權限的測試環境。
第一次測試可以只選一個不會改動資料的任務，例如：
- 讀取一個公開文件並列出它的章節。
- 讀取測試資料夾中的兩個檔案，回報檔名、大小與格式。
- 把一段你已經知道答案的文字整理成固定欄位。
不要一開始就叫它清理整個家目錄、操作正式資料庫、寄信或修改公開內容。這不是因為 Hermes 一定會做錯，而是第一次測試的目的應該是確認「它看到什麼、用了什麼工具、輸出在哪裡」，而不是直接用高風險任務替你完成工作。
模型、工具和結果要分開驗收
一次 Agent 任務至少有三個可能出錯的地方。模型可能理解錯問題，工具可能執行在錯的目錄，結果也可能回來了但沒有被你驗收。這三者混在一起時，你很難知道是 Prompt、權限、執行環境還是資料本身造成問題。
| 檢查層 | 你要讀回什麼 | 通過的意思 |
|---|---|---|
| 模型 | 使用的 provider、模型、上下文或錯誤訊息 | 你知道這次回答由什麼條件產生 |
| 工具 | 實際呼叫的工具、參數、工作目錄和回傳結果 | Agent 沒有超出你預期的操作範圍 |
| 產物 | 檔案、訊息、資料列或報告的實際內容 | 結果符合任務，且能回查輸入和限制 |
這也是我不會把單次「成功回答」當成流程通過的原因。能回一句正確文字，和能穩定、安全地執行一個有副作用的工作，是兩種不同的測試。
工具與執行環境：能做事，也可能碰到你的機器
內建工具涵蓋的範圍很廣
Hermes 官方工具文件列出的工具類別包含 Web 搜尋、瀏覽器自動化、終端機與檔案、媒體、Agent 協作、Memory、Session 搜尋、Cron，以及 MCP Server 工具。這些能力讓 Hermes 可以從「產生文字」走到「讀取、計算、修改或發送」的工作流程。
也正因如此，工具名稱不能代替權限說明。terminal 可能代表直接在本機執行命令，也可能是 Docker、SSH 或雲端 Sandbox。file 代表的讀寫範圍也和 Profile、工作目錄與設定有關。要判斷風險，必須知道工具的實際 backend 和允許的資料範圍。
Local、Docker、SSH 的差異
Hermes 官方設定文件目前列出七種終端機 backend。本文第一次評估先看最常用的三種：
| Backend | 官方文件描述的執行位置 | 我會怎麼看 |
|---|---|---|
local | 直接在你的機器執行 | 開發方便，但沒有隔離；不要把它誤當沙盒 |
docker | 在持續的 Docker 容器中執行 | 適合想先建立容器邊界的測試和自動化 |
ssh | 透過 SSH 到遠端主機執行 | 把工作移到另一台機器，仍要管理遠端憑證和權限 |
官方安全文件很直接地說明，命令阻擋規則不是完整的 shell 直譯器，也不是作業系統 capability sandbox。若你的要求是「Agent 就算被錯誤引導，也不能碰到主機」，只開一個 deny rule 不足以達成；你需要隔離的執行 backend、受限的工作目錄和不外傳的憑證設定。
這裡是技術特性和本文建議的分界。Docker 是否適合你的環境，是基於隔離特性的工作建議；它不代表每個 Docker 配置都安全，也不代表你已經完成資料、網路和憑證的威脅模型。
工作目錄和憑證比漂亮的 Prompt 更重要
要讓 Agent 操作專案，通常需要指定工作目錄或掛載資料夾。官方設定文件提醒，Local backend 沒有隔離，Docker 是否看得到主機工作目錄則是需要明確設定的選項。你應該先決定它能讀哪一個目錄，再決定要不要開啟寫入。
API key 和其他秘密也要留在適合的秘密檔案，不要寫進 Prompt、Skill、Git repository 或 Profile 匯出檔。官方安全指南建議把 API key 放在 ~/.hermes/.env，並以適當的檔案權限保護。不同 Profile 使用不同 provider 時，也要確認憑證沒有因複製設定而共用錯誤對象。
Memory 和 Skills 怎麼分？先把兩種記憶拆開
Memory 放少量、長期有用的事
Hermes 官方Persistent Memory 文件目前描述兩個內建記憶檔：MEMORY.md 用來放環境、慣例和學到的事情，USER.md 用來放使用者偏好與溝通方式。文件列出兩者的字元上限，分別是 2,200 和 1,375 個字元，並說明它們會在新的工作階段載入成固定快照。
這種記憶適合保存「下個月還可能有用」的資訊，例如專案使用的套件、固定的輸出格式、使用者偏好或一條已確認的工作慣例。它不適合放完整執行紀錄、今天的待辦、一次性的錯誤堆疊或所有讀過的文件。官方文件也提醒記憶是 bounded、curated 的設計，容量有限不是缺點補丁，而是要求你不要把它當資料倉庫。
我會先把資料分成三類：長期事實留在 Memory，重複程序寫成 Skill，正在進行的任務留在工作檔案、Issue 或 Session。這是本文建議，不是 Hermes 的唯一官方分類；好處是你日後比較容易知道資料為什麼在那裡。
Skills 放可以重複執行的程序
Hermes 官方Skills 文件把 Skills 描述成按需載入的知識文件，並指出 Agent 可以使用 skill_manage 建立、更新或刪除自己的 Skills。官方文件把 Memory 和 Skills 的分工說得很清楚：Memory 儲存少量、每次都可能有用的事；Skills 儲存需要在相關任務才載入的較長程序。
一份好的 Skill 不只寫「請完成某件事」，而是寫清楚前提、步驟、命令、輸出格式、常見失敗和驗收方式。例如部署檢查 Skill 應該知道先讀哪個設定、怎麼做 dry run、錯誤時要停在哪裡、成功後要讀回哪個 URL。這種內容有點像操作手冊，不是把一段漂亮 Prompt 換個檔名而已。
Memory、Skills 和任務狀態對照表
| 資料類型 | 適合放什麼 | 不適合放什麼 | 例子 |
|---|---|---|---|
| Memory | 穩定偏好、環境事實、已確認慣例 | 大段原始紀錄、短期待辦 | 「輸出用繁體中文」 |
| Skill | 可重複的工作程序與驗收規則 | 只發生一次的臨時決定 | 「部署前做檔案、HTTP 和 DOM 讀回」 |
| Task state | 當前分支、進度、錯誤、待確認事項 | 需要跨所有任務永久套用的偏好 | 「這次 preview 還缺正式 URL readback」 |
社群討論中也有人把這三層分開使用，這可以作為觀察到的實務用法，但不是普遍共識，也不是官方要求。即使你不採用社群配置，這個分法仍然是一個合理的整理方式，因為它讓資料生命週期比較明確。
先用人工審核避免 Agent 把錯誤寫成記憶
Hermes 官方文件提到，Memory 和 Skills 都可能在自我改善流程中被新增或修改；設定中的 write_approval 可以要求寫入先經過人工批准。這對剛開始測試的 Profile 很有用，因為你還不知道 Agent 會把哪些內容判定成值得保留。
我的建議是先讓它只保存一條你能回查的工作規則，然後重新開一個 Session 測試是否真的被正確使用。如果那條記憶把一次性的錯誤、客戶資料或猜測寫成長期事實，就先修正分類，再擴大工具權限。這個步驟會慢一點，但刪掉錯誤的長期記憶，通常比第一次就不讓它寫入更麻煩。
Profiles：讓不同工作不要共用同一個狀態
Profile 是獨立的 Hermes home
Hermes 官方Profiles 文件把 Profile 定義成獨立的 Hermes home directory。每個 Profile 有自己的 config.yaml、.env、SOUL.md、memories、sessions、skills、cron jobs 和 state database。這讓你可以把 coding、research 和個人助理分成不同的執行身份。
這件事比換一個對話名稱嚴格得多。不同 Profile 可以使用不同模型、工具、記憶和工作目錄，這才是「隔離工作脈絡」的實體邊界。當然，若你把同一個主機目錄或相同的秘密掛載給所有 Profile，隔離效果就會打折，這部分仍要看你的設定。
建立 Profile 的基本路線
官方文件提供的 quick start 是先建立一個命名 Profile，再用它自己的 alias 設定和聊天：
hermes profile create coder
coder setup
coder chat
也可以用 -p 明確指定 Profile，例如：
hermes -p coder chat
hermes --profile=coder doctor
如果你只想先建立一個乾淨的研究環境，可以不要把既有 Profile 的設定和記憶複製過去。官方也提供 --clone 和 --clone-all，但兩者的複製範圍不同，尤其是憑證、Memory、Sessions 和 Cron。需要備份或移交時，先讀官方文件再決定要複製哪些東西，不要看到 clone-all 就按下去，這個選項的名字已經很誠實了。
Profile 和工作區不要混為一談
Profile 是 Agent 的設定與狀態邊界，工作區則是它實際讀寫的檔案範圍。你可以有一個工作 Profile 操作多個專案，也可以為同一個專案建立不同 Profile，但這兩種設計的權限和記憶後果不同。
我會先用「一個敏感度或責任邊界一個 Profile」的原則。例如公開內容研究可以放在 research Profile，能改程式的 coding Profile 則另外管理。這不是官方規定的唯一方法，是基於 Profile 有獨立設定、憑證和記憶的技術特性所提出的風險降低建議。
MCP：延伸能力之前，先縮小暴露範圍
MCP 在 Hermes 裡像一個外接工具層
Hermes 官方Use MCP with Hermes說明，MCP 適合用在已有 MCP 形式的工具、想透過乾淨的 RPC layer 操作本機或遠端系統、需要每個 Server 的工具暴露控制，或要連接內部 API 和資料庫而不修改 Hermes core 的情境。
官方同一份文件也提醒，若 Hermes 已有很適合的內建工具、Server 暴露了很大的危險工具面，或者你只需要一個很窄的整合，MCP 可能不是好的第一步。這個界線很實用。MCP 的價值是可組合，不是把每個能找到的 Server 都接上去。
第一個 MCP Server 先做成唯讀和單一路徑
官方文件提供以檔案系統 Server 讀取單一專案目錄的示例。概念上可以是：
mcp_servers: project_fs: command: npx args: -y @modelcontextprotocol/server-filesystem /home/user/my-project
上面為了維持文章可掃讀，把 YAML 壓成一行；實際設定仍應依官方MCP 設定參考使用正確的縮排和欄位。這段示例的重點不是命令列格式，而是最後一個路徑。先讓 Server 只看一個測試資料夾，並確認它實際暴露了哪些 tools、resources 和參數。
第一次連接我會做四個檢查：
- Server 的來源、版本和啟動命令是否可追溯。
tools清單是否只有任務需要的工具。- 讀取路徑是否沒有包含秘密、客戶資料或整個家目錄。
- 是否能在不寫入、不傳送、不刪除的條件下完成第一個測試。
如果 Server 同時能讀取、修改、刪除和傳送資料，先不要因為它「功能完整」就當成更好。完整的工具面等於更大的錯誤半徑，除非你已經有明確的批准流程、隔離環境和可回復備份。
Hermes Agent、MCP 和權限檢查
你可以延伸閱讀Model Context Protocol 是什麼？連接 AI、工具與資料的協定解析，先理解 Host、Client、Server、Tools 和 Resources 的分工。但不要把協定層的連線成功，翻譯成產品層的安全或資料正確。
官方文件的「能連接」只證明配置有一條可用的連線路徑。你的任務還需要驗收 Server 是否看得到正確資料、工具參數是否限制在預期範圍、輸出是否有副作用，以及憑證是否只在必要的程序中出現。這些是實際部署條件，不會因為設定檔看起來很短就自動消失。
Cron：排程很方便，但先做 canary
Cron 是獨立執行的工作，不是把聊天視窗留著
Hermes 官方Cron 文件目前列出一次性和週期性任務、暫停、恢復、手動執行、附加 Skills、交付到本機檔案或訊息平台，以及不需要 LLM 的 script-only job。Cron 由 gateway daemon 處理，官方說明 scheduler 每 60 秒檢查一次，並在獨立的 Agent session 中執行到完成。
這代表排程工作不會自動繼承你現在聊天裡的全部上下文。官方文件也提醒 Cron 預設可能和目前的 repository 脫離，若任務需要特定工作目錄，要明確設定 workdir。Prompt、Skill、模型、provider、工作目錄和交付目標都應該寫進排程設計，而不是靠「它應該記得」來維持。
先用 local 交付測試，不要第一天就傳到外部平台
第一次排程我會用一個低敏感度的檔案輸出，例如每日把公開來源的摘要存到 Profile 內的 output 目錄。先測試一次手動執行，再把同一個工作改成週期任務。若輸出包含收件人、客戶資料、公開貼文或正式資料庫，就另外安排人工核准和失敗回報。
官方文件提供的 CLI 形式例如：
hermes cron create "every 2h" "Check server status"
如果你想建立一個暫停的 canary，官方也提供 --paused 與 --paused-reason。這個設計很適合先留下工作定義，等你檢查模型、工具、工作目錄和交付目標後才 resume。排程的問題通常不會在建立那一秒出現，而是在隔天沒人盯著時才出現，先暫停是一個便宜的保險。
Cron 的完成不等於內容正確
Hermes 官方文件目前也描述 Cron execution ledger，將嘗試分成 claimed、running 和 completed、failed、unknown 等終態，並說明 unknown 嘗試不會自動重跑。這是一個很重要的觀念：系統知道一次執行的狀態，不代表你的輸出就通過內容或業務驗收。
我會另外檢查：檔案是否真的產生、資料是否來自正確來源、報告日期是否正確、交付是否到對象，以及錯誤時是否停止而不是重複寫入。若工作會花錢、改正式資料或對外發送，還要把「unknown 時怎麼處理」寫成明確規則，不要讓排程自己猜。
安全設定：哪些地方一定要保留人工確認
Approval 是護欄，不是完整沙盒
Hermes 官方Security 文件列出的安全層包含使用者授權、危險命令批准、檔案寫入安全、容器隔離、MCP 憑證過濾、Context file 掃描、跨工作階段隔離和輸入清理。這些是多層防護，但每一層處理的問題不同。
官方目前把 approvals.mode 的預設列為 smart，也支援 manual 和 off。off 等同於停用所有安全提示，官方明確提醒只應該在信任的環境或已隔離的容器中使用。對 Cron、單次查詢和 unattended session，文件也列出 cron_mode、single_query_mode 和 unattended_mode，預設方向是拒絕無法由人即時批准的危險命令。
我的建議是第一次測試維持 smart 或 manual，並把真正有副作用的動作列入人工確認。不要為了讓排程「不卡住」就把 approvals.mode 改成 off，然後把測試通過寫成自動化成功。那只是少了一個會阻止你的提示。
把「讀取」、「寫入」和「對外發送」分成三個等級
| 動作 | 例子 | 第一次測試的建議 |
|---|---|---|
| 讀取 | 讀公開文件、列出測試目錄、查詢不含個資的資料 | 可以先做，仍要檢查範圍和來源 |
| 寫入 | 建立草稿、修改本機檔案、寫入資料庫 | 先限定目錄，保留版本和回復方式 |
| 對外副作用 | 寄信、發文、刪除、付款、修改正式資料 | 先產生預覽，再由人確認對象、內容和時間 |
這是本文的風險分級，不是 Hermes 官方的唯一分類。它的好處是讓權限設計和驗收條件綁在一起。你不必把所有任務都做成完全手動，但應該知道哪一級失敗時會影響誰，以及能不能回復。
需要真正隔離時，請用執行環境處理
官方安全指南指出，Local backend 的命令會在你的機器直接執行；Docker backend 提供容器隔離；SSH 則把執行移到遠端主機。這三者的風險不同。若你要測試陌生 MCP Server、下載不熟悉的套件或允許 Agent 執行較廣的命令，我會優先考慮獨立的容器或專用遠端機器。
但容器也不是一句「Docker」就完成的安全設計。還要看掛載了哪些路徑、是否有網路、forward 了哪些環境變數、容器是否允許存取秘密，以及資料要怎麼保存和清除。官方文件建議在生產部署使用容器 backend、限制資源、保護 .env、設定使用者 allowlist 和定期檢查 command allowlist；這些要求值得保留在你的部署清單。
訊息平台和排程要特別小心
Hermes 可以透過多種訊息平台和 gateway 使用。這會讓 Agent 從一個本機工具變成有人可以遠端叫它做事的服務，因此要重新檢查誰能發訊息、哪些命令能被觸發、回覆會送到哪裡，以及外部平台是否保留內容。
我不會把「有登入」當成「授權已完成」。登入只回答你是誰，allowlist、DM pairing、工作目錄、模型工具設定和 approval policy 才回答你能做什麼。這些設定如果沒有實際讀回，就保留為 unknown，不要從文件的範例值推算你的環境。
一套低風險的 Hermes Agent 評估流程
第一步：選一個知道答案的任務
不要一開始測「幫我經營整個專案」。選一個你可以人工核對的任務，例如讀兩份公開文件、整理一份測試 CSV，或把一段文字轉成固定欄位。這個任務不必很厲害，反而要容易知道哪裡對、哪裡錯。
測試資料最好是可以丟掉的副本，來源清楚、沒有客戶個資，也不會因為 Agent 寫錯就影響正式流程。你是在測工作台，不是在賭一個模型會不會剛好表現很好。
第二步：建立專用 Profile 和最小工具集
先建立一個命名 Profile，確認它的模型、工具、記憶和工作目錄。只開完成任務需要的工具，把 MCP 和外部發送先關掉。若任務只需讀檔，就不要同時開啟寫入、瀏覽器和訊息傳送。
可以在紀錄中寫下：
- Profile 名稱與路徑。
- 模型 provider 和版本輸出。
- 啟用的 toolsets。
- terminal backend、工作目錄和掛載路徑。
approvals和 Cron 相關設定。
這些資訊之後用來重現失敗，不是為了把文件寫得很像稽核報告。等你真的遇到「昨天可以、今天不行」時，才會發現前提沒有留下來很麻煩。
第三步：先看它打算怎麼做
給 Agent 的任務要要求它先報告輸入範圍、預計使用的工具和輸出位置。這不是要它寫一篇計畫書，而是讓你有機會在副作用發生前發現方向不對。
例如你可以要求：先列出會讀取的檔案；只使用指定資料夾；不要寫入；完成後回報使用的命令與輸出檔路徑；資料缺少時標記 unknown。這些是本文建議的驗收條件，不是 Hermes 會自動套用的安全政策。
第四步：把模型、工具和產物分開核對
讀回結果時，不要只問「答案看起來對不對」。把它拆成三件事：模型是否理解任務，工具是否在正確範圍內執行，產物是否真的符合格式和內容要求。
如果工具呼叫失敗，記錄失敗和它的替代路線；不要只重跑到成功。若 Agent 改了檔案，對比原始副本；若它算了資料，拿一個你知道答案的樣本核對；若它產生報告，打開原始來源讀回引用。這種驗收比再加一句「請仔細一點」有效很多。
第五步：只把重複成功的流程做成 Skill 或 Cron
一次成功的聊天不值得立刻做成 Skill。先用同一個任務在不同輸入、不同日期或不同 Session 重做幾次，確認它的前提和失敗界線，再把程序整理成 Skill。需要固定時間執行時，再用 paused canary 建立 Cron，先觀察輸出，再放大頻率和權限。
如果流程中還有一個你說不清楚的步驟，就不要急著自動化。可以把它標成待確認問題，或先讓 Agent 只產生草稿。自動化的價值不是少按幾個按鈕，而是讓結果更可預期；如果只是把猜測跑得更快，通常不值得。
Hermes Agent FAQ
Hermes Agent 是 ChatGPT 或 Claude 的替代品嗎？
它們不是同一層產品。ChatGPT 和 Claude 主要以對話產品呈現，Hermes Agent 則提供一套可以搭配不同模型、工具、記憶、Skills、Profiles 和排程的執行環境。你可以把 ChatGPT 或 Claude 當成模型或服務選項之一，但實際可用方式仍取決於 Hermes provider 設定和帳號條件。
如果你的需求只是問答、改寫或偶爾整理文件，先使用現有聊天工具可能比較省設定。若你需要終端機、可重用程序、獨立 Profile 或持續排程，Hermes 才有比較清楚的導入理由。這是依工作條件提出的建議，不是產品性能排名。
Hermes Agent 可以在 macOS Intel 上安裝嗎？
目前官方平台支援文件把 macOS x86，也就是 Intel Mac，列為 unsupported。macOS Apple Silicon 則列在 Tier 1，官方列出的安裝方法包含 Hermes Desktop 和 install.sh。你的機器如果是特殊虛擬化環境，仍要依實際診斷結果判斷；不要用社群文章中的成功案例覆蓋官方支援矩陣。
Hermes Agent 的 Memory 和 Skills 有什麼差別？
Memory 適合放少量、跨工作階段仍然有用的個人偏好、環境事實和慣例。Skills 適合放只在相關任務才需要載入的完整程序、命令和驗收規則。當前任務進度和錯誤則應該留在 Session、工作檔案或 Issue，不要全部塞進 Memory。
這是根據官方 Memory 與 Skills 文件整理出的分工。字元上限、寫入批准和 Profile 隔離等設定仍以你目前版本的官方文件與實際設定為準。
接上 MCP Server 之後就安全了嗎？
不會。MCP 解決的是工具和資料的連線方式，不會自動替你判斷 Server 是否可信、工具是否過多、參數是否有副作用或資料是否應該被讀取。Hermes 官方建議先使用單一、範圍小、能控制暴露工具的 Server；本文再加上先唯讀、先測試資料、保留人工核准的建議。
實際測試時，請確認 Server 來源、版本、工具清單、可讀寫路徑、憑證和輸出位置。連線成功只能算配置通過，不能算資料治理或安全驗收通過。
使用 Hermes Agent 的 Tool Gateway 需要付費嗎？
官方首頁和工具文件目前都把 hermes setup --portal 與 Nous Portal 放在一起說明，工具文件也指出 Tool Gateway 的網路搜尋、圖片生成、TTS 和瀏覽器能力與付費 Nous Portal 訂閱者有關。實際可用性可能依帳號、方案和當時產品設定改變，本文不列固定價格，也沒有讀取你的帳號方案。
如果你要評估成本，請在自己的 Portal 或 provider 設定中確認模型、工具和額度，再用同一個低風險任務測試。不要把官方文件中的功能清單直接當成你今天一定可用的服務清單。
Cron 任務會記得我現在聊天裡的內容嗎？
不應該這樣假設。官方 Cron 文件說明排程會在獨立的 Agent session 中執行，並提醒它不會自動載入目前 repository 的專案規則。需要固定背景、Skill、模型、工作目錄或交付對象時，要把它們明確寫進 Cron 設計。
即使排程有 Memory 或 Skill，也要驗收實際輸出、日期、來源和副作用。執行狀態顯示 completed，只表示這次執行完成，不代表內容正確或業務流程已通過。
結語：先讓它完成一個可驗收的任務
Hermes Agent 的吸引力在於它把模型、工具、記憶、程序、隔離和排程放到同一個工作台裡。代價也在同一個地方。你需要花時間管理 Profile、工作目錄、MCP 暴露範圍、秘密、approval policy 和 Cron 的失敗處理。
我會建議從一個小任務開始：建立獨立 Profile，只開必要工具，使用可丟棄的資料副本，要求它先回報範圍，再人工核對結果。流程重複成功後，才把規則整理成 Skill；需要固定時間執行時，再建立 paused Cron。這樣你測到的是一個可以逐步變可靠的工作流程，不是一段剛好成功的示範。
如果你想先整理 Agent 的上位架構，可以讀AI Agent Harness 文章。想理解外部工具連線，再看MCP 解析。若你的目標是把工具放進固定的日常流程，則可以回到工作自動化的判斷框架。先把任務、權限和驗收寫清楚，工具選擇通常會簡單一點。
來源與查證日期
本文查證截至 2026-09-15（Asia/Taipei）。下列是支撐功能、安裝、設定和安全說明的 Hermes Agent 官方或第一手文件：
- Hermes Agent 官方文件首頁：產品定位、安裝入口、工具、Memory、Skills、MCP 與 Cron 的總覽。
- Hermes Agent 平台支援：Tier 1、Tier 2 與 unsupported 平台和安裝方法。
- Hermes Agent 快速入門：安裝後的設定、診斷與安全起點。
- Hermes Agent 設定：模型、終端機 backend、工作目錄和隔離設定。
- Tools & Toolsets：內建工具類別、toolsets 與 Tool Gateway 條件。
- Persistent Memory：
MEMORY.md、USER.md、字元上限和跨 Session 載入方式。 - Skills System：Skills 的用途、載入方式和
skill_manage。 - Profiles：獨立 Profile、設定、記憶、Sessions、Skills 與 Cron 的隔離方式。
- Use MCP with Hermes：MCP 適用與不適用的情境、最小 Server 示例和工具暴露控制。
- MCP Config Reference：MCP Server 設定欄位和授權相關參考。
- Scheduled Tasks（Cron）：排程、gateway、獨立 Session、執行狀態與 script-only jobs。
- Security：approval、檔案寫入安全、容器、MCP 憑證過濾、授權與部署檢查。
文章中的「本文建議」是依上述官方功能和風險特性提出的工作方法；社群討論只用於選題時觀察讀者問題，不作為本文的功能、價格、性能或安全保證。尚未取得你的 Hermes 版本、帳號方案、provider、Profile、MCP Server、工作目錄和實際執行 readback，因此這些項目仍屬 unknown。