L4-0 · AI 可观测格局：从 30 个产品到一个选型坐标系

TL;DR · 本文把当前 AI 可观测赛道的 30+ 产品按"它们在 LLM 调用链路的哪个位置切入"分成 5 种路线（Trace-first 专用平台 / OTel-native / Gateway / Eval-first / 传统 APM 扩展），给出二维选型坐标系和决策树。 · 写给：要做 AI 可观测选型的 SRE / 架构师 / AI 应用 tech lead——尤其是国内合规敏感、需要 self-hostable 路线的团队。 · 不读会错过：每条路线在赌什么、它的天花板在哪里、哪条最可能在三年洗牌后存活。

截至时间：2026-06。 这个赛道每 3–6 个月会有新玩家、并购、产品转向；本文所有"它做什么 / 它不做什么"的判断都基于这个时间点的公开信息与产品状态。读者使用本文做决策前应核对最新版本说明。

过去两年里，“LLM Observability” 这个标签下冒出了至少三十个产品——Langfuse、LangSmith、Arize Phoenix、Helicone、Portkey、Braintrust、Comet Opik、TruLens、Weights & Biases Weave、OpenLLMetry、LiteLLM、HoneyHive、Lunary……再加上 Datadog、New Relic、Dynatrace 这些 APM 大厂的扩展模块，以及国内云厂商各自的 LLM 监控套件，这个赛道目前的形态是碎片化、未收敛、高速洗牌。

这种碎片化不是"市场不成熟"那么简单。它反映的是这个领域还没有就基础问题达成共识：

谁是基础原语？事件？trajectory？prompt-response 对？
谁负责评估？工具自己？另一个 LLM？人？
怎么和现有可观测栈共存？走 OTel？走专用 SDK？走网关？

我的判断是：这些问题不会被某家厂商"解决"，会被标准化解决。OpenTelemetry GenAI Semantic Conventions（github.com/open-telemetry/semantic-conventions，截至 2026-06 仍在 experimental → stable 推进）正在做这件事。我的隐含立场也基于此：三年后还活着的厂商，大概率是那些主动拥抱 OTel GenAI 而不是抗拒它的厂商。

每家产品都对这些问题做了不同的赌注。选错赌注的成本比选错传统可观测工具高得多——prompt 模板治理、eval 历史、agent trace 数据模型迁移都没有跨厂商互通的标准，迁一次基本等于重做。

L4-0 的任务是给这堆产品画一张地图。不是穷举介绍，是把它们按真正起作用的"分类轴"分开，让你看清自己在哪个位置、为什么。

1. 五种路线

把这三十个产品按"它们在干预 LLM 调用链路的哪个位置、用什么方式干预"来分，可以归为五种路线。每种都对应一种工程哲学。

