AI 应用可观测性平台工程 2026:统一栈选型
把 LangSmith / Langfuse / Helicone / Phoenix 四家平台的差异化定位、技术架构、商业化模式、产品边界做横评,并基于 OpenTelemetry GenAI Semantic Conventions 给出可落地的统一栈选型决策框架与 30/90/180 天迁移清单。
约 35 分钟阅读10,408 字10 次阅读博主
把 LangSmith / Langfuse / Helicone / Phoenix 四家平台的差异化定位、技术架构、商业化模式、产品边界做横评,并基于 OpenTelemetry GenAI Semantic Conventions 给出可落地的统一栈选型决策框架与 30/90/180 天迁移清单。
当一家 AI 应用团队把第一笔真实用户请求送进生产环境时,他们遇到的第一个问题不是模型选型,而是"我刚才那次调用到底发生了什么"。日志里写的是一行 JSON,里面有三个字段:prompt、completion、model,但用户说他看到的是 8 秒的空白,而你的 metrics dashboard 显示 P50 是 1.2 秒。问题出在哪里？是 prefill 慢、decode 慢、还是 RAG 检索慢？是 prompt 缓存命中了但用户没感知,还是 streaming 的 chunk 在 CDN 边缘丢了一个?这时候你才意识到:传统的日志、metrics、tracing 三件套不够用了。LLM 应用的请求既是一个 HTTP 调用,又是一个多轮对话状态机,还是一个工具调用的图谱,还是一次 prompt 拼接与缓存查询的组合,还是一次 embedding + 检索 + 重排的混合管道。它需要一种新的可观测性:不只是"这次请求花了多少时间",还要"这次请求消耗了多少 token、检索到了什么文档、生成了什么 tool call、用户的反馈是正向还是负向"。这就是 2026 年 AI 应用可观测性平台所解决的问题,而 LangSmith、Langfuse、Helicone、Phoenix 四家厂商,正是在这个新战场上划出了四种不同的技术哲学。
传统的 application performance monitoring (APM) 工具——Datadog、New Relic、Elastic——在 LLM 应用面前显得不够用,不是因为它们做得不好,而是因为它们的抽象层错位:它们知道"这个 HTTP 请求花了 800ms",但不知道这 800ms 里有 200ms 是 OpenAI API 排队、300ms 是 streaming 缓冲、150ms 是向量检索、剩下 150ms 才是真正的 token decode。它们知道"这个用户的 session 持续了 12 分钟",但不知道这 12 分钟里发生了 4 轮 prompt 拼接、2 次 tool call、3 次缓存命中。它们能给你 dashboard,但不能给你"为什么用户说这次的回复质量下降了"——因为答案埋在 8000 个 token 的 prompt 里、埋在 embedding 余弦相似度的细微变化里、埋在 ground truth 标注的人工质检报告里。
AI 应用的可观测性因此演化为一个四元组的统一栈:trace(调用链)、token(cost & usage)、latency(响应切片)、quality(质量评估)。这四个维度互相纠缠:同一个 trace 上,token 数和 latency 是相关的(prompt 越长 latency 越长),但和 quality 是弱相关的(更长的 prompt 不一定更好);同一个 latency 切片上,不同模型路由的成本可能差 10 倍,但延迟差距只有 50ms;同一个 quality 评估里,human feedback 和 LLM-as-judge 的相关性又是另一个统计学问题。把它们当作四个独立的 dashboard 是不够的——它们必须被绑定到同一个 trace_id 上,才能回答"上周三下午 3 点那个 P99 spike 到底影响了多少用户、这些用户的会话质量掉了几分、这部分的成本占了当天多少 budget"。
截至 2026 年 9 月,这个赛道形成了四种主流形态:(1) LangSmith——LangChain 生态原生,商业化深度最深,把 prompt IDE 和 evaluation 平台打通;(2) Langfuse——开源 + 自托管优先,Y Combinator 投资,在隐私敏感场景占据头部;(3) Helicone——网关拦截式架构,部署最简单,成本透明做得最好;(4) Phoenix(Arize AI 旗下)——以 evaluation 和 experiment 为中心,质量评估深度最强。四种形态背后是四种哲学:商业化、开源化、网关化、评估化。本文要做的,就是把这四种形态的技术细节、生态位、限制条件、迁移路径拆开讲清楚,然后给出一个从需求到部署形态的决策框架。
把 AI 应用的可观测性形式化为四元组 ,其中:
四元组之间通过 trace_id 绑定,但具体的相关性是非线性的:
观测的真正难度不在于"采集这四个维度"(现代 SDK 都能自动采集),而在于把它们绑在同一个 trace 上,并能在事后做联合查询。一个真实场景的例子:产品经理问"上周那次 prompt 升级,用户的满意度掉了吗?"——要回答这个问题,你需要 join trace 表(detail of which prompt version)、cost 表(用户的 session 总 token)、latency 表(响应时间分布)、quality 表(用户 thumbs up/down)。这就是四元组统一栈的价值:它把版本化的 prompt、有界成本的会话、可切片的延迟、可测量的质量统一到一个查询层上。
LangSmith 是 LangChain 团队的嫡系产品,2023 年底正式 GA,2024-2025 年快速迭代,2026 年已经形成完整商业产品线。它的最大优势是与 LangChain 生态的深度绑定:任何用 langchain / langgraph 写的应用,只要 LANGCHAIN_TRACING_V2=true,零代码就能把整个 trace 推到 LangSmith 的后端,自动生成嵌套的 span graph。这种"开箱即用"的体验在 LangChain 用户群中形成了事实标准——很多团队的第一次 AI 可观测性体验,就是 LangSmith。
技术上,LangSmith 的 trace 数据模型是按"runs"组织:每个 run 有 id、name、run_type(llm/chain/tool/retriever/embedding 等)、inputs、outputs、start_time、end_time、extra(metadata + tags)。父子关系通过 parent_run_id 形成树状结构,UI 上展示为横向 time 轴 + 纵向嵌套层级的混合视图。这种设计的好处是对 LangChain 用户零摩擦——你不需要改代码,只要在环境变量里加一个 key,所有 chain 都被自动 trace。坏处是对非 LangChain 用户摩擦大:如果你用纯 OpenAI SDK 或 Vercel AI SDK,LangSmith 也支持,但需要手动包装 function call,而且 trace 粒度没有 LangChain 那么自动。
商业化层面,LangSmith 的 Plan 分为 Developer(免费,有 trace 数量上限)、Plus(每月 $39/user,2026 年价格)、Enterprise(按 usage 计费 + SSO + 自定义 retention)。值得注意的是,2026 年 LangSmith 已经把 Prompt Hub(版本化 prompt 仓库)、Evaluation Hub(离线评估集 + 在线 A/B)、Annotation Queues(人工标注工作流)、Datasets(ground truth 管理)、Automation Rules(基于 quality 阈值的自动 re-eval)五大模块串成了一个完整的产品矩阵。这意味着 LangSmith 不只是"trace viewer",而是一个端到端的 LLM 应用开发平台——开发者在 LangSmith 上写 prompt、上传 dataset、跑 evaluation、查 trace、做 annotation,所有工作流在一个 UI 里闭环。
但 LangSmith 的局限也很明显:vendor lock-in 严重。它的 prompt hub 格式、dataset schema、evaluation config 都是私有格式,导出到 Langfuse 或 Phoenix 需要重写 metadata。同时,自托管选项几乎为零——LangSmith 主要走 SaaS 模式,虽然有 hybrid 部署,但数据层依然在 LangChain 的云上。对数据敏感的行业(医疗、金融、政府)这是 deal-breaker。此外,2026 年的 LangSmith 价格在大规模使用下显著高于开源替代:每月 1000 万 token 的生产流量,LangSmith Plus + Enterprise 组合可能每月花费 200-500(2 vCPU + 8GB RAM 的 small instance 集群)。
另一个被低估的局限是 LangSmith 的 evaluation 模型与 LangChain 版本深度耦合。如果你从 langchain==0.1.x 升级到 langchain==0.3.x(2025-2026 年 LangChain 团队主导的重构),callback handler 的 span 字段会重命名,evaluation dataset 的格式也会跟着变。这意味着 LangSmith 用户每次 LangChain 大版本升级都要做迁移适配,而不像 Langfuse 那样基于 OTel GenAI Conv 与 LangChain 解耦。
Langfuse 是德国团队 2023 年中开源的产品,采用 Self-hostable under MIT license(2025 年从 MIT 改为 source-available 但仍可自托管)的双协议,2024 年拿到 Y Combinator 投资,2026 年已经是 GitHub 上 star 数最多的 AI 可观测性项目(据 GitHub API 截至 2026-09 实时查询约 12K stars,未公开验证的排名)。它的核心定位是**"开源的 LangSmith"——但更准确的说法是"用 OpenTelemetry 协议 + DuckDB/ClickHouse 列式存储 + 自带 evaluation"的 LangSmith 替代**。
技术架构上,Langfuse 由四个组件构成:langfuse-web(Next.js UI)、langfuse-worker(异步 ingestion + eval trigger)、langfuse-api(FastAPI 后端)、PostgreSQL + ClickHouse + S3-compatible object store。ClickHouse 用于存储 trace 的高频字段(timestamp、latency、tokens、metadata),PostgreSQL 用于存储低频但关系性的数据(project、api_key、user、score、dataset)。S3 存储大字段(input、output 等长文本)。这种"分层存储"的设计让 Langfuse 能在不牺牲 query 灵活性的前提下,处理每秒上万次 span ingestion。
集成方式上,Langfuse 同时支持三种:(1) Native SDK——@langfuse/trace 直接 wrap OpenAI/Anthropic call;(2) OpenTelemetry——通过 opentelemetry-exporter-langfuse 把任何 OTel-instrumented 的应用 trace 推到 Langfuse;(3) LangChain/LlamaIndex integration——CallbackHandler 自动捕获 chain。第三种是 Langfuse 与 LangSmith 正面竞争的战场:两者都提供 CallbackHandler,迁移成本极低——把 langchain.callbacks.LangSmithCallbackHandler 换成 langfuse.callbacks.LangfuseCallbackHandler,环境变量改一下,trace 就跑到 Langfuse 上了。
商业化上,Langfuse 是 open-core 模型:核心 trace / score / dataset 功能完全开源免费,Enterprise 特性(SSO、audit log、custom retention、priority support)放在 SaaS 版本(每月 $199 起,按 events 计费)。这种模式让 Langfuse 在数据敏感 + 成本敏感的场景下占据头部:欧洲金融客户、医疗 SaaS、政府项目通常选 Langfuse 自托管,既要 GDPR 合规又要成本可控。
Langfuse 的产品差异化在两点:(1) Prompt Management 2.0 —— 2025 年推出的 feature,支持 prompt 的 version control + A/B deployment + label-based rollout(staging / production / canary 10%),每个 prompt 版本可以关联 evaluation result,UI 上能直接看到"v3 比 v2 在某个 dataset 上 accuracy 高 4%";(2) Score-based Eval Pipelines——通过 score_config 定义 quality metric(LLM-as-judge / heuristic / human),然后用 eval endpoint 批量跑 evaluation,结果存到 scores 表里,可以和 trace join 做"这个 trace 的 quality score 是 0.72,但 cost 是 $0.03,综合 ROI 偏低"的分析。
但 Langfuse 也有短板:UI 复杂度过高,新用户上手成本陡;ClickHouse 的运维门槛对小团队不友好;evaluation pipeline 的 LLM-as-judge prompt 编辑器不如 LangSmith 的 Playground 直观。
Helicone 是 2023 年成立的 startup,技术架构与 LangSmith/Langfuse 都不同:它不是 SDK 包装,而是一个反向代理 / OpenAI API gateway——你把 base_url 从 https://api.openai.com/v1 换成 https://oai.helicone.ai/v1 ,然后在 header 里加 Helicone-Auth: <your-key>,所有 OpenAI/Anthropic/Groq/Mistral 调用都会被 Helicone 拦截、记录、转给真正的 provider。这种"零代码拦截"的模式在 2024-2025 年迅速吸引了大量小团队——他们不想改任何代码,只想"看看 token 用了多少、谁在用、为什么慢"。
技术实现上,Helicone 部署在 Cloudflare Workers + Fly.io 上(2026 年初的架构,据其公开博客),核心逻辑是用 worker 解析 OpenAI-compatible 的 streaming response,同时记录每个 chunk 的 timestamp、token 数、cost。这种设计的优势是对用户透明:不需要 import 任何 SDK,不需要改业务代码,不需要 wrap 函数。坏处是对非 OpenAI-compatible 的 API 不友好:Azure OpenAI 需要额外的 config,Bedrock 需要 boto3 wrapper,本地模型(vLLM / Ollama)基本不支持。
Helicone 的核心差异化是cost transparency——它的 dashboard 做得极简,直接展示"过去 24 小时用了多少 token、烧了多少钱、哪些 model 最贵、哪些 user session 占了 budget"。这种"成本透明"对早期 startup 极其友好:CTO 一眼就能看出哪些 feature 在烧钱、哪些 user 是 heavy user。同时 Helicone 提供cache layer(语义缓存 + exact match)、rate limit(per-user/per-key)、fallback routing(model A 挂了自动切 model B)这些"代理层"特有的功能,这是 SDK 模式做不到的。
商业化方面,Helicone 有 free tier(每月 10K events)、Pro($20/月,1M events)、Enterprise 自定价。Pro 价格远低于 LangSmith,对早期 startup 友好。但 Helicone 的限制也明显:evaluation 功能很弱——它没有内置 LLM-as-judge、没有 dataset 管理、没有 A/B testing framework。如果你的需求不只是"看看 token 花了多少",而是"系统化地评估 prompt 升级效果",Helicone 不够用,需要和 Langfuse/Phoenix 配合。
截至 2026 年 9 月,Helicone 已经支持 100+ 个 LLM provider(据其官方文档),包括 Anthropic Claude 4.5、OpenAI GPT-5、Google Gemini 2.5、Meta Llama 4、Mistral Large 3 等主流模型,还支持 fine-tuned model 的 custom endpoint 路由。它的"反向代理"模式正在被 Datadog LLM Observability、Dynatrace AI Observability 等传统 APM 厂商模仿——但 Helicone 仍然是这个垂直领域的事实标准。
值得特别提到的是 Helicone 在 2025 年推出的 "Custom Properties" 功能——允许通过 HTTP header 把任意 metadata(用户 ID、feature flag、A/B bucket、地理位置)注入到 trace 上,这些属性可以在 dashboard 里做任意切片。这种"任何维度都能切"的灵活性是很多企业用户从 Helicone 迁移到 Langfuse 的核心原因——Langfuse 的 trace metadata 模型相对刚性,需要预先在 schema 里定义字段,而 Helicone 完全 schema-less。
Phoenix 是 Arize AI 旗下的开源产品,2023 年开源,核心定位是**"evaluation-first"的 LLM 可观测性**——它不是从 trace 出发,而是从 experiment 出发。Phoenix 的核心抽象是 Experiment,一个 Experiment 定义了dataset(ground truth)、task(你跑的函数,通常是 LLM chain)、evaluators(LLM-as-judge 或 heuristic),运行后产出每个 sample 的 score 聚合。这是和 LangSmith/Langfuse 最根本的架构差异:LangSmith/Langfuse 是"先 trace,后看质量",Phoenix 是"先定义 quality,后看 trace"。
技术栈上,Phoenix 用 TypeScript + React 前端、Python + FastAPI 后端、PostgreSQL + DuckDB 存储(2026 年初的架构)。它的 SDK 是 Python-first(pip install arize-phoenix),核心 API 是 @phoenix.experiment 装饰器和 phoenix.launch_app() UI。值得一提的是 Phoenix 深度集成 OpenInference——OpenTelemetry 的 GenAI semantic convention 子集(是的,Phoenix 是 OTel GenAI Conv 的早期贡献者之一)。这意味着 Phoenix 的 trace 和 OTel 生态是互通的,可以从 Phoenix 导出到 Datadog、Honeycomb 等其他 OTel 后端。
Phoenix 的真正杀手锏是 LLM-as-judge 的工具链。它提供了一组内置 evaluator(HallucinationEvaluator、RelevanceEvaluator、ToxicityEvaluator、QACorrectnessEvaluator 等),每个 evaluator 都是用 GPT-4o/Claude 3.5 等强模型作为 judge,加上精心设计的 rubric prompt。更重要的是,它支持 custom evaluator with rationale ——你写一个函数返回 (score, explanation),UI 上会同时显示分数和解释,人工 reviewer 可以对解释点赞/点踩,作为 ground truth 积累。
商业化上,Phoenix 是完全开源 + Arize 商业产品(Arize AX)补贴的商业模式。Phoenix 本体免费,功能上没有 enterprise 限制,但生产环境的长期 retention(超过 90 天的 trace)需要付费的 Arize AX。这种"开源 + SaaS 付费"和 Langfuse 类似,但 Phoenix 走得更彻底——连 SSO 都开源。
Phoenix 的局限:self-hosting 体验不如 Langfuse——Phoenix 的部署脚本对 k8s 友好但对小型 VM 不友好;和 LangChain 的集成不如 LangSmith——虽然有 callback handler,但覆盖的 chain 类型没 LangChain 团队自己维护的那么全;prompt 管理功能很弱——它不是 prompt-first 平台,prompt 编辑器非常简陋,主要靠 dataset + eval 来迭代。
适合谁用 Phoenix?研究团队、做 RLHF/RLAIF 的团队、需要严格 quality benchmark 的团队——这些场景下 evaluation 是核心需求,trace 只是 secondary。
2026 年 AI 可观测性领域最重要的事件,是 OpenTelemetry GenAI Semantic Conventions 正式进入 stable 状态。这个工作从 2024 年开始,2025 年发布 v1.0-alpha,2026 年 3 月发布 v1.1-stable(据 OTel 官方 spec)。它的核心贡献是定义了一套标准的 span name 和 attribute 命名,让不同 LLM SDK、不同框架生成的 trace 能被任何 OTel 后端正确解析。
核心 attribute 集包括:
gen_ai.system(openai / anthropic / azure_openai / vertex_ai / cohere 等)gen_ai.request.model(请求的 model 名称,如 gpt-5、claude-sonnet-4-5)gen_ai.request.max_tokens / gen_ai.request.temperature / gen_ai.request.top_pgen_ai.usage.input_tokens / gen_ai.usage.output_tokensgen_ai.response.model(实际返回的 model,可能因 fallback 不同)gen_ai.response.finish_reasons(终止原因列表)gen_ai.response.id(provider 返回的 request id)gen_ai.evaluation.score / gen_ai.evaluation.name(评估分数)这套语义约定最大的价值是vendor neutrality——一旦你的应用 emit 标准 OTel GenAI span,你可以随时切换后端:从 LangSmith 切到 Langfuse、从 Helicone 切到 Datadog LLM Observability,都不用改代码。这从根本上解决了vendor lock-in 问题,也是 LangSmith 在 2026 年感受到的最大竞争压力——客户开始意识到"我的 trace 应该属于我,不应该绑在某个 vendor 的 UI 上"。
但 OTel GenAI Conv 也有不足:评估维度的语义约定还在演进——gen_ai.evaluation.* 命名空间目前只定义了 score 和 name,没有定义 evaluation type(RAGAS? LLM-as-judge? human?)、evaluation model(哪个 LLM 做的 judge)、evaluation rubric 等。这给 Phoenix、Langfuse 留下了差异化空间——他们可以在 standard convention 之上定义自己的 evaluation attribute extension,形成"标准 + 扩展"的双层结构。
一个具体的 OTel GenAI span JSON 示例(2026 年 3 月 v1.1-stable 标准):
{
"name": "chat gpt-5",
"kind": "CLIENT",
"attributes": {
"gen_ai.system": "openai",
"gen_ai.request.model": "gpt-5",
"gen_ai.request.max_tokens": 2048,
"gen_ai.usage.input_tokens": 1247,
"gen_ai.usage.output_tokens": 583,
"gen_ai.response.finish_reasons": ["stop"]
}
}
这个 span 可以同时被 LangSmith / Langfuse / Phoenix / Datadog / Honeycomb 任何一个 OTel-compatible 后端解析和展示——这就是 vendor neutrality 的工程意义。
对 AI 应用团队的实际建议:未来 12-18 个月内,把代码迁移到 emit OTel GenAI span——这是成本最低的"未来保险"。具体做法:用 OpenLLMetry(Traceloop 出品的 OTel GenAI auto-instrumentation 库)替换 LangSmith/Langfuse 的 SDK,或者直接用 OpenInference(Phoenix 出品)作为 OTel exporter。这样既保留了与 LangSmith/Langfuse/Phoenix 的兼容性,又获得了 vendor neutrality。
选型不是"哪个最好",而是"哪个最适合"。我把决策因素拆成四个轴,每个轴对应一个 0-3 分的选择:
| 部署 | 需求 | LangChain | 预算 | 推荐栈 |
|---|---|---|---|---|
| 0 | 0-1 | 0-1 | 0-1 | Langfuse self-host + Helicone free |
| 0 | 2 | 0-1 | 0-2 | Phoenix self-host + OpenLLMetry |
| 0 | 3 | 0-1 | 1-2 | Langfuse Enterprise + 自建 eval |
| 1 | 0-2 | 0-2 | 1-2 | Helicone Pro + Langfuse SaaS |
| 2 | 0-3 | 2-3 | 2-3 | LangSmith Plus + LangChain 生态 |
| 3 | 0-3 | 3 | 2-3 | LangSmith Plus / Enterprise |
混合策略也很常见:LangSmith 做 IDE 和 prompt hub + Langfuse 做长期 trace storage + Phoenix 做离线 evaluation batch,三家通过 OTel GenAI Conv 互通。这种"best-of-breed"模式在 2026 年开始流行,前提是团队有 1-2 个专职 MLOps 工程师维护这套集成。
最后是给团队的实操建议,按 30 天 / 90 天 / 180 天三个阶段分:
cost_per_session 的 baseline metric——大多数团队没意识到单次会话平均成本是 0.50,baseline 缺失导致无法优化。success_rate / retry_count / parse_error_count。30 天 (基础可观测性):
cost_per_session 仪表盘,按 user_id、feature、model 三个维度切片。90 天 (评估 + 选型):
7 天全字段 → 30 天降采样(只保留 metadata) → 180 天 aggregate metric。180 天 (自动化 + 持续优化):
截至 2026 年 9 月,这个赛道仍在快速演进。OpenAI 自己的 openai-instrumentation SDK、Anthropic 的 claude-trace SDK、Arize 的 Arize AX 商业产品都在迭代。建议每季度重新评估一次选型,不要让 2026 年的技术债带到 2027。
一句话摘要:把 AI 应用的"trace + token + latency + quality"四元组绑在同一个 OTel GenAI span 上,通过 LangSmith(商业化深度)/Langfuse(开源治理)/Helicone(网关透明)/Phoenix(评估深度)的差异化定位做出选型,是 2026 年 AI 应用团队可观测性栈建设的不二路径。
Conversation
0 条