Litefuse 开源发布：一行命令部署 Agent 可观测与评估平台，单机版比 Langfuse 快 5.5 倍

Litefuse 正式开源，并推出轻量的单机单进程版本。开发者只需一行命令，即可在约 25 秒内完成 Litefuse 的下载、安装和部署，快速搭建 Agent 可观测、Trace 分析与效果评估平台。

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

在前一篇文章《Litefuse 正式发布：Agent 可观测与效果评估，比 Langfuse 成本低 88%》中，我们介绍了 Agent 时代为什么需要 EDD（Evaluation Driven Development，评估驱动开发）。

通过“观测—评估—优化”的闭环，EDD 可以帮助开发者应对大模型幻觉、路径规划走偏、工具调用失败、上下文腐化等 Agent 应用中的不确定性问题。Litefuse 则将 Trace 采集、可视化分析、数据集管理、实验运行与评估等能力产品化，帮助开发者更高效地构建和优化 AI Agent。

过去一个月，Litefuse SaaS 服务 litefuse.cloud 受到了众多 Agent 开发者欢迎，注册用户已超过 200 人，并被应用于 Agent 评估优化、大模型网关观测与成本分析、RAG Pipeline 调优等场景。

现在，Litefuse 正式开源，并推出业界首个轻量的 Agent 可观测单机单进程版本。

为什么 Agent 可观测平台需要单机版？

很多开发者在体验 Agent 可观测平台时，都会遇到类似问题：大多数私有化部署方案都依赖 Docker，看起来简单，实际使用却并不轻量。

如果本地或客户环境中没有现成的 Docker 环境，就需要先安装 Docker；随后还要拉取数 GB 的镜像。如果直接从 Docker Hub 下载，可能需要等待很长时间；即使配置国内镜像源，也通常需要数分钟。

部署完成后，用户还会发现系统启动了多个容器和进程。对于只是想快速体验 Agent Trace 采集、LLM 调用分析、评估实验和 RAG 调优的开发者来说，这样的部署方式过于笨重。

更大的问题出现在后续维护中：

• 数据存在哪里？
• 端口如何映射？
• 多个容器如何升级？
• 客户环境没有 Docker 怎么办？
• 网络隔离环境无法拉取镜像怎么办？

很多场景中，用户只需要一个能在单机上运行的 Agent 可观测系统，却不得不维护 Docker、数据库和多个服务进程，复杂度甚至超过了被观测的 Agent 应用本身。

这正是 Litefuse 推出单机单进程版本的原因：让开发者用最简单的方式，在单机场景下快速运行 Agent 可观测与评估平台。

Litefuse 单机版：一行命令，约 25 秒完成部署

Litefuse 单进程版本支持 macOS Apple Silicon 和 Linux x64。开发者只需执行下面一条命令，即可完成下载、安装和部署：

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

在演示视频中，左侧的 Litefuse 单进程版本只使用 curl 和 sh 命令，从零开始约 25 秒完成部署，其中 12 秒下载 358MB 安装包，11 秒完成解压安装。

右侧的 Langfuse 基于 Docker 部署，即使提前准备好 Docker 环境并配置国内镜像源，也耗时 2 分 18 秒，部署时间约为 Litefuse 的 5.5 倍。如果环境中没有 Docker 或镜像下载较慢，耗时差距会进一步扩大。

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

Litefuse 单进程架构有什么特点？

Litefuse 单机版的目标是轻量、开箱即用、易部署、易维护。

它具备以下特点：

1. 一个二进制包，体积不到 400MB

Litefuse 单机版将核心程序、Node.js 运行时、JVM 运行时、PGlite 嵌入式 Postgres、DorisLite 嵌入式 Doris 都打包在一个二进制包中。

开发者无需分别安装数据库、运行时或其他依赖。

2. 无需 Docker，无需外部运行时依赖

Litefuse 单机版不依赖 Docker，也不需要用户提前准备复杂环境。

这对于私有化部署、PoC 测试、客户环境交付、离线环境部署都更加友好。

3. 运行时只有一个进程

PGlite 和 DorisLite 都以库的方式加载，不需要额外数据库进程。

这意味着 Litefuse 在单机场景下更容易启动、维护、升级和排查问题。

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

Agent 可观测的核心数据是 Trace，但它与传统可观测数据有很大不同。

