AI 有自己的電腦了：2026 年 Agent 同事熱潮一次看懂，為何大家突然都在給 AI 一台機器？

三週內三件大事：Hermes Bot Mode、OpenBot、Grok Bot 為什麼全擠在 2026 年 8 月

2026 年 8 月，AI Agent 領域像是被誰按下了加速鍵。8 月 11 日，xAI 推出 Grok Bot，讓每個 Bot 擁有一台長駐的雲端電腦，24 小時不間斷工作。六天後的 8 月 17 日，Nous Research 把原本獨立的 Hermes Bot Mode 外掛直接內建進 Hermes Desktop，同一天，CopilotKit 開源了 OpenBot，喊出「每個 agent 一台隔離電腦」的架構。三週之內，三件大事接連發生，乍看是三款不同的產品，拆開來看，它們都在回答同一個問題：怎麼讓 AI Agent 擁有一台自己的電腦，像同事一樣自主工作，而不是像工具一樣等人下指令。

這不是巧合。這三家公司在同一個月份、前後不到二十天內做出類似的產品決策，背後指向一個產業級別的共識：傳統的聊天機器人模式已經走到盡頭，下一波戰場是「給 AI 一台電腦」。這篇文章先把三件事的推出時間、產品定位與彼此關係攤開來講清楚，後續章節再逐一拆解每一家背後的技術細節與爭議。

時間線：十六天內，三位玩家陸續進場

先把時間軸拉出來看，這三件事的密集程度其實非常不尋常。

• 8 月 11 日，xAI 推出 Grok Bot（early beta）：這是三家之中最早亮相的。Grok Bot 主打「teammate 而非 task」，每個 Bot 有一台長駐的雲端電腦，包含瀏覽器、檔案系統、終端機和自己的登入狀態，可以 24 小時自主工作，只在需要審批時回來找人類。上市初期僅限 SuperGrok Heavy（約每月 300 美元）和 Cursor 高階方案用戶使用。
• 8 月 17 日，Nous Research 把 Hermes Bot Mode 內建進 Hermes Desktop：這一天，原本獨立開發的 Hermes-Bot-Mode 外掛正式併入主框架，GitHub 上的獨立專案同步封存（archive）。Hermes Bot Mode 的核心概念是「A bot IS a Hermes profile」，把原本一次性、用完即消失的 sub-agent 升級成持久、具名、可跨 session 存續的 specialist，每個 Bot 有自己的角色、模型、記憶與技能。
• 8 月 17 日，CopilotKit 開源 OpenBot（Alpha）：同一天，CopilotKit 在 GitHub 上建立 OpenBot 專案庫並打下 v0.0.1 標籤，主打「可稽核的自主」。每個 agent 擁有一台隔離的容器化電腦，所有動作先經過唯一 gateway 審核、記錄，才允許執行。官方稱之為「開源版的 Grok Bot，但能搭配任何 agent 框架」。

十六天內，一家閉源商業公司、兩家開源社群主力，不約而同推出「給 AI 一台電腦」的產品。如果只有一家做，可以說是單一公司的策略，但三家同時押注，背後一定有結構性的原因。

三款產品，一個共同命題：AI 需要一台自己的電腦

把三家產品放在一起對照，共通點非常鮮明：它們都讓 AI Agent 擁有獨立的運算環境與工具存取權限，而不是僅止於文字對話。

傳統 chatbot 的模式是你問它答，回答完就結束，AI 碰不到你的真實工具。但這種模式有一個根本限制：大約 80% 的網路服務沒有乾淨的 API 或 MCP 可以呼叫，純瀏覽器或電腦操控往往是 AI 觸及真實世界的唯一路徑。Grok Bot 讓 Bot 直接操作真實的瀏覽器與終端機，Hermes Bot Mode 讓 Bot 各自擁有獨立的 profile 與技能組合，OpenBot 給每個 Bot 一台隔離的 Chromium 瀏覽器與獨立登入。三條技術路線，指向同一個終點：讓 AI 的工作成果直接落回真實工具之中，而不是停在聊天視窗裡。

xAI 產品團隊的 Roman 在官方發布稿中講了一句關鍵的話：「90% 完成跟 100% 完成之間存在巨大落差。」xAI 官方新聞稿（2026 年 8 月）指出，Grok Bot 之所以強調「把工作做完」，是因為工作要落在真人會放的地方，也就是真實的工具內部，才算真正完成。這句話精準點出了這波 Agent Bot 浪潮的核心焦慮：AI 在對話框裡給你答案很容易，但要它自己打開 CRM、更新欄位、寄出跟進信件，就是另一回事。

三種路線，三種答案

雖然命題相同，三家給的答案卻各自不同，也正好對應三種不同的產品哲學。

Hermes Bot Mode 走的是「開源在地派」。Nous Research 把整個架構建立在「每個 Bot 就是一個 profile」的基礎上，Bot 之間的溝通是真正的 CLI handoff，不是背景 daemon，也不需要 core patch。根據 Hermes-Bot-Mode 專案庫（2026 年 8 月），這個外掛在封存前累積了 658 顆星星、117 個 fork，主框架 hermes-agent 則有超過 23.8 萬顆星星。它的精神是：我的 agent 團隊，我自己掌握。

OpenBot 走的是「開源治理派」。CopilotKit 強調的不是自主性，而是可稽核性。官方在 OpenBot 產品頁（2026 年 8 月）寫得很直接：「一個能行動卻無法事後驗證的 agent，只是帶有聊天介面的負債。」每個動作先經由唯一 gateway 解析真正目標、用 CEL 規則評估 policy、寫入 audit row，才允許執行。它的精神是：不只給 AI 電腦，還給 AI 一套可稽核的規矩。

Grok Bot 走的是「商業自助派」。xAI 把重點放在「像帶新人一樣，示範一次就交給它」。官方員工案例中，sales Bot 會自己更新 CRM、ops Bot 會處理發票、engineering Bot 會在產品 UI 重現 bug 並開 ticket。它的精神是：最直觀、最省事，但代價是閉源與雲端綁定。

為什麼剛好擠在 2026 年 8 月

三件事擠在同一個月，與其說是巧合，不如說是產業條件成熟後的必然。Gartner 預測 2026 年底將有 40% 的企業應用內建 task-specific AI agent，這個數字在 2025 年還不到 5%（Gartner，2025 年預測）。企業需求已經從「AI 能不能回答問題」推進到「AI 能不能幫我把事情做完」。

