Opik vs Langfuse 深度对比：LLM 可观测性工具边界评测

两者都勾选了同一个框

如果你是第一次给 LLM 应用添加可观测性，最简单的方案就是在 API 调用前加一行 print() 语句。当你还是唯一在测试它的人时，这就够了。

自然的下一步是把 print() 语句换成一个真正的 tracing SDK。你包装一下客户端，发起一个调用，UI 上就能看到一个包含 prompt、响应和耗时的 span。这看起来已经解决了——直到你的团队超过一个人、超过一个 prompt、手动测试也超过了一个人。

真正的摩擦点就在这个时候显现出来：条件性 prompt 逻辑、在上线前 diff 两个 prompt 版本的方式、在用户投诉前捕获应用出错调用的方式，以及针对危险输出的实时 guardrail。"它产生了一条 trace" 无法覆盖以上任何一点。令人沮丧的是，这个问题不会大声地失败——大多数开源、自托管的 LLM 可观测性工具从它们的着陆页看都像是可以互换的，因为它们都勾选了同样的三个框：开源、自托管、追踪你的调用。

Opik（由 Comet ML 构建）和 Langfuse 是这个框里最常用的两个工具。于是我们测试了真正的边界：我们在两个平台上独立地构建了完全相同的 prompt——一个支持分流 agent，会根据 VIP 客户改变语气并列出他们的待处理工单——然后把两次运行并排对比。

两个平台在 prompt 模板化上遇到了完全相同的瓶颈——都不支持真正的条件逻辑，只有扁平化的变量替换。

两者都独立确认，光有 Playground 不会产生 trace——只有调用包装了 SDK 的客户端才会。

它们在 prompt 版本管理上出现了明显分歧：Opik 提供了真正的 diff 视图和环境标签，Langfuse 的版本历史两者都没有。

它们测得的客户端开销在性质上不同，而不仅仅是数字上的差异——而且这两个数字来自两次独立的测试会话，不是一次共享的基准测试。

两者都有一个功能相同但名称不同的特性——对实时生产流量自动评分。

它们已经漂移到了真正不同的领域：Opik 的 guardrails 和回归测试套件，与 Langfuse 的阈值告警。

而且截至五个月前，它们已经不能再作为两个独立创业公司来进行比较了——Langfuse 在 2026 年 1 月被 ClickHouse 收购。

完整分析如下。

它们遇到完全相同瓶颈的地方：模板化

两个平台的 prompt 编辑器都只能做扁平的 {{variable}} 替换——没有 {% if %}，没有 {% for %}。我们需要 VIP 客户分支和渲染后的待处理工单列表，但在两个平台上我们都得在 prompt 看到它之前自己把那个逻辑拍平成纯文本，只保留简单字段（如 {{company}}）作为真正的模板变量。

两个产品都没有隐藏这一点——这是一个真实的、共同的設計决策，不是其中任何一个的 bug。如果你的 prompt 需要分支逻辑，两个平台都会把那个逻辑推回到你自己的代码里（一个预渲染步骤），而不是放进模板本身。

它们再次遇到完全相同瓶颈的地方：Playground 不会追踪

这一点足够让我们在每个平台上反复确认。用 Opik 的 Playground 运行一个 prompt 后，它的 Logs 标签页显示"No traces yet"。用 Langfuse 的 Playground 运行一个 prompt 后也是同样的结果——直到我们调用 SDK 包装的客户端才出现 trace。在两者上，"在 UI 中尝试"界面和"从中获得 trace"界面是两个分离的东西，如果你只在 Playground 里点点 before 把 SDK 接入，就很容易忽略这一点。

它们真正分歧的地方：prompt 版本管理

Opik 有一个真正的"Diff"按钮——编辑一个 prompt 创建 v2，它会用红色删除线显示旧 system message，旁边用绿色显示新的。它还有一个"Deploy to"菜单，可以给特定版本打上 production、staging 或 development 标签，用彩色徽章标识。

Langfuse 也有环境标签（production / latest），但我们在它的版本历史 UI 中找不到任何 diff 或比较控件——每个版本都在一个扁平列表里，比较两个版本意味着同时打开两者靠自己并排阅读。

数字真正不同的地方（以及为什么不应当堆叠对比）

我们测量了两个平台的客户端 SDK 开销——但是在两次独立的基准测试会话中，作为两篇不同的帖子的一部分，在不同日期运行的，每次都有自己直接对接提供商的基线。这很重要：网络状况每次会话都不同，所以这两个数字不是来自一次共享的交织测试，不应该被当作单一排名表来解读。

在明确说明这一注意事项后：

Comparison with other platform can be found at AcruxCore

Opik 的 track_openai() 包装器带来的开销在其自身测试会话中清除了噪声基线。Langfuse 的 instrumentation，在其自身独立测试会话中，完全没有清除那个基线——其"代价"在统计上为零。这两个都是关于客户端 instrumentation 的真实发现，不是关于哪个产品比另一个"更快"，因为两者都不会像代理式工具那样通过网关路由调用。

