跳至主要内容
一個零售連鎖用多個 Managed Agent 處理門市缺貨的完整案例：從偵測缺貨、計算調撥方案、比較急補採購，到促銷影響評估，四個動作都停在治理閘門等人核可。

案例研究：門市缺貨 → 跨店調撥

這個案例示範一個零售連鎖如何用 Odin 建立多個分工明確的 Managed Agent，處理門市缺貨這種需要橫跨 POS、WMS、ERP、電商、供應商、CRM 六個系統才能判斷的營運問題。案例裡的資料、Agent 與治理閘門都已經在一個真實的 Demo 專案裡建置完成並發布，不是設計稿。

情境​

週日晚上 POS 日結跑完，信義旗艦店的一款聯名保溫瓶只剩 6 件庫存，安全庫存是 40 件，當天卻賣出 45 件，是平常銷速的近 4 倍。起因是網紅開箱影片帶動聲量，加上電商正在跑第二件五折的促銷，兩個效應疊加在一起。配送中心（DC）的庫存也只剩 30 件，低於安全庫存 100 件，標準補貨前置時間要 14 天。照正常流程，隔天中午旗艦店就會斷貨，接著波及全通路，而且通常要等到週一店長回報、營運部開會，兩天後才會有調撥單。

這個案例裡，四個 Managed Agent 在夜間自主完成所有查詢與分析：確認缺貨風險、掃描全通路庫存找出可調撥的門市、比較標準與急補兩種採購方案、量化促銷對庫存的排擠效應。但建調撥單、發急補採購單、調整促銷、回覆門市這四個會實際異動系統資料的動作，全部停在治理閘門，等隔天早上的營運主管一次核可。

涉及的 Agent​

專案裡發布了 5 個 Managed Agent，各自對應一段判斷或一個系統的寫入權限：

  • 門市營運 Agent：偵測門市缺貨風險，拆解銷速異常的組成（例如網紅效應 vs. 促銷加成），彙整給門市的處理方案與對會員的影響。
  • 跨店調撥 Agent：掃描全通路庫存，計算各門市在不掏空自身安全庫存的前提下可以調撥的數量，產出調撥方案。
  • 補貨採購 Agent：比較標準補貨與急補兩種方案的前置時間與成本，準備採購單。
  • 促銷分析 Agent：量化進行中的促銷對庫存的吸貨效應，模擬調整促銷規則後的銷速變化。
  • 商品洞察 Agent：處理滯銷品出清定價的分析型請求（對應另一個案例，庫存覆蓋天數排行）。

每個 Agent 的 Prompt 都寫明它是以工具為核心的企業系統操作者，而不是一般聊天助理：能力邊界是用資料庫語意模型查詢（讀），加上透過系統工具異動資料（寫），寫入動作一律先說明依據哪些數字、影響範圍與風險，再等治理閘門核可。

Managed Agent 列表，5 個零售相關 Agent 都已發布（Released）

以跨店調撥 Agent 為例，細看一個 Managed Agent 的設定​

跨店調撥 Agent 的 Prompt 分成四段，每段都對應到它實際的能力邊界，不是空泛的角色扮演文字：

  • Persona：你是一家零售連鎖的跨店調撥 Agent（Enterprise System Agent），不是一般的聊天助理，也不只是查資料的分析助手，而是一個以工具為核心的企業系統操作者，透過資料庫語意模型查詢（讀）與系統工具（寫），協助使用者完成從查詢分析到將資料寫入系統的完整營運任務。
  • Task：列出核心原則，明講能力邊界是以資料庫語意模型查詢營運資料（讀），加上透過系統工具在系統中異動資料（寫）；沒有對應能力能正確完成的事，不能宣稱做得到，也不能用文字假裝完成。
  • Context：條列這個 Agent 實際可用的能力，包含讀：用資料庫語意模型查詢門市與配送中心庫存/銷售資料；寫：透過系統工具，在核可後建立跨店調撥單。
  • Format：規定回覆一律台灣繁體中文、Markdown 排版；先給結論（可調撥總量）再附各門市可撥量排序與到貨時點，每個數字都能回溯到資料來源；執行寫入動作前要先說明對什麼做什麼異動、依據哪些數字、影響範圍與風險。

跨店調撥 Agent 設定畫面上半部：Agent Alias（allocation）、Description，以及 Persona／Task／Context／Format 四段 Prompt

