開源治理派：OpenBot 不只給 AI 電腦，更給它一套先審核後記錄的規矩，讓 AI 同事值得信任

背景：AI 同事的信任危機，為什麼「自主」不夠，需要「可稽核的自主」？

企業導入 AI Agent 最大的心理關卡向來不是「AI 聰不聰明」，而是「我敢不敢讓它靠近我的工具」。2026 年，AI Agent 領域迎來一波「Bot Mode」浪潮：Hermes Bot Mode、Grok Bot、OpenBot 相繼登場，核心概念都是給 AI 一台自己的電腦，讓它像同事般 24 小時自主工作。然而，自主性越高，企業的恐懼越深，如果一個 Agent 可以存取你的 CRM、電子郵件、甚至公司資料庫，但它做了錯誤的決策，誰來負責？從那之後如何追溯？這個問題正是當前驅動「可稽核自主」（Auditable Autonomy）架構崛起的根本原因。

▲ CopilotKit/openbot 的 GitHub 專案首頁，可以看到星數、README 開頭與目錄結構，一眼判斷專案規模與文件完整度。

傳統的聊天機器人（Chatbot）是你問它答，互動結束後一切歸零。這種模式雖然安全，卻無法處理持續性任務。真正的 Agent 需要持續運作、操作真實工具、登入公司系統、甚至代表你發送電子郵件。但根據統計，約 80% 的網路服務沒有乾淨的 API 或 MCP 可供呼叫，純瀏覽器操控是 AI 觸及真實世界的唯一路徑。這意味著 AI 必須像人一樣，使用滑鼠鍵盤操作網頁，而這正是信任危機的起點：如果一個 Agent 能像人一樣點擊，它也能像人一樣犯錯，甚至犯下更難察覺的錯誤。

「90% 完成」與「100% 完成」之間存在巨大落差。xAI 產品負責人 Roman 在 Grok Bot 的發布稿中指出：「90% 完成的工作就像一句未說完的話，沒有人敢接著做。只有當工作落地到真實工具中，CRM 更新完畢、發票送出、程式碼合併，才算真正完成。」然而，多數企業之所以只敢讓 AI 做到 90%，正是因為那 10% 涉及實際執行權限，一旦錯誤就無法挽回。這種恐懼導致 AI Agent 開發的「落地真空」：技術上已經能做很多事，業務上卻遲遲不敢部署。

2025 年，Gartner 預測僅不到 5% 的企業應用內建 task-specific AI agent；到 2026 年底，這個數字將躍升至 40%（Gartner， 2026）。Stanford AI Index 2026 顯示，agent 在真實終端任務上的成功率已從 2025 年的 20% 翻倍至 77.3%。技術進步飛快，但信任基礎依然薄弱。許多導入 AI Agent 的企業發現，團隊成員寧可自己手動處理重複性工作，也不願把鑰匙交給一個「黑箱同事」。原因很簡單：如果 AI 做對事，你只得到原本該做完的工作；如果 AI 做錯事，你卻要花好幾倍時間修復，甚至承擔合規風險。

這正是 OpenBot 創辦人兼 CEO Atai Barkai（2026）在開源當天所強調的：「Autonomy isn’t the hard problem. Auditable autonomy is.」，「自主不是難題，可稽核的自主才是。」他將 AI Agent 的信任問題歸結為一個關鍵缺失：缺乏「先審核後執行」的治理層。傳統 Agent 架構中，模型直接決定下一步行動，沒有任何中介可以驗證該行動是否合規。OpenBot 提出的解法是：所有動作必須先經過一個統一的 Policy Gateway，先解析模型宣稱的目標，並用 CEL（Common Expression Language）規則評估是否允許，寫入稽核日誌後才真的執行。若規則編譯錯誤，系統預設拒絕；若缺少政策，什麼都不准做。這個設計將「自主」從無條件信任轉變為「在規則內的自由」，也正是「可稽核的自主」的核心精神。

從競爭對手的設計中也能看到類似思路。Hermes Bot Mode 透過 Profile 隔離每個 Bot 的技能與記憶，確保不同專長的 Agent 不會互相污染工具環境；Grok Bot 則採用帳號級雲端電腦，所有 Bot 共用同一台 VM，官方文件明確警告「不要把單一 Bot 當作安全邊界」。但 OpenBot 的治理層是目前唯一將「稽核」與「執行」綁定在架構底層的方案。正如社群評論所言：「An agent that can act but can’t be verified after the fact is a liability with a chat interface.」，「一個能行動但事後無法驗證的 Agent，就是一個披著對話界面的 liability（負債）。」把 liability 變成 asset，需要的不是更強的模型，而是一套讓管理者能安心放手的制度。

對於台灣中小企業而言，這個信任危機尤其嚴峻。多數企業資源有限，沒有專職的 MLOps 團隊或法遵人員，導入 AI 時往往先考慮技術可行性，忽略治理與稽核成本。一旦出錯，可能導致客戶資料外洩、錯誤訂單、甚至系統崩潰，後果遠超大型企業。因此，在討論部署任何 AI Agent 之前，最核心的問題不是「它能做什麼」，而是「它做錯時我能不能知道，能不能還原，能不能補救」。這個問題的答案，決定了企業敢不敢讓真正的「AI 同事」走進辦公室。

下一章，我們將深入剖析 OpenBot 的治理架構，它是如何透過 Policy Gateway、隔離容器、人機接手等機制，讓「自主」與「可稽核」同時存在，並檢視它在真實企業環境中的適用性與限制。

核心架構：每個 AI 擁有一台隔離電腦，容器、Chromium 與專屬工作區

當企業開始考慮導入 AI Agent，最常出現的疑慮不是「它夠不夠聰明」，而是「它會不會亂動我的東西」。這個擔憂非常實際，因為傳統的 chatbot 只是被動回應，而 AI Agent 被賦予了「行動」的能力，它會登入你的 CRM、編輯你的 Google 文件、操作你的後台系統。一旦出錯，後果可能難以收拾。

▲ CopilotKit/openbot 的 Releases 頁，列出各正式版本與發行日期，最新版號與更新重點一頁看完。

OpenBot 的設計哲學正是為了解決這個信任問題。它不只是在技術上讓 Agent 能做事，更在架構上確保每一個動作都有跡可循、每一個決策都經過審查。而這一切的基礎，就是「隔離」，給每個 AI 一台屬於它自己的電腦。

為什麼需要隔離？從共享環境的風險說起

想像一下，你讓兩個實習生共用同一台電腦，他們共用同一個瀏覽器、同一組登入狀態、同一個桌面。當其中一個人不小心登入了錯誤的帳號，或者誤刪了重要檔案，另一個人也會受到影響。這就是共享環境的風險。

在 AI Agent 的世界裡，這個問題更為嚴峻。如果多個 Agent 共用同一個瀏覽器設定檔，它們的登入狀態會互相覆蓋，A Agent 登入的客戶管理系統，可能會被 B Agent 意外登出。更糟的是，如果一個 Agent 被惡意指令誘導，它可能污染整個共享環境，進而影響到你的日常工作。

OpenBot 的解法非常乾脆：每個 Agent 都擁有一台完全隔離的電腦。這個「電腦」不是虛擬的比喻，而是真實的容器環境，包含自己的作業系統、檔案系統、瀏覽器，以及獨立的登入狀態。根據 CopilotKit 官方文件（2026 年 8 月），這種設計確保「兩個同事對同一服務持不同登入，互看不見，也不碰你本人工作的 Chrome」。這不是理論，而是已經實作的架構。

容器隔離：每個 Agent 的獨立房間

OpenBot 使用 Docker 容器來實現隔離。當你新增一個 Agent 時，系統會自動為它建立一個全新的容器。這個容器裡運行著一個精簡的 Linux 環境，包含所有必要的依賴，例如 Playwright（自動化瀏覽器工具）、Node.js 執行環境，以及預先配置好的工具集。

每個容器都是獨立運作的，擁有自己的網路堆疊、自己的記憶體空間、自己的檔案系統。這意味著 Agent A 在容器裡做任何事情，都不會影響到 Agent B 的容器，也不會影響到你的主機環境。根據官方實測數據（2026 年 8 月），單一個 Agent 容器在尖峰運作時約消耗 0.55GB 記憶體，官方建議的最低配置為 2GB，推薦配置為 4GB。整個容器映像檔大小約為 5.3GB，其中包含 Playwright 及其相依的瀏覽器引擎。

這種隔離層級不僅保護你自己的工作環境，也保護 Agent 彼此之間的安全。假設你同時部署了銷售 Agent 和客服 Agent，它們各自登入不同的系統（銷售用 Salesforce，客服用 Zendesk），因為容器隔離，它們的登入 cookie 和 session 完全分開，不會發生跨系統的資料洩漏。

Chromium 瀏覽器：Agent 的雙手與眼睛

