跳到正文
IFAI

AI工具

xAI 上線 Grok Bot 故障助手:10 分鐘自動清理 204 張工單

首次發布 傳播指數 40

xAI 披露了用於客服運維的兩個 Grok Bot AI 隊友。IncidentWatch 每 5 分鐘掃描工單,搶在內部報警前預警;IncidentSweep 負責排障後收尾,曾在 9 月 18 日用約 10 分鐘清理 204 張工單。

xAI 上線 Grok Bot 故障助手:10 分鐘自動清理 204 張工單
圖:x.ai

線上服務一旦崩了,最先感知的往往不是機房裡的監控告警,而是蜂擁而至的使用者投訴工單。

技術部門可能還沒收到報警郵件,客服後臺的同一類報錯已經刷屏了。等到工程師把 Bug 修完,客服團隊往往還要面對幾十甚至上百個待回覆的工單。近日,xAI 披露了他們內部如何用 Grok Bot 解決這個爛攤子:他們給團隊配了兩個專門對付線上事故的 AI 隊友,一個負責提前報警,另一個負責在事後快速清場。

一個抓苗頭,一個負責打掃戰場

第一個 AI 隊友叫 IncidentWatch,乾的是哨兵的活。

它每隔 5 分鐘就會拉出過去 15 分鐘的所有工單掃一遍,專門找那些集中爆發、內容相似的異常峰值。如果這個峰值不屬於已知的故障,它就會立刻向值班客服工程師發出警報,把疑似問題、匹配到的工單數量以及抽樣案例直接推過去。

在人工介入核實的同時,IncidentWatch 會把明顯相關的工單先扣住。一旦團隊確認發生了事故並更新了公開狀態頁,對外的客服機器人 Support Bot 就會跟進接手,逐一給這些被扣住的使用者同步進展。

第二個 AI 隊友叫 IncidentSweep,負責的是事故後的掃尾工作。

以前服務修好之後,客服處理積壓工單通常只有兩個極端:要麼人工一張一張回,耗費幾個小時;要麼全選後用宏統一批量回復,但很容易誤傷那些只是碰巧提單、問題其實不相干的使用者。

IncidentSweep 走的是中間路線。工程師先告訴它這次要處理什麼、排除什麼以及發什麼文案。它會自動篩查所有匹配的工單,把沒把握確認關聯的單子挑出來放一邊,然後把整理好的列表和文案端給工程師抽檢。只有工程師點選批准後,它才會小批次分批發送,並且中途絕不追加新單,一旦報錯就立刻停下來彙報。

在 9 月 18 日的一次實際事故中,IncidentSweep 在工程師稽核批准後,大約 10 分鐘就清空了 204 張工單。

為什麼重要

對企業客服和運維團隊來說,這套機制最大的價值在於把支援人員從重複且高壓的體力活裡解放了出來。遇到系統故障時,客服最怕兩件事:一是不知道出了事還在盲目回覆,二是事後要機械地點擊發送幾百次同樣的安撫話術。如果你管理著一箇中大型產品的支援團隊,現在完全可以用類似的思路搭建自動化流程,門檻不在於大模型本身,而在於你願不願意給工作流設計嚴密的確認卡點。

從行業角度看,xAI 展現了一個很務實的 Agent 落地切入點。很多團隊還在糾結怎麼讓 AI 獨立解決複雜的程式碼問題,xAI 卻把重點放在了那些卡在人和系統縫隙裡的髒活累活上。讓工單變成比監控系統更靈敏的感測器,這個邏輯非常順理成章,因為終端使用者的體感往往比後臺指標更有前瞻性。

我們認為,IncidentSweep 的設計尤其聰明在它的剋制。它沒有嘗試完全自動化,也沒有追求一鍵全發,而是堅持讓人做最終審批、保留剔除不確定項的機制、並限制審批後不得追加新單。很多企業做自動化總想一步到位把人去掉,結果往往導致發錯客戶的公關災難。把確定性的篩查交給 AI,把兜底的權力留給工程師,這看起來是目前企業引入智慧體最穩妥、也最值得抄作業的姿勢。

來源 (1)

  1. [1]
    x.ai(在新分頁開啟)原文x.ai

每日 AI 內容精選