智慧體可觀測性需要反饋以驅動學習

大多數團隊最初將智慧體可觀測性視為除錯工具。當出現問題時，開發者開啟追蹤鏈，檢查每一步，找出智慧體在哪一步做出了錯誤決策。這種用法確實有用，但視野過於狹窄。

可觀測性的更深層角色是驅動學習。然而，僅靠追蹤本身無法形成這一迴圈。還需要反饋——即那些能夠告訴你智慧體行為是否有用、被接受、被拒絕、低效、存在風險或出錯的訊號。這種學習不限於模型訓練意義上的學習，而是貫穿整個智慧體系統：模型應該做什麼、框架應如何引導模型、需要哪些上下文、哪些故障模式反覆出現、哪些行為真正對使用者有效。

追蹤不僅僅是事件記錄，反饋也不僅僅是最後給出的評分。二者結合，構成了系統改進的原始素材。

學習可以發生在多個層面。模型層面：你可能發現模型在特定示例中持續錯誤分類請求、選錯工具或未能遵守策略。這些追蹤可用於透過監督微調或強化學習來更新模型權重。框架層面：框架是模型周圍的一切，包括提示詞、工具架構、許可權檢查、控制流、記憶更新邏輯、路由、重試和護欄。追蹤可能顯示，模型能力本身沒問題，但腳手架錯了——比如工具描述模糊、缺少讀前寫後約束、系統提示詞做出了錯誤權衡。上下文層面：智慧體對提供的資訊極其敏感，包括檢索文件、記憶、使用者偏好、工具結果、先前輪次和環境狀態。追蹤可以揭示，模型在接收到錯誤或缺失上下文的情況下做出了合理決策。這種情況下的學習迴圈應改進上下文的檢索、儲存、壓縮或丟棄。這裡通常被稱為記憶。

關鍵點在於，所有這些學習迴圈都由追蹤驅動。如果不知道智慧體看到了什麼、做了什麼、以及隨後發生了什麼，就無法可靠地知道該改進什麼。這就是為什麼智慧體可觀測性驅動智慧體評估——追蹤讓智慧體行為變得可見。

學習可以是人工驅動或自動化的。人工驅動：開發者檢視追蹤，發現智慧體呼叫了錯誤工具，然後更新提示詞或工具架構。產品經理檢視一組失敗對話，意識到產品需要新工作流。標註員標記追蹤，以便團隊構建更好的評估資料集。這仍然是學習，只是有人類在其中。自動化：系統可取樣生產追蹤，執行線上評估，檢測已知故障模式，將示例新增到資料集，或在發現異常時觸發審查佇列。智慧體本身不需要自動改進，自動化只需識別哪些追蹤值得關注，並將其轉化為結構化反饋。

對於單個低流量智慧體，手動審查可能足夠。但對於大量智慧體或高流量生產環境，這就變成了基礎設施問題：需要捕獲追蹤、過濾、評分、路由，並保留重要的那些。

追蹤是必要的，但並不充分。追蹤告訴你發生了什麼，但本身並不告訴你發生的事是好是壞。這個區別很重要：智慧體可能在40步內完成一項任務，但同樣的任務本應只需6步；它可能給出自信的最終答案，但使用者可能拒絕了它；它可能避免了報錯，但仍然未能滿足使用者意圖；它可能呼叫了正確的工具，但引數有微妙錯誤。

要從追蹤中學習，需要將反饋附加到追蹤上。反饋將可觀測性從被動記錄轉變為訓練訊號、除錯訊號、產品訊號或評估訊號。沒有反饋，你只有一大堆軌跡；有了反饋，你就可以開始提出有用的問題：哪些軌跡代表成功？哪些代表失敗？失敗是由模型、框架還是上下文引起的？哪些失敗值得轉化為評估？哪些行為在隨時間改善？

核心要求是：將反饋與智慧體可觀測性資料一起儲存。

反饋可以來自多種渠道。最明顯的是直接使用者反饋：點贊、踩、星級評分或文字糾正。這種訊號易於理解，但通常稀疏，大多數使用者不會留下顯式反饋。其次是間接使用者反饋：對於編碼智慧體，可能是接受的行數、還原的差異、編輯後透過的測試，或者使用者是否保留了生成的更改；對於支援智慧體，可能是使用者是否重新開啟了工單；對於研究智慧體，可能是使用者是否複製了答案或再次提出相同問題。這些訊號比顯式評分更嘈雜，但往往更豐富。你還可以使用大模型作為評判生成反饋：評判器可以評估答案是否有幫助、智慧體是否遵守策略、軌跡是否可疑。這可以在規模上執行，尤其適合在線上評估中處理生產追蹤。雖然不是完美，需要校準，但它為團隊提供了一種在人類審查太慢時建立結構化反饋的方式。最後，反饋可以是確定性的：規則和正規表示式常被低估。如果已知某種故障模式，就將其編碼；如果智慧體未經批准不應呼叫破壞性命令，就檢查它；如果響應應包含引用，就驗證它；如果編碼智慧體顯示使用者挫敗跡象，就檢測它。

Claude Code的洩露事件使這一點具體化。多篇報道發現，Claude Code使用正規表示式在userPromptKeywords.ts中檢測使用者提示中的挫敗詞彙和短語。PCWorld報道該正規表示式查詢“wtf”“horrible”“awful”“this sucks”等詞。從工程角度看，這一模式具有啟發性：並非每個反饋訊號都需要模型呼叫。如果一條廉價規則就能捕獲有用訊號，就使用它——並清楚說明該訊號如何儲存和使用。

綜上所述，可觀測性平臺需要具備三項核心能力。第一，儲存追蹤：這是基礎層，需要完整的智慧體行為軌跡，包括模型呼叫、工具呼叫、輸入輸出、後設資料、計時、錯誤和中間狀態。理想情況下，能相容各種框架，而不限於某一個。LangSmith支援來自30多個框架的追蹤，並能透過OpenTelemetry整合。第二，儲存反饋：反饋不應孤立於追蹤之外的電子表格或分析系統。它應直接附加到所評估的執行、追蹤或執行緒上，從而允許按反饋過濾、比較好壞軌跡、從真實失敗構建資料集、跟蹤更改是否改善了重要行為。LangSmith支援捕獲反饋並將其與追蹤關聯。第三，生成反饋：部分反饋來自使用者，但更多有用反饋應由系統自身產生，包括規則、評估器、取樣、標註佇列、告警以及對歷史追蹤的回填。LangSmith支援自動化規則和線上評估，包括在生產追蹤上執行的大模型評判。

這就是智慧體團隊需要的產品形態：儲存追蹤、儲存反饋、生成反饋。學習迴圈依賴於追蹤加反饋。可觀測性的目的不僅是檢視追蹤，而是從中學習。追蹤告訴你發生了什麼，反饋告訴你它的含義。兩者結合，讓你能改進模型、框架和上下文；支援人工除錯和自動化評估；將生產行為轉化為資料集、規則、告警和迴歸測試。

沒有反饋的智慧體可觀測性是不完整的。你可以檢查行為，但無法系統地從中學習。為了最大化智慧體可觀測性的價值，請將反饋與你的追蹤一同儲存。這就是將智慧體追蹤從日誌轉變為學習系統的關鍵。