今年1月，ClickHouse正式收购了Langfuse——目前使用最广的开源Agent可观测平台。不少人的第一反应是担心：会不会闭源？自托管还保不保？半年过去，官方给出的回答很一致：路线图保持不变，目标仍然是构建最佳的AI工程平台，也将继续致力于开源和自托管。知乎真正改变的是速度——它拿到了一家数据库巨头的全部资源支持。
而且这不是孤立事件。把视野放到整个AI可观测赛道，一场整合潮正在进行：Cisco把Splunk、Robust Intelligence和Galileo拼成了一张完整的"AI信任"拼图；Fiddler在拿下3000万美元融资后立刻收购Lumeus；Palo Alto则把AI网关Portkey收入囊中。知乎
你今天选的平台，明天可能换个东家。所以对认真考虑给Agent上可观测的团队来说，今天的问题已经不是"要不要上"，而是"怎么选才不会被锁死、不踩坑"。
为什么是现在？先看钱。Business Research Company估计，全球LLM可观测性平台市场规模在2026年为26.9亿美元，高于2025年的19.7亿美元，到2030年预计达到92.6亿美元，预测期年复合增长率为36.2%。知乎（单一机构测算，看量级就好。）Gartner的预测更直接：到2028年，LLM可观测将覆盖50%的GenAI部署，而2026年初这个数字仅约15%。知乎
更接地气的信号在招聘市场。今年夏天，"Agent项目的追踪、评估与可观测性"已经成了AI大模型岗的面试热门，相关精讲视频播放量轻松过万。哔哩哔哩就在前两天，又出现了从LangChain组件原理讲到Agent可观测性的最新面试题精讲。哔哩哔哩一项技能开始密集出现在面试题库里，通常说明它已经是生产环境的刚需。
背后的原因，是Agent的故障方式变了。有团队遇到用户反馈"答得不对"，监控侧却一切正常：所有接口都是200，延迟正常，错误率为零。知乎模型幻觉、把工具返回的price当成quantity理解、检索没命中却自信作答——这些都不会触发任何HTTP异常，传统APM回答"系统活着"，却没人回答"Agent答得对不对"。
那怎么选？我的核心判断一句话：先选标准，再选平台。2026年这个赛道最大的变量不是任何一款产品，而是一个协议——OpenTelemetry GenAI语义约定。它为模型调用、Token使用、智能体步骤和工具执行定义了与供应商无关的gen_ai.* span属性，目前已经被Google Cloud、AWS、Azure、Datadog等平台采用。知乎
连编码Agent也在接入这套标准：GitHub Copilot的智能体遥测数据会暴露gen_ai.* span树，Claude Code提供可选的OpenTelemetry追踪，Codex则原生支持OpenTelemetry导出。知乎为什么这件事重要？因为它把"埋点层"和"后端层"解耦了——过去选平台等于绑定它的SDK，现在按gen_ai.*标准化埋点，后端随时可换。在巨头互相收购的整合期，这就是选型的那份保险。所以2026年做选择，OTel兼容性应该是硬性要求，不是加分项。
再看市场本身，大致可以分成四条路线。AI原生平台：Langfuse、LangSmith、Braintrust、Arize、Opik，把LLM调用轨迹当核心对象，功能最全，其中Langfuse核心代码采用MIT许可证，用Docker Compose几分钟就能自部署；开源评估库：Arize Phoenix、DeepEval、MLflow，专注给输出质量打分，Phoenix月下载量已超过200万次；AI网关：Helicone、Portkey、LiteLLM，一行代理接入就有成本和延迟看板，但深度追踪不是强项；APM扩展：Datadog LLM Observability、New Relic、Dynatrace，胜在与既有基础设施监控关联，New Relic的免费层最慷慨，每月100GB。
国内用户还有一个值得关注的开源选项：Litefuse。它基于Apache Doris存储，兼容Langfuse SDK和100多个生态集成，官方宣称存储成本比Langfuse降低88%、Trace文本检索效率提升10倍。知乎公允地说，成本和检索数字目前都是厂商口径，还没看到第三方实测，动手前值得用自己的负载压一遍。但它针对的痛点是真实存在的——Langfuse官方方案需要维护6个组件：Web服务、Worker、Redis、MinIO、Postgres、ClickHouse，出了问题，排查这套基础设施本身就要花不少时间。知乎
如果你最终还是选了Langfuse自托管，先看清楚它的架构演进代价：从v3开始，官方部署方案从v2时代的"Web服务+Postgres"，变成了要额外维护Redis、异步Worker、ClickHouse和对象存储的多组件栈，这也是"自部署太重"抱怨的由来。
就在8月20日，有人刚发布了一篇Dify 1.16.1搭配Langfuse v4的完整部署实录，踩中了最典型的一个坑：Dify明明显示"已启用"，Langfuse里却一条Trace都没有。这不是网络或密钥问题——Dify 1.16.1仍在使用旧版写入接口，而Langfuse v4的默认写入模式是events_only，旧Trace和Observation事件会被直接拒绝，因此页面没有Trace。知乎临时解法是把web和worker两个服务的写入模式都设为dual，然后重建容器——只restart不行，环境变量变更必须重建才生效；等Dify未来切换到新版写入路径，这个桥接配置就可以撤掉。另外，对外部署前记得换掉官方Compose里带CHANGEME标记的默认密码，NEXTAUTH_SECRET、SALT、ENCRYPTION_KEY一个都不能少。
最后按人群给几个直接判断。个人开发者或验证期团队：用Langfuse Cloud免费层或本地Compose，从第一天就按OTel GenAI规范埋点，成本约等于零。Agent已上生产的中小团队：自托管Langfuse，避开上面那几个坑；技术栈深度绑定LangChain的，直接用LangSmith省集成成本。成本敏感、Trace数据已经TB级：认真评估Litefuse这类Doris存储的方案，但迁移前先跑自己的负载实测。有合规需求的大企业：APM扩展加专业评估工具的组合阻力最小；顺便提醒一句，EU AI Act对高风险AI系统的主要义务虽然已从2026年8月推迟到2027年12月，但那是施工时间不是暂停，自动事件日志要求意味着系统上线多年后仍要能拿出每一笔决策记录。知乎
值得继续盯的信号也列一下：Langfuse官方路线图是公开的，ClickHouse整合方向不用猜；Dify对OTLP写入的支持进度，决定dual模式何时能退休；Litefuse等国产替代的第三方实测和社区成熟度；以及OTel GenAI约定会不会从"多家采用"变成采购硬性要求。标准一旦统一，这个市场会迎来真正的洗牌——现在选对标准，就是给未来的迁移成本买一份保险。