，Stanford AI Index 2026 顯示，agent 在真實終端機任務的成功率從 2025 年的 20% 大幅躍升到 77.3%（Stanford AI Index，2026 年）。技術成熟度跨過了實用門檻，讓「讓 AI 碰真實工具」不再只是實驗室裡的展示，而是可以上線的生產力工具。

第三，competition 帶動的示範效應。Anthropic 早在 2026 年 4 月就讓 Claude Cowork 透過 Computer Use 操作電腦，而 OpenAI 的 ChatGPT Agent 也已經支援虛擬瀏覽器。當市場前幾名玩家都往這個方向走，其他人如果不跟上，就會在下一階段的 agent 競賽中落後。xAI 選在 8 月 11 日打頭陣，Nous Research 與 CopilotKit 選在 8 月 17 日同時跟進，背後都是同一個產業節奏。

一句話總結這波浪潮

如果用一句話來總結這三件事，那就是：2026 年 8 月，AI Agent 正式從「會聊天的工具」跨入「有自己電腦的同事」時代。Hermes Bot Mode 代表開源社群對「自我掌握」的堅持，OpenBot 代表對「治理與稽核」的重視，Grok Bot 代表商業產品對「體驗與效率」的追求。三條路線會在接下來的章節中逐一拆解，但讀者需要記住的是：這不是三種不同的產品類別，而是同一個浪潮的三種答案。

接下來的章節，我們會先深入 Hermes Bot Mode，看看開源社群怎麼把「一支 agent 團隊」變成現實。

從「你問它答」到「它有自己的瀏覽器、檔案與登入」：Agent 同事的底層邏輯

前一章我們看到，2026 年 8 月三週內，AI Agent 領域接連爆紅三件大事：Hermes Bot Mode、OpenBot、Grok Bot。表面上是三家不同的產品，本質上卻是同一波浪潮，AI Agent 正式告別「會聊天的工具」，跨入「有自己電腦的同事」時代。這不是行銷話術，而是架構上的根本改變，理解這個改變，才能看懂接下來所有章節。

傳統 chatbot 與 Agent Bot 的差別，不在「聰明」，在「手腳」

過去幾年我們熟悉的 chatbot，無論是客服機器人還是寫作助手，本質上都是一問一答。你丟一句話進去，它吐一段文字出來，對話結束，一切歸零。沒有記憶，沒有行動，沒有後續追蹤。它像一個百事通的朋友，你說什麼它都接得上話，但聊完之後它不會幫你把事情辦好，甚至不會記得你們聊過什麼。

Agent Bot 完全不一樣。它的核心不是「更會聊天」，而是「擁有自己的電腦」。這台電腦不是比喻，而是實體存在的一台機器，可能是一台雲端虛擬機，也可能是一個隔離容器，裡面有獨立的瀏覽器、獨立的檔案系統、獨立的使用者設定檔。AI 可以打開瀏覽器，登入你正在用的 CRM 系統，一筆一筆更新客戶資料；可以打開 Gmail，把發票附件下載到自己的檔案夾，整理成表格；可以開著終端機，執行你交代的程式碼。

這意味著什麼？意味著它可以做到「做完才回來」。傳統 chatbot 給你答案，執行靠你自己。Agent Bot 給你結果，而且是登入你的工具、在你的真實工作環境裡完成的那種結果。這就是第一章提到的「工作落回真實工具才算 100% 完成」的底層邏輯。

為什麼 AI 非得「自己開瀏覽器」不可？因為約 80% 的網路服務沒有乾淨 API

有些人會問：為什麼不直接寫程式呼叫 API 就好？為什麼要讓 AI 像人類一樣開瀏覽器、點按鈕、填表單？這牽涉到一個殘酷的現實：約 80% 的網路服務沒有提供乾淨的 API 可以呼叫（xAI 官方文件，2026）。意思是，你想讓 AI 操作一個軟體，但那個軟體沒有開放程式介面，或者開放的 API 權限不足，無法完成「登入、查詢、填寫、送出」這種完整動作。

API 是什麼？你可以把它想像成一個門市櫃檯，你想要什麼，跟櫃檯說，櫃檯幫你處理。問題是，並不是每家店都有櫃檯。很多服務只有開放式的貨架，你得自己走進去、自己拿、自己結帳，而這個「走進去」的過程，目前只有網頁瀏覽器做得到。

所以 Grok Bot、OpenBot、Hermes Bot Mode 不約而同選擇讓 AI 操控真實瀏覽器。OpenBot 的架構裡，每個 Bot 都配一台隔離的 Chromium 瀏覽器，有自己的登入狀態，不會跟你本人正在用的 Chrome 混在一起（CopilotKit 官方說明，2026）。Grok Bot 的官方文件更直接說明，每個 Bot 都有「長駐、帳號級」的雲端電腦，裡面有真實瀏覽器、檔案系統和終端機，電腦在 session 之間保持狀態，意思是不管你什麼時候回來，它都記得做到哪了（xAI 官方文件，2026）。

這個選擇背後是一個產業共識：在 API 覆蓋率不足的情況下，純瀏覽器操控是 AI 觸及真實世界的唯一路徑。與其等全世界每一家軟體公司都做好 API，不如讓 AI 學會用瀏覽器，因為瀏覽器是唯一一個「什麼都能開」的入口。

「90% 完成」與「100% 完成」之間，是巨大的落差

Grok Bot 產品經理 Roman 在官方發布時說了一句話：「90% 完成和 100% 完成之間存在巨大差異。Grok Bot 能完成一擊，因為工作落在真人會放的位置，在真正的工具裡。」（xAI 官方發布，2026）這句話點出了傳統 AI 工具最讓人不滿的地方。

傳統 chatbot 給你的東西，永遠是「半成品」。它幫你擬好一封回信，你得自己貼到信箱裡寄出；它幫你整理好拜訪紀錄，你得自己複製貼上到 CRM 系統；它算出一個數字，你得自己開 Excel 填入。這些「一步」看似簡單，但累積起來就是每天多花半小時到一小時的瑣碎複製貼上。更糟的是，這些工作一旦脫離 AI 的對話框，就斷了追蹤，你無法確定它是否真的被執行，只能靠自己記住。

