開源在地派：Nous Research 的 Hermes Bot Mode，把單一 Agent 變成一支能互相協作的持久團隊

AI 同事浪潮：為什麼 2026 年大家都在給 Agent 一台自己的電腦

2026 年 8 月，AI Agent 領域在短短三週內接連爆紅三件大事。8 月 11 日，xAI 推出 Grok Bot；8 月 17 日，Nous Research 的 Hermes Bot Mode 正式內建進 Hermes Desktop，同一天，CopilotKit 也開源了 OpenBot。三家廠商，三個看似不同的產品，但把時間軸攤開來看，你會發現它們指向同一個方向：給 AI Agent 一台自己的電腦，讓它像同事一樣，而不是像工具一樣。

這不是巧合，也不是行銷話術的跟風。這波浪潮背後有兩個非常具體的現象，一個關於網路的真實樣貌，一個關於工作完成的真實定義。理解這兩個現象，你就理解了為什麼 2026 年大家都在給 Agent 一台電腦。

現象一：大量網路服務，沒有 API 可以呼叫

過去幾年，我們習慣用 API 串接 AI 與各種服務。OpenAI 的函式呼叫、各家廠商的 MCP（Model Context Protocol），讓 AI 可以精準地讀取資料、觸發動作。聽起來很完美，但這套模式只覆蓋了網路的一小部分。許多企業服務仍然沒有可直接使用的 API，你的客戶關係管理系統、採購平台、內部表單，常常還是需要登入、點擊與拖曳才能完成工作。這也是瀏覽器操作重新受到重視的原因。

當 API 不存在，AI 要怎麼接觸真實世界？答案只有一個：讓它像人一樣，直接用瀏覽器操作。Grok Bot 的雲端虛擬機、OpenBot 的隔離 Chromium、Hermes Bot Mode 的 profile 機制，本質上都是在做同一件事：給 AI 一雙眼睛、一雙手，讓它去操作那些沒有 API 的系統。純瀏覽器操控不是退化的選擇，而是觸及真實世界的唯一路徑。

現象二：「90% 完成」跟「100% 完成」，中間是巨大落差

傳統的 chatbot 或 workflow automation，常常停在「生成內容」或「呼叫函式」就算完成。意思是，AI 幫你寫好了一封回覆客戶的信，信件躺在草稿夾，這算完成嗎？對 chatbot 來說可能算，對你的工作來說卻不算。你還是要自己打開郵件系統、貼上內容、檢查收件人、按下送出，再把狀態更新到 CRM。真正的差距不在回覆寫得多漂亮，而在工作有沒有回到原本的工具裡完成。

Grok Bot 的設計目標，就是讓工作「落回真實工具」才算完成。它直接登入你的 CRM，更新聯絡人紀錄，寄出郵件，然後在試算表裡標註狀態。整個流程結束時，你看到的是完成後的真實結果，而不是一份等待你接手處理的草稿。OpenBot 的 gateway 設計也一樣，它允許 Bot 操作真實工具，但每個動作都被記錄、被稽核。而 Hermes Bot Mode 的 Routines（排定的 cron 任務），讓 Bot 在排程時間內直接執行完整流程，而非產生一份建議報告。

把這兩個現象疊在一起，你會看到一幅完整的圖像：AI Agent 不再滿足於「對話」，它開始需要「空間」。這個空間裡有瀏覽器、有檔案、有登入狀態、有屬於自己的記憶。用一句話總結：Agent 需要一台自己的電腦，才能把工作做完。

三種解法，三種不同的答案

同樣是給 AI 一台電腦，三家廠商給出了三種不同的答案，而這正是這波浪潮最有趣的地方。

Grok Bot（xAI）是商業自助派。它把操作示範與瀏覽器工作環境結合，讓使用者把任務交給雲端 Bot 執行。這類產品的體驗通常比較直接，適合想快速驗證瀏覽器自動化的人；但使用者也要確認可使用的模型、資料位置、權限範圍與費用計算方式，不能只看展示流程是否順暢。

OpenBot（CopilotKit）是開源治理派。強調的不是 AI 多聰明，而是你敢不敢讓它靠近你的工具。它的核心設計是「任何動作都先經由單一 gateway，先審核、後記錄、再執行」，官方部落格寫得很直接：「這就是『一個能用你工具的 agent』與『一個你敢讓它靠近工具的 agent』之間的差別。」（CopilotKit 官方公告，2026 年 8 月 17 日）。每個 Bot 有自己隔離的容器、獨立的 Chromium 瀏覽器，自己的登入與 /workspace 檔案。它把「可稽核的自主」當作核心賣點，對話過程全部留下 audit log，任何動作都可事後追溯。

Hermes Bot Mode（Nous Research）是開源在地派。在三家之中，它是唯一把「AI 同事」這件事做出團隊感的產品。它把原本一次性、用完即消失的 sub-agent，升級成持久、具名、可跨 session 存續的 specialist。每個 Bot 有自己的角色、模型、記憶、技能與頭像，可以在群組房間裡互相 @mention、互相交付工作。它不提供雲端服務，完全靠你自己掌握，用哪個模型、放哪台機器、給什麼權限，全部由你決定。獨立實測者 madeyoga 在測試三個 Bot（內容、前端、後端）後評論：每個 Bot 有自己的身分與工具，不再是 workflow 裡看不見的呼叫（2026 年 8 月，madeyoga 的部落格實測）。

把三家的定位攤開來看，你會發現一個有趣的對應：Grok Bot 回答的是「怎麼讓 AI 最好用」，OpenBot 回答的是「怎麼讓 AI 最安全」，而 Hermes Bot Mode 回答的是「怎麼讓 AI 真正屬於你」。三個答案沒有誰對誰錯，它們對應的是不同的企業能力與心態。

其中，Hermes Bot Mode 的開源在地定位特別值得注意。它的 repo 在 8 月 17 日當天從獨立 plugin 內建進 Hermes Desktop，並且擁有 MIT 授權。對台灣企業來說，這代表你不必把企業資料送進別人的雲端，不必被單一廠商的模型綁架，可以完全自架在自己的機房或 VPC 裡。當然，代價是你需要一定的技術能力，光是設定多個 Bot 的模型、技能與 MCP 權限，就比訂閱一個雲端服務門檻高得多。但換來的是資料自主權與完全的掌控力。

三週內三家廠商同時推出「給 AI 一台電腦」的產品，這不是市場的一時衝動，而是整個 AI 產業對「Agent 該如何落地」這件事的一次集體回答。當大量網路服務沒有 API 可呼叫，瀏覽器操控就成為 AI 觸及真實世界的實用路徑；當「差不多完成」與「真正完成」之間的落差大到無法忽略，AI 必須擁有自己的工具與空間才能把工作做完。理解了這兩個現象，你就理解了這波浪潮的共同本質：AI 同事的時代，已經不是要不要來的問題，而是你準備好讓它靠近你的工具了嗎？

核心概念拆解：Bot IS a Hermes Profile，持久、具名、可跨 session 存續

