Dispatch 和 Channels 不是同一件事
Dispatch 和 Channels 都是自動化工具，但一個是為了通知人做決策，一個是為了讓流程自動跑到底。搞反了，自動化就會卡在該人工的地方。
兩個名字，兩種問題
看到有人把 Dispatch 和 Channels 混在一起討論，我一開始也沒多想。它們都標著「自動化」，都在流程裡跑，看起來好像是同一個東西的不同叫法。但實際用過之後才發現，這兩個根本在解決不同的問題。
差別不在功能的細節，而在它們各自的設計假設。一旦搞反了，整個自動化流程就會以一種很微妙的方式卡住——不是壞掉，而是不夠用。
Dispatch：給人類決策的流程
Dispatch 的核心邏輯是：把資訊推送給人，讓人決定下一步。它假設自動化的瓶頸在於「誰該知道這件事」和「什麼時候該知道」，而不是「電腦該怎麼決定」。
所以 Dispatch 通常是：
- 觸發條件很清楚（某個事件發生了）
- 通知目標很明確（某個人、某個團隊）
- 下一步需要人的判斷或簽核
典型場景：訂單異常 → 通知客服主管 → 主管決定是否退款。電腦負責「發現問題並通知」，人負責「決定怎麼辦」。
Channels：讓流程自己跑下去
Channels 的設計假設不同。它假設自動化的瓶頸在於如何把多個步驟串起來，不需要人中途插手。
所以 Channels 通常是：
- 規則可以很複雜（if-then-else 的組合）
- 一個步驟的輸出是下一個步驟的輸入
- 整個流程可以完全自動執行到底
典型場景：訂單成立 → 檢查庫存 → 自動扣款 → 生成出貨單 → 通知物流。中間沒有人工干預點，流程自己決定每一步。
選擇的判斷點
關鍵問題是：你的流程裡有多少決策需要人的判斷？
如果答案是「很多」，Dispatch 更合適。因為 Dispatch 就是為了清楚地把決策點暴露出來，讓人在該決策的地方停下來。
如果答案是「可以用規則完全描述」，Channels 更合適。因為 Channels 的強項就是把複雜的自動規則串起來，不需要等人。
我見過的問題通常出在：用 Channels 去做 Dispatch 的工作。結果是什麼？規則越來越複雜，維護越來越難，最後還是得加一個「人工審核」的步驟，但這個步驟沒有被當成一等公民來設計。
沒有絕對的優劣
有時候同一個流程裡既需要 Dispatch 也需要 Channels。比如：
訂單成立 → [Channels] 自動檢查庫存、計價、生成出貨單 → [Dispatch] 通知客服確認收件地址 → [Channels] 自動扣款、安排物流
前半段可以自動化，中間有個人工確認點，後半段又回到自動化。關鍵是要認清楚：每個步驟需要的是什麼。
我不怕流程複雜。我怕的是：流程複雜，但架構沒有清楚區分「人決策的部分」和「機器執行的部分」。那樣維護起來就像在霧裡開車。
我是江中喬，一位具有 TPM 與產品管理背景的 AI 系統建構者，目前專注於 AI 認知增強系統與多 Agent 協作架構的設計與實踐。