凌晨两点，一位负责 AI 客服的技术合伙人在群里发消息：「线上对话突然大面积答非所问，我们连是哪个 Prompt 版本、哪个模型、哪段上下文出的问题都查不到。」翻聊天记录、翻代码 commit、翻服务器日志，折腾到天亮才定位是某个隐式上线的 Prompt 改动叠加了模型小版本切换。这种夜班，我们这两年陪不少团队一起熬过，每一次的共同结论都是同一句话：该上 LLMOps 平台了。
企业 AI 落地八步法 里我们把 LLMOps 放在工程化阶段，本篇专门展开这一层，把 LangSmith、Langfuse、Helicone 与自建这四条主流路线放在同一张桌子上比较，给做 AI 应用工程化的团队 leader 与 CTO 一份可直接拿去开决策会的参考。
LLMOps 究竟在做什么：五件事而不是一件事
很多团队第一次听到 LLMOps 时，会把它和「监控」画等号，这种理解会让选型走偏。LLMOps 在我们的实践中至少覆盖五件事，缺一件都会在某个阶段被反咬一口。
- Prompt 管理：版本化、多环境隔离、灰度切换、回滚，类似代码仓库之于业务逻辑。
- 调用追踪：把一次用户请求里链式的 LLM 调用、工具调用、检索调用串成一棵 trace，可下钻到每一个 span。
- 评估体系：自动评估（规则、模型评估、嵌入相似度）与人工评估混合，覆盖回归、对抗、红蓝。
- 数据集治理：把线上的 bad case 沉淀为数据集，反哺新的 Prompt 与微调，形成闭环。
- 监控与告警：成本、延迟、错误率、token 用量、模型分布的看板与异常报警。
AI Agent 评估与红队 一文里我们专门展开过评估这一环；本篇关注的是「装这套能力的容器」选哪个。
为什么传统 APM 工具不够用：AI 调用的链路不是微服务
不少团队最初尝试把 Datadog、SkyWalking 这类 APM 改造去监控 LLM 调用，跑两周就放弃。差异不在于「能不能记一行日志」，而在于 AI 调用的链路语义和微服务完全不同。
| 维度 | 传统 APM 监控的微服务 | LLMOps 要监控的 AI 调用 |
|---|---|---|
| 调用本质 | 确定输入产出确定输出 | 同一 Prompt 多次调用结果不同 |
| 失败模式 | HTTP 状态码、异常栈 | 答非所问、幻觉、越权、风格漂移 |
| 关键指标 | QPS、P99 延迟、错误率 | token 用量、模型分布、评估分数、bad case 率 |
| 调试单元 | 一个请求一个 span | 一棵 trace，含多次 LLM 调用与工具调用 |
| 回归手段 | 单元测试、压测 | 数据集回放、人工评估、对抗测试 |
| 版本对象 | 代码版本 | Prompt 版本＋模型版本＋检索配置 |
AI Agent 架构模式 里讨论过为什么 Agent 调用呈树状而非线性，这种结构天然不适合 APM 的线性 trace 模型，这是 LLMOps 平台存在的根本原因。
四条路对比：LangSmith／Langfuse／Helicone／自建
四种主流选型背后是四种工程哲学，我们逐一拆解。
LangSmith：LangChain 系的官配闭源平台
由 LangChain 团队出品，深度绑定 LangChain／LangGraph 生态，开箱体验顺滑，Prompt Hub、评估、回放、生产监控一应俱全。优点是产品迭代速度快、文档详尽；缺点是闭源、默认数据在境外、按 trace 计费在高调用量场景成本上扬较快。
Langfuse：开源派的代表
德国团队主导的 Apache 2.0 项目，功能矩阵正在快速追平 LangSmith，且可完全自托管。我们在多数中型项目里默认推荐它，原因是数据自主、可与企业内的鉴权与审计体系打通、社区活跃度足以覆盖大多数问题。
Helicone：代理模式的轻量监控
通过 LLM 网关代理的方式接入，只需改一行 base_url 就能拿到调用日志、缓存与限流能力。强在「接入快」，弱在「评估与数据集」深度不及前两者。适合已有大量 OpenAI 兼容调用，且短期内只想先把成本与监控管起来的团队。
自建：基于 OpenTelemetry 与现成中间件拼装
部分对数据合规与定制深度要求极高的团队会选择自建，技术栈通常是 OpenTelemetry collector ＋ ClickHouse ＋ Grafana ＋自研 Prompt 版本服务。优点是完全可控、可深度嵌入既有可观测性体系；缺点是评估与数据集模块需要自己造，人力投入比想象中多。
五维度横评：把抽象描述变成可比较的表格
把上面四条路放到同一张表里，决策会就能从「我感觉」变成「我看数据」。
| 维度 | LangSmith | Langfuse | Helicone | 自建 |
|---|---|---|---|---|
| 功能完整度 | 高，覆盖 Prompt／Trace／Eval／Dataset | 高，主要功能齐备且持续追平 | 中，强于代理与监控，弱于评估 | 取决于投入，通常初期偏低 |
| 开源／闭源 | 闭源 SaaS | 开源 Apache 2.0，可自托管 | 同时提供 SaaS 与开源代理 | 完全自有 |
| 数据合规 | 默认境外，需企业方案谈本地化 | 自建后数据完全留在内网 | SaaS 模式跨境，自托管代理可控 | 完全在企业内 |
| 集成成本 | 极低，SDK 一行接入 | 较低，自托管需要基础容器经验 | 极低，改 base_url 即可 | 高，需 2-6 人月起步 |
| 价格区间 | 按 trace 量阶梯计费 | 自建仅基础设施成本，云版较低 | 按调用量计费，免费额度较慷慨 | 主要是研发与运维人力 |
| 适合场景 | 重度使用 LangChain 生态、对合规不敏感 | 多数中型团队、需要数据自主 | 已有大量 OpenAI 兼容调用、先抓监控 | 大型集团、合规与定制要求极高 |
不要把表格当成结论，它只是把讨论拉到同一个坐标系。下面分中小企业与大型企业给出我们更具体的建议。
中小企业的选择：Langfuse 自建＋一组关键指标
对 50-500 人规模、AI 应用刚跨过 PoC 的团队，我们的默认建议是 Langfuse 自托管。理由有三：
第一，数据自主。线上对话与 bad case 是企业的核心数据资产，沉淀在自建实例里既符合 企业 AI 落地的数据安全策略，也方便后续接入企业自己的 权限与审计体系。
第二，部署门槛低。一台 4 核 16G 的虚拟机加上托管 Postgres，能撑住日调用量到几十万的项目数月不出问题。后续按需扩展 ClickHouse 即可。
第三，可与企业既有体系融合。SSO、企业微信／钉钉机器人告警、内部数据仓库回流都有成熟方案。
落地时我们建议团队从一组关键指标起步，不要一上来就铺全量看板：
- 每日 trace 总数与 token 总量，按 Prompt 版本切分
- 评估通过率与 bad case 率，区分自动评估与人工评估
- P95 延迟与端到端成本，区分模型与租户
- 工具调用成功率与重试率，定位 多工具与多模型路由策略 中的瓶颈
大型企业的选择：商用＋私有化部署，分层组合
对集团型企业或受强监管行业，单一平台往往覆盖不了所有诉求。我们见过比较稳的组合是「商用 LLMOps 私有化部署＋自建 Prompt 库＋既有 APM 接 OTel」三层叠加：
- 商用 LLMOps 负责 Trace、评估与数据集，前提是供应商提供本地化部署且通过企业安全评审，与 国内大模型选型 与 PIPL 合规链路 协同。
- Prompt 库与版本服务自建，与 GitLab、内部审批流打通，遵循变更管理规范。
- 既有的 APM 与日志系统通过 OpenTelemetry 接入 LLM span，避免重复造可观测性轮子。
这种组合的核心是「分层」：把易变的评估方法学交给专业平台，把稳定的基础设施留在自家手里。云原生与自建 AI 平台 里我们详细比较过两种部署形态的取舍。
LLMOps 与 Eval、监控、Prompt 库的关系
很多团队在内部讨论时会陷入概念战：LLMOps、Eval 平台、监控、Prompt 库到底是不是一回事？我们的拆法是：
| 能力层 | 关心什么 | 与 LLMOps 的关系 |
|---|---|---|
| Prompt 库 | 谁改了 Prompt、改成什么、灰度到哪里 | 是 LLMOps 的子模块，可独立存在 |
| Trace 与监控 | 线上调用链、延迟、成本、错误 | 是 LLMOps 的核心入口 |
| Eval 平台 | 模型与 Agent 的能力评估、回归、对抗 | 与 LLMOps 共享数据集，常常融合 |
| 数据集治理 | bad case 沉淀、标注、清洗 | 是 LLMOps 的输出与 Eval 的输入 |
| 实验追踪 | 训练与微调的实验记录 | 通常由 MLflow 这类工具承担，与 LLMOps 互补 |
理解这种分工后，再回看四条路的差异会更清晰：LangSmith 与 Langfuse 想做的是覆盖前四层的「LLMOps 一体机」，Helicone 聚焦 Trace 与监控，自建则是按需拼装。
一段题外话：LLMOps 不仅服务于 AI 应用，也服务于 AI Coding
我们内部除了用 LLMOps 平台监控对外的 AI Agent，也用它监控 AI Coding 在软件交付中的使用。开发同学使用 Claude Code 与 Cursor 等企业版工具 的调用同样会产生 trace，里面藏着大量「这次代码生成是否被采纳」「哪种 Prompt 让 PR 通过率更高」的信号。把这条线接上后，AI Coding 团队上手 的节奏变得透明，工程负责人不再只能凭感觉判断引入效果。
这也是我们认为 LLMOps 不会停留在「监控工具」定位的原因：它会逐渐成为 AI 时代的 DevOps 控制面，覆盖从研发协作到线上运行的完整链路。
决策表：三种典型场景给出明确建议
把上面的讨论压缩成一张可直接拿去开会的决策表。
| 场景特征 | 推荐路线 | 关键理由 |
|---|---|---|
| 重度 LangChain／LangGraph 生态、对数据出境不敏感、希望最快出活 | LangSmith SaaS | 生态贴合、产品体验顺滑 |
| 中型团队、自有 DevOps 能力、关注数据自主与成本 | Langfuse 自托管 | 开源可控、社区活跃 |
| 已有海量 OpenAI 兼容调用、短期目标是把成本和监控抓起来 | Helicone | 接入近乎零成本 |
| 集团型企业、强监管行业、要求与既有 APM 深度融合 | 商用私有化＋自建 Prompt 库＋OTel 接入 | 分层组合最大化合规与定制空间 |
| 早期原型阶段、调用量极小 | 暂不投入 LLMOps | 日志加人工评估即可 |
AI Agent 落地的成本拆解 与 AI Agent 供应商选择 是这张表之外两份常被一起翻看的资料，建议组合阅读。
结语
LLMOps 不是一道单选题，而是一组「以数据自主为底线、以评估闭环为目标」的工程选择。先想清楚自己处于 AI Agent 实施路线图 的哪一段，再决定是装上 LangSmith 的「即开即用」、跑起 Langfuse 的「自托管底盘」、插上 Helicone 的「轻量代理」，还是搭一套属于自己企业的「分层组合」。工具的差异终会被时间抹平，沉淀下来的评估方法学与数据集才是真正属于团队的资产。