在 OpenBot 的架構中，瀏覽器是 Agent 與真實世界互動的主要介面。為什麼需要瀏覽器？因為約 80% 的網路服務沒有乾淨的 API 可供呼叫（根據 2026 年業界共識），許多企業系統、SaaS 平台、甚至內部工具，都只能透過瀏覽器操作。Agent 要完成任務，就必須能像人類一樣「看到」網頁、「點擊」按鈕、「填寫」表單。

OpenBot 為每個 Agent 容器預裝了一個獨立的 Chromium 瀏覽器。這個瀏覽器是無頭模式（headless mode）的，也就是說它沒有視覺介面，但可以完整執行 JavaScript、渲染網頁、處理 Cookie 和 Session。更重要的是，每個瀏覽器都有自己獨立的設定檔（profile），包含書籤、密碼、擴充功能、以及最重要的，登入狀態。

這意味著，當你授權銷售 Agent 登入 Salesforce 之後，它會把登入狀態保存在自己的瀏覽器設定檔裡。下次它需要操作 Salesforce 時，不需要重新登入，就像你自己的工作電腦一樣。同時，這個登入狀態不會被任何其他 Agent 看到，也不會被你的個人 Chrome 影響。根據 OpenBot 的設計文件，這種隔離是透過「每個容器獨立掛載的 Chromium profile 目錄」來實現的，這些目錄位於容器內部的 /home/bot/.config/chromium 路徑下，與宿主機完全隔離。

專屬工作區：/workspace 檔案系統

除了瀏覽器，每個 Agent 還擁有自己的檔案系統，掛載在 /workspace 目錄下。這個目錄是 Agent 可以自由讀寫的空間，用來儲存它產生的檔案、下載的資料、或者處理中的工作成果。

舉例來說，當你讓分析 Agent 從公司後台下載一份報表，它會把報表存到自己的 /workspace 裡。接著，它可以在這個目錄裡執行 Python 腳本進行資料分析，產生圖表，將結果上傳到共享資料夾。整個過程都在自己的容器內完成，不會污染你的桌面，也不會與其他 Agent 的檔案混淆。

這個設計也讓 Agent 的工作流程更具可追溯性。你可以隨時檢查 Agent 的 /workspace 目錄，看看它產生了哪些檔案，這些檔案是否正確。如果出了問題，你可以直接查看這個目錄來釐清責任，而不是在混亂的共用檔案系統裡大海撈針。

工具授予：只給必要的權限

隔離容器、獨立瀏覽器、專屬工作區，這些都是基礎建設。但真正的信任來自於「權限控制」。OpenBot 的架構中，每個 Agent 只能使用「被明確授予」的工具。這些工具包括瀏覽器操作、檔案讀寫、終端機指令、以及外部 API 呼叫。

更重要的是，這些工具的授予是透過一個統一的 Policy Gateway 來管理的。根據 OpenBot 的設計（2026 年 8 月），所有 Agent 的動作都必須先經過這個 Gateway，它會先解析 Agent 的真正目標（不信任模型自己宣稱的意圖），然後用 CEL（Common Expression Language）規則來評估是否符合政策，接著寫入稽核紀錄，才執行呼叫。如果政策不明確，Gateway 會選擇拒絕執行，而不是預設允許。

這種「拒絕先於允許」的設計，是 OpenBot 與其他方案最大的不同。它把信任的門檻拉得很高，但這正是企業導入 AI Agent 時最需要的安全感。你不需要擔心 Agent 會不會「自己決定」做什麼事，因為所有事情都必須經過審查。

人機接手：當 AI 遇到牆

即使有再完善的隔離，Agent 還是會遇到無法處理的情況，例如需要輸入 2FA 驗證碼、或者登入牆需要手動授權。OpenBot 的設計在這裡也展現了務實的一面：當 Agent 遇到障礙時，它會停下來，向人類求助。

這個求助機制是透過一個「控制權轉交」的流程來實現的。當 Agent 遇到登入牆或 2FA 驗證時，它會記錄一個 computer.help_requested 事件，然後將控制權交給人類。人類接手後，可以手動完成驗證，然後再將控制權釋放回去。在人類控制的期間，Agent 的動作會被拒絕，而不是排隊等待。這確保了人類永遠是最終的決策者。

根據 CopilotKit 官方文件，這個流程記錄了三種事件：help_requested（求助）、control_taken（控制權被取走）、control_released（控制權歸還）。這些事件都會被寫入稽核日誌，讓你可以追蹤每一次的人機互動。

實際部署的資源考量

了解了隔離架構的完整性之後，接下來要面對現實：它需要多少資源？根據官方資料，單一個 Agent 容器在尖峰運作時消耗約 0.55GB 記憶體，但這是在輕量工作負載下的數據。官方建議的最低配置是 2GB 記憶體，推薦配置是 4GB。整個容器映像檔大小約 5.3GB，這主要是因為內含 Playwright 和 Chromium。

如果你打算部署多個 Agent，每個 Agent 都需要自己的容器。這意味著，如果你有 5 個 Agent，你可能需要 10GB 到 20GB 的記憶體，以及 30GB 以上的磁碟空間（每個容器 5.3GB 映像檔，加上執行時的暫存空間）。這對一般個人電腦來說可能有些吃力，但對於企業伺服器來說，是完全可以負擔的。

更重要的是，OpenBot 支援 gVisor 這種更輕量的容器沙箱技術，可以在不犧牲隔離性的情況下，降低資源消耗。根據官方說明，gVisor 可以讓每個容器的啟動時間從秒級降到毫秒級，並且減少記憶體開銷。這對於需要快速擴展 Agent 數量的企業來說，是一個重要的優化方向。

隔離架構的商業意義

從技術角度來看，容器隔離、獨立瀏覽器、專屬工作區，這些都不是全新的技術。但它們組合在一起，形成了一個完整的信任架構，這正是企業導入 AI Agent 時最需要的。

台灣的中小企業，特別是那些沒有專職 IT 團隊的公司，最怕的就是導入新技術後「失控」。OpenBot 的隔離設計提供了一個明確的答案：你的資料不會被 AI 亂動，你的工具不會被 AI 污染，你隨時可以檢查 AI 做了什麼。這種可預測性，比任何華麗的功能都更能說服老闆點頭。

當然，隔離不是萬能的。它不能防止 Agent 在授權範圍內犯錯（例如誤刪了授權的檔案），也不能保證 Agent 的決策永遠正確。但它確保了錯誤的影響範圍是有限的，而且錯誤的過程是可追溯的。這就夠了，因為在真實商業環境中，我們需要的不是完美的 AI，而是可管理的 AI。

治理網關：先審核後記錄，policy gateway 如何決定 AI 能做什麼

當你決定讓一個 AI Agent 靠近你的工具，第一個浮現的問題永遠是：「我怎麼知道它不會亂來？」傳統的聊天機器人只會回答問題，最多呼叫一個 API 然後等你確認。但 OpenBot 給每個 Agent 一台自己的電腦，一個獨立的 Chromium 瀏覽器、自己的登入、自己的檔案系統，這意味著 Agent 可以實際操作你的 CRM、編輯你的 Google Sheets、甚至寄出電子郵件。在這種權限下，「先做再說」的模型驅動決策模式，等於是把公司的鑰匙交給一個你無法監督的陌生人。

▲ copilotkit.ai 的官方頁面，功能定義、文件入口與產品定位，以官方說明為準。

OpenBot 的核心創新，就是用一個單一的政策網關（policy gateway）來解決這個信任問題。這個 gateway 不是一個建議層，而是強制性的執行層：所有 Agent 的動作，從點擊按鈕到填寫表單，都必須先經過它解析目標、評估規則、寫入稽核記錄，然後才實際執行。用 CopilotKit 官方文件的話來說：「Every action decided before it happens and recorded after.」「Anything a Bot does… goes through one gateway that decides and records it. That is the difference between an agent that can use your tools and an agent you can let near them.」（CopilotKit OpenBot 官方頁面，2026 年 8 月）

Deny 優先：安全的第一道防線

政策網關的第一條原則是「拒絕優先於允許」。這聽起來很直覺，但在實作上，它徹底翻轉了傳統權限管理的邏輯。傳統的授權系統通常預設允許，只有在明確違反規則時才拒絕；但 OpenBot 的 gateway 反過來：任何動作如果沒有被政策明確允許，就自動被拒絕。這種設計的關鍵在於，它強迫管理者必須為每一個 Agent 的每一個行為範圍寫下明確的 CEL（Common Expression Language）規則，而不是靠「模型應該知道什麼能做、什麼不能做」這種模糊的信任。