Agent Bot 企圖消滅這個落差。當 Grok Bot 的銷售人員用它更新 CRM 時，AI 是直接登入 Salesforce，把通話重點寫在正確的欄位，存檔，然後在對話框回報「已更新，編號 12345」（xAI 官方案例，2026）。OpenBot 的治理機制要求每個動作都先經過 Gateway 審核、記錄，才真正執行，這代表 AI 做完的事有稽核軌跡可查（OpenBot 官方文件，2026）。Hermes Bot Mode 則用 cron 例行任務讓 Bot 定時執行工作，時間到了自動跑，跑完把結果留在對話裡（Nous Research 文件，2026）。

這三種做法的共通點是，AI 做的事情「直接落在真實工作的最終位置」，而不是給你一個需要你動手搬運的結果。這就是機器人同事與聊天機器人的分水嶺。

Agent Bot 的「自己的電腦」到底長什麼樣子？

我們可以把這台「AI 的電腦」拆成三層來看。第一層是獨立的瀏覽器，AI 用它開網頁、登入服務、填表單。第二層是獨立的檔案空間，AI 把下載的檔案、產出的文件、暫時的資料都存在這裡，不會弄亂你的電腦。第三層是獨立的登入狀態，AI 有自己的帳號或使用你授權的登入資訊，它登入之後保持登入狀態，隔天繼續工作不會斷線。

Grok Bot 的架構最具體，每個 Bot 擁有一台長駐的雲端虛擬機，session 之間保持狀態（xAI 官方發布，2026）。OpenBot 則是用 Docker 容器隔離，每個 Bot 一台獨立容器，裡面有自己的 Chromium 瀏覽器設定檔和 workspace 資料夾（CopilotKit 官方文件，2026）。Hermes Bot Mode 稍微不同，它不開虛擬機，而是把每個 Bot 的設定、記憶、技能工具（MCP）隔離開來，各有各的設定檔（madeyoga 獨立實測，2026）。

不管是哪一種做法，核心概念都一樣：AI 不再是躲在對話框後面的幽靈，而是一個有自己工作空間的實體夥伴。它有自己的書桌（檔案空間）、自己的電腦螢幕（瀏覽器）、自己的門禁卡（登入狀態）。你可以交代它事情，看它進度，甚至打斷它，就像對待一個坐在隔壁的同事。

為什麼這個轉變對企業特別重要？

把「給 AI 一台電腦」這件事放到企業場景，意義立刻浮現。過去企業導入 AI 的最大心理關卡不是「AI 聰不聰明」，而是「我敢不敢讓它靠近我的工具」。這正是 2026 年眾多企業的真實心聲（EnterpriseDNA 分析，2026）。

Chatbot 時代這個問題不存在，因為它碰不到你的工具。Agent Bot 時代這個問題變成核心。當 AI 擁有自己的瀏覽器和登入狀態，它可以登入你的 ERP、你的客戶資料庫、你的金流系統，意味著它獲得了「能造成實際影響」的能力。能力越大，責任越大，企業也越需要審慎評估。

也正因為如此，OpenBot 的治理 Gateway 特別強調「每個動作在發生前都被決定，發生後都被記錄」，「一個能行動但無法事後驗證的 AI，是有聊天介面的風險，不是生產力工具」（moclaw 評測，2026）。這是 Agent 同事與 chatbot 另一個截然不同的地方：Chatbot 犯錯頂多說錯話，Agent 犯錯可能做錯事，所以治理與稽核變成不可或缺的基礎建設。

回到這一系列的主題。Hermes Bot Mode 的開源精神、OpenBot 的治理框架、Grok Bot 的商業體驗，三條路線的底層邏輯一模一樣：AI 需要一台自己的電腦，才能從「你問它答」進化成「它做完再回來」。理解了這個邏輯，接下來我們就能深入看每一家怎麼把這台電腦組裝起來，以及不同選擇會帶來哪些代價與機會。

實際動手：Hermes Bot Mode 把一支 Agent 變成能互相 @mention 的團隊

前一章我們談到，Agent 犯錯可能做錯事，所以治理與稽核變成必要基礎建設。我們也點出三條路線的底層邏輯一模一樣：AI 需要一台自己的電腦。而 Nous Research 在 2026 年 8 月 17 日推出的 Hermes Bot Mode，則是用「開源、自架、profile 即 Bot」的方式，把這台電腦的鑰匙直接交到使用者手上，做法是讓一支 Agent 變成一支能互相 @mention 的具名團隊。

「A bot IS a Hermes profile」，不是另一套系統

官方文件對 Bot Mode 最核心的定義只有一句話：「A bot IS a Hermes profile」。意思是，每一支 Bot 就是一個 Hermes profile，Bot Mode 只是包在這個 primitive 外面的使用者介面。它沒有新增任何原語、不需要 core patch、沒有背景 daemon，也不多佔儲存空間。2026 年 8 月 17 日，這個功能從獨立 plugin 直接內建進 Hermes Desktop，原本的 plugin 專案庫 NousResearch/Hermes-Bot-Mode 同步封存，GitHub 顯示 658 stars、117 forks，授權為 MIT（2026）。換句話說，這不是實驗性質的附掛程式，而是已經收編進主程式的正式功能。

每一支 Bot 擁有自己的頭像、角色、模型與 provider、記憶、技能集與 MCP，以及自己的 cron 例行任務。跟 Hermes 過去的 sub-agent 相比，sub-agent 是一次性、用完即消失、互不通話的臨時子任務；Bot 則是持久、具名、可以跨 session 存續的 specialist。官方甚至替每支 Bot 保留了「canonical forever Bot Chat」，使用者打 /new 會被重新導向到 /compact，取得全新上下文、但永遠不會 fork 出另一個對話關係。這對長期維護一支 Bot 的人來說，是相當關鍵的設計。

三支 Bot 的實測：寫手、前端、後端各自持有自己的技能