上一章從產業視角看完整個「AI 有自己的電腦」浪潮，這一章我們把鏡頭拉到最小單位，拆解 Hermes Bot Mode 最重要的設計哲學。官方文件用一句話總結了整個 Bot Mode 的架構核心：A bot IS a Hermes profile。這句話乍看像是廢話，但它是理解 Bot Mode 的鑰匙。它說明了 Bot Mode 沒有新增任何程式語言層級的原語（primitive），沒有 core patch，沒有背景 daemon，也不多佔儲存空間。它做的是把 Hermes 早就擁有的 profile 概念，包上一層使用者介面，讓一支支 profile 變成一支支「具名、持久、可互相對話」的 Bot。

Bot 就是一個 profile，這句話拆開來看

在 Hermes 的架構裡，profile 本來就是用來區隔不同設定與記憶的單位。同一個 Hermes agent 可以有多個 profile，每個 profile 各自擁有獨立的模型設定、系統提示詞、技能清單與記憶空間。過去的運作方式是：你呼叫一個 profile，它執行完任務就結束，下一次要用再重新載入，用完即消失，profile 之間也不會互相通話。Bot Mode 的關鍵改變，就是把這個「用完即消失」的 profile，升級成一支「具名、持久、可跨 session 存續、可互相溝通」的 specialist。

也就是說，Bot Mode 沒有發明新東西，它只是把 Hermes 原有的 profile 變成「同事」。每個 Bot 有自己的名字、自己的頭像、自己的角色設定，你可以指定它用哪一個模型，甚至可以讓不同 Bot 使用不同的模型供應商。這個設計的意義在於：過去你切換 profile 是在「換工具」，現在你 @mention 一個 Bot 是在「找同事」。工具沒有名字、不會記得你上一句話；同事有名字、有專長、記得你們之前的合作內容。

每個 Bot 擁有什麼？就是一個完整 profile 該有的全部

因為 Bot 就是 profile，所以 profile 能承載的一切，Bot 都繼承了。具體來說，每個 Bot 可以獨立擁有以下四樣東西：

• 角色與模型：每個 Bot 可以設定自己的角色提示詞，並指定不同的模型或 provider。寫手 Bot 用擅長長文的模型，程式碼審查 Bot 用另一家更穩的模型，彼此不互相干擾。
• 記憶：每個 Bot 有自己獨立的記憶空間，跨 session 保留。你前天交代它的偏好，它下次運行還記得，不需要重新說明。
• 技能與 MCP：每個 Bot 掛載自己需要的技能與 MCP 伺服器。前端 Bot 只需要瀏覽器工具，後端 Bot 只需要資料庫連線，工具權限不會互相污染。
• Routines（等同 cron）：每個 Bot 可以設定自己的排程任務，命名格式是 [bot:名字] 任務名稱，會出現在 hermes cron list 裡。等於每個 Bot 有自己的行事曆，時間到了就自己開工。

這四樣東西，本來就是 profile 能承載的全部內容。Bot Mode 沒有多加任何一種新的能力類型，它做的是把這些能力「具名化、持久化、可溝通化」。這就是官方所說的「UI over primitive」的真正含義：底層原語沒有變，變的是人與 agent 互動的方式。

canonical forever Bot Chat：對話永不 fork 的設計

Bot Mode 另一個值得拆解的設計，是官方文件中的canonical forever Bot Chat。每個 Bot 都有一條「正典、永遠存在」的聊天串，這條聊天串的關鍵行為是：當使用者對 Bot 下達 /new 指令時，系統不會真的開一條全新的對話，而是把指令重新導向到 /compact。也就是說，對話會壓縮成精簡的摘要，但仍然是同一條 conversation，Bot 與使用者的關係沒有被切斷，不會產生分岔。

為什麼這個設計重要？傳統聊天機器人的 /new 是「拋棄過去、重新開始」，每次重開對話，機器人就失憶。但 Bot Mode 的 /new 被設計成「壓縮記憶、繼續前進」。這代表 Bot 與使用者的合作關係是連續的，Bot 記得你們之前討論過的專案脈絡、記得使用者的偏好，甚至記得其他 Bot 之前交代過的事。官方把這條永遠存在的聊天串稱作「canonical」，就是強調它是唯一正典，不會因為使用者手動開新對話而製造出多個互相矛盾的記憶分支。

對於多 Bot 協作的場景，這個設計格外重要。想像一個團隊裡有寫手 Bot、前端 Bot、後端 Bot，它們各自有 canonical 聊天串，當寫手 Bot 完成一份文件並移交給前端 Bot 時，前端 Bot 讀取的是寫手 Bot 那條完整且連續的記憶。如果每次交接都開新對話、重新累積，團隊合作就會變成一次次失憶後的重新自我介紹。Bot Mode 用一個「永不 fork」的設計，確保了協作的連續性。

Bot 之間的「對話」：其實是 CLI handoff

Bot 之間的互相溝通，也不是什麼神奇的平行宇宙傳訊。官方文件顯示，bot-to-bot 的訊息傳遞走的是真正的 CLI handoff，指令格式大致是：hermes -p 收訊Bot chat --in ~ -c "Bot Chat" -Q -q "訊息內容"。發訊的 Bot 會自動加上 attribution 前綴，標明這則訊息來自哪一支 Bot。換句話說，Bot 之間的互動就是 Hermes 命令列介面的組合，只是包上了一層「對話」的皮。

同時官方也設定了群組運作的硬性上限：一個群組房最多容納 2 到 6 支 Bot，一次 send 最多 10 則訊息，同一條訊息最多 3 輪 serial rounds。失敗重試最多一次，而且只在重試確實有幫助時才執行；涉及權限、配額或設定錯誤的失敗絕不會自動重試，並會回傳 12 種機器可讀的原因碼（官方 2026 年 8 月文件）。這些限制看起來保守，但正是這種保守，讓 Bot 群組不會陷入互相觸發的無限迴圈。

「只是介面改變而已」？批評與回應

Bot Mode 發表後，社群確實出現過質疑聲浪。Reddit 上的 r/hermesagent 討論區就有使用者直言：「Bot Mode 比較像介面的改變，Bot 之間的交流與交換很笨拙」「他們只是把前端加到 Hermes Desktop 然後叫它 bot mode」（2026 年 8 月貼文）。這樣的批評不是沒有道理，如果只看表象，Bot Mode 確實沒有推出新的模型、沒有新的 agent 框架，看起來就是包了一層 UI。

但把「UI over primitive」視為貶義，其實忽略了產品化的價值。Hermes 原本的 profile 機制雖然強大，卻只有熟悉命令列與設定的進階使用者能駕馭。Bot Mode 把 profile 變成具名的、可 @mention 的、有頭像的實體，讓一般使用者不必理解 profile 背後的設定細節，就能像訊息聊天一樣指揮多支 agent 分工。獨立實測者 madeyoga 在 2026 年 8 月的評測中指出，三支 Bot（內容、Nuxt UI、ASP.NET）各自有自己的身分、角色、工具與技能，agent 不再只是 workflow 裡看不見的函式呼叫。這正是「UI over primitive」的價值：把開發者才懂的原語，變成一般使用者也能直覺操作的產品。

當然，Bot Mode 也有明確的技術限制。bot-to-bot 的訊息投遞是 per-invocation，收訊的 Bot 要等到下一次被喚醒才會看到訊息，無法中斷正在進行中的對話。官方文件也坦承，Bot 相互即時中斷（live interrupt）是未來的功能方向。也就是說，目前 Bot 之間的協作比較像「留言板」而非「即時通訊」，這在需要緊密互動的任務中會卡卡的。

