配套：篇（十四）全链路追踪与可观测性
本篇定位：篇14 讲了"怎么埋 trace，用 _meta 注入 W3C traceparent"。本篇回答紧接着的问题："埋完用什么看、用什么评？"对三大开源/主流可观测与评测工具做一次横向评测。
范围：聚焦 MCP/Java 视角下的接入成本与适用场景，不做厂商背书。

---

一、为什么需要这一层：监控 ≠ 评测

篇14 的 trace 让你看见调用链——哪一步慢、哪一步错、跨几个实例。但 Agent 生产化真正卡住企业的，是第二件事：知道好坏。

把能力拆成三层，别混：

层	回答的问题	代表手段
trace（看见）	这次调用经过了什么	篇14 的 _meta 注入 + W3C traceparent
metrics（量化）	调用多频繁、花多少 token	限流计数、成本计量（见篇13 散点）
eval（评好坏）	这个回答对不对、稳不稳	评测集、在线回归、质量打分

Gartner 2026 指出 85% 企业把"全链路可观测性"列为 Agent 生产化首要门槛，远超模型性能——说的就是这三层都得有，而 trace 只是第一层。

本篇横评的三个工具，正好分别在不同层有侧重。

---

二、横评维度

维度	Langfuse	Braintrust	Phoenix（Arize）
核心定位	trace + eval 一体，开源自托管	评测集 / 在线回归强，偏开发循环	LLM 可观测 + 追踪，OpenInference
MCP/Java 接入	OTel 兼容，有 Java SDK；_meta span 可直接喂	主要 Python/TS SDK，Java 需自接	OpenInference 语义约定，多语言
trace 可视化	✅ 强	中（偏实验结果视图）	✅ 强，工件级可视化
token / 成本归因	✅	✅	✅
评测集管理	✅	✅✅ 最强	中
自托管 / 云	均可（MIT/Apache）	云为主，可私有	均可（开源）
OpenTelemetry 兼容	✅	部分	✅（OpenInference 基于 OTel）

⚠️ 待核实：三者的 Java SDK 成熟度与 MCP 一等支持在快速演进，以上以 2026-10 公开文档为准；写正文前二次核验最新状态，别写死。

---

三、Langfuse —— trace 与 eval 一体，最贴合"埋完就看"

开源自托管（MIT/Apache），同时覆盖 trace 与 eval，且与 OpenTelemetry 兼容——这意味着篇14 注入的 traceparent 能直接对接，不用另起一套。

接入思路（与篇14 方法论对接）：

// 篇14 在 _meta 注入 traceparent；这里把它透传给 Langfuse 的 trace/span
// 伪代码示意：把 MCP 调用链的每个 tool 调用包成一个 Langfuse span
LangfuseSpan span = langfuse.span(
    SpanInput.builder()
        .traceId(traceparent.traceId())   // 复用篇14 的 traceId
        .name("call_tool:" + req.name())
        .input(req.arguments())
        .build());
try {
    McpClientResult r = client.callTool(req);
    span.end(SpanOutput.builder().output(r).build());
} catch (Exception e) {
    span.end(SpanOutput.builder().error(e).build());
}

⚠️ 待实测：本机跑通后补一张"一次 MCP 工具调用在 Langfuse 里的完整 span 树"截图——这是本篇最有说服力的证据，也是验证"篇14 方法论能被外部工具消费"的闭环。

适用：想自托管、要 trace 和 eval 同一套、且已是 OTel 体系的中小团队。

---

四、Braintrust —— 评测集与在线回归最强

Braintrust 的强项不是"看调用链"，而是"改了 Prompt/工具后跑回归"：把一批期望输入-输出做成 dataset，每次改动自动算分。

这对 MCP 特别有用：工具的行为变了，怎么证明没回归？ 把 tool 的入参-期望出参固化成 dataset，CI 里每次发布前跑一遍。

适用：已经有"调优-验证"开发循环、重视评测集管理的团队；纯看 trace 的需求它不如另两个。

---

五、Phoenix（Arize）—— LLM 调用级深度可视化

Phoenix 基于 OpenInference 语义约定（构建在 OpenTelemetry 之上），对 LLM 调用、工具调用、检索步骤有细粒度的 span 与工件（artifact）可视化，自托管方便。

适用：想把"模型调用 + 工具调用 + 检索"放在同一张可观测图里钻取的团队；和篇14 的 trace 理念一致，只是更偏 LLM 语义层。

---

六、传统 APM 补位：SkyWalking vs Jaeger（Java 团队的"本命"选项）

前三节评的三个工具偏 LLM 语义 / 评测层，适合"看 Agent 脑子怎么转"。但 MCP 服务本质是 Spring Boot Java 后端，传统 APM 才是多数 Java 团队的日常——它们对 HTTP/gRPC/DB/线程池自动埋点，开箱即看。这里补一张与篇14 最相关的对照：

维度	SkyWalking	Jaeger
血缘 / 定位	国产 APM，中文 Java 企业圈最普及	CNCF 毕业，云原生 trace 标准代表
Java 自动埋点	✅ Java agent 无侵入，Spring Boot 开箱即用	需 OTel agent / 手动埋（篇14 即手动 _meta 注入）
接收 MCP trace	✅ 已支持 OTLP 直收（把 Collector 指向其 OAP）	✅ 原生 OTLP（篇14 演示后端）
看板 / 拓扑	服务拓扑图、依赖分析强	trace 查询 + 瀑布图强，拓扑弱
多语言	Java 最强，其他靠 OTel 桥接	多语言原生（OTel 生态）
选谁	纯国产 Java 单体/微服务、要熟悉 UI 和拓扑	跨语言、上 K8s、要标准底座不绑厂商

要点：这两个都不是篇14 的核心——篇14 的 _meta 注入把 traceparent 喂进 OTel 体系后，想存 Jaeger 还是 SkyWalking，只差 Collector 一个 export 端点。对本文读者（Java 团队）的务实建议：注入用 OTel（标准、可移植），看板用 SkyWalking（眼熟、拓扑全），两端 OTLP 直连即可。

---

七、选型建议 + 与第二季的关系

你的首要诉求	选谁
埋完就想看调用链 + 顺手做 eval	Langfuse
要评测集、要改完跑回归	Braintrust
要 LLM/工具/检索一体化深度可视化	Phoenix

互链：

• → 篇（十四）：本篇所有接入都建立在篇14 的 _meta traceparent 注入之上，篇14 是"因"，本篇是"果"。
• → 篇（九）L6 审计：trace 是可观测的一面，结构化审计日志是另一面，两者互补不替代。

---

八、诚实边界

• 三个工具生态偏 Python/TS，Java 接入成熟度需本机实测核实；本篇重点放在"接 MCP trace"而非深度评测功能，避免超出本季 Java 栈能力。
• 横评保持中立，给"适用场景"而非"谁最好"；具体 API 以官方文档为准，规范演进快，写定时标注版本与时间。
• 真实 span 截图、dataset 回归示例均为待实测项，占位待补。