從看見問題到解決問題，Agent 正重新定義可觀測

作者 | 凌敏

Vibe Coding 正在批量生產“日拋型軟件”。它們可以在一天內被搭出來，卻未必經得起一周后的真實業務流量、權限調用和故障追責。Gartner 預警，到 2028 年，公民開發者采用 Prompt-to-App 的方式可能使軟件缺陷增加 2500%，并觸發軟件質量與可靠性危機。

“這些軟件的產生，在目前傳統的運維架構下是災難”。觀測云創始人&CEO 蔣爍淼在做客 InfoQ《C 位面對面》欄目時表示，這些軟件一旦接入數據庫、部署到服務器、開始承接真實業務，就成為一套需要持續運行、維護和治理的 Online System，同樣需要日志、指標、鏈路、告警、權限控制和故障響應。但問題是，這些運維工具往往分散在不同系統中，運維團隊需要為不斷涌現的小應用逐個接入、配置和兜底。

更嚴峻的是，在 Agent 批量進入業務場景的當下，企業系統里的參與者不再只有人。過去那套圍繞機器和服務展開的運維邏輯，接不住這些新的變量。今天再討論可觀測，面對的是一套新的運行邏輯。

為什么 Agent 爆發后，可觀測更重要了？當可觀測 Agent 開始自動診斷、修復問題，人類工程師的能力邊界在哪里？在本期《C 位面對面》中，InfoQ 極客傳媒總編輯&總經理王一鵬對話觀測云創始人&CEO 蔣爍淼，一起聊聊 Agent 時代，可觀測的變與不變。

1 Agent 爆發后，可觀測更重要了

如果在 2018 年談論可觀測，大多數人的理解，大概還停留在指標、日志和鏈路追蹤。但放到今天，再用這個“三件套”概括可觀測性，顯然太過狹隘了。

一個真實運行的系統，不只有幾組指標和幾條調用鏈。用戶在頁面上的行為事件、服務之間的依賴關系、應用運行時的內存狀態、主機與服務的拓撲變化，都會影響最終的業務結果。比如，程序運行變慢的背后，可能存在內存泄露，這類問題往往需要通過 Profiling 生成的火焰圖來定位，它是一種二進制格式，并不屬于傳統“指標、日志、鏈路追蹤”中的任何一類。

在蔣爍淼看來，真正意義上的可觀測，是“全面無死角的體檢”，盡可能完整地記錄系統運行中的信號，讓團隊能夠還原系統發生了什么。

在 AI 技術出現之前，這件事的難點是數據太多、太專業。以 Profiling 生成的火焰圖為例，它包含 I/O wait、內存對象大小、CPU 熱點等信息，一般只有經驗豐富的“老法師”才看得懂。但在 AI 技術出現以后，Agent 開始有機會承擔讀數據的工作：它可以跨越指標、日志、調用鏈、拓撲和運行時數據，先拼出系統的整體狀態，再幫助工程師定位問題。

更深層的變化是，Agent 本身也在成為新的觀測對象。

過去，運維團隊主要觀察的是服務器、容器、數據庫和服務調用。隨著越來越多的 Agent 開始深入業務，運維團隊還需要看到 Agent 做了什么、調用了哪些工具、訪問了哪些數據、是否越過了權限邊界，以及每一步動作對業務系統造成了什么影響。

這也催生出一個新的方向：ABA，即 Agent Behavior Analytics，面向 Agent 行為本身的分析。“我們已經具備了這個功能。包括 OpenClaw、Hermes、Claude Code、Codex，都可以將數據收集到觀測云平臺上進行追蹤。”蔣爍淼認為，在 AI 時代，無論是軟件自身還是其運行時系統，都可以借助 Agent 更精準地捕獲各類信號。幫助人類更高效地理解系統狀態，也能反哺 Agent 自身，持續優化軟件系統的運行表現。

不過，Agent 可觀測并不等于把員工電腦上的每一個 Agent 都監控起來。像 Claude Code、Codex 這類桌面端 Agent，本質上更接近客戶端軟件。真正需要被看見的，是它們進入企業系統之后留下的行為軌跡：是否訪問了 OA、調用了什么業務接口、讀取了哪些數據、最終在系統中產生了什么操作。

