作者 | 郭勇良，快手資深服務端架構師

審核 | Kitty

策劃 | QCon 全球軟件開發大會

在 AI coding 工具日益成熟的今天，代碼生成能力已被視為接近攻克的領域，但軟件工程的全局難題遠未解決。本文整理自快手資深服務端架構師郭勇良在QCon 全球軟件開發大會 2026 北京站的分享《復雜業務場景下 RCA Agent 的探索實踐》。

郭勇良在分享中詳細介紹了一套基于大模型的業務排障體系，拆解業務中面臨的四個核心挑戰：如何讓 AI 理解業務、如何對抗告警噪聲、如何衡量不確定性、如何抑制模型幻覺，以及圍繞這些挑戰所構建的 Agent 架構設計、評測體系與持續演進思路。

以下是演講實錄（經 InfoQ 進行不改變原意的編輯整理）。

背景和痛點：為什么需要 RCA Agent

Claude Code 負責人 Boris Cherny 曾在播客中提出一個觀點：編碼工作大體上已經被 AI 攻克了。這個判斷引發了一個更加深層的問題——軟件工程真的被解決了嗎？

從兩份調研報告來看，答案是否定的：2025 年的 DORA 報告統計了 AI Coding 落地后的效能變化，個人效能的提升相當顯著，但組織效能的提升卻相當有限。微軟內部的一項調研也給出了類似的方向，他們收集了約六千份工作日時間分配的樣本，除去會議、溝通、學習與行政事務，開發和排障仍然是研發人員時間占比最大的兩塊。一個自然而然的推論就是：如果 AI Coding 帶來的紅利已經趨于穩定，那么排障就是下一個需要被攻克的生產力瓶頸。

另一組現象也印證了這個判斷。OpenClaw 在今年三月份發布了一個重大版本重構，版本上線后大量用戶反饋插件出現癱瘓或功能失效。值得留意的是，OpenClaw 的代碼絕大部分是通過 AI Coding 生成的。這意味著什么？隨著 AI 時代人對代碼掌控度的下降，AI 排障有可能從一個可選項演變成一個必選項。當人不再能完整理解自己的系統時，就必須有一個同樣由 AI 驅動的診斷體系作為對等的保障。

整個技術系統大致可以切分為三層：基礎設施層涉及容器、節點、網絡故障，中間件層涵蓋 Cache、DB、MQ 的異常，而我們主攻的業務層故障則直接面向核心指標下跌、風暴告警和跨系統傳播。業務層有三個顯著特點：第一，它是用戶體驗和營收的直接體現；第二，業務代碼迭代極快，高度易變；第三，業務問題無法預測排查步驟。舉個例子，同樣是視頻時長下跌，根因可能來自 Redis 慢查詢，可能來自服務自身的 GC，也可能來自下游某個服務引入的 bug，排查路徑的不確定性正是業務層排障最大的難點。

業務場景落地挑戰

在實際落地過程中，我們面臨著四個層層遞進的核心挑戰。第一個是如何讓 AI 理解業務。一個典型的四象限圖中，能引起業務指標波動的因素同時包含內源的與外源的、主動的與被動的，信號與噪聲高度混合。中小學開學導致的流量自然變化與代碼缺陷引發的異常下跌混在一起，共同構成了一個巨大的狀態空間。第二個挑戰是對抗噪聲——在一個告警噪聲占比可能超過 75% 的系統中，如何讓 Agent 不會在無效信號上耗盡算力。第三個是如何衡量 AI 排障的不確定性本身，即建立可重復、可量化的評測體系。第四個則是直接對抗大模型在數值計算與趨勢識別中的幻覺問題。

挑戰一：如何讓 AI 理解業務

舉個例子，主站某次突然遭遇用戶 Feed 流請求量上漲，突破了告警閾值，入口服務 A 作為直接承載 Feed 流的核心服務，它的所有下游可用率都顯示正常。但服務 A 的下游依賴極其龐大，橫跨幾百個服務與多個部門。這種情況下，擺在值班工程師面前有兩個層次的問題：首先，這個指標異常本身到底是不是一個問題？它是內部故障導致的，還是純粹由外部熱點自然引發？其次，即便決定把它當問題處理，逐一拉取所有下游業務的同事來排查，顯然不現實。

