詞彙表

工單（Work Item）是 GembaOS 為每一個工作單位保存的持續記錄：誰提出、以誰的名義執行、每個 Agent 回合、每項政策判定、每個簽章與每次執行，依次序以雜湊鏈記錄。

本詞彙表的一切都圍繞工單。一宗客戶申請、一個監控告警、一份貼上的離職名單、一份已批准的會議記錄，各自開出一張工單。

常見問題安全與合規

審批單（Approval Request）是政策判定某個動作需要簽章時，GembaOS 組成的文件：治理內核核驗過的事實、確切參數、理由，以及路線所要求的審批人次序。

審批人在審批台看到的就是這份文件。簽章後，簽發一張綁定文件所列參數的放行令，不會簽發其他任何東西。台灣企業慣稱「簽核」，指的是同一件事。

安全與合規

放行令（Clearance Token）是 GembaOS 為一個已批准動作簽發的單次、限時授權，綁定該動作參數的雜湊值（argsHash）。執行動作會消耗放行令；參數不同就不相符。

正因有放行令，Agent 不需要持有業務系統的憑證：憑證由閘道保管，一張放行令只放行一次呼叫。

常見問題安全與合規

過時的審批，是指簽章當時正確、但到執行時已與現實不符的判斷：記錄被改動、另一個已批准的動作碰過同一條記錄、上限值變了，或單純是等得太久。

這是時間造成的失誤，不是 Agent 出錯。GembaOS 在寫入前重新讀取簽章時的事實與目標系統自身的上限，執行期間押住該記錄，並為每張放行令設有效期，藉此收窄這個時間窗。

常見問題安全與合規

冪等鍵是告訴目標系統「這筆寫入與已接受的那筆相同，不是新的一筆」的識別碼。在 GembaOS 中由治理內核依審批單與工單產生，Agent 無從選擇。

正因如此，即使發生重試、重新啟動後重送或逾時重複，一次審批最多只會變成一筆寫入。GembaOS 內部由只能用一次的放行令負責，目標系統內部則由冪等鍵負責。

常見問題安全與合規

簽署鏈（Signature Chain）是審批單上按次序排列的簽章：政策委託給 Agent 核查的步驟由 Agent 簽章，路線保留給人的步驟以通行密鑰由人簽章。

每個簽章記錄誰、何時、為何、看到甚麼。審計頁會按現行政策重放整條簽署鏈——即台灣企業所稱的「簽核紀錄」。

安全與合規

會簽、移交、上報、接管，是 GembaOS 中人對待簽章審批單可做的四個有記錄的動作：先請另一角色審閱、把簽章交給權限不低於自己的角色、交給上級簽章、上級接管下屬待簽章的審批單。

四個動作都不是簽章，也不會減少必需的簽章。理由記在工單上，最終簽章的人以自己的通行密鑰簽署。

安全與合規常見問題

授權表（DOA）是一張按角色、金額或風險級別，列明誰可以批准甚麼、上限多少的表。GembaOS 的政策讀取授權表，決定一個動作憑 Agent 簽章通過，還是需要指定審批人。

它通常就是企業已有的授權表的轉錄。試點的首兩週用來把它寫下來。台灣企業多稱「核決權限表」，性質相同。

Design Partner 計劃常見問題

代表執行（On-Behalf-Of）是 GembaOS 的一項原則：Agent 的每個動作都以某位指定員工的名義、在該員工的權限之內執行；Agent 不會得到員工沒有的任何權限。

審計員能讀懂記錄，正因如此：行為人是人，Agent 是工具。

安全與合規

能力閘道（Capability Gateway）是 GembaOS 站在 Agent 與業務系統之間的組件。Agent 只看到能力名稱與結構；閘道保管憑證、核對政策、預留及消耗放行令，並呼叫 Adapter。

讀取也經閘道，按欄位級規則進行，Agent 只看到其角色可見的欄位。

安全與合規常見問題

政策重放（Policy Replay）是把已記錄的判定按現行政策重新評估，由相同事實得出相同路線與規則鏈。GembaOS 為每項判定記錄足夠資料，令重放是確定性的。

審計員藉此核對數月前的決定今天是否仍然相同；政策變更亦藉此以歷史記錄測試。

安全與合規

影子重放（Shadow Replay）是把已記錄的工單交給新模型或新配置重跑一次，不執行任何動作，只顯示結果會在哪裡不同。

這是模型變更進入生產前的關卡，也是 Design Partner 計劃的第五週。

Design Partner 計劃

黃金測試（Golden Test）是一段附有預期判定的記錄對話，GembaOS 離線對執行平台重放；任何改變判定的變更都會令測試失敗。

黃金測試與紅隊案例，是與夥伴安全團隊一同檢視的證據。

安全與合規Design Partner 計劃

審計回放（Audit Replay）是從雜湊鏈事件重建工單、再在其上重跑政策的頁面，令路線、規則鏈與簽章可以被驗證，而不是被相信。

