案例研究：門市缺貨 → 跨店調撥（使用者視角）

《門市缺貨 → 跨店調撥》這篇案例研究是從 Odin | Asgard Studio 的角度，介紹管理者怎麼建立跨店調撥 Agent、掛載它能查詢的 Semantic Model 與治理閘門。這篇接著同一個零售 Demo 專案，改從 Sindri 使用者的角度看：業務同仁完全不需要知道 Agent 是怎麼建出來的，只要在聊天視窗裡問一句話。

情境

營運人員登入 Sindri，切換到零售 (IaC) 這個 Project，畫面上列出跨店調撥、商品洞察、促銷分析、補貨採購、門市營運五個已發布的 Agent。他不需要判斷該找哪一個，直接在對話框輸入：

信義旗艦店那顆明天就要斷貨的聯名鈦保溫瓶（SKU-8801），哪些門市有多餘庫存可以調撥？各能撥多少？

Sindri 委派給跨店調撥 Agent

送出問題後，Sindri 判斷這個請求該交給哪個 Agent，畫面上依序出現 Thought for a moment 的處理提示、自動產生的對話標題 SKU-8801 跨店調撥分析，接著 Subagents 面板顯示委派給 allocation（對應 Odin 那篇案例研究裡的跨店調撥 Agent），並即時查詢它掛載的 Semantic Model。

幾秒後回覆完整的分析結果：信義旗艦店現貨、安全庫存、日均銷速與預估斷貨時間，接著是全通路可調撥總量（102 件），以及依優先序排列的各門市可調撥量與調撥後覆蓋天數。最後 Agent 沒有直接動手建調撥單，而是提出三個方案（A：前三順位、B：全部門市、C：自訂）並等使用者確認要採用哪一個。

治理閘門：在聊天視窗裡實際核可

使用者接著回覆：

執行方案 A，建立前三順位調撥單

Agent 準備呼叫寫入系統的工具，這一步就是跨店調撥 Agent 設定裡提到的治理閘門，在 Sindri 這一側是一個核可對話框：寫明要呼叫的工具集（ts-wms）與工具（create_transfer_order）、可以展開查看的實際輸入內容，以及目前是第幾個待處理的工具呼叫（例如 1 / 3）。使用者可以選擇本次對話皆允許、僅此次允許或拒絕。

三筆調撥單（板橋、竹北、花蓮）逐一經過核可後，Agent 回報執行結果：每一筆調撥單的單號、來源門市、目的門市與數量，並附上調撥後信義旗艦店的庫存預測（調入 86 件後可覆蓋約 2.0 天），最後主動提醒調撥只能爭取到約 2 天緩衝，建議同步啟動補貨採購，並詢問是否要接著評估補貨方案。

這個案例展示的重點

• 使用者不需要知道背後有哪些 Semantic Model、哪個 Agent 負責什麼，只要用自然語言描述問題，Sindri 就會依 Agent 的委派說明自動轉發。
• 查詢與分析（讀）由 Agent 自主完成；會異動系統資料的動作（寫）一律停在治理閘門，讓使用者在聊天視窗裡就能看到工具名稱、實際輸入內容，並自行決定允許或拒絕，不是送出後就直接執行。
• 同一個 Agent、同一組治理閘門設定，在 Odin 是管理者眼中的建置細節，在 Sindri 則是使用者眼中一個會主動提醒風險、等待核可才動手的助理。