上线一个智能体却不去度量它，等于把仪表盘用胶带糊住飞行：质量崩盘的第一个信号是用户投诉，成本翻三倍的第一个信号是发票。四款平台都提供同样三件原语——trace、数据集、评测器——功能清单几乎重合。真正把它们分开的那一点不在清单上：每款产品被设计去闭合的反馈回路不同。LangSmith 闭合 LangChain/LangGraph 的开发回路；Braintrust 用「Eval-as-code」闭合 CI 回路；Helicone 在不动你的 SDK 的前提下闭合生产网关回路；Arize Phoenix 闭合 OpenTelemetry 原生的监控回路，并把 ML 可观测性那一脉关于「漂移」的传统一并带了过来。
速览
四款产品，对同一个问题给出四种答案——团队究竟在生命周期的哪个时刻真正去看这些数据、并据此动手。下表先列基本信息；之后的矩阵呈现各自在真正存在差异的几条轴上最用力的方向。
| 平台 | 发布时间 / 维护方 | 主打场景 | OSS vs SaaS |
|---|---|---|---|
| LangSmith | 2023 年，LangChain Inc. | LangChain/LangGraph 开发回路——prompt、数据集、在线评测 | SaaS 优先（付费自托管层） |
| Braintrust | 2023 年，Braintrust Data Inc. | 把评测做成一等公民的 CI 产物，带回归 diff | SaaS（企业版自托管） |
| Helicone | 2023 年，Helicone Inc. | 网关优先的生产可观测性 + 成本 | Apache-2.0 开源（提供托管版） |
| Arize Phoenix | 2023 年，Arize AI | OpenTelemetry 原生的 LLM 可观测性 + 漂移 | Elastic-2.0 开源（Phoenix Cloud / Arize AX） |
快照：2026-06-01。这些平台更新频繁，请对照最新文档核实。
LangSmith — 架构详解
数据模型——runs、traces，以及带 prompt 版本的数据集
LangSmith 的一次「run」是一棵嵌套的子 run 树——每个节点对应一次 LLM 调用、工具调用、检索器调用或某个 chain 步骤——每个节点都带有输入、输出、延迟、token 用量、成本和自由的元数据。同一套 schema 既描述一次单元测试、一次 CI 评测，也描述一次生产请求；正因如此，一条被标记的生产 trace 可以直接被提升为数据集的一行，而不必重新建模。数据集本身是带版本、可 fork 的，于是「我们用来跑 prompt 变更的那 200 条黄金样例」就成了一个能钉死在某次提交上的一等公民对象。
它闭合的那条回路——prompt hub → 数据集 → 在线评测 → prompt hub
LangSmith 的重心是为基于 LangChain 或 LangGraph 的团队打磨 prompt 迭代回路。你在 Prompt Hub 里写 prompt，在 Playground 里针对数据集跑它，肉眼比对逐样例的 diff，用内置或自定义评测器打分，再把胜出的版本推回应用。在线评测器闭合回路的后半段：被采样的生产 trace 被异步打分，回归化作新的数据集行。同样的形态也支撑起 LangSmith Deployment 旗下的托管 LangGraph 运行时，所以开发回路与生产回路共享同一个控制面。如果你的应用已经是框架形状——通过 LangChain 栈接线的 graph、chain、agent——则这种契合最强，因为它们的埋点是免费的。
接入形态——SDK 回调，外加 OTel 支持
主要接入方式是 LangChain 的 tracer 回调：如果你已经在用 LangChain 或 LangGraph，接入只是设置一个环境变量。除此之外，@traceable 装饰器把任意 Python 或 JS 函数包成 LangSmith 的 span；平台也通过 OTLP 接收 OpenTelemetry 数据，因此标准化在 OTel 上的团队不会被锁在门外。但权衡是真实存在的：离开 LangChain 世界，你能拿到 trace，却放弃了一部分框架感知的 UI 能力——智能体步骤分组、prompt 版本联动——而这些恰恰是选择 LangSmith 的初衷。
Braintrust — 架构详解
Eval() 写在代码里，每个 PR 都跑一次，与基线 experiment 做 diff。数据模型——Eval-as-code 与不可变的 experiment
你在 Braintrust 中编写的单元是一个 Eval()——一个把数据集、任务（你的 prompt 或 chain）、scorer 列表绑在一起的函数，用 TypeScript 或 Python 写就，签入你的代码仓库。一次 Eval() 运行产出一个 experiment：一份不可变的构建产物，把每个样例、每次模型输出、每个 scorer 的得分以及聚合指标缝合成一个对象，可以永久链接、可以对比、可以与产出它的那次提交并排存档。数据集与 scorer 都是一等公民，且都有版本。autoevals 库提供一整套 LLM-judge、分类和相似度 scorer，像任何依赖一样 import 即可。
它闭合的那条回路——每个 pull request 都是一次评测运行
这正是 CI 回路。braintrust eval ./eval.ts 在 GitHub Actions 里每个 PR 都跑一次，产生的 experiment 与 main 上的基线 experiment 做 diff，逐样例的回归以 PR 评论形式出现、并附上并排的输出对照。黄金集上准确率掉了、单样例成本飙了、延迟回归——任何一项都可能让检查不过、卡住合并。这与「事后翻 trace 仪表盘」是完全不同的肌肉：它强迫你在每个 PR 上回答「这次变更是好是坏」，正是Evals 101把它定义为做认真 LLM 工作的最低门槛的那块肌肉。同样的原则下沉到 RAG 也成立——见评估 RAG对检索/接地/答案质量评测集长什么样的描述。
接入形态——包装器与在线日志
埋点是显式的代码而非「魔法」：wrapOpenAI() 包装一个客户端，@traced 包装一个函数，span 自然嵌套。也有在线日志——生产调用流入 Braintrust，可以播种新的数据集行——于是 UI 上的一次「踩」可以变成下一个 PR 的下一条回归测试。但重心是本地优先：评测在你的笔记本和 CI 里先跑，再去生产，这与「网关优先」的产品恰好相反。
Helicone — 架构详解
base_url，就能拿到 trace、成本、缓存与回放。数据模型——以被代理的请求为观测单位
Helicone 的单位是一个发往模型提供商的 HTTP 请求，在网关处被捕获。每一行都携带完整的 prompt、完整的响应、流式 chunk、延迟、token 计数、计算得到的成本、模型、提供商，以及 user/session/request 标签和你自设的任意自定义头。多步 agent 和 chain 通过 session ID 聚合——一个你为每段逻辑「对话」或「智能体运行」设置的 header——所以一个多工具的智能体循环看起来是一棵 session 树，而不是四十个互不相关的请求。它并没有内建图-节点抽象；网关看见什么就有什么。
它闭合的那条回路——不做 SDK 迁移的生产可观测性
Helicone 的卖点是：在一个已经上线的系统上拿到真正的仪表盘，所需的增量成本尽可能接近零。把你的 OpenAI 或 Anthropic 客户端指向 oai.helicone.ai/v1（或 Anthropic 的对应地址），加上一个 Helicone-Auth 头，发布。当天，单用户成本、p95 延迟、错误率、prompt 级别的慢查询、缓存命中率就出现在仪表盘上。缓存、重试、按用户/按 key 限流、PII 过滤，以及 AI Gateway 的跨提供商路由都坐在同一层——它们是网关的特性，不是可观测性的特性，但共用代理。这种权衡正是 LangSmith 的反面：你放弃了框架感知（没有节点 span，没有 prompt 版本联动），换回零迁移成本。回放与实验让你能把一个已被捕获的 prompt 换上新模型或新模板重新跑一遍、再用评测器打分，但万有引力中心始终是「我的生产此刻在做什么」。
接入形态——网关代理优先，OTel 可选
代理就是它的「线形状」，没有别的。对于无法改路由的场景，它也提供异步日志 SDK；项目也确实发送/接收一部分 OTel 信号，但标准安装就是「改一个 URL」。对那种成本、质量、延迟话题正发生在「平台账单」层面的团队——财务在问「那 4 万美元去哪了」、运维在问「为什么 14:00 99 分位炸了」——Helicone 是回答这些问题、又不改应用代码的最低摩擦路径。
Arize Phoenix — 架构详解
数据模型——OpenTelemetry 之上的 OpenInference span
Phoenix 不发明一套专有 trace schema。它的数据模型是 OpenInference——一份建立在 OpenTelemetry 之上的开放规范，为 LLM、retriever、embedding、工具调用、智能体步骤定义了 span 属性。埋点器就是 OTel 的自动埋点器——把一个 OTel SDK 指向 Phoenix 的 OTLP 端点，一次 LangChain、LlamaIndex、OpenAI SDK、Anthropic SDK 或 Bedrock 调用就会以结构化 LLM span 的形式出现，而你不必自己写包装。其含义是「可移植」：同一个已埋点的应用今天可以把 span 发给 Phoenix，明天发给 Jaeger、Tempo 或 Datadog，无需重新埋点。这个属性是其他三家所不具备的。
它闭合的那条回路——OTel 原生监控，加上 ML 可观测性的漂移
Phoenix 从其母公司 Arize 继承了ML 可观测性传统。这意味着「漂移」不是后补：RAG 输入上的嵌入相似度漂移、随时间变化的检索质量漂移、模型输出的 UMAP 聚类、分人群的回归——都是一等公民视图，是 ML 团队对表格类模型做了十年、又被搬到 LLM 时代的那种监控。phoenix.evals 是一个 Python 库，用于在已存储的 trace 上跑离线评测器（LLM-judge、幻觉、检索质量、自定义等），在 notebook 里很顺手。它闭合的回路是「在生产里监控，发现漂移，跑一段 notebook 评测，开一张工单」，而不是「卡住 PR」的回路。具体到 RAG，评估 RAG把嵌入漂移视图描述为最难「以后再补」的那一块——而 Phoenix 一开始就在这里。
接入形态——OpenTelemetry、开源、自托管优先
Arize Phoenix 在四者中是最名副其实的「开放」：Elastic-2.0 许可，pip install arize-phoenix 即可在 notebook 里跑起来，能扩到 Docker/Kubernetes 部署；Phoenix Cloud 是便利的托管选项，Arize AX 是 OSS 服务器装不下后的付费生产层。OTel 原生的设计是反向锁定的故事——你的埋点在构造上就是可移植的，Phoenix 的价值是叠在这种可移植性之上，而非藏在它之下。代价是工作流的密度：Phoenix 给你原语，但它不会像 Braintrust 那样把你推向 CI 工作流，也不会像 LangSmith 那样把你推向 Prompt Hub 工作流。回路需要你自己拼。
横向对比
埋点形态——SDK vs 代理 vs OTel
四款产品，trace 数据离开进程的方式有三种架构。LangSmith 与 Braintrust 都给你一个 SDK，但分坐「自动 vs 显式」的两端：LangSmith 与框架耦合（LangChain 的 tracer 回调免费触发；@traceable 装饰器覆盖剩下的部分），Braintrust 与包装器耦合（你用 wrapOpenAI 或 @traced 显式接入，胜在一次评测无非就是用这些包装器写出的另一个函数）。Helicone 走的是完全相反的路：代理坐在每个请求之前，所以埋点是改 base_url，不是改代码，权衡是你只能看见跨过线缆的东西。Phoenix 整个跳出「专有 SDK」框架去说 OpenTelemetry/OpenInference，是四者中唯一一个埋点能在「换供应商」之后存活下来的——重新指向 OTel 导出器，同一批 span 就能去任何地方。如果你的团队为栈的其他部分已经标准化在 OTel 上，这种不对称就是决定性的。
评测模型——离线 vs 在线 vs CI
四者都能对一个数据集跑 LLM-judge。它们在「评测应当生活在生命周期的哪个时刻」上分道扬镳。Braintrust的态度最强硬：评测就是代码，每个 PR 都跑，回归会卡住合并——「这次有没有变差」的答案在变更发布之前就到了。LangSmith跨在开发与生产之间：Prompt Hub 加上在线评测器，后者采样生产 trace、事后浮现回归。Helicone把评测锚定在被捕获的生产请求上——它的回放/实验流程用新模板重跑一个真实的生产 prompt，更像事后假设性分析，而不是发布前的门禁测试。Phoenix把评测器做成在 OTel trace 上跑的 Python 库（在 notebook 里顺手，做 CI 门禁较弱），并把嵌入漂移视图作为持续监控而非离散测试加在旁边。这些没有谁是错的；它们在不同时刻回答同一个问题，正确选择取决于你的 bug 是「我们在某个已知数据集上回归了」（Braintrust）、「生产看起来怪我想知道为什么」（Helicone、Phoenix），还是「我即将发布的这个 prompt 改动有风险」（LangSmith）。
开源 vs SaaS——以及谁持有数据
这条轴清楚地一分为二。LangSmith 和 Braintrust 都是 SaaS 优先的产品，对那些「不能把 prompt 发到供应商」的企业提供付费自托管层——其 OSS 部分是 SDK，不是存储你数据的后端。Helicone 和 Phoenix 是真正的开源：Helicone 的网关是 Apache-2.0，整套栈可以在你自己的机器上跑；Phoenix 是 Elastic-2.0，从一段 notebook 单元跑到 Kubernetes 部署都在设计内。对于受监管的工作负载——医疗、金融、政府——这一对是天然的起点，Phoenix 的 OTel 原生设计和 Helicone 的网关形态各覆盖问题的不同一半。对其他人来说，权衡是便利：SaaS 优先的产品在 UI 打磨和在线评测特性上更快；OSS 产品在可移植性和「我们持有数据面」上更快。
该选哪一个
| 使用场景 | 选 LangSmith，当…… | 选 Braintrust，当…… | 选 Helicone，当…… | 选 Arize Phoenix，当…… |
|---|---|---|---|---|
| 收紧 prompt 迭代回路 | 你生活在 LangChain/LangGraph 里，想要 Prompt Hub + Playground + 在线评测装在一个产品里。 | 你希望每次 prompt 变更都经由 CI 出货，合并前先看回归 diff。 | 不是天然合适——Helicone 看的是生产在做什么，不是开发即将发布什么。 | 你愿意在 notebook 里基于 OTel trace 自己拼出这条回路。 |
| 让评测卡 PR | 可以通过 SDK + CI 实现，但工作流没那么有主张。 | 这正是它的全部卖点——TS/Py 写 Eval()、回归 diff、阻断式 PR 检查。 |
回放/实验是事后的，不是 CI 门禁。 | 可以把 phoenix.evals 接进 CI，但它是库，不是工作流。 |
| 当天就拿到生产成本 + 延迟遥测 | 可以，但接入需要改 SDK。 | 可以通过包装器，但重心在离线运行。 | 是——把 base_url 指向网关，几分钟内仪表盘就亮起来。 |
如果你已经在跑 OTel，则可以；OpenInference 埋点器开箱给你成本 + 延迟。 |
| 监控嵌入/RAG 漂移 | 有限——不是它的赛道。 | 有限——不是它的赛道。 | 有限——网关层指标，不是嵌入空间指标。 | 这是从 Arize 继承下来的肌肉——UMAP、嵌入漂移、检索漂移。 |
| 自托管 + 自持数据面 | 仅企业付费层。 | 仅企业付费层。 | 可以——Apache-2.0，docker-compose 哪里都能跑。 | 可以——Elastic-2.0，notebook 跑到 Kubernetes。 |
| 厂商中立的埋点 | 支持 OTel，但价值是 LangChain 形状的。 | 与 SDK 耦合。 | 代理可移植，但数据落在 Helicone 形状的表里。 | OpenInference + OTel 是构造性的——重新指向导出器，留下同一批 span。 |
常见问题
用 LangSmith 一定要用 LangChain 吗？
不一定，但你会放弃大多数 LangChain 形状的 UI 能力。该平台通过 @traceable 装饰器从任意 Python 或 JavaScript 代码摄取 trace，也通过 OTLP 接收 OpenTelemetry 数据，所以非 LangChain 的栈也可以用 LangSmith 拿到 trace、数据集和评测器。但相对其他方案选 LangSmith 的真正理由是框架感知的视图——智能体步骤分组、Prompt Hub 中的 prompt 版本联动、graph trace 可视化——这些价值在你的应用本就是 LangChain 或 LangGraph 图时最高。
能不付 SaaS 钱就在本地跑 Braintrust 的评测吗？
可以——SDK 与 autoevals scorer 库都是开源的，braintrust eval ./eval.ts 能在笔记本或 CI runner 上跑你的评测套件并打印得分。失去 SaaS 后端，你失去的是持久化的 experiment 存储、并排回归 diff UI、用于 prompt 迭代的 Playground，以及把生产 trace 回流到数据集的在线日志路径。它的卖点正是「这些持久化产物让 CI 回路得以闭合」——只跑本地，对第一个评测还行，对第十个 PR 就力不从心。
Helicone 真的只是一个代理吗？如果我没法把流量绕到供应商怎么办？
标准安装是代理，但不是唯一选项。Helicone 也提供异步日志 SDK，在你的进程里捕获请求并流式发到平台，无需改路由，适合供应商 URL 固定或合规禁止重定向的场景。包括网关在内的完整 Helicone 栈是 Apache-2.0 的，所以「我不能把这发给供应商」的最强版本是把网关整套自托管——线形状不变，自家集群运行。
Arize Phoenix 和 Arize AX 有什么区别？
Phoenix 是开源的 LLM 可观测性项目——Elastic-2.0，免费，可自托管，并提供 Phoenix Cloud 作为托管版本。Arize AX 是同一家公司的付费生产层：继承 OpenInference 数据模型与嵌入漂移血统，并加上规模、告警、基于角色的访问控制，以及生产团队通常会买单的、面向非 LLM 模型的更宽的 ML 可观测性面。这是有意为之的「进阶路径」——开发阶段在 OSS Phoenix 上起步，等到生产规模或治理需要时再迁到 AX，由于两者都说 OpenTelemetry，无需重新埋点。
四者中哪些支持 OpenTelemetry？
四者都声称有一定支持；深度差别很大。Arize Phoenix 是构造性的 OTel 原生——OpenInference 是它的数据模型，埋点器就是 OTel 自动埋点器，于是同一批 span 能发给任何 OTel 后端。LangSmith 和 Braintrust 都接收 OTLP 数据，用作 OTel 管道里的 trace 汇聚点是足够的，但二者并非 OTel 优先设计，最丰富的特性预设你用它们自家 SDK 形状。Helicone 是网关优先；OTel 是次要路径。如果「埋点必须在未来换供应商时存活下来」在你清单上，Phoenix 是唯一一个不必带星号的答案。
我有几个单元测试，还需要评测平台吗？
单元测试覆盖确定性代码；LLM 行为不是确定性的。哪怕针对手工策划的黄金集跑一个非常小的 LLM-judge，也能抓到单元测试看不见的 prompt 回归，跑起来的代价是数小时而非数周——见Evals 101对最小可用配置的描述。要不要从「自己造」升级到「选个平台」，取决于你维护的评测器数量、改 prompt 的人数，以及「需要并排比较 run 而不仅仅滚屏看 log」的需求。在这条线之下，一份 CSV 测试用例加一段 Python 脚本是诚实的工作。
延伸阅读
本站相关内容：
- Evals 101——评测集真正包含什么、LLM-judge 为何不是免费的，以及任何平台之前的最小可用 harness。
- 智能体框架——框架在裸模型调用之上添加了什么；LangSmith 的价值在你的应用本就是框架形状时最浓。
- 成本、质量、延迟——这些平台所度量的三方权衡；网关级数字（Helicone 的主场）与质量分数（Braintrust 的主场）不可互换。
- 评估 RAG——检索/接地/答案质量的三段切分；在你选一个平台为它打分之前值得先看。
- 评估记忆质量——记忆特有的指标（recall@k、过期率、漂移），在一个本就懂嵌入的平台上更易监控。
项目来源：
- LangSmith 文档——runs、数据集、Prompt Hub、评测器、LangSmith Deployment。
- Braintrust 文档——Eval() as code、experiments、autoevals、在线日志、playground。
- Helicone 文档——网关代理、缓存、限流、sessions、AI Gateway 路由（源码在 github.com/Helicone/helicone）。
- Arize Phoenix 文档——OpenInference、OTel 埋点、phoenix.evals、漂移视图（源码在 github.com/Arize-ai/phoenix）。