一個小團隊很容易踩到的狀況
有些小團隊會把客服回覆、進度整理、退款確認拆成幾個 AI agent 或自動化模組。 這裡的「skills」是指會在指定事件發生時，自動接手某段任務的模組。
有時候一個事件會這樣出現：
- 客服回覆、進度整理、退款確認都在同一個事件上可被叫起
- 2 個以上 skills 都能改狀態欄位
- 團隊又想全自動化，結果卻經常是誰先誰後不一致
這不是「模型比較笨」的問題。
真正問題是事件邊界還沒清楚，導致多個 skills 在同一點「搶著執行」。
一個先驗原則
仲裁是保險；最強的方法是減少衝突源頭。
- 先把事件的啟動入口變單一
- 先把重複觸發條件刪掉
- 先把「能寫」權限收斂到最少個 skills
- 先把流程設計成少競爭、互補合作
不建議你先做的 3 件事
- 不要先做複雜仲裁規則來「兜」混亂流程。
- 不要依賴「最後寫到就贏」來決定結果。
- 不要讓多個 skills 都具備同一高風險欄位的寫入權限。
上線前 4 步：把衝突降到設計端
| 步驟 | 你現在就做什麼 | 通關條件 |
|---|---|---|
| 1. 先定事件邊界 | 列出共享事件、觸發來源、啟動責任；每個同類事件只保留一個主入口 | 每個同一類事件只對應一個啟動責任 |
| 2. 先移除重複觸發 | 找出同一事件同時啟動的情形，合併或下線重複條件 | 不再有同事件可同時起兩個主要 skills |
| 3. 先收斂責任歸屬與寫入權限 | 每個高風險欄位只保留一個可直接寫入的 skills，其他 skills 只保留讀取，或僅能提出建議 | 任一高風險欄位僅保留一個寫入責任者（skills） |
| 4. 先重設流程順序 | 以一主一輔模式設計流程：主 skills 決定寫入，其餘只補資料；仲裁保留為最後的備援（備援機制） | 清楚定義「誰執行、誰不執行、誰接手」，仲裁只留給少量例外 |
1. 先定事件邊界：把「同一件事」只留單一路徑
事件同時有網路回呼（webhook）、排程任務（cron）、訊息佇列（queue）等多入口時，最容易變成競爭點。
- 首先把所有事件來源逐一列出並命名，並在事件鍵上固定到「一件事一入口」
- 以
ticket.updated、refund.alert類型做正規分組；每個鍵只放一個主執行 skills - 先做一次 2 週抽樣，確認是否還有「同事件走不同入口」的案例
2. 先清掉重複觸發：在實際上線前先阻斷
很多衝突是條件名字不同但結果相同。
- 檢查最近 14 天重複啟動事件，從原始日誌抓出「同事件同秒出現的起始紀錄」
- 對可合併條件立刻做歸併，先把它們整理成同一條規則，不能併在一起的先臨時停用
- 設「重複觸發」停止條件：任一事件在同一類事件中只允許 1 個主要 skills
3. 先收斂責任歸屬：縮小可寫範圍
不要先調權重與仲裁，先調寫入邊界。
- 列出所有可改欄位並標註高風險程度
- 對高風險欄位只保留 1 個可直接改值的 skills（寫入責任者），其餘改為只能讀取，或只能提出建議
- 當缺少對應編號（能把同一筆資料對起來的編號）、版本不一致、或人工介入中，直接阻擋自動寫入
4. 先重設流程順序：把比賽改成接力
流程設計要從「誰先到」改成「誰該接手」，才不會用仲裁修補。
- 固定主 skills 為執行者，其他 skills 只補上下文與證據
- 在判斷不清楚時，直接暫停並交接給人工確認
- 留下審計欄位：
primary_skill、blocked_by、handoff_to
仲裁只做備援（最後預備方案）的原因
某些場景短期仍難完全拆開，例如法務界線、舊流程難改。
這些情況可保留仲裁，但要做成例外：
- 明確優先序
- 不明確直接阻擋
- 觸發人工接手
但仲裁必須永遠是「最後手段」，不是主流程。
用日常來理解
- 先把事件進場通道收斂成一條主路徑，避免同一事件被多個技能同時搶進。
- 將重複啟動條件先下架，降低同一事件同秒重複起動的可能。
- 高風險欄位只留單一寫入責任，其他技能只做建議或只讀。
- 只有不可避免重疊場景才進入仲裁並轉交人工，平日流程保持簡單。
結論
若目標是穩定，小團隊最省力的做法是：
- 先把事件邊界定到位
- 先清掉重複觸發
- 先收斂責任歸屬與寫權
- 先重整流程，降低 skills 同場競爭
- 只在不可避免重疊時，啟用仲裁備援
先把衝突從源頭降下來，才不會把仲裁推成日常作業。