事實上的根因出在推薦質量的下降上——信息流質量下降導致用戶反復刷視頻，引起了請求量的異常上漲。故障傳播鏈非常復雜：入口服務 A 調用了下游 B，B 之所以沒有表現出異常，是因為它內部存在兜底降級邏輯，但 B 所依賴的下游部門服務 E 發生了 Core Dump。而 E 發生 Core Dump 的原因，是其請求的另一個服務 F 出現了接口字段缺失，最終歸因于 F 服務的配置變更引入了先前未走過的邏輯路徑。

這個案例中出現了幾個反常識的地方。一般來說推薦質量下降會導致用戶請求量降低，但這個問題恰恰相反地引發了請求增加。整條異常傳播鏈在 A 調 B、E 調 F 兩個節點上被中斷，指標層面看起來一切正常，依賴 Metrics 根本無從關聯。跨部門協同更是人為增加了難度——主站的同學不了解下游部門內部的變更事件。這個問題最終耗費了大量人力，排障群一度達到一百多號人。

用傳統的監控三板斧——Trace、Metrics、Log，在這個案例中至少存在兩個明顯的斷點。第一個斷點出現在 A 調 B，請求正常，Metrics 無法關聯，只能依賴業務經驗，主站同學不得不去找部門 B 的同學人工確認。第二個斷點更隱蔽：E 調 F 的故障由接口字段缺失引發，請求也是正常的，且由于這個邏輯此前沒有走到過，很可能根本沒有打 Log。這個斷點的發現同樣依賴內部同學的人工溝通。

由此得出的結論非常清晰：如果想讓 Agent 去做這件事，必須在技術指標之外理解業務，否則永遠無法跨越這兩個斷點。

怎么做到？除了常規的 Trace、Metrics、Log 與變更事件外，我們引入了業務代碼 GIT。因為代碼是唯一真實的文檔，所有系統都構建在代碼之上。最初的實踐非常直接，引入 Coding Agent 對代碼進行實時分析。一開始使用的是 Claude Agent SDK，分析一個代碼庫的時間大約三十分鐘，這在排障場景中顯然不可接受。切換到 PI Coding Agent 后，單庫任務分析時長降低到五分鐘左右。但即便降到五分鐘，實際場景中依然有效率瓶頸。一次完整的業務排障任務通常涉及一條鏈路上多個服務，而且 Java 系統中還有大量 SDK 的底層依賴需要梳理，往往需要同時分析三到五個庫，總共需要十五到二十五分鐘，這個時間對于故障響應來說依然太長了。

問題的根源在于，代碼雖然是唯一真實的文檔，但它是抽象層次極低的東西。低抽象必然帶來低效率。人在排障時，即使是服務的維護者，也絕不可能記住每一行代碼，人腦中對業務代碼進行了一定程度的抽象。如果讓 AI 去理解，就必須降低它的認知成本。

我們的做法是建立一層代碼抽象，稱之為“業務資產”。比如對錯誤碼標注其業務語義，對 Metrics 含義進行業務化描述，建立指標之間的拓撲關系——以 Feed 流場景為例，下游 推薦服務 可用率降低可能導致上游服務兜底率變化，最終引起 Feed 下發量的變化。還有一些開關配置會直接影響業務邏輯，我們也把它們的影響地圖建立起來。這些資產的構建有兩種模式：一部分通過離線沉淀，用 Coding Agent 離線生成核心代碼的關系描述，放入知識庫并以 Markdown 文檔形式存儲；另一部分則在排障過程中按需生成，Agent 實時分析完某個任務后，將其沉淀為 Skill，納入知識庫。通過這兩種方式，業務資產就轉起來了。

總結起來，解決“讓 AI 理解業務”這一挑戰的本質，就是消除人和 AI 之間的上下文代差。AI 獲取傳統監控數據相對容易，但研發腦中同時運轉著大量其他信息——代碼邏輯、指標關系、業務常識，比如主播開播后可能引起送禮請求的增加，以及外部事件。這些與代碼邏輯一樣，如果想讓 AI 去排查，就必須將這些信息全部提供給它。

