你有沒有遇過：AI Agent 15 分鐘重做完一份分析，你卻花了兩個小時確認，它是不是用了錯的表、錯的分母，或一條上週就已經被排除的分析路徑？
Agent 會找欄位、寫 SQL、跑 Notebook、畫圖，也能把結果整理得很有說服力。但當你追問：「這個結論到底怎麼來的？」答案往往散落在聊天紀錄、被改寫過的查詢、幾個 Notebook cell，以及分析師自己的記憶裡。
AI 加快了分析，也讓脈絡遺失的代價更高。
問題在於，我們仍用為「人一次操作一步」設計的紀錄方式，管理一個能自己探索、執行、修正和分岔的工作者。執行越快，缺少脈絡造成的返工也越快。
AI Agent 的工作早已超過寫 SQL
早期的分析 AI 比較像補字工具：你描述需求，它回傳一段 SQL；你自己貼到編輯器、執行、看錯誤，再回去問下一題。每一步都經過人的手，所以人自然記得剛才發生了什麼。
現在的分析 Agent 可以接下一個目標後，自行完成一連串動作：
業務問題
→ 尋找可能的資料表與欄位
→ 產生 SQL 或 Python
→ 執行並讀取結果
→ 根據錯誤或異常自動修改
→ 製作圖表、摘要與報告
Databricks 的 Genie Code 會規劃任務、查找相關資產、執行 Notebook code，並根據 cell output 修正錯誤。Microsoft Fabric Data Agent 會根據問題、schema、範例和指令產生 SQL、DAX 或 KQL，並顯示中間步驟。分析師的角色也隨之轉變，從逐步操作改為設定目標與審閱結果。
dbt Labs 2025 State of Analytics Engineering 的調查也顯示，AI 已廣泛進入分析開發、程式碼與文件工作。問題因此從「AI 能不能寫」逐漸變成「我們能不能確認它做了什麼」。
真正讓分析師疲憊的，是重新建立上下文
日常協作最花時間的往往是這些追問：
- 哪一段 SQL 才是最後採用的版本？
- 這張圖來自哪一次執行，而不是目前畫面上的查詢？
- Agent 為什麼從資料表 A 改用 B？A 是暫時無法連線，還是已確認不適用？
- 報告中的「活躍用戶」使用哪個定義、時間窗和時區？
- 新對話裡的 Agent 是否知道某個資料來源上週已被排除？
- 一個 JOIN、分母或篩選條件何時被改過，又影響了哪些下游結論？
聊天紀錄可以證明「討論過」，卻很難標示哪個決定仍然有效。檔案版本可以告訴你「文字改過」，卻不一定說得出改動對證據鏈的意義。Notebook 保留 cell，也可能以非線性順序執行。
研究者在 Data Analysis in the Era of Generative AI 中把分析描述為在問題定義、資料蒐集、探索、視覺化、驗證與溝通之間反覆迭代的過程。這種工作本來就不是一條直線。Agent 讓迭代加快、分支增加，也更容易超出一個人的短期記憶。
為什麼軟體開發的 Plan → Result 邏輯還不夠
軟體開發和數據分析都會先規劃、執行、產生成果，也都需要版本控制。但兩者判斷「這條路可不可行」的訊號不同。
軟體工作當然也有隱藏風險，不過許多失敗會留下直接訊號：程式無法編譯、測試失敗、型別不符、API 回傳錯誤，或 diff 明確顯示行為被改動。當實作成功且驗收通過，一條從需求、變更到結果的版本鏈，通常能保存相當多關鍵資訊。
數據分析最危險的情況，則是技術上成功、分析上錯誤：
- SQL 正常執行，但 JOIN 把每筆訂單重複了三次。
- 圖表正常生成，但分母混入不具資格的用戶。
- 替代資料表有同名欄位，卻沒有原方法需要的歷史覆蓋。
- Notebook 沒有報錯，但 cells 的執行順序讓結果無法重現。
- 數字與前一版一致，只是兩個錯誤剛好互相抵銷。
程式成功執行，不代表分析成立。
因此，只記錄「Plan 產生 Result，新的 Plan 再產生新 Result」會漏掉真正重要的資訊：前一條路為什麼停止、哪些假設已被否決、哪些部分結果仍可沿用，以及新路徑是替代、延伸，還是重新開始。
AI 會讓「安靜的錯誤」一起規模化
一位分析師手動嘗試三段查詢，通常還記得自己為什麼放棄第一段。但 Agent 可以在幾分鐘內查看十張表、改寫多輪查詢、建立中間結果，再把其中一版數字寫進圖表與文字。
這種速度有真實價值，也讓四件事更容易遺失：
- 被否決的路徑：為什麼資料 A 不可用，而不是單純沒選它。
- 轉換的理由：查詢從 A 改成 B，是修正 bug、改變口徑，還是換了假設。
- 證據的身分：報告引用的是哪次實際執行結果。
- 目前的權威版本：多個看似完成的產物中，哪一個才是正式結論。
如果這些資訊只存在對話裡，換一個 Agent、壓縮 context 或隔週重開專案，就可能把已經排除的路徑當成新發現，再走一次。
失敗的分析路徑不該被刪除，也不該被假裝完成
分析走不下去，不一定代表前面的工作沒有價值。
假設團隊原本計畫用事件資料評估某功能對 30 日留存的影響，檢查後才發現歷史資料只保留 14 天。這個路徑不能支持原問題，但過程可能已確認事件定義、資料品質和可用期間。合理的處理不是刪除整段紀錄，也不是把它標成「完成」。
它應該被清楚標記為：
- 已停止，尚未成功完成。
- 停止原因是歷史覆蓋不足。
- 已完成哪些檢查，哪些部分結果仍有效。
- 後續用什麼新方法或新範圍取代它。
這個差異看似只是狀態名稱，實際上是在保護未來的人和 Agent：不要再把一條已證明不可行的路，誤認成尚未嘗試的路。
Data Lineage 不夠，我們還需要 Analysis Lineage
Data Lineage 回答的是資料如何流動：
原始資料 → 清洗 → JOIN → 聚合 → Dashboard
它能幫助團隊判斷上游改動會影響哪些資料表和報表，但它通常不會回答：為什麼選這張表？哪個指標定義被否決？這份結論引用哪次執行？前一個方法為什麼停止？
Analysis Lineage 要追蹤的是結論如何成立：
業務問題
→ 分析路徑、假設與口徑
→ 實際執行的 SQL / Notebook
→ 驗證、部分結果與停止原因
→ 圖表、報告與最終結論
兩者回答不同的問題：
Data Lineage 追蹤資料如何流動。Analysis Lineage 追蹤結論如何成立。
一條實用的 Analysis Lineage 不必保存 Agent 的每個思考片段。它應記下能協助人與 Agent 回答下列五個問題的資訊：
- 目前討論的結論來自哪個正式產物與哪次執行？
- 它使用哪些資料、查詢、定義、篩選與時間範圍？
- 上游有哪些被停止或被取代的分析路徑，原因是什麼？
- 哪些內容是正式證據，哪些只是歷史背景或部分成果？
- 證據鏈是否完整？若不完整，缺少哪一環？
這條脈絡必須活在聊天之外
如果 Analysis Lineage 只有目前這個 Agent 看得到，它就不是團隊資產。內建 Agent、外部 Agent 和人類審閱者都應讀到同一套關係，而且關係要跟分析產物一起保存，不依賴某段對話仍在 context 裡。
在 Lantide Data 中，我們用這個原則連接分析的 Plan、被停止或取代的路徑、實際結果與 Report。使用者可以直接查看 Analysis Lineage。Agent 也能沿著同一條脈絡，從目前報告追溯到上游計畫與證據。下次追問、交接或重新分析時，就不必靠猜測拼回歷史。
無論使用哪套工具，都可以先從一條最低限度的規則開始：每個正式結論都要能指回實際執行證據。每條被放棄的路徑都要保留停止原因與替代關係。
結語
AI Agent 讓分析師不必親手完成每一個操作，也讓「我記得自己做過什麼」不再足以支撐可信度。未來的分析工作流除了保存最後一版 SQL 和最後一份報告，還要保留問題、選擇、失敗、驗證與結論之間的關係。
AI Agent 讓分析更快。Analysis Lineage 讓團隊仍能說清楚結論是怎麼得出的。