常見問題

可以。缺口登記冊會記錄未定義的手順與不清晰的邊界。Agent 可草擬建議，但須經負責人審閱和批准，才會成為正式業務規程。

缺口不會擴大 Agent 的權限。在有人批准之前，任何 Agent 都不能引用該草案；遇到缺口的工單會等待台賬上指定的負責人。

不需要。Gateway 模式支援接入既有 Agent。將支援的工具呼叫或 MCP 連接經由 GembaOS 處理即可；具體介面與 Adapter 需求會在示範時確認。

Agent 的編排邏輯保持不變。改變的是，敏感的工具呼叫不再直達業務系統，而是先到能力閘道，由政策判定，需要時等待人手簽章。

不會。低風險查詢及額度內操作可自動放行。只有授權表規定須審批的操作，例如超額退款或生產特權變更，才會交由負責人決策。

路線由政策決定，而非由 Agent 決定。額度內的退款憑 Agent 簽章通過；同一宗退款超出額度，就會變成交財務負責人的審批單。兩條路線的記錄格式相同。

可以。可採用本地或私有 VPC 部署，配合自託管模型。如選擇雲端模型或外部系統，則會產生對外資料路徑，須按實際需要配置，包括適用的欄位遮蔽措施。

每個租戶、每個 playbook 都可以設定上限：哪一類模型供應商可以看到哪一類資料。自託管模型與 SaaS 模型可按資料敏感度混用，而不是按角色劃分。

架構師會全程協作。設定階段需 IT／維運窗口參與，影子模式需指定業務負責人進行審批。實際投入視系統連接而定，會在試點範圍確認時議定。

不會。GembaOS 是治理執行平台，不是編排框架。它決定一個動作可否執行、誰須審批，並在放行令之下只執行一次；Agent 如何推理和規劃，仍由框架負責。

以 LangGraph、Dify 或 CRM 供應商建立的 Agent，都經同一個閘道呼叫 GembaOS。無論 Agent 以哪個框架建立，治理路徑都一樣。

執行會停下。治理內核在呼叫業務系統之前，重新讀取現實狀態，與簽章的人當時看到的事實比對。若比對項目已經改動，動作不會執行，放行令作廢，工單連同這項改動的記錄退回重新判斷。

參數本身也由同一套機制守住：每張放行令綁定已批准參數的雜湊值（argsHash），參數不同的呼叫與放行令不符，不會執行。上限值在寫入前向持有該上限的系統重新讀取；放行令設有有效期，等太久的審批不再授權任何事。

不會。放行令只能用一次，而寫入的冪等鍵由治理內核依審批單與工單產生，不是由 Agent 提供。因此重試、重送或重新啟動之後，落地的仍是同一筆寫入，而不是第二筆。

已批准的動作執行期間，目標記錄會被押住，不讓其他已批准動作同時寫入；各 Adapter 亦須聲明其寫入如何防範並發變更（版本號、條件寫入，或對記錄加鎖）。

外部內容一律視為資料，不是授權。電郵、聊天訊息、日誌行或圖片內嵌的指令都不能授予任何能力，因為允許動作的決定由模型以外的政策作出。

疑似注入的內容會在工單上標記為可疑輸入；帶標記的動作不論 Agent 提議甚麼，都會交由人手處理。圖片只在 playbook 允許時才會送到模型。

任何有支援 Adapter 的模型，自託管或雲端皆可。政策判定、放行令與審計記錄都在模型之外，因此更換模型不必改動規則；影子重放與黃金測試可在上線前顯示新模型會怎樣做。

一個附有自己資料目錄的 Linux 單一二進制檔案，運行於貴司控制的伺服器。控制台以 TLS 提供，或置於貴司反向代理之後；透過 Adapter（REST、檔案、SQL、以雙向 TLS 連接的 worker）接入業務系統。運作不需要任何外部服務。

對象不同。MCP 閘道或 AI 閘道決定模型可以取用哪些工具與哪些資料；GembaOS 決定 Agent 提出的動作可否執行、由誰簽署，並在放行令下執行一次。兩者可以並用。

GembaOS 也有欄位級的讀取規則與資料送出上限，但它保存的記錄是審批單：核實過的事實、確切的參數、簽署，以及可重放的事件鏈。

工單負責人可以會簽另一角色（先請法務審閱合約條款）、移交給權限不低於自己的角色，或上報給上級；上級也可以接管下屬待簽章的審批單。每個動作都必須寫理由並留有記錄，不會減少任何必需的簽章。

缺席時，由基於員工名錄匯入的組織圖所設的代理規則接手（例如按金額分流）。員工離職時，其待簽章審批單交給最近在職的上級或留待分配，其持有的代理隨之終止。主管可在團隊桌面查看團隊身上的待辦，包括目前無人負責的審批單。

playbook 開啟後可以，但只能按種類索取：病歷、收據、報價等，從 playbook 設定的封閉清單中選取。申請人收到的是需要哪些文件和截止日期；Agent 的理由只給經辦人看。

每次索取都是工單上的一輪補件請求，附截止日期，輪數有上限。逾期會記錄在案，個案不會自行結束。詳見保險理賠審批場景。

是。補件、申請人確認和各部門會簽都在工單上進行；審批單在文件齊全時才起草一次，路線上每人附結論簽署一次。

回到審批單的人會先看到自上次查看以來的變化與唯一剩餘決策。若結論要求補件或退回經辦人，重新提交的仍是同一張審批單。