> ## Documentation Index > Fetch the complete documentation index at: https://data-machi.com/docs/llms.txt > Use this file to discover all available pages before exploring further. # Day 15｜實作：讓 AI 同時查數字與文件，完成第一次跨來源回答 > 把 Google Sheets 資料工具、PDF 檢索增強生成（RAG）與選配知識來源放進同一個任務，理解跨來源查詢時的拆題、順序與來源整合。 前一天我們畫出了企業知識地圖（Knowledge Map），今天開始面對真正的跨來源問題。這也是 Data Machi 從「有幾個工具」走向「能完成一段工作」的第一步。 假設使用者問：「今年哪一類需求工單最多？這個類別的正式定義是什麼？相關改善專案目前進度如何？」這句話看起來只有一個問號，但實際上至少包含三個子任務：算出最多的類別、查出正式定義、再確認改善專案狀態。 ## 先拆問題，而不是直接把所有工具都叫一遍 第一個子問題依賴 Google Sheets 的實際數字；第二個子問題需要文件或 Confluence；第三個子問題則需要 Trello 或其他專案系統。更重要的是，這三步不一定都能同時執行。 如果第二步要查「最多的那個類別」的正式定義，那就必須先知道第一步的結果。這是一個有資料依賴的 sequential workflow。相反地，如果使用者只是同時問「今年總工單數」和「報銷規範」，兩者沒有依賴關係，就可以平行查詢。 跨來源問題的拆解、查詢與整合流程

*圖 1｜跨來源問題先拆解，再依資料依賴查詢並保留來源整合*

## 第一版先不要追求全自動代理（Agent） 這個階段最好的實作方式，是先把跨來源流程寫清楚。你可以先由程式明確定義：先呼叫 Sheets Tool，取得 top category；再把這個 category 當作參數傳給 Document Tool；最後整理結果。 這樣做的原因很簡單：如果現在就把所有決策交給 LLM，你很難知道問題到底出在工具、路由還是 Prompt。先做出 deterministic workflow，後面再把「選擇哪個工具」交給 Agent，會更容易理解每一層的差異。 ## 來源整合不是把文字黏起來 跨來源答案應該保留每一段資訊來自哪裡。數字可能來自 Google Sheets，正式定義來自 PDF 或 Confluence，進度則來自 Trello。最終回答可以是一段自然語言，但內部資料結構最好保留來源與查詢時間。 例如： ```text theme={null} Top category: Delivery Issue Source: Google Sheets Definition: ... Source: Customer Service Taxonomy.pdf Project status: In progress Source: Trello ``` 這樣不只比較容易查核，也能在某個來源失敗時清楚告訴使用者：「數字已取得，但專案狀態目前無法讀取」，而不是整個回答一起失敗。 ## Confluence、Trello 不一定是必選 在跨來源工作流裡，更重要的是理解工具的可替換性。如果你的團隊沒有 Confluence 或 Trello，可以只用 Sheets + PDF 完成主實作。未來要接 Jira、Notion 或資料庫，本質上只是新增另一個 Tool。 因此主線的成功條件不是「接滿三個 SaaS」，而是確認**同一個問題可以被拆成不同資料任務，並把各工具結果重新整合。** ## 階段實作三｜畫出第一條跨來源工作流程 回到 Day 05 的企業問題與 Day 10 的知識來源，再加入一個結構化或即時來源，例如試算表、資料庫、專案看板或其他 API。這一階段不需要真的串接所有系統，重點是先把資料依賴寫清楚。 | 子問題 | Source of Truth | 必要輸入 | 是否依賴前一步 | 預期輸出 | 失敗時怎麼辦 | | ---------- | --------------- | ------- | ------- | ------- | ----------- | | 例：哪一類工單最多？ | Google Sheets | 日期範圍 | 否 | 類別與數量 | 說明數據無法取得 | | 例：該類別如何定義？ | 政策 PDF | 前一步的類別 | 是 | 定義與頁碼 | 保留數字，說明定義缺失 | | 例：改善進度如何？ | 專案看板 | 類別或專案名稱 | 是 | 狀態與更新時間 | 回傳部分成功 | 接著用箭頭標出執行關係：前一步輸出是後一步輸入時，使用循序流程；彼此獨立時，才使用平行流程。最後準備三類測試問題：只需要單一資料來源、需要兩個獨立來源，以及後一步依賴前一步結果。第三類問題必須先取得精確結果，再用結果補查其他來源，不能讓模型自行推測。 保存這份「跨來源工作流程」。Day 20 會在同一張流程上標記哪些判斷可以交給 Agent，以及它必須在哪些條件下停止。 做到這裡，Data Machi 已經不再只是兩個獨立工具，而是開始具備工作流程（Workflow）的雛形。但目前「何時該用哪個工具」仍然主要由程式固定。下一階段，我們就要把這個判斷能力交給代理（Agent）。 ## 實務補充｜跨來源回答一定要保留「哪一句來自哪裡」 跨來源最容易出問題的地方，不是工具沒接上，而是最後把不同時間點、不同定義的資訊混成一段話，讓人無法回頭驗證。跨來源整合時，至少應保留四種資訊：**來源系統、查詢時間、查詢條件、原始結果**。這樣即使其中一個來源失敗，也能清楚告訴使用者「數字已取得，但專案狀態目前無法查詢」，而不是整份答案一起消失。 另一個很重要的原則是：**不要為了展示代理（Agent）很厲害，就每次把所有工具都叫一遍。** 好的工作流追求的是足夠、正確、有效率；如果兩個來源已經足以回答問題，多查三個系統只會增加延遲與混亂。 真實環境裡，某個 API 可能 timeout、某份文件可能找不到、某個看板可能沒有權限。Coordinator 應該保留已成功取得的結果，同時明確指出缺少哪一部分。這種「partial success」比把失敗靜默吞掉更符合企業使用情境。 今天的 milestone 是：同一個使用者問題第一次可以跨越不同資料來源完成，而不是要求使用者自己拆成多次查詢。 下一篇我們會正式回答：當工具愈來愈多時，什麼時候固定的工具使用（Tool Use）才真正需要進化成代理（Agent）？