1. 從“Oncall”說(shuō)起當(dāng)AI開(kāi)始值夜班深夜兩點(diǎn)警報(bào)響起。一個(gè)線上服務(wù)因?yàn)槟硞€(gè)依賴的API響應(yīng)變慢觸發(fā)了P1級(jí)別的告警。值班工程師Oncall Engineer被電話叫醒睡眼惺忪地打開(kāi)電腦開(kāi)始排查是網(wǎng)絡(luò)問(wèn)題是下游服務(wù)掛了還是自己的代碼有bug他需要快速查看監(jiān)控圖表、分析日志、執(zhí)行診斷命令并在黃金修復(fù)時(shí)間內(nèi)做出決策——是重啟、擴(kuò)容、回滾還是聯(lián)系其他團(tuán)隊(duì)這個(gè)過(guò)程我們稱之為“Oncall”它是現(xiàn)代軟件工程中保障服務(wù)可靠性的核心環(huán)節(jié)也是對(duì)工程師綜合能力的終極考驗(yàn)技術(shù)深度、應(yīng)急判斷、溝通協(xié)作缺一不可。那么如果把這個(gè)考驗(yàn)交給一個(gè)語(yǔ)言模型Language Model, LM呢這就是“ORCA-bench: How Ready Are Language Model Agents for Oncall?”這個(gè)標(biāo)題背后一個(gè)既前沿又極具現(xiàn)實(shí)意義的問(wèn)題。它探討的遠(yuǎn)不止是讓AI“看懂”幾個(gè)錯(cuò)誤日志而是評(píng)估一個(gè)由大語(yǔ)言模型驅(qū)動(dòng)的智能體Agent是否具備像一個(gè)合格的人類(lèi)Oncall工程師一樣在復(fù)雜、動(dòng)態(tài)、高壓的真實(shí)生產(chǎn)環(huán)境中完成端到端故障排查與應(yīng)急響應(yīng)的能力。ORCA-bench就是這個(gè)評(píng)估的“考場(chǎng)”和“評(píng)分標(biāo)準(zhǔn)”。最近關(guān)于AI智能體Agents的討論如火如荼從自動(dòng)編寫(xiě)代碼到規(guī)劃復(fù)雜任務(wù)似乎無(wú)所不能。但“Oncall”是一個(gè)特殊的領(lǐng)域它充滿了不確定性、模糊性和時(shí)間壓力。一個(gè)在代碼生成上表現(xiàn)優(yōu)異的模型面對(duì)一條含義模糊的告警信息、一堆雜亂無(wú)章的日志、以及需要跨多個(gè)系統(tǒng)進(jìn)行探查的復(fù)雜鏈路時(shí)很可能瞬間“懵圈”。ORCA-bench的出現(xiàn)正是為了系統(tǒng)性地回答當(dāng)前這些風(fēng)光無(wú)限的LM Agents在“值夜班”這件事上到底準(zhǔn)備好了沒(méi)有是已經(jīng)能獨(dú)當(dāng)一面還是僅僅停留在“玩具”階段這對(duì)于未來(lái)人機(jī)協(xié)同運(yùn)維、乃至自動(dòng)駕駛運(yùn)維AIOps的演進(jìn)方向有著至關(guān)重要的指引作用。2. ORCA-bench拆解一個(gè)為AI Oncall量身定制的“壓力測(cè)試場(chǎng)”要理解ORCA-bench的價(jià)值我們得先把它拆開(kāi)來(lái)看。這個(gè)名字本身就蘊(yùn)含了其設(shè)計(jì)目標(biāo)OperationalReadiness forCyber-Articulation即“面向網(wǎng)絡(luò)表達(dá)的操作就緒度評(píng)估”。簡(jiǎn)單說(shuō)它評(píng)估的是AI智能體在真實(shí)的運(yùn)維Operations場(chǎng)景下通過(guò)“表達(dá)”理解、推理、決策、執(zhí)行來(lái)解決問(wèn)題的能力。這個(gè)基準(zhǔn)測(cè)試Benchmark的核心不是一堆靜態(tài)的、定義良好的選擇題或代碼題而是一個(gè)高度仿真的動(dòng)態(tài)環(huán)境。想象一下ORCA-bench為AI智能體搭建了一個(gè)微縮的、但要素齊全的“線上系統(tǒng)沙盤(pán)”。這個(gè)沙盤(pán)里可能包含模擬的服務(wù)與依賴?yán)缫粋€(gè)Web前端服務(wù)、一個(gè)訂單處理服務(wù)、一個(gè)數(shù)據(jù)庫(kù)和一個(gè)緩存服務(wù)它們之間通過(guò)模擬的API進(jìn)行調(diào)用?？勺⑷氲墓收蠝y(cè)試者可以像導(dǎo)演一樣在沙盤(pán)中“制造”各種真實(shí)世界常見(jiàn)的故障。比如讓數(shù)據(jù)庫(kù)連接突然變慢模擬網(wǎng)絡(luò)抖動(dòng)讓某個(gè)API端點(diǎn)返回錯(cuò)誤碼模擬下游服務(wù)異常或者讓緩存集群的某個(gè)節(jié)點(diǎn)失聯(lián)模擬硬件故障。豐富的可觀測(cè)性數(shù)據(jù)AI智能體可以像人類(lèi)工程師一樣“看到”這個(gè)沙盤(pán)里的監(jiān)控?cái)?shù)據(jù)如CPU/內(nèi)存使用率、請(qǐng)求QPS、延遲P99、結(jié)構(gòu)化日志包含錯(cuò)誤堆棧、請(qǐng)求ID以及分布式鏈路追蹤Trace能看到一次請(qǐng)求流經(jīng)了哪些服務(wù)。AI智能體的任務(wù)就是扮演Oncall工程師接入這個(gè)沙盤(pán)。當(dāng)故障被注入后它會(huì)收到告警通知就像人類(lèi)工程師收到PagerDuty或釘釘告警一樣然后它需要自主地理解告警這條告警在說(shuō)什么哪個(gè)服務(wù)什么指標(biāo)異常信息收集主動(dòng)去查詢相關(guān)的監(jiān)控圖表、搜索特定時(shí)間段的日志、查看鏈路追蹤。根因分析基于收集到的信息進(jìn)行邏輯推理。是數(shù)據(jù)庫(kù)慢了導(dǎo)致全鏈路雪崩還是前端代碼發(fā)布了一個(gè)有bug的版本或者是某個(gè)中間件配置錯(cuò)誤制定與執(zhí)行修復(fù)動(dòng)作給出修復(fù)方案并能在沙盤(pán)的安全邊界內(nèi)執(zhí)行。例如執(zhí)行一個(gè)“重啟數(shù)據(jù)庫(kù)從節(jié)點(diǎn)”的命令或“將流量從故障的緩存節(jié)點(diǎn)切走”的配置變更。驗(yàn)證與閉環(huán)執(zhí)行動(dòng)作后繼續(xù)觀察監(jiān)控指標(biāo)是否恢復(fù)正常確認(rèn)故障是否被解決。整個(gè)過(guò)程中ORCA-bench會(huì)從多個(gè)維度對(duì)智能體的表現(xiàn)進(jìn)行打分診斷準(zhǔn)確性找對(duì)根本原因了嗎、動(dòng)作有效性采取的行動(dòng)真的解決問(wèn)題了嗎、步驟效率是否用了最少的、必要的探查步驟以及操作安全性有沒(méi)有執(zhí)行危險(xiǎn)或無(wú)關(guān)的操作。這就像給AI智能體設(shè)置了一個(gè)全真模擬的“臨床執(zhí)業(yè)醫(yī)師考試”考的不是背書(shū)而是在模擬診室里處理各種疑難雜癥的能力。通過(guò)ORCA-bench我們才能客觀地比較不同模型、不同智能體框架如LangChain, AutoGPT, CrewAI等在真實(shí)運(yùn)維場(chǎng)景下的強(qiáng)弱項(xiàng)。3. LM Agents的“Oncall能力”解剖優(yōu)勢(shì)、短板與當(dāng)前瓶頸基于ORCA-bench這類(lèi)測(cè)試所揭示的結(jié)果我們可以對(duì)當(dāng)前LM Agents的Oncall能力進(jìn)行一次深度“體檢”。我的觀察是它們?cè)谀承┓矫嬲宫F(xiàn)出了令人驚訝的潛力但在更多關(guān)鍵環(huán)節(jié)上仍存在明顯的“阿喀琉斯之踵”。3.1 令人驚喜的潛力信息整合與模式識(shí)別大語(yǔ)言模型最核心的優(yōu)勢(shì)在于其對(duì)自然語(yǔ)言的深刻理解和強(qiáng)大的信息整合能力。這在Oncall的初期階段作用顯著。多源異構(gòu)信息的快速消化人類(lèi)工程師需要花時(shí)間在不同監(jiān)控系統(tǒng)如Grafana、日志平臺(tái)如ELK和追蹤系統(tǒng)如Jaeger間切換并手動(dòng)關(guān)聯(lián)信息。一個(gè)訓(xùn)練有素的LM Agent可以近乎實(shí)時(shí)地解析這些不同格式的數(shù)據(jù)將一條高延遲告警、一個(gè)數(shù)據(jù)庫(kù)連接錯(cuò)誤的日志、以及一條顯示在某個(gè)服務(wù)層“卡住”的追蹤鏈路自動(dòng)關(guān)聯(lián)起來(lái)形成一個(gè)初步的故障假設(shè)。這大大縮短了信息收集和初步判斷的時(shí)間。歷史經(jīng)驗(yàn)的“模糊”匹配模型在訓(xùn)練時(shí)“閱讀”過(guò)海量的技術(shù)文檔、故障報(bào)告Post-mortem和社區(qū)問(wèn)答。當(dāng)遇到“Kafka consumer lag激增”的告警時(shí)它可能立刻聯(lián)想到幾種常見(jiàn)原因消費(fèi)者組重啟、消息處理邏輯變慢、或分區(qū)再平衡。它能將這些可能性按概率排序?yàn)榕挪樘峁┓较?。這種能力是新入職的工程師需要積累數(shù)月才能獲得的。3.2 當(dāng)前的核心短板確定性推理、工具使用與“常識(shí)”然而當(dāng)深入到具體排查和操作時(shí)問(wèn)題就暴露出來(lái)了。缺乏確定性的、鏈?zhǔn)降倪壿嬐评砟芰ncall排查是一個(gè)嚴(yán)密的邏輯推理過(guò)程往往遵循“假設(shè)-驗(yàn)證”的循環(huán)。例如假設(shè)是數(shù)據(jù)庫(kù)慢那么下一步就應(yīng)該去查數(shù)據(jù)庫(kù)的監(jiān)控CPU、IO、慢查詢?nèi)绻O(jiān)控正常則否定該假設(shè)轉(zhuǎn)向下一個(gè)如網(wǎng)絡(luò)。但當(dāng)前的LM Agents其推理過(guò)程本質(zhì)上是基于概率的“聯(lián)想”而非確定性的“演繹”。它可能會(huì)從一個(gè)數(shù)據(jù)庫(kù)錯(cuò)誤日志“聯(lián)想”到去檢查前端JavaScript代碼做出跳躍的、缺乏邏輯鏈條的決策。在ORCA-bench中這表現(xiàn)為無(wú)效的探查步驟增多甚至得出荒謬的根因結(jié)論。工具使用的精確性與安全性問(wèn)題讓AI執(zhí)行kubectl delete pod刪除K8s Pod或rm -rf刪除文件命令是極其危險(xiǎn)的。即使是在沙盤(pán)中評(píng)估其工具使用的精確性也至關(guān)重要。當(dāng)前Agent在調(diào)用復(fù)雜命令行工具時(shí)容易在參數(shù)生成上出錯(cuò)。更關(guān)鍵的是它缺乏人類(lèi)工程師那種對(duì)操作后果的“敬畏感”和“雙重確認(rèn)”本能。它可能為了“解決”一個(gè)Pod不斷重啟的問(wèn)題而草率地執(zhí)行刪除操作卻不知道這可能導(dǎo)致服務(wù)中斷。運(yùn)維“常識(shí)”的缺失這是最微妙也最致命的一點(diǎn)。人類(lèi)的Oncall經(jīng)驗(yàn)中充滿了“常識(shí)”例如“在業(yè)務(wù)低峰期如凌晨進(jìn)行重啟操作”、“更改配置后需要觀察幾分鐘再確認(rèn)效果”、“如果某個(gè)操作不確定先在小流量或預(yù)發(fā)環(huán)境驗(yàn)證”。這些常識(shí)很少被寫(xiě)在正式的運(yùn)維手冊(cè)里卻是保障操作安全的關(guān)鍵。當(dāng)前的LM Agents幾乎完全缺乏這類(lèi)上下文和約束意識(shí)其行為是“目標(biāo)驅(qū)動(dòng)”而非“風(fēng)險(xiǎn)感知”的。3.3 瓶頸背后的技術(shù)根源這些短板的根源在于當(dāng)前LM Agents架構(gòu)與Oncall任務(wù)需求之間的根本性錯(cuò)配。訓(xùn)練數(shù)據(jù)的偏差大語(yǔ)言模型的訓(xùn)練語(yǔ)料以通用文本、代碼為主雖然包含一些運(yùn)維文檔但極度缺乏高質(zhì)量的、結(jié)構(gòu)化的“決策過(guò)程”數(shù)據(jù)。我們能看到故障報(bào)告結(jié)果但模型學(xué)不到人類(lèi)工程師在黑暗中摸索、試錯(cuò)、排除的完整思維鏈條。這導(dǎo)致模型可以“描述”故障卻難以“重現(xiàn)”診斷過(guò)程。規(guī)劃與反思能力的不足一個(gè)強(qiáng)大的Oncall Agent需要具備動(dòng)態(tài)規(guī)劃能力根據(jù)新收集到的信息實(shí)時(shí)調(diào)整排查計(jì)劃。同時(shí)還需要有反思能力當(dāng)執(zhí)行某個(gè)命令失敗或未達(dá)到預(yù)期效果時(shí)能分析原因并調(diào)整策略。目前大多數(shù)Agent框架的“規(guī)劃”模塊還相對(duì)簡(jiǎn)單和脆弱容易在復(fù)雜場(chǎng)景下陷入循環(huán)或跑偏。與真實(shí)環(huán)境的“隔離墻”O(jiān)RCA-bench再逼真也是沙盤(pán)。真實(shí)生產(chǎn)環(huán)境有更多的“噪音”不準(zhǔn)確的監(jiān)控、殘缺的日志、復(fù)雜的權(quán)限體系、突發(fā)的并行事件。如何讓Agent在充滿不確定性的真實(shí)環(huán)境中保持穩(wěn)健是另一個(gè)維度的挑戰(zhàn)。4. 從評(píng)估到實(shí)踐構(gòu)建可用Oncall Agent的關(guān)鍵組件與設(shè)計(jì)思路ORCA-bench為我們指明了方向也揭示了差距。那么如果我們今天就想著手構(gòu)建一個(gè)初步可用的Oncall輔助Agent應(yīng)該從哪里入手結(jié)合業(yè)界的一些探索和我個(gè)人的實(shí)踐思考我認(rèn)為以下幾個(gè)組件和設(shè)計(jì)思路至關(guān)重要。4.1 核心組件一領(lǐng)域知識(shí)增強(qiáng)的“運(yùn)維大腦”我們不能指望一個(gè)通用大模型直接變成運(yùn)維專家。必須為其注入領(lǐng)域知識(shí)Domain Knowledge。構(gòu)建運(yùn)維知識(shí)圖譜將你的系統(tǒng)架構(gòu)圖、服務(wù)依賴關(guān)系、關(guān)鍵SLO指標(biāo)、歷史故障案例、運(yùn)維操作手冊(cè)Runbook等結(jié)構(gòu)化地構(gòu)建成一個(gè)知識(shí)圖譜。當(dāng)Agent收到“訂單服務(wù)延遲高”的告警時(shí)它能立刻從圖譜中知道訂單服務(wù)依賴支付服務(wù)和庫(kù)存服務(wù)它的核心指標(biāo)是創(chuàng)建訂單API的P99延遲上個(gè)月曾因支付服務(wù)網(wǎng)關(guān)超時(shí)導(dǎo)致過(guò)類(lèi)似問(wèn)題。這為Agent的推理提供了堅(jiān)實(shí)的上下文基礎(chǔ)。微調(diào)與提示工程結(jié)合使用高質(zhì)量的運(yùn)維對(duì)話數(shù)據(jù)、故障排查記錄對(duì)基礎(chǔ)模型進(jìn)行微調(diào)Fine-tuning可以顯著提升其在運(yùn)維語(yǔ)境下的理解能力。同時(shí)設(shè)計(jì)精妙的提示詞Prompt模板將當(dāng)前告警、相關(guān)監(jiān)控?cái)?shù)據(jù)、知識(shí)圖譜片段作為上下文Context輸入給模型引導(dǎo)其進(jìn)行更專業(yè)的思考。例如提示詞可以強(qiáng)制要求模型按照“1. 現(xiàn)象描述 - 2. 可能原因假設(shè)基于知識(shí)圖譜- 3. 下一步驗(yàn)證步驟”的結(jié)構(gòu)輸出。4.2 核心組件二安全且精準(zhǔn)的“工具執(zhí)行層”這是將AI的“思考”轉(zhuǎn)化為“行動(dòng)”的關(guān)鍵也是安全紅線所在。工具抽象與權(quán)限最小化不要直接讓Agent生成原始的kubectl或linux shell命令。應(yīng)該為其封裝一套高度抽象、安全的工具API。例如提供一個(gè)名為restart_pod(service_name, environment)的工具背后對(duì)接的是經(jīng)過(guò)嚴(yán)格參數(shù)校驗(yàn)、并且只能在預(yù)發(fā)環(huán)境執(zhí)行的標(biāo)準(zhǔn)化重啟腳本。遵循權(quán)限最小化原則生產(chǎn)環(huán)境的寫(xiě)操作如刪除、重啟初期絕對(duì)不應(yīng)該對(duì)Agent開(kāi)放。操作模擬與預(yù)校驗(yàn)在Agent正式執(zhí)行任何有潛在風(fēng)險(xiǎn)的操作前增加一個(gè)“模擬運(yùn)行”或“預(yù)校驗(yàn)”環(huán)節(jié)。例如Agent計(jì)劃執(zhí)行“擴(kuò)容數(shù)據(jù)庫(kù)從節(jié)點(diǎn)”工具層可以先模擬執(zhí)行并返回一個(gè)預(yù)估的影響報(bào)告“此操作將增加3個(gè)只讀節(jié)點(diǎn)預(yù)計(jì)耗時(shí)5分鐘期間讀取性能可能短暫下降”由人類(lèi)工程師確認(rèn)后再實(shí)際執(zhí)行。或者對(duì)于某些操作強(qiáng)制要求Agent必須提供“為什么這個(gè)操作能解決當(dāng)前問(wèn)題”的解釋。4.3 核心組件三基于確定性工作流的“推理導(dǎo)航器”為了解決模型推理跳躍的問(wèn)題不能完全依賴模型的自由發(fā)揮需要引入一些確定性的框架來(lái)約束和引導(dǎo)其行為。集成診斷決策樹(shù)將一些常見(jiàn)故障的排查路徑編碼成決策樹(shù)或狀態(tài)機(jī)。當(dāng)Agent識(shí)別出故障可能屬于某一類(lèi)如“數(shù)據(jù)庫(kù)相關(guān)”、“網(wǎng)絡(luò)相關(guān)”時(shí)可以激活對(duì)應(yīng)的決策樹(shù)模塊。這個(gè)模塊會(huì)以更確定性的方式一步步詢問(wèn)模型“當(dāng)前數(shù)據(jù)庫(kù)CPU是否高于80%”如果模型回答“是”則引導(dǎo)至“檢查慢查詢”步驟如果“否”則引導(dǎo)至“檢查網(wǎng)絡(luò)連接”步驟。這相當(dāng)于給模型的自由聯(lián)想套上了一個(gè)“導(dǎo)航軌”保證排查過(guò)程不跑偏。實(shí)施分階段協(xié)作模式人機(jī)回環(huán)在現(xiàn)階段追求完全自治是不切實(shí)際的。更可行的模式是“分階段協(xié)作”。讓Agent擔(dān)任一級(jí)響應(yīng)Tier-1角色自動(dòng)完成信息聚合、初步分析、甚至執(zhí)行一些無(wú)害的診斷命令如grep日志并生成一份包含“當(dāng)前現(xiàn)象”、“已收集數(shù)據(jù)”、“根因假設(shè)附置信度”、“建議操作”的摘要報(bào)告。人類(lèi)工程師作為二級(jí)響應(yīng)Tier-2快速審核這份報(bào)告確認(rèn)或修正根因并授權(quán)執(zhí)行修復(fù)操作。這樣既利用了AI的效率又保留了人類(lèi)的關(guān)鍵判斷和安全控制。5. 實(shí)測(cè)挑戰(zhàn)與未來(lái)展望我們離AI Oncall還有多遠(yuǎn)即便我們按照上述思路構(gòu)建了一個(gè)Agent在將其推向真實(shí)Oncall輪值之前仍然會(huì)面臨一系列嚴(yán)峻的實(shí)測(cè)挑戰(zhàn)。首先是對(duì)抗“幻覺(jué)”的持久戰(zhàn)。在壓力下模型為了給出一個(gè)答案可能會(huì)“捏造”一個(gè)不存在的監(jiān)控指標(biāo)或“引用”一個(gè)知識(shí)圖譜里沒(méi)有的故障案例。我們需要在系統(tǒng)中內(nèi)置強(qiáng)大的事實(shí)核查Fact-Checking機(jī)制例如對(duì)Agent輸出的每一個(gè)關(guān)鍵判斷如“A服務(wù)調(diào)用B服務(wù)超時(shí)”都要求它必須附上可驗(yàn)證的數(shù)據(jù)來(lái)源如具體的追蹤ID或日志時(shí)間戳系統(tǒng)會(huì)自動(dòng)進(jìn)行校驗(yàn)如果校驗(yàn)不通過(guò)則該判斷被標(biāo)記為不可信。其次是處理“未知未知”故障的能力。ORCA-bench可以測(cè)試已知故障模式但真實(shí)世界總會(huì)出現(xiàn)前所未有的新問(wèn)題。面對(duì)全新的、訓(xùn)練數(shù)據(jù)中從未出現(xiàn)過(guò)的錯(cuò)誤模式Agent很可能完全失效甚至產(chǎn)生誤導(dǎo)。這就要求系統(tǒng)必須具備良好的“降級(jí)”機(jī)制當(dāng)Agent的置信度低于某個(gè)閾值或其在預(yù)設(shè)的步驟內(nèi)無(wú)法取得進(jìn)展時(shí)能清晰地“舉手投降”并立即、無(wú)延遲地將任務(wù)全權(quán)移交人類(lèi)同時(shí)提供它已嘗試過(guò)的所有路徑和結(jié)果供人類(lèi)參考。最后是信任與責(zé)任的建立。運(yùn)維是關(guān)乎業(yè)務(wù)連續(xù)性的重任信任需要一點(diǎn)點(diǎn)積累?？梢詮摹爸蛔x助手”開(kāi)始讓Agent在人類(lèi)工程師排查時(shí)作為實(shí)時(shí)信息查詢和案例推薦的副駕駛。然后逐步開(kāi)放一些低風(fēng)險(xiǎn)、可回滾的操作權(quán)限如在測(cè)試環(huán)境執(zhí)行故障注入演練。通過(guò)長(zhǎng)期記錄Agent的“診斷準(zhǔn)確率”和“動(dòng)作成功率”等客觀指標(biāo)來(lái)建立團(tuán)隊(duì)對(duì)它的理性信任。從我個(gè)人的實(shí)踐角度看短期內(nèi)1-2年LM Agents最現(xiàn)實(shí)的定位是“超級(jí)輔助”承擔(dān)起信息聚合、初步篩選、文檔檢索、執(zhí)行標(biāo)準(zhǔn)化操作腳本等重復(fù)性勞動(dòng)將人類(lèi)工程師從繁瑣的信息篩選中解放出來(lái)專注于更高層的決策和復(fù)雜問(wèn)題的解決。中長(zhǎng)期看隨著模型推理能力的強(qiáng)化、更多高質(zhì)量決策過(guò)程數(shù)據(jù)的喂養(yǎng)、以及人機(jī)協(xié)作模式的成熟我們或許能看到AI開(kāi)始獨(dú)立處理一些定義相對(duì)清晰、模式常見(jiàn)的夜間告警NOC Alert實(shí)現(xiàn)真正意義上的“自動(dòng)駕駛運(yùn)維”第一站。這條路注定漫長(zhǎng)但ORCA-bench這樣的基準(zhǔn)測(cè)試就像迷霧中的燈塔清晰地標(biāo)出了我們當(dāng)前的位置和需要前進(jìn)的方向。它告訴我們興奮是應(yīng)該的但盲目樂(lè)觀是危險(xiǎn)的。構(gòu)建一個(gè)可靠的AI Oncall伙伴不是簡(jiǎn)單地將ChatGPT接入運(yùn)維系統(tǒng)而是一項(xiàng)需要融合軟件工程、機(jī)器學(xué)習(xí)、運(yùn)維實(shí)踐和安全設(shè)計(jì)的系統(tǒng)工程。每一次在ORCA-bench上分?jǐn)?shù)的提升都意味著我們朝著“讓工程師睡個(gè)好覺(jué)”這個(gè)樸實(shí)而偉大的目標(biāo)又邁進(jìn)了一小步。