獨立開發者 madeyoga 在 2026 年做過一組非常清楚的實測，一次開了三個 Bot：Blogi 負責內容、Nuxti 負責 Nuxt UI、Aspi 負責 ASP.NET 後端。三支 Bot 各自持有自己的 skills 與 MCP，想要什麼能力就裝在對應的 Bot 身上，彼此不互相污染。這個設計背後的概念是領域切割。過去單一 Agent 只能綁定單一 context window、單一 model、單一執行緒，一旦任務牽涉兩種專業，就得在同一個上下文裡切換角色，很容易互相干擾。Bot Mode 把這件事變成實體的分工：寫手 Bot 的 MCP 裡放知識庫與文件工具，前端 Bot 只看到元件庫與設計系統，後端 Bot 則綁定資料庫與 API 文件。而且每一支 Bot 可以用不同 model 與 provider，寫手用長上下文模型，前端用速度快、成本低的模型，完全是各自獨立調度。

三支 Bot 在同一個群組房裡協作，彼此可以 @mention，就像真實團隊用 Slack 或 Teams 討論一樣。madeyoga 在評測中特別強調：「agents aren’t just invisible calls in a workflow. Each bot has its own identity， role， tools， skills」，這正是這個模式最迷人的地方。

CLI handoff 與 Routines：Bot 之間怎麼對話

Bot 之間的通訊，本質上是一條 CLI handoff 指令。官方文件揭露的實際呼叫長這樣：hermes -p <bot> chat --in ~ -c "Bot Chat" -Q -q "Message..."。系統會自動加上 attribution 前綴，好讓收訊的 Bot 知道這則訊息來自哪一位同事。也就是說，Bot 之間沒有特殊的私有協定，全部走同一條公開指令管線，開發者可以完全掌握訊息流向。

例行任務則沿用 Hermes 的 cron 機制，稱作 Routines。Routine 的命名規則是 [bot:<名字>] <任務名稱>，設定完之後會出現在 hermes cron list 裡。每一支 Bot 可以有自己的時程表，例如寫手 Bot 每天早上九點彙整素材，前端 Bot 每小時同步一次設計 tokens，後端 Bot 半夜跑一次資料庫備份檢查。群組房設有硬上限：2 到 6 支 Bot、一則訊息最多 3 輪 serial rounds、每次 send 最多 10 則訊息。失敗重試最多一次，而且只在重試確實有幫助的時候才重試；auth、quota、config 這類失敗永遠不會自動重試，系統會提供 12 種 machine-readable 原因碼，方便外部程式接手處理（2026）。

投遞是 per-invocation，訊息要等下一次運行才看得到

實際動手之後會發現一個關鍵限制：bot-to-bot 的投遞是 per-invocation。意思是，當一支 Bot 傳訊息出去，收訊的那支要等到下一次運行才會看到，它無法中斷對方正在進行中的對話。官方在文件裡自承，live interrupt of a mid-conversation bot 是 future work。madeyoga 的實測則直接描述：「If Nuxti is mid-turn， Blogi’s message waits.」這跟一般聊天軟體的即時感完全不同。你可以把 Bot 群組房想成一個留言板，而不是一通電話。這個限制也影響了使用者的流程設計，團隊必須把任務拆成非同步的步驟，而不是期待 Bot 之間能即時交換意見。

這個限制正好回應了社群最尖銳的批評。Reddit 上有用戶認為 Bot Mode「只是介面改變」「把前端包一層就叫 bot mode」（2026）。從某個角度來看確實如此，它沒有改變 Hermes 的底層推理能力，也沒有新增排程引擎或調度器。但從使用體驗來看，把隱形的工作流程呼叫變成看得見、具名、狀態可以跨 session 存續的 specialist，本身就是一種功能。跟 Claude Code 那種 ephemeral、扁平、不可再派生的 subagent 比起來，Bot Mode 提供的是截然不同的協作模型。

人仍是調度者：Handoffs 不是流水線

做那組三 Bot 實測的開發者自己下了一個結論：「Handoffs are not a pipeline… I am the scheduler」。這句反思很重要。Bot 之間的交接不是工廠輸送帶，訊息不會自動流到下一站。實際上，還是得由人類決定哪支 Bot 該在什麼時候接手。他甚至提醒，「Capability lists drift」，意思是不同 Bot 的能力清單會隨著各自更新而逐漸偏離，過一陣子你可能搞不清楚前端 Bot 到底會不會寫 API 串接。

把這些放回台灣企業的應用場景：Bot Mode 的價值不在於取代工程師，而在於把專業領域切開，讓每一支 Bot 只專注一件事。寫手 Bot 持有內容技能與知識庫 MCP，前端 Bot 持有元件庫與樣式系統，後端 Bot 持有資料庫連線與部署工具。人負責指派任務、檢查結果、處理例外。這個模式特別適合那些手上已經有明確分工流程，卻被重複勞動卡住的團隊。當然，人事成本不會消失，調度與驗證依然需要人參與，但至少每一支 Bot 的責任邊界清清楚楚，出錯時也知道該找誰。

下一篇我們要轉向另一條路線，看看 CopilotKit 的 OpenBot 如何把「可稽核的自主」變成治理基礎建設。先記住這章的結論：Bot Mode 讓 Agent 有了角色與分工，但投遞是非即時的，人仍然是整個系統的調度者。

實際動手：OpenBot 的隔離電腦與政策閘道，以及 Grok Bot 的雲端長駐 VM

前一篇談完 Hermes Bot Mode 的角色分工，這一章我們實際拆解另外兩家的運作架構。OpenBot 與 Grok Bot 都走「給 AI 一台電腦」的路線，但兩者對於「電腦怎麼開、動作怎麼管」的答案截然不同。OpenBot 強調隔離與稽核，每個動作先經過政策閘道審核、記錄，才真正執行；Grok Bot 則把重心放在「像帶新人一樣」，示範一次流程，它就記住並在雲端 VM 裡長期運作。這兩個實作路線，正好對應台灣企業導入 AI 同事時最常問的兩個問題：它碰得到我的工具，然後呢？它做了什麼，我看得到嗎？

OpenBot：一台 agent 一台隔離電腦，動作先過閘道

CopilotKit 在 2026 年 8 月 17 日開源 OpenBot，定位是「開源的 AI 同事平台」。根據官方 GitHub 專案庫 的敘述，每個 agent 擁有自己的隔離電腦，包含獨立的 Chromium 瀏覽器、自己的登入狀態、自己的 /workspace 檔案目錄，以及只被授予的工具。換句話說，OpenBot 不追求讓 agent 隨意進出你的環境，而是先蓋好一道牆，牆內給它完整的作業空間。

