Doris原生Agent可观测平台Litefuse发布：实时监控与性能优化权威指南

你的 Agent 其实是个黑盒

排查传统软件的问题，翻翻日志、看看报错栈、尝试复现一下，基本就能定位。但 Agent 的工作方式，完全是另一回事。

一次完整的 Agent 执行，链路可能横跨多个环节：用户输入 → 意图理解 → 上下文检索 → Prompt 动态拼装 → 大模型推理 → 工具调用 → 结果整合 → 输出。

每一个环节都可能出问题，但诡异的是，单独审视任何一个环节，它看起来又没有异常。

更棘手的是，同样一句用户指令，换个上下文、换个模型版本、甚至温度参数稍微波动一下，最终的输出就可能天差地别。

Agent 犯错，很少是系统崩溃那种“硬伤”，更多是在某个语义角落悄悄产生了偏差。这种偏差，在你的监控大盘上，可能连一丝涟漪都不会泛起。

于是，很多团队发现 bad case 的方式，不是靠监控告警，而是靠用户投诉。这件事本身就挺能说明问题。

一位做 AI 客服的朋友曾提到，他们团队三个工程师，每周要花两天时间手工翻看对话记录来排查问题。不是不想自动化，而是市面上根本没有趁手的工具。

他们尝试过传统的 ELK 技术栈，结果搜索慢、缺乏语义理解能力、更看不到完整的 Agent 执行链路。用他的话说：“就像在用望远镜找一根针，就算找到了，也搞不清楚针为什么会在那里。”

这个普遍存在的痛点，正是 Litefuse 想要解决的核心问题。

在深入探讨 Litefuse 之前，有必要先厘清一个关键概念——EDD，即评估驱动开发。

大家对 TDD（测试驱动开发）都很熟悉：写测试、跑用例、代码通过、重构。这套方法论在传统软件开发中久经考验。

但到了 Agent 领域，TDD 只能保证代码逻辑不出错，却无法保证 Agent 的“言行”是否得当。

Agent 的核心质量关切点变了：回答是否准确？工具调用是否正确？任务路径是否合理？上下文有没有被污染？

这些问题，传统的单元测试很难覆盖。

EDD 的逻辑则不同：先观测 Agent 在真实环境中的运行表现，然后用评估器对输出进行打分，找出 bad case 并定位根因。改进之后，再用同一批数据集验证效果，确认分数提升后再上线。

听起来很直接，但这个闭环背后需要一整套基础设施支撑：Trace 采集、可视化分析、数据集管理、评估器配置、实验对比……每一块单独实现都不算太难，难的是将它们无缝串联成一个流畅的工作流，并且让算法工程师、产品经理、数据分析师都能轻松使用。

而 Litefuse 所做的，正是将这个闭环产品化。

Litefuse：Doris 原生 Agent 可观测平台

谈到 Litefuse 的底层技术选型，这一点值得深入展开，因为它正是 Litefuse 区别于同类产品的关键所在。

Litefuse 选择了 Apache Doris 作为其核心数据引擎，而非行业中更常见的 ClickHouse 加 PostgreSQL 组合。

这个选择带来了三个显而易见的优势：

首先是存储成本。

在实际的 Agent 对话数据测试中，对于短对话场景，Litefuse 比 Langfuse 节省了 65% 的存储空间；而在长对话和超长对话场景下，节省幅度更是达到了 88%。

其背后的原理在于 Doris 的 VARIANT 数据类型。Agent 的输入输出大多是 JSON 格式，VARIANT 类型能够自动将 JSON 拆解为子字段进行列式存储，从而充分利用列存的高压缩率优势。对于非 JSON 的文本数据，也能自适应降级为字符串存储，无需开发者额外处理。

再加上 Doris 的存算分离架构，数据只需写入一次、存储一份，避免了多副本冗余，使得存储空间和写入计算资源都得以减半。

数据最终落在对象存储或 HDFS 这类成本更低的介质上，综合下来，成本优势就非常明显了。

