LangChain “不务正业”，居然从零造了个数据库？LangChain 作为世界上最懂 Agent 的公司，突然从零

作者：老纪的技术唠嗑局

LangChain 作为世界上最懂 Agent 的公司，突然从零写了一个分布式数据库。

是顺势而为，还是迫不得已？

最主流的 Agent 框架公司，居然开始做数据库了？

先交代下背景：

LangChain 是全球最主流的 AI Agent 开发框架之一，数以万计的开发者用它来构建各种智能体应用。

2026 年 5 月 13 日，LangChain 发了一篇官方博客，标题显得十分平静：《We built SmithDB, the data layer for agent observability》[1]。

一个做 Agent 框架的公司，从零开始，顺手写了个分布式数据库。听起来就像：一家面馆，突然开始卖起了面粉（大概率是被现实撞了满头包之后的选择）。

这里再多补充一个背景：LangChain 生态里有一个叫 LangSmith 的重要工具，专门用来观测 Agent 的每一次推理、每一次工具调用、每一次对话。

LangSmith 原本用的是 ClickHouse —— 业内顶级的分析型数据库，OLAP 场景的性能一流（兹拉坦前两年在做 OceanBase 数据库 SQL 层的 AP 性能优化时，还时常会去学习 ClickHouse 的源码和设计理念）。

他们遇到的问题是现在的 AI Agent 发展速度太快，一次 task 或者 trace 里都能套出几百个嵌套 span，一个 span 可能“出生”在早上十点、“死亡”在下午三点，数据一块儿一块儿地挤进来。

LangSmith 用户每天往里灌的数据太多，在 ClickHouse 的架构中行不通，数据量和 payload 都爆了。

“only supports multi-replica clusters (read scaling), not multi-shard clusters (write scaling)”。

翻译过来就是 “ClickHouse 支持读扩展，但写扩展支持得不好。读可以堆机器，但写只能硬扛”。

除此以外，Agent 系统里的查询模式变得越来越复杂，不只是按时间查日志，一条查询中还需要支持：

全文搜索
根据 error / tag 等字段进行过滤
根据更复杂一些的 JSON 字段进行过滤
聚合 cost、latency、token、eval score 等指标

LangChain 对于解决这个问题的选择是——直接掀桌，自己“原创”了一个分布式数据库 SmithDB。接下来，就先简单为大家介绍下这个 SmithDB 的几个亮点。

（欢迎大家关注 OceanBase 社区公众号 “老纪的技术唠嗑局”，在这里，我们会持续为大家更新与 #AI 和 #Data 相关的技术内容~）

亮点一：把 Agent trace 当成一种新的数据类型

SmithDB 的第一个亮点，是它不是把 trace 当成普通日志存，而是把 Agent trace 当成一种新的数据类型来处理。

传统日志系统更擅长处理一条条已经结束的记录，但 Agent trace 不是这样：一个 run 可能拆成多个事件，一个 span 可能长时间保持打开状态，输入输出里还可能混着大段 JSON、文本、多模态内容和工具调用结果。

亮点二：架构拆得很轻

第二个亮点，是它把架构拆得很轻：底层用对象存储放持久数据，用一个小型 Postgres metastore 记录 segment 元数据，查询、写入、compaction 服务都尽量做成无状态。

这样扩容的时候，不是去维护一堆带本地盘的复杂数据库节点，而是加计算资源，让数据继续稳稳地躺在对象存储里。

亮点三：热数据就近读取

第三个亮点，是它知道“新鲜数据”不一定已经完全沉到对象存储里。对象存储是最终的数据底座，但刚写入的数据往往还在 ingestion node 的本地 SSD 或内存缓存里。

SmithDB 会记录每个 segment 是哪个写入节点产生的，如果这个节点还在线，查询就可以直接从这个节点读最新数据，而不是绕一圈再从对象存储里把小文件捞回来（这个思路很像传统数据库的 LSM Tree）。

亮点四：run 是“一串事件”，不是“一行记录”

最后一个亮点，是它**把 run 看成“一串事件”，不是“一行记录”**。这点对 Agent 特别关键。因为一个 Agent 运行过程中可能发生模型调用、工具调用、重试、后台任务、handoff，中间状态不断变化。

如果非要等全部结束再写入，可观测性就失去了实时价值；但如果每个事件都写进去，查询时又必须高效合并。

SmithDB 专门为这个模型做了事件 fanout、merge 和 compaction 策略（哈哈，这个写入策略，更像 LSM Tree 了）。

SmithDB 的性能数据也相当能打：Trace 树加载 P50 延迟 92 毫秒，单次 run 加载 71 毫秒，全文搜索 400 毫秒。相比 LangSmith 原来的体验，快了 12 倍。

但兹拉坦认为：真正的看点不在性能提升上的数字，在于 SmithDB 是专门为 Agent trace 设计的。

它知道一条 run 里会有多个事件，知道旧数据和热数据要分开压缩策略，知道用户查询最新 trace 的时候不需要扫全表。这些“知道”是 ClickHouse 做不到的——不是不够强，而是不像 SmithDB 那么懂 Agent。

这件事真正有意思的地方，可能不在技术本身

LangChain 造 SmithDB，说明了一个比技术更重要的行业判断：Agent 运行时产生的那些数据——推理路径、工具调用、上下文变化、反馈信号，都极其重要，但通用数据库不一定能承载好。