蔣爍淼認為，最理想的 Agent 觀測入口，是統一的 AI 網關。當模型調用、Token 收發和工具調用都經過這里，企業才能建立起一條可追溯的行為鏈路。

此外，當企業內非技術部門的人都能用 Vibe Coding 隨手搭出一套上線生產環境的系統時，這些“影子 IT”天然就處于可觀測的盲區。它們已經在生產環境里跑著，卻沒有任何人知道它們的狀態。

這也是為什么，行業已經默契地將可觀測擺在重要位置。Gartner 預測，到 2028 年，40% 已經部署 AI 的組織將采用專門的 AI 可觀測工具，用于監測模型性能、偏差和輸出。背后的邏輯很簡單，當 AI 開始參與業務決策和執行，企業首先要解決的，就是要知道它正在做什么、為什么這么做，以及出了問題后如何追溯。

2 可觀測平臺，正在變成系統的“統一上下文”

當系統里同時跑著人、軟件和 Agent，可觀測平臺承擔的角色將發生什么變化？蔣爍淼的判斷是：可觀測性平臺更像是系統的統一上下文平臺。

無論是人類工程師，還是 Agent，要想做出正確判斷，都需要依賴足夠完整的上下文。對人類工程師來說，上下文決定了排障效率，如果數據沒接全、日志沒到位，再資深的專家也無從下手；對 Agent 來說，上下文決定它會不會陷入幻覺。

“任何人也好，AI 也好，它只能看到自己的事實，看不到的事實就是猜，猜就是幻覺，可能對，也可能錯。你給出足夠的上下文，它才能做出準確的判斷。”蔣爍淼認為，當下模型本身的能力差距正在縮小，真正讓不同 Agent 拉開差距的一大關鍵，就是擁有獨特的上下文。

圍繞這一判斷，觀測云的產品思路也在發生“變與不變”。

不變的是底層能力。數據采集、海量實時寫入、低延遲查詢，這些看起來不那么 AI 的能力，反而構成了統一上下文平臺最難替代的部分。

蔣爍淼表示，觀測云長期積累的數據采集能力不會變，這也是其與其他廠商的差異化之一。目前，觀測云 DataKit 支持超過 600 種數據采集，能把數據接進來，也能理解不同技術棧里的字段含義、數據結構和標準化方式，讓這些數據最終能夠被統一查詢、統一關聯。不管使用者是人，還是 Agent，只有數據結構足夠統一，后續分析才有基礎。

另一個不變的核心底層能力是數據庫。可觀測平臺的一大壁壘，在于采集足夠多的數據后，能否低成本地處理、關聯和理解這些數據。

據了解，觀測云早在幾年前就開始自研數據庫，為了應對傳統監控數據庫在寫入性能與查詢性能上的局限，其自研的 GuanceDB 3.0 采用了完全存算分離的架構，將計算節點與存儲節點徹底解耦。通過統一的數據管理、標簽體系和查詢語言（DQL），觀測云實現了對全鏈路數據的深度關聯。這種“數據湖倉一體化”的設計，也讓跨團隊協作不再需要頻繁切換工具，溝通成本顯著降低。

變的是產品交互與自動化方式。過去，Dashboard、低代碼頁面、人工編排的 Workflow，核心使用者都是人，需要人來手動搭建界面、設計流程。當 Agent 也成為可觀測平臺的使用者后，交互方式自然也需要發生變化。

比如，用戶想要什么樣的大屏、什么樣的頁面，可能完全不需要通過低代碼工具一點點拖拽配置，幾句自然語言描述，就能讓 Agent 基于平臺數據和 API 自動生成頁面。

Workflow 也會發生類似的變化。過去告警出現后，人需要提前畫好流程，設定每一步該怎么處理。如果 Agent 能夠理解事件上下文，并結合 Runbook 在可控邊界內做判斷，Workflow 就有可能變成 Agent 自循環、自決策的一部分。

