Litefuse开源Agent可观测平台：25秒极速轻量评测

在 Agent 可观测这个领域，业界一直面临一个两难选择：要么功能强大但成本高昂（比如 Langfuse），要么简单轻量但能力缺失。上个月，Litefuse 正式发布了，带着一种新的方法论 EDD——Evaluation Driven Development，试图用“观测-评估-优化”的闭环来应对 Agent 特有的那些头疼问题：大模型幻觉、路径规划走偏、工具调用失败、上下文腐化等等。Litefuse 把 Trace 采集、可视化分析、数据集管理、实验运行与评估这一整套能力产品化了。

过去这一个月，Litefuse SaaS 服务收到了不少正向反馈。注册用户已经超过 200 人，使用场景也从最初的 Agent 评估优化，扩展到了大模型网关观测与成本分析、RAG Pipeline 调优等多个方向。可以说，市场验证了我们的判断。

今天，我们将 Litefuse 开源，并且推出了一个在行业里算得上是首创的模式——极致轻量的单机单进程模式。如果你手头正好有一台 Mac（Apple Silicon）或 Linux（x64）机器，不妨试试下面这一条命令，大约 25 秒就能完成下载、安装和部署，直接从零跑起来。

curl -fsSL https://litefuse.ai/install.sh | sh

为什么要做单机版

提起 Agent 可观测平台的私有化部署，相信很多开发者都有类似的体验——几乎所有产品都要求你用 Docker 来启动。看起来简单，实际上一上手就是一堆麻烦事。没有现成的 Docker 环境得先下载安装，然后拉取对应的 Docker image，动辄几个 GB，默认从 Docker Hub 下载往往得按小时计算。哪怕你配好了国内镜像，下载也得花上好几分钟。等好不容易跑起来了，好家伙，一群容器，光看着就觉得臃肿。

这还只是第一次体验。后续的维护更是让人头大：数据存在哪里？端口映射怎么配？Docker 网络怎么搞？一系列多进程问题接踵而至。而如果你需要把这么一套系统部署在你的用户或者客户环境里，这个“笨重”的代价就更明显了——客户可能根本没有 Docker 环境，网络可能是隔离的，根本拉不了镜像。

有些场景里，用户其实只需要一个单机就能跑的系统，结果却不得不跟 Docker 和五六七八个进程打交道，复杂度甚至比被观测的系统还要高。这显然是反直觉的。

正是这种现状，促成了 Litefuse 极致轻量单进程模式的诞生——在单机场景下，让用户用最简单的方式，把 Agent 可观测与评估跑起来。

我们做了一个直观的对比：左边 Litefuse 单进程版本，只用一条命令行，从零开始到部署完成也就 25 秒左右（12 秒下载完 358MB 的安装包，11 秒解压安装）。而右边的 Langfuse 基于 Docker 需要 2 分 18 秒，慢了 5.5 倍。这还是在我们提前准备好了 Docker 环境、而且配置好国内镜像的前提下。如果没有这些准备，时间上的差距会拉开到几十倍。

点击观看演示视频：litefuse_install_demo3.mp4

Litefuse 单进程版目前支持 macOS (Apple silicon) 和 Linux (x64)。它的架构和设计要点非常清晰：

• 单一二进制包，体积压缩到了 400MB 以内，里面打包了 Litefuse 本身、Node.js 和 JVM 运行时，以及 PGlite 嵌入式 Postgres、DorisLite 嵌入式 Doris。
• 没有其他任何运行时依赖，不依赖外部的 Node.js、JVM，更不需要 Docker 环境。
• 跑起来之后只看得到一个进程。数据库 PGlite 和 DorisLite 都以库的方式加载，不需要额外的进程伺候。

为什么选择 Apache Doris 作为存储分析引擎

Agent 可观测的核心数据，说到底还是 Trace。但它和传统可观测到底有什么本质区别？答案是：几个量变引发了质变。