回到章節標題的三個關鍵詞：持久、具名、可跨 session 存續。這三個詞總結了 Bot Mode 對 Hermes profile 的升級。持久，代表 Bot 的記憶不會因為對話結束而消失；具名，代表每支 Bot 有明確的身分與專長，可以被 @mention、被指派任務；可跨 session 存續，代表 Bot 的狀態與記憶在多次運行之間連續累積，加上永不 fork 的 canonical 對話串，讓 Bot 真正成為團隊成員，而不是用完即丟的臨時工具。理解了這層設計，你就掌握了 Hermes Bot Mode 的精髓：它沒有改變 Hermes 的能力邊界，它改變的是人與 agent 的關係。

實戰操作：十分鐘在 Hermes Desktop 建立你的第一支 Bot 團隊

理論說得再多，不如直接動手。這一段以獨立開發者 madeyoga 在 2026 年 8 月底公開的實測紀錄為藍本，帶著你從零開始，在 Hermes Desktop 裡建立一支三人的 Bot 團隊：負責內容寫作的 Blogi、負責 Nuxt UI 的前端專家 Nuxti、以及負責 ASP.NET 的後端工程師 Aspi。三個 Bot 各自擁有身分、角色、模型與技能組合，還會透過 CLI 互相傳遞訊息，就像真正的團隊成員在工作群組裡交辦事項。

整個操作過程不需要修改 Hermes 核心，不用背景常駐程式，也不佔用額外儲存空間。官方文件開宗明義指出，Bot Mode 是疊加在現有 profile 機制之上的介面，一支 Bot 就是一個 Hermes profile，只是它被賦予了名字、頭像、專長與排程能力。當你建立完第一支 Bot，往後的第二支、第三支只是複製貼上再微調的功夫，十分鐘建立一個團隊確實辦得到。

第一步：建立 Bot 的 profile

在 Hermes Desktop 中，建立 Bot 等同於建立一個全新的 profile。打開設定面板，找到 profile 管理區塊，按下新增，輸入 Bot 的名字。以 madeyoga 的實測為例，Blogi 的設定檔明確標註它的職責是內容產出，偏好使用具備長篇寫作能力的模型，並且掛上文章生成相關的 skills。Nuxti 則是前端專家，模型選擇針對 JavaScript 框架調校過的版本，掛上 Nuxt UI 的元件庫技能。Aspi 負責 ASP.NET，設定檔裡載入的是 .NET 生態系的工具鏈。

每一個 profile 都是獨立儲存，Bot 之間的技能與 MCP 伺服器不會互相污染。寫手 Bot 不需要看到程式碼編譯的工具，後端 Bot 也不需要載入 SEO 分析的外掛。這種領域切割正是 Bot Mode 相較於單一 agent 的最大優勢，每個 Bot 只專注在自己的職責範圍，不會把無關的 context 灌進對話窗。

第二步：指派模型與技能

建立完 profile，接著要指派模型與技能。每個 Bot 可以用不同的模型供應商，也可以各自掛載不同的 MCP 伺服器。你在 profile 設定頁裡選擇要用的模型，例如 Blogi 用擅長自然語言生成的模型，Nuxti 用程式碼能力較強的模型，Aspi 則用支援 C# 語法的最佳化模型。同一支 Bot 團隊裡混用多個模型供應商完全沒問題，這正是 Bot Mode 的設計初衷。

技能設定同樣在 profile 頁面完成。每一個 Bot 可以載入自己的 skills 集合，當 Bot 被 @mention 或被排程喚醒時，它會自動套用這些技能來處理任務。實測紀錄提到，capability lists 會隨著使用逐漸偏離實際狀態，意思是技能的描述與實際行為之間可能產生落差，建議每隔一段時間回去檢視並更新設定。基礎架構請見 Hermes-Bot-Mode 原始碼，裡面記錄了完整的設定範例。

第三步：設定 Routines 排程

Routines 是 Hermes 內建的 cron 排程機制，Bot Mode 讓每個 Bot 都能掛上自己的例行任務。命名規則是在 routine 名稱前加上 [bot:名字] 的前綴，例如 [bot:blogi] 每日晨間產業新聞摘要。設定完成後，這些排程會出現在 hermes cron list 指令的輸出中，你可以統一檢視所有 Bot 的排程狀況，確認每個時段的任務分配是否合理。

排程的用途很廣，內容 Bot 可以每天早上自動產出一則新聞摘要，前端 Bot 可以在程式碼合併後自動跑一次 UI 迴歸檢查，後端 Bot 可以定時檢查 .NET 套件的安全性更新。每個 Bot 的排程彼此獨立，不會互相干擾。你甚至可以讓兩支 Bot 的排程錯開，例如 Blogi 在上午八點產出稿件，接著 Nuxti 在上午九點接手排版檢查，形成一條自動化的接力流程。

第四步：讓 Bot 之間透過 CLI 真傳訊息

Bot 與 Bot 之間的通訊不是透過抽象的內部 API，而是真實的 CLI handoff。官方文件記載的指令格式如下：hermes -p <bot> chat --in ~ -c "Bot Chat" -Q -q "訊息內容..."。以 -p 指定收訊的 Bot，-c 指定對話串名稱，-q 帶入要傳遞的訊息。系統會自動在訊息前方加上 attribution 前綴，標明這則訊息來自哪一支 Bot，所以收訊的一方永遠知道訊息來源。

實際操作時，Blogi 可以把整理好的文章大綱以這種方式丟給 Nuxti，請它確認 UI 元件是否齊全，再轉交給 Aspi 評估後端 API 的對應方式。每一則訊息都會被記錄在該 Bot 的長期對話串中，不會因為 session 結束而消失。

有一個重要的限制要先講清楚：投遞是 per-invocation，不是即時中斷。如果 Nuxti 正在進行中的對話還沒結束，Blogi 傳過來的訊息會先排隊，等 Nuxti 下一次運行時才看得到。獨立實測者 madeyoga 在文章裡明確寫道，如果 Nuxti 正在處理任務，Blogi 的訊息就只能等待。這代表你必須把工作流程設計成批次導向，而不是即時交談導向。

第五步：認識群組房的硬上限

當你把多支 Bot 放進同一個群組房協作，有三條硬上限必須記住：

• 群組容量：一個群組房容納 2 到 6 支 Bot，太少無法形成協作，太多會撐爆共享的 context。
• 序列回覆：每一則訊息最多觸發 3 輪序列回覆（serial rounds），超過之後 Bot 之間不會再自動接力。
• 發送上限：一次 send 最多攜帶 10 則訊息。

失敗重試機制同樣有嚴格限制：最多只重試一次，而且只有在重試確實有幫助的情況下才會觸發。驗證失敗、額度不足、設定錯誤這三類問題永遠不會自動重試。系統會回傳 12 種 machine-readable 的原因碼，涵蓋授權、配額、設定等各類失敗情境，讓外部管線可以準確判斷失敗原因並決定下一步動作，而不是盲目重跑。這套設計對想要寫自動化腳本串接 Bot 團隊的開發者特別重要，你可以在程式裡針對不同原因碼設計不同的應對策略，例如驗證失敗時通知管理員更新憑證，額度不足時切換到備援模型。

