AI Orchestration Agent 導入前：先畫清楚工作指揮圖
一個客戶在 WhatsApp 問訂單狀態，客服同事想用 AI 快速回覆。AI 先查客戶關係管理系統(CRM)，再查物流狀態，發現貨件延誤，又建議補寄優惠券。問題來了：AI 可否直接查所有客戶資料？可否自動承諾補償？誰批准？最後要寫回哪個系統？
這就是 `AI Orchestration Agent` 真正要處理的問題。它不是另一個聊天機械人，而是公司用來指揮多個 AI Agent、業務系統、人工審批和審計紀錄的控制層。對香港中小企來說，重點不是一次過買齊所有 AI 工具，而是先畫清楚一張「工作指揮圖」：每類請求由誰接、AI 做哪一步、人在哪裏批、系統在哪裏留紀錄。
2026 年 6 月 25 日，OpenAI 發布有關 agents 如何進入工作場景的研究；同日 Axios 亦報道，Codex 類代理工具正在由簡單查詢走向更長時間、更複雜的委派工作。相關研究亦指出，部分使用者已同時管理多個代理，並用 skills 保存複雜工作指令。這些訊號很清楚：AI 正在由「幫我寫一句」變成「幫我跟完整件事」。一旦 AI 可以跟完整件事，企業就要先決定誰指揮。
一句定義：Orchestration Agent 是工作路由，不是萬能員工
AI Orchestration Agent 可以理解為一個工作路由和管控層。它負責接收請求、分類、分派、檢查權限、觸發審批、記錄結果，再把資料寫回正確系統。
它未必親自完成所有工作。比較健康的設計，是讓不同專門代理各做一段：
客服代理：整理查詢、草擬回覆、分類投訴。
銷售代理：根據 CRM 和產品資料準備跟進內容。
財務代理：按規則計算退款、折扣或對賬差異。
文件代理：摘要合約、表格或客戶提交資料。
報表代理：整理每日或每週異常。
軟件代理：準備程式修改、測試和發布說明。
Orchestration Agent 的工作，是決定這些代理何時出手、可讀甚麼資料、可寫回甚麼位置、哪一步必須由人批准。
培訓中心例子：企業客戶查詢 30 人課程。Orchestration Agent 先判斷是 B2B 報價；銷售代理草擬方案；排班代理檢查導師時間；財務代理計算公司客戶折扣；如折扣超過指定門檻，就送主管審批；批准後才寫回 CRM、預約系統(Booking System)和銷售 pipeline。這才是一條可管理的 AI 工作流。
第一層：把請求分類，避免所有事都丟給同一個 AI
很多公司試 AI 時，會先建一個「公司 AI 助手」，甚麼都問它。這對內部試用很方便，但一到真實營運就容易混亂。客服問題、退款問題、系統問題、合約問題和管理報表問題，風險完全不同，不應走同一條路。
工作指揮圖的第一層，是把請求分成清楚類別。
零售例子：同一句「我收不到貨」，可能是一般查詢、物流延誤、地址錯誤、付款異常，亦可能是投訴。Orchestration Agent 應先分類：一般查詢可由客服代理草擬回覆；物流延誤要建立 ticket；付款異常要通知財務；投訴升級要交主管。這樣前線同事不用每次重新判斷，管理層亦知道哪類問題最多。
專業服務例子：客戶問「合約可否改這一條？」文件代理可以找出相關條款，但 Orchestration Agent 應判斷這是法律/商務風險，不可自動回覆。它可以準備摘要，然後送負責顧問或主管確認。
第二層：把資料權限拆細，不要給 AI 一把總匙
AI Agent 最危險的地方，不一定是答錯，而是拿到太多權限。為了 demo 好看，團隊很容易把整個 CRM、共享雲端硬碟、客服對話和報表都接上 AI。結果是每個代理都看得太多，也做得太多。
Orchestration Agent 應把權限拆成四級：
只讀參考資料：產品介紹、FAQ、公開政策、標準流程。
讀取指定個案資料：某一位客戶、某一張訂單、某一個項目的文件。
低風險寫入：新增內部備註、建立待辦、分類 ticket、更新標籤。
高風險動作：發正式通知、批准退款、改合約、改價格、部署系統。
物流例子：AI 可以讀取某張運單和客戶查詢紀錄，但不應讀取全公司所有客戶資料。它可以草擬延誤回覆，但不可自行承諾賠償。它可以建立內部跟進 ticket，但退款必須經主管或財務批准。
軟件團隊例子：AI coding agent 可以讀取指定 repo 和任務編號，可以開 pull request，但不可直接合併到主分支，更不可直接部署生產環境。Orchestration Agent 要在任務系統、程式碼審查和持續整合/持續部署(CI/CD)之間加上清楚閘口。
第三層：審批點要寫成規則，不要靠人記得
很多企業其實有審批文化，只是沒有把它寫入系統。退款要問誰、折扣要問誰、客訴要問誰、系統上線要問誰，通常靠同事記得。當 AI 加入流程，靠記憶會更危險，因為 AI 會把事情做得更快。
Orchestration Agent 應把審批點變成可執行規則。
客服例子：客戶要求退款。AI 可以先查付款紀錄、訂單狀態、過往投訴和公司政策，然後生成三個建議：拒絕、部分退款、全額退款。但只要金額超過指定門檻，或者客戶一年內已有多次退款，系統就要送主管審批。
教育例子：學員想轉班。AI 可以查名額、付款和出席紀錄。同價轉班可由前台確認；涉及退款、保留學位或企業客戶合約條款，就要送行政主管批核。
管理報表例子：AI 每星期整理銷售和客服摘要。若只是內部草稿，可以自動產生；如果要發給董事或外部投資者，就必須由管理層確認數據來源和口徑。
第四層：審計紀錄要講得出「點解」
如果 AI 只留下最後答案，企業其實沒有真正控制流程。日後客戶追問、主管覆盤、合規檢查或系統出錯時，公司需要知道每一步為何發生。
一條可用的 AI orchestration workflow，至少應保存這些紀錄：
請求來源：客戶、同事、系統提醒或管理層指示。
使用資料：讀取了哪個系統、哪個文件、哪段時間的資料。
代理分工：哪個代理做分類、摘要、計算、草擬、檢查。
觸發規則：例如金額門檻、客戶等級、風險分類、SLA 超時。
人工審批：誰批准、何時批准、批准甚麼。
系統寫回：更新了 CRM、客服 ticket、預約系統、報表或文件庫哪個位置。
例外處理：哪一步失敗、由誰接手、如何補回紀錄。
例如客服主管每星期看報表，不應只看到「AI 處理了 300 個查詢」。更有用的是：多少個自動完成、多少個轉主管、多少個涉及退款、多少個因資料不足要人手跟進、多少個超過服務水平協議(SLA)。這些數字才可以幫公司改善人手、系統和客戶承諾。
第五層：備援不是換模型，而是保留公司流程
AI 工具會更新、限流、改價、停用某些功能，甚至因政策或供應商安排而改變可用範圍。企業不能把整條流程鎖死在單一平台。
Orchestration Agent 的設計應保留三個備援點。
第一，資料仍留在公司系統。CRM、訂單、發票、ticket、報表和審批紀錄，不應只存在 AI 平台裏。
第二，規則可被人讀懂。退款門檻、客戶分級、升級條件、資料權限，不應只藏在一段 prompt 裏，應整理成公司可維護的規則。
第三，人手可以接回流程。當 AI 工具不能用，前線同事仍應知道下一步：查哪個系統、用哪個模板、誰審批、如何補回紀錄。
例如一間電商公司讓 AI 處理退貨查詢。即使 AI 暫停服務，客服仍可在 CRM 看到退貨規則、客戶紀錄和待審批事項，而不是要由頭翻查聊天紀錄。
30 日內可以這樣開始
第一星期，選一條流程，不要選全公司。建議由客服查詢、銷售跟進、退款審批、預約改期、每週管理報表或軟件發布流程入手。標準是高頻、規則清楚、風險可控。
第二星期，畫出工作指揮圖。用表格列出：輸入來源、資料系統、AI 可做的步驟、人手審批點、系統寫回位置、例外處理方法。
第三星期，拆權限。決定哪些代理只可讀資料，哪些可建立草稿，哪些可寫入內部紀錄，哪些永遠不能自行做高風險動作。
第四星期，小規模試行。先選一個部門、一類查詢或一批內部個案。量度四件事：處理時間、人工接手比例、錯誤原因、紀錄是否足夠。不要只問「有沒有快」，也要問「出事時是否查得清」。
最後要問的不是「用哪個 AI」，而是「誰指揮工作」
AI Orchestration Agent 的價值，不在於讓 AI 變成萬能員工，而是讓 AI 在公司可控的工作流內做事。當多個 AI Agent 開始連接 CRM、預約、客服、財務、文件、報表和開發工具，真正的競爭力會來自流程設計：資料邊界清楚、審批點清楚、紀錄清楚、例外有人接手。
管理層可以先問一個很直接的問題：如果明天 AI 幫公司處理一宗退款、一份報價、一個投訴或一次系統修改，誰會知道它用了甚麼資料、跟了哪條規則、誰批准、最後寫回哪裏？
如果這個答案講不清楚，暫時不要急着擴大 AI Agent。先把工作指揮圖畫出來，才是導入 orchestration agent 的第一步。
規劃實際項目
先確認現有系統怎樣交換數據、哪些步驟需要審批，以及交易失敗後由誰跟進。