資料分析自動化已經行之有年，固定的 query 可以寫成 SQL / Python 定期執行，BI 工具也早就可以把 dashboard 定義好，再 scheduled refresh。
現在有 Coding Agent，Data Analyst、Product Manager 或其他 technical user，要臨時寫一段 SQL、Python 或產 report，也比以前容易很多。
所以這 30 天想做的，其實不是：
怎麼讓 Agent 幫我們做資料分析？
而是：
怎麼盡量減少資料分析裡重複性的工作，讓真正有意義的分析可以更早開始？
target user 不一定是不會 SQL 的人，Product Manager、Operations、Finance 或其他 domain user，很多本來就會 SQL，甚至自己就能完成不少分析。
問題不在於會不會，而是每次做分析時，除了 query 本身，還有很多事情要處理：
Coding Agent 可以幫忙完成其中很多 task，但如果每次都要重新把這些東西組起來，時間成本是很可觀的。
特別當一些需求是有時效性的，越快越有價值，因此這個平台的目的在於把這些細節串接起來，希望未來不用再花額外的時間做重複的事情。
常見的分析，可以先由 Data Analyst 或 domain expert 做成 saved Analysis。
例如：
其他人之後可以直接 reuse。
Known Question
→ Saved Analysis
→ Run
→ Report
但實際工作不可能全部都是預先定義好的問題。
譬如今天 user 可能突然想問：
Mobile user 最近 session 變短，是哪些 event type 改變了？
如果沒有現成 Analysis，他不一定要先去找 Data Analyst，也不一定要另外開 Coding Agent，自己確認 database 有沒有正確 expose。
他可以直接在平台裡問 Agent 這些細節，或是直接叫他確認。
畢竟平台本來就已經包含：
如果只是一次性的問題，跑完就結束。
如果後來發現這個問題會一直出現，再把它存成新的 Analysis。
Existing Analysis
→ Reuse
New Question
→ Explore
→ Run
→ Save if reusable
→ Analysis Library grows
所以 Data Analyst 的角色沒有消失，他們可以建立、review、維護比較重要的 Analysis，差別只是其他 user 不需要因為每一個新問題，都先排進 Data Analyst 的工作 queue。
前面幾天最重要的一個決定，是讓 Agent 不只回傳答案，而是產生 executable code。
因為 code 可以：
使用者(Human)在 conversation 裡補 business rule，datasource 提供實際資料，最後才得到一個確認過的 Analysis。
Analysis
=
Intent
+
Confirmed Code
+
Output Guidance
Save 之後，它就不再只是某次 conversation 的結果，而是一個可以重新執行的 artifact。
既然 code 是動態產生的，就不能直接丟進 backend process 執行，畢竟還是會有危險程式碼的疑慮。
所以後來加入 Sandbox，把 execution 和 application 本身分開。
我們逐漸建立 Sandbox 的管理系統，例如：
我們預期遇到 OOM 時，不是直接換更大的 sanbox，而是先理解需要多少infra，然後透過 rewrite execution strategy 來優化，真的還是不夠，再換較大的 sandbox。
Run
→ Measure
→ Rewrite
→ Scale if needed
Conversation 變長之後，另一個問題是 context。
完整 history 當然可以保存，但如果每次 request 都全部送進 model：
隨著 conversation 越來越長，context window 會被大量歷史訊息和 tool results 佔掉。
恰好這次競賽期間 TypesafeAI 推出了 Jev。
它的輸出方式和一般 LLM 不太一樣，很適合拿來做 bounded classification，例如：
所以後來把它用在：
Conversation history 還是完整保留，只是每次真正進 context window 的內容會先做 selection。
Full History
→ Relevant Turns
→ Agent Context
實際測試也看到，conversation 越長，這個優化效果越明顯。
這邊潛在的風險是，在更專業或低容錯的領域，Jev 能不能維持同樣的表現還需要更多測試。Context selection 一旦漏掉重要資訊，省下 token 的同時也可能影響結果。
Analysis 可以保存之後，很快就碰到下一件事：
同一份 recipe 換到另一個 datasource，還跑得動嗎？
Schema compatible 不代表 execution strategy compatible。
小資料上把幾百萬 rows 拉進 sandbox 可能沒事，換到 production-sized table 就可能直接 OOM。
所以後來加了：
System 像是醫院檢傷分類一樣先歸類問題，：
再讓 Agent 針對那個問題 rewrite。
但 rewrite 完不能直接存。
Candidate 還要和原本版本在同一份資料上比較 output，確認 calculation 沒被改掉，通過後才存成下一個 version。
因此一個 Analysis 最後不只是 code，還有：
實際 report 通常不只有一張 chart。
所以後來把多個 saved Analysis 組成 Workflow。
Analysis
↓
Batch
↓
Report
Workflow 本身沒有另外做一套 execution engine，每個 node 還是走原本的 Analysis runtime，換句話說 Workflow 整合了前面所做的：
Scaling up 碰到的第一個問題是如果有很多分析要執行，要怎麼做才是最優組合？
第一次同時跑 7 個 Analysis，整個 Workflow 花了 51 秒，但所有 script 加起來 CPU time 只有大約 7 秒，所以我們建了 Performance Page 來找出瓶頸在哪邊。
拆解之後發現主要時間其實花在：
因此我們希望減少開新 Sandbox 的次數，讓原本的可以繼續使用，所以後來才改成：
最後同樣 7 個 Analysis：
Analysis 本身幾乎沒有改，改的只是怎麼去規劃執行他們。
到 Day 29，Analysis、Workflow、Report、Scheduler 都已經存在。
所以最後把它們再接回 Chat。
User 可以直接說：
幫我做一份 Monday Report，把 Users、Content、Business 分成三個 section，然後直接跑。
Agent 會：
需要進一步修改時，再按 Open workflow 回到完整 Workflow page。
這時候 Chat 比較像整個平台的入口，可以在這邊做絕大部分的操作。
而 Deterministic 的部分如：execution、validation、versioning、scheduling，仍然由後面的 system 負責。
不是所有事情都需要交給 Agent，越 deterministic 的工作，越適合留在 code 裡。
把段時間的東西放在一起後，是一個完整規模化數據分析的 lifecycle：
Ask a Question
↓
Explore with Data
↓
Create Analysis
↓
Save
↓
Validate
↓
Version
↓
Reuse
↓
Compose Workflow
↓
Schedule / Execute
↓
Measure
↓
Optimize
↓
Report
BI、SQL、Python、Coding Agent 都已經能解決其中一部分。
這次做的事情，是把這些原本分散的能力放進同一個 Analysis lifecycle 裡，常見問題可以直接 reuse，新的問題可以直接探索，不斷重複執行的再變成下一個 reusable Analysis。
這也是整個系列的標題：
Define Once, Analyze at Scale.
iThome鐵人賽
看影片追技術