Grok Bot 的安全自動化：Four Cs、Routine 與審批邊界

一般 AI 助手等人打開視窗、輸入問題，再回傳一份草稿。雲端電腦型 Agent 的差別，是它可以在持久環境裡使用瀏覽器、檔案與工具，把工作一路做到需要人類決定的位置。

@0xCodez 的〈Grok Bot Agents: how to automate your life in 10 Steps〉把導入方式拆成十步：安裝、定義角色、連接工具、接管登入、示範流程、建立 Routine、增加專家、群組協作、畫出審批線，以及定期清理。Nate Herk 的兩小時實作課程則用一間虛構 HVAC 公司，示範 Inbox Bot 如何分類急件、先建立回覆草稿，再把需要人工處理的案件交給 ClickUp Bot。兩份材料指向同一個導入順序：先讓一件真實工作可驗證，再讓成功路徑重複，最後才增加 Bot。

不過原文有一個不能照字面採用的描述：Bot 並不是各自擁有安全隔離的電腦。依 Grok Bot 官方 Overview，同一使用者的所有 Bot 共用一台持久雲端電腦、檔案、瀏覽器 Session 與登入；每個 Bot 有自己的畫面與對話 Context，但不是獨立安全邊界。

先把十步收斂成一條導入路徑#

1–2：先交付一件真實工作，再定義職責#

第一個任務不要是「介紹你自己」，也不要一開始就做跨十個系統的全自動流程。選一件結果能快速核對的真實工作，例如整理一份指定來源的摘要、替五筆資料補齊欄位，或產出不會直接送出的 Email 草稿。

確認成功後，再把 Bot 寫成一個職責，而不是一段萬用 Prompt。依 Grok Bot 的 Bot 管理說明，角色至少應指出主要目標、來源與工具、工作方式，以及什麼動作必須等待批准。若兩個「角色」使用相同資料、規則與審批線，就先不要拆；名稱變多不會自動讓成果更可靠。

一份可執行的最小職責可以只有四行：

目標：每週整理產品異常，回傳附來源的優先清單。
輸入：唯讀監控資料與客服紀錄。
完成：每項異常都有證據、影響與建議下一步。
停止：不得修改正式環境或聯絡客戶；先提交草稿等待批准。

Four Cs：缺一層，自動化就會在錯的地方卡住#

Nate Herk 把 AI 作業系統拆成四層：Context、Connections、Capabilities、Cadence。這不是另一套工具清單，而是一個找缺口的順序：

順序不能倒過來。先開 Routine、再補 Context，等於準時重複一個判斷不足的流程；先連二十個帳號、再找用途，則只會提早擴大權限。最小做法是讓一個 Bot 先讀取一份權威文件、完成一個不對外送出的成果，再把穩定方法保存成 Skill。

3–4：只連接必要工具，敏感登入由人接管#

連接器與持久瀏覽器 Session 讓 Bot 不必每次重新設定，但也放大權限範圍。由於所有 Bot 共用同一使用者的雲端電腦，某個 Bot 登入的網站、放進工作區的檔案，以及命令列憑證，其他 Bot 也可能使用。

因此不要先把「以後可能用到」的帳號全接上。按照工作需求逐一增加，優先使用來源服務提供的唯讀 scope 或專用服務帳號；工作結束後移除不再需要的暫存檔、登入與連接器。

遇到密碼、Passkey、2FA、CAPTCHA 或付款確認時，官方安全與審批文件要求 Bot 將雲端電腦交給使用者操作，再取回控制權。這是 Session handoff，不是在聊天裡貼出 Secret；一般對話不應承載密碼或一次性驗證碼。

5–6：示範一次只是 Skill 草稿，驗證後才建立 Routine#

原文把「做給 Bot 看一次」視為關鍵能力。這確實適合難以描述、容易示範的瀏覽器工作，但一次錄製只能捕捉 happy path。依官方 Skills and routines 文件，Teach a task 產生的是 Skill 草稿；還要補上決策規則、失敗處理、驗證方式與審批邊界，再用安全案例測試。

Skill 與 Routine 不應混為一談：

• Skill 說明怎麼做，保存步驟、判斷、輸出與安全限制；
• Routine 指定由哪個 Bot 在何時執行，可用排程，或在支援時由事件觸發。

