企業級架構白皮書

GembaOS 是企業 AI Agent 的治理執行平台：以政策判定權限、以綁定參數的單次放行令授權每一個動作、以可追責的簽署鏈記錄人的審批，部署於企業本地機房或私有 VPC。本頁是《GembaOS 企業級架構白皮書》的公開閱讀版（文檔編號 GEMBA-WP-2026-PUB，v1.17.1，2026 年 10 月 1 日），面向 CISO、CTO、CIO、企業架構師與風險合規、審計專業人員。

為甚麼企業不敢讓 Agent 進入生產系統？

GembaOS 的出發點是一個觀察：阻礙 Agent 進入 ERP、生產資料庫與特權系統的，不是模型推理能力，而是現有體系答不出風險管理委員會的四個問題。

1. 授權源頭：Agent 的每一次寫入與配置變更，由誰授權？
2. 責任歸屬：模型被提示詞注入或產生幻覺而造成損失時，法定責任人是誰？
3. 資料邊界：Agent 在多輪推理中讀取了哪些未授權的敏感欄位？
4. 證據：如何向監管機構與法務審計說明：決定了甚麼、依據哪一條規則、由誰決定，以及記錄事後沒有被改動？

大模型防火牆與系統提示詞處理的是文字，API 閘道檢查的是密鑰與流量；單靠它們，都表達不了企業對某一項業務動作的授權鏈：誰有權決定、批准的究竟是甚麼、執行時事實是否依然成立。當 Agent 只輸出文字時，風險由讀者承擔；當 Agent 可以呼叫 API，文字層面的防禦便不再足夠：提示詞防火牆一旦被繞過，底層 API 全盤暴露；長期持有 API 憑證的 Agent 可能在自主規劃中做出超出預期的寫入。

這四個問題分佈在四個層次。AI 資產發現、執行期閘道與業務流程類的產品各自覆蓋其中一部分，當中不少也有審批步驟與參數控制；下表寫明 GembaOS 在每一層的位置。

GembaOS 的架構原則是甚麼？

GembaOS 堅持「非假定信任」：不依賴模型自覺，而是把企業的授權制度、雙人覆核、職責分離與法規基線編譯成機器可確定執行的規則。以下原則貫穿整個平台。

• 嚴格代行授權：Agent 代表員工執行時，有效權限是 Agent 職位權限、登入員工本人權限與當前場景（playbook）聲明邊界三者的交集。員工無權看的財務資料，Agent 不能代為讀取；員工無權批的採購單，Agent 不能代為批准。這就是代行授權。
• 責任不丟失：系統內不存在無人負責的自主操作。每張工單、每次查詢、每張審批單都綁定企業 IAM 或 SSO 中的法定自然人。
• 資料邊界在閘道：未授權的欄位與非必要的上下文在能力閘道直接裁剪，不流入模型的推理記憶；資料庫讀取只經由聲明了欄位清單的只讀檢視與參數化程序，不接受自由拼接的 SQL。
• 管制對準 AI，不對準員工：自主代理沒有員工編號，也沒有甚麼可失去，所以四道關卡一道不少。但一位用自己權限、自己資格動手的管理員是另一回事——責任本來就在他身上，目標系統的稽核日誌也早已記下他的名字。在這裡 GembaOS 要做的是留下紀錄，而不是製造排隊：審批級距可以由執行者本人一次簽章通過；緊急級距則把次序倒過來——先執行，隨即以硬件密鑰與必填理由，向該級距指名的保安角色自動公證。在事故當下擋路的管制，最後都會被繞過去。
• 權限不隨模型改變：審批制度、業務合約與安全邊界獨立於底層模型。無論換成本地自託管模型還是雲端前沿模型，誰可以做甚麼都不變；但模型在邊界之內的表現——質素、工具的選擇——仍會改變，所以要在切換前以影子回放與黃金測試顯示差異。
• 供應商改了 API，是一宗審查案，不是一場意外：API 契約裏宣告了供應商響應的形狀，排程檢查會定時向供應商沙盒發送探針。實際響應的形狀直接作為待審批的 API 變更草案；治理內核逐項對照預定義的契約——前置條件、欄位清單、審批條件——列出哪些業務會失效、會否靜默失效。審查以具名負責人的名義開立，須按路線所定的人員簽批；未配置的變數記為「未執行」，而不是「通過」。受理之後，修復任務指派給具名工程師，AI 在沙盒起草的 Pull Request 由工程師審閱後以個人帳號合併。

四道防線執行引擎如何運作？