挑戰二：如何對抗噪聲

在實際執行中，告警噪聲是一個讓人極其疲憊的問題。從統計來看，系統中大部分告警是沒有用的，告警噪聲占比可能超過百分之七十五，真正需要關注的不到四分之一。

告警噪聲帶來的危害是實實在在的。我們內部曾復盤過一個 P2 級別以上的故障，發現故障發生后大約十分鐘，某個指標已經發生波動并發出告警，但當時的值班人員直接點擊了靜默。此后該指標在十五分鐘之內快速偏離到嚴重程度，卻沒有人感知，原因正是這個告警在七天之內報警超過十五次，值班人員已經產生了告警疲勞，基本看都不看就直接靜默。

但如果讓 AI 全量處理所有告警，又會產生新的問題。內部試驗下來，Agent 在 ReAct 循環中完成一次完整推理的 Token 消耗大約在六、七十萬到一百多萬 Token 之間。快手主站每個月的告警事件總量大概在兩三萬左右，如果讓 AI 處理所有告警，每月 Token 消耗接近一百億，年化成本達到幾百萬人民幣。除了成本問題，ReAct 循環的交互次數不可控，延遲也無法保證。

我們的解決方案是分成兩層。第一層引入一個非常輕量的告警置信度評估 Agent 或 Workflow。它的任務是提取告警的“畫像”——包括告警的周期性規律、每次觸發后閾值偏離程度、恢復時間、服務分布以及曲線的聚集情況，將這些作為統計數據進行評估。舉個例子來說明偏離分析的價值：某個可用率告警每天可能都突破四個九到 98%，有一天突然降到 60%，顯然需要關注；如果仍然只是到 98%，可能就不需要關注。周期性同理：如果告警每天凌晨都報警，其置信度就相對低；假如某天突然下午開始報警，那這很可能是一個明顯的異常信號。

經過置信度評估篩掉一部分噪聲后，下一步就是對保留下來的問題進行排障推理。然而即便經過了初步過濾，推理階段仍然存在大量噪聲。系統中充斥大量技術指標的波動，比如服務恰好發生了 GC，但又不足以引起核心業務指標的波動，這些都會造成 Agent 的誤判。另一個典型的噪聲來源是變更事件：在發布高峰期，一條核心服務的關聯鏈路上可能在一個小時內關聯出五百多個變更，這些變更絕大多數都不會導致故障，但當故障真的發生時，Agent 必然會拉到這么多變更，怎么判斷它們與告警到底有沒有關系？這些都是潛在的誤判信號。

我們的應對方法是引入類似循證醫學的證據金字塔，建立證據分級體系。這個思路來源于醫院看病的場景——醫生每天接手大量病例，其中很大一部分病人可能僅僅因為焦慮來就診，并沒有什么實質性疾病，所以醫生首先需要過濾噪聲。而對于真正有病的病人，則需要進一步排查病因。醫學在這個問題上已經是一套非常嚴謹的科學，有成熟的最佳實踐，我們完全可以拿過來借鑒。

在這個金字塔中，最下層是原始信號，往上一層是背景上下文——比如外部趨勢熱點、靜態服務依賴關系、工程師的經驗。再往上是單點觀測數據，比如單個 Metrics 異常或單服務指標異常。當這些單點異常通過 Trace 或拓撲建立關聯時，就組成了多元融合證據，例如鏈路上關聯的變更、匹配歷史故障模式等，這構成了更堅實的一層。最上層是直接因果推斷：指標之間有明確的有向圖拓撲關系，或在源碼層面已經實錘，或故障服務恰好對應時間窗口內的直接變更，這些都被認為是直接因果推斷。

挑戰三：如何衡量不確定性

