02 / 典型場景
工作跨部門流轉，責任始終有據可查
GembaOS 是企業 AI Agent 的治理執行平台：以政策判定權限、以綁定參數的單次放行令授權每一個動作、以可追責的簽署鏈記錄人的審批，部署於企業本地機房或私有 VPC。此場景是跨部門業務：一份名單由一個部門送出，另一個部門的 Agent 據此行事，問題在於每一行由誰負責。
工作在部門與 Agent 之間流轉，如何不失去負責人？
GembaOS 為整個工作流程保持一張持續的工單，每次流轉都經政策路由：每個專責 Agent 只收到其角色可見的脈絡，每項決定都落到該步驟指定的負責人手上。多行的名單變成一張彙總的審批單；負責人簽章一次；每一行在自己的放行令下執行。
| 導入前 | GembaOS 做法 | |
|---|---|---|
| 交接 | 附試算表的電郵，轉發兩次 | 載有名單、來源與每次流轉的工單 |
| 脈絡 | 每個 Agent 看到全部 | 職責分離：每個角色只看自己的欄位 |
| 決定 | 轉發者的一句「請處理」 | 指定負責人在變更前的事實上簽章一次 |
| 名單中的錯字 | 整批失敗，或動到錯誤的帳戶 | 那一行單獨失敗並回報，其他行照常通過 |
逐步發生甚麼？
| 步驟 | 誰 | 記錄甚麼 |
|---|---|---|
| 1. 接收 | 人事交來月底離職名單；批次頁解析各行 | 原樣的名單，以及解析方式 |
| 2. 預讀 | 主機讀取每個帳戶的現狀 | 每行的事實；讀不到的行如實顯示 |
| 3. 彙總 | 一張載有每一行的審批單 | 負責人將看到的申請 |
| 4. 簽章 | IT 管理員以通行密鑰簽章一次 | 簽署鏈 |
| 5. 放行令 | 每行一張，各自綁定自己的參數 | 四個帳戶四張放行令 |
| 6. 執行 | 逐行執行；失敗只停止自己那一行 | 每次執行及其結果 |
控制點在哪裡？
控制點是在預讀事實上對彙總申請的那一次簽章。名單內容不能擴大簽章所覆蓋的範圍：不在申請上的行沒有放行令；預讀之後帳戶已改變的行會被退回而不執行。流程所欠缺的東西，例如缺少的交接規則，會收集到缺口台賬，留待負責人日後補上。
控制台看起來怎樣？
開始需要甚麼？
- 現行的交接方式：名單格式、誰送出、誰處理。
- 各行所觸及的身份或帳戶系統，透過 REST、SQL 或 worker Adapter 接入。
- 按貴司授權表為該類變更簽章的負責人。
- 可選：一個工單系統，讓每個批次鏡像過去，記錄出現在團隊平日查看的地方。
最後更新: · GembaOS v0.2