示範一次，變成有人負責的規則

GembaOS 是企業 AI Agent 的治理執行平台：以政策判定權限、以綁定參數的單次放行令授權每一個動作、以可追責的簽署鏈記錄人的審批，部署於企業本地機房或私有 VPC。

一項工作實際是怎樣做的，往往只存在於做這項工作的人腦子裡。把它寫成規則，需要既懂業務又懂設定的人，也需要時間。除了直接寫規則、向組織設計助手用話描述，GembaOS 還有第三個起點：員工照常把一件事做一遍，由 GembaOS 協助把看到的整理成有人負責的規則。

觀察工作、由此草擬流程，並不是新鮮事。我們做的是記錄之後的部分。這篇筆記用 GembaOS 附帶的參考訂單畫面走一遍；這些畫面扮演公司自己的客戶管理與核心系統，有訂單搜尋、訂單詳情、付款查詢、退款例外申請及其批核，以及退款錄入。

1. 哪些可以記錄，由公司宣告

在員工自己的頁面按「示範這項工作」，就開出一份示範記錄。員工寫下工作名稱，例如「處理退款例外」，再從公司在設定裡宣告的應用程式清單中，選定要記錄的。員工不能自行加入；沒有宣告，就沒有可記錄的東西。公司也可以宣告一些欄位，其值一概不保存。

GembaOS 隨後發出一個記錄碼。它只可用於一次記錄，兩小時後失效，也不能再次顯示。示範記錄本身甚麼都不執行：沒有審批、沒有放行令、不呼叫任何系統。

2. 照常做事

員工在瀏覽器的記錄工具輸入記錄碼與 GembaOS 的網址，然後照常操作。記錄工具只在宣告範圍內的應用程式頁面上留下：到過的頁面、頁面按欄位名稱顯示的內容、用過的控件、確定下來的值。密碼欄位的值、頁面標明為信用卡資料或一次性驗證碼的欄位、Cookie、瀏覽器儲存的資料、網絡內容與剪貼簿，一概不留。它沒有點擊、輸入、跳轉或提交的程式碼，所以無法在應用程式裡做任何事。

記不了、也不該記的，不靠猜測補上，而是成為有標記的空檔：在別的網站上的一段、暫停、讀不出名稱的控件、從別處嵌入頁面的部分。員工停止記錄後，會看到每一步。不該送出的可以刪除，刪除本身也會留成一段空檔；然後決定送出或捨棄。在那之前，甚麼都不會離開瀏覽器。

記錄送到時，GembaOS 不會照單全收記錄工具的說法。它再按公司宣告的範圍核對一次，丟掉別的網址上的步驟，去掉密碼欄位的值；留下的保存為附有哈希的觀察所得，也就是畫面上顯示過的東西。頁面顯示「已提交」，不等於已付款，記錄也如此寫明。

記錄內容存放在工單的記錄之外；工單記錄只留來源、時間、步驟數量與哈希。員工送出後仍可撤回記錄，據此整理的版本一併刪除，已確認的規則保留。公司可以設定保留日數，沒有設定就保留到員工撤回為止。

3. 助手理解了甚麼

員工的助手把記錄當作資料閱讀，給出我理解的流程：業務步驟（每一步都對應到記錄裡的步驟）、帶著「仍未清楚之處」的規則候選，以及最多三條問題，先問會不會付錯錢、誰來決定。GembaOS 按記錄約束這份提案：沒有記錄依據的丟掉；會寫入其他系統的步驟一律標明仍由人處理；頁面上的數字由 GembaOS 數出；規則只有引用了員工自己的回答，才算「已有說明」。「我不知道」「只是這一次」「請問我的上司」都是有效的回答。

2026 年 9 月 30 日，我們用真實模型（DeepSeek）讀了一份退款例外的記錄，只跑了一次。助手交回九個業務步驟，每步都有記錄依據，退款錄入標明仍由人處理；它把退款頁面讀作「已受理」而不是「已結算」，還注意到申請人與批准人是同一個人。規則候選有七條，各自附著邊界與幣種上的未明之處，另有三條問題。回答一條後，兩條規則變成「已有說明」，助手自己還指出，那個回答沒有回應所問的問題。