目前在生產級 AI 系統中存在一個共識：跑一個 Good Case 非常簡單，給出幾個 Demo 很容易，但真正投入生產環境時，消除 Bad Case 極為困難，存在大量的 Corner Case 與 Silent Error。一位 AI 初創公司 CTO 曾在發文中提到這樣一個觀點：Demo 演示時只需找到正確路徑即可，但在生產環境下，百分之九十的情況都是壞情況。為什么會出現這種情況？因為此前在程序中的確定性因素，在 AI 中變成了不確定性因素——同一個問題多次輸入推理，可能形成不同的推理路徑，結論也可能不一樣。而且在一個極其龐大的業務系統中，影響因素非常多，任何一個變量變動都可能導致結果出現巨大偏差，類似于蝴蝶效應。

我們有一個非常真實的案例。最初做 Agent 時，我們想要召回“單點抖動”問題，因為大量 RPC 可用性告警可能是由于下游某個 Pod 的單點抖動造成的整體指標波動。做法比較簡單，引入傳統異動分析算法并增加下鉆維度，將這個工具提供給 Agent 使用。然而加上這個工具之后，單點問題雖然被成功召回了，整體 Case 的準確率反而劣化了。原因在于，單點問題是一個極其高頻的問題，在一個幾千 Pod 的集群中發生概率很高，當核心業務指標波動時，往往伴隨有單點問題。Agent 在排查訪問量下降時找到單點問題，在排查搜索量下降時也找到單點問題，于是錯誤地建立了因果關系。這個案例的根因很清楚：它跟傳統軟件的確定性修復不同，優化了一個 Case，可能又引入了其他 Bad Case。

解決方法在這個問題上也有比較強的共識。Andrej Karpathy 在三月份的一篇推文中提到了一個觀點：現在的 Benchmark 已經是新的 Meta 了。去年那篇頗具影響力的文章《Agent Design is Still Hard》也表達了類似的觀點：評估和測試是最難的問題，到了一定程度之后必須引入 Benchmark。

我們的 Benchmark 體系分為兩個階段。第一個階段是 Case 收集：故障發生后，從發生到智能歸因，經過專家標注后進入評測階段，Case 被加入評測集，判斷其是否值得納入，相關數據進行轉儲，然后跑一個評測 Agent，進行效果對比。在評測集設計階段，目標是覆蓋真實的業務問題空間，所有 Case 全部來源于線上真實的異常場景。在評測集數據構造階段，目標是復現真實的排障環境，我們采用了快照式的監控數據轉儲方案。快手每天會產生大量監控數據，部分數據有過期機制，我們需要將故障發生期間的監控數據盡量轉儲出來。

之所以沒有采用仿真環境或混沌工程的方案，是因為我們要解決的是業務場景的問題，這類問題非常難以通過混沌工程來模擬。比如搜索量下降，你不可能真的去構造一個搜索量下降的故障——請求量太大，模擬成本太高。所以我們更多是從真實異常中收集案例，保存故障現場。在評估階段，目標則是衡量模型效果，關注核心指標，比如線索命中率，進行量化評分，與預期行為做比對。

挑戰四：對抗幻覺

大模型幻覺是一個繞不開的話題。有一個在去年 Claude Opus4 模型下發現的典型案例，雖然現在有了 4.7 可能已經不存在了，但它帶來的啟示仍然有效。有一次一位同事發給我一段 Prompt，我直接發給了 Claude，Prompt 非常簡單，就是讓它把時間轉換成時間戳。結果發現它幾乎做不了這件事，每次轉換都不準確。后來我只是稍微修改了一下提示詞，告訴它通過運行 Python 腳本的方式來幫我轉換，結果就變得極其精準了。這個小小的實驗非常清楚地說明了一件事：大模型本質上是一個概率預測器，并不擅長數值計算任務。

在實際業務場景中，我們遇到的第一個問題是識別監控圖片中的簡單趨勢，比如八點到八點二十之間某個指標是上升還是下降。這本來是一個非常簡單的事情，但我們用大模型嘗試的時候卻出現了明顯的幻覺。最初想到的方案是用多模態去識別，直接把監控截圖發給了大模型。這種方式幻覺相當嚴重——圖片中 8:00 到 8:20 之間確實有下降，但時間點不夠精準，模型只能給出非常模糊的時間范圍。更糟糕的是，有時大模型對縱軸的理解也不準確，甚至會突然說一句“我在 8:30 發現了一次下降”，這顯然是嚴重的幻覺。而且這種方案還依賴于圖表樣式的穩定，前端同學隨意調整一下圖表的顏色或布局，準確率可能就立刻受影響。