實際部署時，OpenBot 用 Docker Compose 一次帶起 PostgreSQL（含 pgvector 擴充）、supervisor 主控程式、每個 Bot 各自的 computer 容器、PoC Bot、LangGraph Bot，以及 Hono API 層。supervisor 的角色是調度與治理中樞，它為每一個 Bot 開出獨立容器，容器裡有自己的 /workspace、Chromium 瀏覽器、browser profile。兩個 coworker 同時對同一服務持不同登入，彼此看不見對方，也不碰使用者本人正在用的 Chrome 視窗。

這套隔離架構的關鍵，在於 policy gateway，政策閘道。OpenBot 官方文件用一句話說明它的哲學：所有動作先被決定，然後被記錄，任何 Bot 做的事都經過同一個閘道，這個閘道同時負責決策與記錄。這就是「一個 agent 能使用你的工具」與「一個 agent 你敢讓它靠近你的工具」之間的差異。閘道運作的順序是：先解析動作背後的真正目標，不信任模型自己宣稱的意圖；接著用 CEL 規則評估是否符合政策；寫入 audit row（稽核紀錄）；才真正呼叫工具。

政策評估的細節也值得留意。deny 的優先級高於 allow，如果沒有任何政策允許某個動作，閘道就拒絕執行，缺政策就不准動。甚至當規則編譯失敗時，系統也會朝「拒絕」的方向放行，寧可擋下也不誤放。至於密碼或 API key 這類 secret，閘道只記錄「被要求過」以及長度，不把實際內容寫進 transcript，避免稽核日誌本身變成資安漏洞。

人機接手機制同樣是 OpenBot 的治理一環。當 Bot 碰到登入牆或 2FA 驗證時，它不會硬闖，而是停下來發出求助，控制權交回人類手上。系統會記錄 computer.help_requested、control_taken、control_released 三個事件。人在駕馭期間，Bot 的動作會被拒絕，而不是排進佇列等待，確保人在操作時不會被背景程序干擾。

從實測數據看，OpenBot 的資源需求不算低。根據 GitHub 上的官方資料與獨立測試，單一 Bot 在尖峰時段記憶體使用約 0.55GB，官方建議的最低需求是 2GB，推薦 4GB。單一映像檔大小約 5.3GB，裡面包含 Playwright 瀏覽器自動化元件。換句話說，每多一個 coworker，就要多一台容器、多一份常駐 Chromium 的記憶體開銷。這對台灣中小企業的伺服器預算來說，是需要事先算清楚的成本。

OpenBot 目前還在 Alpha 階段，版本為 v0.0.1，2026 年 8 月 17 日建專案庫同日打標籤。官方預設的 OPENBOT_SINGLE_USER 模式會把每個 request 都當作單一管理員，完全跳過登入驗證，官方文件也明確表示 production 環境會拒絕這個旗標。另外，durable threads 與記憶體功能依賴 CopilotKit Intelligence 授權，如果沒有取得授權，Bot 會「忘記每一段對話」，而且沒有降級模式。這點也被社群批評為 vendor lock-in。

還有一個有趣的插曲：Intel Labs 在 2020 年也開源過一個叫做 OpenBot 的專案，那是一台用手機當大腦的 50 美元自駕車，跟 CopilotKit 的 AI 同事平台完全無關，搜尋時要注意區分。

社群對 OpenBot 的評價，moclaw.ai 的分析說得很精準：值得觀察，還不到部署的時候。但也有評論指出，一個能行動卻無法事後驗證的 agent，只是換了聊天介面的責任炸彈。自主若沒有可稽核性，只是更快走向事故的捷徑。這正呼應 OpenBot 的核心主張：自主不是最難的，可稽核的自主才是。

Grok Bot：長駐雲端 VM，示範一次就記住

xAI 在 2026 年 8 月 11 日推出 Grok Bot，定位是 always-on 的 agent 團隊。根據 xAI 官方發布稿，每個 Bot 都有自己的雲端電腦，那是一台長駐的 VM，裡面有真實瀏覽器、檔案系統、終端機、外部連接器與 MCP 工具。與 OpenBot 的「每個 Bot 各自獨立容器」不同，Grok Bot 的所有 Bot 共用同一台帳號級雲端電腦，電腦在 session 之間保持狀態。官方文件特別提醒，不要把單一個別 Bot 當作各自的安全邊界。

Grok Bot 最受好評的功能是 teach-a-task。使用者用螢幕錄影示範一次流程，Bot 看過就記住，之後可以長期自動執行。發布稿引用內部員工案例：sales Bot 更新 CRM、寫上通話紀錄重點、起草後續跟進郵件；ops Bot 安頓新進員工、處理 Gmail 裡的發票；engineering Bot 在產品 UI 重現 bug、開 ticket、把修復交給 debugging Bot。產品負責人 Roman 說，90% 完成與 100% 完成之間有巨大落差，Grok Bot 能把一哩走完，因為工作落回真實工具，落在人類原本會放的地方。

定價方面，cellcog 的價格追蹤顯示，Grok Bot 在 16 天內經歷三次調整。8 月 11 日上市時僅限 SuperGrok Heavy（約 300 美元/月）與 Cursor Ultra（200 美元/月），沒有免費層。8 月 21 日降到 60 美元，8 月 26 日再降，基本 Cursor Pro 降到 20 美元/月、SuperGrok 基本方案 30 美元/月。地面價在 16 天內跌了 10 倍，這在企業軟體定價史上相當罕見。

額度消耗是另一個需要留意的數據。Grok Bot 使用自有額度，不佔原本 Grok 或 Cursor 用量，但每週額度大小官方並未公開。用戶回報大約 10 分鐘的 Bot 活動就吃掉 40% 的每週額度，重度使用一天內就耗光。這對企業導入是極大的變數，帳單可能比人事成本更早嚇退老闆。

社群實測方面，Hacker News 用戶 jjcm 讓 Bot 聯絡約 40 家越南布料供應商談價、鎖定一家、催促打樣，一個月下來他說自己用掉的 token 比過去五年加起來還多。always-on 的 agent 極度燒 token，這是商業模式的必然，也是企業導入前必須先算清楚的帳。

缺點也很明確：無法選擇模型，系統自動挑選且不公布 router 規則；閉源、綁定 xAI 模型，不能換成 Claude、GPT、Gemini 或本地模型；無法檢視、修正、匯出或刪除記憶；目前只有桌面版加 iPhone companion app，沒有 email、Slack 或 Telegram 介面。

