QM vs OpenClaw vs Hermes：公司 Agent 怎麼選？

QM、OpenClaw 和 Hermes Agent 都已經能處理不只一個 Agent，但它們切割信任邊界的方法完全不同。

QM 在同一個組織核心內建立個人與共享作用域（scope）；OpenClaw 為不同租戶（tenant）啟動完整、分離的 Gateway cell（閘道單元）；Hermes 則用代理設定檔（profile）分開設定、記憶、技能、憑證與 gateway，再用受管範圍（managed scope）鎖定部分組織基線。

選擇的關鍵不是功能數量，而是你要共用一個控制層，還是分開多個完整執行單位。

本文比較的是 2026 年 8 月 2 日可查到的官方公開資訊。這些專案仍快速演進；採用前應重新檢查版本、文件與安全限制。

QM、OpenClaw、Hermes 的核心差異是什麼？

可以先把系統粗分成五層：

介面（interface）：CLI、Desktop、Web、Slack 或其他訊息管道。
Agent loop：模型如何推理、呼叫工具、反覆完成任務。
個人執行環境（personal runtime）：workspace、記憶、技能和本機工具。
組織控制層（organization control plane）：身分、scope、政策、排程、稽核與共享狀態。
沙箱基礎設施（sandbox infrastructure）：隔離程序、檔案、網路與持久環境。

三者現在都跨越多個層級，不能再簡化成「個人工具對公司平台」。真正的差異是預設治理單位：QM 是 scope，OpenClaw 是 Gateway 或 cell，Hermes 是 profile。

YC 對 QM 的公開說法也採用這個角度：希望它像 Hermes 或 OpenClaw 一樣容易自訂，但能供整間公司使用。這個定位可在QM 公司級 Agent harness 的公開資訊整理看到；官方並未主張三者是可以逐項替換的同類產品。

三個專案的定位

OpenClaw：以 Gateway Cell 分開信任邊界

OpenClaw 把 Agent 連到不同訊息入口，並以 workspace 保存指令、記憶、技能和工作檔案。單一 Gateway 的預設仍是一位受信任 operator 所擁有的 personal assistant 邊界；session key 和不同聊天頻道只負責路由，不是 tenant 授權。

現在的 OpenClaw 也提供實驗性的 Fleet：每個 tenant 使用一個完整 cell，擁有自己的 Gateway、狀態、憑證、workspace、channel account 與容器。這不是在單一 Gateway 裡增加多租戶權限，而是用多個完整實例換取隔離。

這個模型的邊界很清楚，但營運方式也不同。Fleet 目前是單機 lifecycle supervisor，不提供共享 channel ingress、跨主機 cell 管理、tenant 自助 portal 或 delegated administration。若公司需要的是中央協作空間，而不是一組互相分離的 tenant，仍要再補一層控制面。

Hermes Agent：以 Profile 管理獨立 Agent

Hermes Agent 提供 CLI、Desktop 與 messaging gateway，並整合模型、skill、記憶、工具、排程與多種 terminal backend。它目前也能建立多個 profile；每個 profile 有獨立的設定、API keys、記憶、session、skill、cron、state database 與 gateway。

Hermes 的 managed scope 讓管理者在單台機器上鎖定部分設定與環境變數，外部 secret manager 可集中輪替憑證，egress proxy 則能讓 remote sandbox 只拿到 opaque token。這代表 Hermes 已不只是單一個人設定檔。

但它和 QM 仍不是同一種治理。Hermes profile 是彼此獨立的 Agent home；profile 本身不是 sandbox。Managed scope v1 主要依賴檔案權限，官方也明列尚未提供遠端／MDM 配送或 Agent 無法逃逸的硬邊界。它較像「管理一組獨立 Agent」，而不是讓多人在同一個共享 scope 裡協作。

Hermes 官方也提供 OpenClaw migration 路徑，顯示兩者在 Gateway、記憶、skill 與訊息入口場景有明顯交集。差異會隨版本變動，所以不宜把任何一份 feature checklist 當成永久界線。

QM：多人 Agent 的 Harness 與控制層

QM 讓每位使用者和每個 room 擁有獨立 scope，分別管理記憶、檔案、keychain view、權限、cron、Web App 與 durable sandbox。它的 headless core 保存 session、memory 與 job queue，並可連接 Pi、OpenCode、Claude Code 或 Codex 等不同 agent loop。

QM 因此不是把所有人接到同一個超級助手，而是建立可共享服務、又能分開狀態與權限的 multiplayer harness。

代價也很明顯：你不再只維護一個 Agent，而要負責資料庫、訊息入口、sandbox substrate、憑證、政策和平台升級。QM 是早期開源專案，官方 SECURITY.md 已列出現階段限制；「YC 使用」是值得研究的訊號，不是替你的部署背書。

QM、OpenClaw、Hermes 比較表

面向	QM	OpenClaw	Hermes Agent
預設信任邊界	中央 core 裡的使用者／room scope	一個 Gateway；多 tenant 用獨立 cell	一個 profile；每個 profile 是獨立 Agent home
多實例方式	同一組織服務內建立多個 scope	實驗性 Fleet 在單機管理多個完整 cell	多 profile、每個 profile 可啟動獨立 gateway
共享協作	Slack room、group、project 是核心設計	cell 彼此分離；Fleet 不提供共享 ingress	profile 彼此分離，可分享 profile distribution
組織政策	org config、security posture、grants、audience、audit	每個 Gateway 自行設定；cell 由 host supervisor 管生命週期	managed scope 可鎖定單機上的部分設定與環境變數
憑證	scope keychain view 與 grant	每個 Gateway／cell 擁有自己的 credentials	每個 profile 可分開 keys，也支援外部 secret manager
執行隔離	每個 scope 的 durable sandbox	可按 agent／session 建 sandbox；tenant 隔離靠獨立 cell	profile 不等於 sandbox；可選 Docker、SSH、Modal、Daytona 等 backend
目前公開限制	早期實驗軟體，部分 security gate 與 egress 仍有限制	Fleet 實驗中，單一 Gateway 不是 hostile multi-tenant 邊界	managed scope v1 以檔案權限為主，沒有遠端 MDM 或不可逃逸硬邊界
較適合的問題	多人共享專案與中央治理	隔離的個人／tenant Gateway cells	多個獨立 Agent profiles 與跨介面工作流