“我們要推行的方案肯定是面向未來的 AI-Driven 自動化，而不是人類畫流程圖的自動化。雖然這件事可能目前存在爭議，但如果放眼五年后，AI 不可能還以人類指手畫腳的方式運行。”蔣爍淼表示，AI 的優勢在于，它可以持續、細致地參與到每一次工作流和事件處理中。“它的注意力可能會飄散，但它不會偷懶。”

但要讓 AI 實現這種持續、細致的參與，一個巨大的前提是，整個鏈路的信息完全貫通。現實卻是，研發、運維和業務之間的上下文往往彼此割裂，數據不少，但能支撐決策和行動的卻不多。從打通上下文，到讓人和 Agent 都能看懂數據，再到讓 Agent 真正能在生產環境中可靠行動——觀測云的思路是，沿著這三層問題逐層下探。

3 從看得懂到能上崗，觀測 Agent 進入工作流

第一層，是先打通上下文。

研發、運維和業務之間長期存在上下文斷層。過去，生產環境里的數據往往掌握在運維手里，研發看到的是代碼和本地環境，業務看到的是用戶反饋和業務結果。一旦線上出現問題，幾方需要反復溝通，排障效率很大程度上取決于人能不能把上下文說清楚。到了 Vibe Coding 時代，這種割裂感進一步加劇。代碼生成的速度更快了，如果 Coding Agent 看不到線上真實運行態數據，它對問題的判斷就只能停留在代碼和局部信息里。蔣爍淼把這種狀態形容為“幻覺對幻覺的大廝殺”：研發看不到生產環境的數據，就只能猜；AI 看不到真實上下文，也只能猜。

觀測云 OWL 試圖解決的，就是這層矛盾。它能提供 CLI 和 MCP Server 兩種接入形態，將觀測云的指標、日志、事件、監控器、儀表板、APM 等核心能力封裝為標準化工具。研發工程師可以將 OWL 裝到 Claude Code 或 Codex 等主流 Coding Agent 中，直接讓 AI 自動查詢生產環境的觀測數據并執行根因分析，不需要獲得生產環境的任何訪問密鑰。

第二層，是讓人和 Agent 都能看懂數據。

可觀測平臺長期面臨的一大矛盾是，數據越采越全，使用門檻也越來越高。面對復雜的查詢語言和數據模型，業務和研發人員往往無從下手。

這正是 Obsy AI Copilot 想要解決的核心問題。蔣爍淼提到，早期的 Obsy AI Copilot 的底層形態更接近 Dify 這類固定工作流：看到日志后，按既定流程做定位分析，最后生成總結。目前，Obsy AI Copilot 底層 Runtime 已經被更新為更接近 Manager Agent 的形態，它不是一個純粹 ChatBot，是注冊了 Skill、上下文和大量 System Prompt 的 Agent。

比如，用戶看到一條日志，可以讓它分析相關性；不知道監控器怎么配，可以讓它幫忙配置；需要遷移或新建 Dashboard，也可以直接用自然語言描述需求，讓它根據觀測對象、指標 Schema 和數據結構自動生成。

“Obsy AI Copilot 本質上，就是幫助人類更好地在自己的界面中使用觀測云產品，更好地和各種 Agent 做驗證。除了早期 1.0 版本里比較簡單的日志問答、產品使用幫助之外，我們現在也引入了更多能力，比如自動幫客戶配置監控器，以及用自然語言生成 Dashboard。”蔣爍淼表示，過去做 Dashboard 是可觀測平臺里非常重的工作，用戶既要理解自己的觀測對象，也要熟悉平臺采集的指標。現在，用戶可以直接描述需求，AI 會根據觀測對象、指標 Schema 和數據結構，自動生成對應的儀表盤。

第三層，是讓 Agent 真正能在生產環境中可靠行動。

在真實生產環境里，發現問題只是開始。一個完整閉環，還需要有人，或者說有 Agent，繼續完成診斷、協同和行動。全新升級的 Guance AI Agent Teams，瞄準的正是這個環節：幫助企業構建可落地、可協作、可執行的 AI 工作團隊。它可以被放進飛書、釘釘、微信等協作場景中，用戶可以在群聊里直接問它問題。并且它更主動，可以圍繞生產環境事件持續參與分析和協同。