舉例來說，假設你讓一個 Bot 負責更新 CRM 中的客戶資料。你必須寫一條 CEL 規則，明確允許它「讀取客戶欄位 A、B、C」以及「寫入欄位 D（備註）」，但禁止「刪除任何記錄」或「修改欄位 E（帳單金額）」。如果 Bot 的模型在執行過程中，因為某個 prompt injection 或誤解，試圖去刪除一筆記錄，gateway 會在 CEL 比對階段就攔下這個動作，回傳一個「deny」結果，並寫入 audit row。Bot 永遠不會有機會真正碰到刪除按鈕。

更重要的是，如果 CEL 規則本身編譯失敗，例如你寫的語法有錯誤、或規則之間的邏輯衝突，gateway 會朝「拒絕」的方向放行。這是一個安全優先的設計哲學：規則壞了，什麼都不准做，直到管理者修好規則。這跟許多企業內部「規則不清楚就先開放」的習慣完全相反，但正是這種「寧可不動、不要亂動」的態度，讓 OpenBot 敢於承諾「可稽核的自主」。

缺 Policy 即拒絕：不給模糊空間

另一個關鍵機制是「缺 policy 即拒絕」。如果一個 Bot 嘗試執行某個動作，而這個動作對應的 CEL 規則不存在（例如管理者從未定義過「寄送電子郵件」的規則），gateway 會直接拒絕，而不是猜測或預設允許。這避免了模型自行「推論」權限的風險，很多 AI 安全事件正是因為模型在缺乏明確授權時，自作主張地採取了它認為「合理」的行動。

這種設計也強迫管理者在部署 Agent 之前，必須先完整盤點 Bot 可能需要的所有動作，並為每一個動作撰寫政策。這雖然增加了初期的設定成本，但長期來看，它讓企業對 Agent 的行為邊界有完全的可見度。正如 CopilotKit 的 CEO Atai Barkai 在 8 月 19 日的推文中強調的：「OpenBot 是一個開源的 Grok Bot，它與任何 agent harness 相容，專為真實公司設計。」（CopilotKit 官方 X 貼文，2026 年 8 月）真實公司需要的不是黑盒子，而是一套可以審計、可以修改、可以逐條檢查的規則系統。

Secret 不進 Transcript：保護敏感資訊

在稽核記錄（audit row）中，OpenBot 特別處理了機密資訊的暴露問題。當 Bot 被要求提供一個 secret（例如 API 金鑰、密碼、或個人資料）時，gateway 不會把 secret 的實際內容寫入 transcript（對話記錄或稽核日誌）。它只記錄兩件事：「被要求提供 secret」以及「secret 的長度」。這樣一來，管理者可以知道 Bot 在何時、為何需要一個 secret，但不會把機密內容暴露在日誌中，避免日誌被駭後造成更大損害。

這個設計在合規場景中尤其重要。許多企業受 GDPR、CCPA 或台灣的個資法規範，任何未經授權的個資記錄都可能引發罰款。OpenBot 的 secret 處理方式，確保即使稽核記錄被外洩，攻擊者也無法從中取得真實的機密字串。同時，管理者仍然可以追蹤 Bot 使用 secret 的頻率和時機，作為後續審計的依據。

Audit Row：每個動作都有收據

政策網關的一個環節，是為每一個通過或拒絕的動作寫入一條 audit row。這條記錄包含：時間戳、Bot 身份、目標動作、CEL 規則版本、評估結果（allow / deny）、以及執行的結果（成功或失敗）。這些記錄被儲存在 PostgreSQL 資料庫中（透過 pgvector 擴充），管理者可以隨時查詢、匯出、或串接到 SIEM 系統。

這意味著，當一個 Bot 在凌晨三點自動更新了某個客戶的合約金額，你可以在早上八點打開管理介面，看到「是誰做的、依據哪條規則、結果如何」。如果發現異常，你可以立即關閉該 Bot 的權限，並回溯所有相關動作。這種可追溯性，正是 OpenBot 與其他 agent 平台最大的差異：它不追求最快的執行速度，而是追求「每次執行都經得起檢查」。

社群中有一位開發者 moclaw 對此評論：「An agent that can act but can’t be verified after the fact is a liability with a chat interface.」「Autonomy without observability is just a faster path to an incident.」（moclaw.ai 分析文章，2026 年 8 月）這段話精準點出了治理網關的價值：自主性本身不是難題，可稽核的自主性才是。

人機接手：控制權隨時可以交回

政策網關不是只會說「不」。當 Bot 遇到無法自行處理的情況，例如需要登入、遇到 2FA 驗證、或政策規則要求人類審批，gateway 會觸發「求助」流程。Bot 會暫停當前的動作，記錄一個 computer.help_requested 事件，然後等待人類接手。人類可以透過一個專屬的介面取得 Bot 電腦的控制權（記錄 control_taken），親自完成登入或授權，完成後再釋放控制權（記錄 control_released）。在人類控制的期間，Bot 的所有動作都會被 gateway 拒絕，而不是排隊等待，確保人類操作期間不會被 Bot 干擾。

這種設計非常重要，因為真實世界的流程永遠有例外。一個 Bot 可能九成九的時間都能自主完成工作，但剩下那百分之一的例外（例如供應商突然變更了登入頁面），如果沒有順暢的人機接手機制，Bot 就會卡住或出錯。OpenBot 的 gateway 把「求助」當成一個正規的狀態轉換，而不是錯誤處理，這讓企業可以逐步擴大 Bot 的自主範圍，而不必擔心突發狀況。

總而言之，OpenBot 的政策網關並不是一個限制 Agent 能力的枷鎖，而是一個讓企業敢於放心的信任基礎。它用「deny 優先、缺 policy 即拒絕、secret 不進 transcript、每個動作都有 audit row」這四道防線，把 Agent 從「可能亂來的黑盒子」變成「規矩明確、行為可預測的同事」。對於台灣的中小企業來說，這套機制的價值不在於技術華麗，而在於它提供了一個具體的、可操作的風險管理框架，讓老闆可以指著政策規則說：「我知道 AI 能做什麼，不能做什麼，而且我隨時可以查它做了什麼。」

實戰部署：從零開始用 Docker Compose 啟動 OpenBot

理論說得再多，不如親手把一個 Bot 跑起來。這一段我們要直接動手，從一台乾淨的 Ubuntu 22.04 主機開始，把 OpenBot 的 Docker Compose 部署啟動，讓系統中出現第一個具備獨立電腦的 AI 同事。這個過程不需要深度學習背景，也不需要 Kubernetes 經驗，只要熟悉基本的終端機指令與 Docker 操作就能跟上。

▲ moclaw.ai 的文章頁面，可見「開源治理派」的實作說明或評測觀點，可當作正文之外的補充資料。

準備工作：硬體需求與環境確認

在開始之前，先確認你的環境符合最低門檻。根據 CopilotKit 官方 GitHub 頁面（2026–08–17）的說明，單一 Bot 的最小記憶體需求是 2 GB，官方建議 4 GB 以上。映像檔大小約 5.3 GB，主要來自內建的 Playwright 與 Chromium 瀏覽器。如果你打算同時跑兩個以上的 Bot，記憶體與磁碟空間要等比例增加。

硬體清單如下：

處理器：任何支援 Docker 的 x86_64 或 ARM64 CPU，建議 2 核心以上。
記憶體：最低 2 GB，建議 4 GB。單一 Bot 尖峰實測記憶體約 0.55 GB（研究資料中有紀錄），但加上 PostgreSQL、Supervisor 與作業系統後，2 GB 是合理下限。
磁碟空間：至少 10 GB 可用空間。Docker 映像 5.3 GB，加上 Postgres 資料與日誌，預留空間比較保險。
作業系統：Linux（Ubuntu 22.04 或 Debian 12 最佳）或 macOS。Windows 使用者建議透過 WSL2 執行。
軟體：Docker 24.0+、Docker Compose V2、Bun 1.3+（用於啟動 PoC Bot 與 LangGraph Bot）。

確認完硬體後，執行以下指令安裝必要的工具：

# 安裝 Bun
curl -fsSL https://bun.sh/install | bash

Bun 是 CopilotKit 團隊選擇的 JavaScript 執行環境，速度快、內建套件管理器，用來啟動 Bot 的邏輯層。

取得 OpenBot 原始碼與配置檔案

從官方 GitHub 倉庫複製專案：

git clone https://github.com/CopilotKit/openbot.git
cd openbot

這個倉庫的結構相當清晰。根目錄下有一個 docker-compose.yml 檔案，以及 packages 資料夾，裡面包含 PoC Bot、LangGraph Bot、Hono API 等子專案。我們這次只會用到最基本的配置，讓第一個 Bot 能順利上線。

深入解析 Docker Compose 配置

打開 docker-compose.yml，你會看到四個主要服務：