實際操作過一次你就會發現，Bot Mode 的協作更像人類團隊的非同步溝通，而不是程式的同步函式呼叫。你在這個團隊裡扮演的其實是調度者的角色，負責安排誰在哪個時間點該做什麼事，讓每支 Bot 各自在自己的 context 裡專心完成任務。這正是 madeyoga 在實測文末的結論：handoffs 不是一條自動化的 pipeline，人仍然是 scheduler。把這個心態建立起來，你才不會對 Bot 團隊抱持不切實際的期待，也才能把這套機制真正用好。社群對這個設計的討論也相當熱烈，Reddit 上的實測心得提供了不少實務上的微調建議，值得在動手之前先瀏覽一遍。

深入探討：bot-to-bot 通訊是怎麼運作的？Per-invocation 投遞的極限

前一篇我們建立了基本認知：Bot Mode 的協作不是自動化的 workflow pipeline，人仍是 scheduler。這個章節我們把引擎蓋掀開，看 bot-to-bot 通訊在 CLI 層面實際長什麼樣子，以及「per-invocation 投遞」到底限制了什麼。

bot-to-bot 的底層：一次 CLI handoff

先從官方文件看起。Hermes Bot Mode 的 bot 之間的訊息傳遞，本質上不是什麼新的網路協定，而是包裝好的指令列呼叫。根據 Hermes 官方文件（2026 年 8 月），當 Bot A 要送訊息給 Bot B 時，系統實際執行的是類似這樣的一條指令：

hermes -p <bot> chat --in ~ -c "Bot Chat" -Q -q "Message..."

這個指令的結構透露了很多資訊。`-p` 指定收訊的 profile，`–in` 指向輸入目錄，`-c` 指定 conversation ID，`-Q -q` 代表靜默模式下的查詢。系統會自動加上 attribution 前綴，讓收訊端知道這則訊息來自哪個 Bot。換句話說，Bot 之間的「對話」，底層就是一次次的指令列呼叫，每一次呼叫都是一次全新的 process。

Per-invocation 投遞：看不到即時訊息，只有下次醒來才讀得到

這就帶出最重要的限制：投遞是 per-invocation 的。意思是，收訊 Bot 不會像通訊軟體一樣，在訊息送達的瞬間跳出來打斷你。它只有在「下一次被喚醒」時，才會去讀取輸入目錄裡的訊息。如果 Bot B 正在處理一個耗時的工作，Bot A 此刻送過來的訊息會安靜地排隊等待，不會插隊、不會中斷 Bot B 的執行緒。官方文件甚至直接寫明，「live interrupt of a mid-conversation bot is future work」，也就是說，即時打斷進行中的 Bot 對話，目前還在未來工作清單上，尚未實作。

這個設計的優缺點都很明顯。優點是執行緒的單純性，每個 Bot 都專注在自己的任務上，不會被隨機插播干擾，狀態管理也因此變得可預測。缺點是協作的即時性大打折扣。如果你想像的是兩個 Bot 像真人同事一樣即時討論、互相插話、動態調整策略，那 Bot Mode 目前辦不到。

獨立實測的交叉驗證

官方文件的描述是一回事，實際跑起來是不是這樣？獨立開發者 madeyoga 在 個人部落格（2026 年 8 月）發布了三 Bot 協作的實測記錄，他建立了 Blogi（內容）、Nuxti（Nuxt UI）、Aspi（ASP.NET）三個各司其職的 Bot，結果印證了官方說法：

「Delivery is per-invocation. If Nuxti is mid-turn， Blogi’s message waits.」

當 Nuxti 正在處理 UI 任務時，Blogi 送來的訊息確實就在佇列裡等待。這個實測也帶來了一些正面的觀察，例如每個 Bot 有自己的 identity、角色、工具與技能，不再是 workflow 裡看不見的無名呼叫。但同篇文章也坦承，Bot 之間的 handoff 不是 pipeline，實際的調度者仍然是測試者本人。另外，能力清單（capability lists）會隨著 Bot 的 skills 變動而漂移，需要人為維護。

對照 Claude Code：ephemeral subagent 與持久 Bot 的根本差異

如果把 Bot Mode 放回 agent 協作的光譜上，最直接的對照組是 Anthropic 的 Claude Code。Claude Code 有 subagent 機制，但它的 subagent 是短期、一次性、用完即消失的子任務。你在主 agent 的脈絡裡呼叫一個 subagent，它執行完回傳結果，就結束了。它沒有自己的名字、沒有跨 session 的記憶、不能在其他對話中被重新喚醒，也不能主動發訊息給你。它就像是主 agent 程式裡的一個 function call，只是這個 function 由另一個 LLM 執行。

Bot Mode 的 Bot 則是完全不同的存在。它有自己的角色設定、自己的模型供應商、自己的 skills 與 MCP 工具、自己的 cron 例行任務。它有一個「canonical forever Bot Chat」，即使你下了 `/new`，系統也會把她 reroute 到 `/compact`，用新的 context 繼續同一個對話，永遠不 fork 關係。也就是說，Bot 是持久的、具名的、狀態跨 session 存續的 specialist，不是用完即丟的工具。

對照 OpenClaw：控制平面與市場機制的差距

在光譜的更遠端，有 OpenClaw 這樣更成熟的 control plane。根據 Composio 的比較分析（2026 年），OpenClaw 提供的不只是 Bot 之間的訊息傳遞，還包含完整的控制平面、agent 註冊、任務調度、以及 ClawHub 這個 marketplace，讓 agent 可以像 app 一樣被發現、安裝、管理。OpenClaw 的設計假設是「agent 是基礎建設」，而 Hermes Bot Mode 的設計假設是「Bot 是 profile 的延伸」。前者把 agent 當作獨立運行的服務，後者把 agent 當作 Hermes 這個應用程式裡的角色。

這個差異直接反映在運作模型上。OpenClaw 的 agent 可以常駐、可以透過 control plane 被外部觸發、可以做為服務被其他 agent 呼叫。Hermes 的 Bot 則活在 Hermes 這個 process 的 lifecycle 裡，沒有背景 daemon、沒有常駐服務。它的存在與執行，都依附在 Hermes 的啟動與呼叫之上。

光譜上的定位：從呼叫到同事的過渡帶

把三個方案攤開來看：Claude Code 的 subagent 是「純呼叫」，呼叫完就消失；Hermes Bot Mode 是「具名呼叫」，Bot 之間可以互相留訊息，但投遞靠下次喚醒；OpenClaw 是「服務導向」，agent 是常駐的基礎建設。Hermes 正好卡在中間，它把無名的呼叫升級成具名的、持久的 specialist，但還沒走到即時互動、常駐服務的那一端。

這個位置其實很務實。它不需要背景 daemon、不需要額外的基礎建設、不需要常駐 VM，就達成了「Bot 有 identity、有記憶、可以互相指派工作」這個目標。代價就是投遞的非即時性，以及人仍然是 scheduler 這個事實。如果你的協作需求是「A 寫完草稿，B 下次醒來時接手修改」，per-invocation 完全夠用。如果你的需求是「A 和 B 要即時討論一個設計問題」，那需要的是群組聊天室，不是 Bot Mode。

給台灣企業讀者的小結