但生產環境里的 Agent 一旦具備行動能力，風險也會隨之上升。蔣爍淼提到，觀測云在產品設計上做了明確區分：放在 IM 和普通會話里的 Agent 默認是只讀的，只能查數，不能執行危險操作；真正涉及操作的能力，會放在 Task 頁面里，并由企業把允許 AI 執行的動作封裝成 API。

與通用 Agent 相比，Guance AI Agent Teams 的區別不是重新發明一個 Agent Runtime。蔣爍淼認為，單純從 Runtime 角度看，今天搭一個 Agent 并不難，真正難的是把 Agent 放進具體場景里，給它足夠準確的上下文、合理的角色定位，以及可持續積累的記憶。

這種“場景記憶”也是觀測云正在強化的能力。據了解，觀測云的“筆記”功能過去主要用于故障發生時記錄分析過程，現在已經升級為由 AI 自動生成故障筆記：當用戶與 AI 完成一次問題排查對話后，AI 會將分析過程、處置經驗和相關結論沉淀到平臺中，人類也可以隨時查看。7 月 3 日，觀測云筆記宣布更新，成為 Guance AI Agent Teams 不斷迭代更新的長期記憶層，讓 Agent 團隊能夠持續學習，提升執行準確度。這也是觀測 Agent 從“看得懂”走向“能上崗”的關鍵一步。

此外，Guance AI Agent Teams 還有內建的排障方法論，能把告警分診、影響面判斷、假設生成、證據收集、根因定位、動作建議、審批執行、結果驗證這些流程產品化，并將治理能力作為產品能力交付：默認只讀、最小權限、高風險動作審批、操作留痕、證據鏈可追溯、處置后可驗證。

從 OWL 到 Obsy AI Copilot，再到 Guance AI Agent Teams，觀測云正在重構一條完整的故障處理鏈路。OWL 負責打通數據與工具的連接，讓上下文不再割裂；Obsy AI Copilot 負責降低理解門檻，讓人看得懂、驗證得了；Guance AI Agent Teams 負責在權限和邊界的約束下，將診斷和行動推進到生產環境最后一公里。

三層能力疊加起來，構成了可觀測性從“看得懂”到“調得動”再到“控得住”的完整閉環。

4 結束語：Agent 負責執行，Builder 負責定義結果

當我們重新審視可觀測性的價值時，會越來越清晰地發現，Agent 沒有削弱可觀測性的價值，反而把它從后臺推到了系統中央。

過去十年，AIOps 這個概念被反復提起，但如果一個系統連完整的運行態上下文都沒有，所謂智能運維就無從談起。蔣爍淼對 AIOps 的判斷很直接，“不管是 AI 還是人類，或者哪怕你用算法去驅動，如果你連整個系統發生了什么的上下文都沒有，這真的不叫 AIOps，這叫做神仙 Ops。”

這也是為什么，在 Agent 時代，可觀測的重要性能夠被重新放大。AI 要判斷，就需要事實；要行動，就需要邊界；要減少幻覺，就需要足夠完整、實時、可驗證的上下文。沒有這些，Agent 只是把人的猜測換成了機器的猜測。從 OWL 到 Obsy AI Copilot，再到 Guance AI Agent Teams，觀測云試圖重構的，正是這樣一套工作方式。

但這并不意味著人會退出循環。蔣爍淼認為，人類工程師的角色會變得更重要，只是關鍵能力變了。過去，工程師的價值常常體現在親手寫代碼、手動查問題、逐步執行流程。未來，當 Agent 可以完成越來越多執行動作，人更關鍵的能力會變成：能不能提出正確的問題，能不能定義清楚目標，能不能提供足夠上下文，能不能驗證 AI 給出的結果。

蔣爍淼把這類人稱為 Builder——這是一類更懂技術架構、能活用工具、能把大問題拆成小問題，并對最終結果負責的人。

當一個團隊里每個人都是 Builder 而不只是 Coder，企業的研發和運維模式會發生什么變化？這會是一個更好協作的時代，還是一個超級個體孤軍奮戰的時代？這些問題，將留給每一位正在思考 AI Native 工程體系的人去回答。