兩種路線，同一個問題

把 OpenBot 與 Grok Bot 擺在一起看，會發現它們回答的是同一個問題：AI agent 有自己的電腦之後，你敢不敢讓它靠近你的工具？OpenBot 的答案是治理，先審核、後執行、全程記錄，用政策閘道把「能做」與「該做」分開。Grok Bot 的答案是信任，示範一次、長期託付，靠雲端帳號隔離與品牌商譽撐起使用者的信心。對台灣企業來說，選擇哪一條路，其實是在選擇自己對 AI 的掌握程度。下一章我們會把這三家的差異放上同一張比較表。

三種解法、三套代價：開源在地、開源治理、商業自助要怎麼選

把 Hermes Bot Mode、OpenBot 與 Grok Bot 三家攤開來看，會發現它們雖然都在做「給 AI 一台自己的電腦」，但背後的哲學與代價截然不同。Hermes Bot Mode 是開源在地派，強調自我掌握；OpenBot 是開源治理派，強調先審核後記錄的可稽核自主；Grok Bot 是商業自助派，最省事但綁定 xAI 模型與雲端。這一章我們從授權、自架門檻、治理機制、訂閱價格與資源消耗五個面向並排比較，幫讀者看清楚每一條路真正的成本。

三個流派，三個答案

先說結論：這三家不是在比誰的功能多，而是在回答同一個問題，「你敢不敢讓 AI 靠近你的工具？」

• Hermes Bot Mode：開源在地派。每一支 bot 都是一個獨立的 Hermes profile，有自己的角色、模型、技能與記憶。企業把整套系統架在自己的機器上，資料不出門，規矩自己訂，代價是 IT 團隊得扛下自架與維護的責任。
• OpenBot：開源治理派。每一支 bot 擁有一台獨立的隔離容器加 Chromium 瀏覽器，所有動作先經過政策閘道審核、寫入稽核記錄、才允許執行。它把「可稽核的自主」當成核心賣點，要的是讓企業敢把 bot 放進正式流程。
• Grok Bot：商業自助派。xAI 把一切打包成雲端服務，每個 bot 有一台長駐的雲端 VM，示範一次流程它就學會。企業不用碰基礎設施，但模型選擇、記憶管理與資料落點全部交給 xAI 決定。

五個面向，並排比較

治理機制，決定你敢不敢放手

五個面向裡，最關鍵的差異在治理。OpenBot 的做法是「先審核後記錄」，任何動作在執行前都會先經過一個唯一的 gateway，系統會解析真正的目標，而不是單純相信模型的宣稱，再用 CEL 規則評估是否符合政策，寫入稽核紀錄後才呼叫工具。deny 優先於 allow，缺少政策時什麼都不許做，秘密資訊只記錄「被要求」與「長度」，不會進入對話紀錄。這種設計把「能做什麼」與「該做什麼」徹底分開，適合需要對稽核負責的產業。

Hermes Bot Mode 的治理則比較輕量，主要靠 profile 隔離。每個 bot 有獨立的技能與 MCP 設定，寫手 bot 不會污染前端 bot 的環境，但 bot 之間透過 CLI handoff 傳遞訊息時，投遞是 per-invocation 的，收訊 bot 必須等到下一次運行才會看到訊息，無法即時中斷進行中的對話。官方自己都承認，即時打斷是未來工作。

Grok Bot 的治理最簡單，也最模糊。官方文件明確指出，所有 bot 共用同一台帳號級雲端電腦，不建議把單一 bot 視為安全邊界。它的隔離是帳號層級的，不是 bot 層級的，企業必須理解這層風險。

價格戰與隱藏的 token 帳單

Grok Bot 的定價在 2026 年 8 月經歷了戲劇性變化。8 月 11 日上市時僅限 SuperGrok Heavy 與 Cursor Ultra 等高階方案，8 月 21 日降到 60 美元，8 月 26 日再次調整，基本方案從每月 20 到 30 美元起跳。

這看起來划算，但真正的成本在 token 消耗。國外開發者 jjcm 在 Hacker News 分享實測經驗，他讓 Grok Bot 聯絡約 40 家越南布料供應商談價，一個月下來的 token 用量超過過去五年的總和。always-on agent 的特色就是持續運作，每一封郵件、每一次網頁瀏覽、每一段思考都在燒 token。另一位用戶回報，約 10 分鐘的 bot 活動就吃掉每週配額的 40%。

OpenBot 與 Hermes Bot Mode 雖然開源，但自架不代表免費。OpenBot 需要 PostgreSQL 與容器環境，單一 bot 映像檔約 5.3GB，記憶體尖峰實測達 0.55GB，官方建議至少 2GB 記憶體。如果同時跑多個 bot，伺服器成本會線性成長。Hermes Bot Mode 則需要企業自己佈署模型與 API key，token 費用同樣跑不掉。

選擇的關鍵，回到「你敢不敢」

三條路沒有絕對的對錯。開源在地派適合已經有技術團隊、對資料掌控有高度要求的企业；開源治理派適合需要稽核軌跡、身處受監管產業的企業；商業自助派適合想快速驗證、願意把資料交給雲端的團隊。但無論選哪一條，都要先算清楚 token 用量與基礎設施成本。always-on agent 不是買了軟體就好，它是一台 24 小時運轉的機器，每一秒都在產生費用。

替代方案有限公司觀點：給 AI 一台電腦之前，台灣企業先想清楚三件事

這波「給 AI 一台自己的電腦」浪潮，我們在台灣第一線看到的反應很兩極。一邊是老闆眼睛發亮，覺得終於可以擺脫重複勞動；另一邊是 IT 主管冷汗直流，因為他們第一個想到的問題永遠是：這套系統會碰到我們哪些資料？

我們認為，導入前的核心問題從來不是 AI 聰不聰明，而是你敢不敢讓它靠近你的工具。Hermes Bot Mode、OpenBot、Grok Bot 這三款產品，表面上是三種技術路線，骨子裡是三個關於信任的答案。Hermes Bot Mode 說「我的 agent 團隊，我自己掌握」，OpenBot 說「不只給 AI 電腦，還給它一套可稽核的規矩」，Grok Bot 則說「像帶新人一樣，示範一次就交給它」。三種答案沒有對錯，只有適不適合你的公司。

第一件事：先挑一個流程，證明它真的能把工作做完

