數(shù)據(jù)平臺(tái)們花大力氣做觀測(cè)，卻在最復(fù)雜的地方留了盲區(qū)。

Databricks這類企業(yè)數(shù)據(jù)平臺(tái)投入了大量精力完善產(chǎn)品的可觀測(cè)性與追蹤能力。這在受監(jiān)管行業(yè)的企業(yè)支持中是剛需。但針對(duì)復(fù)雜的數(shù)據(jù)科學(xué)與分析智能體，觀測(cè)套件存在明顯缺口——不僅是Databricks，所有大小數(shù)據(jù)分析與數(shù)據(jù)科學(xué)智能體供應(yīng)商都面臨同樣問(wèn)題。

以Databricks為例，即使以notebook作為主要用戶界面，憑借數(shù)據(jù)血緣、數(shù)據(jù)管理和MLflow的完整布局，其控制與追蹤能力已經(jīng)相當(dāng)成熟。然而，無(wú)論是Databricks、Snowflake這樣的大廠商，還是小型分析智能體供應(yīng)商，都共享同一個(gè)觀測(cè)盲區(qū)。這個(gè)盲區(qū)根植于編碼智能體的架構(gòu)特性，并非所有智能體都會(huì)遇到。

具體差異在哪里？一個(gè)文本轉(zhuǎn)SQL助手出錯(cuò)的方式很"直白"：結(jié)果明顯不合理。但智能體生成的多步Python或Spark流水線完全不同。即便是人類編寫的這類代碼，面對(duì)無(wú)窮無(wú)盡的表連接組合、數(shù)據(jù)問(wèn)題和數(shù)據(jù)特征，理清流水線邏輯也極為困難。智能體介入后，這個(gè)問(wèn)題并未消失。Databricks的Genie可以規(guī)劃解決方案、運(yùn)行代碼、利用單元格輸出優(yōu)化結(jié)果、自動(dòng)修復(fù)錯(cuò)誤。問(wèn)題在于：除了最初的推理過(guò)程和最終產(chǎn)物，中間環(huán)節(jié)能檢查什么？什么能被可靠地、非概率性地記錄？

為實(shí)現(xiàn)目標(biāo)，這些更復(fù)雜的數(shù)據(jù)科學(xué)與分析智能體需要構(gòu)建相當(dāng)復(fù)雜的多步流水線。越過(guò)初始數(shù)據(jù)檢索和最終存儲(chǔ)步驟，流水線本身就是任意代碼。人類編寫的這類腳本，其可觀測(cè)性已經(jīng)催生了MLOps領(lǐng)域的眾多公司，包括Databricks自家的MLflow。但當(dāng)代碼由智能體生成時(shí)，現(xiàn)有的觀測(cè)方案是什么？除了讓智能體自己為代碼插樁（概率性地），似乎別無(wú)選擇——而這某種程度上違背了觀測(cè)的初衷。

將觀測(cè)缺口從更大的數(shù)據(jù)平臺(tái)語(yǔ)境縮小到特定領(lǐng)域——這些復(fù)雜分析與數(shù)據(jù)科學(xué)智能體工作流中的"已執(zhí)行流水線代碼"環(huán)節(jié)后，第一個(gè)問(wèn)題是：MLflow或生態(tài)系統(tǒng)中其他"開箱即用"的工具能否直接填補(bǔ)這個(gè)缺口？關(guān)于為何OpenTelemetry在此不足，前文已有討論。

MLflow的發(fā)展方向 unsurprisingly 是更細(xì)粒度的儀器化，且盡量減少各方——無(wú)論是人類還是智能體——的工作量。對(duì)于經(jīng)典機(jī)器學(xué)習(xí)，單次mlflow.autolog()調(diào)用即可自動(dòng)捕獲參數(shù)、指標(biāo)、模型、數(shù)據(jù)集和制品；對(duì)于生成式AI和智能體工作流，一行代碼的追蹤原語(yǔ)如@mlflow.trace、mlflow.trace(...)等提供了類似便利。

但智能體生成的多步數(shù)據(jù)流水線，其觀測(cè)需求與經(jīng)典ML訓(xùn)練或簡(jiǎn)單LLM調(diào)用追蹤截然不同。流水線中的每一步都可能涉及數(shù)據(jù)轉(zhuǎn)換、中間表創(chuàng)建、條件分支——這些動(dòng)態(tài)生成的結(jié)構(gòu)，其觀測(cè)復(fù)雜度遠(yuǎn)超靜態(tài)訓(xùn)練腳本。MLflow的自動(dòng)日志能捕獲什么？智能體自己都不一定"知道"它生成了哪些中間變量，更遑論以確定性方式記錄。

當(dāng)前的觀測(cè)工具假設(shè)代碼是人類編寫的、意圖明確的、結(jié)構(gòu)相對(duì)穩(wěn)定的。智能體代碼打破了這些假設(shè)：它可能是為特定數(shù)據(jù)特征即時(shí)生成的，可能包含大量防御性處理，可能在執(zhí)行過(guò)程中自我修改。傳統(tǒng)MLOps的觀測(cè)哲學(xué)——"記錄你知道會(huì)發(fā)生的事"——在這里遇到了根本性的不匹配。

這個(gè)盲區(qū)的影響是實(shí)質(zhì)性的。當(dāng)智能體生成的流水線產(chǎn)出異常結(jié)果時(shí)，調(diào)試路徑被嚴(yán)重壓縮。開發(fā)者面對(duì)的是黑箱：輸入、輸出，以及中間的概率性自我報(bào)告。在受監(jiān)管行業(yè)，這種可解釋性缺口可能成為 adoption 的硬性障礙。

填補(bǔ)這個(gè)缺口需要重新思考觀測(cè)的邊界。不是讓智能體"順便"記錄自己的執(zhí)行——這本質(zhì)上是要求 fox 看守 henhouse——而是需要能夠獨(dú)立于智能體意圖、對(duì)任意生成代碼進(jìn)行外部追蹤的基礎(chǔ)設(shè)施。這更接近于傳統(tǒng)軟件工程的調(diào)試器，而非MLOps的日志系統(tǒng)。

問(wèn)題是，這樣的工具存在嗎？