083 · 用多代理系統急救 Spark 任務
Pinterest 工程師分享怎麼把 Spark 故障診斷，從單一 prompt 逐步演化成可觀測、可測試的多代理系統。
原標題：Medic for Apache Spark - First Aid for Failing Jobs - Drasko Profirovic, Pinterest
重點摘要
- 從人力支援到 agent 診斷Data Platform 團隊的支援輪值長期被優先順序難排、新手常見的 Spark 錯誤壓垮，講者的解法是打造一個能無限擴充的 agent，直接回答「job 為什麼失敗」並附證據與修復建議。
- 從單一 prompt 到可觀測、可測試最早的雛型只是接了 MCP 工具的單一 ReAct agent，beta 試用後暴露品質不穩、context window 爆量等問題；團隊靠 OpenTelemetry／LangFuse 追蹤與可重放的端到端測試框架，把品質從「憑印象」變成可量化的離線 eval。
- log 與 metrics 都要先做特徵工程再餵給模型直接丟原始 log 或時序資料給 LLM 既沒效果又燒 token；團隊改用 exception classifier 排序關鍵例外，並把 metrics 轉成標註過的圖表交給獨立 subagent 判讀，讓輸入大小固定、不受任務長短影響。
- 多代理架構帶來的控制力改建在 LangGraph 的 DeepAgents library 之上後，triage、research、supervisor、healer 各司其職，每個角色有獨立 prompt 與工具子集，除了讓維護與測試更容易，加新功能（例如 Spark SQL 優化）也只需要多寫一個 prompt。
- 成效與下一步強化 log 處理讓根因誤判明顯減少，團隊接下來要把使用者回饋餵回系統做自動改進，並打算把整套模式複製到 Flink、Trino 等其他分散式系統。
時間軸
時碼點下去會跳到影片的那一段。
| 時碼 | 段落 | 重點 |
|---|---|---|
| 00:00 | 開場 | Drasko Profirovic（Pinterest staff engineer）開場說明主題：Medic for Apache Spark，一套排查 Spark 任務失敗原因的 agentic 診斷工具，並預告會談建置歷程與後續規劃。 |
| 00:38 | 支援輪值痛點 | 講者說明在 Data Platform 團隊做支援輪值的共同困境：新手常卡在 Spark 這類分散式系統，各團隊要求的優先順序也難以取捨。 |
| 01:15 | LLM 補上人力缺口 | 人得取捨時間分配，LLM 卻能依需求無限擴充；願景是讓 agent 回答「這個 job 為什麼失敗」，產出附證據的診斷報告與修復建議。 |
| 02:05 | MCP 雛型 | 團隊先用 MCP 把資料資源接給 LLM，再做出單一 prompt 的 ReAct agent，具備基本的問題排解與報告產出能力。 |
| 02:55 | beta 試用現形 | 開放測試後發現品質不穩、分析深度時淺時深，缺乏行為控制，大型 log 輸出也常把 context window 塞爆。 |
| 03:47 | 補上可觀測性 | 團隊導入 OpenTelemetry 把 trace 送到 LangFuse，並建端到端測試框架，用離線 eval 量化品質、確認改動沒有讓表現退步。 |
| 05:49 | log 處理進化 | 從 regex 過濾常見例外，進階到 exception classifier pipeline：學習哪些例外常見於成功任務並排除，agent 改用 MCP tool 只取排序後的關鍵例外。 |
| 06:47 | metrics 圖像化 | 原始時序 metrics 太耗 token，改由獨立 subagent 把資料畫成標註過的圖表拼成一張圖再交給模型判讀，讓 token 用量固定、不受任務長短影響。 |
| 08:17 | 架構大改版 | 從單一 ReAct agent 換成建立在 LangGraph 的 DeepAgents library 之上的多代理架構，每個 agent 有自己的 prompt 與 MCP tool 子集，也讓新增 Spark SQL 優化功能只需加一個新 prompt。 |
| 09:27 | 完整工作流程 | 使用者提問先分類為簡單回答或深度診斷；triage agent 判斷任務生命週期並生成失敗假設，多個 research agent 平行蒐證後由 supervisor 選出最高信心根因，交給 healer agent 依 runbook 提出修復建議。 |
| 10:32 | 成效與展望 | 強化 log 處理明顯降低根因誤判；接下來要把使用者回饋餵回系統自動改進，並計畫把同一套模式套用到 Flink、Trino 等其他分散式系統。 |
值得記的話
名詞與人物
| Medic | Pinterest Data Platform 團隊打造的 agentic 診斷工具，用來排查 Spark 任務失敗原因並提供修復建議，後續也擴充到 Spark SQL 優化。 |
|---|---|
| MCP（Model Context Protocol） | 把 Spark 相關的資料資源（log、metrics）以工具形式暴露給 LLM 呼叫的協定，是整個系統最早的雛型基礎。 |
| ReAct agent | 早期版本的架構：單一 agent 靠一份 prompt 邊推理邊呼叫工具，是後來多代理架構的前身。 |
| LangFuse | 團隊用來接收 OpenTelemetry trace、以瀑布圖檢視 agent 每一步執行狀況的可觀測性工具。 |
| exception classifier pipeline | 取代 regex 過濾規則的做法：學習哪些例外常出現在成功任務中並視為雜訊過濾掉，再依相關性與時間排序剩下的例外。 |
| DeepAgents library（LangGraph） | 團隊拿來重建 harness 的多代理框架，內建待辦清單、虛擬檔案系統等機制，讓每個 agent 專注在自己的 prompt 與工具上。 |
| triage agent | 多代理架構裡負責判斷 Spark 任務生命週期狀態、產生失敗假設的第一線角色。 |
| healer agent | 負責依向量資料庫裡的 runbook，針對 supervisor 選出的根因提出修復建議的角色。 |
延伸
- 提到團隊也試過用 LangGraph 的 workflow 讓 agent 行為更具決定性，但沒有進一步說明結果。
- 提到正在實驗把使用者過去 session 的回饋自動餵回系統改進 agent，但沒有說明實作機制。
- 提到打算把整套診斷模式套用到 Flink、Trino 等其他分散式系統，但只是點名帶過。