GembaOS 要求所有改變業務狀態的敏感操作依次通過四道防線：政策判定、簽署鏈、單次放行令、執行前現狀核對。

• 兩種方式，沒有第三種：一項操作要麼由具名的人決定，要麼由企業事先宣告、並經企業內具名的人確認過的自動規則放行。沒有人簽章的檔位必須宣告為自動規則，否則 Playbook 不能載入；範本帶來的自動規則，在貴司有人確認之前不生效，規則一經修改即須重新確認。自動規則放行的操作，簽署鏈上寫明是哪一條規則、哪個版本、由誰確認，而不是寫成某位主管批准。
• AI 的簽章只是意見：AI 審查員排在決定的人之前，閱讀審批單並附上理由。它建議駁回，申請也不會就此終結，而是交到決定的人手上；檔位上已沒有人時，AI 的異議會把路線指定的人請進來，自動規則不再放行。客戶收到「拒絕」的答覆，只可能因為具名的人駁回；系統自行拒收、模型故障或多次退回，都改由人跟進。
• 沒有人判斷過的事，不走無人檔位：AI 沒有提出方案、由系統按記錄補上的申請，以及系統按規則自動開立（沒有人提出）的工單，一律要有人簽章。
• 四道防線管不到的地方：只有經過 GembaOS 的呼叫才受治理。重讀的是 Playbook 宣告的事實，或審批人看到的那條記錄，而不是世上所有的事實。對 GembaOS 以外的寫入者，只有目標系統本身的版本或條件寫入能擋下過時的寫入；GembaOS 自己的對象租約只為經過它的寫入排序。單次放行令不等於跨系統的「恰好一次」：目標系統的冪等處理、寫入後回讀，以及寫入沒有回應時怎樣處理，都屬上線驗收的範圍；一套驗收測試會對執行平台逐項跑這些情況。

審批人不在，或應由其他人判斷時怎麼辦？

GembaOS 把圍繞待簽章審批單的人手動作（會簽、移交、上報、接管）記錄為受治操作，每一個都附理由；組織圖則從貴司自己的員工名錄匯入。

• 只會變嚴：四個動作都不是簽章，不會減少任何必需的簽章，也不會讓同一人在同一張審批單上兼任兩個角色。
• 每個動作都有理由：每個動作都作為事件寫入工單的雜湊鏈記錄。退回與駁回同樣須寫理由，批准可附備註。
• 誰簽誰負責：代理人、上報對象與接管人都以自己的通行密鑰簽章，簽署鏈記錄代誰簽署。
• 組織圖沿用現有來源：上下級、在職狀態與休假，從貴司身份供應商或人事系統的匯出檔案匯入。GembaOS 只保存其上的治理規則。
• 缺席代理規則：可按金額門檻、風險或業務類型設定，例如「上限以下由副手代理」「涉及合約條款先會簽法務」。規則命中後，產生的就是與人手操作相同的會簽或代理紀錄。
• 離職時的權限交接：不再向離職者派發簽章；其待簽章審批單按企業政策交給最近在職的上級，或留待分配；撤銷其持有的代理；進行中的工單取消並提示重新發起；已批准但未執行的操作（包括尚未簽發放行令的），可按審批級別或密級作廢放行令並重新審批；離職者經辦中的工單交給最近在職的上級，或交回工單原本的經辦人。
• 團隊桌面：主管在自己的管理桌面旁，可看到下屬身上的待簽章、逾時、無人負責、缺席代理中與高風險事項，並按人員、部門、業務類型、期限、風險與積壓時間篩選。
• 運行中的 Agent，也只有一位具名經辦人：跑幾小時甚至幾天的工單，任何時候都只有一位經辦人，預設是發起請求的同事。有權查看的人都可以實時觀看；誰在看會顯示在畫面上，但不記入記錄。只有經辦人能向 Agent 發指示（補充、收窄範圍、在 Playbook 容許的範圍內轉向），Agent 在下一步讀到；指示改變的是 Agent「嘗試甚麼」，不改變它「被允許甚麼」；指示的文字與外來訊息一樣要經過注入檢查。沒有具名本人的登入可以觀看，但不能成為經辦人。收工時經辦人把工單移交給同事，對方認領之前經辦人不變；一天內無人認領的提議自動失效。上司可按公司的接管規則接管。保留、繼續、取消都記下操作者姓名與理由。這些都不改變由誰簽章：簽章仍屬審批路線指定的角色；經移交或接管成為經辦人的人，在一般級距上不能為同一工單簽章。觀看的人也可以問助手；回答按提問人本人的權限生成，只有本人看得到，經辦人可以把它用作自己的指示。
• 審批畫面先講業務語言：審批單第一屏回答「批准後會發生甚麼」：效果與可否撤銷、對象、金額、上限（附核對時的數字）、放行令的有效期與可用次數、執行前會重新核對甚麼、由誰執行。放行令編號與雜湊等技術標識預設收起，供審計查看。系統核對過的項目與系統沒有核對的項目分開列出：沒有任何來源評分的風險不會顯示為「通過」；申請理由是否屬實、附件裏顯示的內容，都明確標為系統未核對，留給簽章人判斷。

