LangChain 发布用于 Agent 可观测性的 SmithDB 数据层

Agent traces 已经超出了传统可观测性存储的承载范围——现代 agent traces 包含数百个嵌套 span、多模态内容，以及持续打开数小时的 span，产生的数据量和查询模式是通用数据库从未为之设计的。

SmithDB 在所有关键可观测性工作负载上都提供了业界领先的性能——trace tree 加载的 P50 延迟为 92ms、全文搜索为 400ms、run 过滤为 82ms，使核心 LangSmith 体验比之前最多快 15 倍。

面向企业需求打造的可移植、可扩展架构——依托对象存储，并采用无状态的摄取与查询服务，SmithDB 通过扩展计算能力而不是管理本地磁盘来实现横向扩展，使其能够轻松部署在自托管和多云环境中。

我们正在推出 SmithDB，这是一款专为 agent 可观测性打造的分布式数据库，如今已支撑 LangSmith 的核心工作负载。

SmithDB 为 LangSmith 带来了业内领先的关键可观测性工作负载性能，能够灵活部署在客户需要数据驻留的任何位置，并支持传统可观测性存储并未为之设计的、以 agent 为原生的查询模式。

在 agent 可观测性中，trace 扮演着 agent 核心行为记录的角色。

当 LangSmith 于 2023 年首次推出时，AI 应用还相对简单：团队主要在构建 RAG 流水线、提示词链，以及非常早期的 agent。

此后，agent 变得更加普及，也运行得更久；LLM 的上下文窗口大小大幅提升，而工作负载中包含的多模态内容也越来越多，比如图像和音频。

因此，与现代 agent 相关的 trace 数据在规模上和体量上都出现了爆发式增长：既包括 trace 的数量，也包括单个载荷的大小。一个现代 agent 的 trace 可能包含数百个深度嵌套的 span。

除了体量大、层级深之外，agent trace 还是分片到达的：一个 agent span 的开始事件，可能会比结束事件早几分钟，甚至几个小时到达。

用于分析这些数据的查询模式也变得日益复杂。Agent 可观测性需要支持：

随机访问：立即加载单个运行或 trace

交互式过滤：按元数据、反馈、延迟、错误、标签和时间切分大规模 trace 数据集

全文搜索：在 agent 运行的输入和输出中查找短语和模式

JSON 过滤：查询任意用户定义元数据和结构化工具输出

树状感知查询：可基于根运行、子运行或跟踪中的任意节点进行过滤

线程重建：即时重构跨多个 agent 轨迹的长时对话

聚合：按不同筛选条件计算成本、延迟、token 用量和评估器得分

要在低延迟下，支持所有这些场景，并且覆盖大规模 agent 跟踪数据，同时满足自托管和多云要求，就需要一种从根本上全新的架构。

这正是 SmithDB 诞生的动因。

SmithDB 是 LangSmith 专为智能体可观测性和评估工作负载打造的数据层。

它采用 Rust 构建，基于 Apache DataFusion 查询引擎和 Vortex 文件工具包，并针对 LangSmith 的独特工作负载进行了大量定制。

从整体上看，SmithDB 由三个组件组成：

用于持久化 trace 数据的对象存储

用于段元数据的小型 Postgres 元数据库

无状态的摄取、查询和压缩服务

性能之于可观测性，不只是“锦上添花”。对人类和智能体而言，缓慢的可观测性工具会成为智能体开发循环中的瓶颈。SmithDB 在智能体可观测性最关键的工作负载上提供领先性能，并让核心的 LangSmith 体验比之前快高达 12 倍。

由于 SmithDB 以对象存储为后端，因此不需要管理本地磁盘。查询和摄取服务都是无状态的。系统通过增加计算资源来扩展，而持久化数据则存放在对象存储中。

这使得 SmithDB 在自托管和多云环境中的部署，远比那些需要本地磁盘和复杂分片的传统数据库集群要容易得多。

美国 Cloud 的摄入流量 100% 都进入 SmithDB。

100% 的 tracing UI 查询流量都进入 SmithDB，包括 threads

所有主要过滤器都由 SmithDB 提供支持，包括 metadata、feedback、文本搜索、tree filters 和 trace filters

产品集成功能，如运行规则、批量导出和实验，已接近完成