把這個技術細節拉回台灣企業的導入場景。當你在評估是否要採用 Bot Mode 時，團隊內部常見的想像圖像，是兩個 AI 像真人同事一樣在 Slack 上即時鬥嘴討論。實際上的圖像是：Bot A 完成任務後，把訊息寫進佇列，Bot B 在下次被排程喚醒時讀取並接手。這個落差如果沒有先建立，導入後很容易產生「這 AI 怎麼這麼笨、不會即時回應」的負面印象。理解了 per-invocation 的底層邏輯，你才能設計出符合這個限制的工作流程，例如把任務切成可以非同步接力的小單元，而不是期待即時的雙向討論。理解工具的真實紋理，永遠是導入成功的第一步。

真實反饋：Reddit 與 madeyoga 的實測，真的能當團隊嗎，還是只是包了一層前端？

Bot Mode 推出後，社群的反應呈現兩極。有人認為這只是把 Hermes Desktop 的前端重新包裝，也有人實際跑了一輪後，認為這是 agent 協作模式的重大突破。兩邊看的都是同一套程式碼，為什麼感受落差如此之大？這篇文章整理 Reddit 上的負面意見，與 madeyoga 的獨立實測正面結果，把 hype 之外的實際樣貌攤開來檢視。

Reddit 的冷水：介面改版還是真團隊？

在 Reddit 的 r/hermesagent 板，新功能發布後不久就出現質疑聲浪。有用戶直言「Bot Mode is more of a change in interface， and exchange between bots/profiles is clunky at best」，更有人不留情面地說「They’ve just added the front end to Hermes Desktop and called it bot mode」（r/hermesagent，2026）。這些批評的核心，是認為 bot 之間的通訊從底層來看仍是 CLI handoff，UI 上多了一些頭像和名稱，不代表真的產生了「團隊感」。

官方的文件也間接承認了這項限制。在 Bot Mode 的開發藍圖中，「live interrupt of a mid-conversation bot」被標記為 future work（Hermes Bot Mode 官方文件，2026）。意思是當一個 bot 正在執行任務、處於對話中途時，另一個 bot 傳來的訊息並不會打斷它。投遞機制是 per-invocation，收訊的那一方要等到下一次被喚醒，才會讀到訊息。如果你的想像是一群 AI 在線上即時討論、互相插話、當下回應，那這個版本會讓你失望。

更現實的規格限制也擺在眼前。一個群組最多只能容納 2 到 6 個 bot，一條訊息最多跑 3 輪 serial rounds，每次 send 最多帶 10 則訊息。失敗時最多重試一次，而且只有在重試確實有幫助時才會重試；遇到認證、額度或設定錯誤則完全不會自動重試，而是回傳 12 種 machine-readable 的原因碼（Hermes Bot Mode 官方文件，2026）。這些限制讓「團隊」二字聽起來更像「排程佇列」，而不是你心裡想像的那種即時協作。

madeyoga 的獨立實測：三隻 Bot 的真實協作

如果只看 Reddit，你會以為 Bot Mode 只是換皮。但 madeyoga 的獨立實測提供了另一種視角。他用三個 bot 組成一支小型團隊：Blogi 負責內容、Nuxti 負責 Nuxt UI、Aspi 負責 ASP.NET 後端，然後讓它們各自帶著不同的技能與工具協作。結論是「agents aren’t just invisible calls in a workflow. Each bot has its own identity， role， tools， skills」（madeyoga，2026）。

這句話的關鍵在於「invisible calls」。在傳統的 sub-agent 架構裡，主 agent 呼叫子任務時，子任務用完即丟、彼此不認識。但 Bot Mode 讓每個 bot 擁有持久的身份、各自的記憶與技能，而且可以跨 session 存續。以 madeyoga 的案例來說，Blogi 寫好的內容可以直接交給 Nuxti 去套版，Nuxti 需要後端資料時再找 Aspi，三者的技能與 MCP 設定互相隔離，不會污染彼此的 context。他認為這對 domain 切割的價值，是 Reddit 批評者沒有深入體驗到的部分。

也因為每個 bot 都有獨立的 profile，你可以在同一個專案裡同時使用不同的模型與 provider。寫作用的模型、寫程式用的模型、設計 API 用的模型，可以各自獨立，不必為了遷就單一 agent 而屈就。這種彈性在實際導入時，比「看起來像聊天室」的介面更值得重視。對開發者而言，Bot Mode 的核心意義不是多了幾個頭像，而是把過去藏在 workflow 裡、用完即丟的 sub-agent，升級成有名字、有記憶、可長期追蹤的專責成員。

藏在讚美裡的痛點：調度與能力漂移

但 madeyoga 的讚美並非毫無保留。他坦承「Handoffs are not a pipeline… I am the scheduler」（madeyoga，2026）。意思是 bot 之間的工作交接，不是一條自動化流水線，你必須親自扮演調度者的角色，決定什麼時候讓哪個 bot 接手。再加上投遞機制是 per-invocation，你等於要手動安排「哪個 bot 在什麼時候醒過來讀訊息」。所謂的團隊協作，實際上是你在背後拉線，只是拉線的頻率比你想像中高得多。

另一個痛點是「Capability lists drift」。當每個 bot 各自擁有越來越多的技能與工具，你很難維持一份精確的「誰會做什麼」清單。一開始三個 bot 的分工很明確，幾個月後技能列表膨脹，你反而搞不清楚哪個 bot 可以做哪件事。這個問題在人類團隊裡也存在，但在 AI 團隊裡更容易發生，因為技能的增減往往沒有經過正式會議，而是某次任務中順手加上去的。等到你發現兩個 bot 重複做同一件事，往往已經浪費了可觀的 token。

把這兩個痛點與 per-invocation 的投遞機制擺在一起看，Bot Mode 的真實樣貌就清楚了。它不是一個讓你「丟著不管」的自動化平台，而是一個讓你更清晰切割工作領域的框架。你把任務拆成小單元，指定專責的 bot，然後在恰當的時機手動觸發下一棒。它提供了持久、具名、可跨 session 存續的 specialist，但調度權沒有交給任何自動化機制。這不是缺陷，而是一種設計取捨，只是你需要用正確的方式駕馭它。

回到最初的問題：真的能當團隊嗎？答案是，看你把「團隊」定義成什麼。如果你期待的是像真人同事一樣即時回應、互相插話、主動承接工作的團隊，Bot Mode 現在還做不到。但如果你需要的是把不同領域的任務交給不同專長的 agent，讓它們各自保有記憶與技能、非同步接力完成工作，那 Bot Mode 已經提供了扎實的基礎。重點不在於它是不是「只是包了一層前端」，而在於你能不能根據 per-invocation 的限制，設計出適合自己團隊的工作流程。

替代方案有限公司觀點：開源在地派的台灣落地建議

如果說 Grok Bot 回答的是「怎麼最省事」，OpenBot 回答的是「怎麼最安心」，那 Hermes Bot Mode 回答的其實是另一個更根本的問題：「這支 agent 團隊，到底算誰的？」開源、MIT 授權、可自架、模型可換、profile 完全隔離，這條路線的答案非常乾脆，軟體是我們的，資料是我們的，模型可以是我們的，連 agent 之間的默契也是我們自己定義的。這正是我們所說的「開源在地派」，也是台灣中小企業在導入 AI 同事時，最少被綁架、最多保留選擇權的一條路。