Agent 的数据和传统数据库，完全不是同一个画风。它是半结构化的，一段 JSON 里混着自由文本和向量。它是高频写入的，一次对话能爆出几十条记录。它是长生命周期的，一个 span 从开到关横跨好几个小时。它还需要复杂的关联——"找出所有调用过这个工具但最终失败了的那一步"。

把这种数据丢给通用数据库，就像让一个会计去画画——也不是不能，但感觉不太对劲儿。

数据绿色循环，让生活更美好

Agent 最宝贵的资产，是它在你这儿跑出来的那些“个性化经验”——这次推理路径走通了、那次工具调错了被纠正了、这类问题用户问了 100 遍、那条回答用户都点了踩。这些原始数据如果能被沉淀下来、提炼出来、再喂回去，Agent 就开始“长记性”了。

问题在于，这个“提炼 → 沉淀 → 反哺”的过程，传统做法每一步都在不同系统里完成。数据搬来搬去，Pipeline 一长串，人力成本比数据价值还高。

LangChain 显然懂这件事，SmithDB 社区博客里那些“text search”、“JSON filtering”、“tree-aware queries”，翻译过来就是——我们不只是存 trace，我们要让 trace 能被喂回去、用起来，让 Agent 系统能够不断进化。

这也是为什么“数据库”在 AI Agent 里是永远绕不开的角色。如果 Agent 数据从一开始就存进同一个底座，那运行、记录、提炼、评测、反哺就不再是割裂的步骤，而是一个紧耦合的飞轮。Agent 跑一次，就聪明一点点。循环越密，进化越快。

AI Agent 的“数据饥饿”问题

随着 AI Agent 越来越频繁地遇到“数据饥饿”问题，LangChain 的做法很有意思，基于 Agent 框架往上做了一层数据库。背景的介绍原文如下：

LangSmith 于 2023 年首次推出时，人工智能应用还相对简单：团队正在构建 RAG 管道、提示链和非常早期的代理。

从那时起，Agent 变得更加普遍，运行时间更长，LLM 上下文窗口大小大幅增加，workload 包含了更多的多模态内容，例如图像和音频。

因此，与现代 Agent 相关的 trace 数据在数量和大小上都呈爆炸式增长。一个现代 Agent 的 trace 可能包含数百个深度嵌套的 spans。

LangSmith 先做了可观测性，发现存储有问题（不支持对分布式写入进行扩展），然后从零造了 SmithDB。

兹拉坦认为：LangChain 等 Agent 公司自研数据库，目前还处在非常原始的“发现某些场景玩儿不转，然后就去补”的阶段。AI Agent 发展的速度极快，过几天，大概率还会再在其他组件依赖的基础设施上，再次遇到诸如：数据分片、容灾备份、扩展性、安全合规，乃至和 AI 密切相关的混合检索等等新问题，到时候可能难免就要头痛医头，脚痛医脚。

简单总结一下：LangChain 开发了一个 SmithDB 数据库，用于在 LangSmith 中提升 Agent 可观测性相关的工作效率。虽然很有想法，在用于观测的组件中也能跑得不错，但可能还真喂不饱现在越来越复杂的 AI Agent 框架。

一些思考

LangChain 这一手，捅破了一层窗户纸：Agent 跑出来的那些破事：推理链、工具调用、上下文、反馈，很多数据库都扛不住。

这事不只是 LangChain 一家在头疼。

我们随便看看周围：Claude Code 的对话历史存哪？JSONL 文件。OpenClaw 呢？Markdown。讲究点的团队上了 SQLite，但本质还是"在文件夹里整齐摆放"。想加向量？装个 pgvector。要存上下文？再来个 Redis。看 trace？试试新鲜热辣的 SmithDB。跑评测？那就再搭一套 Pipeline……

最后你打开服务器，五六个组件并排站着。数据在它们之间来回搬运，搬一次掉一次精度、烧一次 token。

LangChain 从 Agent 框架往下，做了一层数据库。那反过来呢？从更成熟的数据库层往上，去接一层 Agent 框架，会不会有更大的想象空间？

什么意思？比如让 Agent 从第一行代码跑起来，产生的数据，天然就在一个非常成熟的数据库里。不是通过什么“外挂日志”，而是通过数据库原生的能力，支持可查询、可回放、可对比、可进化。然后从一个成熟的数据库层往上，集成 LangChain、AgentScope 等最主流 Agent 框架。

这跟 LangChain 的路数构成了一个有趣的对照。如果起点是数据库，是不是就会绕过很多“发现某些场景玩儿不转，然后就去补”的阶段了？LangChain 正在踩的那些数据库的坑，数据库公司 N 多年前早就踩完了。 这不是谁比谁厉害的问题，是起点不同带来的天然差异。

我们希望能够从一个和 LangChain SmithDB 完全相反的路径上，实现一个效果更好的 Data × AI 闭环：

Agent 运行产生数据 → 存进 OB4AI（姑且先简单理解成是一个成熟的数据底座）        ↓Context / Memory 系统自动提炼：原始记录 → 洞察 → 知识 → 可复用技能        ↓评测筛选出高质量数据        ↓高质量数据反哺 Agent，让它下次表现更好        ↓Agent 表现更好 → 产生更有价值的数据 → 循环加速

做法特点传统做法循环的每一步都在不同系统里完成，数据搬运成本极高**“也许”更好的做法？**所有数据从一开始就在同一底座上，整个循环是“内循环”——不需要数据搬运，不需要额外基础设施