Grok Bot 進階架構指南：Harness、Loop、Graph 與 AI Agent 批准機制

建立一個 Bot，替它取名字，再連接幾個帳號，並不等於建立了一個可靠的 AI Agent。

如果工作目標模糊、工具權限過大、失敗後沒有停止條件，那麼持續運行只會讓問題持續累積。

長時間工作的 Agent，真正需要的不是一段更長的提示詞，而是一套能保存狀態、限制行動、驗證成果並管理交接的系統。

這個框架的價值，在於它把「AI 為什麼失敗」從單純的模型問題，轉變成可以逐層檢查的工程問題。

Agent 改變的，不只是答案，而是工作的交付單位

聊天式互動通常以一段回答結束。執行型 Agent 則試圖交付一個可檢查的產物或狀態變更。

那可能是一份附來源的研究報告、一個完成測試的程式修補、一份準備好的客戶簡報，或一組等待人工批准的草稿。

因此，評估 Agent 時不能只問「回答是否流暢」，還要問：

• 任務是否真的完成？
• 成果是否放在正確位置？
• 過程是否超出授權？
• 失敗時是否停止？
• 能否提出完成工作的證據？

「擁有結果的隊友」是一個有用比喻，但不代表系統能自行承擔責任。權限設定、風險決策與最終問責，仍需要明確的人類負責者

模型是推理引擎，不是完整的作業系統

Grok 4.6 為面向長時間 Agent 任務的模型，並提到補充訓練、工具環境與多項評測。

這些產品及效能主張需要另外核實，但其中有一個普遍成立的問題：長時間執行與單回合問答，面臨的失敗模式不同。

Agent 必須跨越多次工具操作維持目標，理解意外結果，辨認重複失敗，並決定是否值得再試。

然而，即使模型能力提高，它也不會自動建立安全邊界。

基準分數不能決定哪個帳號可以被開啟，也不能代替付款批准、資源上限或資料隔離。

模型越有能力，控制它的系統就越需要清楚。

一個模型，三層控制

把所有事情塞进單一提示詞，會讓每次失敗都看起來像文字描述不夠好。

實際上，不同錯誤需要不同修復方法：

更好的提示詞可以改善一次執行；更好的架構，才能系統性改善之後的每一次執行。

第一層：Harness，建立受控的工作環境

先定義角色，再交付任務

Harness 可以理解為模型周圍的執行框架，包含工具、状态、權限、記錄與控制機制。

第一個設計工作，是把角色與當前任務分開。

「你是研究助手，只負責核准來源的資料蒐集與引用整理」是角色。

「今天請整理三家公司的定價差異」則是一次指派。

角色應穩定描述責任、輸出及邊界，避免每次對話都重新決定工作方式。

工具面越小，失敗範圍越容易控制

更多工具不一定帶來更好的 Agent，卻通常會增加出錯的可能範圍。

只需要讀取文件的 Bot，不應預設取得信箱寄送權限。只需要準備分析的 Bot，也不應順便擁有刪除資料或修改帳務的能力。

整合與授權是兩個不同問題：

• 整合決定系統可以接觸哪些服務。
• 授權決定某個角色可以對那些服務做什麼。

兩者都需要明確設定，而不是依靠角色名稱暗示。

把工作狀態保存在對話之外

聊天適合協調，卻不適合成為唯一的任務資料庫。

當流程變長，只靠對話摘要傳遞進度，容易遺漏決策、混淆版本，或把舊指示帶進新任務。

更穩定的方式，是保存結構化狀態：

任務 ID：
目標：
負責者：
目前階段：
輸入位置：
產物位置：
已完成的驗證：
未解問題：
待批准動作：
下一步：
最後更新時間：

訊息負責討論，產物承載細節，狀態檔保存進度。這三者不必擠在同一份逐字稿裡。

共享環境不是安全隔離

若多個 Bot 共享瀏覽器登入、檔案或憑證，就應依此設計風險控制。不同的畫面、名字與角色，不會自動建立隔離。

當角色需要不同信任等級時，應考慮分離底層帳號、憑證、容器或工作環境。

角色契約是行為規則；安全隔離是技術控制。兩者不能互相取代。

登入工作階段也是敏感權限

讓使用者接手登入，通常比把密碼貼入聊天更合理。但登入完成後，已驗證工作階段仍可能允許讀取資料、修改內容或代表使用者行動。

因此，還需要了解：

• 工作階段存放在哪裡。
• 是否會錄製畫面或操作。
• 哪些 Bot 可以使用同一個登入。
• 如何撤銷授權。
• 平台如何儲存及保護秘密。

不要把「密碼沒有出現在聊天裡」誤認為「沒有憑證風險」。

第二層：Loop，讓修正有方向，也有終點

「一直試到成功」不是可靠的迴圈

一個能長時間工作的 Agent，必須接收回饋並修正。但如果成功沒有定義，重試沒有上限，持續執行就可能變成持續消耗預算。

可靠迴圈需要五件事：

1. 清楚的目標。
2. 可觀察的驗證方法。
3. 有意義的修正策略。
4. 時間、費用與重試上限。
5. 停止及升級路徑。