同一理念，不同名称：对生产流量自动评分

两个平台都有一个做同样底层工作的特性——在流量到达时对其进行评分，无需人工审核步骤——但名称和 UI 完全不同。

Langfuse 的 LLM-as-a-judge Evaluators 会引导你编写一个 eval 模板：一个评分 prompt、一个要运行的模型、以及它读取的 trace 变量。

Opik 的 Production 下的 Online Evaluation 页面让你创建一个规则，对每条匹配的 trace 在到达时进行评分。

如果一个平台中立的特性列表只检查"在线评估"或"LLM-as-a-judge"这个名字，就会漏掉两个产品实际上都提供了这个功能。

它们真正分道扬镳的地方：guardrails 与告警

Opik 附带了一个 guardrails 面板——一个主题限制检查，带有灵敏度滑块和逗号分隔的受限主题列表，外加一个 PII（个人身份信息）检查，会标记信用卡号码、电话号码和电子邮件地址等类别，每个都有自己的阈值。它还有一个专用的 Test suites 对象用于上线前的回归测试，与 Experiments 功能分开——从 CSV/JSON 文件或 SDK 导入用例，每个用例都有预期输出和评分方法。

Langfuse 没有提供任何类似的东西。它有的是 Monitors——在成本、质量或延迟上设置一次阈值，当指标超出范围时，将通知路由到 Slack、webhook 或 GitHub Action。

两者都没有对方的功能。如果你需要阻止一个包含 PII 的调用到达用户，Langfuse 今天什么都没有。如果你想在 P95 延迟上升时收到 Slack 通知，Opik 今天什么都没有。

它们背后是谁，各自有多大

这是我们第一次测试这两个产品以来情况发生变化的地方。下面的数字截至本周，从每个项目的 GitHub API 直接拉取。

两个仓库都是在 2023 年 5 月的一周内创建的，至今仍在每天收到提交——这不是一个"其中一个被抛弃了"的故事。Langfuse 在每个原始计数上都有更大的社区足迹，包括明显更高的开放 issue 数量，这可能意味着更活跃的使用暴露了更多边缘 case，或者是一个更小的团队在跟上分类工作——我们没有深入研究 issue 关闭率来判断是哪种情况。

更大的区别是谁拥有每个项目。Opik 是 Comet ML 内部的一个产品，Comet ML 是一家总部位于纽约的 ML 平台公司，成立于 2017 年，披露的种子轮融资为 680 万美元（2018 年、2020 年），此后没有再披露任何信息。Langfuse 曾经是一家独立的、Y Combinator 支持的创业公司——直到 2026 年 1 月 16 日被 ClickHouse 收购，同一天 ClickHouse 宣布了 4 亿美元的 D 轮融资，估值 150 亿美元。两家公司都公开承诺将继续保持 Langfuse 开源和可自托管。

对于选择平台来构建的读者来说，这是一个值得在特性列表之外认真权衡的真实信号：一个工具是一家更小、更稳定的公司的副属产品；另一个刚刚成为一个更大、刚刚充裕起来的基础设施公司内部的集成点。两者都不是天生就更安全的选择——但它们是不同的赌注。

我们还通过各自的 sitemap 比较了每个项目的文档覆盖范围，有一个注意事项：Langfuse 的 sitemap 覆盖了其整个域名（博客、更改日志、学院和文档合在一起——822 个 URL，其中只有 112 个严格属于 /docs），而 Opik 的文档位于 Comet 的站点下，其 sitemap 仅限于该文档子树（709 个 URL）。所以"709 对 822"不是一个苹果对苹果的文档深度比较——更接近于"Opik 的文档 alone"对"Langfuse 的文档加其博客、更改日志和手册的组合"。

我们没有宣布赢家

我们挑选了七个点，不是两个平台各自的完整特性列表，也没有给每一行都加上对称的"优点/缺点"——有些事情确实是一边倒的（两个平台都没有为了看起来公平而添加一个虚假的制衡力量）。模板化和 Playground-tracing 是真正的平局。版本管理有利于 Opik。开消数字彼此不可比，只能与各自的基线比。Guardrails/测试套件和 Monitors/告警是两个团队在不同的方向上构建，不是一个落后于另一个。

如果你今天在两者之间选择，特性列表会指向对你的团队更重要缺口的那个——guardrails 和回归测试，还是阈值告警。所有权问题是去年还不存在的问题，现在可能和任何一个特性列表一样重要。

来源：GitHub 上的 comet-ml/opik 和 langfuse/langfuse（检查日期：2026-08-10）；ClickHouse 的收购公告；Langfuse 自己的"加入 ClickHouse"帖子。产品截图和动手发现来自我们对两个平台的独立测试。