先由人來做，Agent 一步一步接手

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

大多數企業不是從 Agent 開始的。他們從一條紙上已經在跑的流程開始——申請、審核、兩個簽章、某個人實際動手——外加一份誰也審不了的試算表。他們問的不是「AI 先接哪一步」，而是「能不能把現有流程原樣搬進去，以後再決定」。

GembaOS 的答案是可以，而且這不是甚麼特別模式。手冊的每一步都寫明由誰來做，並有預設值：調查表預設由 AI 調查員撰寫，除非指定了職位；申請內容預設由 GembaOS 按記錄組出，除非指定由某職位填寫；簽章永遠是人的，或企業確認過的規則；執行預設由 GembaOS 呼叫系統，除非指定由某職位動手。AI 是其中一種可以被指定的執行者。

1. 只有人參與的「合約蓋章申請」

參考企業附帶了一項沒有任何模型的業務。員工申請在合約上蓋公司印章。法律顧問讀合約台賬、寫調查表——與理賠案件台上 AI 調查員填的是同一張表，GembaOS 的核對也相同：法律顧問輸入的相對方與金額會與台賬比對，不符就標記，不論是誰寫的。營運負責人簽章；金額超過一百萬日圓，或合約會自動續約時，財務總監也簽。然後法律顧問拿實體印章蓋在合約上、登記用印台賬，附上台賬編號回報。GembaOS 再讀一次台賬，記下它顯示的內容。

下面是產品從附帶配置畫出的路線：

決裁之前: 受理 (申請人) → 讀取記錄 (GembaOS) → 調查要點 (人) → 補件 (申請人) → 規則選定決裁級別 (GembaOS)

簽章之後: 執行前重新讀取 (GembaOS) → 由人執行並回報結果 (人) → 系統回讀核對 (GembaOS)

讓人手那一步保持誠實的有三件事。該操作屬於一個宣告為「無人呼叫」的操作集，欄位與密級與其他操作集一樣宣告；若手冊為一個系統也能呼叫的操作指定了人，GembaOS 會拒絕載入。職位必須是企業的審批職位之一，申請人不能執行自己的申請。而沒有宣告回讀時，手冊檢查會指出：記錄只會保存本人的回報。

2. 由人做完之後，記錄長甚麼樣

簽章鏈與其他案件台一樣可讀：誰簽、按甚麼順序、基於哪些事實。之後，取代 GembaOS 執行記錄的，是等待指定職位的記錄、本人以自己名義附參考號與憑證的回報、被這份回報消耗一次的放行令，以及回讀結果——與批准內容一致、不一致，或因手冊未設期望而僅讀取並記錄。

一份「未能蓋章」的回報不會結束任何事：放行令作廢，審批單帶著本人的理由退回，案件回到經辦人手上——與執行前重讀發現世界已變時的處理完全一致。

3. 同一本手冊，把一步交給 Agent

當企業準備好讓 Agent 讀合約、起草調查表時，改動只是手冊裡的一行，加上該角色的一份指示檔。發佈前的檢查比對新舊版本，單獨印出一行：調查表改由 AI 撰寫，不再由法律顧問。級距、人手執行與回讀都不變；審批單上 AI 的調查表帶著和法律顧問那份相同的「一致／不符」標記。

遷移路徑就是這麼多：先用現在跑流程的人、以他們的名字把流程數碼化，讓記錄累積；之後 Agent 每接手一步，都是同一份檔案上、由另一個人批准的一次變更。

資料來源

• GembaOS 企業級架構白皮書（公開版）§3.3：每一步寫明由誰來做。
• 附帶配置：config/playbooks/seal_request.yaml、config/capabilities/seal.yaml（無人呼叫的操作集）、config/capabilities/contracts.yaml。