用 Gemini 3.5 Flash 在幾分鐘內找出 ML CI 失敗的根因
除錯一條損壞的 ML 訓練流程既緩慢又繁瑣。你需要從兩次不同的 CI 執行中拉取日誌，與 golden values 比對，翻查 commit 歷史找出回歸來源，然後撰寫報告說明出了什麼問題以及原因，同時你的團隊還在等待。這個使用案例將整個調查流程全面自動化。
透過結合 ml-failure-audit 技能、Google 的 Gemini 3.5 Flash 模型，以及作為遠端推理引擎的 Gemini Agent API，Eigent 的多代理工作團隊可以端到端稽核 CI 失敗：抓取日誌、提取參考值、追蹤證據、委派繁重分析，並產出結構化交付物，全部只需要一個提示詞。
將 Gemini 3.5 Flash 選為你的模型
前往 Settings → Agents → Model，並從雲端模型清單中選擇 Gemini 3.5 Flash。如果你偏好使用自己的 API 憑證，可以在 Settings → API Keys → Gemini 下輸入自己的 Gemini 金鑰。
Gemini 3.5 Flash 針對長上下文任務的快速、具成本效益推理進行了最佳化，這正是 CI 日誌分析所需要的能力。
啟用 Gemini Agent API 作為遠端子代理
前往 Settings → Agents → Remote Agents，並開啟 Gemini Agent API。這會將 Gemini Agent 註冊為 Eigent 工作團隊內可呼叫的子代理。
啟用後，你的 Developer Agent 就能把計算密集型的推理任務，例如跨數百行日誌的根因分析，直接交給 Gemini Agent，而不是在單次模型呼叫中處理所有事情。這會形成雙層架構：Eigent 的本地 agents 負責協同編排與工具使用，而 Gemini Agent 負責深度推理。
上傳 ml-failure-audit 技能
前往 Settings → Agents → Skills，並上傳 ml-failure-audit 技能套件。你也可以瀏覽 Skill Hub: ml-failure-audit 以查看技能詳情與安裝步驟。這個技能定義了 Eigent 應如何進行 CI 失敗稽核：要收集哪些工件、要執行哪些比較、要蒐集哪些證據，以及最終報告應如何組織。
上傳完成後，工作團隊中的任何 agent 都可以在處理 ML 稽核任務時呼叫此技能。
將你的任務送交給 Eigent
完成所有設定後，將你的任務提示詞輸入 Eigent 的聊天中：
遵循 {{ml-failure-audit}} 技能，並使用遠端子代理來完成複雜的子任務。
請稽核這個 Megatron-LM MIMO VLM pretraining golden metric CI 失敗。我提供了一份本機 NVIDIA/Megatron-LM checkout，commit 為 <your-commit-sha>，以及我附加的 CI 工件（例如通過與失敗執行的日誌）。失敗的工作負載是一個 8-GPU frozen start convergence check，使用 sequence packing、global batch size 32、total packed sequence length 3200、packing buffer 4，以及 100 次 training iterations。
請判斷這個失敗究竟是真正的模型收斂／正確性回歸，還是 metric／gating policy 問題。請使用倉庫的 golden value 比對程式碼與 CI 日誌作為證據。不要重新執行 GPU 訓練。
請在倉庫根目錄輸出 answer.json，內含 source_refs、extracted_facts、calculations、final_answer 與 validation。也請輸出一份精簡的 answer.md。
請包含倉庫 URL、你的目標 commit checkout，並附上你要比對的 CI 工件。Eigent 會立即開始規劃調查。
在執行此提示詞之前，請先安裝 ml-failure-audit 技能。
**帶上你自己的輸入：**將 <your-commit-sha> 替換成你要稽核的 commit，在你的工作區中 checkout 該版本，並附上你自己的 CI 工件（例如通過／失敗執行的日誌、stderr 擷取，或匯出的 CI job 輸出）。你可以把 Megatron-LM 範例改成任何你正在調查的倉庫與失敗情境。
Coordinator Agent 規劃並指派任務
Eigent 的 Coordinator Agent 會讀取提示詞，並將其拆解為結構化的稽核計畫。它會識別關鍵階段，日誌擷取、資料提取、證據追蹤與報告生成，並將整個調查指派給一個 Developer Agent。
Coordinator 不只是盲目轉派：它會一併傳遞技能參考、倉庫上下文與 CI 日誌工件，讓 Developer Agent 一開始就具備所需的一切。
Developer Agent 載入技能並抓取日誌
Developer Agent 的第一步是載入 ml-failure-audit 技能，閱讀其指示以理解稽核方法。
接著它會平行執行 4 個命令來取得 CI 日誌資料，同時抓取兩份失敗日誌與任何相關中繼資料。平行工具執行意味著資料收集階段只需一小部分時間即可完成，而不是按序執行。
提取 golden values 並追蹤修正 commit
在取得日誌後，Developer Agent 會執行一個 Python 腳本來提取 golden 參考值，也就是通過的 CI 執行應該產生的預期訓練指標、loss 曲線或 benchmark 數值。接著它會將這些值與失敗日誌中記錄的數值進行 diff，比對出究竟在哪裡、以及偏離了多少。
下一步，Developer Agent 會搜尋 Megatron-LM 的 commit 歷史，找出 修正 commit，最有可能造成回歸的特定程式碼變更。這個 commit 會作為稽核報告中的具體證據，讓審閱者能直接把觀察到的失敗與底層程式碼變更連結起來。
將深度推理委派給 Gemini Agent
一旦原始證據組裝完成，日誌 diff、golden value 比對，以及追蹤到的 commit，Developer Agent 就會呼叫 Gemini Agent 來執行繁重的推理步驟。
Gemini Agent 會分析完整上下文：程式碼發生了什麼變化、該變化如何影響訓練行為，以及最可能的根因是什麼。幾分鐘後，它會回傳一份完整且結構化的稽核報告，涵蓋失敗診斷、促成因素，以及建議的修正方式。
Developer Agent 撰寫最終稽核報告
Developer Agent 會採用 Gemini Agent 的分析，並在工作區中寫入兩個交付物：
-
answer.json: 可供機器讀取的稽核記錄，包含結構化欄位，如失敗類型、根因、受影響的指標、證據 commit 與建議修正。適用於自動化流程、工單系統或 CI 儀表板。 -
answer.md: 精簡、適合人類閱讀的稽核摘要，涵蓋發生了什麼失敗、為什麼失敗、證據是什麼，以及下一步該做什麼。可直接貼到 PR 留言、Slack 討論串或事件報告中。
這兩個檔案都會直接寫入工作區資料夾，並立即可供存取。
為什麼這個工作流程很重要
ML CI 失敗之所以難以除錯，主要是因為訊號被埋在密集的日誌輸出中，而根因往往存在於距離症狀好幾個 commit 之前。這個工作流程透過三項協同運作的能力來解決這個問題：
- 平行日誌擷取 消除了逐一抓取工件的順序瓶頸。
- 基於 Python 的 golden value 提取 以精確的數值比較取代模式比對或人工檢視。
- 將 Gemini Agent 作為推理子代理，把最複雜的推論步驟卸載給最適合它的模型，同時保持編排輕量、分析深入。
最終得到的是一份根因稽核，原本可能需要工程師 30–60 分鐘的專注工作，如今幾分鐘內即可交付，並附帶結構化的工件軌跡。
下一步可以嘗試什麼
當你的第一次稽核完成後，可以透過以下後續提示詞延伸工作流程：
對最近三次 CI 失敗執行相同的稽核，並比較根因。
找到修正 commit 後，開一個預先填入稽核報告的 GitHub issue。
排程每日夜間觸發，稽核任何新的 CI 失敗，並將 answer.md 發到 Slack。
換用不同模型，試試 Gemini 3.5 Pro 進行更深入的分析，或用 Gemini Flash Lite 以獲得更快的回應。
取得更好結果的提示
- 明確附上你的 CI 工件。 ml-failure-audit 技能在你提供 commit checkout 加上要比對的日誌或匯出檔（例如通過執行與失敗執行）時效果最佳。
- 包含倉庫 URL。 Developer Agent 會用它來搜尋 commit 歷史以找出修正 commit。直接提供倉庫連結可以省下一個搜尋步驟。
- 指定你的輸出檔案。 要求同時產生
answer.json與answer.md，可讓 Developer Agent 同時輸出兩種格式，如果你需要給 CI 流程使用的機器可讀輸出，以及給團隊閱讀的人類可讀輸出，這會非常有用。 - 將 Gemini Agent 用於重推理任務。 當本地 agents 能處理資料收集，而 Gemini Agent 負責綜合時，遠端子代理模式效果最佳。避免把它用在本地工具就能更快完成的簡單查詢上。