最穩的順序是 one-off task → verified skill → test run → enabled routine。例如每日摘要除了時間，還要寫清楚時區、資料來源、輸出位置、過期資料政策與通知邊界。若來源失敗，應回報缺資料，而不是拿舊資料假裝完成。

7–8：專責 Bot 解決 Context 汙染，群組保留交接#

當 Expense、Recruiting 與 Sales 的來源、術語和成功條件穩定分開，拆成專責 Bot 能讓記憶與對話更集中。它解決的是 Context 與責任歸屬，不是權限隔離。

群組對話則適合讓交接可見：研究 Bot 可以把附來源的候選項目交給編輯 Bot，編輯 Bot 再回傳草稿給協調者。交接時至少傳遞四樣東西：輸入版本、已完成結果、未解風險與下一個 owner。只丟一句「請繼續」會讓接手者重新猜測整個任務。

先用一個 Bot 完成端到端結果；只有出現穩定的專業邊界時才新增角色。這也符合官方「最小可用 roster」的建議，並能避免多 Bot 只增加交接與 Token 成本。

多 Bot 開始接力後，不要把聊天紀錄當任務系統。Nate Herk 的示範把負責 Bot、狀態、開始時間、截止時間、來源連結與最終交付物寫進 ClickUp；高頻 Inbox 輪詢則只留在 Routine history，避免每半小時製造一張沒有決策價值的卡片。這個區分很實用：需要 owner 與後續處理的工作進共享帳本；沒有狀態改變的週期檢查只保留執行紀錄。

9：審批線看可逆性，也看外部影響#

原文提出一個好用的起點：可逆工作交給 Bot 完成，不可逆工作留給人。但工程上還要補一個條件——任何對外代表使用者、移動金錢、改變權限、刪除資料或碰正式環境的動作，即使技術上能回復，也應先審批。

可以自動完成的通常包括研究、比對、分類、建立內部草稿與準備變更；應停下來的包括寄信、發布、購買、刪除、改權限與 production change。審批卡只控制尚未執行的動作，不會撤銷先前工作，因此開始任務時就要寫出停止條件，不能等 Bot 做到最後才補救。

平台提供 Auto Review 時，可用窄範圍的 Require Approval 規則強制這條線；但模型審查仍應搭配來源系統的最小權限，不能把「Prompt 說不要做」當成唯一控制。

公開分享 Bot 模板時也要套用同一條線。官方說明指出，公開連結會暴露 Bot 的描述、Skills 與 Routines；雖然不會一併分享原帳號的登入與對話紀錄，設定裡仍不得留下 API key、內部 URL 或客戶資料。安裝別人的模板前，也應把它當成待審查的第三方程式，而不是無害的 Prompt。

10：每週只問三題，沒有價值的 Routine 就停掉#

長駐自動化最危險的不是明顯失敗，而是網站版面或資料格式改變後，流程仍顯示成功卻持續產生錯誤結果。每週抽十五分鐘檢查每條 Routine：

1. 它有沒有按時執行，失敗是否明確？
2. 抽查一筆輸出，來源與結果是否仍正確？
3. 如果今天停掉，是否真的有人會察覺？

前兩題處理可靠性，第三題處理自動化膨脹。沒有實際使用的 Routine 應先暫停；網站、連接器或輸入格式改變後，先重新 Test run 再恢復。官方文件也建議定期檢查已安裝連接器與啟用中的 Routine，而不是把背景執行視為永久設定。

結語：從提示詞技巧，轉向授權設計#

這十步真正改變的不是「AI 幫你多點幾下」，而是人類工作的重心：從逐步操作，轉向定義成果、提供必要存取、驗證輸出，以及決定哪裡必須停下來。

最小可行做法不需要一支 Bot 軍團。先用 Four Cs 找出目前缺的是資料、存取、方法還是觸發；選一件可核對的工作，把它跑成可靠 Skill，再加一條有明確失敗政策的 Routine。當單一流程已穩定、角色邊界也真的不同，再增加 Bot 與交接；否則更多 Agent 只會把提示詞問題改名為管理問題。

當執行環境已經能長時間並行運作，下一個瓶頸會轉向任務狀態、證據驗收與風險分流；可接著閱讀如何把多個 Coding Agents 組成工程管理迴路。若困難不在 Bot 如何執行，而在一條業務流程由誰持續定義結果、處理例外並檢查改善，則先閱讀 AI Business Partner 如何擁有流程結果。