在大型規模的系統營運中，當生產環境發生故障時，值班工程師面臨的最大挑戰往往不是缺乏解決問題的能力，而是在診斷開始前需要耗費大量時間收集碎片化的上下文資訊。這類工作包括確認服務的所有權歸屬、檢查最近的部署紀錄、分析日誌與指標、搜尋內部文件，以及將目前的症狀與過去發生的類似事故進行比對。這種 lll-initial-phase（初始階段）的資訊搜集過程極其繁瑣，且容易在壓力巨大的事故處理期間導致認知負荷過重，進而延緩故障恢復的時間。
為了解決這個痛點，電商平台 Instacart 開發了一套名為 Blueberry 的 AI 輔助事故響應系統。這不是一個簡單的聊天機器人，而是一個基於 Agentic AI（代理式人工智慧，指能自主使用工具、規劃路徑並執行任務的 AI 系統）的框架，旨在將工程師從重複性的資訊搜集工作中解放出來，讓他們能直接進入核心的診斷與修復階段。
Blueberry 的核心運作邏輯在於將 AI 的推理能力與企業內部的營運知識庫深度結合。當系統觸發告警時，Blueberry 會在背景同步啟動約 10 個子代理（Sub-agents），這些子代理會並行執行不同的診斷任務。為了確保 AI 給出的建議不是憑空想像的幻覺，Instacart 採用了 Grounding（接地/事實對齊）技術，將 AI 的輸出限制在可靠的內部數據範圍內。
具體而言，Blueberry 透過 Model Context Protocol (MCP，模型上下文協定，一種讓 AI 模型能標準化地存取外部工具與數據的介面) 連結了公司內部的多項關鍵資源，包括長達 14 年的歷史事故紀錄、服務所有權資料、即時日誌、部署紀錄以及其他調試訊號。當事故發生時，Blueberry 會在約三分鐘內，直接在工程師協作的 Slack 頻道中生成一份基於事實的根因假設（Root Cause Hypothesis），提供相關的日誌片段與部署變更紀錄，讓工程師在進入頻道的第一時間就擁有了完整的上下文。
這種設計將 AI 定位為資訊的收集者與假設的提出者，而非決策者。Blueberry 負責執行診斷路徑、調用工具並整理資訊，而最終的診斷結論、緩解措施的決定以及修復行動，依然由值班工程師負責。這種人機協作模式確保了生產環境的安全性，避免 AI 自動執行可能導致更嚴重後果的修改操作。
從實務成效來看，Blueberry 顯著提升了診斷的準確度。Instacart 指出，透過導入 14 年的歷史事故數據進行事實對齊，診斷準確率從原本的 60% 左右提升到了 90% 以上。在 2026 年 4 月的單月數據中，該系統在超過 270 個 Slack 頻道中執行了約 25,000 次診斷流程，調用 MCP 工具超過 58,000 次，且工作流成功率高達 99.9%。
然而，Instacart 的經驗也揭示了一個關鍵的技術限制：AI 在營運維運中的有效性並不單純取決於大型語言模型（LLM）本身的強大程度，而是在於周邊工程框架的完整性。如果缺乏標準化的工具整合、精確的營運上下文以及持續的反饋迴路，AI 僅能提供泛泛而談的建議，無法真正解決複雜的生產問題。
Blueberry 的意義在於它改變了值班工程師的起點。工程師不再是面對一個空白的調查路徑，而是從一份已彙整的初步調查報告開始分析。這不僅縮短了平均修復時間（MTTR），更重要的是，它將分散在不同工程師腦中的經驗，透過歷史紀錄的數位化與 AI 化，轉化為組織可持續利用的營運資產。
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。