所有相关的产品界面都将迁移到 SmithDB，SmithDB 也将提供给 LangSmith 的自托管部署使用

过去几个月里，我们一直在将客户工作负载迁移到 SmithDB。以下是 Clay 和 Vanta 团队的反馈：

我们每天都会向 LangSmith 记录数亿条 agent 可观测性事件。SmithDB 让我们的团队能够以所需的速度搜索、排查和分析这些数据，从而改进生产环境中的 agent。性能提升立竿见影，而且非常明显，尤其是在大型项目中，过去 trace 探索一直是个瓶颈。‍ — Jeff Barg，Clay AI 负责人

自从迁移到 SmithDB 之后，性能提升立刻就能感受到。我们的 UX 明显更流畅了，查看数据也比以往更快、更直观。整体体验非常好。‍ — Andy Almonte，Vanta AI 高级工程经理

我们有很多包含大量工具调用的 trace，迁移到 SmithDB 之后，在各个项目中查询和阅读 trace 都变得容易多了。这帮助我们更快地定位边缘情况、构建 eval 数据集，并以前所未有的速度迭代我们的 trace。‍ — Kunal Rai，Unify AI 软件工程师

在 Cogent，我们的后台 agent 一次就能生成海量 trace。我们需要对这些系统具备实时可观测性，而 SmithDB 已经做到了这一点：trace 能在几秒内看到，而不是几分钟——这也是我们在测试其他提供商时的体验。‍ — Larsen Weigle，Cogent Security 技术团队成员

为了把 SmithDB 打造成一个在 agent 可观测性工作负载下极其高性能的数据库，团队投入了惊人的工程努力。

从高层来看，SmithDB 采用对象存储作为后端构建为日志结构合并树（LSM）。LSM 会先将写入缓存在内存中，然后把它们以不可变的有序批次刷入持久化存储，并定期将这些段合并压缩。查询时，会读取多个段，并将它们合并成一条有序流。

SmithDB 由五个主要组件组成：

摄取服务：接受 trace 写入，按分区和时间桶进行批处理，并写入不可变文件

元数据存储：记录分段元数据，包括位置、时间范围、行数，以及更新/删除向量

查询服务：提供查询接口，配套自定义执行计划，能够理解 LangSmith 的运行语义和对象存储。SSD 和内存缓存被大量利用。

压缩服务：在应用删除、升级、TTL 到期和索引合并的同时，将写优化段重写为查询优化段

集群管理器：将在线服务节点分配到不同的键范围。这一点很重要，因为 SmithDB 不只是想分散负载；它还希望让重复查询尽量落到那些很可能已经缓存了正确数据的节点上。

下面是其中一些关键工程挑战的细节，我们会在后续的博客文章中展开：

许多 LangSmith 查询都会请求某个特定租户和 tracing 项目中最新的 runs。一个朴素的对象存储方案会先找出所有候选文件，打开其中很多文件，对数据进行排序合并和去重，然后才应用 limit。

SmithDB 会沿时间向后回溯，并围绕最新的候选 segment 构建一个有界时间窗口。这把“先把所有内容排序，再做 limit”变成了“读取最新的有界切片，流式读取、合并并去重行，并在正确性允许的情况下尽早停止”，从而显著减少为满足“Top K”类查询而扫描的数据量。

对象存储是持久的事实来源，但最新鲜的数据往往仍然存在于写入它的摄取节点上。

每个文件分片都会记录生成它的节点的服务器标识符。如果该写入节点仍在线，查询规划器就可以使用自定义计划，直接从摄取节点的本地 SSD 和内存缓存扫描这些文件，而不是立刻从对象存储中把它们读回来。这避免了我们为了满足前沿查询而不得不从对象存储中读取几十个小文件。

智能体可观测性围绕长时间运行的 span 构建。

在传统的请求/响应应用中，一个 span 可能在毫秒内开始并结束。但智能体的 span 可以保持开启更久。一次运行可能涉及模型生成、工具调用、重试、后台工作，或移交给其他智能体。在 span 结束之前什么都不写入，显然并不理想。

在 SmithDB 中，一次 run 是一系列事件，而不是一条不可变记录。这个说法看起来很简单，但它会影响整个查询引擎。系统会格外小心地将过滤条件分发到目标事件，并在查询时以高效的方式合并这些事件。如何处理每个 run 下的多个事件，也会影响我们的压缩策略。