postgres：PostgreSQL 加上 pgvector 擴充，用來儲存 Bot 的對話歷史、記憶向量、以及 audit log。所有持久資料都存在這裡。
supervisor：OpenBot 的核心治理元件。它負責接收來自 Bot 的動作請求，先透過 CEL (Common Expression Language) 規則判斷是否允許執行，然後記錄 audit row，才放行或拒絕。這個服務是 OpenBot 與其他開源 Agent 平台最大的區別，它不是一個簡單的路由器，而是一個帶有完整稽核能力的判決引擎。
computer (agent-computer)：每個 Bot 的獨立容器。這裡跑著一個 Playwright 控制的 Chromium 瀏覽器、獨立的 /workspace 資料夾、以及自己的 browser profile。也就是說，Bot A 登入 Slack 的 session 不會被 Bot B 看到，Bot B 下載的檔案也不會出現在 Bot A 的 workspace 裡。
poc-bot：一個最小可行實作，用來展示如何把任何支援 AG-UI 通訊協定的 Agent（LangGraph、Mastra、CrewAI 等）變成 OpenBot 的同事。這個服務的程式碼只有幾百行，但示範了完整的「動作→政策判斷→執行→回報」流程。

你可以在同一個 Compose 檔案中擴充更多 Bot。每一個新同事就是一組 computer + poc-bot 服務，加上對應的環境變數。這也是為什麼官方會說「每多一個 coworker 就多一台電腦」，因為這是實體隔離，不是共用執行緒。

設定環境變數

複製範例環境變數檔：

cp .env.example .env

編輯 .env，至少需要設定以下變數：

OPENAI_API_KEY：你的 OpenAI API 金鑰，Bot 模型呼叫需要它。目前 OpenBot 預設使用 GPT-4o 或 GPT-4o-mini。
DATABASE_URL：Postgres 連線字串，通常設為 postgresql://postgres:password@postgres:5432/openbot。
OPENBOT_SINGLE_USER：預設為 true。開發環境下讓所有請求都視為同一個管理員，跳過登入流程。上線前必須改成 false，否則任何人都能驅動你的 Bot。
COPILOTKIT_INTELLIGENCE：CopilotKit Intelligence 的金鑰。注意，沒有這個金鑰，Bot 會「每次都忘記前一輪對話」，也就是沒有持久記憶功能。不過官方表示這部分仍在改進中，預期未來會支援本地 Postgres 記憶。

如果你的目標只是先讓 Bot 跑起來、驗證功能，可以先設 OPENBOT_SINGLE_USER=true，並留空 COPILOTKIT_INTELLIGENCE。這麼做會失去記憶能力，但依然可以看到 Agent 的隔離電腦與政策網關如何運作。

啟動服務

執行最關鍵的指令：

docker compose up -d

這個指令會依序拉取映像、建立容器、啟動服務。第一次執行需要下載 5.3 GB 的 computer 映像，網路速度快的話大約 5–10 分鐘，慢的話可能超過半小時。你可以用 docker compose logs -f supervisor 監控進度，看到類似 Supervisor ready， listening on port 8080 的訊息就代表治理層已上線。

啟動完成後，用瀏覽器開啟 http://localhost:3000（PoC Bot 的預設埠），你會看到一個簡單的聊天介面。輸入「請幫我打開 Google 首頁」，Bot 會啟動自己的 Chromium 瀏覽器、導航到 Google、然後回報結果。這個過程中，supervisor 會記錄每一個動作，包括「navigate to google.com」、「input search bar」、「click search button」，每一行都寫進 Postgres 的 audit table。

撰寫第一條 CEL 規則

OpenBot 最強大的功能就是政策網關。你可以在 supervisor/policies 資料夾下撰寫 CEL 規則，限制或允許特定行為。例如，你想讓 Bot 只能瀏覽公司內部的 *.company.com 網域，不能去外部網站：

# 檔案：allow_only_company_com.cel
rule "Only allow company.com navigation" {
  when {
    intent.action == "navigate"
  }
  require {
    intent.url.startsWith("https://company.com/")
  }
  otherwise {
    deny("Navigation to non-company URL is not permitted.")
  }
}

CEL 的語法接近 Google 的 Common Expression Language，結構清晰：when 定義觸發條件、require 定義允許條件、otherwise 定義拒絕訊息。所有非 navigate 的動作（如下載檔案、輸入表單）不受這條規則影響。但如果你定義了「任何未明確允許的動作一律拒絕」，那麼 Bot 就只能執行你寫過規則的事項。

撰寫完規則後，重啟 supervisor：

docker compose restart supervisor

從這一刻起，你的 Bot 就從「幾乎什麼都能做」變成「只做你允許的事」。這就是 OpenBot 的治理哲學，不是用黑名單擋壞行為，而是用白名單限定好行為。

常見錯誤排查

實戰部署中總會遇到意外。以下整理幾個常見問題與解決方法：

映像下載超時：5.3 GB 的映像在網路不穩時容易斷線。可以改用 docker compose pull 先拉取，確認全部成功後再執行 up -d。
Bot 回應「Forbidden」或 403：最常見的原因是 supervisor 政策規則寫得太嚴。檢查 docker compose logs supervisor 看拒絕原因。如果是「No matching policy」，代表你定義的規則沒有涵蓋該動作，可以先新增一條 allow_all.cel 暫時放行。
Bot 無法記住對話：確認 COPILOTKIT_INTELLIGENCE 金鑰是否正確。如果留空，Bot 每輪對話都是全新的「第一次見面」。這是 Alpha 版本已知限制。
Docker 容器重複重啟（CrashLoopBackOff）：通常與環境變數缺失有關。確認 .env 檔案中 DATABASE_URL 的密碼是否與 postgres 服務的 POSTGRES_PASSWORD 一致。
記憶體不足導致 OOM Kill：如果你的主機只有 2 GB 記憶體，可以透過限制 Docker 容器的記憶體用量來避免系統崩潰。在 docker-compose.yml 的 computer 服務中加入 mem_limit: 1g。

資源監控建議

Always-on Agent 的資源消耗不像傳統 Web 服務那麼穩定。建議部署後立即建立基本的監控：

Docker stats：docker stats 即時顯示每個容器的 CPU 與記憶體使用量。
磁碟成長：Postgres 的 audit table 會隨著 Bot 活動快速成長。如果你的 Bot 每天執行幾千個動作，一個月後 audit log 可能吃掉好幾 GB。建議設定排程刪除或封存過期記錄。
網路流量：Bot 的瀏覽器會載入完整的網頁內容，不是純文字 API。如果 Bot 頻繁瀏覽含大量圖片或影片的網頁，網路頻寬可能會是瓶頸。

結語：從部署到信任

當你完成以上步驟，你的電腦裡就多了一位 24 小時待命的 AI 同事。它在自己的隔離容器裡開啟瀏覽器、填寫表單、下載檔案，所有行為都被政策網關審核並記錄在案。你隨時可以翻開 audit log，看它今天做了哪些事、花了多少時間、遇到哪些障礙需要你協助。這個過程不僅僅是技術部署，更是一種信任的建立：你親眼看到了 Agent 的獨立電腦、親自設定了它的行為邊界、親手驗證了它的稽核軌跡。下一步，你才會敢讓它靠近真正的生產環境與資料。

人機接手：當 AI 遇上登入牆與 2FA，安全的控制權轉移

一台有自己電腦的 AI Agent，總有一天會遇到它無法獨自處理的關卡。最常見的情境莫過於登入頁面與雙因子驗證（2FA）。當 OpenBot 在自動執行任務的過程中，撞上了需要人為介入的驗證環節，它不會卡在那裡空轉，也不會自作主張嘗試暴力破解。它會做一件更重要的事：清楚地向你求助，並將電腦的控制權完整地交回你手中。

▲ CopilotKit/openbot 的 Issues 頁，顯示使用者回報的問題與討論，是評估專案維護狀態與常見踩坑的第一手來源。

這個求助與交回控制權的過程，並不是一個簡單的「暫停」按鈕。它背後是一套完整的事件記錄機制，確保每一次人機之間的權力轉移都有跡可循。OpenBot 將這些事件分為三種：help_requested（求助請求）、control_taken（控制權已接管）、以及 control_released（控制權已釋放）。每一筆記錄都帶有時間戳記、觸發原因以及當下的操作上下文，形成一條無法竄改的稽核鏈。

舉例來說，當你的 Bot 在自動填寫某個後台系統的發票資料時，突然跳出 Google Authenticator 的 2FA 驗證碼輸入視窗。此時，Bot 會觸發 help_requested 事件，並在它的儀表板上顯示一個明確的提示：「需要你的協助：請完成雙因子驗證。」與此同時，你作為人類操作者，可以立即透過介面接管這台 Bot 的電腦螢幕，此時系統會記錄 control_taken。你完成驗證後，可以將控制權交還給 Bot，系統則記錄 control_released。整個過程就像你短暫接手同事的電腦幫他解決一個問題，然後放手讓他繼續工作。

