LangSmith开源替代方案：144款LLMOps自托管工具全盘点

LangSmith 是追踪和评估 LangChain、LangGraph 应用的默认选择，用起来确实顺手。但它有一个绕不开的问题：LangSmith 的服务端并不开源。SDK 采用 MIT 协议，而后端却是闭源的。对于需要出于数据隐私或合规要求进行自托管的团队，或者单纯不希望追踪数据离开自家基础设施的开发者来说，这是个硬伤。

一位开发者为此整理了一份覆盖 144 款可自行部署的 LLMOps 工具 的清单，并开源在 GitHub（awesome-llmops-platforms），试图系统性回答一个被反复问到的问题——「LangSmith 的开源等价物到底是什么？」

为什么需要 LangSmith 的开源替代

在 LLM 应用进入生产环境后，可观测性（Observability）和评估（Evaluation）几乎是刚需。你需要看到每一个链路步骤、工具调用、token 消耗和延迟，也需要在上线前对 chain 和 agent 跑评估。LangSmith 把这些能力打包得很好，但它的闭源后端意味着数据必须经过官方服务。

对金融、医疗等受合规约束的行业，或是对数据主权敏感的企业来说，追踪数据外流是不可接受的。这正是自托管开源方案的价值所在：能力对标 LangSmith，但完全跑在自己的基础设施上。

可观测性（Observability）在 LLM 应用语境下，指的是对模型调用链路的全程追踪能力——包括每一步的输入输出、工具调用序列、token 消耗量、推理延迟以及中间状态。与传统软件的日志监控不同，LLM 应用往往涉及多步骤的 chain 或自主决策的 agent，单条请求可能触发数十次嵌套调用，出错时极难定位根因。OpenTelemetry 是目前该领域的通用埋点标准，许多开源工具都以此为基础构建追踪后端，从而实现与语言和框架无关的链路采集。评估（Evaluation）则是另一个维度：LLM 的输出具有随机性，传统的单元测试难以覆盖，需要借助专门的评估框架对准确性、相关性、安全性等指标进行量化打分，通常结合人工标注或另一个 LLM 充当评判者（LLM-as-judge）的方式完成。

九大类别：144 款工具的全景地图

这份清单把工具按功能拆成了 9 个类别，覆盖了 LLMOps 从开发到上线再到安全防护的完整生命周期。

一体化平台（21 款）

这是最接近 LangSmith 的一类，把追踪、评估和提示词管理整合在一起。代表项目包括 Langfuse、MLflow、Opik、Agenta、LangWatch 等。如果你想一步到位替换 LangSmith，优先从这一类里挑选。

可观测性与追踪（26 款）

专注于让每一个 chain 步骤、工具调用、token 计数和延迟都变得可见。这类工具解决的是「黑盒」问题——没有追踪，调试 agent 就等于盲人摸象。

评估与测试（33 款）

数量最多的一类，用于在交付前对 chain 和 agent 进行评估，代表项目有 promptfoo、deepeval、openevals 等。随着 agent 复杂度上升，自动化评估正从「可选项」变成「必选项」。

提示词管理（9 款）

把提示词从代码里剥离出来做版本管理，类似 LangChain Hub 的思路。提示词即配置，独立版本化后更利于团队协作和迭代回溯。

护栏与红队（9 + 5 款）

护栏（Guardrails）和红队（Red teaming）两类合计 14 款，用于捕捉提示注入、越狱攻击和不良输出。随着 LLM 应用面向真实用户，安全防护逐渐成为生产部署的必修课。

提示注入（Prompt Injection）是 LLM 应用特有的安全威胁：攻击者通过在用户输入中嵌入特定指令，试图覆盖或绕过系统提示，使模型执行未授权的操作。护栏（Guardrails）工具在模型输入和输出两侧设置检测层，可以拦截包含恶意指令的请求，也能过滤涉及敏感话题、个人信息或有害内容的模型回复。红队（Red Teaming）则是一种主动式安全测试方法，借鉴自网络安全领域：通过系统性地构造对抗样本或越狱提示，提前发现模型和应用的脆弱点，而非等待真实攻击发生。随着 LLM 应用的服务对象从内部测试扩展到真实终端用户，这两类工具正从研究性工具演变为生产部署的标配防护层。

网关与路由（30+ 款）

包括 LLM 网关、路由器，以及 API/agent 网关和 OpenTelemetry 埋点工具。这一层负责统一管理模型调用、做负载均衡和成本控制。

比「链接堆砌」更靠谱的地方

开源清单最大的通病是年久失修——列了一堆项目，结果一半已经停更。这份清单在工程化维护上做了几件实事：

按 GitHub stars 排序：每张表格都按星标数排序，热度一目了然。
自动刷新：通过 GitHub Action 每周自动更新星标数、许可证和最近提交日期。
死项目标记：archived 表示仓库已归档，inactive 表示 12 个月内无提交，避免你踩坑。
许可证提醒：带 † 标记的是「源代码可见」（source-available）而非 OSI 认证的开源协议。例如 Phoenix 使用的是 Elastic-2.0。商用前务必核对，这类协议往往对商业使用有限制。

这份清单也明确了边界：只收录工具，不包含论文、课程或 agent 框架。定位清晰反而让它更实用。

「源代码可见」（Source-Available）与「开源」（Open Source）是两个容易混淆但有实质区别的概念。OSI（开源促进会）认证的开源协议——如 MIT、Apache 2.0、GPL——明确保障使用、修改和分发的自由，包括商业场景。而源代码可见协议（如 Elastic-2.0、BUSL、Commons Clause）虽然公开源码，但通常对商业用途、竞争性使用或云服务分发设有明确限制，违反条款可能引发法律风险。以 Elastic-2.0 为例，它禁止第三方将软件作为托管服务提供给他人——这意味着你可以内部自托管，但不能基于它对外提供 SaaS 服务。在为企业生产环境选型时，务必区分这两类协议，避免将「可以看到代码」误解为「可以自由商用」。

从 LangChain/LangGraph 快速上手的推荐

如果你正在用 LangChain 或 LangGraph，想快速找到起点，作者推荐了几款带原生 LangChain 集成的工具：Langfuse、Opik、MLflow、Phoenix 和 AcruxCore。

这些工具都支持通过添加 callback handler 或自动埋点（auto-instrumentation）的方式接入，几乎不需要改动多少代码就能拿到完整追踪。对想快速验证的团队来说，这是迁移成本最低的路径。

写在最后

LLMOps 工具链正处在快速扩张期，144 款工具的规模本身就说明生态有多热闹，也侧面反映出 LangSmith 闭源后端留下的真实缺口。对需要自托管的团队而言，这份持续维护的清单提供了一个靠谱的决策起点——先从一体化平台的 Langfuse、Opik、MLflow 入手，结合许可证和项目活跃度做筛选，往往就能找到合适的替代方案。