Agent 可观测性平台:Langfuse、Phoenix 与 Opik

Agent 可观测性平台:Langfuse、Phoenix 与 Opik

本节摘要:第 23 节的 OTel GenAI 给了你 span 的模式(schema),但你还需要一个平台——它要摄取 span、跑评估、存提示版本、浮现回归。2026 年,三个开源平台主导了这个领域,各自强调生命周期的不同部分。Langfuse(MIT 许可,每月 600 万+ SDK 安装、1.9 万+ GitHub star)是全能型:追踪 + 带版本与 playground 的提示管理 + 评估(LLM-as-judge、用户反馈、自定义)+ 会话回放;2025 年 6 月起,原商用模块(LLM-as-judge、标注队列、提示实验、Playground)在 MIT 下开源。Arize Phoenix(Elastic License 2.0)做更深的 Agent 专用评估:追踪聚类、异常检测、RAG 检索相关性,带原生 OpenInference 自动仪表化,定位是配合更宽平台的「漂移/行为回归」工具(无提示版本管理)。Comet Opik(Apache 2.0)主打优化循环:经 A/B 实验的自动提示优化、护栏(PII 脱敏、话题约束)、LLM-judge 幻觉检测。据 Maxim(2026 年现场分析),89% 的组织已部署 Agent 可观测性,质量问题是头号生产障碍(32% 受访者提及)。本节吃透三者取舍,并用标准库实现一个「追踪采集 + LLM-judge 评估」流水线,产出失败率、失败原因 Top、评估分分布的仪表盘式摘要。读完本节,你应能避免「只追踪不评估、自造 LLM-judge 无锚定、提示版本不挂追踪」三种陷阱。

对应原课程:Phase 14 · Lesson 24 · agent-observability-platforms(原英文 phases/14-agent-engineering/24-agent-observability-platforms/docs/en.md)。前置:第 23 节(OTel GenAI)。

学习目标

阅读完本节,你应当能够:

1. 说出三大开源 Agent 可观测性平台及其许可证。
2. 区分各自最强项:Langfuse(提示管理 + 会话)、Phoenix(RAG + 自动仪表化)、Opik(优化 + 护栏)。
3. 解释为何 2026 年 89% 的组织已部署 Agent 可观测性,且质量是头号障碍。
4. 用标准库实现一个「追踪→仪表盘」流水线,含 LLM-judge 评估。
5. 识别三种失败:无评估策略、自造 LLM-judge 无锚定、提示版本不挂追踪。

一、问题与直觉

OTel GenAI(第 23 节)给了你模式——span 该长什么样。但你还需要平台:谁来摄取这些 span、跑评估、存提示版本、在生产回归时告诉你「是哪个提示改动导致的」?

这正是 Langfuse、Phoenix、Opik 三个 contenders 解决的问题。它们都消费 OTel GenAI span(所以底层一致),但在生命周期侧重不同:

Langfuse(MIT)

• 每月 600 万+ SDK 安装,1.9 万+ GitHub star。
• 功能:追踪、带版本 + playground 的提示管理、评估(LLM-as-judge、用户反馈、自定义)、会话回放。
• 2025 年 6 月:原商用模块(LLM-as-a-judge、标注队列、提示实验、Playground)在 MIT 下开源。
• 最强项:端到端可观测性 + 紧密的提示管理闭环。

Arize Phoenix(Elastic License 2.0)

• 更深的 Agent 专用评估:追踪聚类、异常检测、RAG 检索相关性。
• 原生 OpenInference 自动仪表化。
• 配合托管 Arize AX 用于生产。
• 无提示版本管理——定位是配合更宽平台的漂移/行为回归工具。
• 最强项:RAG 相关性、行为漂移、异常检测。

Comet Opik(Apache 2.0)

• 经 A/B 实验的自动提示优化。
• 护栏(PII 脱敏、话题约束)。
• LLM-judge 幻觉检测。
• Comet 自测基准:Opik 日志 + 评估 23.44 秒 vs Langfuse 327.15 秒(约 14 倍差距)——厂商基准仅作方向性参考。
• 最强项:优化循环、自动实验、护栏执行。

行业数据

据 Maxim(2026 年现场分析):89% 的组织已部署 Agent 可观测性;质量问题是头号生产障碍(32% 受访者提及)。这意味着「没有可观测性的 Agent」在 2026 年已属少数——可观测性是入场券,不是加分项。

选哪个

⚠️ 三种失败模式:① 无评估策略——只追踪不评估,等于昂贵的日志;追踪的价值在于回答「这次运行好不好」,这必须靠评估。② 自造 LLM-judge 无锚定——第 05 节 CRITIC 模式适用:judge 需要外部工具做事实核验,纯语言自评会幻觉。③ 提示版本不挂追踪——生产回归时,你无法二分定位到是哪个提示改动导致的。

二、从零实现