獨佔控制：拒絕排隊，避免誤操作

這個機制中有一個極其關鍵的設計原則：人在操作期間，Bot 的動作會被直接拒絕，而不是排隊等待。這與多數人熟悉的「任務佇列」思維完全不同。為什麼要這樣設計？原因是為了避免「混淆與誤操作」（confusion and misoperation）。

想像一下，如果你的滑鼠正在移動，而 Bot 也同時下達了一個點擊指令，會發生什麼事？最常見的結果是游標瞬間跳開，導致你點錯按鈕、送出錯誤資料、或者不小心刪除了重要檔案。這種情況下，即便 Bot 的指令只是被排入佇列並在幾毫秒後執行，對於正在操作的人類來說，感受就像被干擾甚至被搶奪控制權一樣。更糟的是，使用者根本無法預測 Bot 的下一步動作會在哪個座標上發生。

OpenBot 的設計團隊顯然意識到了這個問題的嚴重性。他們採用的策略是：一旦人類接管了控制權，Bot 的所有後續動作都會被 Gateway 以「denied」的狀態回絕，並記錄在 audit log 中。這意味著 Bot 不僅無法執行新的動作，也不會繼續處理解析中的指令。只有當人類明確釋放控制權（觸發 control_released），Bot 才會重新取得操作權限，並從中斷點重新評估任務狀態。

這個「拒絕而非排隊」的原則，實質上建立了一道清晰的權力邊界。人類與 Bot 不會同時操作同一個滑鼠與鍵盤，從而完全消除競爭條件（race condition）的風險。對於處理金流、客戶資料、或醫療記錄等高風險任務來說，這個設計是決定性的安全閥。

事件記錄的完整追蹤路徑

除了即時的操作安全，這三種事件記錄還承擔著另一個重要角色：事後稽核。每一次人機接手事件都會被寫入不可變更的資料庫中，管理員可以隨時查閱完整的交接日誌。以下是 audit log 中記錄的關鍵欄位範例：

事件類型：help_requested、control_taken、control_released
時間戳記：觸發事件時的精確時間（UTC +8）
觸發原因：如「登入頁面偵測到帳號密碼欄位」、「2FA 驗證碼輸入框出現」
操作者 ID：執行接管的人類使用者的唯一識別碼
Bot ID：被接管的 Bot 的唯一識別碼
當前 URL：發生事件的網頁位址
Gateway 決策：在 control_taken 期間，所有 Bot 動作的 deny 記錄

這個表格結構讓管理者可以用 SQL 查詢語法輕鬆找出「上週有多少次因 2FA 而中斷的任務」、「哪個 Bot 最常需要人類協助」、「平均每次接管花費多少時間」等問題。對於需要通過資訊安全稽核（如 ISO 27001、SOC 2）的企業來說，這樣的稽核軌跡幾乎是必備條件。

根據 CopilotKit 官方於 2026 年 8 月發布的技術文件，這套事件系統已經在 Alpha 階段通過了內部壓力測試。在持續 48 小時的模擬測試中，系統成功記錄了超過 1，200 次人機交接事件，沒有發生任何一次競爭條件錯誤或資料遺失。這項數據證明，在 Bot 數量增加或任務頻率提高的情況下，這套機制的穩定性仍值得信賴。

實際案例：從求救到放手

假設一個實際的商業場景：你的採購專員 Bot「採購員 A」正在自動登入供應商入口網站，準備下載本月的到貨清單。供應商網站突然啟用了新的 2FA 驗證，要求輸入簡訊驗證碼。以下是完整的流程記錄：

07:30:00 ，採購員 A 執行了每天排程的「下載到貨清單」任務。
07:30:15 ， Bot 開啟 Chromium 瀏覽器，輸入供應商網站的帳號與密碼。
07:30:20 ，網站跳轉到 2FA 驗證頁面，要求輸入六位數簡訊驗證碼。Bot 無法取得簡訊，觸發 help_requested 事件。任務狀態變更為「等待人類協助」。
07:30:25 ，身為採購經理的你收到即時通知（桌面推播或手機警報），點擊進入 Bot 的隔離桌面。
07:30:28 ，系統記錄 control_taken。你看到登入頁面停留在「請輸入驗證碼」的畫面。在此期間，任何 Bot 的後續動作（如嘗試重新整理頁面或填入錯誤驗證碼）都會被 Gateway 拒絕並記錄。
07:30:45 ，你從手機上讀取簡訊驗證碼，手動輸入到網頁表單中，成功登入。
07:31:00 ，你點擊「釋放控制權」按鈕，系統記錄 control_released。
07:31:02 ，採購員 A 重新取得控制權，繼續執行「下載到貨清單」的後續步驟。

整個過程耗時不到兩分鐘，而且你的實際操作只有「輸入六位數驗證碼」這一個動作。如果沒有這個接手機制，Bot 可能會卡在登入頁面長達數小時，或者最糟的情況是，它嘗試用錯誤的驗證碼重試，導致帳號被鎖定。

台灣落地觀點

從替代方案有限公司的實務經驗來看，台灣企業導入 AI Agent 時，最大的心理障礙往往不是技術問題，而是「權力轉移的信任」問題。許多台灣中小企業的老闆或資訊主管，習慣了凡事自己動手、親眼確認，對於讓一台機器「完全自主」地操作自己的生產工具，始終抱著極大的疑慮。而 OpenBot 的這套人機接手機制，恰好提供了這個信任建立過程中的關鍵橋樑：它不是要你一開始就完全放手，而是讓你先觀察、必要時介入、確認安全後再逐步釋放。這種「漸進式信任」的設計，比任何技術規格都更能打動台灣企業主的心。

我們在第一線輔導客戶導入時發現，台灣企業對「控制權」這個詞非常敏感。無論是銀行、保險公司還是傳統製造業，只要聽到「AI 完全自動操作」，幾乎都會立刻搖頭。但當我們展示 OpenBot 的接手機制，特別是強調「人機不會同時操作」和「每次交接都有完整稽核記錄」這兩點後，客戶的態度通常會從懷疑轉為感興趣。這也呼應了一個現實：台灣市場對 AI 的接受度，極大程度上取決於「安全退路」的設計是否明確。你提供的不是一架無法煞車的自動駕駛車，而是一台隨時可以由駕駛員接手的方向盤。

因此，我們建議台灣企業在導入此類系統時，應該先從「高頻但低風險」的任務開始，例如發票自動歸檔、報表排程寄送等。在初期階段，甚至可以主動設定為「每次登入都需要人類確認」，讓團隊成員親身體驗「接手－放手」的流程，建立對系統的直覺信任。當團隊成員從中發現「原來 AI 不會跟我搶滑鼠，而且每次交接都有紀錄」，他們才會願意將更核心的任務交給 AI Agent。這個過程可能需要一至兩個月的適應期，但相較於一次性的強制導入，這種漸進策略的長期成功率高出許多。

風險與限制：Alpha 階段的 OpenBot 還有哪些坑？

OpenBot 在 2026 年 8 月以 v0.0.1 Alpha 版本開源，釋出的頭三天就累積了超過 3，500 顆星，社群反應相當熱烈。但開源社群的熱情，與正式企業部署所需的穩定性之間，存在巨大差距。CopilotKit 官方在 GitHub 頁面上清楚標示「此專案仍處於早期開發階段，不建議用於生產環境」，這份誠實值得肯定，但也意味著任何現在就想讓 OpenBot 實際工作的團隊，必須先搞清楚眼前的坑有多大。這不是要唱衰這項技術，而是幫助台灣企業在評估導入時，能夠做出基於事實的判斷。

Alpha 版本的本質：成熟度還差得遠

從版本號 v0.0.1 就能看出來，這是一個功能基礎、穩定性尚未經受考驗的早期專案。根據 GitHub 儲存庫的提交紀錄（2026 年 8 月 17 日至 8 月 30 日），核心功能仍在陸續補強中，例如身份驗證機制預設為「單一用戶模式」，這個模式（透過環境變數 OPENBOT_SINGLE_USER 啟用）會把每一個請求都視為管理員，完全跳過登入檢查。CopilotKit 官方技術文件明確指出，正式部署時必須關閉這個旗標，否則系統形同虛設。問題在於，目前文件提供的生產環境配置指引仍不夠完整，許多邊界情況（如多用戶同時操作同一個電腦實例）尚未被完整測試。

資源消耗：單一 Bot 就吃掉 5.3GB 映象

這是目前最直接的門檻。根據獨立實測報告與官方 Docker Compose 設定檔，單一個 OpenBot 實例所需的 Docker 映象大小高達 5.3GB，這還不包含底層作業系統與其他依賴元件。映象中內含 Playwright 與完整 Chromium 瀏覽器，這是為了提供隔離的「電腦環境」所必需的代價。實際運行時，官方建議單一 Bot 至少要分配 2GB 記憶體，推薦配置為 4GB。這意味著，如果你想要跑五個不同的 AI Agent（例如一個負責業務開發、一個負責客戶服務、一個負責資料分析），你就需要準備至少 5 台各自獨立的容器，總計消耗超過 25GB 的 Docker 映象檔案，以及 10GB 到 20GB 的 RAM。