第二種方案是用時序數據進行識別，把一段時間內所有數據點的“時間-值”對構成一個巨大的 JSON List 直接發給大模型。結果依然逃不出計算出錯的問題。首先是 Token 消耗太高，數據序列實在太長了。其次，它仍然需要執行計算，比如判斷到底下降了多少百分比，大模型對此還是處理不好。

最終我們把這件事轉變成了傳統算法的任務，用孤立森林算法結合一些規則去判斷。采用這種方式后，準確率顯著提高，也不消耗 Token，確定性也得到了根本性的增強。由此得出的一個結論是：當確定性要求超過一定程度時，工程化封裝成 Tool 和 Skill 是更優解。

將某個判別能力封裝為標準化算子之后，它就擁有了標準化的接口，可以被復用，也可以配置可調參數。一旦沉淀為標準化算子，就可以逐步積累成一個算子庫。借鑒類似 AutoResearch 與 CodeAct 的思路，把確定性重復問題沉淀成算法，然后為這些算法準備一系列輸入輸出——本質上就是一個函數。我們準備一些 Case，要求在輸入 A 的情況下輸出 B，在輸入 C 的情況下輸出 D，不斷去跑，目的就是提高算法的得分。這一步就非常容易量化了，很容易形成一個有正向反饋的迭代回路，持續地打磨算法。

核心機制和架構設計

從整體演進路線來看，在 AI 引入之前是純 Rule-Based 的階段。AI 剛出來時，我們嘗試將一些 SOP 用 Prompt 編排起來。Workflow 出現后又嘗試過 Workflow 與 MCP 的組合。到去年下半年，我們開始真正嘗試讓 Agent 完全由大模型自主決定何時停止、何時繼續排查。

有一個值得認真思考的問題：從 Workflow 演進到 Agent，一定是更優的選擇嗎？Workflow 的優點很明確，確定且可控，但它的局限性也同樣明顯——它嚴格依賴編排好的流程，依賴固定的流程編排，非常缺乏靈活性。Agent 解決了靈活性的問題，非常發散，有泛化能力，但同時也帶來了不確定性。同時把 Workflow 換成 Agent 還會產生延遲的增加——ReAct 循環多輪必然導致延遲大幅上升，Token 消耗也是巨量爆炸。Workflow 不存在這些問題，延遲更低，Token 消耗更少，確定性更強。所以我們發現 Agent 對 Workflow 并不是一個純粹的取代關系，Agent 更像是一個更靈活的升級，而非一個“更智能”的代名詞。在某些場景下，用 Workflow 的效果確實更好。

那么為什么要用 Agent？因為在復雜的業務排障場景中，存在相當多的高度不確定性問題，這些問題沒有辦法用靜態 SOP 覆蓋。這就是引入 Agent 的核心價值所在。

整體告警治理的架構也是分層的。最下層是告警噪聲，通過傳統的告警治理、常規策略治理以及智能告警的引入，先把噪聲降下來。上面的兩層就是 AI 去處理的范疇。第一層通過一些 Workflow 進行“快思考”，將相對固定的系統類告警場景處理好，比如 SOP 場景、Redis 排障場景、Java 異常場景。這些東西相當套路化，可以變成快思考的簡單問題來處理。最上層則是核心業務指標的突變，我們引入 Agent 進行“慢思考”，做深度推理。

在快思考這一層，從告警事件發出，經過抑制規則判定，比如被認定為一個單點問題，直接就可以處置，把單點重啟一下，告警抑制掉即可。然后結合特征畫像分析，會抑制掉相當一部分告警。剩下的告警進行簡單的復雜度判定，有些問題通過維度分析、簡單影響范圍分析，就被認為可以在 Workflow 內解決，直接同步歸因。對于那些比較復雜的問題，就走異步的 Agent 分析流程，可能耗時十分鐘以上。Workflow 這一塊的確定性相對較高，也會比較快速地出結論。

