傳統 o11y 問「系統有沒有活著」；
Agent o11y 要問 有沒有做對事

先講結論：agent observability 的核心問題不是「up or down」

傳統 observability 很適合回答系統是否運作：服務有沒有掛、latency 是否升高、duration 是否異常、HTTP 400/500 是否變多。Phil Hetzel 甚至明確說 Braintrust 自己也使用 Datadog，因為這類工具對網站與服務層的 technical observability 很有效。

但 agent 產品需要多回答一層問題：它回覆得對不對？是否 grounded 在它取得的 context？是否用了預期工具？是否符合品牌或專業標準？這些問題不能只靠 metrics 解決，因為答案藏在 prompt、tool call、retrieved context、reasoning path、輸出文字與人類標註裡。

傳統 o11y 看「系統是否正常」；agent o11y 還要看「代理在不確定環境裡是否做了正確決策」。— 本頁依影片逐字稿與 YouTube 描述整理

差異一：agent 是非決定性系統，品質不能只量 latency

傳統應用多半走已知 control flow。request 進來、服務處理、資料庫查詢、response 回去，trace 和 span 可以映射到相對穩定的程式路徑。Agent 不一樣，它可能根據使用者輸入、上下文與工具結果選擇不同路徑；我們關心的不只是它花多久，而是它為什麼走這條路。

因此 agent observability 仍然需要 time to first token、total tokens、duration、latency、cache hit 等 technical metrics，但這些只是底層。更高層的指標是 functional quality：答案有沒有引用正確 context、工具選擇是否合理、輸出是否符合標準、是否踩到安全或專業邊界。

差異二：agent trace 是新的資料系統問題

Phil 用「nasty」形容 agent trace：高度半結構，裡面又塞滿非結構文字；體積可能巨大，單一 trace 可超過 1GB，單一 span 可到 20MB；同時產品團隊仍然期待像傳統 observability 一樣即時看到最新互動。

這會改變 storage 與 query 的設計。Braintrust 為此從頭做了一個針對 agent trace 的資料庫：資料先進 write-ahead log 以便立即可見，再透過 analytical indexes 支援快速 filter，並 fork Tantivy 這個 Rust full-text search library，讓工程師可以查「所有提到 Amazon 的 traces」這類文字問題。

差異三：使用者不只 SRE，也包含 domain expert

傳統 observability 的主要使用者通常是 systems engineer、product engineer 或 SRE。Agent observability 如果做得好，使用者會擴大到最懂業務與風險的人：clinician、registered nurse、lawyer、wealth advisor、product manager。因為 agent 的好壞往往不是純技術問題，而是領域判斷問題。

這也是 human annotation 重要的原因。專家可以打開 trace，判斷 agent 做得好不好，並寫下原因。那些 justification 之後可以被 LLM 歸納成 failure modes，再變成可規模化的 scoring functions。人類標註找出錯誤形狀，自動評分把它放大到更多 trace 上。

Observability 與 evals 其實是同一個系統

Phil 對 evals 的定義很實務：evals 和 observability 解的是同一類資料與品質問題，差別只是 evals 通常事先知道 inputs、用 batch 跑；observability 不知道 inputs，必須在 production real time 處理。也就是說，trace 不應只是 debug 過去，而要能回流成 offline dataset，支援下一輪 experiment。

這也是 agent 產品迭代的閉環：production trace 暴露真實使用與錯誤，人類或模型把問題標成可評分的 failure modes，團隊再用 evals 比較 prompt、tool、model 或 workflow 版本。沒有這條閉環，agent quality 很容易停留在 demo 感覺，而不是可驗證的改善。

下一步：從 known unknowns 走向 unknown unknowns

Braintrust 已開始在 trace 上跑 lightweight LLM，做 embedding、clustering 與 topic modeling，用來理解使用者 intent、sentiment，以及他們遇到的問題。這件事回答的是客戶常問的簡單問題：「你們既然收了我的 trace，能不能告訴我大家怎麼用我的 agent？」

簡單問題背後其實是複雜系統。已知 failure mode 可以用 online scoring 或 eval 追蹤；未知問題則需要從大量 trace 中自動浮現模式。對 agent 團隊來說，這代表 observability 不只是監控面板，而是產品洞察、品質治理與實驗資料的共同底座。

實務啟發：要把 agent o11y 當成產品核心，而不是外掛 log