先拆問題，而不是直接把所有工具都叫一遍
第一個子問題依賴 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。最終回答可以是一段自然語言，但內部資料結構最好保留來源與查詢時間。 例如：Confluence、Trello 不一定是必選
在跨來源工作流裡，更重要的是理解工具的可替換性。如果你的團隊沒有 Confluence 或 Trello，可以只用 Sheets + PDF 完成主實作。未來要接 Jira、Notion 或資料庫，本質上只是新增另一個 Tool。 因此主線的成功條件不是「接滿三個 SaaS」，而是確認同一個問題可以被拆成不同資料任務，並把各工具結果重新整合。階段實作三｜畫出第一條跨來源工作流程
回到 Day 05 的企業問題與 Day 10 的知識來源，再加入一個結構化或即時來源，例如試算表、資料庫、專案看板或其他 API。這一階段不需要真的串接所有系統，重點是先把資料依賴寫清楚。
接著用箭頭標出執行關係：前一步輸出是後一步輸入時，使用循序流程；彼此獨立時，才使用平行流程。最後準備三類測試問題：只需要單一資料來源、需要兩個獨立來源，以及後一步依賴前一步結果。第三類問題必須先取得精確結果，再用結果補查其他來源，不能讓模型自行推測。
保存這份「跨來源工作流程」。Day 20 會在同一張流程上標記哪些判斷可以交給 Agent，以及它必須在哪些條件下停止。
實務補充｜跨來源回答一定要保留「哪一句來自哪裡」
跨來源最容易出問題的地方，不是工具沒接上，而是最後把不同時間點、不同定義的資訊混成一段話，讓人無法回頭驗證。跨來源整合時，至少應保留四種資訊：來源系統、查詢時間、查詢條件、原始結果。這樣即使其中一個來源失敗，也能清楚告訴使用者「數字已取得，但專案狀態目前無法查詢」，而不是整份答案一起消失。 另一個很重要的原則是：不要為了展示代理（Agent）很厲害，就每次把所有工具都叫一遍。 好的工作流追求的是足夠、正確、有效率；如果兩個來源已經足以回答問題，多查三個系統只會增加延遲與混亂。延伸閱讀：部分成功比假裝全部成功更可靠
延伸閱讀：部分成功比假裝全部成功更可靠
真實環境裡，某個 API 可能 timeout、某份文件可能找不到、某個看板可能沒有權限。Coordinator 應該保留已成功取得的結果，同時明確指出缺少哪一部分。這種「partial success」比把失敗靜默吞掉更符合企業使用情境。
今天的 milestone 是：同一個使用者問題第一次可以跨越不同資料來源完成，而不是要求使用者自己拆成多次查詢。