flowchart LR
    APP["应用代码
LangChain / LlamaIndex / 自研"] --> SDK["SDK 埋点"]
    APP --> GW["调用网关"]
    GW --> LLM["LLM API
OpenAI / Anthropic / Bedrock"]
    SDK --> LLM
    SDK -.->|"专用协议"| TF["路线 A · Trace-first
LangSmith / Langfuse / Phoenix"]
    SDK -.->|"OTel 协议"| OTEL["路线 B · OTel-native
OpenLLMetry / Traceloop"]
    GW -.->|"网关日志"| GWO["路线 C · Gateway
Helicone / Portkey / LiteLLM"]
    APP -.->|"评估流水线"| EV["路线 D · Eval-first
Braintrust / Opik / TruLens / Weave"]
    TRA["路线 E · 传统 APM 扩展
Datadog / New Relic / Dynatrace"] -.->|"既有探针"| APP
    style TF fill:#e0eaff
    style OTEL fill:#fff4d6
    style GWO fill:#ffe3e3
    style EV fill:#e8f5e9
    style TRA fill:#f3e5f5

图 1·五种路线在 LLM 调用链路上的接入位置。每条虚线代表一种"切入观测"的姿势。

路线 A · Trace-first 专用平台

典型玩家：LangSmith、Langfuse、Arize Phoenix、HoneyHive、Lunary

主张：LLM 应用的核心可观测原语是调用 trace——从用户输入到最终输出的完整链路，含 prompt / response / tool calls / metadata。把这条 trace 看清楚，其他东西（eval、cost、replay）都可以挂在它上面。

做法：提供 SDK 让你在应用代码里手动 / 自动埋点，把每次 LLM 调用、每次 chain step、每次 tool 调用作为一个 span 上报。后端做存储、可视化、查询、关联 eval。

这条路的赌注：相信 trace 是 LLM 可观测的中枢；相信开发者愿意接受 SDK 侵入；相信 trace 数据模型可以承担 prompt 治理 + eval + cost 等所有需求。

主要分化：

LangSmith 是 LangChain Inc. 的嫡系——和 LangChain / LangGraph 深度耦合，自动埋点最完整，但绑定也最深。
Langfuse 是开源 + self-hostable 路线——框架中立、数据自主可控，是国内合规敏感团队的首选。
Arize Phoenix 是开源版本（Arize AI 是商业版）——OTel 对齐、与 Arize 的 ML observability 同源、偏 production 视角。

路线 B · OTel-native

典型玩家：OpenLLMetry、Traceloop（兼具 SDK 与商业后端）

主张：LLM 可观测不应该再造一套自己的协议、数据模型、SDK——它应该是 OpenTelemetry 的延伸。一组 GenAI Semantic Conventions（gen_ai.system、gen_ai.request.model、gen_ai.usage.input_tokens……）让 LLM 调用变成普通的 OTel span。

做法：发布 OTel SDK（OpenLLMetry 就是 Traceloop 的开源 SDK），把所有主流 LLM provider / 框架的调用自动转成 OTel span，然后由用户选择任何 OTel-兼容的后端接收（Tempo、Grafana、ClickHouse、Apache Doris、Honeycomb，或 Traceloop 自己的商业后端）。

这条路的赌注：相信标准化最终会赢；相信团队已有的可观测栈是宝贵资产、应当复用而不是另起炉灶；相信"专用平台"模式三年后会被通用 OTel 后端吃掉。

主要分化：OpenLLMetry（SDK）+ Traceloop（商业后端）是这条路最纯粹的代表。Phoenix 同时支持 OTel 和自己的格式，骑墙。趋势是越来越多专用平台都在提供 OTel 兼容接收端——边界正在模糊。

路线 C · Gateway 路线

典型玩家：Helicone、Portkey、LiteLLM、Cloudflare AI Gateway

主张：把可观测放在网关上而不是 SDK 上。所有 LLM 调用都经过网关代理（应用 → 网关 → OpenAI / Anthropic），网关天然能看到每次调用的请求 / 响应 / 延迟 / token / 错误。副作用：你顺便还能在网关上做 retry、cache、rate limit、provider 切换、PII 脱敏。

做法：让团队把 base_url 从 https://api.openai.com 改成 https://gateway.helicone.ai（或类似），几行配置就能开通可观测，无需埋点。

这条路的赌注：相信"零代码侵入"是 LLM 应用团队的真实痛点（很多 AI 团队是产品 / 业务出身，不愿改代码）；相信网关能承担的不只是观测，是 LLM 的"流量控制平面"。

强项：开通成本极低、多 provider 支持天然、可以叠加 cache / rate limit / cost cap。弱项：只能看到"进出网关的"——Agent 内部的 chain step、tool call 之间的因果关系，网关看不到。RAG 检索阶段如果不走网关也看不到。

主要分化：

Helicone 强调 observability + cost，YC 系 startup。
Portkey 强调 governance + observability + 多 provider 路由。
LiteLLM 起家是统一 API（兼容 100+ provider），observability 是副产品；越来越往 gateway 平台演进。

路线 D · Eval-first

典型玩家：Braintrust、Comet Opik、TruLens、Weights & Biases Weave

主张：LLM 可观测的核心信号不是 trace，是评估。看见一次 trace 没用——你要知道这次调用"做得好不好"。所以工具应当围绕 eval 流水线建：在线评估、离线评估、回归集、LLM-as-Judge、人工标注闭环。

做法：提供 eval-first 的 SDK 和数据模型——主信号是 (input, output, eval_score)，trace 是辅助。配合实验追踪（experiment tracking）的能力，让 prompt / 模型 / 配置变更的影响可以被严谨度量。

这条路的赌注：相信"质量"是 LLM 系统真正的稀缺信号；相信生产团队最终会从"看 trace 找 bug"演化到"看 eval 改 prompt"。

主要分化：

Braintrust 是 eval-first 最纯粹的代表，强调实验、playground、prompt iteration。
Comet Opik 是开源 + self-hostable 路线，从 ML experiment tracking 延伸过来。
TruLens 是 Snowflake 收购的开源 eval 框架，偏 RAG 评估。
W&B Weave 是 Weights & Biases 在 LLM 时代的扩展，借助 W&B 原有 experiment tracking 优势。

路线 E · 传统 APM 扩展

典型玩家：Datadog LLM Observability、New Relic AI Monitoring、Dynatrace AI Observability、国内云厂商（阿里云 ARMS、火山引擎、腾讯云 APM 等）

主张：LLM 可观测不需要新工具——它就是现有 APM 的一个新视图。把 GenAI semantic conventions 加进既有 trace 系统，把 token usage 加进既有 metric 系统，把 prompt 加进既有 log 系统，搞定。

做法：在现有产品里加 “LLM” 模块，复用既有数据管道、UI、告警、user management。

这条路的赌注：相信"AI 可观测不会成为独立类别"；相信企业客户的"少一个 vendor 是少一个 vendor"心态会让 incumbent 赢。

强项：和现有 APM 栈零迁移、统一计费、企业关系成熟。弱项：LLM-specific 的深度功能（prompt playground、eval 流水线、agent trace 可视化）通常落后专用平台 6–18 个月。

2. 选型坐标系

把五种路线放进一个二维坐标：

quadrantChart
    title AI 可观测产品定位
    x-axis "深度耦合 (框架 / SDK)" --> "零侵入 (Gateway / OTel)"
    y-axis "Trace-first" --> "Eval-first"
    quadrant-1 "评估驱动 + 开放"
    quadrant-2 "评估驱动 + 嵌入式"
    quadrant-3 "追踪驱动 + 嵌入式"
    quadrant-4 "追踪驱动 + 开放"
    "LangSmith": [0.15, 0.4]
    "Langfuse": [0.35, 0.4]
    "Phoenix": [0.55, 0.45]
    "OpenLLMetry": [0.85, 0.3]
    "Helicone": [0.9, 0.25]
    "Portkey": [0.85, 0.35]
    "LiteLLM": [0.92, 0.2]
    "Braintrust": [0.35, 0.85]
    "Opik": [0.4, 0.75]
    "TruLens": [0.5, 0.8]
    "W&B Weave": [0.3, 0.7]
    "Datadog LLM": [0.7, 0.3]

图 2·二维选型坐标系。X 轴：从深度耦合到零侵入；Y 轴：从 trace-first 到 eval-first。位置决定它最适合哪类团队。

读这张图的方式：

左下角（深度耦合 + trace-first）：LangSmith 是典型——LangChain 嫡系，自动埋点最完整。代价是离开 LangChain 生态成本高。
右下角（零侵入 + trace-first）：OpenLLMetry / Helicone——不动应用代码就能开通可观测。
上方（eval-first）：Braintrust / Opik / TruLens / Weave——更关心"做得好不好"而非"调用经过了哪里"。

注意几乎没有产品落在严格的左上角（深度耦合 + eval-first）——这反映了一个市场事实：eval-first 工具通常选择保持框架中立，因为评估的语义不依赖 chain 拓扑。

3. 几个非技术维度

技术哲学之外，有四个非技术维度同样决定选型——往往是国内团队最终拍板的真正变量。

1. 数据归属与合规 Prompt 和 response 里通常包含业务敏感信息（用户对话、内部知识、未公开产品规划）。把它们上报到境外 SaaS 是合规问题——这是为什么国内团队对 Langfuse self-hosted 和 Phoenix 开源版的关注度远高于海外。LangSmith 的 self-hosted 是企业版门槛（需要谈合同、非开源 OSS 路线），不像 Langfuse 自带开源 self-host 镜像——这一条让相当多国内中小团队把它从候选名单上划掉。

2. 与现有可观测栈的关系 你已经有 Prometheus + Grafana + Loki + Tempo 一整套？那 OpenLLMetry + 已有 Tempo（或 ClickHouse / Apache Doris 列存）可能比再上一个独立平台更顺。你完全没有可观测栈、想一站式开通？那 LangSmith / Langfuse / Helicone 都比"自己拼 OTel"快得多。

3. 框架绑定程度 LangSmith 对 LangChain / LangGraph 的耦合是优势也是负担。LangChain 重度使用、且不打算迁移的团队，LangSmith 的"自动埋点 + 原生集成"是真的省时间。自研框架 / LlamaIndex / 直接调 SDK 的团队，LangSmith 的优势消失，框架中立的 Langfuse / Phoenix 更顺。

4. 厂商生命周期风险 这个赛道至少还有一轮洗牌。今天的 30 个产品里三年后大概率剩 5–8 个。选型时值得考虑：① 是否能导出原始数据？② 数据模型是否标准化（OTel 兼容）？③ 团队是否同时记一份原始日志以备迁移？把"哪天这家厂商消失了我能不能撤"作为入场前的明确问题。

4. 五种典型选型场景

把上面的维度组合起来，可以给出五种典型场景的推荐起点。

flowchart TD
    Q["你的核心约束是什么 ?"] --> Q1{"LangChain
重度使用 ?"}
    Q1 -->|是| S1["场景 A · LangSmith
自动埋点最省时间"]
    Q1 -->|否| Q2{"数据合规 / 自主可控
是硬约束 ?"}
    Q2 -->|是| S2["场景 B · Langfuse / Phoenix
self-hostable"]
    Q2 -->|否| Q3{"已有完整 OTel 栈 ?"}
    Q3 -->|是| S3["场景 C · OpenLLMetry
+ 既有 Tempo / ClickHouse / Doris"]
    Q3 -->|否| Q4{"多 provider 路由
是核心需求 ?"}
    Q4 -->|是| S4["场景 D · Helicone / Portkey / LiteLLM
Gateway 路线"]
    Q4 -->|否| S5["场景 E · Braintrust / Opik
Eval-first 起步"]
    style S1 fill:#e0eaff
    style S2 fill:#e0eaff
    style S3 fill:#fff4d6
    style S4 fill:#ffe3e3
    style S5 fill:#e8f5e9

图 3·选型决策树。每个分支对应一个核心约束，约束之间的优先顺序决定终点。

简化版口诀：

要快——LangSmith（前提是已在 LangChain 系）
要安全——Langfuse self-hosted
要复用现有栈——OpenLLMetry
要省代码改动——Helicone / Portkey
要做 eval 驱动开发——Braintrust / Opik

5. 这个市场还会怎么变

三个明确正在发生的趋势，会影响一两年内的选型有效期：

1. OTel GenAI Semantic Conventions 成熟。 一旦标准固定，专用平台和 OTel-native 路线的差距会缩小，“必须用专用 SDK"的理由会变弱。Langfuse、LangSmith、Phoenix 都在为这件事做准备（提供 OTel 兼容入口）。

2. Trace + Eval 合流。 Trace-first 平台都在快速补 eval（Langfuse 的 eval 模块、LangSmith 的 evaluations），Eval-first 平台也在补 trace（Braintrust 的 logging、Opik 的 traces）。三年后这两类的边界可能消失。

3. Gateway 路线的天花板。 Gateway 在零侵入上有结构性优势，但在 Agent 内部 chain / RAG 内部 retrieval 这两个最重要的"内部状态"上是结构性盲的。它会在"轻量场景的好选择"和"重型应用的不够用"之间分裂。

6. 自我证伪

如果以下任一条件成立，本文的"五种路线"框架就需要重画： ① 如果浏览器原生 / 端侧 LLM（on-device inference）成为主流——那么"调用链路 + 网关 + SDK"这个隐含假设就崩了，可观测的接入点完全不同。截至 2026-06： 端侧 LLM 在 PoC 阶段，但还远未成为主流流量。 ② 如果 OTel-native 路线完全吃掉其他四种——专用平台只剩"OTel-后端 + 可视化”——那么"五种路线"就退化成"一种路线 + 工具差异"。部分正在发生： Langfuse / LangSmith / Phoenix 都在补 OTel 兼容；但深度功能（prompt 治理、eval UI）目前还无法被通用 OTel 后端原生提供。 ③ 如果 Trace + Eval 在两年内合流为单一"统一信号"——那么 X / Y 轴中的 Y 轴消失。正在发生： Trace-first 平台都补了 eval，eval-first 平台都补了 trace；但完全消解可能需要 3–5 年而非 2 年。 ④ 如果监管 / 合规要求把"调用 LLM 必须留存完整 prompt + response 至少 N 年"立法——那么所有"日志可丢"的设计假设瓦解，存储 / 加密路线大改。截至 2026-06： 欧盟 AI Act、国内大模型管理办法都已有类似条款，但具体执行细则仍在迭代。

7. Key Takeaways

五种路线对应五种工程哲学：Trace-first（trace 是中枢）/ OTel-native（标准化最终赢）/ Gateway（零侵入）/ Eval-first（质量是核心信号）/ 传统 APM 扩展（少一个 vendor 是少一个）。
国内团队的现实起点通常是 Langfuse 或 Phoenix 开源版——数据合规是最强的非技术约束。
LangSmith 在 LangChain 重度场景下省时间，其他场景被开源对手抢走。
Gateway 路线有结构性天花板——看不到 Agent 内部和 RAG 检索内部，重型应用不够用。
三年后大概率剩 5–8 个产品——选型时把"哪天它消失我能不能撤"作为入场前的明确问题。
OTel GenAI Conventions 是当前最有可能成为终局的标准——选不选支持 OTel 会决定你三年后能不能跨厂商迁移。

8. L4 系列接下来的目录

#	篇目	重点
L4-1	Langfuse 深度解构	路线 A 开源代表，self-hostable 全栈、prompt 治理闭环
L4-2	LangSmith 深度解构	路线 A 嫡系代表，与 LangChain 生态耦合优劣
L4-3	OTel-native 路线	OpenLLMetry / Traceloop / Phoenix
L4-4	Gateway 路线	Helicone / Portkey / LiteLLM
L4-5	Eval-first 路线	Braintrust / Opik / TruLens / Weave
L4-6	Prompt Tracing 数据模型	跨厂商 schema 对比
L4-7	Agent Trace 超越 DAG	LangGraph / AutoGen / CrewAI
L4-8	Online vs Offline Eval 流水线	评估架构 / LLM-as-Judge 偏见治理
L4-9	RAG 可观测专题	检索质量 / embedding drift / citation
L4-10	成本、Replay、未来	收尾 + GenAI conventions 路线图

下一篇 L4-1 拆 Langfuse——国内场景最现实的起点。

主要参考

OpenTelemetry GenAI Semantic Conventions. github.com/open-telemetry/semantic-conventions——本文反复引用的标准化进展。
Langfuse Documentation. langfuse.com/docs——self-hostable + framework-agnostic 路线的代表。
LangSmith Documentation. docs.smith.langchain.com——LangChain 嫡系平台。
Arize Phoenix Documentation. docs.arize.com/phoenix——OTel-aligned 开源平台。
OpenLLMetry / Traceloop. traceloop.com / openllmetry.dev——OTel-native 路线代表。
Helicone / Portkey / LiteLLM / Cloudflare AI Gateway——Gateway 路线四代表（各自官方文档）。
Braintrust / Comet Opik / TruLens / W&B Weave——Eval-first 路线四代表（各自官方文档）。

1. 五种路线#

路线 A · Trace-first 专用平台#

路线 B · OTel-native#

路线 C · Gateway 路线#

路线 D · Eval-first#

路线 E · 传统 APM 扩展#

2. 选型坐标系#

3. 几个非技术维度#

4. 五种典型选型场景#

5. 这个市场还会怎么变#

6. 自我证伪#

7. Key Takeaways#

8. L4 系列接下来的目录#

主要参考#

1. 五种路线

路线 A · Trace-first 专用平台

路线 B · OTel-native

路线 C · Gateway 路线

路线 D · Eval-first

路线 E · 传统 APM 扩展

2. 选型坐标系

3. 几个非技术维度

4. 五种典型选型场景

5. 这个市场还会怎么变

6. 自我证伪

7. Key Takeaways

8. L4 系列接下来的目录

主要参考