很多台灣企業導入 AI 的失敗模式，我們看過太多次了。第一步都是先買工具，第二步是要求員工「趕快用起來」，第三步是三個月後發現使用率不到兩成，然後專案悄悄消失在組織的記憶裡。問題不在員工不配合，而在於企業從來沒有先回答一個問題：這個 AI 到底要負責哪一件具體的事？

我們的建議是反過來做。不要一開始就想「讓 AI 全面賦能公司」，那是顧問公司在講的漂亮話。請先挑一個流程，一個重複性高、容錯度也高的流程。什麼叫容錯度高？就是萬一 AI 做錯了，你不會得罪客戶、不會違反法規、不會造成財務損失。我們常用的兩個例子是收件匣整理和發票處理，前者是把信件分類、標記、草擬回覆，後者是讀取發票上的廠商、金額、日期，丟進會計系統的草稿區。兩者都有一致性的規則可以遵循，而且出錯時人類很容易發現並修正。

把這個流程交給 Bot 去跑，不要只用測試環境，要讓它在你真實使用的工具上運作，Gmail、ERP、CRM 都好。判斷的標準只有一個：它有沒有把工作做到 100% 完成。傳統 chatbot 的毛病是回答得頭頭是道，但你要的東西從來不會真的出現在系統裡。Hermes Bot Mode 的 Routines 能讓 Bot 定時執行任務，Grok Bot 的賣點是工作會落回真實工具，OpenBot 則強調整段過程可稽核。如果在真實工具上的完成度一直無法讓你放心，那就換一個流程再試，或者換一個產品再試，而不是硬撐。

第二件事：先算清楚 always-on 的燒錢速度

永遠在線的 agent 不是買一套軟體，而是養一台 24 小時運轉的機器。我們必須誠實地說，這點在台灣企業的溝通中常常被忽略。老闆看到的是「省下的人力成本」，IT 看到的是「伺服器與 API 費用」，但兩邊都沒算到 always-on agent 最可怕的地方：它會一直吃 token，吃到你心臟病發作。

國外就有實際案例。一位 Hacker News 用戶 jjcm 在實測 Grok Bot 一個月後描述，他讓 Bot 聯絡約 40 家越南布料供應商談價格、鎖定合作對象、催促打樣，那個月消耗的 token 量超過他過去五年總和（來源：Hacker News 討論串，2026）。另一位用戶 cellcog 記錄到，Grok Bot 的每週額度大約 10 分鐘的 Bot 活動就會吃掉 40%，重度使用的話一天內就會耗光（來源：cellcog.ai 分析，2026）。台灣企業的預算數字和國外新創不同，這種消耗速度在台灣公司大概撐不過兩週就會被財務部門攔下來。

所以我們的建議是：導入前先做一份 token 用量估算。把流程拆成步驟，粗略計算每一步會呼叫幾次模型、輸入多少字、輸出多少字，然後乘以預期的執行頻率。開源方案像是 Hermes Bot Mode 或 OpenBot，token 費用來自你自己接的模型 API，單價可以控制，但伺服器與維運成本要算進去。商業方案像是 Grok Bot，月費看似固定，但每週額度用完之後的計價方式並不明朗，這點在簽約前一定要問清楚。

第三件事：不要一次全公司鋪開，先讓一個 Bot 通過驗收

一件我們想強調的事，是「循序漸進」不是保守，而是負責任。很多企業導入新工具時，最喜歡做的事情就是「全面啟動」。我們強烈建議不要這麼做。先讓一個 Bot 在你挑選的那個流程上跑一段時間，設定一個明確的驗收標準，例如連續兩週完成率達 95% 以上，或是每週省下多少工時。通過驗收了，再把同樣的方法複製到下一個流程，讓第二個 Bot 上線。

為什麼要這麼謹慎？因為 always-on agent 的失敗模式不是「沒反應」，而是「亂反應」。它會在你沒注意到的時候，用你給它的權限做出你沒預期的動作。OpenBot 的官方文件裡有一句話我們非常認同：「autonomy without observability is just a faster path to an incident」，意思是不具可觀測性的自主，只是通往災難的更快路徑（來源：CopilotKit/OpenBot 官方文件，2026）。單一 Bot 出錯，你還有時間救。十個 Bot 同時出錯，你連哪一個該先關都不知道。

另外，台灣企業還有一個特有的考量：個資法與營業秘密的保護。如果你的流程會碰到客戶個資，例如病歷、保單、帳務資料，你就必須先搞清楚這些資料去了哪裡。Grok Bot 這種商業雲端服務，資料會在 xAI 的伺服器上處理，你能不能接受？OpenBot 與 Hermes Bot Mode 可以自架，資料留在台灣的機房，但你的 IT 團隊有沒有能力維運？這些問題沒有標準答案，只有適不適合。我們不會說開源一定好，也不會說商業方案一定不安全，而是要看你的產業、你的客戶、你的合約要求。

我們在陪伴台灣企業導入時，最常遇到的狀況是：老闆想要一次到位，IT 想要慢慢來，財務想要看到明確的 ROI。這三個角色永遠在拉扯。我們的角色就是擔任翻譯，把老闆的期待翻譯成 IT 能理解的架構，把 IT 的擔憂翻譯成老闆能懂的風險，再把兩者轉換成財務部門能接受的數字。自架、治理稽核、商業訂閱這三條路，分別對應企業的不同技術能力與資料外送接受度。開源在地派適合已有技術團隊、對資料掌控有高度要求的企業；開源治理派適合需要稽核軌跡、身處受監管產業的企業；商業自助派適合想快速驗證、願意把資料交給雲端的團隊。

我們想說的是，這波浪潮真正考驗的不是 AI 的能力，而是企業的決策品質。你敢不敢讓 AI 靠近你的工具，取決於你有沒有先把上面三件事想清楚。想清楚了，AI 是你的同事；想不清楚，AI 只是另一筆帳單。

結論：讓 AI 同事真正接手前，先用三個問題驗收你的第一個 Bot

從 Hermes Bot Mode 的開源在地派、OpenBot 的治理稽核派，到 Grok Bot 的商業自助派，我們把 2026 年這場「給 AI 一台自己的電腦」的浪潮從產品定位、技術架構、治理機制到成本結構，完整攤開來看了一遍。你已經知道三種方案的差異，也理解了企業導入的心理關卡不在 AI 聰不聰明，而在你敢不敢讓它靠近你的工具。