原课程 code/main.py 实现一个标准库追踪采集器 + LLM-judge 评估器:

• 摄取 GenAI 形状的 span。
• 按 session 分组,标记失败运行(护栏绊倒、低置信评估)。
• 一个脚本化 LLM-judge,按评分量表给 Agent 响应打分。
• 一个仪表盘式摘要:失败率、失败原因 Top、评估分分布。

Step 1:span 摄取 + 按 session 分组

class TraceCollector:
    def __init__(self): self.sessions = defaultdict(list)
    def ingest(self, span):
        sid = span.attrs.get("session_id", "default")
        self.sessions[sid].append(span)
    def failures(self, session):
        return [s for s in self.sessions[session]
                if s.attrs.get("error") or s.attrs.get("guardrail_trip")]
​

Step 2:LLM-judge 评分量表

RUBRIC = {
    "factual":   "响应在事实层面正确吗?(1-5)",
    "scope":     "响应是否停留在范围内,未越界?(1-5)",
    "complete":  "响应是否完整回答了请求?(1-5)",
}

def llm_judge(response, request):
    # 真实版用第二个 LLM 按量表打分;这里脚本化
    return {k: script_score(response, request, v) for k, v in RUBRIC.items()}
​

Step 3:仪表盘式摘要

def dashboard(collector, judge):
    fails = sum(len(collector.failures(s)) for s in collector.sessions)
    total = sum(len(v) for v in collector.sessions.values())
    reasons = Counter(s.attrs.get("fail_reason") for s in all_fails(collector))
    scores  = [judge(r.response, r.request)["factual"]
               for r in completed_runs(collector)]
    return {"failure_rate": fails/total,
            "top_reasons":  reasons.most_common(3),
            "eval_dist":    histogram(scores)}
​

运行 python3 code/main.py 会输出每 session 的评估分与失败分类,匹配 Langfuse/Phoenix/Opik 会展示的东西。

💡 设计要点:可观测性的价值不在「看见」,而在「判断好坏 + 定位回归」。这三个动作——追踪、评估、提示版本挂 trace——缺一不可。只追踪是昂贵日志;追踪 + 评估能判断好坏;再加提示版本挂 trace,才能在生产回归时二分定位。

三、框架对比

三者都消费 OTel GenAI span(第 23 节),所以底层可互换——换平台不必改 Agent 代码,只改导出目标。

四、可复用产物

原课程 outputs/skill-obs-platform-wiring.md:为给定平台把追踪 + 评估 + 提示版本接进一个已有 Agent,含许可证检查(是否接受 ELv2)、自动仪表化配置、LLM-judge 量表模板。

五、练习

1. (Easy) 把一周的 OTel 追踪导到 Langfuse 云(免费层)。哪些 session 失败了?为什么?
2. (Medium) 为你的领域写一个 LLM-judge 量表(事实正确性、语气、范围遵从)。在 50 条 trace 上测。
3. (Medium) 对比 Langfuse 提示版本管理与 Phoenix 的追踪聚类。哪个更快告诉你什么坏了?
4. (Hard) 读 Opik 护栏文档,为你的某次 Agent 运行接一个 PII 脱敏护栏。
5. (Hard) 在你的语料上基准这三者。忽略厂商发布的数字,测你自己的。

本节要点回顾

1. OTel 给模式,平台给能力:第 23 节的 span 模式是地基,平台在其上提供摄取/评估/版本/回归。
2. Langfuse(MIT):全能型,追踪 + 提示版本 + playground + 评估 + 会话回放,2025-06 商用模块开源。
3. Phoenix(ELv2):Agent 专用深度评估,RAG 相关性 + 追踪聚类 + 异常检测 + OpenInference 自动仪表化,无提示版本。
4. Opik(Apache 2.0):优化循环,A/B 自动提示优化 + 护栏(PII 脱敏)+ LLM-judge 幻觉检测。
5. 89% 组织已部署:2026 年可观测性是入场券;质量是头号障碍(32%)。
6. 选型矩阵:全能+提示选 Langfuse,深度 RAG/漂移选 Phoenix,优化+护栏选 Opik,已跑 Datadog 选 Datadog LLM Obs。
7. 底层可互换:三者都消费 OTel GenAI span,换平台不必改 Agent 代码。
8. 三种失败:无评估策略(昂贵日志)、自造 LLM-judge 无锚定(用 CRITIC 第 05 节)、提示版本不挂 trace(无法二分定位回归)。
9. 可观测性三动作:追踪 + 评估 + 提示版本挂 trace,缺一不可。
10. 厂商基准仅方向性参考:Opik vs Langfuse 的 14 倍差距要自测,勿轻信。

下一节,我们看多智能体如何通过**辩论(debate)**提升答案质量——多个 Agent 各自独立作答、互相批判、收敛到更鲁棒的结论,以及它在什么条件下真正有效、何时只是浪费 token。