• MB 级长文本：Agent 依赖的 LLM 动不动就生成上千甚至上万字的文本。尤其最近新出的模型都支持百万 token 上下文了，一次请求的输入输出轻松达到 MB 级别。而在传统可观测中，文本通常只有几百字节或者 KB 级别。长文本给 Trace 检索带来了巨大挑战：用户反馈问题时往往没有 Trace ID，只有一张截图，你只能靠关键字去可观测系统里找。文本越长，传统的 LIKE 字符串模糊匹配就越慢。更让人头疼的是，长文本给查询时的内存消耗带来了冲击——想象一下，10000 行 MB 级别的长文本全部加载到内存需要 10GB，而 Agent Trace 分析时涉及的数据行数会更多。
• 跨度几天、GB 级别的超长 Trace：复杂的 Agent 任务可能会运行数小时甚至数天，由几百甚至上万个步骤组成。一个步骤产生一个 Span，加上前面提到的长文本，一个 Span 可能高达 MB。一个 Trace 的数万个 Span 加起来，轻轻松松几百 MB 甚至 GB。这个特性直接导致分析 Agent 轨迹时，获取一个 Trace 的所有 Span 成为一个苦差事——因为相关的数据分散在大量的文件里。
• 大量半结构化数据：传统 Trace 中的 JSON 数据通常只用于元数据。轮到 Agent Trace 就不一样了，主数据里也到处都是 JSON——input 和 output 字段几乎全是 JSON 格式。如果没有对半结构化数据的原生支持和优化，Trace 分析就会变得很慢，因为读取和解析 JSON 本身就是一个非常消耗资源的操作。
• 数据量成倍增长：单个 Span 变大，一个 Trace 里的 Span 变多，总数据量因此出现了数量级的变化。这种变化带来的最直接后果就是存储成本飙升。

过去几年，我们在和 MiniMax、阶跃星辰等大模型公司合作构建可观测系统的过程中，不断探索和扩展 Apache Doris 的能力边界。现在回过头来看，Doris 的能力正好精准地匹配上了 Agent 可观测的这些技术挑战。

1、成熟的倒排索引加速全文检索 10 倍

Apache Doris 早在 2023 年就开始支持倒排索引了。在 MiniMax、阶跃星辰、字节、快手、腾讯、阿里、百度、网易等数百家公司的大规模生产环境中，这项功能已经经历了充分的打磨。功能方面，它不光支持基础的关键词检索（MATCH），还支持多关键词检索（MATCH_ALL）、短语检索（MATCH_PHRASE）、前缀检索（MATCH_PHRASE_PREFIX）、短语词距（SLOP）、正则检索（MATCH_REGEXP）、多字段检索（MULTI_MATCH）等等。分词器方面支持英文、中文、中英文混合（IK、UNICODE、ICU 等）。还支持 BM25 相关性打分和排序。从性能数据来看，Doris 的倒排索引已经可以支持 PB 级别的存储、百 GB/s 的实时写入、秒级检索。经过这么多生产环境的验证，它对付 Agent 可观测中的长文本检索挑战，可以说是绰绰有余。

2、延迟物化等手段降低长文本查询时的内存占用

在 MiniMax、阶跃星辰等客户的真实可观测场景中，我们已经遇到过 MB 甚至百 MB 级的长文本。Doris 在存储、检索、查询等环节为长文本做了大量针对性的优化。举个例子，可观测场景里常见的 TOPN 查询——按日志的时间排序取最新的 N 条数据。Doris 的延迟物化技术会让排序阶段只读取时间字段，直到最后确定要取的 N 条数据时，才真正去读取完整的数据。这样一来，大量的 IO、CPU 和内存开销都被省了下来。查询响应快且稳定，不会因为数据量大而出现抖动。

3、分桶、排序、索引机制实现 Trace 聚簇存储，解决超长 Trace 分析问题

