圖 1｜Coordinator 負責理解需求、分派工作並整合結果
當系統只有兩三個工具時，最直覺的做法是先做 Router：看到數據問題就送到 Sheets，看到文件問題就送到 RAG。這種設計簡單、容易理解，也很適合作為第一版。 但當問題開始跨來源，Router 很快會不夠用。因為它通常只回答一件事：「這個問題應該去哪裡？」真正的任務卻可能需要先查 A，再根據 A 的結果決定是否查 B，最後還要整合兩個來源並判斷資料是否足夠。路由器（Router）的角色比較像總機
Router 的工作是分類與分流。例如判斷輸入屬於data_query、document_query 或 project_query，再把它交給對應工具。它很適合處理單一意圖，因為決策明確、成本低，也容易測試。
但如果使用者問的是「找出問題最大的市場，說明這個問題的正式定義，並確認是否有改善專案」，單純 Router 就不知道應該選哪一個，因為答案是「三個都要」。
Coordinator 比較像專案經理
Coordinator 不只是選工具，而是管理整段任務。它需要知道目前已經拿到什麼資料、還缺什麼、下一步要查哪裡，以及某個工具結果能不能直接沿用。 更重要的是，它必須維持上下文。假設上一輪已經查到 TW 是問題最大的市場，下一句使用者只問「那相關專案呢？」Coordinator 應該知道「那」指的是 TW，而不是重新把整個問題當成全新查詢。什麼時候用 Router，什麼時候用 Coordinator？
如果每個問題只對應一個明確工具，Router 通常就夠了。當任務開始涉及多步驟、跨來源、前後文與重新查詢判斷時，再引入 Coordinator 會更合理。 這也是 Data Machi 的演進方式：先建立清楚可驗證的單一工具，再讓協調者（Coordinator）統一管理，而不是一開始就用一個萬能代理（Agent）把所有複雜度藏起來。Coordinator 需要保留哪些資訊？
至少包括使用者目前的問題、最近對話、已經使用過的工具、工具回傳結果，以及任務是否完成。這些資訊後面會成為 LangGraph State 的基礎，也會和 Memory、Clarification、Verification 直接連在一起。進階理解｜Coordinator 不只判斷「去哪裡」，還要判斷「要不要重新工作」
使用者訊息可以先分成幾種很實用的類型：全新問題、延續追問、改寫需求、重新查核、格式調整。這個分類對非工程背景讀者其實很好理解，因為不同訊息需要的工作量完全不同。
這也是好的 Coordinator 很重要、卻不容易被看到的能力：知道什麼時候不做事。 不必要地重新查詢不只浪費時間，也可能讓使用者在同一段對話中看到不同時間點的資料而產生混淆。
實務踩坑：Domain Hint 是建議，不是絕對命令
實務踩坑：Domain Hint 是建議，不是絕對命令
初步分類可能判斷這題「應該查 Trello」，但真正執行時仍可能發現資料不存在、問題需要先釐清，或其實還需要文件定義。好的架構允許後續 Observation 修正方向，而不是第一次分類錯了就一路錯到底。
今天先記住一件事：Router 解決「送去哪裡」，Coordinator 解決「這個任務接下來怎麼做，直到完成」。