歷時數週的案件，如何收斂成一張審批單？

一宗理賠可能歷時數週、附件十餘份、跨越理賠、醫療審查與法務。GembaOS 把這類案件放在工單上，而不是放在審批單上。

• 工單長、審批單短：案件在受理後即停住，等經辦人。經辦人向申請人索取材料（種類來自封閉清單、有截止日、有輪數上限）；申請人在工單頁上傳並補充一句話；到期會記錄在案，之後按 Playbook 的設定處理（預設由經辦人決定）。材料齊全後才起審批單：整宗案件只有一張審批單，一次簽完。
• 申請人看得見、確認得了、改不了：系統從記錄渲染申告（本人原話、檔案、對象、受理時間），申請人只能「確認」或「說明哪裏不對」；更正追加到記錄，原文不被改動。確認以雜湊釘住，審批單上寫明「申請人已於某日確認此申告」。
• 會簽結論是資料：醫療審查、法務等被會簽的角色，從 Playbook 定義的封閉清單中選一個結論再簽章；結論進入簽署鏈，下一位簽章人簽的是含結論的內容。
• 結論決定下一步：Playbook 為每個結論規定一個動作（從封閉清單中選）：請另一角色緊接著簽章、退回經辦人，或退回並向申請人索取指定材料。審批人只選結論，接下來做甚麼由 Playbook 決定。
• 回來看甚麼：審批單記住每位查看者上次看到哪裏，回來時先給變化（等了幾天、期間完成了哪些簽章與結論、新增檔案、補件輪次、更正、確認），再給「唯一剩餘決策」：待簽角色、Playbook 為該角色寫的一句話、最近一條仍未決的結論。簽署的內容不變。
• 事實由 Playbook 派生：出險或購買至今天數、補件輪數、檔案數、是否已確認等，由系統從該角色本已可見的讀值、按企業的營業日曆計算，審批級別與缺席代理規則都可引用。Playbook 不寫自由表達式，個人的代理規則仍是表單。
• 案件可以全程在電郵上完成：電郵申請的案件，系統把記錄下來的申告連同一個確認碼寄給申請人；回覆確認碼即確認，回覆其他內容即記為更正。每一輪補件也以電郵寄出，申請人直接回覆並附上檔案。
• 代理也可以索取材料，但只說要甚麼：Playbook 啟用後，專員代理可向申請人索取清單內的材料；申請人只會收到需要哪些材料，代理的理由只給經辦人。新到的圖片先在受理一側描述一次，其他代理只看到這份描述。
• 模型負責調查，人負責決定：案件的 Playbook 可以宣告一名調查員。調查員是模型，閱讀陳述、附件、已回覆的補件和 Playbook 准許讀取的記錄，向簽署人交出固定格式的要點：文件上的數值、經過、封閉清單內的問題（條款按記錄原文引用）、欠缺的文件、值得諮詢的角色。它像一名得力的幕僚那樣提出建議：推薦哪個結果、最多三條理由（引用條款同樣由系統核對原文）、考慮過的其他方案與後果、風險。審批畫面把建議單獨列為「AI 的意見，由你決定」，並標明建議是否與待批內容一致。它不提議金額，也不簽章；建議只會提高風險標記，不會改動要執行的內容，建議與預設結果不同時，快速通道即關閉，由人決定。凡在記錄中有對應欄位的數值，GembaOS 逐一核對並標示「一致」或「不符」；記錄中沒有的條款亦會標明。不符、問題或欠缺要點都是風險標記，只會為路線加人。
• 小額、無標記案件的快速通道：Playbook 可以讓申請人已確認陳述的小額案件由規程規則簽批（規則須經貴司確認），但只限租戶權限表之內，而且包括要點在內沒有任何標記。其餘案件留給經辦人，原因記錄在案。不設調查員的案件，仍可完全由系統受理和起審批單。
• 所需文件由執行平台索取：案件的 Playbook 可以按記錄欄位（例如理賠類別）列明案件必須具備的文件。調查員只負責把檔案歸類；GembaOS 逐一核對檔案是否確實在案，自行計算尚欠甚麼，欠缺所需文件就是風險標記。Playbook 開啟後，由 GembaOS 自行向申請人索取欠缺的種類：受理時及每次回覆後，在 Playbook 的輪數上限內進行，截止日前提醒一次。文件始終未到，就按 Playbook 的設定處理：由經辦人決定、轉交指定角色、以資料不齊結案（並非對理賠本身的決定），或把拒賠交由簽署人決定。單憑逾期，拒賠永遠不會被執行。
• 引用條款須附條文原句：若 Playbook 已列明案件可引用的條款一覽（例如保單的除外條款），也可以一併列明取得這些條文的讀取操作。引用條款的問題因而必須附上原句，GembaOS 會把引文與調查員自己讀到的該條款正文核對：字句在條文內、不在條文內，或根本沒有引文，都會在表單上寫明，除第一項外都是風險標記。條文全文印在引文旁邊，引用的一句另加標示。這項核對只證明字句出自條文，條款是否支持該說法，仍然是人的判斷。
• 對客文字是定型句，可按句開放改寫：工單上的正式回覆是企業自己寫好的定型句，出哪一句由執行平台按記錄判定，模型不參與。Playbook 可以逐句開放改寫：負責改寫的模型只拿到那一句話，看不到案件與記錄；寫好的稿子出門前先核對——定型句裡沒有的數字、過長的稿子，GembaOS 自己就會退回；再由另一個模型把稿子與定型句逐條讀比（結論是否一致、有沒有加事實、有沒有作承諾、有沒有加指示、有沒有越出本件），並且只回報違反條目的編號，不回傳任何文字。不合格的稿子改回定型句；或只告知違反編號重寫一次，仍不合格即改回定型句。工單會標明這是改寫，並可當場展開原定型句，客戶自己就能核對。正式答覆寫明決定內容（例如退款金額）；拒絕時只引用簽署人親手寫下的理由，AI 審查員與專員的話不會給客戶看。
• 客戶再來信，先對上自己的工單：客戶再次來信（包括重新開啟聊天），助手按該客戶自己工單上已核實的事實判斷來意：問進度、補材料、新事項，還是要轉人。問進度即自動回答，不重複開單；回覆裏的每個數字都必須能在事實中找到，另由審查模型檢查有沒有新承諾、改動決定、編造理由或越界透露，不合格就改發定型句。爭議、例外、補償、法律主張與涉及客戶權益的變更，轉為該工單負責人桌面上的待辦，負責人寫的答覆以本人名義回到客戶的工單。
• 內置五個案件台：理賠、採購例外（申請人是員工）、保養更換、公司秘書變更（客戶公司的董事、公司秘書、註冊辦事處或重要控制人變更，以法定限期和客戶盡職審查為事實）與不合格品處置（品質工程師就保留中的一批貨申請照用、返工、報廢或退貨）。申請人只能就屬於自己的記錄開案；別人的理賠編號、產品序號、採購單號、變更申請號或不合格報告號，一律當作不存在。每個案件台都有一名調查員：讀取記錄與附件（包括相片），核對關鍵數值，列出問題並附理由提出建議，例如保養更換從相片判斷是故障還是使用不當，不合格品處置比較照用、返工與報廢三種做法。簽章的人與簽批規則不因此改變。
• 簽的就是執行的：案件做甚麼，由申請人指明的記錄欄位決定（變更類別與表格、建議處置），不由簽署人選。系統在執行前一刻重新讀取記錄；如果簽署之後記錄被改過，審批單即退回，甚麼都不會執行。

