一家小型網店把客服做了自動化，接了三個 AI 模組：一個負責回覆顧客，一個負責整理訂單進度，一個負責判斷退款。某天一位顧客寫信說「商品壞了，我要退款」。三個模組同時被叫起來：客服模組回信說「已為您安排退款」，進度模組把訂單狀態改成「處理中」，退款模組判斷還缺照片，把狀態改成「待補件」，又寄了一封信請顧客補照片。顧客收到兩封說法相反的信，訂單狀態最後停在哪一個，要看哪個模組最後寫入。
這裡說的「模組」，在不同工具裡有不同名字：skills、agents、自動化流程。共同點是它們會在某個事件發生時自動接手一段工作。
遇到這種衝突，很多團隊第一個想到的是加一套仲裁規則，決定誰說了算。比較有效的做法是回到設計：一件事只有一個入口，每個會被修改的欄位只有一個模組能寫，其他模組只能提供建議。
仲裁規則為什麼越加越多
仲裁規則看起來很合理：退款模組的判斷優先於客服模組，進度模組最後才寫。但規則一多，就得處理規則之間的例外：如果退款模組還沒跑完，客服模組要不要等？如果兩個模組幾乎同時寫入，誰算先？每一條新規則都在替原本不該發生的競爭收拾善後。
更常見的做法是「最後寫入的算數」，因為它不需要任何設計。問題是，最後寫入的那個不一定是對的，只是剛好比較慢。
衝突從兩個地方來
第一個來源是重複觸發。 同一件事從好幾個入口進來：顧客寄信觸發一次，客服系統建立工單又觸發一次，排程每五分鐘掃一次未處理案件再觸發一次。三個入口名稱不同，處理的卻是同一件事。很多「模組打架」，其實是同一個模組被叫了三次。
第二個來源是多個寫入者。 訂單狀態這個欄位，三個模組都有權限改。只要有兩個以上的模組能寫同一個欄位，衝突就只是時間問題。
這兩個來源都是設計造成的，跟模型聰不聰明沒有關係。Microsoft 在整理多 agent 協作模式的架構指南裡提醒，當多個 agent 同時處理同一件事，卻無法可靠地協調對共用狀態或外部系統的修改時，就不該讓它們同時跑；它也建議，如果單一 agent 搭配工具就能可靠完成任務，優先用這種較簡單的做法。Anthropic 在說明如何打造 agent 的文章裡也有類似的建議：先找最簡單的解法，只有在確實能改善結果時才增加複雜度。
一個入口、一個寫入者
所以，修衝突要從源頭著手，順序是這樣的。
先讓一件事只有一個入口。 把會觸發模組的來源全部列出來，找出名稱不同、處理同一件事的那幾個，合併成一個。同一件事被重送時，系統要認得出來。這在付款系統裡是成熟的做法：Stripe 讓每個請求帶一個唯一的識別碼（idempotency key），同一個請求重送時，系統會回傳第一次的結果，而不是再做一次。AI 模組的事件也可以比照：每個事件帶一個編號，同一個編號只處理一次。
再讓每個欄位只有一個寫入者。 把會被修改的欄位列出來，標出哪些做錯了後果嚴重：訂單狀態、退款金額、寄給顧客的信。每一個這樣的欄位，只留一個模組能寫。其他模組可以讀、可以提建議，但不能直接改。
最後把競賽改成接力。 回到網店的例子：退款模組當主模組，負責判斷並寫入訂單狀態、決定要不要寄信；客服模組和進度模組只把它們看到的資訊交給退款模組。顧客只會收到一封信，訂單狀態也只有一個來源。
仲裁還有用，但只用在例外
有些情況短期內確實拆不開，例如舊系統很難改，或兩個部門各自負責同一個欄位的不同部分。這時仲裁仍然需要，但要當成例外處理：優先順序寫清楚，判斷不了就停下來交給人，而且每一次動用仲裁都要記錄下來。仲裁被動用的次數，就是設計還沒修好的地方。
這個做法也有代價。只留一個寫入者，代表這個主模組一出錯，就沒有別的模組能自動補救；所以主模組的失敗要能被偵測，並轉給人處理，而不是讓其他模組搶著接手。
可以先挑一個最常出問題的事件，問兩個問題：這件事從幾個入口進來？它會修改的欄位，各有幾個模組能寫？答案都是「一」，這個事件就不太需要仲裁。如果 AI 模組是從第三方安裝的，安裝前還有另一層要檢查，參考〈AI agent 擴充工具掃描過了還不能裝，因為風險在它跑起來之後〉。流程跑到一半出錯要怎麼收拾，參考〈自動化卡在半途，先查清楚再決定能不能重跑〉。
AI 整理卡
請 AI 幫你找出一個事件的入口與寫入者 這段提示詞會先問清楚哪個事件會叫起多個模組，再逐一列出入口和每個欄位的寫入者，最後建議如何改成一個主模組負責寫入。
我的自動化流程裡，有一個事件會同時叫起多個 AI 模組（skills、agents 或自動化流程），結果常常互相衝突。
判斷方法來自這篇文章：https://boosterminiclass.com/posts/ai-agent-skill-conflict-prevention/
文章的看法是：衝突主要來自兩個地方，同一件事從多個入口進來，以及同一個欄位有多個模組能寫入。修法是一件事只有一個入口、每個重要欄位只有一個寫入者，其他模組只提供建議；仲裁只留給拆不開的例外。
請先問我 3 個問題：
1. 是哪一個事件，它會叫起哪些模組，每個模組各做什麼；
2. 這個事件從哪些來源進來（例如收到信件、建立工單、排程掃描），同一件事會不會被觸發不只一次；
3. 這些模組會修改哪些欄位或對外動作（例如訂單狀態、金額、寄信），每一項目前有幾個模組能直接寫入。
根據我的回答，請輸出：
- 入口清單：哪些入口其實處理的是同一件事，建議怎麼合併，以及如何辨認重複的事件；
- 寫入者清單：每個重要欄位目前的寫入者，以及建議保留的唯一寫入者；
- 改成接力後的流程：主模組是誰、其他模組交給它什麼資訊；
- 仍然拆不開、需要仲裁或交給人判斷的例外。
不要假設我的系統有我沒提到的功能；資訊不足時先問我。
建議只是起點，哪個模組擔任寫入者，要由負責這個流程的人決定。
參考來源
- Microsoft Learn（Azure Architecture Center）：AI Agent Orchestration Patterns — https://learn.microsoft.com/en-us/azure/architecture/ai-ml/guide/ai-agent-design-patterns [accessed: 2026-10-11]
- Anthropic Engineering：Building effective agents — https://www.anthropic.com/engineering/building-effective-agents（2024-12-19）
- Stripe Docs：Idempotent requests — https://docs.stripe.com/api/idempotent_requests [accessed: 2026-10-11]