首頁各「審計記錄」分頁的畫面，就是這個頁面。台灣企業慣稱「稽核軌跡」，指的正是這條可重放的鏈。

安全與合規

缺口登記冊（Gap Register）是 Agent 登記完成任務所欠缺之物的台賬：欠缺的手冊、未定義的額度、不明的負責人。缺口不會擴大權限；它寫明應由誰決定，然後等待。

建議的規程送到審定台，經人批准後才成為知識。

常見問題Design Partner 計劃

組織設計助手是控制台裏的助手，管理員用自己的話告訴它公司怎樣運作。它閱讀平台內建的說明文件與現行設定，然後提出一份規則發佈草稿；每個改動的檔案都附有管理員原話的逐字引用，GembaOS 核對之後才起草。

它不能發佈。草稿即時校驗，列出比之前寬鬆的地方與每一項組織變更，並由另一人批准。同一份草稿也可以來自手寫的設定，或外部編碼助手。

企業級架構白皮書用自己的話描述公司怎樣運作，就能得到真正執行的規則

示範記錄是員工在公司宣告的應用程式裏把一件工作做一遍時，GembaOS 所保存的內容：畫面顯示過甚麼與本人做過甚麼的記錄、助手由此得出的理解，以及負責人已確認的規則。

它不執行任何東西。記錄只是觀察所得，不證明系統做過甚麼；其中的規則在負責人按原文確認之前只是候選，只有已確認的規則，才能作為規則發佈草稿的依據被引用。

企業級架構白皮書示範一次，變成有人負責的規則

有限發佈是指規則發佈先只對部分個案生效——按申請人比例，或按某些團隊與部門——其餘個案繼續按現行版本處理。新工單在開始時分到其中一個版本，之後一直沿用。

範圍與檔案一起簽批；擴大範圍是另一次須第二人批准的發佈，縮小或收回寫明理由即可直接執行。管理員沒有選用就不會啟用。

企業級架構白皮書這條規則管用嗎？由個案中找答案，經有名字的程序去改

變更集（ChangeSet）是 Agent 在受限沙箱內草擬、以審批單形式提交而非直接套用的生產系統變更。

這就是 IT 維運場景：調查可以自主進行，變更必須經過變更審批。

安全與合規

沙箱（Sandbox）是 Agent 讀取、測試、草擬而不觸及生產的受限環境。沙箱允許甚麼，會記錄在工單上。

程式錯誤的修正在沙箱內準備，只有經覆核的變更集才會經變更審批離開沙箱。

安全與合規

正式回覆（Official Answer）是工單結束時客戶或申請人收到的唯一回覆：由治理內核根據已批准的事實撰寫，與內部審批記錄分開，並引用所用的已批准知識。

涉及分類關注或失敗的執行會得到錯誤回覆，絕不猜測。

常見問題

補件請求（Document Round）是個案經辦人向申請人發出的一輪要求：需要哪些文件（從 playbook 設定的封閉清單中選取）、一句說明與截止日期。申請人在工單頁面或以電郵回覆，附上檔案和一句說明。

每宗個案可發出的輪數由 playbook 設定上限。逾期不會自動結案，只記錄在案，由經辦人決定下一步。審批單要等文件齊全才起草一次，所以補件往來發生在工單上，不會帶進簽署。

保險理賠跨越數星期，審批只需一屏材料不齊怎麼辦：AI Agent 如何規範化發起補件輪次

申請人確認（Applicant Confirmation）是由治理內核呈現 GembaOS 已記錄的內容（申請人的原話、檔案、對象、收件時間），以雜湊值鎖定，再由申請人本人確認。申請人可以確認，或指出哪裏有誤；更正以追加方式記錄，原件保持不變。

若 playbook 規定必須確認，申請人確認前不會起草審批單。審批單會寫明申請人在哪一天確認了這份內容。

保險理賠跨越數星期，審批只需一屏

會簽結論（Consult Finding）是簽署人在簽署前從封閉清單中選取的結論：是否在保障範圍內、治療是否必要、條款是否可接受。結論隨簽署進入簽署鏈，playbook 為每個結論設定下一步。

下一位簽署人簽在結論之上，而不是簽在一段自由文字評語之上。像「報價不足」這類結論可以退回審批單，並向申請人索取指定文件；結論由人選，下一步由 playbook 決定。

保險理賠跨越數星期，審批只需一屏採購例外申請，理由留在記錄上

「自上次查看以來」是審批單上先向每位查看者顯示變化的部分：等了多少天、新增了哪些簽署與結論、新文件、補件輪數、更正、申請人確認。其下是「唯一剩餘決策」。

「唯一剩餘決策」列出待簽的角色、playbook 為該角色設定的問題，以及最近一條仍未決的結論。被簽署的內容不會改變；這是把同一份記錄呈現給兩星期後才回來的人的方式。

保險理賠跨越數星期，審批只需一屏