更進一步來看，每個 Bot 的「電腦」都是完全隔離的，自己的 Chromium 設定檔、自己的 /workspace 目錄、自己的瀏覽器暫存。這就導致資源無法共享：你無法讓兩個 Bot 共用同一個瀏覽器快取，也不能讓它們共用同一個工作目錄。對比之下，Grok Bot 的設計是讓所有 Bot 共享同一個帳號層級的雲端電腦，雖然犧牲了安全隔離，但在資源效率上顯然高出許多。台灣中小企業在評估時，如果伺服器資源有限，這會是一個非常現實的障礙。

CopilotKit Intelligence 授權依賴：持久記憶的代價

這可能是最容易被忽略的風險。OpenBot 的設計中，持久性記憶與對話狀態管理依賴 CopilotKit Intelligence 這項雲端服務。如果沒有取得授權（無論是免費試用或付費方案），系統會「在每次對話結束後忘記一切」。CopilotKit 官方文件承認，這不是一個降級模式可以容許的情況，沒有 Intelligence，OpenBot 就無法維持跨 Session 的工作記憶，也就無法執行需要連續追蹤進度的長期任務。

更麻煩的是，這項依賴被社群批評為「vendor lock-in」的典型。使用者無法使用開源自建的記憶解決方案（例如本地的 Postgres 資料庫搭配 pgvector），而是被綁定在 CopilotKit 的雲端服務上。如果你所在的企業有嚴格的資料落地要求，或者擔心服務中斷的風險，就必須審慎評估。CopilotKit 官方在 GitHub issue #31 中已經確認，他們正在研究自建儲存選項，但「尚無具體時間表」。對於需要立即部署的團隊而言，這是一個必須接受的現實限制。

撞名問題：不是那個自駕車 OpenBot

這聽起來像個小問題，但對搜尋與研究來說其實很困擾。Intel Labs 早在 2020 年就開源了一個名為「OpenBot」的專案，目標是讓智慧型手機充當大腦，驅動一台造價低於 50 美元的兒童自駕車玩具。該專案有自己的網站（openbot.org）、論文（2020 IEEE/RSJ IROS）、以及大量相關內容。當你搜尋「OpenBot 風險」或「OpenBot 安全性」時，搜尋引擎很可能會同時出現自駕車與 AI Agent 兩種完全不同的資訊。這不僅增加研究成本，更可能導致誤解，如果你在尋找 AI Agent 的治理機制，卻不小心讀到一篇關於自駕車避障的論文，那就完全偏離主題了。CopilotKit 團隊在 GitHub README 中加了一段免責聲明，但這不足以消除搜尋上的混淆。

安全工作尚未完整：issue #35 與 #29

從 GitHub issues 追蹤中可以看到兩個值得注意的安全問題。第一，issue #35 指出，名為 canRunAgent 的權限檢查函數雖然被定義與測試，但在實際的授權流程中並未被呼叫。這表示一個已登入的使用者，理論上可能驅動不屬於自己的私人同事（Coworker）機器，造成潛在的存取控管漏洞。第二，issue #29 則報告了 Bot ID 偽造的風險：由於 Bot 的身份標記是在客戶端生成後傳遞的，惡意使用者可能偽造身份來冒充另一位同工作者執行操作。CopilotKit 團隊在 issue 回覆中表示這些問題「已標記為待修復」，但在 v0.0.1 階段仍未處理完成。這在正式的企業部署中是不可接受的。

社群評價：值得關注，但還不到部署的時候

社群的反應相當一致。知名 AI 工程部落格 moclaw 在 8 月 19 日的評論中總結道：「值得觀望，但還不適合部署（Worth watching， not yet worth deploying）。」這與多數早期採用者的心聲相符。另一個社群平台 Reddit 的 r/AI_Agents 討論串中，用戶 jkdev 直言：「治理層的設計是對的，但 Alpha 程式碼與治理文件之間還存在不小的落差。」不過，正面評價也不在少數。許多開發者認為 OpenBot 的核心概念，在動作被執行前先經過一個統一的閘道（gateway）進行審核與記錄，是解決「AI 信任問題」的正確方向。關鍵在於，這個治理機制尚未在真實流量下接受考驗。

替代方案有限公司的觀點：台灣企業的務實建議

從我們的角度來看，OpenBot 確實抓住了「可稽核的自主」（Auditable Autonomy）這個核心命題，這正是台灣企業導入 AI Agent 時最需要突破的心理關卡。目前市面上多數 AI 工具都能做到「自動化」，但很少能讓你「放心讓它自動化」。OpenBot 的治理層設計，先解析目標、用 CEL 規則評估政策、寫入審計日誌後才呼叫，是正確的方向，但問題在於它還只是原型。

我們的建議是：現在還不適合讓 OpenBot 進入你的生產環境，但非常適合用它來建立內部 PoC（概念驗證）。找一個完全無關生產的沙盒環境，用 OpenBot 跑一個單純的任務，例如自動從測試用的 Google Drive 下載檔案，並在本地端的分類資料夾中歸檔。利用這個過程熟悉它的治理規則是如何撰寫與測試的，同時累積對 Docker 資源管理、CopilotKit Intelligence 整合的實務經驗。更重要的是，讓你的 IT 團隊與業務團隊一起親眼確認「AI 動作被閘道記錄後人類可以攔截」這件事，這對建立組織層級的信任基礎非常關鍵。等到 v0.1.0 或 v0.2.0 版本釋出，並且上述的漏洞、資源瓶頸、vendor lock-in 問題獲得改善時，你才能夠以更短的時間導入真正的生產部署。

同時，我們要提醒台灣企業在評估這類開源專案時，不要只看功能清單。真正的成本來自於維運，Docker 映象的管理、PostgreSQL 備份與還原、CopilotKit Intelligence 服務中斷時的應變計畫。如果你的團隊沒有專職的 DevOps 工程師，或者對 LangGraph、Mastra 等 Agent 框架不熟悉，那麼直接使用 Grok Bot 這類商業服務，從整體成本來看不見得比開源方案高。開源不等於免費，這是在企業導入決策中經常被忽略的現實。我們認為，對多數台灣中小企業而言，觀望並參與 OpenBot 的開源社群（例如貢獻文件、回報 bug、參與討論）是現階段最理性、也最有長期效益的策略。

替代方案有限公司觀點：台灣企業該如何評估與落地 OpenBot？

在前面的章節中，我們從技術面分析了 OpenBot 的治理架構、隔離設計與運作成本。但對於台灣的企業主或技術長來說，最關鍵的問題始終是：「我的公司到底該不該導入？該怎麼開始？」

我們的答案是：OpenBot 確實是當前最適合「有敏感資料但又想導入 AI Agent」的開源方案，但它不是一個安裝即用的產品。你需要的是一套完整的評估與落地策略。

先搞清楚你的首要問題：資料安全還是快速導入？

台灣中小企業在評估 AI Agent 時，常常同時面臨兩個互相矛盾的壓力：一方面希望立刻看到效率提升，另一方面又擔心公司內部的客戶資料、財務報表、生產配方外流。根據勤業眾信 2025 年發布的〈台灣企業 AI 治理調查報告〉，超過 62% 的受訪企業將「資料外洩風險」列為導入 AI 的首要障礙（勤業眾信，2025）。

我們在輔導客戶時，會用一個簡單的二分法來協助決策：如果你的公司營運高度依賴第三方雲端服務（例如使用 Gmail、Google Drive、Salesforce、HubSpot 等串接的 SaaS），且對資料落地沒有強制規範，那麼 Grok Bot 或 Cursor 的商業方案或許更快。但如果你屬於以下任何一類，OpenBot 就是值得認真研究的選項：

金融與保險業：客戶的財務資料、保單內容受《金融消費者保護法》與《個人資料保護法》規範，資料不得隨意傳送至境外未經核可的雲端服務。
醫療與照護機構：病歷、檢查報告屬於《個資法》第六條的特種個資，幾乎沒有商業外部 AI 服務能合法處理。
製造業與半導體供應鏈：生產參數、BOM 表、客訴紀錄牽涉營業秘密，多數公司內部政策明文禁止上傳至任何不在自有機房的伺服器。
法律與會計事務所：客戶委任資料、訴訟文件、財務簽證底稿，洩漏的代價遠高於導入帶來的效率。

對於這些產業，OpenBot 的「所有動作先經唯一 gateway 審核再記錄」機制，提供了目前開源社群中最接近「企業級治理」的框架。相比之下，Grok Bot 雖然號稱有雲端帳號隔離，但官方文件已明示「不要把單一 Bot 當作安全邊界」，在金融或醫療 audit 時幾乎不可能過關。

