全量采集Agent日志：何時該說"夠了"

你剛上線一個AI Agent。第一周，Honeycomb上的鏈路追蹤漂亮極了——每次對話輪次、每個工具調用、每個token都完整記錄，出問題隨時能回溯。然后賬單來了：存儲費用比推理成本還高。周五下午，沒人愿意面對那個問題：該扔掉什么數(shù)據，才能既不破產又不瞎眼？

真相是：對Agent集群做100%全量采集，收益遞減來得比你想象得早得多。鏈路追蹤仍是調試工具調用循環(huán)的唯一手段，但一條trace的價值天差地別。一個3秒干凈收尾的正常對話是統(tǒng)計噪音；一個47秒、調了11次工具、最終撞MAX_TOKENS報錯的trace才是金礦。用同樣的價格買兩者，等于拿找bug的預算補貼無聊的正常流量。

這篇講怎么算這筆賬，以及OpenTelemetry該怎么配。

普通HTTP請求的trace大概10個span：請求進來，命中handler，查數(shù)據庫，調一個下游服務，返回。Honeycomb、Datadog這些APM的定價都按這個量級設計的。

Agent的對話輪次完全不是這個形狀。單條用戶消息可能產生：LLM調用span、系統(tǒng)prompt加載、RAG檢索、向量數(shù)據庫查詢、重排序模型調用、工具執(zhí)行（每個工具有自己的輸入輸出token計算）、工具結果回傳、最終生成。加上MCP（Model Context Protocol）工具邊界，數(shù)量再翻倍——每個MCP調用都是獨立的client+server span對。一個愛聊天的Agent做跨三個倉庫的代碼搜索，單輪輕松60到120個span。按每天5萬輪算，就是300萬到600萬個span。按公開APM定價頁的低個位數(shù)美元/百萬indexed span（Datadog約$1.27/M，15天保留期），錢還沒開始路由就已經燒掉了。

Honeycomb的付費檔標著每月10億事件配額，聽著很多，但按上面的單輪span數(shù)一算，中等規(guī)模的Agent集群兩周就能吃完。關鍵是"每條有用trace的成本"，全量采樣時這個比例被90%的無聊trace主導。

第一反應是頭部采樣（head sampling）：在trace開頭拋硬幣，OTel的TraceIdRatioBased就這么干。Agent SDK創(chuàng)建root span時，采樣器決定"你進10%桶，下游全記；你進90%桶，全扔"。

便宜、簡單、可預期。但對Agent是錯的。

缺陷在于：頭部采樣在trace存在之前就決定了。你無法預知這個對話會不會變成47秒的災難。等你知道的時候，已經沒數(shù)據可看了。