一項業務可以在沒有任何 Agent 的情況下開始嗎？

可以，而且這不是另一種模式。作業手冊的每一步都寫明由誰來做——一個人、AI、GembaOS 本身，或企業確認過的自動規則——並有預設值。AI 是其中一種執行者，不是手冊的前提。

• 調查表可以由人來寫：與案件台上 AI 調查員填的是同一張表，以同一方式對照記錄。人寫的內容記在本人名下；GembaOS 不審查人自己的話。
• 申請內容可以由人來填：填寫的欄位受與 Agent 相同的規則約束（不超過記錄上的數值、須在記錄列出的選項之內）；審批單寫明填寫人，填寫人不能為它簽章。
• 執行可以由人來做：簽章齊全、放行令發出後，GembaOS 不呼叫任何系統。工單停在指定職位的待辦，該同事以自己的登入在該系統完成工作，附上手冊要求的憑證、以本人名義回報「已執行」。回報只消耗放行令一次；手冊指定了讀取時，GembaOS 回讀系統並記錄是否與批准內容一致，或僅讀取並記錄；沒有指定時，記錄明寫「只反映本人的回報」。回報「未能完成」則審批單退回。
• 由人執行的操作仍是操作集裡的操作：有欄位、密級與欄位級規則，只是宣告為無人呼叫。手冊若為一個系統也能呼叫的操作指定了人，GembaOS 拒絕載入。
• 路線圖把每一步畫在執行者的泳道；把某一步從人改由 AI（或反過來）的發佈，會在變更清單中單獨列出一行。