Apache Doris 从设计之初就为面向用户的实时分析设计了分区分桶、数据排序等机制。数据按 user id hash 分桶分散到不同服务器，文件内部再按 user id 排序。这意味着一个用户的数据尽量集中在同一台服务器、同一个数据文件的相邻区域。用户做查询时，它的数据局部性表现得很好，能很快拿到结果，同时全局并发很高。

这个机制对应到 Agent 可观测领域，恰好可以用来优化超长 Trace 的分析。我们可以把 Trace 数据按照 trace id hash 分桶分散到不同的服务器，数据文件内部再按 trace id 排序，并对 trace id 建立前缀索引。这样一来，Agent 轨迹分析时，获取一个超长 Trace 的所有数据，再也不用在很多分散的服务器和文件里大海捞针了。系统可以很快找到对应 hash 的服务器，在数据文件中定位到 trace id 的范围，通过范围扫描就能迅速拿到结果。思路很直接，效果也很实在。

4、VARIANT 数据类型原生支持和优化半结构化 JSON 数据的存储分析

Apache Doris 为半结构化 JSON 数据专门设计了一个名叫 VARIANT 的数据类型。它的工作机制是：写入时自动识别 JSON 数据里的字段名和类型，把它们拆分成子列，然后采用列式存储。这么做有两个显而易见的好处：一是压缩率上去了，存储空间降下来了；二是查询时只需要读取相关字段的那几个子列，数据读取量大幅减少，而且省去了耗时的 JSON 解析过程。实测下来，查询速度通常能提升 10 倍。对于 Agent 可观测中 input、output 字段里海量的 JSON 数据来说，VARIANT 的效果尤其明显，因为 input 和 output 比 metadata 长得多，列式存储和行式存储的差距会被进一步放大。

5、存算分离架构加上列式存储，存储空间和成本降低 75% ~ 80% 以上

过去几年，Apache Doris 在降低存储空间和成本方面做了大量优化。列式存储加上 ZSTD 压缩，同样的数据用更少的空间就能存下来。存算分离架构则更进一步：数据不再需要在本地磁盘上存多个副本，而是存在对象存储里，只需要存 1 份而不是 2-3 份。光这一项，存储空间就降了 50% 以上。如果再考虑到对象存储本身的成本仅为本地磁盘的 25% ~ 50%，那整体成本就能降 75% 到 88%。而且，存算分离架构还能降低数据写入时的成本，因为数据只写 1 份，不需要多个副本同时消耗计算和 IO 资源。

值得多说一句的是，Langfuse 背后的 ClickHouse 在开源版本中并不支持存算分离架构。用户只能用本地磁盘多副本来保证可靠性，代价就是多份存储空间带来的额外成本。而 Apache Doris 在开源版本中就支持存算分离架构，用户可以免费享受到 75% 到 88% 的成本降低。这一块的优势是相当明显的。

现在就加入社区

基于以上的这些原因，Litefuse 选择基于 Langfuse 和 Apache Doris 来构建。在 Langfuse 已有的丰富功能之上，借助 Doris 来优化存储成本和分析性能，同时推出极简的单进程模式来简化整体架构和维护成本。

目前，Litefuse 已经在 GitHub 上开源，采用 MIT 协议。如果你觉得这个项目有价值，欢迎到 GitHub 上点个 Star。源码已托管在 GitHub，你也可以直接访问官网了解完整信息。

在你自己的 macOS（Apple Silicon）或 Linux（x64）服务器上，一行命令加上大约 25 秒，就能立刻跑起来：

curl -fsSL https://litefuse.ai/install.sh | sh

如果不想自己动手部署，也可以直接使用云端服务。Litefuse 提供了免费额度，注册即用。

Litefuse 开源只是一个新的起点。接下来，一方面我们会继续在架构层面下功夫，进一步提升性能、降低成本；另一方面，会在 Agent 评估层面持续增强产品能力，真正帮助开发者更高效地评估和迭代自己的 Agent。