四大 LLM 可观测性平台横评：Langfuse vs Helicone vs Opik vs Phoenix

第一条 trace 在每个平台看起来都一样

用任意一个开源可观测性 SDK（Langfuse、Helicone、Opik、Phoenix，用哪个无所谓）包装你的 LLM 客户端，第一个结果都是一样的：请求发出，仪表板里出现一个 span，带有 prompt、响应内容以及耗时。这部分已经解决了。这个领域的每一个落地页都做了一样的宣称的，而对于第一条 trace 而言，他们说的都是实话。

接下来每个团队问的下一个问题也都一样： 这个工具能否对一个 trace 采取行动，而不只是展示给我看？给它打分。通知相关人员。在它上线之前拦截它。表面上看这也解决了——四个平台都有 "Evaluation" 标签页和 "Settings" 页面，所以很容易认为它们在这一块也是殊途同归。

但并非如此。我现在把四个平台都自托管了，把每个仪表板并排放在一起看，有四个特定的能力让我停了下来——每一个都是某一个平台的独家亮点，而在另外至少两个平台上完全缺失。因为"它能做可观测性"就选了某个工具，六个月后才发现你实际需要的那个功能在你没选的仪表板里——这是一个昂贵的教训。

Langfuse —— 一个 LLM judge，自动对每条生产 trace 打分，无需人工审核步骤。

Helicone —— 一个独立的限速规则构建器，与简单的消费上限不同。

Opik —— 主题和 PII guardrails，直接检查调用的输入或输出，可按项目配置。

Phoenix（由 Arize 构建）—— PXI，一个停靠在仪表板内的 AI agent，已经知道你正在查看的 trace。

Opik 是唯一一个同时满足四个行中的两个的平台。完整对比如下。

Langfuse：永不休眠的 judge

大多数平台的"评估"意味着人工点击，针对某个数据集运行一次。Langfuse 的 Evaluators 页面做的事不太一样：你写一个 eval 模板——一个评分 prompt、一个模型、以及它应该读取的 trace 变量——然后每有一条新的生产 trace 到达，它就拿那个模板去跑一次。整个流程里根本没有"运行实验"按钮。

这就是在评估这个功能时决定性的细节：评分是你手动触发的东西，还是在你打开仪表板之前就已经在运行的东西？

Langfuse 自己的文档里走通了设置流程。Opik 的 Online evaluation rules 换了名字做了同样的事情（见上表），所以 Langfuse 并非完全独霸这个领域——但在这个工具上是它第一个让我发现这个功能的，而且执行 tracing 还延伸到了 evaluator 本身，作为额外收获。

Takeaway：如果需求是无人值守、持续运行的 trace 评分，Langfuse 和 Opik 是这里为此而建的两个平台。Helicone 和 Phoenix 仍然需要有人显式触发一次运行。

Helicone：限速规则，不是消费上限

消费预算回答一个问题：这个应用花多少钱会停掉。限速规则回答的是另一个问题：在这个时间窗口内，这个特定用户可以发多少请求，与任何成本无关。

Helicone 的 Monitor → Rate Limits 页面有一个 "Create Rule" 构建器，正好用来回答第二个问题。一个规则包含一个配额、一个时间窗口、一个单位（请求数、token 数或美元数）、以及一个维度——用户、团队或全局——表达为类似 10;w=1000;u=cents;s=user 这样的 header，意思是"每 1000 秒每个用户 10 美分的请求量"。Helicone 的文档里有完整语法说明。

Takeaway：如果某个噪声用户需要限流，而不想把整个应用预算关掉让所有人都受影响——那是限速规则，不是消费上限，而 Helicone 是四个平台中唯一把限速规则作为独立对象提供的。

Opik：检查调用本身的 guardrails

上面所有功能都是在调用发生之后对它进行评分或告警。Opik 的 guardrails 则直接在调用上操作——根据你启用哪个检查项，在模型看到它之前或之后。

"Set a guardrail" 面板有两个检查项：一个 Topic guardrail（一个敏感度滑块加一个逗号分隔的受限主题列表）和一个 PII guardrail（按类别切换——信用卡号、电话号码、邮箱，以及更多——每个都有各自的敏感度阈值）。两者都附带一个现成的 opik.guardrails Python 代码片段。Comet 的公告文章里有每个检查项触发条件的说明。

Takeaway：如果需求是在内容上线之前就拦截掉某一类内容，而不是事后评分，guardrails 是这个列表里唯一为此构建的功能——而且 Opik 是唯一一个同时具备这个功能和自动评分规则的平台。

Phoenix：PXI，那个已经了解你 traces 的助手

PXI 是一个聊天面板，嵌入在 Phoenix 的每个页面里，预置了"Find critical issues"和"Explain a concept"这样的建议。它之所以不仅仅是挂在产品上的文档机器人，关键细节在于：它从你当前所在的页面读取数据，所以它能回答关于你自己的 traces 的问题，而不需要你粘贴 trace ID 或复制 payload 进去。Arize 的文档把它描述为一个能调试 trace、构建 evaluators、并在你当前正在查看的上下文中运行实验的 agent。

Takeaway：如果需求是"解释这个 trace 里正在发生什么，就现在，不用切换工具"，Phoenix 是这里唯一一个拥有针对当前页面范围提供服务的助手的平台。

这四个特性没有一个能决定哪个工具"最好"——它们决定的是哪个工具适合你可能还没有遇到的需求。不需要无人值守评分的团队不会想念 Langfuse 的 judge 或 Opik 的在线评估。只用内部聊天机器人的五人团队不会想念 Helicone 的限速规则。

但如果你是今天在假设"可观测性"是一个已解决、可互换的复选框的基础上选平台，这就是这个假设会破掉的四种方式：自动化生产 trace 评分、真正的限速对象、内容 guardrails、以及仪表板内 agent。在你包装第一个客户端之前检查这四个里你实际需要哪个，而不是之后。

这四个里你实际会用哪一个——有没有第五个我遗漏的仪表板功能值得拥有自己的一行？