參考企業附帶了一項只有人參與的業務——合約蓋章申請：法律顧問讀合約、寫調查表，營運負責人與財務總監簽章，法律顧問動手蓋章並回報台賬編號，GembaOS 回讀台賬。之後把一步交給 Agent，是同一本手冊上的一次發佈。GembaOS 不是流程工具的替代品：賣的仍是四道防線與記錄，人本來就是其中的一種執行者。

資料、產出物與審計記錄如何受治？

GembaOS 把每條記錄都標上密級、業務領域與資料駐留地，並以追記專用的雜湊鏈保存工單的每一項事件。

• 產出物密級標記：Agent 起草的程式碼變更與報告統一管理為受治產出物。程式碼變更集取其觸及檔案的最高密級；產出物離開沙箱（合併、投遞、對外發送）是一項受治動作，經同一套政策判定與審批簽署。
• 會議室與知識邊界：未經整理的會議實時記錄不會直接成為指令輸入；只由書記 Agent 起草紀要，經主持人簽發後才轉化為正式工單。無權訪問的機密文檔回覆「文檔不存在」，與真正不存在時完全一致，杜絕探針式嗅探。
• 會議室的助手以提問人的身份工作：會議裏任何人都可以問助手，助手按提問人本人的權限讀取資料，讀取記在提問人自己的記錄上。只憑會議內容的回答直接發在會議裏，並註明由誰提問；用了提問人權限的回答是只有本人看得到的草稿，由本人原樣或修改後以自己名義發送，或捨棄。助手看得到多少會議內容仍由主持人決定；房間裏不會審批或執行任何動作。
• 會議待辦交給合適的業務：紀要簽發後，每項待辦由助手從負責人有權發起的業務中建議一項，由派發的人確認或改選後才派發；負責人無權發起的業務會被拒絕。
• 雜湊鏈審計記錄：每張工單的事件以追記專用方式寫入，逐條以密碼學雜湊鏈關聯；任何修改、刪除或調序都會使鏈條斷裂，可隨時校驗完整性。雜湊鏈能顯示記錄被改動過；但若有人掌控全部存儲、把整條鏈重寫，雜湊鏈本身擋不住，這正是企業自選的 WORM 存儲或外部錨點的作用。日誌是普通檔案，企業可存放於自選的 WORM 介質以滿足法證與不可否認要求；GembaOS 本身不附帶 WORM 存儲。審計回放用現行政策重跑已記錄的政策判定；它不重跑模型，也不重跑外部系統。
• 決裁路線可出圖、可逐版比對：Playbook 所宣告的決裁路線可輸出為流程圖：給實施與法務的一版是識別子與內核逐字評估的條件，給要點頭的業務的一版是控制台同一套用語——同一張圖的兩種讀法，而且兩者都由配置生成，不是畫出來的，圖不會悄悄與實際運作不符。每一步都標明由誰執行：模型、具名的人，還是 GembaOS 本身（簽章之後由它重讀紀錄並執行）。兩個版本可以逐版比對，每一處差異都帶方向——人變少（或規程可獨自處理的範圍變大）、反之、或角色可見範圍的變動——變更審批因此在送出時就已寫明方向。

如何接入企業現有系統與現有 Agent？

GembaOS 透過模組化 Adapter 把既有系統封裝為標準的受治能力，企業不必重寫架構；同時以雙向 MCP 與現有 AI 助手和 Agent 框架互通。

網店的參考 Playbook 把同一套做法用在價格上：降價幅度決定誰簽。小幅調整自動通過（審批單照樣留在記錄上），八折以內要店舖負責人簽，更深的折扣還要管錢的人簽。寫入價格前系統重新讀取商品；如果簽署後自動改價工具動過價格，審批單即退回。

