LangSmith vs Helicone vs Langfuse：全面对比

这三者常被归为“LLM 可观测性”工具，但它们从不同角度解决问题：Helicone 是一个代理——只需更改一次 base URL 即可记录每次调用，并附带缓存和限流功能。Langfuse 是开源追踪 + 评估平台——通过 SDK 插桩，可自托管，框架无关。LangSmith 是 LangChain 原生平台——如果你使用 LangChain/LangGraph，它能提供最深的追踪，闭源。决策主要取决于*你愿意做多少插桩*以及*你的数据必须存放在哪里*。

概览

HeliconeLangfuseLangSmith

集成方式代理（更改 base URL）SDK / 装饰器 / OTelSDK；LangChain 自动集成 设置工作量几分钟几小时几分钟（LangChain）/ 几小时（其他） 开源 / 自托管核心开源，可自托管✅ 完全开源（常见路径）❌（存在企业版自托管） 追踪深度请求级别完整嵌套追踪完整嵌套追踪（LangChain 最佳） 评估 / 数据集基础评分✅ 强大✅ 强大 提示管理✅✅✅（Hub） 额外功能内置缓存、限流、密钥管理—深度 LangGraph 调试 风险代理位于请求路径中自行运行或使用其云服务供应商 + 生态锁定

真正的区别

Helicone：无需修改应用代码即可实现可观测性。 将你的 SDK 指向 Helicone 的网关，带上项目头信息，每个请求/响应/延迟/成本都会被记录——无论使用哪个提供商、哪个框架，甚至是你无法控制的代码。代理位置还支持响应缓存（相同提示免费服务）和按用户限流。代价是：第三方（或你必须运维的网关）位于关键路径上，并且由于它看到的是请求而非你的代码，追踪深度较浅——它知道你发起了 6 次 LLM 调用，但不知道它们构成了一个包含检索步骤的代理运行。（如果你在广泛评估代理，也可以比较网关类别：LiteLLM vs Portkey。）

Langfuse：自托管或保持中立时的默认选择。 SDK 插桩（Python 中的 @observe 装饰器，OTel 支持）能生成真正的嵌套追踪——代理运行 → 检索 → LLM 调用——此外还有数据集、LLM 作为评判的评估以及提示版本管理。完全开源，提供 Docker-compose 自托管路径，并已实际用于生产环境，因此成为欧盟/受监管环境（提示数据不能离开基础设施）的标准答案。代价是：你需要编写插桩代码，自托管意味着要运维 ClickHouse 等组件。

LangSmith：在 LangChain 生态内无与伦比，在生态外表现平平。 设置两个环境变量，所有链/代理/LangGraph 节点即可零代码变更地追踪——在 LangSmith 的追踪视图中调试行为异常的 LangGraph 状态机是该类别中最佳体验。数据集、评估和提示中心都很成熟。在 LangChain 之外，你需要像其他工具一样手动插桩，并且你购买的是框架供应商的闭源产品——如果你致力于该技术栈，这没问题；否则就是真正的耦合。（更深入的 LangSmith 与 Langfuse 工作流对比：LangSmith LLM evaluation workflow。）

决策规则

你的技术栈是 LangChain/LangGraph → LangSmith（零成本的追踪质量值得）。

数据必须留在你的基础设施 / 需要开源 → Langfuse。

希望今天就能记录日志和成本可见性，无需代码更改 → Helicone；后续如果需要深度追踪，再加 Langfuse。

多提供商网关功能（缓存、限流、密钥管理）与日志同等重要 → Helicone，或者将网关与 Langfuse 配对使用。

它们也可以组合使用：一个常见的生产栈是 Helicone（或 LiteLLM）作为网关层，加上 Langfuse 进行应用级追踪和评估——代理提供网络视图，SDK 提供语义视图。

FAQ

哪个最便宜？ 三者都有可用的免费层；在规模下，定价模式不同（按追踪、按请求或按席位），且经常变化——请根据当前定价页面估算你的调用量，而不是相信博客表格。

原型阶段需要这些吗？ 一个日志装饰器和电子表格就能走很远。当你开始*比较*运行结果（评估、回归、提示版本）时，才需要采用平台——那时临时日志就会崩溃。

OpenTelemetry？ Langfuse 和越来越多的工具接受 OTel GenAI spans；如果你已有可观测性基础设施（Datadog/Grafana），在采用独立工具前先检查 OTel 路径。

---

*最后更新：2026 年 6 月。*