你的同事在周二下午三點發出那聲哀嚎之前,整個工單系統已經安靜了整整四天。一個生產環境的代理在某次長達11分鐘的會話中,先是調了三個內部工具、穿過兩個沙箱邊界、等了一次人工審批、在一個子代理那里卡了47秒——最后返回了一個結果,沒人知道對不對。他把原始事件日志從頭翻到尾,七千三百行,像一個21世紀初期查Apache日志的運維。
我把這個事告訴了一個做SRE的朋友。他把自己的屏幕分享給我看:左邊是Honeycomb在2026年創新周上推出的代理可觀測性初版界面,右邊是那個同事本周打開的第八個grep窗口。同一時間線上的兩種職業畫像。
![]()
代理監控這件事,我已經把它從“報表類”那欄挪到了“SRE生產基礎設施”那欄。心情是有點不爽,但這種不爽很真實。你以前拿到一條追蹤鏈路,是用來看懂一個請求發生了什么。現在這條鏈路要扛著一次代理運轉的全過程跑:工具調用、子代理、沙箱、服務邊界、審批節點、重試策略、副作用鏈。你得把每一步的決策和副作用同時追下去,追到跨越工具邊界、MCP邊界、沙箱邊界和其他所有運行時邊界的地步。
這件事的尷尬之處在于,鏈路還是那條鏈路,但對它的期待已經變了。它不再是給開發者在調試時隨手翻翻的調試器,而是一條在事故發生一周后,當沒有人記得那次會話的任何細節時,由SRE或安全調查人員作為證據去回溯的記錄。它必須支持回滾操作。它必須能講清楚一個從未通讀過全量原始事件日志的SRE,也能一眼看明白這個代理到底干了什么、在哪一步跑偏了。
針對這個趨勢,要把幾個人的話按順序看完。莎拉·卡特第一個點破核心問題:管理和監控代理需要對基礎設施做徹底的重想,因為現有的系統在設計之初就不是為代理這種規模準備的。哈里森·蔡斯隨后補了一句,相同的邏輯也完全適用于監控側。然后查瑞蒂·梅杰斯把可觀測性這一層的矛盾磨到了最鋒利的狀態——她說,用傳統的交易和追蹤構建塊去追蹤長時間運行的異步AI會話,存在一個巨大的問題。
這句話值得暫停幾幀。什么叫“長時間運行的異步AI會話”?就是你發出一個指令之后,代理自己去做了十幾分鐘甚至幾個小時的事,期間它做決定、調用外部系統、產生副作用、修改狀態——這些都不是一個同步請求-響應的模型能裝得下的。一段Web請求的形狀很簡單:請求進到處理器,調個數據庫,可能走個隊列,然后把響應返回給發起方。圍繞這個形狀,人們構建了他們的可觀測性工具全家桶:跨度、日志、指標、單個范例、服務地圖、儀表盤。現在你讓一個異步跑了好一陣子的代理會話塞進這套架構,它就漏了。
那代理可觀測性到底應該長什么樣?朗鏈的可觀測性文檔給了一個很直白的答案:代理需要可見性覆蓋到工具、提示、決策、工具調用、模型交互和決策點。朗史密斯的儀表盤文檔又把這個界面翻譯成了一套運營指標:追蹤計數、延遲、錯誤率、令牌用量、成本、工具運行次數、工具錯誤、工具延遲、運行類型和反饋評分。把這行列表慢慢讀一遍。你沒有在看一份監控需求清單,你是在讀一個代理控制面的雛形。
我自己喜歡追蹤工具,我喜歡儀表盤。但有一點我非常不買賬:假裝原始日志就是記錄本身。一次代理運轉期間打出來的日志,把它當日志來讀,完全沒問題。可一旦進入生產環境的監控語境,這些日志變成了SRE事后復查的證據,鏈路就不止要跟著日志里的命令跑,還得跟著決策和副作用跑,跨過上述所有邊界。所以這個結論很殘忍:長時間運行的代理會話,就是會打破請求形態的思考框架。一個交易的追蹤鏈路太小了,裝不下它。
把這個邏輯推到底,針對長時間運行的代理會話的可觀測性體系,正在演變成一套關于AI代理行為的底座系統:存儲、身份、留存、關聯和控制面。你可以繼續叫它“監控”,如果這個標簽讓組織內部更好達成共識的話。但配人的時候不要照著報表系統來配。因為鏈路正在搬運一個比以前大得多的對象,而你還得保證一個不認識這個代理的SRE,能在事故記錄里跑通整場復盤。
特別聲明:以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布,本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.