• 產出方向：把傳統系統封裝為標準 MCP 工具，供企業內部現有的 Claude Code、Copilot 或 Cursor 呼叫；每次呼叫都強制經過四道防線。
• 內置 Agent 由 Playbook 宣告：企業沒有自己的 Agent 時，GembaOS 的對客 Agent 以 Playbook 宣告，不寫程式碼：前台核對哪條記錄、專員讀取哪條記錄、專員可提議哪些欄位，以及每個提議值要對照記錄符合的規則（與記錄相同、不超過記錄、屬記錄列出的其中一項，或等於記錄就另一提議欄位給出的值）。模型看到的工具由這份宣告生成；不符規則的值退回模型，不會進入審批單。簽署之後由平台執行，模型不在執行路徑上。參考 Playbook 有兩個：退款，以及航班改期（所選航班的差價決定誰簽）。專員先查規定（受治知識庫）、看到客戶原話，提交時附上建議：應執行、不應執行，或應由人判斷；提議超出可退範圍時，系統告知範圍讓它重新提議。建議與自己的提議不一致時，無人簽章的檔位即關閉。
• 外部編碼助手（選用）：企業若已有自己的編碼 Agent，可讓它為程式修正出草案。它接成能力而非角色——角色能蓋章，能力不能。它只看得到修正計劃已宣告的檔案（與模型同一條讀取路徑，機密路徑照樣拒絕），沒有執行權、沒有放行令；唯一產出是一段修改文字，之後照樣走原來的校驗、CI 與審批。它由企業自己在內網執行，原始碼不出租戶。它是外部系統呼叫，與呼叫 CRM 的 REST 同級：它內部如何得出該草案，不在可回放範圍內——記錄的只有輸入與輸出的雜湊；要啟用的 Playbook 必須明示這一點。
• 接入方向（BYOA）：企業基於 LangGraph、Dify 等框架開發的 Agent，只需把工具端點指向 GembaOS 閘道，不改動編排程式碼即獲得審批與放行令保障。

SOP 還沒整理好，能先啟動嗎？

GembaOS 的缺口登記冊讓企業在沒有完美 SOP 的前提下安全啟動：Agent 遇到未定義的規程或權限邊界時，只報缺、不越權。

1. Agent 執行任務時遇到未定義規程或邊界，記錄缺口並附上建議規程草稿，不作猜測。
2. 缺口登記冊把同類缺口自動合併，定期匯總至對應部門負責人的桌面。
3. 主管在審定台以通行密鑰審批；通過的規程進入受治知識庫，缺口閉合。

在日常運行中，Agent 由此主動幫企業把散落的隱性知識整理為結構化的合規資產。

可以先描述公司怎樣運作，再由 GembaOS 生成規則嗎？

可以。GembaOS 的規則有三個起點：事先自己設計（直接編寫設定檔，或把平台內建文件交給外部編碼助手）、在控制台用自己的話向組織設計助手描述工作如何進行，或在公司指定的瀏覽器應用程式裏示範一次。三條路都會產生規則發佈草稿，走同一套校驗與第二人批准。示範只是觀察記錄，不會自行變成公司規則；負責該規則的人須確認確切文字。瀏覽器記錄工具仍是原型，也不會重播點擊。

1. 由空白開始。 新公司只帶平台自己的安全底線與語言包；審批人、負責人、權限表一概留空，不預填任何客戶日後才發現原來是平台代定的數值。設定清單按現有設定推導下一步。
2. 每一處改動都有原話。 助手先讀內建文件與現行設定，再起草；草稿裏每個改動的檔案都要附一句逐字引用管理員原話的依據，平台核對這句話確實出自管理員，否則不起草。生效日期同樣要有原話。
3. 平台即時校驗。 草稿即時編譯：版本是否遞增、哪些地方比之前寬鬆、組織變更（審批人、團隊、權限表、各角色可用的操作、誰可以看到哪些資料）與影響範圍，逐項列出。
4. 仍由人批准。 助手不能發佈，也不能改自己的模型設定或管理員的設定；草稿由管理員提交、另一人批准。可以定生效日期：先批准，到期由平台自動發佈。
5. 逐步完善。 之後每次補充——加一個防欺詐小組、限制客服看到支付資料、下月起調高自動處理的上限——都是一份新的草稿，差異與方向照樣列明。

平台另備一套情景測試：管理員原話、助手的回答（真實模型錄製，或刻意寫壞的紅隊回答）與期望性質；性質從平台對草稿的實際編譯讀出，不看模型怎樣描述，離線可重跑。

可以由做這項工作的人親自示範，而不必先寫成文件嗎？