但我們必須先講清楚，這條路不適合所有人。Hermes Bot Mode 的門檻不在功能，而在技術能力。它沒有 Grok Bot 那種「示範一次就學會」的華麗介面，也不像 OpenBot 那樣把治理規則寫成 policy 就能自動審核。它給你的是一組 CLI 指令、一群 profile、以及一套 cron 語法，你必須自己把這些零件組裝成 workflow。對沒有 IT 人員、沒有 self-host 經驗的公司來說，這不是「導入」而是「專案開發」。

台灣許多中小企業的 IT 人力有限，甚至需要委外處理日常維護。要團隊自己架設 Hermes、管理多個 Bot 的模型憑證、設計 Routines 的觸發條件，現實上並不輕鬆。我們在輔導客戶的過程中，最常聽到的反應不是「這東西不實用」，而是「我知道它很強，但我們真的不知道從哪裡開始」。

那麼，什麼樣的公司適合 Hermes Bot Mode？我們的判斷標準很簡單，你公司的數位工具是否已經高度雲端化，以及你有沒有一位願意花時間研究 CLI 的員工。如果答案是肯定的，Hermes 的多模型自由度就值得納入評估。你可以讓負責寫稿的 Bot 使用一種模型、讓處理資料的 Bot 使用另一種模型，讓需要低延遲的 Bot 使用本地模型，每個 profile 各自獨立，互不干擾。真正要比較的不是宣稱哪個方案一定最好，而是實際測試你的繁體中文內容、資料格式與工作速度是否符合需求。

我們的具體建議是，不要一開始就建一支五人 bot 團隊。先挑一條線，最好是一條重複性高、容錯度也高的流程。例如收件匣整理，讓一個 bot 每天固定時間登入信箱，把發票、報價單、客戶詢問分類歸檔，遇到不確定的信件就標記為待確認，不擅自回覆。或是發票處理，讓 bot 讀取 PDF 發票、擷取統編與金額、寫入試算表。這兩類工作有個共同點，出錯的後果可控，而且執行成果很容易驗證。跑兩週之後，你自然會知道「什麼該交、什麼該留人」的界線在哪裡。

關於成本，我們必須誠實提醒，always-on 的 agent 會快速累積 token 用量。公開社群討論中，也有人分享長時間讓 Bot 執行任務後，模型用量大幅增加；這類個人經驗不能直接當成每家公司預算，卻提醒你不要只看單次展示的費用。Hermes Bot Mode 雖然可以搭配本地模型，但如果使用的是 API 模型，Routines 的執行頻率、每次帶入的對話脈絡與工具回應，都會影響月底帳單。所以在導入前，先算清楚三件事：這個流程每天執行幾次、每次大概會消耗多少 token、模型 API 的報價是多少。算完之後再決定這個 workflow 是否適合讓 Bot 接手，而不是讓帳單先嚇退老闆。

我們也必須指出 Hermes 現階段的明顯限制。bot-to-bot 的訊息傳遞是 per-invocation，收訊 bot 下一次運行才會看到訊息，無法中斷進行中的對話。官方文件也承認，對進行中 bot 的即時插話是未來工作。代表你自己必須扮演調度者的角色，這跟 Grok Bot 那種「交出去就不用管」的體驗差很多。另外，最大的社群批評是它只是把前端包一層、把 profile 之間的 exchange 做得有點笨重，這個批評有一定道理，因為它的底層確實沒有新增任何原語。但我們的看法是，介面包裝的價值不在技術含量，而在它能把原本隱形的機構呼叫變成看得見、叫得出名字、可以跨 session 追蹤的團隊成員，這對企業導入的溝通成本來說，是實質的幫助。

我們認為台灣中小企業導入 Hermes Bot Mode 的實際路徑，是先找一家懂 agent 協作、也懂 self-host 的顧問團隊做一次單線小步驗證，花兩到四週跑完收件匣或發票流程，把耗能與準確率的數據攤開來，再決定要不要擴編。這不是因為 Hermes 不夠好，而是因為它的自由度高，對技術能力足夠的團隊來說，長期最划算、最不會被綁定。但自由是要付出學習成本的，台灣企業的優勢在於靈活與務實，只要先算清楚成本、先驗證一條線，開源在地派絕對值得認真考慮。

我們公司自己就是這樣走過來的。我們寧可多花兩週建立流程，也不願意被閉源平台的更新節奏綁架。Hermes Bot Mode 給我們的，不只是軟體主導權，還有一個可以慢慢打磨、愈用愈貼近自己工作習慣的 agent 團隊。這個選擇或許不適合所有人，但對願意花時間理解它的人來說，它會是那個「你自己掌握」的答案。

結論：從單一 Agent 到一支能互相協作的持久團隊

2026 年 8 月，短短三週內，Hermes Bot Mode、Grok Bot、OpenBot 接連問世，乍看是三款不同產品，本質上卻是同一波浪潮的產物：給 AI Agent 一台自己的電腦，讓它二十四小時自主工作。而 Hermes Bot Mode 在這一波浪潮中，選擇走一條更遠的路，它不只給 Agent 一台電腦，更把單一 Agent 變成一支具名、持久、能互相對話的 specialist 團隊。

回顧前幾篇的討論，三個方案其實代表了三種不同的信任模型。Grok Bot 是商業自助派，像帶新人一樣，示範一次 workflow 就交給它，代價是閉源綁定，所有 Bot 共用同一台帳號級雲端電腦，官方文件也明確提醒，不要把單一 Bot 當作安全邊界。OpenBot 是開源治理派，用一道唯一 gateway 先審核後記錄，把「autonomy」轉變成「auditable autonomy」，讓企業敢讓 Agent 靠近工具。而 Hermes Bot Mode 則是開源在地派，把 agent 團隊的完整主導權交給使用者，你的團隊、你的模型、你的資料，全部自己掌握。

這三者之間沒有絕對的優劣，只有適不適合。Hermes 特別的地方在於，它回答了台灣開源社群與技術團隊最在乎的問題：當別人都把 Agent 關在雲端裡，你有沒有能力、有沒有意願，自己掌握整支 agent 團隊？

從用完即消失到持久具名，為什麼這是關鍵躍遷

過去的 sub-agent 是一次性的，呼叫完就消失，彼此之間不互通，像是 workflow 裡看不見的臨時工。Hermes Bot Mode 把這個底層原語升級了，每個 Bot 都是一個 Hermes profile，有自己的角色、模型、記憶、技能與頭像，而且可以跨 session 存續。這不是單純的介面包裝，而是從「工具」到「同事」的範式轉移。

當一個 Bot 具名且持久，它就能累積 domain knowledge。寫手 Bot 不需要每次重新學習你的品牌語氣，前端 Bot 不用重新理解你的 component library，後端 Bot 的 MCP 設定不會被其他任務污染。這個 domain 切割的價值在實務上非常巨大，過去一個 Agent 要做所有事，context window 一下就滿了，模型混亂、工具互相干擾。現在每個 specialist 只負責自己的領域，各配有專屬 skills 與 MCP，品質自然提升。

