做運(yùn)維的人應(yīng)該都有過這種沖動(dòng)半夜告警響了爬起來看一眼發(fā)現(xiàn)只是某個(gè)服務(wù)抖動(dòng)了一下自己恢復(fù)了或者收到一堆日志排查半天定位到一個(gè)早就該有人處理的配置項(xiàng)。那時(shí)候就在想這些事能不能讓機(jī)器自己干了說實(shí)話傳統(tǒng)的腳本和自動(dòng)化能做不少事但遇到“需要判斷、需要協(xié)同、需要臨時(shí)改策略”的場(chǎng)景腳本就僵住了。最近我在折騰 AI 運(yùn)維 Agent試了一套多智能體協(xié)同的方案讓幾個(gè) Agent 自己分工、自己干活、自己匯報(bào)效果比預(yù)期好不少。這篇就聊聊這個(gè)系統(tǒng)是怎么搭的、里面的 Agent 怎么協(xié)作、以及實(shí)測(cè)下來的真實(shí)表現(xiàn)踩過的坑也一并寫出來。這適合已經(jīng)在用自動(dòng)化腳本、但想往智能化走一步的運(yùn)維同學(xué)也適合對(duì) Agent 概念感興趣、想看看它在運(yùn)維場(chǎng)景里到底能干啥的人。不需要你有大模型訓(xùn)練基礎(chǔ)但得對(duì) Linux、API、工作流編排有點(diǎn)概念。1. AI 運(yùn)維 Agent 的“自主做事”靠的不是大模型本身先說一個(gè)容易誤會(huì)的點(diǎn)AI 運(yùn)維 Agent 不是把大模型接進(jìn)來就完事了。大模型本身只能理解語言、生成文本它不會(huì)執(zhí)行命令、拉取指標(biāo)、改配置。真正讓它“自己做事”的是一套把它跟運(yùn)維系統(tǒng)連起來的執(zhí)行鏈路。1.1 從“聊天”到“干活”隔著一個(gè)完整的工具鏈我見過不少人說“接入大模型之后能讓它幫我查日志嗎”。實(shí)際上大模型返回的只是一段文本甚至可能是一段“我建議你執(zhí)行 xxx 命令”的文字。要讓它真的去查日志、去重啟服務(wù)需要做三件事第一給大模型提供工具。每個(gè)運(yùn)維動(dòng)作都得封裝成一個(gè)可調(diào)用的函數(shù)或接口比如“查 CPU 使用率”“拉取最近 1 小時(shí)錯(cuò)誤日志”“重啟某個(gè) Pod”“回滾某個(gè)版本”。這一步很像把所有常用運(yùn)維操作做成 REST APIAgent 通過調(diào)用函數(shù)來執(zhí)行動(dòng)作。第二給大模型觀察結(jié)果的能力。一次調(diào)用可能不夠Agent 得能連續(xù)多輪“觀察-思考-行動(dòng)”。比如先查指標(biāo)指標(biāo)異常再查日志日志里看到某個(gè)錯(cuò)誤碼再?zèng)Q定下一步動(dòng)作。這個(gè)循環(huán)是 Agent 能做決策的基礎(chǔ)。第三設(shè)置邊界和審批機(jī)制。自主不等于不受控尤其是生產(chǎn)環(huán)境。初期部署時(shí)每臺(tái)機(jī)器都配了白名單命令和操作風(fēng)控超過閾值的操作會(huì)轉(zhuǎn)人工確認(rèn)。所以“自己做事”的本質(zhì)是大模型負(fù)責(zé)推理、規(guī)劃和拆解任務(wù)工具層負(fù)責(zé)執(zhí)行編排層負(fù)責(zé)控制節(jié)奏和風(fēng)險(xiǎn)。三者缺一不可。1.2 我的第一個(gè)最小閉環(huán) Demo我最開始跑通的版本很簡(jiǎn)單一臺(tái)測(cè)試服務(wù)器部署了一個(gè)大模型接口通過 Python 寫了一個(gè)執(zhí)行器腳本封裝了三個(gè)函數(shù)get_cpu()、get_disk()、restart_service()。然后給模型一個(gè)目標(biāo)“檢查 CPU 持續(xù) 5 分鐘高于 80% 時(shí)重啟應(yīng)用服務(wù)”。這次跑通過程讓我理解了關(guān)鍵的機(jī)制Agent 不是一次性生成答案而是進(jìn)入了循環(huán)模式。第一輪調(diào)用模型模型返回“先執(zhí)行 get_cpu()”執(zhí)行器去查系統(tǒng)指標(biāo)把結(jié)果塞回對(duì)話上下文模型看到 CPU 確實(shí)高繼續(xù)執(zhí)行restart_service()然后再檢查一次 CPU 是否回落。整個(gè)過程沒有人工參與。心跳定時(shí)器驅(qū)動(dòng)了這個(gè)循環(huán)。每檢查一次算一個(gè) step通常任務(wù)要 3~6 個(gè) step 才能完成。為了不把上下文撐爆我給對(duì)話歷史做了截?cái)嘀槐Ａ糇罱?10 輪往返。這也是后面很多問題的根源后面會(huì)細(xì)說。2. 多智能體協(xié)同不是“一堆模型開會(huì)”而是“流水線 分工”單 Agent 能做的事很有限。真正想覆蓋“監(jiān)控發(fā)現(xiàn)、根因定位、止損恢復(fù)、通知響應(yīng)”這條完整鏈路得讓不同 Agent 各管一段互相配合。2.1 每個(gè) Agent 的角色畫像和能力邊界我最終部署的這套環(huán)境里定義了四個(gè) Agent每個(gè)都有自己的職責(zé)和工具集Monitor Agent 專職盯告警和指標(biāo)。它定時(shí)輪詢監(jiān)控系統(tǒng)一旦觸發(fā)閾值就生成一條結(jié)構(gòu)化事件。它不負(fù)責(zé)修復(fù)只負(fù)責(zé)“發(fā)現(xiàn)問題并發(fā)出信息”。Diagnose Agent 專職分析。它拿到 Monitor 的事件后去拉日志、查依賴關(guān)系、看最近變更記錄輸出一份帶置信度的根因判斷。它不直接操作只給結(jié)論。Executor Agent 專職執(zhí)行動(dòng)作。它接收 Diagnose 的判斷結(jié)果匹配預(yù)案庫里的操作步驟執(zhí)行重啟、回滾、擴(kuò)縮容等操作。它需要最嚴(yán)格的風(fēng)控。Notify Agent 專職通報(bào)。所有階段性結(jié)論、執(zhí)行結(jié)果、人工確認(rèn)請(qǐng)求都由它發(fā)出發(fā)到企業(yè)微信或釘釘機(jī)器人。它不做決策只是保持信息透明。四者協(xié)作按照標(biāo)準(zhǔn)的三個(gè)階段推進(jìn)——發(fā)現(xiàn)、診斷、處置——構(gòu)成完整閉環(huán)。2.2 關(guān)鍵在于Agent 之間如何交換信息多 Agent 架構(gòu)里最常見的坑是各說各話。每個(gè) Agent 都接了大模型如果不做結(jié)構(gòu)化管理它們之間傳的就是一堆自然語言段落結(jié)果后面的 Agent 根本沒法穩(wěn)定地把關(guān)鍵信息提取出來。我用的辦法是所有 Agent 之間只通過 JSON 結(jié)構(gòu)傳消息。Monitor 輸出的事件格式固定{ event_id: evt_001, type: cpu_high, severity: P2, target: order-service, metrics: { cpu_usage: 92.5, load1: 18.3 }, timestamp: 2025-01-10T14:23:00Z }Diagnose 拿到這個(gè)消息后解析target和type決定拉哪些數(shù)據(jù)源輸出根因判斷也走固定格式{ event_id: evt_001, root_cause: jvm_old_gc, confidence: 0.87, evidence: [gc log count12, heap usage95%], suggested_actions: [restart_service, increase_heap] }這樣做的好處是每個(gè) Agent 都不需要理解其他 Agent 的“思維過程”只需要消費(fèi)結(jié)構(gòu)化的輸入、產(chǎn)出結(jié)構(gòu)化的輸出。大模型的不穩(wěn)定性被鎖在了各自的處理流程里Agent 間的通信反而是穩(wěn)定的。這一步我強(qiáng)烈建議不要省略。早期版本試過直接傳自然語言Diagnose 經(jīng)常把 Monitor 的意思理解偏甚至?xí)约耗X補(bǔ)出不存在的問題。2.3 協(xié)同編排一個(gè)輕量的任務(wù)狀態(tài)機(jī)四個(gè) Agent 不是并行隨便跑的它們得按一個(gè)流程走同時(shí)允許異常分支。我用了很輕量的狀態(tài)機(jī)來做編排沒有引入重型工作流框架就維護(hù)一張任務(wù)狀態(tài)表狀態(tài)負(fù)責(zé) Agent流轉(zhuǎn)條件detectedMonitor指標(biāo)越限diagnosingDiagnose收到事件root_causedDiagnose輸出根因置信度 0.6executingExecutor收到建議動(dòng)作recoveredExecutor恢復(fù)命令返回成功notifiedNotify消息發(fā)送成功wait_approvalExecutor置信度低或超閾值操作每個(gè) Agent 異步處理處理完就更新狀態(tài)。狀態(tài)一旦更新會(huì)觸發(fā)現(xiàn)有定義的下一跳。這套模型足夠簡(jiǎn)單但也踩了不少坑。后面遇到的最多問題都是狀態(tài)沒流轉(zhuǎn)到、事件卡死這類細(xì)節(jié)讓我意識(shí)到編排層和 Agent 一樣重要。3. 部署實(shí)踐從零搭一個(gè)能自主處置告警的 Agent 系統(tǒng)如果你也想搭一套類似的系統(tǒng)我這里把可復(fù)制的步驟整理一遍假設(shè)環(huán)境是一臺(tái) Linux 服務(wù)器、Docker、Python 3.9、已經(jīng)有大模型 API 的訪問權(quán)限。監(jiān)控?cái)?shù)據(jù)源我們先拿 Prometheus 的 API 來測(cè)。3.1 環(huán)境準(zhǔn)備和必要的組件清單系統(tǒng)拆四個(gè)模塊部署用 Docker Compose 管理。四個(gè)模塊分別是事件總線用輕量消息隊(duì)列、Agent 執(zhí)行器Python 進(jìn)程、編排引擎帶狀態(tài)表的小服務(wù)用 FastAPI 寫的、管理面板只用來查日志和狀態(tài)。實(shí)際部署過程中有幾件事要提醒第一大模型 API 一定要走內(nèi)網(wǎng)或代理地址不然每次 Agent 調(diào)用都走公網(wǎng)延遲不可控。后面排查問題的時(shí)候就遇到過一次因?yàn)橥饩W(wǎng)不穩(wěn)定導(dǎo)致 Diagnose 響應(yīng)超時(shí)整體任務(wù)狀態(tài)卡了十幾分鐘。第二所有 Agent 需要共享一套時(shí)鐘。最開始排查一個(gè)“事件順序錯(cuò)亂”的問題發(fā)現(xiàn)是不同容器的系統(tǒng)時(shí)間偏差了十幾秒診斷 agent 讀到的日志時(shí)序是反的。第三日志必須全部帶結(jié)構(gòu)化字段。最好不要只靠打印字符串。后面調(diào)試多 Agent 協(xié)作時(shí)一篇混亂的日志根本沒法快速定位是哪個(gè)環(huán)節(jié)出了問題。Docker Compose 的 service 定義大致長這樣單機(jī)玩法夠用了version: 3.8 services: queue: image: valkey/valkey:7.2 ports: [6379:6379] executor: build: ./executor environment: - MODEL_ENDPOINThttp://llm-gateway:8080/v1 - TOOL_WHITELISTrestart_service,get_cpu,get_mem volumes: - /var/run/docker.sock:/var/run/docker.sock orchestrator: build: ./orchestrator ports: [8081:8080] depends_on: - queue第一版跑起來之后建議不要一次啟用四個(gè) Agent。我是先用假的告警數(shù)據(jù)流把事件總線拆通再逐個(gè)開啟 Agent 驗(yàn)證。3.2 編寫 Executor Agent 的工具封裝一個(gè)關(guān)鍵動(dòng)作是封裝給大模型調(diào)用的工具函數(shù)。這里最容易踩的坑是模型“亂發(fā)明工具”。第一次跑我讓大模型輸出工具名模型自己編了個(gè)restart_nginx_if_cpu_high()的函數(shù)名執(zhí)行器當(dāng)然找不到。解決辦法是工具調(diào)用不用自然語言輸出而是用 function calling。大模型結(jié)構(gòu)化返回調(diào)用的工具名和參數(shù)。執(zhí)行器里注冊(cè)所有合法工具模型只能從白名單里選。以查 CPU 為例def get_cpu_usage(host: str) - float: # 調(diào)用 Prometheus API 獲取瞬時(shí) CPU 使用率 resp requests.get( fhttp://prometheus:9090/api/v1/query, params{query: favg(rate(node_cpu_seconds_total{{mode!idle,instance{host}}}[5m])) * 100} ) return float(resp.json()[data][result][0][value][1])封裝完這一個(gè)函數(shù)后需要在 OpenAI 兼容格式的 tools 列表里描述它{ type: function, function: { name: get_cpu_usage, description: 獲取指定主機(jī)的 CPU 使用率百分比, parameters: { type: object, properties: { host: {type: string} }, required: [host] } } }tools 描述就像是給大模型的“說明書”。說明書寫得好不好直接影響后面的診斷準(zhǔn)確率。3.3 配置定時(shí)巡檢與擬人化反饋機(jī)制Monitor Agent 不需要大模型純規(guī)則就行。它的巡檢頻率我設(shè)為 30 秒一次查詢最近 5 分鐘的平均負(fù)載。觸發(fā)條件設(shè)置了兩級(jí)超過 70% 寫一條 warning 日志超過 85% 進(jìn)入診斷流程。巡檢本身是死邏輯但反饋要擬人化。我特意給每個(gè) Agent 設(shè)置了不同的“人設(shè)”描述和措辭模板。比如 Notify Agent 發(fā)消息時(shí)會(huì)寫“CPU 持續(xù)高位已排查 XX 服務(wù)的 GC 日志判斷為堆內(nèi)存不足已進(jìn)行重啟操作”而不是只發(fā)一個(gè)“CPU 高”。這個(gè)細(xì)節(jié)的效果非常好——因?yàn)樽罱K看消息的還是人措辭越接近人話響應(yīng)效率越高。而且如果通知周末凌晨發(fā)過來一眼能看清發(fā)生了什么值班的人也不需要再重新拉一堆日志核實(shí)可以直接決定要不要介入。3.4 配置權(quán)限控制和人工確認(rèn)環(huán)節(jié)自動(dòng)化程度越高越要想清楚控制邊界。對(duì)外面常見的做法是“全自動(dòng)或者全手動(dòng)”其實(shí)中間應(yīng)該有一層灰度策略。我按操作風(fēng)險(xiǎn)分級(jí)操作類型風(fēng)險(xiǎn)等級(jí)執(zhí)行方式查詢指標(biāo)、拉日志低自動(dòng)執(zhí)行重啟服務(wù)、清理緩存中自動(dòng)執(zhí)行寫審計(jì)日志回滾版本、變更配置高自動(dòng)準(zhǔn)備命令人工確認(rèn)后執(zhí)行這個(gè)表格是按實(shí)際經(jīng)驗(yàn)總結(jié)的。初期誰都不想讓機(jī)器直接改生產(chǎn)配置但全手動(dòng)又失去了 Agent 的意義。折中下來把“查詢和常規(guī)重啟”交給 Agent 自動(dòng)做把“回滾、擴(kuò)容等有長期影響的動(dòng)作”設(shè)為待確認(rèn)狀態(tài)。通知 Agent 會(huì)把預(yù)執(zhí)行的命令和變更原因發(fā)出來人工點(diǎn)確認(rèn)之后Executor 才真正執(zhí)行。有一點(diǎn)很值得說人工確認(rèn)不能只在流程末尾加那樣 Agent 可能會(huì)在決策過程中做出錯(cuò)誤行為。正確做法是把人工確認(rèn)作為獨(dú)立的狀態(tài)節(jié)點(diǎn)嵌入流程中間。例如高風(fēng)險(xiǎn)的變更在 Executor 生成命令后必須等待確認(rèn)不允許先執(zhí)行后補(bǔ)審批。權(quán)限上還要區(qū)分不同 Agent 能訪問的主機(jī)范圍Monitor 和 Diagnose 可以看所有機(jī)器Executor 默認(rèn)只能操作測(cè)試環(huán)境的機(jī)器生產(chǎn)環(huán)境機(jī)器要額外授權(quán)。整套權(quán)限體系跑通了之后我才敢讓它處理一部分低風(fēng)險(xiǎn)告警。4. 實(shí)戰(zhàn)場(chǎng)景實(shí)測(cè)從“告警產(chǎn)生”到“自動(dòng)恢復(fù)”的完整鏈路整個(gè)系統(tǒng)搭建完成后我用三個(gè)典型故障場(chǎng)景做了壓測(cè)模擬了真實(shí)環(huán)境中容易遇到的告警類型。這幾個(gè)場(chǎng)景能比較全面地暴露問題。4.1 場(chǎng)景一CPU 持續(xù)飆高Executor 自動(dòng)重啟服務(wù)我模擬了某訂單業(yè)務(wù)服務(wù) CPU 打滿的情況。用stress-ng在容器里持續(xù)占 CPU讓其超過 85% 閾值并保持。Monitor 首次檢測(cè)到該指標(biāo)生成告警事件寫入隊(duì)列。Diagnose 收到事件后先去拉該服務(wù)的 CPU 監(jiān)控曲線確認(rèn)不是瞬時(shí)尖峰是持續(xù)攀升。然后拉日志翻到大量線程阻塞信息結(jié)合最近變更記錄判斷根因疑似“連接池配置過小導(dǎo)致請(qǐng)求堆積”最終輸入根因結(jié)論和建議動(dòng)作restart_service和increase_pool_size。由于restart_service屬于中風(fēng)險(xiǎn)操作Executor 執(zhí)行腳本完成重啟。重啟過程中Notice Agent 每步更新進(jìn)度避免中間狀態(tài)無人知曉。最終查到 CPU 負(fù)載回落。Notify Agent 發(fā)出完整報(bào)告包含觸發(fā)時(shí)間、根因、處置動(dòng)作、當(dāng)前狀態(tài)、后續(xù)建議字段。這套聯(lián)動(dòng)從告警發(fā)生到恢復(fù)用了大約 4 分 40 秒。其中大部分耗時(shí)在大模型多次推理上。如果繼續(xù)優(yōu)化可以把 Diagnose 的日志分析改成先做關(guān)鍵詞預(yù)篩再讓大模型判斷總耗時(shí)能壓縮到 3 分鐘以內(nèi)。4.2 場(chǎng)景二誤判差點(diǎn)釀錯(cuò)人工確認(rèn)攔住了第二個(gè)場(chǎng)景專門測(cè)人工確認(rèn)機(jī)制。我模擬的是磁盤使用率報(bào)警。Monitor 發(fā)現(xiàn)某臺(tái)主機(jī)的磁盤超過 90%觸發(fā)診斷。Diagnose 分析后發(fā)現(xiàn)目錄/data/logs占用最多判斷為“日志文件膨脹”建議動(dòng)作是“清理 7 天前的日志文件”。這個(gè)動(dòng)作本身沒問題但磁盤上其實(shí)還跑著一個(gè)數(shù)據(jù)分析任務(wù)正準(zhǔn)備讀取/data/logs/archive下的舊文件直接清理會(huì)破壞這個(gè)任務(wù)。因?yàn)榍謇韯?dòng)作被列入高風(fēng)險(xiǎn)操作Executor 生成了命令但沒有執(zhí)行而是通過 Notify 發(fā)給我確認(rèn)。我看到命令涉及刪除文件手動(dòng)檢查了一下目錄內(nèi)容發(fā)現(xiàn)舊文件還有用否掉了這個(gè)操作改成讓 Diagnose 重新給方案最終換成了“按文件大小和最后訪問時(shí)間只清 tmp 目錄”。這個(gè)案例很有價(jià)值。證明“慢一點(diǎn)確認(rèn)一下”不是拖后腿反而可能是真正的保護(hù)。也正因如此我強(qiáng)烈建議人工確認(rèn)的閾值設(shè)置得偏保守寧多不少。4.3 場(chǎng)景三長任務(wù)執(zhí)行中上下文丟失的驚人后果第三個(gè)場(chǎng)景是暴露問題最狠的。我模擬了一個(gè)復(fù)雜故障一個(gè)業(yè)務(wù)依賴了三個(gè)組件狀態(tài)全部異常一個(gè)組件磁盤滿一個(gè)組件 OOM一個(gè)組件網(wǎng)絡(luò)延遲高。Diagnose 在同一輪上下文里要分析三個(gè)組件的日志。但對(duì)話歷史經(jīng)過截?cái)噍^早的組件 A 信息被擠出上下文Diagnose 分析到最后只報(bào)告了組件 B 和 C 的問題組件 A 的問題被漏掉。結(jié)果 Executor 只處理了 B 和 CA 的故障未被處置。最終告警主鏈路沒有恢復(fù)。這個(gè)案例敲響的警鐘遠(yuǎn)超預(yù)期讓我意識(shí)到單 Agent 大模型上下文的局限多組件、多關(guān)聯(lián)任務(wù)的情景個(gè)人的記憶窗口就是瓶頸。后續(xù)優(yōu)化方案是拆分解耦。讓 Diagnose 做兩級(jí)分析先由一個(gè)粗篩 Agent 把所有組件異常匯總成一張清單再拆成獨(dú)立子任務(wù)分別診斷。每個(gè)子任務(wù)都是獨(dú)立上下文互不污染?，F(xiàn)在這個(gè)新架構(gòu)上線后再次模擬同樣的場(chǎng)景三個(gè)組件異常都能被正確識(shí)別和處置沒有出現(xiàn)“高并發(fā)的多問題互相擠掉”的現(xiàn)象。上下文丟失的問題算是解決了。5. 多智能體協(xié)同系統(tǒng)跑起來之后的優(yōu)化經(jīng)驗(yàn)與避坑指南整個(gè)系統(tǒng)從能跑到能用中間經(jīng)歷了大量調(diào)整。下面寫幾個(gè)我認(rèn)為最有價(jià)值的優(yōu)化點(diǎn)和最容易踩的坑。5.1 大模型返回不穩(wěn)定怎么辦大模型不是每次都聽話的。偶爾會(huì)給出越界建議偶爾會(huì)漏掉函數(shù)調(diào)用偶爾會(huì)生成亂碼。我的處理思路是給所有 Agent 加一個(gè)輸出校驗(yàn)層。校驗(yàn)層做兩件事一是格式校驗(yàn)解析大模型輸出的 JSON、工具調(diào)用是否合法二是邏輯校驗(yàn)——比如 Executor 要執(zhí)行重啟但當(dāng)前 CPU 負(fù)載只有 10%明顯不合理就拒絕執(zhí)行并要求重新診斷。這個(gè)校驗(yàn)層也幫我攔下了一次比較危險(xiǎn)的操作某個(gè)模型在分析了一句錯(cuò)誤日志時(shí)建議“重裝操作系統(tǒng)”被校驗(yàn)層直接攔截并標(biāo)記為異常輸出。所以不要把所有判斷權(quán)都交給大模型工具層該有的理智還是要用代碼寫死。5.2 消息隊(duì)列選型和事件冪等設(shè)計(jì)多 Agent 系統(tǒng)里的消息隊(duì)列一開始選型很隨意直接用最簡(jiǎn)單的 Redis 列表。結(jié)果在并發(fā)告警多的時(shí)候多個(gè) Executor 同時(shí)消費(fèi)同一個(gè)任務(wù)重復(fù)執(zhí)行了操作。原因是消息沒有做冪等。后來換成了 Stream 類型每條事件帶event_id消費(fèi)端維護(hù)一個(gè)已處理集合。遇到相同的event_id直接跳過。這個(gè)改動(dòng)雖然小但效果非常明顯大量因?yàn)橄⒅貜?fù)觸發(fā)的誤操作消失了。另外Agent 的執(zhí)行入口必須是冪等的。例如restart_service被調(diào)兩次第二次要判斷服務(wù)狀態(tài)已經(jīng)是 running就跳過。這也是一種保護(hù)。5.3 記憶持久化與上下文管理是保證長任務(wù)穩(wěn)定性的基石前文提到的上下文丟失問題除了拆分解耦還需要在架構(gòu)層面做記憶持久化。我引入了一個(gè)向量庫用于存歷史故障處置案例。當(dāng) Diagnose 遇到某個(gè)事件時(shí)會(huì)先檢索相似歷史案例把檢索結(jié)果拼進(jìn) prompt 里供大模型參考。這個(gè)機(jī)制的效果出乎意料地好——第二次遇到同類故障時(shí)Diagnose 的根因置信度明顯提高建議的動(dòng)作也更貼合之前驗(yàn)證過的方案。這有點(diǎn)像給團(tuán)隊(duì)加了一份“歷史經(jīng)驗(yàn)存檔”每次處置完故障之后整個(gè)鏈路都會(huì)自動(dòng)歸檔摘要?，F(xiàn)在每次工單結(jié)束我都盡可能地保證歸檔動(dòng)作是自動(dòng)完成的并且會(huì)把最終的根因、處置動(dòng)作、驗(yàn)證結(jié)果都寫成結(jié)構(gòu)化摘要。長期跑下來這套系統(tǒng)會(huì)越來越懂這個(gè)環(huán)境越用越精準(zhǔn)。6. 這套模式在落地時(shí)實(shí)際運(yùn)維團(tuán)隊(duì)?wèi)?yīng)該如何適配很多朋友看完上面可能會(huì)問我這邊沒有大模型開發(fā)和編排能力怎么落地這套東西我覺得核心不是非得自研而是把現(xiàn)有的工具鏈和團(tuán)隊(duì)分工重新理順。6.1 大模型基座用成熟平臺(tái)比什么都重要我嘗試過本地部署開源模型也試過各種微調(diào)。最后穩(wěn)定下來的方案反而最簡(jiǎn)單——用成熟的大模型 API 服務(wù)作為底座。主要原因有三個(gè)穩(wěn)定性、工具調(diào)用的成熟度、持續(xù)迭代能力。部署一個(gè)私有模型要處理顯存、推理速度、上下文長度這些問題很影響體驗(yàn)。而成熟服務(wù)在 function calling 上做得比較完善對(duì) Agent 場(chǎng)景支持好。甚至到現(xiàn)在我的 Agent 系統(tǒng)接入的大模型 API 已經(jīng)在不同版本間切換了好幾次業(yè)務(wù)代碼幾乎沒有改動(dòng)。建議如果要試不必糾結(jié)必須完全私有化部署先用成熟 API 把流程跑通再評(píng)估后續(xù)需要調(diào)整的部分。6.2 運(yùn)維人員的角色轉(zhuǎn)型從“操作員”到“策略制定者”當(dāng) Agent 真的開始接管低風(fēng)險(xiǎn)操作后運(yùn)維人員的工作內(nèi)容會(huì)發(fā)生變化。團(tuán)隊(duì)里最明顯的體會(huì)是一線工單少了許多例如重啟、日志清理這些重復(fù)操作基本不需要人參與了。但提出問題、制定安全策略、審核 Agent 操作合理性的工作量卻變多了。我現(xiàn)在主要做的一件事就是不斷給工具白名單補(bǔ)充和修正操作邊界以及對(duì) Agent 的決策邏輯給出校驗(yàn)規(guī)則。比如某些命令只在特定目錄可用某些環(huán)境只允許在維護(hù)窗口期執(zhí)行變更全部要靠人提前定義清楚。如果團(tuán)隊(duì)里沒有這樣一個(gè)“策略制定者”Agent 系統(tǒng)很容易暴走。這塊需要盡早重視哪怕初期一個(gè)人專職盯控也比全自動(dòng)裸奔強(qiáng)。6.3 灰度發(fā)布和評(píng)估機(jī)制這套系統(tǒng)從 Demo 走到生產(chǎn)用了一個(gè)還算穩(wěn)妥的灰度策略先讓 Monitor 和 Diagnose 全量上線但 Executor 只接入一臺(tái)測(cè)試機(jī)跑了兩周確認(rèn)沒有邏輯錯(cuò)亂再逐步擴(kuò)大到低風(fēng)險(xiǎn)操作每一步都留有人工復(fù)核通道。我個(gè)人的判斷是評(píng)估機(jī)制的關(guān)鍵不在于“自動(dòng)化率有多高”而在于“人工介入次數(shù)是否逐步下降”。如果今天自動(dòng)執(zhí)行了 100 次但其中 40 次都需要人工干預(yù)糾偏那說明 Agent 的學(xué)習(xí)和判斷能力還沒到位。反之如果人工介入頻率逐月降低說明系統(tǒng)進(jìn)入了良性循環(huán)新增的自動(dòng)恢復(fù)能力是值得信任的。7. 一些最后想說的話折騰這套系統(tǒng)大半年我最大的感受是“AI 運(yùn)維 Agent”并不是一個(gè)成品而是一個(gè)需要持續(xù)調(diào)教的協(xié)作過程。多智能體協(xié)同也不是把多個(gè) Agent 丟在一起就能成事關(guān)鍵還是清晰的角色分工、穩(wěn)定的信息流轉(zhuǎn)以及嚴(yán)格的邊界控制。最讓我欣慰的時(shí)刻是它在一次真實(shí)故障里成功識(shí)別出根因并自動(dòng)處置完畢值班同事第二天早上看了一眼報(bào)告發(fā)現(xiàn)處理記錄比人工寫的還要清晰。那種“機(jī)器真的在幫忙分擔(dān)壓力”的成就感很難用語言表達(dá)。它不能替代所有判斷但確實(shí)把不少重復(fù)的、低價(jià)值的勞動(dòng)接了過去。讓做運(yùn)維的人可以去做更復(fù)雜、更值得思考的事這大概就是這套系統(tǒng)最大的價(jià)值。