2026 年 4 月 23 日发布 Litefuse：去掉运维负担的 Agent 可观测性与评估平台
Litefuse 是一个轻量、agent-native 的 Langfuse fork。两个进程替代六个进程，存储占用减少约 80%，内置支持主流开源 agent，并完全兼容 Langfuse SDK。
今天我正式发布 Litefuse：一个开源的 agent 可观测性与评估 平台，基于 Langfuse fork 而来。
一句话介绍：Litefuse 保留了 Langfuse 的开发者体验，但运维模型更简单、存储成本更低，并且内置了面向 agent 的支持。它兼容 Langfuse SDK，所以如果你已经完成了埋点，只需要把现有代码指向 Litefuse endpoint，就可以继续使用。
这篇文章讲的是 Litefuse 为什么存在，以及它短期和长期想成为什么。
为什么 fork？
Langfuse 是一个很优秀的项目，Litefuse 能成立，很大一部分也建立在它的基础之上。我很感谢 Langfuse 团队在开源世界里做出的工作。
我选择 fork，是因为我想为自托管部署选择一条不同的取舍曲线，也因为我认为 agent 工作负载应该被当作一等公民，而不是 LLM 可观测性的一个特殊分支。Langfuse 的目标更宽，这没有问题；Litefuse 则有意更窄。
fork 给了我空间，让我可以押注这个更窄的方向，并在架构、存储和开箱即用的集成上做出不同选择。
“lite” 到底轻在哪里
Litefuse 里的 “Lite” 主要体现在两个具体地方。
1. 更少的组件
一个生产级 Langfuse 部署会运行 六个 进程：Langfuse web、Langfuse worker，再加上 Redis、MinIO、Postgres 和 ClickHouse。对于一个功能完整的 AI agent 可观测性与评估平台来说，这是合理的架构，但当你需要部署、升级，或者凌晨两点排查问题时，它也是一套不小的机器。
Litefuse 把它收敛成 两个 进程：一个 Litefuse 进程，加上作为后端存储的 Apache Doris。Doris 同时承接原本由 ClickHouse 负责的分析查询，以及原本由 Postgres 负责的元数据存储，并以单一集群的方式横向扩展。
结果是：需要学习的服务更少，需要预案的故障模式更少，也少了很多挡在团队和 agent trace 之间的运维工作。
2. 少得多的存储
Apache Doris 的列式存储和压缩机制非常适合 trace 与 observation 数据。这类数据重复度高、基数高，并且绝大多数读取都是分析型查询。Litefuse 在存储同等 trace 量时，相比经典 Langfuse 部署模型可以减少 约 80% 的空间占用。
规模小的时候，这只是一个不错的优化。等 agent trace 开始成为可观测性账单里的大头时，这就会变成关键差异：因为每次 agent run 都会产生几十条 observation，可观测性要么成为显然值得做的事，要么变成每个季度都要有人解释的一项成本。
开箱即用的 agent 支持
Litefuse 的另一半判断是：主流开源 agent 应该得到 内置 支持，而不是让用户自己拼 SDK、埋点和 exporter。
Litefuse 会为 Claude Code、OpenClaw、Hermes Agent 等 agent 提供一等集成。这意味着：当你把这些 agent 接入 Litefuse 时，可以直接获得结构化 trace、工具调用可见性、agent graph 视图和成本追踪，而不需要自己写 instrumentation 代码，也不需要研究该用哪个 OTEL exporter。
这是我认为今天还没有被充分服务的地方。很多可观测性平台把 agent 当成”一个会循环的 LLM 调用”。Litefuse 则把它当作它真实的样子：一个有状态、会分支、会使用工具的系统，它的正确性和成本都取决于每一步的决策。Litefuse 的集成会围绕这个形态来设计。
兼容 Langfuse SDK
Litefuse 保留了 与 Langfuse SDK 的 wire compatibility。如果你的代码已经用 langfuse、langfuse-python 或 langfuse-js 做了埋点，只需要更换 endpoint 就可以继续运行，不需要重新埋点、不需要迁移桥，也不需要重写。
这是一个有意为之的长期承诺。Langfuse 生态里的 SDK、集成、文档和示例代码都很有价值，我不想要求用户把这些全部放弃。Litefuse 是一个不同的运维和产品方向，但它站在这个生态之上，也会继续兼容它。
实际含义是：
- 现有 Langfuse 用户可以在不改应用代码的情况下评估 Litefuse。
- Langfuse SDK 里的新集成也会流向 Litefuse 用户。
- 为 Langfuse 构建的框架集成，比如 LangChain、LlamaIndex、OpenAI Agents 等，也可以在 Litefuse 上工作。
Litefuse 接下来会走向哪里
短期来看，上面四点就是今天尝试 Litefuse 的理由：更轻的运维、更轻的存储、内置 agent 集成，以及 SDK 兼容性。
长期来看，我押注的是一个更具体的方向：agent 可观测性和评估驱动开发，应该被当作独立的一等问题来解决。 不是”带一些 agent 功能的可观测性”，而是从一开始就围绕 agent 团队真正需要回答的问题来设计平台：哪些推理路径会导向哪些结果，哪些 subagent 会随时间漂移，如何把每一条糟糕的生产 trace 自动变成回归测试，如何判断本周的模型升级到底让你的 agent 在真实工作负载上变好了还是变差了。
下面两篇配套文章会更深入地讨论 Litefuse 所围绕的核心想法：
如果这些方向和你正在做的事情有关，最快了解 Litefuse 的方式是：
我很希望听到你的反馈：哪些地方好用，哪些地方不好用，以及你希望它接下来具备什么能力。这只是第一天。