分析師與 AI Agent 最有效的分工，不是把整個專案丟給 AI，而是讓 Agent 加速 schema 探索、SQL 初稿、重複查詢與報告草稿；分析師保留問題定義、業務口徑、驗證設計、異常解釋與決策溝通。前者節省操作時間，後者決定結果是否值得相信。
先按「可驗收程度」分，不按職稱分
Agent 適合承接有明確輸入、可觀察輸出與可重跑檢查的工作；人類應主導需要情境判斷、責任承擔或跨部門協商的工作。
| 工作 | Agent 可先做 | 分析師必須負責 |
|---|---|---|
| 資料理解 | 列 schema、型別、NULL、候選 key | 判斷欄位真正業務語意與資料缺口 |
| SQL | 草擬 JOIN、聚合、重複步驟 | 審 grain、分母、時間窗、fan-out |
| 驗證 | 跑 row count、distinct、異常值檢查 | 決定什麼差異可接受、補哪個測試 |
| 報告 | 整理發現、表格與段落初稿 | 解釋原因、區分相關與因果、給建議 |
| 溝通 | 依模板重寫受眾版本 | 面對追問、承諾與風險取捨 |
這也解釋了為什麼「AI 寫得比我快」不是完整的生產力指標。若省下 20 分鐘草擬，卻多花兩小時追查不透明的數字，工作流反而退步。
Quick 路徑：讓 Agent 當探索加速器
適合 Quick 的任務包括：列出欄位、找狀態值、產生初步分布、驗證一段 SQL、估計問題是否值得深挖。分析師可以給一個短但具體的驗收要求：
先列出 order_status 的 distinct value 與筆數；
標記 NULL、未知值及最晚資料日期，不要直接下業務結論。
Quick 的成果可留在對話與 SQL 分頁，但若問題開始牽涉分母、跨表 JOIN、正式比較或對外數字，就應升級。
Project 路徑：讓 Agent 在契約內執行
正式分析可拆成五個交棒點：
- 分析師定義問題：決策、母體、粒度與成功標準。
- Agent 探索並草擬 Plan：資料來源、查詢步驟與 checkpoint。
- 分析師審 Plan：修正口徑、排除條件與風險。
- Agent 執行：依核准範圍跑 SQL、保存 evidence、形成 Report 草稿。
- 分析師驗收與解讀：抽查、挑戰替代解釋、確認 limitations，再向決策者溝通。
OpenAI 2026 年針對 Codex 使用的研究顯示，Agent 使用正往較長、跨工具的任務發展；但該研究的工時門檻來自模型估計，而且樣本與 OpenAI 自身使用情境都有明確範圍，應視為 Agent 工作型態的訊號，不是所有企業的生產力保證。OpenAI：How agents are transforming work
長任務的挑戰也不只是模型聰明度。Anthropic 將 context 視為有限資源，建議透過按需檢索、結構化筆記與 compaction 維持任務一致性。Anthropic：Effective context engineering for AI agents 對分析師而言，Plan、SQL、checkpoint 與 Report 正是比長聊天更穩定的外部狀態。
Lantide Data 的分工心智
Lantide Data 把這種分工落在兩條工作路徑：Quick Analysis 支援探索與一次性驗證；Project Analysis 則以 Plan → 批註 → 使用者 Approve & Execute → SQL evidence → Report 推進。完整流程可參考 分析師 Plan／Execute／Report 指南。
Lantide 的優點不是把分析師移出流程，而是讓 Agent 做過的工作留下可審閱 artifact；SQL 是取數證據，Plan 是執行前契約，Report 則交代結論與限制。對高度程式化模型、非表格資料或重度 notebook 探索，Jupyter、程式開發環境與專門工具仍可能更適合；Lantide 的主場是 SQL-first、需要治理與交付的表格分析。
用四個指標評估分工，而非只算省時
試跑後可記錄：
- 口徑在 Execute 前被修正幾次；
- SQL／資料品質 checkpoint 發現幾個問題；
- 同一分析重跑或交接需要多久；
- Report 有多少內容可直接用、多少因過度推論被退回。
這些指標能辨別 Agent 是真的降低返工，還是只把工作提早包裝成「已完成」。
結語
先挑一個低風險但真實的復盤：讓 Agent 做探索、SQL 與初稿，分析師在 Plan、checkpoint 與 Report 三處驗收。理想分工不是人做得更少，而是人把時間集中在只有情境、責任與專業判斷才能完成的地方。