数据摄入会优先优化写入延迟，因此会产生许多较小的不可变分段。一直查询这些分段会带来过高的文件打开开销和去重工作。

压缩会把这些写入优化型分段转换为查询优化型分段。SmithDB 采用时间分层策略。时间分层决定了 SmithDB 应该多激进地执行这项工作。较新的数据更可能收到结束事件，因此如果过早把它们压缩成超大的文件，就会带来不必要的写放大。较旧的数据更稳定，也更可能被反复扫描，因此值得合并成更大的文件。

这样既能保持写入速度，又能逐步降低旧数据的查询成本。

像删除和升级这类变更，在可观测性系统中往往很难处理，因为数据文件是不可变的。默认情况下，SmithDB 不会在每次删除时同步重写数据文件。相反，metastore 会把删除向量和升级向量附加到分段条目上。查询路径和压缩路径会使用这些向量来正确解释不可变文件。文件重写则在压缩过程中发生。

这种策略让 SmithDB 中的变更具备很高的可扩展性。这一点对 agent 可观测性尤其重要，因为保留期限很少是统一的。大多数 trace 只对近期的调试、监控和评估有用，但只有少数会因为某条 trace 的具体内容而需要长期保留。

Agent 轨迹通常包含体量很大、且可能无限增长的载荷。SmithDB 通过将核心运行字段与大字段分离，来保持常见的列表和筛选查询足够快。核心行只携带指向大字段文件的指针，而查询引擎只有在查询实际投影这些字段时，才会去读取那些大载荷。

这意味着，加载 run 列表或应用筛选条件时，不需要读取数 MB 的 JSON，除非用户真的打开该 run，或者明确请求这些字段。

要在 1MB 以上的载荷上支持亚秒级全文搜索和 JSON key-path 筛选，本身就是一个颇具挑战的工程问题。

SmithDB 通过一种针对对象存储优化的自定义倒排索引布局，高效处理这些查询。在本地磁盘上，索引可以依赖低成本的 seek 和大量小规模读取；但在对象存储上，这种模式就不再适用：每一次不必要的请求都会增加延迟，而如果过早拉取过大的 postings 或 positions 列表，往往会主导整个查询耗时。

SmithDB 的索引布局就是为了避免这一点而设计的。词项会按行组排序，每个行组都会记录词项区间的最小/最大值。因此，在 SmithDB 获取 postings 字节之前，精确词项查询和前缀词项查询就可以先剪枝掉不相关的索引行组。postings 和 positions 会与词典分开分块，因此常见词项不会迫使系统进行一次超大的内存分配，也不会迫使对象存储发起一次超大的范围读取。行组和分块阈值同时限制了构建器内存占用和查询时 I/O。

SmithDB 还包含一个轻量级集群管理器，用来控制哪些服务节点拥有哪些流量。这一点很重要，因为 SmithDB 不只是想分散负载，它还希望重复查询尽量落到那些很可能已经缓存了正确数据的节点上。

这个集群管理器借鉴了 Google 的 Slicer 和 Databrick 的 Dicer 项目，它通过把 keyspace 划分为若干 slice，并将每个 slice 分配给一组稳定的服务节点来避免这一问题。路由器会利用这些分配，把相关请求发送到同一个节点或一个较小的副本集合。

这给了 SmithDB 两个重要特性：

黏性路由：相关请求更有可能落到一个已经持有正确缓存元数据或分片字节的节点上。

自适应负载均衡：当节点加入、离开或变得过载时，集群管理器可以在不更改持久化分片元数据的情况下迁移切片。

除了让更多 LangSmith UI 迁移到由 SmithDB 提供支持之外，我们还对这一数据层解锁的新产品体验感到非常兴奋。

LangSmith 的下一阶段不只是更快的 trace 加载。它还要让 trace 数据更有用：更易搜索、更易分析，也更易回馈到 agent 开发循环中。SmithDB 将作为实现这一切的基础层。

我们也在寻找优秀的系统工程师和数据库工程师加入我们！

LangSmith 是我们的智能体工程平台，帮助开发者调试每一个智能体决策、评估变更，并一键完成部署。