常見問題

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

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

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

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

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

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

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

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

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

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

以 LangGraph、Dify 或 CRM 供應商建立的 Agent，都經同一個閘道呼叫 GembaOS。GembaOS 亦附有自己的 Agent 迴圈，供未有框架的團隊使用，但治理路徑並不依賴它。

動作會被拒絕。GembaOS 把每張放行令綁定到已批准參數的雜湊值（argsHash）。參數不同的呼叫與放行令不符，不會執行，而不符的記錄會寫入工單。

放行令同時是單次和限時的。執行已批准的動作會消耗放行令；用同一張放行令再試第二次，同樣會被拒絕。

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

疑似注入的內容會在工單上記為一項具類型的關注事項。主機把它變成風險標記；帶標記的動作不論 Agent 提議甚麼，都會交由人手處理。圖片在接收時重新編碼，只有在 playbook 與模型設定同時允許的情況下才會送到模型。

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

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