那麼接下來該怎麼做？我們建議你別急著把整套架構搬進公司，先挑一個重複性高、容錯度也高的流程，讓第一個 Bot 實際跑起來，然後用三個問題驗收它。這三個問題不是技術檢測，而是管理判斷。通過驗收，再談擴大；沒通過，就當作一次有價值的試驗。

第一個問題：工作有沒有真的落回真實工具？

最常見的 AI Agent 失敗模式，是「看起來完成、實際上沒做完」。Bot 可能在對話視窗裡回報「已完成」，但你打開 CRM、開啟試算表、檢查電子郵件時，發現資料根本沒進去，流程也沒有往下走。這種落差正是 xAI 產品負責人所強調的，「90% 完成」跟「100% 完成」之間的巨大鴻溝。Grok Bot 的設計哲學就是讓工作落在人會放的地方，落在真實的軟體工具裡，而不是停在 AI 自己的回應中（xAI，2026）。

所以驗收時請打開你原本在用的系統，逐一檢查 Bot 聲稱完成的事項。它說更新了 CRM，就打開那筆客戶紀錄看欄位有沒有填對；它說處理了發票，就去帳務系統看憑證有沒有建檔。別只看它的回報文字，要看真實系統裡的狀態。這個動作很基本，卻能過濾掉七成以上的「假性完成」。

第二個問題：決策過程有沒有留下記錄？

自主性不是最困難的部分，真正困難的是可稽核的自主。OpenBot 的核心論點是，所有動作必須先經過單一閘道，先解析目標、評估政策、寫下稽核紀錄，然後才執行。任何號稱自主、卻無法事後檢驗的 Agent，都只是「有聊天介面的風險」，而不是可靠的同事（CopilotKit，2026）。

我們建議你在導入時就要求 Bot 的平台具備完整的操作日誌，包括它做了什麼、什麼時候做的、用了哪些工具、存取過哪些資料，以及是否發生過需要人工介入的事件。面對受監管的產業，這份紀錄更是必備。如果一個平台連「做了什麼」都說不清楚，那就表示它的成熟度還不夠，別急著讓它碰正式環境。

這裡也提醒你留意記憶體與資料處理的透明度。以 Grok Bot 為例，用戶無法檢視、修正或匯出 Bot 的記憶，這對某些企業來說可能是無法接受的條件。驗收前先確認你對資料的掌控程度，與公司政策相符，才不會事後發現無法交代。

第三個問題：需要人審批的關卡有沒有設好？

AI Agent 不是全自動化，而是人機協作。Grok Bot 在遇到登入牆或雙重驗證時，會停下來把控制權交還給人，這是正確的設計。你的第一個 Bot 必須明確知道哪些動作需要人工授權，例如送出報價、刪除資料、匯出客戶清單、對外發布訊息，這些高風險動作都應該設計成強制暫停，等待真人確認。

驗收時請實際測試它的判斷力。故意給它一個需要審批的任務，觀察它會不會擅自執行，或者有沒有在該停的地方停下來。理想的表現是，它會主動告訴你「這個動作需要你確認，後續的流程我先暫停」，而不是自作主張一路做完。此外，若平台支援多重角色的權限分離，請確實設定好不同帳號的存取範圍，避免任何單一 Bot 擁有過大的權限。

值得一提的是，Bot 協作時的失誤處理設計也該納入檢查。市面上某些平台在 Agent 之間傳遞任務時，只能做到「下次運行才收訊」，無法即時中斷正在進行中的對話（Nous Research，2026）。這表示人仍然是整體流程的調度者，確認你保留這個調度權，而不是反過來被 Bot 的時程綁架。

把驗收結果帶回來，我們陪你跑下一步

三個問題背後的共同精神，是拒絕「看起來完成」的幻覺，要求真實的產出、完整的軌跡、以及明確的界線。你不需要一次到位，只需要一個可驗證的起點。根據 Gartner 的預測，2026 年底將有 40% 的企業應用程式內建任務型 AI Agent，2025 年這個數字還不到 5%（Gartner，2026）。Stanford AI Index 2026 則顯示，Agent 在真實終端機任務的成功率已從前一年的 20% 提升到 77.3%。浪潮已經來了，時間站在願意早點開始驗證的人這邊，但同時，導入的每一步都需要審慎的規畫與衡量成本，尤其是 always-on Agent 的 token 消耗量，務必在啟動前先估算用量，否則月底的帳單會非常可觀。

如果你正在評估 AI Agent 導入，歡迎把第一個驗證流程帶來跟我們討論。公司累積了輔導台灣中小企業數位轉型的經驗，也熟悉開源與商業方案各自的優缺點。我們可以陪你一起釐清，哪個流程適合先跑、哪個環節該留人、以及最重要的，哪個方案真正符合你的預算與風險承受度。

替代方案有限公司的觀點

我們在輔導企業導入 AI 的過程中，最常聽到的一句話是「我們公司沒有那麼多技術人力」。說實話，台灣多數中小企業確實不具備自架開源方案的能力，Docker、PostgreSQL、模型 API 的串接，對一個五人 IT 團隊來說往往已經是沉重的負擔。但這不表示企業只能被商業方案綁住。我們的角色，就是為客戶找出「技術門檻與資料掌控度」之間的平衡點。若客戶身處受高度監管的產業，我們會優先推薦具備完整稽核軌跡的架構，即使這意味著需要投入更多初期建置成本。若客戶想快速驗證流程價值，我們會協助設計小範圍、低風險的試辦專案，用最少的預算換取真實的數據。

我們堅信，AI 導入的成敗關鍵不在工具本身，而在於企業有沒有想清楚「什麼該交給 AI、什麼該留給人」。歷史上的每一次生產力革命，都是因為有人敢於重新劃分人與機器的職責界線，同時也誠實面對成本與風險的現實。不要急著複製別人的成功案例，先找出你自己的第一個驗證流程，跑一次，然後用三個問題檢視它。想清楚了，AI 會是你的同事；想不清楚，它只是另一筆帳單。願你成為前者。

如果你正在做這份評估，或者已經挑好了第一個流程，我們很樂意陪你一起走過驗證階段。來信聊聊，把問題帶到桌面上，我們一起找出最務實的路徑。

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