而 bot-to-bot 的互相 @mention 更開啟了協作的可能。2 到 6 個 Bot 在群組房裡接力，每個 Bot 有自己的專長，寫手 Bot 產出內容草稿，前端 Bot 接手套版，後端 Bot 串接 API。過去這些工作要嘛由人類當搬運工，把結果從一個工具貼到另一個工具，要嘛靠脆弱的 API 串接，現在 agent 之間能直接傳訊息，而且 attribution 前綴讓追蹤變得透明。

誠實面對代價：投遞非即時，人仍是調度者

不過這套設計有其代價。bot-to-bot 的訊息投遞是 per-invocation，收訊的 Bot 要等下一次運行才看得到訊息，無法打斷進行中的對話。官方文件自己也承認，即時中斷 mid-conversation 是未來工作。獨立的實測報告也驗證了這點，如果某個 Bot 正在處理任務，其他 Bot 傳來的訊息只能排隊等待。

換句話說，這套系統不是即時戰情室，而比較像非同步的團隊協作：每個人有自己的節奏，訊息到了自然會處理。這意味著，人類仍是真正的調度者。就像 madeyoga 在實測心得中提到的，「Handoffs are not a pipeline… I am the scheduler」。能力清單會漂移，Bot 的技能組合需要人類定期檢視調整。這不是缺陷，而是設計選擇，它把複雜的即時調度問題留給人，讓 Bot 專注在各自領域的深度工作。

對台灣企業來說，這個取捨其實是務實的。真正需要即時協作的場景，人間用 Slack 或 Teams 就能解決，Agent 的價值不在於快，而在於可靠與可預期。非同步投遞換來的是架構單純、錯誤可控，而且每一則訊息都有記錄，事後可以檢討優化。

你要關在雲端裡，還是自己掌握？

回到這篇文章最核心的問題：當各家廠商都把 Agent 關進自家的雲端機房，你有沒有能力與意願，自己掌握這整支 agent 團隊？

以雲端 Bot 為例，方案價格與使用規則可能隨產品調整而改變，企業不能只用一次展示的費用推估長期支出。對企業來說，更實際的問題是資料能不能帶走、流程能不能替換、模型能不能更換，以及費用是否能按工作量追蹤。你的流程與資料一旦深度綁定，就應該在導入前保留匯出方式與替代方案。

開源方案也不是完全沒有成本，而是把成本結構放在不同位置。以 Hermes 為例，Bot Mode 的 GitHub 專案頁截至 2026 年 9 月 1 日我們查看的頁面，顯示 658 顆星與 117 個 fork；頁面同時標示外掛已封存，並說明 Bot Mode 已經內建到 Hermes Desktop。MIT 授權讓團隊可以依授權條件修改、部署與商用，但實際支出仍包括模型用量、機器、維護與設定時間。這些項目要分開估算，不能只看到「開源」就當成零成本。

成本結構可以拆成幾個部分：自架的主要投入在 IT 人力、機器與前期建置，模型若走 API 則另有用量費用。每多一個 Bot，除了 profile 設定，也可能增加對話、工具與排程的執行量，所以不能只用 Bot 數量推估成本。對有技術能力的團隊來說，自架可能換來較多配置空間；是否划算，仍要用實際工作量與維護時間試算。

台灣企業落地建議：先小步驗證，再逐步擴編

我們給台灣企業的建議，仍然是那句老話：先小步驗證，不要一開始就全公司鋪開。挑一兩個重複性高、容錯度也高的流程，例如收件匣整理、發票處理、例行報表產出，單線跑一個 Bot，驗證「什麼該交給 Bot、什麼該留給人」之後，再考慮擴編成團隊。

同時要務實評估內部能力的門檻。Hermes 的彈性來自於它的自由度，自由度就意味著學習成本。團隊裡至少要有人熟悉 command line、理解 MCP 與 skill 的設定，也願意花時間觀察 Bot 的運行狀況、調整能力清單。台灣多數中小企業沒有專職的 AI 工程師，導入前尋找熟悉 agent 與 self-host 的顧問協助，其實是合理的投資。

一個警示，always-on agent 會讓 token 用量隨執行頻率與對話脈絡快速累積。導入前一定要先估算每天執行幾次、每次帶入多少資料、失敗重試會增加多少消耗，並設定用量上限與人工檢查點。我們始終認為，AI 導入的成敗，往往不在於技術多先進，而在於成本與效益有沒有算清楚。

替代方案有限公司的觀點

我們公司自己就是開源在地派的實踐者。過去半年，我們陸續把內部流程遷移到 Hermes 的生態系，從最早單純用 hermes-agent 跑排程任務，到現在有了三支具名的 specialist Bot 在協作。我們寧可多花兩週建立流程、寫清楚 skill 與 MCP 設定，也不願意被閉源平台的更新節奏綁架，更不願意把客戶資料放在我們無法掌控的雲端。

對台灣的中小企業，我們認為最務實的路徑是混合起步：先用商業方案驗證需求與 ROI，同時找專業團隊評估哪些流程適合移回自架。關鍵不是選陣營，而是先想清楚，你的 agent 團隊是要長期累積、愈用愈懂你，還是只是短期輔助、用完就丟。如果你期待的是前者，那 Hermes Bot Mode 提供的持久、具名、可互相協作的 specialist，會是那個「你自己掌握」的答案。這條路需要投入時間，但它回報的是長期的主導權與彈性，對台灣這片以靈活與務實著稱的土地來說，這個選擇值得認真考慮。

從功能清單到工作流程：導入前要先畫出責任邊界

官方文件把 Bot Mode 描述成既有 profile 的使用者介面，這個定義對企業導入很有幫助，因為它提醒你不要把 Bot 想成一個獨立部門。Bot 不會自動理解公司的權責，也不會因為換了名字就自動知道哪些事情可以直接完成。它承接的是你放進 profile 的角色、記憶、技能、工具與憑證，工作的品質取決於這些內容是否清楚。建立 Bot 以前，先把任務寫成一張簡單的責任表：誰提供資料、誰做判斷、誰執行動作、誰負責確認結果。這張表不需要技術背景，業務主管、行政人員與 IT 人員都看得懂，卻能避免把一個模糊的「幫我處理信件」直接丟給 Agent。

以收件匣整理為例，內容 Bot 可以讀取信件標題與附件名稱，將信件分成發票、報價、客戶問題與待人工確認四類；它可以在郵件系統中加上標籤，卻不應該自行承諾交期、修改報價或回覆爭議內容。當資料進入待人工確認區，流程就停在一個看得見的交接點。這種設計不是降低自動化程度，而是把可以重複的工作與需要判斷的工作分開。Bot 擅長按照固定規則整理資料，人則保留對例外情況的判斷，兩邊的責任都比較容易追蹤。

內容、前端與後端可以分成三支 Bot，但不代表三支 Bot 必須一起出動。每支 Bot 都有自己的技能與工具清單，啟用的能力越少，執行時遇到無關選項的機會就越低。寫手 Bot 只需要讀取研究資料與產生草稿，前端 Bot 只需要檢查頁面結構與畫面，資料 Bot 才需要接觸試算表或資料庫。你可以把這種分工想成公司的職務說明書：職責寫得越具體，交接時越少爭議；權限寫得越寬，出錯時越難判斷是哪一個環節造成問題。

用 Hermes Desktop 建立 Bot 時，畫面上的選項代表什麼

