LangChain 在 2026 年 5 月 13 日推出 SmithDB，並表示它已支撐 LangSmith 的核心 observability workloads。
這個題目表面上很基礎設施，但對 enterprise AI 很重要。因為 agent 一旦上 production，trace data 很快就會變成新瓶頸。
為什麼 agent traces 不像一般 logs？
傳統 request-response 系統的 trace 通常比較短。Agent 不同，一次任務可能包含：
- 多輪 model calls。
- 多個 tool calls。
- Subagent delegation。
- Human approval。
- Long-running spans。
- 多模態 payload。
- 檔案和 artifacts。
- 大量 structured metadata。
LangChain 提到 modern agent trace 可能有數百個 deeply nested spans，而且 start event 和 end event 可能相隔數分鐘甚至數小時。
這種資料形狀不是一般 observability store 一開始設計要處理的。
Agent observability 需要哪些查詢？
SmithDB 針對幾種 agent-native query patterns：
- Random access：快速載入單一 run 或 trace。
- Interactive filtering：依 metadata、feedback、latency、errors、tags、time 切資料。
- Full-text search：搜尋 inputs、outputs 和 pattern。
- JSON filtering：查 user-defined metadata 和 tool outputs。
- Tree-aware queries：依 root runs、child runs 或任一 trace node 查詢。
- Thread reconstruction：重建長對話和多次 traces。
- Aggregations：計算 cost、latency、token usage、evaluator scores。
如果 trace 查詢慢，agent improvement loop 就會慢。工程師會少看 trace，也更難把失敗轉成 eval。
SmithDB 的架構重點
SmithDB 包含三個核心部分：
- Object storage：保存 durable trace data。
- Postgres metastore：保存 segment metadata。
- Stateless ingestion、query、compaction services。
這種設計讓資料持久化放在 object storage，compute 則可以水平擴展。對自架和 multi-cloud 環境來說，這比管理本地磁碟和複雜 sharding 更適合企業需求。
對企業的啟發
如果公司開始大量部署 agent，要提早思考 trace data strategy。
需要問：
- Trace 保留多久？
- 哪些 payload 要遮罩？
- 哪些 trace 要長期保存成 eval dataset？
- 能否搜尋 tool outputs？
- 能否依使用者回饋和 evaluator 分數查詢？
- 能否重建跨多輪的 thread？
- 自架時資料是否留在企業環境？
Agent observability 如果只停在 log collection，後面會很快遇到限制。
官方來源
結論
SmithDB 的重點，是把 agent trace 當成一種新的資料負載來處理。
未來企業 AI 基礎設施不只會有模型、向量資料庫和工具層，還會需要專門的 agent observability data layer。因為沒有快速、可搜尋、可過濾、可重建的 traces，就很難真正改善 production agent。