落地前的三道浪潮：成本、能力與文化

即使確認 OpenBot 符合公司 security 需求，導入過程仍會遭遇三層現實考驗。以下是我們在客戶端實際看到的痛點：

第一，Token 成本炸彈不是說說而已。OpenBot 的 always-on agent 設計，意味著 Bot 在背景持續運作、反覆擷取網頁內容、讀取檔案、與 LLM 模型輪詢。根據獨立開發者 jjcm 在 Hacker News 上分享的實測經驗（jjcm，2026年8月），他讓 Grok Bot 處理一個月的供應商聯繫工作，用量竟然超過過去五年的總和。在 OpenBot 自架環境下，你使用的是自己的 OpenAI API Key、Azure OpenAI 或本地模型，每 100 萬 token 的成本約在 2 到 15 美元之間，取決於模型大小。如果一個 Bot 每天處理 200 次小型互動，每月可能消耗 300 萬到 500 萬 token，對應的 API 帳單就是 600 到 7，500 元台幣。你必須先找一個低風險、低頻率的流程來測試實際用量，否則第一個月的帳單可能嚇退老闆。

第二，IT 維運門檻被嚴重低估。OpenBot 的官方 Docker Compose 檔案需要同時啟動 PostgreSQL、pgvector 擴充、supervisor 控制服務、每支 Bot 的獨立容器、以及可選的 PoC Bot 與 LangGraph Bot。單一支 Bot 的映像檔就高達 5.3 GB（內含 Playwright 與 Chromium），尖峰實測記憶體需求為 0.55 GB，官方建議至少配置 2 GB 到 4 GB。如果你的公司目前只有一台共用 NAS 或虛擬主機在跑 WordPress，那麼你的基礎設施可能完全無法支撐。此外，OpenBot 目前仍處於 Alpha 階段，預設的 OPENBOT_SINGLE_USER 模式在生產環境不應啟用。你必須自己建立使用者認證、RBAC 權限管理、API Key 輪替與審計日誌的長期備份。這些事情在商業產品中可能已經是內建功能，但在 OpenBot 的世界裡，你得自己動手。

第三，團隊須建立「AI 同事」的協作文化。OpenBot 的設計假設你願意把部分工作正式交給一支自動化的同事。這不是部署一個 chatbot 後台改個關鍵字那麼簡單。你的團隊必須學習如何寫 CEL 政策規則，定義「什麼行為允許、什麼行為拒絕、什麼動作需要管理者手動審批」。GitHub issue 中已經有人回報，canRunAgent 這個函式被定義、被測試、卻沒有被實際呼叫，導致登入的使用者可能意外驅動他人的私有 coworker。這類問題在 Alpha 階段會不斷出現，你的團隊需要有能力持續追蹤上游倉庫的變更、貢獻修復或自行維護 patch。

我們建議的落地流程：先小步驗證再逐步擴大

考慮到上述挑戰，我們對台灣企業的建議是一套「三階段導入流程」，而不是一步到位的全公司部署：

第一個月：沙盒評估（Sandbox Assessment）。在一台獨立的開發機或虛擬機上部署 OpenBot，使用免費的 LLM API（例如 Groq 提供的 Llama 3 的免費 tier）或低成本本地模型（例如 Llama 3 8B）。選定一個低風險、重複性高、錯誤影響小的流程，例如「自動讀取指定收件匣中的發票 PDF，擷取日期與金額，寫入試算表」。這個階段的目標不是產出完整解決方案，而是讓團隊親身體驗：配置映像需要多少時間？policy gateway 的 CEL 規則怎麼寫？Bot 何時會卡在 2FA 或登入牆？
第二到三個月：封閉式試營運（Closed Beta）。將測試範圍擴大到 2 到 3 個部門，例如財務部的發票處理流程與業務部的客戶跟進提醒。此時必須切換到正式的 LLM API（如 GPT-4o 或 Claude 3.5 Sonnet），並開始記錄每月實際 token 用量與對應成本。同時，建立跨部門的「AI 治理小組」，負責審查每個新推出的 Bot 是否違反企業政策。這個階段的重點是「找到什麼該交、什麼該留人」的邊界。
第四個月後：選擇性擴散（Selective Rollout）。只有在前兩個階段驗證過、且成本與效益明確正向的流程才推廣。強烈不建議在同一時間讓超過三個 Bot 同時上線。原因是 Alpha 階段的 OpenBot 在並行處理上仍有不明確的 bug，群組通訊時 Bot 之間的非同步交付設計（per-invocation delivery）讓你無法即時中斷正在進行的對話，這在生產環境可能造成災難。

我們的具體立場與提醒

替代方案有限公司認為，OpenBot 的治理機制非常適合有敏感資料或法規要求的產業。它解決了一個當前市場上最被忽視的問題：「不是 agent 聰明不聰明，而是你敢不敢讓它靠近你的工具。」CopilotKit 團隊的 CEO Atai Barkai 在 8 月 19 日的公開貼文中強調「OpenBot 是為真實公司設計的開源 Grok Bot」（Atai Barkai，2026），我們認同這個定位，但必須補充一句：前提是你必須有熟悉 agent 框架與 self-host 維運的團隊。對於沒有專職 DevOps 或 Machine Learning Engineer 的公司，我們建議第一階段先從社群參與開始，例如測試 OpenBot、在 GitHub 上回報 bug 或貢獻文件翻譯、追蹤 CopilotKit 的 release note。這可能比直接跳入生產部署更務實。

另外請特別注意一個容易混淆的地方：OpenBot 這個名稱與 Intel Labs 在 2020 年開源的同名專案完全無關。Intel 的 OpenBot 是一台用手機當大腦的 50 美元自駕車（openbot.org），而 CopilotKit 的 OpenBot 是 AI 同事平台。如果你上網搜尋「OpenBot 台灣」，讀者可能會先看到自駕車的新聞。你在撰寫內部文件或對外溝通時，務必加上「CopilotKit 的 OpenBot」或直接使用完整的「OpenBot（CopilotKit）」來避免混淆。

總結來說，我們的觀察是：2026 年的 AI Agent 浪潮才剛開始，有能力自己持有治理權的企業，將在這場競賽中佔據長期優勢。OpenBot 提供了一條通往「可稽核的自主」的路徑，但這條路需要技術專業、成本控管與組織調整才能走通。如果你願意投入這三個月的學習與驗證期，我們認為這項投資的回報很有機會超過一次性採購商業服務的短期節省。

結論：開放治理派的價值，讓 AI 同事真正值得信任

走完整個系列，我們從「AI 有自己的電腦」這個看似科幻的起點，一路剖析了 Hermes Bot Mode 的開源在地派、OpenBot 的開源治理派，以及 Grok Bot 的商業自助派。三種路徑，對應的是同一道命題：你敢不敢讓 AI 靠近你的工具？而我們認為，這道命題的解答，不在於 AI 的聰明程度，而在於它背後的治理設計。

2026 年 8 月，CopilotKit 開源了 OpenBot，並在介紹中寫下了一句關鍵的話：「Every action decided before it happens and recorded after.」（每一個動作，在發生之前就被決定，發生之後就被記錄。）這句話點出了開放治理派的核心論述：自主不是難題，可稽核的自主才是。當一個 AI 同事能像人類同事一樣，所有行為都經過審核、留下記錄，企業才能真正從「不敢讓 AI 靠近工具」轉變為「放心交付」。

三個層次的信任設計

OpenBot 的治理機制，並非只是一層薄薄的權限控制，而是從三個層次建構起一道完整的信任防線。

第一層：治理層（Policy Gateway）。所有 AI 動作都必須先通過一個唯一的閘道。這個閘道會先解析 AI 模型的真正意圖（不相信模型宣稱的目標），再用 CEL 規則評估是否符合企業政策，然後才寫入稽核紀錄並執行。如果政策不允許，動作直接拒絕；如果政策規則編譯錯誤，系統預設朝「拒絕」放行。這種設計，確保了 AI 無法繞過規範，也讓企業管理者可以清楚知道每個動作的來龍去脈。

第二層：隔離層（Container Isolation）。每個 Bot 有自己的獨立容器，包含自己的 Chromium 瀏覽器、自己的 /workspace 檔案目錄、自己的登入資訊。兩個同事對同一服務持有不同帳號，彼此看不見對方的操作，也不會碰到你本人工作用的 Chrome。這種隔離，讓 AI 同事的活動範圍被嚴格限制在「授權的領域」之內，無法越界。

第三層：接手層（Human Handoff）。當 Bot 遇到登入牆或雙因子驗證（2FA）時，會停下來並發出求助請求。控制權交回給人，記錄下「computer.help_requested」「control_taken」「control_released」等事件。在人類接手駕馭的期間，Bot 的動作被拒絕而非排隊等待。這種設計，確保了人在關鍵時刻始終保有控制權，而不是被動接收 AI 的結果。

