6.2 工具格局与选型
6.2 工具格局与选型
本节摘要：跑通了第 6.1 节的 170 行，你已经知道 span 怎么长出来、账怎么算出来、告警怎么触发——现在可以诚实地问：这些要不要交给现成工具？本节按三层看 2026-10 的格局：标准层，OpenTelemetry GenAI 语义约定（
gen_ai.*属性族）截至 2026-10 仍为实验态（官方），期间还发生过属性改名破坏兼容的事件（社区），对策是给自己的埋点加一层属性隔离；平台层，Langfuse（核心开源、可自托管）、Arize Phoenix（开源、可自托管、评测见长）、LangSmith（LangChain 系商业 SaaS，自托管仅企业级）各有取向；采集层，OpenLLMetry 是 OTel 系自动插桩 SDK，本身不是后端。四件工具过一张对比表（口径 2026-10，以各官方文档当期版本为准），然后给一套不排名的判定框架：六问加一棵决策树——数据主权、插桩侵入度、评测深度、生态绑定、拥有成本、团队技能。结论先行：工具替你省的是重复劳动，替不了的是第 1.2 节那张能力清单。
学习目标
- 描述 2026-10 的三层工具格局：标准层、采集层、平台层各是什么
- 说清 OTel GenAI 语义约定实验态的风险与对策（属性隔离层）
- 用六问判定框架评估任意一款观测工具，而不是看排行榜
- 用第 2.3 节数据策略与 21 问清单反向审问候选工具
一、格局总览：三层各就各位
你的应用 │ 埋点（SDK/自动插桩） ▼ 采集层 ── OpenLLMetry（OTel 系自动插桩 SDK）、OTel SDK 本体 │ 按 OpenTelemetry 协议导出 ▼ 标准层 ── OTel GenAI 语义约定（gen_ai.* 属性族，实验态） │ 定义"属性叫什么名、记什么值" ▼ 平台层 ── Langfuse · Arize Phoenix（开源自托管） LangSmith（商业 SaaS）· 各云厂商观测产品
这三层可以组合：用 OpenLLMetry 自动插桩采集、遵循 OTel GenAI 约定命名、导出到自托管的 Phoenix——这就是"不绑定单一平台"的经典路线（社区常见组合）。
二、标准层：OTel GenAI 语义约定的现状与对策
第 2.1 节埋过伏笔：属性键名向 gen_ai.* 看齐。到选型时必须知道三件事（口径 2026-10）：
- 仍是实验态：全部
gen_ai.*span 与属性仍标记为开发中/实验态（官方），属性名可能随版本变化，不承诺向后兼容； - 变动真的发生过：实验期间发生过属性改名（如系统标识属性更名）导致按旧属性名做报表的后端被动失效（社区）——实验态不是理论风险；
- 对策是隔离层：不要让
gen_ai.*字符串散落在业务代码里。第 6.1 节的做法就是范例——业务侧用统一函数把 usage 写进 span，键名集中在一处（mock_llm外的那一行gen_ai.usage.*拼接），约定再变也只改一行。
💡 顺带回收一个伏笔：第 2.1 节建议属性名向 OTel GenAI 看齐、第 2.2 节建议跨服务传播用 W3C Trace Context 的 traceparent——两件事的共同理由在本节兑现：跟标准走不是为了标准本身，是为了换后端时不重写埋点。
三、平台层：四件工具对比（口径 2026-10）
| 维度 | Langfuse | OpenLLMetry | Arize Phoenix | LangSmith |
|---|---|---|---|---|
| 是什么 | LLM 工程平台 | OTel 系自动插桩 SDK | 观测 + 评测平台 | 商业观测/评测 SaaS |
| 采集方式 | 自家 SDK 与 OTel 兼容接入，主流框架集成多 | 字节码/框架级自动插桩，覆盖面广 | OpenInference 标准 SDK， notebook 内调试是特色 | LangChain 生态深度集成 |
| 部署形态 | 核心开源、支持自托管 | 是库不是平台，导出到任意 OTel 后端 | 开源、支持自托管 | SaaS 为主，自托管限企业级 |
| 评测能力 | 在线/离线 evals、用户反馈、prompt 管理 | 不做（交给后端） | 实验与 evals 是强项 | evals 强项，回归测试集成顺 |
| 成本口径 | 花费按模型定价表折算（配置而定） | 透传 usage，口径取决于后端 | token 与花费面板（配置而定） | 用量与花费报表（配置而定） |
| 最适合谁 | 要一个齐整的自托管平台 | 想少写埋点、后端保持自由 | 重评测、重实验的算法团队 | 已深度使用 LangChain 的团队 |
（以上格局截至 2026-10 公开资料，官方与社区口径混合；各家功能与许可演进很快，采购决策前一律以官方文档当期版本为准，本表只供建立坐标系。）
三个容易误读的点：OpenLLMetry 不是平台——它解决"埋点怎么少写"，不解决"数据存哪、报表谁出"；LangSmith 的深度绑定是双刃剑——LangChain/LangGraph 用户启动飞快，但非 LangChain 应用的接入体验明显打折（社区评价）；自托管不等于免费——Langfuse/Phoenix 自托管要算上存储、升级与运维的人力（第 6.1 节的 170 行已经让你体会过最小版本的工作量）。
四、判定框架：六问加一棵决策树
不排名，因为四个变量的权重因团队而异。六问按顺序过：
- 数据主权：观测库含用户原文，能否出你的墙？金融、医疗、政企通常一票否决 SaaS（除非有专属区域方案，以官方条款为准）；
- 插桩侵入度：自动插桩（OpenLLMetry 类）省事但黑盒，手动埋点（第 6.1 节式）可控但费人——你的团队改得动多少业务代码？
- 评测深度：第 4 章的探针是自建 rubric 还是平台 evals？裁判成本谁付（LLM 裁判也要花钱，第 3 章账本管得住它吗）？
- 生态绑定：换掉这个工具要重写多少埋点？跟标准（OTel GenAI、traceparent）走的埋点迁移成本最低；
- 拥有成本：许可、SaaS 计费与自托管的运维人力，加上观测数据自身的存储成本（第 2.3 节热温冷三档的估算直接用上）；
- 团队技能：有 SRE 编制、能扛自托管升级，还是三个应用工程师兼职观测？
（决策树，示意） 要求数据不出墙？──是──▶ 排除纯 SaaS ──▶ 自托管平台（Langfuse/Phoenix 类） │ 否 或 自建（第 6.1 节路线 + 落库 + 面板） ▼ 重度使用 LangChain？──是──▶ LangSmith 起步最快 │ 否 ▼ 想少写埋点？──是──▶ OpenLLMetry 插桩 + 任选后端（保持可迁移） │ 否 ▼ 手动埋点（已按 OTel 命名）+ 按六问 3/5/6 选后端
五、选型之外的三条提醒
- 工具不等于能力：第 1.2 节清单的 21 问没有一问是"你们用什么工具"。买了平台但数据没接全、没人会查，L1 依然是"部分"；
- 用第 2.3 节数据策略反向审问：能否按数据域分别配采样？脱敏在采集端还是服务端？留存能否按域自动过期？——这三问答不好的平台，接进来就是合规负债；
- 保留退路：埋点尽量跟标准走、导出尽量走开放协议，让"换后端"始终是一个选项而不是一次手术。第 6.1 节那 170 行的价值之一，就是让你有能力在任何平台上验证"它说的和你记的是不是一回事"。
本节要点回顾
- 三层格局：标准层（OTel GenAI 约定，实验态）、采集层（OpenLLMetry 插桩）、平台层（Langfuse/Phoenix 自托管，LangSmith SaaS）。
- 实验态约定的风险已经发生过（属性改名破坏兼容），对策是属性隔离层——键名集中在代码一处。
- 六问判定：数据主权、插桩侵入度、评测深度、生态绑定、拥有成本、团队技能；不排名，权重因团队而异。
- 三条提醒：工具不等于能力、用数据策略反向审问、保持可迁移。
平台选定、数据接齐，可观测体系算是"建成"了。但建成的体系要跑成日常机制才值回票价——第 7 章进入成本治理实战：优化闭环怎么带着质量护栏一起转，容量与限速怎么让峰值来了不翻车。