可以，目前限於在瀏覽器裡運行的應用程式。除了事先寫規則、用話描述，GembaOS 還有第三個起點：員工照常把一件事做一遍，GembaOS 協助把它整理成有人負責的規則。觀察工作、由此草擬流程，並不是新鮮事；GembaOS 做的是記錄之後的部分——示範本身不會變成規則，要由負責這條規則的人確認；它進入運行中的公司，也只能是一份規則發佈草稿，走同一套校驗與第二人批准。筆記〈示範一次〉以參考用的訂單畫面逐步走一遍。

1. 哪些應用程式可以記錄，由公司宣告。 員工在控制台按「示範這項工作」，寫下工作名稱，從公司宣告的應用程式清單中選定要記錄的（員工不能自行加入）；公司也可以宣告不記錄的欄位。平台發出一個只可用一次、兩小時內有效的記錄碼。
2. 只看、不能動的記錄工具。 瀏覽器擴充功能只在選定應用程式的頁面上，記錄員工在畫面上做的事——到過的頁面、頁面按欄位名稱顯示的內容、用過的控件與填入的值。密碼欄位，以及頁面標明為信用卡資料或一次性驗證碼的欄位，一律不記錄；Cookie、瀏覽器儲存的資料、網絡內容與剪貼簿同樣不碰。它沒有點擊、輸入或跳轉的能力。離開選定範圍（轉到別的網站、暫停）只留下一段「未記錄」的空檔，不記內容。傳送前，員工逐步檢查、可刪除任何一步，再決定傳送或捨棄；平台收到後，仍按公司宣告的範圍再核對一次，不信任記錄工具。
3. 記錄是「畫面上看到的」，並如實標明。 記錄以「觀察所得」保存並附哈希，它不證明系統實際處理了甚麼——頁面顯示「已提交」，不等於已付款。記錄內容存放在工單事件鏈之外，鏈上只留來源、時間、數量與哈希。員工送出後可以撤回記錄，據此整理的版本一併刪除，已確認的規則保留；公司可設定保留日數，到期自動刪除，預設是保留到員工撤回為止。
4. 「我理解的流程」。 員工的助手把記錄當作資料閱讀，提出業務步驟（每一步都對應到記錄裡的步驟）、帶著「仍未清楚之處」的規則候選，以及最多三條問題，先問會不會付錯錢、要不要由人決定。平台丟棄沒有記錄依據的項目；凡是在其他系統寫入的步驟，在該系統接入之前一律標明仍由人處理；規則只有引用了員工自己的回答，才算「已有說明」；頁面上的數字由平台數出。「不知道」「只是這一次」也是有效的回答。助手只會收到公司宣告的資料上限、以及模型獲准處理的資料域所容許的內容；沒有接上模型時，只按畫面把步驟切開並如實說明，步驟與規則由員工自己寫。
5. 規則屬於負責人，不屬於示範者。 規則在確認前只是候選。公司可以按應用程式指定對其規則負責的職位（例如退款的客服主管），沒有指定就由示範者的直屬上司確認；示範者不能確認自己示範出來的規則。確認只對當時的原文有效，改一個字就要重新確認。負責人撤回確認後，依據這條規則起草的發佈草稿既不能批准，也不能發佈。
6. 由確認的規則到發佈草稿。 組織設計助手可以引用一份示範記錄中已確認的規則，連同確認時仍未清楚的地方與記錄上尚未解決的事項；批准人在發佈頁看到「負責人在示範記錄上確認的規則」，以及確認人的姓名與職位。助手還要說明每個示範步驟落在哪裡：公司已有的操作、某個簽章、已確認的規則、尚未接入的系統，或仍由人處理。平台只接受合適的落點——會改動系統的步驟只能落在經審批路線的操作上，所以示範出來的寫入不會在沒有簽章的情況下執行；其餘留給人，並註明原因。
7. 批准人看到甚麼。 發佈頁並排畫出受影響路線的變更前後；可以在不接觸正式系統的環境裡，用這份草稿的檔案試行受影響業務所聲明的案例（模型是按腳本應答的替身，外部系統只用測試資料）；並接收第二人提供的保留案例——提供者既不是起草人，也不是示範者——按候選規則與現行規則並排判定，再列出規則條件所分出的各種情形（例如金額在上限以下、剛好在上限、超過上限）哪些已有案例、哪些還沒有。案例給出之後檔案若再改動，就不再算保留案例。之後仍是第二人批准、平台發佈。
8. 可以由多人示範同一項工作。 由發起人指定，最多十人：各人用自己的記錄碼記錄，只能撤回自己的記錄；模型只知道「第幾位示範者」，不知道是誰，因為記錄之間的差異可能只是某個人的習慣；這些人都不能確認規則，也不能提供保留案例。

