*圖 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 應怎麼做 | | ----------- | -------------------- | | 「那去年呢？」 | 延續前文，但改時間條件，通常要重新查資料 | | 「整理成表格」 | 沿用既有結果，不要重新查 | | 「換成英文」 | 只改呈現方式，不要重新查 | | 「你確定嗎？再查一次」 | 強制重新查原始來源 | | 「幫我分析另一個市場」 | 視為新的查詢條件 | 這也是好的 Coordinator 很重要、卻不容易被看到的能力：**知道什麼時候不做事。** 不必要地重新查詢不只浪費時間，也可能讓使用者在同一段對話中看到不同時間點的資料而產生混淆。