同一項工作有多份記錄時，差異會並排保留。我們在參考畫面上記錄了三次（一般會員的部分退款，經例外申請與客服主管批核；金卡會員直接全額退款；有爭議的訂單不退款），助手指出前兩次處理不同，也說明記錄無法看出是會員等級還是金額決定的；它的第一條問題問的正是這一點。得到回答之後，它補上一個新的未明之處：5 萬日圓是指訂單金額，還是退款金額。

沒有接上模型，或模型未獲准處理該畫面的資料時，由替身按畫面把步驟切開，不提出任何規則，並如實說明。員工自己寫好步驟與規則之後，往下的一切都一樣。

4. 負責人按原文確認

規則候選在確認之前只是候選。員工申請確認後，回答的是公司為該應用程式指定的職位的人（參考畫面上是客服主管），沒有指定就是示範者的直屬上司。逐條規則決定確認或略過，並附上備註。示範者不能確認自己示範出來的規則。

確認綁定規則的原文。員工日後改了措辭，新的措辭就沒有確認。確認是以確認人自己的名義留下的記錄，本身不授權任何執行。

5. 由確認的規則到發佈

組織設計助手可以引用一份示範記錄中已確認的規則，連同確認時仍未清楚的地方、記錄上尚未解決的事項（未回答的問題、沒有採納的規則、記錄沒有覆蓋的區間），作為草稿的依據。批准人看到「負責人在示範記錄上確認的規則」，以及確認人的姓名與職位，還有尚未解決的事項。

助手也要說明每個示範步驟落在哪裡：公司已有的操作、某個簽章、已確認的規則、尚未接入的系統，或是人。GembaOS 只接受合適的落點。讀取的步驟只能落在讀取的操作上。會改動系統的步驟，只能落在會改動系統、並經審批路線的操作上，所以示範出來的寫入不會在沒有簽章的情況下執行。判斷類的步驟只有在同一份記錄上確認的規則已列入草稿時，才能落在規則上。其餘一律留給人，發佈頁會註明原因。

發佈頁按設定畫出變更所動到的每條路線，並排顯示前後。它也可以在碰不到正式系統的環境裡，用這份草稿的檔案試行受影響業務所聲明的案例（畫面上稱為「試行」）：模型是按腳本應答的替身，外部系統只用測試資料，沒有測試資料的連接視作連不上，並會計數。此外，它還接收第二人提供的保留案例，提供者既不是起草人，也不是示範者；這些案例按候選規則與現行規則並排判定，並以表列出規則條件所分出的各種情形（金額在上限以下、剛好在上限、超過上限；標記有沒有被提出）中，案例到了哪些。案例給出之後檔案若再改動，就不再算保留案例。

批准由第二人作出，發佈由 GembaOS 執行。其間負責人若撤回確認，發佈就會停下，既不能批准，也不能發佈。

GembaOS 查核甚麼，不查核甚麼

目前還做不到的

• 只涵蓋瀏覽器裡的應用程式。 記錄工具是原型階段的瀏覽器擴充功能。桌面應用程式不能記錄；我們只在自己準備的兩個測試應用程式上試過讀取，還沒有在真正的業務應用程式上試過。
• 不重放點擊。 讓 Agent 執行示範出來的步驟，不在範圍之內。寫入留給人，直至該系統以受治理的操作接入。
• 一次示範不是公司規則。 那是員工的經驗。某人在系統裡做得到的事，不會變成別人的許可；見過一次的繞過做法，也不會被學成慣例。
• 記錄存放在公司自己的儲存，檔案權限受限。公司也可以設定用自己保管的密鑰，把這些檔案加密存放，密鑰與資料分開放；這是一項設定，設了才生效，只涵蓋這些檔案。其餘資料的靜態加密要靠公司自己的磁碟加密。
• 試行驗證的是 GembaOS 的判定，不是模型的理解；保留案例只覆蓋規則裡寫明的條件，幣種、已退款、重複提交等，仍由聲明案例承擔。
• 已送給模型供應商的內容，按該供應商的保留條款處理。

我們怎樣測試

不需要模型的部分由自動測試覆蓋：GembaOS 從記錄中留下甚麼、丟掉甚麼，誰可以確認，發佈拒絕甚麼，撤回會刪掉甚麼。另有一套腳本化的演練，把真正的擴充功能載入瀏覽器，在參考畫面上做一件退款例外，中途離開到別的網站、也輸入一次密碼，然後檢查記錄裡任何地方都沒有密碼。用到模型的那一步，如上文所述，是用真實模型手動跑過的；我們不宣稱它有經測量的準確度。