北京
你的同事在周二下午三點發出那聲哀嚎之前，整個工單系統已經安靜了整整四天。一個生產環境的代理在某次長達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.