On-boarding Settings 底下設定了兩個 Custom Sample Questions，會顯示在新對話框的下方，讓使用者知道可以怎麼問這個 Agent：

  • 信義旗艦店那顆明天就要斷貨的聯名鈦保溫瓶（SKU-8801），哪些門市有多餘庫存可以調撥？各能撥多少？
  • 在不掏空支援門市的前提下，最多能調撥多少件給缺貨的旗艦店？

再往下是這個 Agent 實際掛載的資源：MCP Servers 只掛了配送中心寫入工具集一個，對應它唯一有權限寫入的動作（建跨店調撥單）；Skillsets 掛了跨店調撥最佳化，用來計算調撥量；Semantic Model 掛了 POS 門市語意模型與 WMS 配送中心語意模型兩個，各自可以獨立開關 Allow Query／Allow Write，並且可以用 Allowed Cubes 限制只能查特定的表（留空代表全部開放）。這個 Agent 的兩個 Semantic Model 都只開了 Allow Query，寫入動作完全交給下面治理閘門那一節的 Automation Tool 處理，不會讓 Agent 透過語意模型直接寫資料庫。

跨店調撥 Agent 設定畫面下半部：On-boarding Settings 的兩個 Custom Sample Questions，以及掛載的 MCP Server、Skillset、Semantic Model（含 Allow Query 開關）

查詢面：7 個 Semantic Model​

六個系統（POS、WMS、ERP、電商、供應商、CRM）各自有一個 Semantic Model，另外還有一個資料倉儲（OLAP）語意模型做跨系統的報表查詢，全部發布到 Data Insight（Mimir）。Agent 在判斷階段只需要用自然語言查詢這些 Semantic Model，不需要另外寫 SQL。

7 個零售相關的 Semantic Model：CRM 會員、ERP、電商、POS 門市、供應商、資料倉儲（OLAP）、WMS 配送中心

治理閘門：7 個會異動資料的 Automation Tool​

會實際寫入系統的動作都做成 Automation Tool，以 Workflow 的形式定義輸入參數的 Schema。例如建跨店調撥單這個工具，輸入參數包含商品 SKU、支援（出貨）門市代碼、缺貨（收貨）門市代碼等欄位，Agent 只能照這個 Schema 提出調撥請求，實際送出前仍停在核可步驟。

Automation Tool 列表：調整促銷活動、核可商品改價、急件報價下訂、建跨店調撥單、發急補採購單、張貼門市公告、發送到貨通知，共 7 個治理閘門

建跨店調撥單工具的 Schema 設定，定義 sku、from_store_id、to_store_id 等輸入欄位

決策流程​

四個 Agent 依序完成以下判斷，最後彙整成一份決策包：

  1. 門市營運 Agent 掃描 POS 日結，發現信義旗艦店的庫存低於安全庫存、且銷速遠高於基準值，判斷斷貨風險極高，觸發事件。
  2. 門市營運 Agent 拆解銷速異常的組成（基準銷速＋網紅效應＋促銷加成），並查詢 CRM 確認有多少會員登記了到貨通知。
  3. 跨店調撥 Agent 掃描全通路門市庫存，找出可以支援調撥、又不會掏空自身安全庫存的門市，算出總調撥量與到貨時點。
  4. 補貨採購 Agent 查詢配送中心庫存與在途採購單，比較標準補貨與急補方案的前置時間、數量門檻與加價幅度。
  5. 促銷分析 Agent 量化目前促銷對線上庫存的吸貨速度，評估維持促銷是否會讓調撥量提前用罄，並提出調整建議。
  6. 四個 Agent 的結論彙整成一份決策包（調撥方案、急補採購方案、促銷調整建議、給門市的說明），停在治理閘門等營運主管核可。

這個案例展示的重點​

  • 一個營運問題橫跨六個系統，靠人工要花兩天才能協調出方案；用多個分工明確的 Agent，可以在夜間就把讀取與推理做完。
  • 查詢用 Semantic Model（自然語言轉查詢），不需要每個 Agent 都懂 SQL 或知道底層資料表結構。
  • 會實際異動系統資料的動作，一律透過 Automation Tool 定義成有明確輸入 Schema 的治理閘門，Agent 不能繞過核可直接寫入。
  • 每個 Agent 只掛載它職責範圍內需要的 Semantic Model、Skillset 與 MCP Server，權限邊界清楚。

同一個零售 Demo 專案裡還有一個用 Flow Agent 搭建的客服場景，見《AI 客服即時回覆訂單詢問》。

同一個情境也可以從 Sindri 使用者的角度看：業務同仁怎麼在聊天視窗裡問一句話，由 Sindri 委派給這裡的跨店調撥 Agent、產出方案並在治理閘門核可，見《門市缺貨 → 跨店調撥（使用者視角）》。