对于一个拥有几万月活的 Agent 产品来说，这 88% 的节省意味着什么？

意味着原本只能保存一个月的 Trace 数据，现在可以保存近九个月。或者说，在同样的预算下，你可以运行更多的 Agent 实例，进行更密集的效果评估。

其次是部署架构。

Langfuse 的标准部署需要 6 个组件：Web 服务、Worker、Redis、MinIO、PostgreSQL、ClickHouse。每一个组件都需要运维，也都有出故障的风险，在私有化交付场景下，这套架构的负担相当重。

Litefuse 利用了 Doris 的实时写入和服务端 group commit 能力，直接移除了 MinIO 这个写入缓冲层，使得写入链路更短，数据实时性更高。同时，用 PostgreSQL 的插件替代了 Redis 的异步队列功能。整体组件数量从 6 个压缩到 3 个，单机版甚至能合并为单进程形态，一台机器、一个进程就能处理 TB 级数据。

对于众多中小团队和强调简易部署的私有化场景而言，这种简化具有实质性的意义。

第三是文本检索速度。

Agent 观测中有一个高频操作：当用户反馈了一个 bad case，你需要根据对话内容快速定位到对应的 Trace。

Langfuse 底层的搜索依赖于数据库的 LIKE 操作，数据量一大就会触发全表扫描，速度慢且消耗资源。

Doris 从 2023 年开始支持倒排索引，使得搜索 Trace 中的输入输出文本能够实现秒级返回。实测表明，其速度比 LIKE 方式快 5 到 10 倍。

MiniMax、字节跳动、快手、腾讯...这些公司已经在 PB 级别的生产环境中大规模使用了该能力，其稳定性得到了充分验证。

一句 Prompt 就能接入

在易用性方面，Litefuse 兼容 Langfuse SDK，并支持 OpenAI SDK、Anthropic SDK、LangChain、Dify 等超过 100 个 AI 生态组件，老用户的迁移成本极低。

对于 Hermes、OpenClaw、Claude Code 这类通用 Agent，Litefuse 还做了专门的增强支持。

以 Claude Code 为例，当你给它下达一个任务：

research and write a report about agent observability and evaluation

在 Langfuse 中，你看到的可能只是一系列模型调用请求和响应记录。

而在 Litefuse 中，你能看到完整的执行步骤：用户消息、思考过程、每一步的文本响应、工具调用细节，以及所有元数据。这些信息被统一组织在 claude_code 层级字段下，极大方便了后续的查询和评估。

完整的 Agent Trace 与单纯的模型调用记录，对开发者的价值差异巨大。前者能让你真正理解 Agent 做出某个决策的原因，而这正是定位 bad case 根因的前提。

还有更简单的接入方式：只需将下面这条指令交给你的 Agent：

Read https://litefuse.ai/SKILL.md and follow the instructions to install and configure Litefuse.

Agent 便会自动读取配置文档并完成接入，全程无需你编写任何代码。

这个设计本身，就充满了 AI Native 的体验感。

结语

Agent 时代最大的工程挑战，已经悄然从系统能否跑起来转变为Agent 是否做对了事。前者有数十年的工具和方法论积累，而后者的系统性解法，现在才刚刚开始浮现。

Litefuse 所做的事情并不神秘：清晰记录 Agent 的执行过程，顺畅构建效果评估的闭环，同时把底层存储和检索的成本降下来。

但将这三件事同时做好，并且巧妙地利用 Apache Doris 将它们高效串联，则体现了真正的工程价值。

目前，Litefuse 的 SaaS 服务（litefuse.cloud）已经上线，提供 10 万条数据存储 1 个月的免费额度。此外，在阿里云 SelectDB 上也可以开通独享实例。

如果你的团队正在从事 Agent 开发，现在或许是一个不错的试水时机——毕竟，所有无法被量化的优化，最终都可能只是感觉良好而已。