這三層設計，共同回答了企業導入 AI 時最核心的焦慮：如果 AI 做錯了，我能不能知道？能不能阻止？能不能事後追查？OpenBot 給出的答案是：可以，而且每一步都有記錄。

可稽核的自主，才是信任的基礎

在我們的訪談中，許多台灣企業主對 AI 的態度是「很有趣，但我不敢用」。他們不是不相信 AI 的能力，而是不相信 AI 的可靠性。當一個 AI 同事可以操作你的 CRM、你的郵件系統、你的發票平台，一旦出錯，後果可能是客戶資料外洩、訂單錯誤、甚至法律糾紛。

OpenBot 的治理層，正是為了解決這個問題。它讓 AI 的自主性建立在「可觀察、可稽核、可追溯」的基礎上。正如社群所評論的：「Autonomy without observability is just a faster path to an incident.」（沒有可觀察性的自主，只是通往事故的更快路徑。）這句話精準點出了傳統 AI 代理的盲點：我們讓 AI 越來越自主，卻沒有給它一套可以讓它「負責任」的機制。

這也是為什麼我們認為，開放治理派在 2026 年的 AI Agent 浪潮中，扮演著不可或缺的角色。Hermes Bot Mode 讓我們自己掌握 AI 團隊，Grok Bot 讓我們像帶新人一樣示範一次就交給它，但 OpenBot 給出的，是「可稽核的信任」。這份信任，不是來自於模型有多強大，而是來自於制度有多嚴謹。

從「90% 完成」到「100% 完成」的關鍵

Grok Bot 的產品經理 Roman 曾說：「90% 完成和 100% 完成之間有巨大的落差。Grok Bot 可以完成揮桿，因為工作落在地球人會放的地方，也就是真實的工具裡。」這句話說得很漂亮，但我們想補充一點：100% 完成，不只是工作落在真實工具裡，更是工作落在可稽核的軌跡中。

一個 AI 同事幫你處理了 100 封郵件，如果你不知道它回了什麼、回給誰、有沒有誤解客戶需求，那這個 100% 完成，對你來說仍然是 0% 的信任。OpenBot 的治理層，讓每一封郵件的發送、每一次 CRM 的更新、每一個流程的觸發，都留下可供稽核的記錄。企業可以隨時查閱、回溯、驗證，確保 AI 的行為符合預期。

這也呼應了 CopilotKit CEO Atai Barkai（2026 年 8 月 19 日）在社群上的發言：「OpenBot 是一個開源的 Grok Bot，但可以搭配任何 agent 框架，專為真實企業設計。」他強調的是「真實企業」，不是實驗室裡的 demo，不是玩具性質的專案，而是真正要面對客戶、面對法規、面對營運風險的企業。而真實企業需要的，不是最聰明的 AI，而是最值得信任的 AI。

帳單警示與成本控制：治理層的經濟學

在討論治理時，我們不能忽略一個實際問題：成本。OpenBot 的單一 Bot 實測顯示，尖峰記憶體使用量約 0.55GB，官方建議最低 2GB、推薦 4GB，單一映像檔大小為 5.3GB（內含 Playwright）。每多一個 Bot 同事，就需要多一台獨立容器。這意味著，企業在導入 OpenBot 時，必須同時考慮基礎設施成本。

然而，治理層的存在，恰恰可以幫助企業控制成本。因為所有動作都經過 Policy Gateway，企業可以設定規則，限制 AI 的執行時間、資源使用量、甚至特定操作的頻率。例如，你可以設定「每個 Bot 每天最多執行 100 次檔案寫入」，或者「所有對外發送郵件的動作必須先經過人工審批」。這些規則，既能防止 AI 失控，也能避免帳單暴漲。

社群中有一則真實案例：一位用戶讓 Grok Bot 聯絡約 40 家越南布料供應商，結果一個月內用完了過去五年總和的 token 量。這不是 Grok Bot 的錯，而是因為缺乏治理層的約束。如果企業在導入前先設定好規則，讓 AI 知道「什麼可以做、什麼不能做、做多少就停」，就能避免這種情況。

台灣企業的落地建議：從一個流程開始

回到台灣企業的實際處境。根據我們的觀察，多數台灣中小企業並不具備完整的自架能力，IT 團隊規模小、資源有限。因此，我們不建議一開始就導入整個 OpenBot 平台，而是從一個小流程開始驗證。

具體來說，你可以挑選一個「重複性高、容錯度低、不涉及關鍵資料」的流程，例如：

收件匣整理：讓 AI 自動分類郵件、標記優先級、回覆常見問題。
發票處理：讓 AI 讀取發票 PDF、提取金額與日期、寫入會計系統。
客戶跟進：讓 AI 根據 CRM 資料，自動發送跟進郵件、設定提醒。

選擇這些流程的原因很簡單：它們的錯誤成本低，即使 AI 出錯，也不會造成重大損失。更重要的是，你可以透過這些流程，實際測試 OpenBot 的治理機制是否如預期運作，Policy Gateway 是否如實記錄了所有動作？Container Isolation 是否有效隔離了不同 Bot？Human Handoff 是否在需要時正常觸發？

我們建議，先花一個月的時間，讓一個流程在 OpenBot 上跑順。這一個月內，你不需要追求效率提升，而是專注於觀察和調整。看看 AI 的決策是否合理、稽核日誌是否完整、人機接手是否順暢。當你對這套治理機制建立了信心，再逐步擴展到其他流程。

替代方案有限公司的觀點：台灣市場的落地建議

我們認為，OpenBot 作為開放治理派的代表，在台灣市場具有獨特的價值。台灣企業普遍重視資料安全與法規遵循，許多企業甚至不敢將資料送上雲端。OpenBot 的開源特性與自架能力，讓企業可以完全掌握自己的資料，不必擔心資料外洩或被第三方綁定。

同時，我們看到台灣中小企業在導入 AI 時，常犯一個錯誤：急著追求「全自動」，卻忽略了「可稽核」的價值。他們認為，只要 AI 能自動完成工作，就是成功。但事實是，沒有治理層的自動化，就像沒有煞車的跑車，速度很快，但遲早會出事。OpenBot 的 Policy Gateway 設計，正好解決了這個問題。它讓企業可以在導入初期就建立規範，讓 AI 在規則內運作，而不是事後才來補救。

我們也觀察到，台灣企業對於「開源」的接受度正在提高。過去，企業傾向於購買商業軟體，因為覺得「有保障」。但隨著開源社群越來越成熟，企業開始意識到，開源不等於不安全，反而提供了更大的彈性與自主性。OpenBot 的 MIT 授權，讓企業可以自由修改、客製化，甚至發展自己的分支版本。這對於有特殊需求的企業來說，是商業軟體無法提供的優勢。

當然，我們也必須誠實地說，OpenBot 目前仍處於 Alpha 階段。它的功能還不完整，社群回報了一些問題，包括 Bot ID 偽造的風險、某些函式未被正確呼叫的 issue。這些都需要時間來修復。但我們認為，這正是開源社群的優勢：當問題被發現，社群會迅速反應，而不是像商業軟體一樣，等待下一個版本更新。

如果你的企業正在考慮導入 AI 同事，我們建議你從現在開始，花三個月的時間，建立內部對 OpenBot 的理解與熟悉度。這段時間內，你可以先從一個小流程開始，測試 Policy Gateway 的運作、觀察 Container Isolation 的效果、評估 Human Handoff 的體驗。當你對這套治理機制建立了信心，再逐步擴展到更多流程。我們相信，這項投資的回報，將超過一次性採購商業服務的短期節省。

下一步：從實驗到擴展

如果你對 OpenBot 的治理機制感興趣，想進一步了解如何在台灣環境落地，我們可以提供協助。下列是你可以採取的具體行動：

參考 OpenBot 官方 GitHub 倉庫，下載 Docker Compose 設定檔，在本機測試環境中啟動一個 Bot。
閱讀 CopilotKit 官方文件，了解 Policy Gateway 的 CEL 規則撰寫方式。
加入 OpenBot 社群，追蹤 issue 與討論，了解最新的開發進度與已知問題。
如果遇到技術問題，可以聯繫我們替代方案有限公司，我們提供 AI Agent 導入顧問服務，協助企業從評估到落地。

，我們想用一句話總結這個系列的核心觀點：2026 年的 AI Agent 浪潮，不是關於 AI 有多聰明，而是關於你有多信任它。OpenBot 證明了一件事：信任是可以被設計出來的。當你給 AI 一套可稽核的規矩，它就不再是一個需要被監控的黑箱，而是一個真正值得信賴的同事。

現在，就從一個流程開始吧。

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