传统可观测系统主要处理日志、指标和调用链，而 Agent 可观测需要处理大模型输入输出、工具调用、Prompt、上下文、检索结果、评估数据等复杂信息。

这些数据带来了新的技术挑战。

Agent Trace 相比传统 Trace 有哪些不同？

1. MB 级长文本带来检索和查询挑战

Agent 应用依赖大模型，而大模型输入输出通常包含长文本。随着百万 token 上下文模型的出现，一次请求的输入和输出可能达到 MB 级别。

这远远超过传统可观测中几十字节或 KB 级别的文本。

长文本会带来两个问题：

第一，Trace 检索更困难。用户反馈问题时，往往没有 Trace ID，只有截图或片段信息。此时需要根据关键字在大量 Trace 中搜索对应记录。文本越长，传统 LIKE 查询越慢。

第二，查询内存消耗更高。如果一次查询加载 10000 行 MB 级文本，就可能需要 10GB 以上内存。Agent Trace 分析时涉及的数据规模往往更大。

2. 超长 Trace 可能持续数小时甚至数天

复杂 Agent 任务可能运行数小时甚至数天，由几百到几万个步骤组成。

每个步骤都会生成一个 Span，而每个 Span 又可能包含较长的输入、输出、工具调用结果和上下文信息。最终，一个 Trace 可能达到数百 MB 甚至 GB 级别。

这会导致分析 Agent 轨迹时，读取一个完整 Trace 的所有 Span 非常慢。

3. Agent Trace 中包含大量半结构化 JSON 数据

传统 Trace 中，JSON 通常只用于 metadata。而在 Agent Trace 中，input、output、tool call、retrieval result 等主数据也经常是 JSON。

如果存储引擎没有对半结构化 JSON 的原生支持，就需要在查询时频繁读取和解析 JSON，带来明显的性能开销。

4. 数据量整体提升一个数量级

由于单个 Span 更大、单个 Trace 中 Span 更多，Agent 可观测数据总量也会显著增长。

这直接推高了存储成本、查询成本和运维复杂度。

过去几年，SelectDB 团队在与 MiniMax、阶跃星辰等大模型公司构建可观测系统的过程中，不断探索和扩展 Apache Doris 的能力边界。现在，这些能力正好匹配 Agent 可观测场景中的核心挑战。

Apache Doris 如何优化 Agent 可观测性能与成本？

1. 倒排索引加速长文本检索，查询性能提升 10 倍

Apache Doris 早在 2023 年就开始支持倒排索引，并已经被 MiniMax、阶跃星辰、字节、快手、腾讯、阿里、百度、网易等公司应用于生产环境。

Doris 倒排索引不仅支持基础关键词检索 MATCH，还支持：

• 多关键词检索 MATCH_ALL
• 短语检索 MATCH_PHRASE
• 前缀检索 MATCH_PHRASE_PREFIX
• 短语词距 SLOP
• 正则检索 MATCH_REGEXP
• 多字段检索 MULTI_MATCH
• BM25 相关性打分与排序
• SQL 和 Lucene 风格检索语法

同时，Doris 支持英文、中文、中英文混合 IK、UNICODE ICU 等多语言分词器，适合 Agent Trace 中常见的中英文混合文本检索。

对于 Agent 可观测场景中的 Prompt、Response、上下文、工具调用结果等长文本，Doris 倒排索引可以显著提升检索效率。

2. 延迟物化降低长文本查询内存占用

在大模型可观测场景中，MB 甚至百 MB 级别长文本并不少见。Apache Doris 在存储、检索和查询环节都针对长文本做了优化。

例如，在可观测场景常见的 TOP N 查询中，用户通常会按照时间排序，查询最新 N 条 Trace 或 Span。

Doris 的延迟物化技术会在排序阶段只读取时间字段，等确定最终结果后再读取完整长文本内容。这样可以避免无效读取大量长文本，降低 IO、CPU 和内存消耗，使查询响应更加稳定。

3. 分桶、排序和索引机制优化超长 Trace 分析

Apache Doris 最初就是为面向用户的实时分析场景设计的，天然支持分区、分桶、排序和索引机制。

在 Agent 可观测场景中，可以将 Trace 数据按照 trace id 进行 hash 分桶，使同一个 Trace 的数据尽可能聚集在相同服务器和相邻数据区域中。

同时，数据文件内部按照 trace id 排序，并对 trace id 建立前缀索引。