表格描述的是官方定位與架構重心，不是安全認證或性能排名。實際能力仍取決於你使用的版本、部署設定和外部服務。

不是只能三選一

常見的實際架構可能是分層組合：

員工以 Hermes 或 OpenClaw 類工具處理個人工作。
公司把高價值共享流程放進獨立的 organization control plane。
控制層依任務啟動不同 agent loop。
個人與專案使用分開的憑證、記憶與 sandbox。

QM 本身支援多種 agent loop，正說明 control plane 和 agent runtime 可以分開選擇。採用標準協定也能降低連接成本：MCP 處理 Agent 與工具／資料的介面；A2A 則定義獨立 Agent 系統之間的探索與通訊方式。協定提供連接方式，但不會替組織決定誰有權使用什麼。

依場景選擇，而不是依品牌選擇

Loading diagram...

選 OpenClaw，如果你接受用完整 Gateway 分開 tenant

你希望透過多種 messaging channel 使用 Agent，而且願意把每個不互信的 tenant 放進獨立 Gateway cell。這時 OpenClaw 的邊界直接：一個 Gateway 就是一個受信任 operator domain。

開始前仍要閱讀官方安全文件、開啟需要的 sandbox，並把 Fleet 的實驗性和單機限制算進營運計畫。不要把不同 session 誤認成 tenant 隔離。

選 Hermes Agent，如果你要管理多個獨立 Agent Profile

你重視 CLI、Desktop、messaging、模型切換、skills 和自我累積的記憶，也希望每個 Agent 各自擁有設定與狀態。Hermes profile 很適合這種「一台機器上有多個獨立 Agent」的模型。

如果要由 IT 管理，可以用 managed scope 固定部分基線，並以外部 secret manager 集中輪替憑證。但要記得：profile 和 managed scope 都不是完整 sandbox，也不是跨機器中央控制面。

可先參考Hermes Agent 生態系整理，再依官方 README 核對最新安裝方式與功能。

選 QM 類控制層，如果多人必須共享同一個工作脈絡

當你必須處理個人與共享 scope、專案記憶、集中憑證、durable sandbox、cron、稽核與撤銷，而且這些人需要在同一個 Slack room 或專案裡協作，QM 的中央 core 才是關鍵差異。

但如果公司尚未找出一條有價值的 Agent 工作流，直接自建完整平台可能只是提早承擔營運成本。先做低風險試點，再用真實的權限與協作需求決定是否升級。

選型時一定要問的十個問題

誰是 Agent owner，誰負責停用它？
多位使用者之間是否互相信任？
個人與專案記憶能否分開保存和刪除？
憑證是長效複製，還是按需核發？
Workspace 以外是否有真正的 sandbox 邊界？
背景排程失控時能否集中停止？
工具、skill 和模型版本能否追蹤？
高影響動作是否支援 preview、批准與回滾？
Audit log 能否重建一次工具決策？
平台升級或停止維護時，記憶和工作流能否搬走？

選型會改變你的營運責任。自架不是「免費 SaaS」，而是把成本換成自己的主機、更新、安全、備份與事故處理。若你準備搭一個獨立測試工作區，可參考本站整理的開發者桌面 4 件套；這是聯盟連結，若透過連結購買，我們可能獲得少量分潤，價格不受影響。

我們的建議：從最小邊界升級

對大多數個人與小團隊，最務實的順序是：

先用一個 Gateway 或 profile 找到重複、高頻且低風險的工作。
記錄工作需要哪些資料、工具、批准與輸出。
當第二個獨立信任邊界出現時，用另一個 OpenClaw cell 或 Hermes profile 分開狀態與憑證。
當多人必須共享專案狀態與中央政策時，再導入 QM 類控制層。

這個順序不是把安全延後。相反地，它讓每一次架構升級都有明確需求，避免用一個複雜平台掩蓋尚未驗證的工作流。

下一篇會把選型轉成實作：如何用兩週、單一低風險流程，驗證公司 Agent 是否值得進入下一階段。

常見問題

QM、OpenClaw 和 Hermes Agent 哪一個最好？

先看需要哪種信任邊界。QM 把多人協作放進中央 scope；OpenClaw 以獨立 Gateway 或 tenant cell 隔離；Hermes 以 profile 管理多個獨立 Agent，並可由 managed scope 下發部分組織設定。

QM 可以取代 Hermes Agent 嗎？

不能直接假設可以。QM 目前公開列出的 agent loop 是 Pi、OpenCode、Codex 與 Claude Code，未把 Hermes 列為內建 loop；兩者的預設治理模型也不同。

OpenClaw 適合直接給整間公司共用嗎？

不要讓互不信任的使用者共用同一個 Gateway。OpenClaw Fleet 可為每個 tenant 建立獨立 cell，但目前仍屬實驗性功能，也不提供共享 ingress、tenant 自助入口或跨主機中央控制層。

小團隊應該先自建 QM 嗎？

如果目前只有一個信任邊界，先用單一 Gateway 或 Agent profile 驗證工作流通常更快；當共享記憶、專案身分、集中撤銷與稽核成為必要條件，再評估 QM 類控制層。