这四个平台都能接收 OpenTelemetry，所以「它支持 OTel」已经不再是一个有用的答案：真正能让一条轨迹可迁移的那套词汇表——gen_ai.* 这组属性——到 2026 年末整体仍停在 Development 稳定级，并且已经搬进了自己的独立仓库，于是根本没有一份被冻结的契约供任何人去对齐。这一点在这里比在普通可观测性里更要紧，因为生产轨迹是你的智能体技术栈里唯一无法重新造出来的资产。评测可以重跑，提示可以重写，评判器可以重训，而上个季度的流量你无法重新观测一次。所以请按「谁拥有写入路径与批量读出路径」来选，并把许可证徽章当成它本来的样子：一件与此无关的事实。
速览
四个在功能表格上看起来可以互换、而在「退出」这件事上完全不可互换的平台。
| 平台 | 许可证 | 部署形态 | 最强之处 |
|---|---|---|---|
| Langfuse | MIT 核心；治理类功能走商业许可 | 云端，或在任意档位自托管 | 不用谈合同就同时拥有代码与数据存储。 |
| Phoenix（Arize） | Elastic License 2.0——源码可得，非 OSI | 单进程：pip、Docker 或 Helm | 一个下午就让一条检索形态的轨迹变得可读。 |
| Braintrust | 专有 | 云端；企业档可把数据面放进你的账号 | 把评测当成主工作流，而不是一个页签。 |
| LangSmith | 专有 | 云端；企业档可自托管 | 本来就身处 LangChain 与 LangGraph 手感之内的团队。 |
请把许可证那一列和部署那一列当成两件独立的事实来读，因为它们会朝两个方向分开。Phoenix 的许可证不是 OSI 认可的，而它照样把数据库交到你手上。Braintrust 从上到下都是专有的，而它照样可以把轨迹字节放进你自己的对象存储。这种组合在基础设施里少见到足以让大多数团队凭直觉把这四者排错序。
「支持 OpenTelemetry」说的是协议，不是契约
OTLP 是一种线上格式。它规定一条 span 如何被序列化与发送，却对这些字段叫什么名字一字未言。一条轨迹的可迁移性完全住在第二个问题里，而在 2026 年，这个问题的答案还没有定下来——定没定下来，厂商对比表是看不出来的。OpenTelemetry 注册表里的每一个 gen_ai.* 属性、span、指标与事件，都挂着 Development 稳定级的徽章。2026 年 6 月，生成式 AI 这套约定被从 open-telemetry/semantic-conventions 中分了出去，搬进一个专门的 semantic-conventions-genai 仓库，而那个仓库如今还一并承载了 MCP 与各家厂商特有的约定。
Development 稳定级是一个有实际后果的真实状态：处在这一级的属性可以在两个版本之间被改名或移除，而不享有一条稳定约定会得到的弃用窗口。所以当四家厂商都说自己支持 OTel 的 GenAI 约定时，它们各自对齐的是一个移动中的目标，停在不同的提交上，各自掺进了不同比例的自家词汇。Phoenix 甚至懒得假装不是这样——它原生对接 OpenInference，那是 Arize 自己那套 OTel 约定，为 chain、agent、retriever、embedding、tool、LLM 与 reranker 定义了明确的 span 类型。这可以说是更诚实的立场，而它同样是一种词汇锁定，只是换了个名字。
有一个只花二十分钟、胜过任何对比表的实操检验：把一次带三个工具调用与一个评判分数的智能体运行，发进一个试用账号。然后试着把它取回来。不是「有没有一个导出按钮」——而是：你能不能按你发送时用的那些名字、把你发送的那些属性批量取回来，而不被分页上限逼得把一年的历史变成好几周的活？这篇文章里其余的一切都是这个答案的下游。那套词汇表保证了什么、还没保证什么，见OTel GenAI 语义约定。
字节落在哪里
Langfuse——唯一一个代码与存储默认都归你的
Langfuse 在 2025 年 6 月把产品功能以 MIT 许可开源，自托管在任意档位都可用且不收使用费。轨迹、提示管理、数据集、LLM 充当评判器的评测、playground 与标注队列都包含在免费发行版里。走商业许可的是一份简短而具体的治理功能清单——项目级的基于角色的访问控制、SCIM、审计日志、受保护的提示标签、留存策略——需要一枚付费许可密钥。span 落进由你运行的 Postgres 与 ClickHouse，这让导出变成一条查询，而不是一份 API 预算。
结构性后果是：离开 Langfuse 是一个模式翻译问题，不是一个数据取回问题。这是这个品类里能拿到的最便宜的那种退出形状。
Phoenix——源码可得、单进程、原生 OpenInference
Phoenix 以单个进程运行，可用 pip、Docker 或 Helm 起，自托管时没有按事件计的上限，这让它成为四者里最快在一台笔记本上把轨迹渲染出来的那个。它的许可证是 Elastic License 2.0：广泛的内部使用与修改被允许，把 Phoenix 作为托管的受管服务对外提供不被允许，而它不是 OSI 认可的开源许可证。如果你的合规评审里有一个「它是否开源」的二值字段，那么这个字段在这里会朝两个方向都被答错——这份许可证限制的是你本来也不会去做的事，而它授予的恰是你真正在意的那件事。
Braintrust——专有引擎，你的对象存储
Braintrust 是评测优先的：追踪是为回归测试服务的，而不是反过来，而这一点体现在它手感好的那些地方。它的混合部署在企业档可用，用 Terraform 把数据面——API、Postgres、Redis、对象存储与 Brainstore——放进你自己的云账号，而由 Braintrust 托管控制面。Brainstore 是它自家的 Rust 引擎，把 span 写进对象存储，并用开源的 Tantivy 库为其建索引。
于是字节可以在你的账号里，而能高效读懂它们的那个东西不归你。这与开放内核和纯 SaaS 两种情形都是真正不同的风险画像：你的数据驻留与主权问题会拿到好答案，而你的退出问题拿到的答案，比存储位置给人的印象要差一些。
LangSmith——默认受管，自托管靠合同
LangSmith 是专有的、按用量计价的，只有企业档能自托管。对于本来就在写 LangChain 与 LangGraph 的团队，集成成本近乎为零，而轨迹视图与代码里的抽象是对齐的——这是一项真实而被低估的优势：一条映射你自己控制流的轨迹才会被人读，不映射的那种不会。代价是，在企业档以下的每一个档位上，代码与存储都是别人的，于是你的历史轨迹存在于某家厂商的分页上限之内。
许可证说的是代码，不是数据
这个失败模式值得直说，因为它是这个品类里最常见的一个错误。团队按「许可证有多开放」给这四者排序，得出「MIT 那个是可迁移的、专有那几个是陷阱」的结论，然后做出一个撞上真实迁移就撑不住的选择。
换成按退出成本排序，次序就变了。Phoenix 的许可证按 OSI 的定义不算开源，它给你的是一个你能 dump 的数据库。Braintrust 通体专有，它能把 span 字节放进你的 S3 桶。LangSmith 的企业自托管把整套东西放进你的 VPC，靠一份商业协议。而与此同时，一张你从未自托管过的托管档位上的 MIT 许可证，买到的是「运行你并没有在运行的代码」这项理论权利——它作为「万一厂商消失」的保险有点价值，而对于下个月把上个季度的轨迹搬进另一个工具这件事，一点价值也没有。
# Rank on these, in this order 1 can I run a bulk read of historical spans, un-paginated? 2 do the stored attribute names come from my code or the vendor's SDK? 3 where do the bytes physically sit, and under whose contract? 4 what is the licence? # Note what is NOT on the list dashboard quality — you will look at it twice a week number of integrations — you need two of them judge library size — you will write your own judges
这一切并不意味着许可证毫无价值：一份可以被撤回的商业许可是一条厂商风险条目，而它该待的地方是第三方与厂商风险，不是可迁移性那一列。
把那层转换自己握住，这道选择就变小了
这篇文章里最有用的东西不是一个排名。而是：可迁移性这个决定发生在平台的上游，发生在你只写一次的大约两百行代码里——一层薄薄的东西，夹在你的智能体循环与你用来导出的那个 SDK 之间，由你来决定那些一年后你仍会在意的事物的属性名：运行 id、任务类别、工具名、重试序号、按缓存状态拆分的令牌计数、评判结论与评判器版本、人工覆写。用你自己选的名字发出这些，在边界处把它们映射到厂商期望的样子，于是平台就成了架在你的模式之上的一个渲染器，而不是这个模式的所有者。
由此会得到两项性质，而它们正是这层转换值得花掉一个下午的理由。迁移期的双写从一个项目变成一次配置改动，于是你可以让两个平台并行跑一个月，用你自己的真实流量而不是一份演示数据集来比较它们。而 gen_ai.* 约定的那些变动则变成了别人的问题：上游某个属性被改名时，你改一张映射表，而你拥有的每一块仪表盘和每一条存下来的查询都继续工作。请钉住你所对接的那个约定版本、并有意识地去挪动它——这跟对待其他任何你的厂商无需一次部署就能改掉的东西是同一套纪律。
这层转换也有两件事修不了。它无法把你已经按某家厂商的模型积累下来的历史回溯性地迁走——这正是「在第一次生产运行之前做这件事、而不是在第一次续费之后」的论据。它也不会减少数据量：无论你选哪一个，轨迹成本都随流量伸缩，而杠杆是采样，所以请同时定下留存与采样策略——见轨迹采样与留存；并把脱敏放在这层转换里（它本该在那儿），而不是放在某个厂商的设置项里。
什么情况下选哪一个
| 情形 | 选 | 理由 |
|---|---|---|
| 受监管数据，而且看不到任何厂商合同的影子 | Langfuse | MIT 核心在任意档位都能自托管；存储归你，不用谈合同。 |
| 你今天就需要一条可读的轨迹 | Phoenix | 单进程、无事件上限、开箱即有检索形态的 span 类型。 |
| 你的瓶颈是回归测试，不是调试 | Braintrust | 评测是第一类对象；混合数据面回答了驻留问题。 |
| 通体 LangChain 或 LangGraph，小团队 | LangSmith | 集成成本为零，而轨迹映射的是你自己的控制流。 |
| 你预计一年之内会改主意 | 任选一个，加上那层转换 | 正是那层转换让第一个答案变得可逆。 |
再给这片领域一句诚实的总结：这四个没有一个是差的，各家仪表盘正在趋同，而十八个月后真正会对你起作用的那个差别，是你此刻正在积累的那些轨迹，有没有写在一套你掌控的词汇表里。这个决定你今天就在做了，无论你是否在有意识地做它。
常见问题
既然四者都接收 OTLP，那我以后再换不行吗？
你可以在一个下午里把新 span 的去处换掉。换不走的是历史：每个平台都按自己的模型存 span，所以搬一年的轨迹意味着经由现存的那条导出通路做一次批量读取，再加一次模式翻译。这就是为什么在试用期该问的是批量读取，不是接收。
OpenTelemetry 的 GenAI 约定可以作为标准来对齐吗？
可以采纳，但不能当成已被冻结。每一个 gen_ai.* 属性仍挂着 Development 稳定级，而这套约定如今住在一个专门的仓库里。按它们埋点、钉住你所对接的版本，并保留一层归你所有的映射，这样上游一次改名就只是改一个文件。
Phoenix 是开源的吗？
是源码可得。Elastic License 2.0 允许广泛的内部使用与修改，但不允许把 Phoenix 作为托管的受管服务对外提供，而且它不是 OSI 认可的。对大多数团队来说，这个区分在运维层面什么也不改变；而对一张带二值字段的采购清单来说，它改变了答案。
Braintrust 的混合部署是否意味着数据归我？
字节及其位置归你——在企业档，包括 Brainstore 在内的数据面通过 Terraform 跑在你的云账号里。而能高效读懂它们的那个引擎仍是专有的，所以驻留问题被答得很好，退出问题被答得比存储位置暗示的要差。
在做选择之前最该先建的那一件东西是什么？
那层埋点转换：由你自己为运行 id、任务类别、工具名、重试序号、按缓存状态拆分的令牌计数、评判结论与评判器版本命名。大约两百行，写一次，而它把平台选择从一道单向门变成了一个配置值。
延伸阅读
本站相关：
- OTel GenAI 语义约定——这套词汇表覆盖了什么、又还没承诺什么。
- 智能体的追踪与可观测性——一条有用的智能体 span 首先该包含什么。
- 轨迹采样与留存——这四家都不会替你拉的那根成本杠杆。
- 评测驱动的智能体开发——Braintrust 围绕着组织起来的那套工作流。
- 智能体可观测性——如果你是不带词汇表来的，先看这页概念。
项目来源：
- Langfuse——MIT 核心、任意档位可自托管，以及那份企业治理清单。
- Arize Phoenix——Elastic License 2.0、OpenInference span 类型。
- Braintrust——OTLP 接收、混合数据面、Brainstore。
- LangSmith——各档位与自托管可用性。
- open-telemetry/semantic-conventions-genai——那个专门的 GenAI 约定仓库。