目前的 Hermes Desktop 已經把 Bot Mode 內建在桌面應用程式裡，官方說明指出不需要另外安裝外掛，左側會出現 Bots 分頁，旁邊也會有 Routines 區塊。按下建立新 Agent 後，最短路徑只需要填寫名稱、職稱與描述。名稱是團隊辨認它的方式，職稱用來說明它負責的領域，描述則應寫清楚它處理什麼資料、交付什麼結果，以及遇到哪些情況必須交還給人。這三欄不是裝飾，會直接影響你日後是否找得到正確的 Bot。

進階設定可以從既有 profile 複製，也可以建立全新的空白 profile。複製適合建立同類型的工作角色，例如把一支內容 Bot 複製成中文版本與英文版本，再各自調整語氣；空白 profile 適合處理敏感或範圍很窄的工作，避免沿用不必要的技能與記憶。模型與供應商可以逐支 Bot 指定，也可以沿用啟動時的設定。這讓企業可以把需要長篇整理的工作與需要快速分類的工作分開配置，不必讓整個團隊只能使用同一種模型。

每支 Bot 也可以個別選擇技能、工具組與 MCP 伺服器。對一般使用者來說，可以把它理解成「這位同事的工作桌上有哪些工具」。不要因為某項工具可用，就把它放進所有 profile；工具越貼近職責，結果越好檢查。官方文件也列出自訂 SOUL.md 的選項，它代表這支 Bot 的固定角色與工作規則。企業可以在其中寫入資料格式、回報方式、不可自行決定的事項，以及完成工作後要留下的紀錄，但不應把一次性的任務細節永久塞進角色設定裡。

永久對話與一般對話，要分清楚用途

Bot Mode 的每支 Bot 都有一條固定的 Bot Chat。官方文件把它設計成持續存在的對話，建立 Bot 時就會產生並固定在清單中。這條對話適合放長期交接，例如固定的工作規則、近期任務狀態與其他 Bot 的交辦內容。若工作內容太長，介面中的 /new 或 /reset 會在這條固定對話裡改走壓縮脈絡的處理方式，保留同一段合作關係。一般 session 則仍然可以依照原本方式重新開始，兩種用途不要混在一起。

對企業團隊而言，最實用的做法是把固定對話當成工作紀錄，而不是當成隨手聊天的地方。每次交付可以用一致格式寫明任務名稱、輸入資料、完成內容、待確認事項與下一位接手者。這樣做的好處是人類主管不用翻找零散訊息，就能看出工作目前卡在哪裡。若 Bot 產出的結果要交給另一支 Bot，交接訊息也應附上檔案名稱、版本日期與驗收條件，而不是只寫「請處理」。交接越具體，非同步投遞越不容易變成猜謎。

Routines、群組與人工確認：三種情境不要混用

Routines 適合固定時間重複發生的事情，例如每天整理收件匣、每週彙整客服問題或在工作日結束時整理待辦。官方文件指出，這些例行工作會以 Bot 名稱作為命名空間，也會出現在 Hermes 的排程清單中，執行結果則回到該 Bot 的對話紀錄。設定時應該寫出明確的輸入範圍與停止條件，例如只處理當天新信件、只讀取指定資料夾、遇到缺少欄位就列入待確認。排程不是把模糊要求固定重複，而是把清楚的工作規則固定執行。

群組房適合多支 Bot 對同一個問題交換意見，但不適合取代所有工作流程。官方目前將群組限制在 2 到 6 支 Bot，每則訊息最多進行 3 輪序列回覆，每次傳送最多帶 10 則訊息。沒被點名時，成員不一定都要發言；被點名的 Bot 可以回覆，也可以判斷自己沒有新資訊而略過。這代表群組的重點不是讓所有 Bot 一起說話，而是讓特定角色在需要時提供意見。小型團隊可以把它用在「內容草稿完成後請品牌 Bot 與資料 Bot 各自檢查」這類明確場景。

當任務涉及寄信、修改正式資料、核准付款或對外發布，應在流程中保留人工確認。Bot 可以準備內容、整理差異與標示風險，但「準備完成」不等於「已經送出」。在收件匣流程裡，可以讓 Bot 建立草稿並附上引用來源；在報價流程裡，可以讓 Bot 整理品項與金額，但把送出按鈕留給負責人。這樣的分界也方便測試：你可以逐項檢查 Bot 是否讀到正確資料、是否使用正確格式，以及人工確認後的實際結果是否回寫到原系統。

失敗時看原因，不要把所有問題都當成重試

Hermes 官方文件對投遞失敗有明確區分。暫時離線、傳送逾時、供應商暫時限流或服務端錯誤，可能適合重新執行一次；認證失效、額度不足與設定錯誤，重做一次通常不能解決，還可能增加消耗。系統會附帶可讀的原因代碼，讓管理者知道該重新連線、補充額度、修正設定，或只是等待服務恢復。對企業流程來說，這比看到一行「執行失敗」更有用，因為每一類失敗都能對應不同的處理人與處理時間。

因此，導入 Bot 時最好建立一份簡單的失敗紀錄：發生時間、工作名稱、輸入範圍、Bot 名稱、原因、是否重新執行、重新執行後的結果。這不是要做複雜的監控平台，而是讓團隊看得出某個流程是否經常卡在同一個地方。若相同的工作反覆遇到資料缺欄，應該修正輸入表單或規則；若經常遇到權限問題，應該重新檢視憑證與工具範圍；若只是偶爾逾時，才適合把單次重試當成正常處理。錯誤紀錄要服務於改善，不要拿來掩蓋工作沒有完成。

給中小企業的一份小步驗證表

想試 Hermes Bot Mode 的團隊，可以先挑一個不會直接改變正式結果的流程，並在開始前寫下四個答案：每天要處理哪些資料、完成後要產出什麼、哪些情況必須交還給人、如何確認結果真的完成。接著只建立一支 Bot，讓它使用最少的技能與工具，跑過幾個真實但可回復的案例。不要只看它回覆得像不像人，要檢查它有沒有讀到正確檔案、分類是否符合規則、交接訊息是否完整，以及失敗時有沒有留下可追蹤的原因。

觀察一段時間後，再決定是否增加第二支 Bot。第二支 Bot 不應只是換一個名字，而要接手清楚不同的工作，例如第一支負責整理資料，第二支負責檢查格式。兩支 Bot 之間以固定格式傳遞結果，人則確認每一棒是否真的完成。等流程穩定後，才把固定工作放入 Routines，並設定合理的執行頻率。這種順序可以讓團隊先理解 Bot 的記憶、權限、投遞與錯誤行為，再判斷是否值得擴大使用，不會因為一次展示成功就誤以為所有流程都能自動化。

Hermes Bot Mode 的價值，不是把公司變成一間完全不用人的公司，而是讓不同工作有清楚的負責角色，讓交接內容留在固定位置，也讓企業可以自行決定模型、機器與資料的配置。它適合願意整理流程、願意維護設定，並且能為例外情況保留人工判斷的團隊。若你的團隊目前連資料放在哪裡、誰負責確認、完成的標準是什麼都還沒有共識，先整理工作規則，會比急著建立很多 Bot 更實際。

📩 有任何問題或需要協助，歡迎聯絡我們：[email protected]