在復雜問題的慢思考層面，我們采用 Multi-Agent 架構。告警事件觸發后進入平臺，進入主 Agent 循環，創建一個 Plan 計劃，動態調用底層的若干 Sub-Agent。底層有業務資產和數據基建作為支撐，最后輸出可解釋的報告。這里用到了幾個關鍵技術點：第一是 SubAgent 領域封裝。我們的工具加起來有八十多個，如果把這八十多個工具直接全量拋給主 Agent，其認知負擔極大，Token 消耗壓力也巨大。因此我們會把相近領域的 Tool 組成 SubAgent 封裝起來。第二是在長任務中仍然可能需要代碼分析，我們將這種代碼分析異步化，投遞到信箱中，讓主 Agent 進行消費。第三，由于采用 SubAgent 的排查方式，各 SubAgent 之間的信息是隔離的，個別 SubAgent 容易陷入無效路徑。比如某個 Agent 已經發現了關鍵線索，找到了關鍵的變更事件，那可能就沒有必要繼續做 RPC 下鉆了。我們的解決方法是組成 Agent 通信 Team，讓 SubAgent 之間進行必要的通信，以縮短整個排查路徑。

在 Agent 自進化方面，我們的思考是這樣的：大模型存在兩個極端。如果非常泛化，不給它任何 Case 參考，就是 Zero-shot 的推理模式，可能會過于發散。但如果把 SOP 在 Prompt 里完全定死，第一步做什么、第二步做什么，又會產生過擬合。所以我們采用 Few-shot 的模式，告訴他類似故障大概要怎么處理。但構建 Few-shot 案例的過程中存在人工成本，需要人一個個去構建。為了解決這個問題，我們設計了一套自動構建案例集的系統。事先準備好一些問題和正確答案，然后讓 Agent 啟動迭代模式，不斷去跑。過程中把模型換成小模型，提高溫度，讓它跑出非常多的路徑，直到命中那個正確答案。當評估 Agent 認為它命中了，就把整個評估過程抽取出來，做一份摘要，加入到經驗庫中沉淀下來。

在 Agent 記憶方面，排障需要查詢的信息量非常龐大，告警畫像的統計信息、研發腦中的業務知識，這些可能都需要在推理啟動時初始化到 Context 中，初始化到 System Prompt 里。推理過程中則會有動態的檢索搜索過程，去搜索歷史離線業務資產、過去推理過程所沉淀下來的長期記憶，以及場景化的 Skill，這部分 Skill 可能比較偏 SOP。這些東西我們會盡量讓 Agent 自己去進行合并與整理，而不是消耗大量人力去人工解決。

在產品交互層面，我一直在思考一個問題。從去年 Claude Code 出來，到今年一月份 OpenClaw 發布，我身邊的很多程序員同事并沒有對 OpenClaw 展現出很大的熱情，但它在社會上卻產生了巨大的反響。Claude Code 為什么沒有產生類似的反響？增量究竟是什么？觀察下來，我們發現 OpenClaw 有一些獨特的能力：接入了 IM，默認給全所有超級權限，有心跳機制來感知任務進展。總結起來，現在同類產品統一的特點就是讓 AI 越來越 Proactive，越來越主動。

所以我們產品迭代的思路也是沿著這個方向走。最初形態是研發輸入一個問題，Agent 進行推理，過程中給出一些關鍵發現，實時繪制鏈路拓撲，整個產品以 Chatbot 的形式對外提供服務。但未來的方向還是要發展成更加 AI Native 的自驅模式，讓 Agent 能夠自動發現問題，需要拉群就自動拉一個群，不斷把它發現的關鍵線索拋在群里，最終實現從問題感知到排障處置到協同處理，甚至自己也可以進行經驗沉淀，這種完全的閉環才是理想中的終態。