基本流程可以寫成：

取得輸入
→ 執行工作
→ 檢查成果
→ 符合標準：交付
→ 不符合標準：判斷是否允許修正
→ 仍有預算且存在新策略：重試
→ 否則：停止並回報

模型可以提出如何修正，但是否允許再試，最好由外部控制機制決定，而不是讓模型自行擴張預算。

驗證必須依靠產物，不是信心

不同任務需要不同證據。

程式任務可以檢查測試結果與差異檔；研究工作可以核對引用與主張；資料處理可以比較前後筆數；介面操作可以檢查實際狀態及截圖。

第二個模型也能協助審查，但不天然等於獨立驗證。如果它只閱讀第一個模型的結論，仍可能繼承相同假設。

驗證者應能接觸原始證據，並使用事先定義的標準。

重試前，先確認前一次是否已成功

工具逾時不代表操作一定失敗。

例如，新增紀錄的請求可能已完成，只是回應沒有傳回。如果 Agent 立即再做一次，就可能產生重複資料。

因此，流程應包含去重或冪等設計，也就是重複執行不會額外造成不必要的變更。

可採用任務 ID、唯一鍵、提交前查詢，以及操作後狀態確認。

先測試流程，再保存成例程

若產品支援工作流程示範、例程或排程，應在流程正確後才使用。

好的例程應包含：

• 輸入條件。
• 必要工具。
• 操作步驟。
• 輸出位置。
• 驗證標準。
• 批准邊界。
• 失敗處理。

排程與事件觸發器，應喚醒同一個已測試流程，而不是每次觸發都要求 Agent 重新規劃整份工作。

第三層：Graph，讓多個 Bot 形成協作流程

協作的核心是依賴，不是數量

單一 Bot 可以執行一個迴圈；多個 Bot 的合作則可以用圖結構表示。

節點代表工作，連線代表依賴。

研究 A ─┐
研究 B ─┼→ 資料核對 → 草稿整合 → 人工批准
研究 C ─┘

研究分支可以並行，但整合必須等待必要資料。若一個節點需要前一步產物，就不應為了看起來更快而取消依賴。

目標不是最大化同時運行的 Bot 數量，而是減少不必要的等待與重工。

建立專家，不是建立不同性格的通才

五個都叫「智慧助手」的角色，很容易產生責任重疊。

更有用的分工，是讓每個角色擁有清楚的成果：

• 研究者負責來源與資料。
• 建構者負責草稿或實作。
• 檢查者負責標準與證據。
• 協調者負責路由與交付。
• 人類負責高影響批准與策略判斷。

這樣出錯時，才能定位需要修正的契約，而不是只知道「整個系統不太可靠」。

交接產物與所有權，不是整段對話

有效交接應讓接手者知道：現在有什麼、還缺什麼、接下來由誰負責。

任務 ID：
交接目標：
上游負責者：
下游負責者：
產物連結：
已通過的檢查：
尚未確認的假設：
允許的下一步：
禁止的動作：
期限與剩餘預算：

不要把整段聊天紀錄複製給每個角色。這通常只會增加成本，並讓過時資訊與當前規格混在一起。

Lead Bot：把協調規則寫進系統

總指揮應管理流程，而不是重做所有工作

Lead Bot 或 Chief 的價值，是接收一個目標後，分配工作、追蹤依賴、處理阻礙，再組合出可審查的成果。

它不必親自研究每個來源，也不應無理由改寫每位專家的交付物。

對一人團隊而言，理想情況是：你交付一次目標，只在需要判斷、身份驗證或批准時介入。

協調權不能變成權限擴張

Lead Bot 不應透過其他角色執行自己無權執行的動作。

如果某項發布需要人工批准，改由另一個 Bot 按下發布，也不會讓這項限制消失。

同樣地，任務受阻時，協調者不能自行新增帳號、取得更高權限或提高預算。這些都應走明確的授權流程。

批准機制：讓自主權在正確的位置停止

完成安全步驟，再提交具體請求

好的批准機制，不是讓 Agent 每做一步都詢問，也不是到最後才回報已經執行的高風險動作。

更合理的方式，是先完成所有已授權、低風險的前置工作，再停在實際變更之前。

例如，它可以完成研究、草稿與收件者清單，但寄信前要提供完整待審內容。

批准應綁定具體動作與版本

一份有用的批准請求應包含：

提議動作：
目標對象：
確切內容或版本：
預期影響：
費用：
資料範圍：
可否復原：
復原方式：
批准有效範圍：

若收件者、金額、內容或權限範圍改變，就應重新請求批准。

「你可以寄這封信」不是「你之後可以自行寄所有類似信件」。

不要只靠可逆性判斷風險

可逆性重要，但還要考慮隱私、外部影響、法律責任與操作規模。

公開內容即使能刪除，也可能造成不可回收的資訊外洩。大規模標籤或歸檔雖然能還原，仍可能影響日常營運。

真正可靠的批准線，應結合：

• 動作類型。
• 影響對象。
• 資料敏感度。
• 變更規模。
• 復原成本。
• 既有授權。

十個步驟，建立可維護的 Agent 系統

1. 從真實的重複工作開始