这样在分析一个超长 Trace 时，系统不需要从大量分散文件中随机读取数据，而是可以快速定位到对应 trace id 的数据范围，通过范围扫描高效返回结果。

4. VARIANT 类型原生支持半结构化 JSON 分析

Apache Doris 为半结构化 JSON 数据设计了专用数据类型 VARIANT。

VARIANT 会在写入时自动识别 JSON 字段名和类型，并将其拆分成子列进行列式存储。

这样带来两个核心收益：

第一，提升压缩率，降低存储空间。

第二，查询时只需读取相关字段的子列，无需读取完整 JSON，也无需反复解析 JSON。

在 Agent 可观测场景中，input、output、metadata、tool call 等字段经常包含大量 JSON 数据。VARIANT 能够显著提升这类数据的分析性能，查询速度通常可以提升 10 倍。

5. 存算分离与列式存储降低 75% 到 88% 成本

Apache Doris 通过列式存储、ZSTD 压缩和存算分离架构，有效降低 Agent Trace 数据的存储成本。

列式存储和压缩可以减少数据占用空间。存算分离架构则将数据存储在对象存储中，不需要在本地磁盘保留 2 到 3 份副本。

这意味着存储空间可以降低 50% 以上。同时，由于对象存储成本通常低于本地磁盘，整体成本可以降低 75% 到 88%。

相比之下，Langfuse 背后的 ClickHouse 开源版本不支持存算分离架构，用户通常需要通过本地磁盘多副本来保证可靠性，带来更高存储成本。

Apache Doris 开源版本即支持存算分离，用户可以免费获得更低成本的数据存储与分析能力。

Litefuse 与 Langfuse 有什么区别？

Litefuse 基于 Langfuse 和 Apache Doris 构建，既保留了 Langfuse 在 LLM Observability 和 Agent 评估方面的丰富功能，又利用 Apache Doris 优化了大规模 Trace 数据的检索性能、分析性能和存储成本。

同时，Litefuse 推出了更适合轻量部署和私有化交付的单进程模式。

简单来说，Litefuse 的核心优势包括：

• 支持 Agent Trace 采集、分析和评估
• 支持 EDD 评估驱动开发闭环
• 支持单机单进程部署
• 无需 Docker
• 一行命令即可安装
• 基于 Apache Doris 优化长文本检索
• 原生支持半结构化 JSON 分析
• 存储成本最高可降低 88%
• 适合 Agent 评估优化、大模型网关观测、RAG Pipeline 调优等场景

Litefuse 适合哪些使用场景？

Litefuse 适合正在构建或优化 AI Agent、LLM 应用和 RAG 系统的团队。

典型使用场景包括：

Agent 可观测

采集 Agent 运行过程中的 Trace、Span、Prompt、Response、工具调用、上下文和中间状态，帮助开发者理解 Agent 为什么失败、在哪里失败、如何优化。

Agent 效果评估

通过数据集、实验运行和评估指标，持续评估 Agent 在不同版本、不同 Prompt、不同模型和不同工具链下的表现。

大模型网关观测与成本分析

分析不同模型、不同应用、不同用户的调用量、延迟、Token 消耗和成本，帮助团队优化 LLM 使用效率。

RAG Pipeline 调优

观测 Query、Embedding、召回、重排、上下文拼接和最终生成结果，定位 RAG 系统中的召回不足、上下文污染和回答质量问题。

立即体验 Litefuse 开源版

Litefuse 已经在 GitHub 开源，并采用宽松的 MIT 协议。

如果你正在构建 Agent、LLM 应用或 RAG 系统，欢迎体验 Litefuse，并给我们一个 Star。

• GitHub：https://github.com/litefuse/litefuse
• 官网：https://litefuse.ai
• SaaS 服务：https://litefuse.cloud

在 macOS Apple Silicon 或 Linux x64 服务器上，你可以通过下面一条命令快速启动 Litefuse 单机版：

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

如果你不想自己部署，也可以直接使用 Litefuse Cloud：

• Litefuse SaaS：https://litefuse.cloud
• 阿里云 SelectDB：https://www.aliyun.com/product/selectdb

Litefuse 开源只是一个新的起点。接下来，Litefuse 将继续在架构层面提升 Agent Trace 分析性能、降低存储成本，并在 Agent 评估能力上持续增强，帮助开发者更高效地评估、优化和迭代 AI Agent。