在核心指標運營上，面向告警和故障處置，我們最終要衡量的是 MTTR 的縮短。但實際過程中真正遇到故障的頻次相對較低，案例數量有限，所以我們引入了一些過程指標。第一個過程指標是“有效線索率”。為什么會有線索這個概念？是因為整個 Agent 推理時間比較長，一個任務可能十分鐘以上才能完成，不可能等到十分鐘才告訴研發結論。過程中每發現一個值得分享的關鍵線索，就應該拋出來。因此關鍵線索的準確率就成為一個重要的衡量維度。同時我們也有歸因的準確率以及歸因時長，這些都需要持續運營。

目前我們在整體準確率上達到了百分之八十以上，但這個數字包括了非常多的告警噪聲。實際推理層面的準確率并沒有這么高。在推理層面目前主要衡量有效線索的準確率，讓 Agent 最終把根因推對是相當困難的，但只要過程中發現了有效線索，就已經能給業務帶來實際價值。

在實踐中我們也踩過很多坑。比如遇到大模型層頻繁失敗的問題，API 接口不匹配的問題，不同模型廠商之間的大模型接口存在非常大的差異。這些問題本質上是軟件工程的問題，需要去處理故障、防范故障、增強系統的容錯能力。在過去做分布式系統開發時，我們就一直在對抗環境的不確定性。AI 的引入是把這種不確定性進一步增強，變成了一個常態。理解這一點之后，我們的心態反而變得坦然了：只能去擁抱它。

總結和展望

最后我想分享一個認知：“拿著舊地圖，找不到新大陸”。現有的監控系統全都是圍繞著人去構建的，全是為了給人使用而設計的。人有一個顯著特點，就是認知是有帶寬限制的。我們給老板做匯報時，需要把大量復雜信息屏蔽掉，濃縮成抽象、簡單的結構。系統在給人匯報時也是一樣的邏輯，不可能把底層所有數據都全量展現出來，只能做數據抽象。但 Agent 不存在這個問題，它幾乎可以處理無限多的復雜數據。那么未來的系統會怎樣發展？可觀測的整個體系是否會被整體重構？這個問題我沒有答案，也在持續思考。

另外還有一點，現在的整個組織都是按照人來組織架構的，人是高度分工的。但 Agent 不需要分工，而且人與人之間存在信息隔離，組織上的某些問題會跟技術問題糾纏在一起，比如誰掌握更多信息誰就掌握了主動權。但對于 Agent 來說也并非如此。從第一性原理出發，有些東西已經變了。

再說回現在的發展。Agent 領域發展極快，很多結論過兩個月就可能已經過期。那到底能積累下什么東西呢？我們認為有一些東西是可以復用的——問題域業務資產、Eval 評價體系、結構化案例集、人機協作模式，這些東西是穩定層，可以持續積累。同時也有易變層，隨著模型迭代，下半年出了一個更強大的模型，很多當前適用的東西可能就沒用了，Prompt 描述、工具選型、協議規范都在這個范疇。我們的思路是把更多精力投入到穩定層上，盡量減少在易變層上的投入，因此會更多地構建數據上下文。

最后，我認為整個方向還是要向著 AI Native 自主化、AI 自進化的方向演進。目前 Agent 能做到的是提供輔助決策，由人主導排查問題。后面可能會發展到一個新階段：Agent 自己出決策建議，人進行最終審批，起到一個把關兜底的作用。最終，如果這個階段運行得足夠久，我們發現在百分之九十九的場景下 Agent 都是準確的，人的審批已經沒有提出任何有效修訂的空間，那就可以完全走向 Agent 自我進化、自主閉環了。

作者介紹

郭勇良，快手資深服務端架構師，目前在快手負責主站歸因排障 Agent 建設，曾在華為云、美團 Infra 任職工作。

會議推薦

AICon 上海站 Keynote 嘉賓已集齊！來自復旦、清華、螞蟻、阿里云等高校知名教授與頂尖專家集結！從多模態、大模型落地與 Token 服務維度，拆解大模型從 “會回答” 到 “能執行” 的技術拐點。9 折倒計時最后一周，現在報名立減 580。