選擇已經存在、成果可見，而且值得節省時間的工作，不要先為了展示技術而創造流程。

2. 用一句話定義角色

若一個角色同時負責多項不相關工作，先考慮拆分，避免上下文與權限無限擴大。

3. 在執行前定義完成

明確說明必要欄位、品質要求、輸出位置及驗證方式，避免雙方對「完成」有不同理解。

4. 只連接必要工具

從唯讀及低權限開始。真實任務證明需要更多權限時，再評估擴充。

5. 執行並觀察一次完整流程

使用產品實際支援的操作方式，檢查每個重要步驟，不預設它具備觀看示範或自動學習例程的功能。

6. 保存成功路徑

記錄輸入、步驟、驗證、停止條件及批准邊界，建立可重複執行的規格。

7. 加入獨立檢查

使用測試、來源核對或狀態比較確認成果，不要只由產出者替自己打分數。

8. 限制重試並設計升級

明確規定何時重試、何時停止，以及需要向誰回報。不要讓模型自行提高限制。

9. 有瓶頸時才增加專家

當研究與寫作互相干擾，或建構與審查不夠獨立，再增加角色。架構應回應問題，而不是追求複雜。

10. 每週抽查並淘汰低價值流程

網站會改版，登入會過期，需求也會改變。持續執行的系統需要持續維護。

若一個例程扣除檢查與返工後沒有省下工作，就應重新設計或停用。

自主權階梯：先取得證據，再增加自由度

從建議模式逐步升級

自主權不是永久資格。當例程退化、資料來源改變或錯誤增加時，就應降低權限或恢復人工檢查。

即使達到較高層級，高風險動作仍可持續要求人工批准。

三種值得建立的生產模式

模式一：隔夜研究桌

研究 Bot 蒐集核准來源，來源檢查者核對主張，整理者合併重複資訊，最後由寫作角色產出簡報。

人類早上收到的應是一份有證據、有不確定性標示的審查包，而不是大量未整理的連結。

模式二：Bug 重現與修復

第一個角色先確認問題能否重現，保存環境、步驟、日誌及截圖。

除錯角色再依據已確認的問題提出修復，檢查者執行測試。正式部署則由另一個批准流程控制。

這能降低 Agent 修復不存在問題，或在未理解原因前大幅修改程式的風險。

模式三：有公開發布閘門的內容系統

素材整理、研究、草稿與事實檢查可以在授權範圍內自動推進。

對外發布前，系統提交完整版本、發布平台、時間及相關素材，等待批准。

人類審查的是一個完整成果，而不是管理五段零碎對話。

最常見的失敗模式

一個通才擁有所有工作與權限

它可能同時記住互相衝突的偏好，難以區分任務範圍，也讓任何一次誤操作造成更大影響。

沒有完成標準，也沒有硬停止

Agent 可能在看似合理的地方結束，或在沒有新資訊時反覆嘗試。兩者都不是可靠完成。

把共享登入誤認為角色隔離

不同 Bot 名稱只提供介面上的區分，不會自動保護憑證與資料。

每個角色都收到完整對話

上下文越來越長，卻沒有增加有效狀態，最後交接變成不斷壓縮與遺漏。

所有動作都要批准，或完全不設批准

前者讓自動化變成更慢的手動工作；後者讓系統可能在你知情前對外發送、花錢或修改正式資料。

相信外部內容能修改操作規則

網頁、郵件或文件可能包含試圖引導 Agent 改變任務的文字。

这些內容應被視為待處理資料，而不是新的管理指令，更不能藉此擴張權限或索取秘密。

例程從不淘汰

能運行不代表有價值。真正需要保留的，是扣除維護與返工後，仍然值得存在的流程。

隔夜運行前的上線檢查

在增加自主權之前，確認以下項目：

• [ ] 任務範圍與完成標準明確。
• [ ] 工具與資料權限符合最小必要原則。
• [ ] 已確認 Bot 之間的共享與隔離方式。
• [ ] 時間、費用及重試都有上限。
• [ ] 高影響動作有實際批准機制。
• [ ] 操作有紀錄，產物可直接檢查。
• [ ] 重複觸發不會造成重複提交或發送。
• [ ] 外部內容不能變更安全規則。
• [ ] 有失敗通知與明確接收者。
• [ ] 可以停止任務並撤銷權限。
• [ ] 已測試必要的復原流程。
• [ ] 有人負責定期抽查與維護。

如果其中多項尚未完成，系統需要的通常不是更大自主權，而是更好的執行框架。

結語：可靠的 Agent 必須知道何時停止

模型提供推理能力，Harness 管理它能接觸的世界，Loop 讓修正建立在證據上，Graph 讓不同角色有序協作，批准機制則把高影響決策留在明確授權之下。

真正的 Agent 能力，不只是完成更多步驟，而是能回答三個問題：

這次完成了什麼？有什麼證據？哪些事情不應自行執行？

無论 Grok Bot 的實際產品功能如何演進，這三個問題都比「能不能一直運行」更重要。

值得信任的自動化，不是永不停止的自動化，而是能可靠交付、保留證據，並在正確邊界停下的系統。