目前還做不到的。示範只涵蓋在瀏覽器裡運行的應用程式，記錄工具是原型階段的瀏覽器擴充功能，桌面應用程式尚未能記錄。示範是員工的經驗，不是授權：一次記錄不會變成公司規則，某人在系統裡做得到的事，也不會變成別人的許可。沒有把操作重放成自動點擊的做法：寫入留給人，直至該系統以受治理的操作接入；讓 Agent 執行示範出來的步驟，不在這一項之內。記錄內容存放在公司自己的儲存，檔案權限受限；公司也可以設定用自己保管的密鑰，把這些檔案加密存放（設定了才生效，密鑰不與資料放在一起）。其餘資料的靜態加密依公司自己的磁碟加密。試行驗證的是 GembaOS 的判定，不是模型的理解；保留案例只覆蓋規則裡寫明的條件，幣種、已退款、重複提交等仍由聲明案例承擔。已送給模型供應商的內容，按該供應商的保留條款處理。

管理者日常怎樣運營？

四道防線回答「這個動作可不可以做」。管理者每星期還要回答：公司有哪些 Agent，它們接了甚麼，改一條規則會怎樣，風險在哪裏，憑證用了多久。GembaOS 為這些問題各提供一個主控台頁面，全部由設定與記錄推導而非另外維護清單，沒有一個數字往上湊。文章管理者看的六個畫面附圖走其中六個。

外面的規則改了，公司哪些業務會受影響？

法規、集團政策、供應商條款、價目表——外面發佈的文本改了，企業要回答的不是「改了甚麼」，而是「我們哪些業務受影響、適用不適用、誰負責改」。GembaOS 把這件事拆成幾個通用件，任何一種外面的文本都走同一條路。

• 關注來源：知識庫的來源可以是目錄，也可以是 https 網頁；任何來源都可以標為「關注」。掃描發現文檔新建、改寫或已批准文本有變化時，GembaOS 發出一條內部信號，由信號的宣告決定開哪項業務、替誰開，同一份文檔一天內只開一次。網頁只取正文，與檔案一樣先成為草稿，變更在審定前不會生效。
• 平台讀自己的設定：三個只讀操作——每項業務的說明及其每一步由誰來做（包括沒有 AI 的業務）、哪些業務引用了某份文檔或某個操作集、已批准文本與待審修訂的逐行差異。三者都是由 GembaOS 自己的宣告計算出來的表，沒有模型參與。
• 調查員受表約束：AI 閱讀差異與全部業務說明，交出受影響的業務。平台的引用表是下限：漏了引用該文檔的業務即標為「不符」，寫了不存在的業務同樣「不符」；有不符即關閉所有自動檔位。差異行數與變動章節同樣逐項對照。
• 有名字的決定記入決定台賬：合規責任人簽署是否適用（需要時先會簽法務），決定記入通用的決定台賬，釘住簽署時所見修訂的雜湊，寫入前平台再讀一次。同一決定重複即拒絕；改變主意要開一張新的審批單，而不是改舊記錄。
• 按受影響的業務逐一開單：每項受影響的業務各得到一張改規則的任務，交給該業務自己的負責人。任務可以全由人完成：負責人寫改法、合規簽署、資訊科技部以發佈落實並回報發佈編號，平台回讀該業務的說明。工單頁列出這條鏈：來源文檔、影響審查、決定台賬記錄、各項任務。

參考租戶裏的「法令・規程變更影響審查」就是這樣一本作業手冊：它沒有自己的程式碼，只有設定與四種語言的詞條。換成集團政策或價目表，另寫一本手冊即可。

與合規標準如何對應？

GembaOS 把主流網絡安全、人工智能與金融監管標準的控制項要求，對應到已實現的機制；此對應由我們自評，未經審計機構監修。截至 2026 年 10 月 1 日，GembaOS 未取得 SOC 2、ISO 27001 或 ISO 42001 等第三方認證。我們提供設計與測試證據，評估由企業及其審計師作出。

六週試點怎麼做？

GembaOS 以標準化的六週路徑驗證業務價值，把組織阻力降到最低；這就是 Design Partner 計劃。

各語言的標準術語如何對照？

GembaOS 的控制台、政策與文件在每種語言都使用同一套核心術語；詞彙表給出每個詞的唯一定義。

相關：安全與合規、詞彙表、常見問題。