如果你的Agent已经在生产环境跑，大概对这个场景不陌生：用户提了个问题，Agent沉默了半分钟，然后自信地给了一个错误答案。你打开日志，HTTP状态码全是200。
这就是LLM应用最让人抓狂的故障形态——程序没报错，但结果是错的。一次智能体运行可能连续调用十几次工具、烧掉几千个Token，最后给出的答案却是错的。传统APM看的是延迟、错误率、可用性，恰恰捕捉不到这种语义层面的失败。
而且Agent的慢是会叠加的：一次工具调用两三秒看着不痛，一条任务链跑下来，检索一轮、调用三个工具、中途反思一次、失败重试一次，十几秒到几分钟就出去了。用户不知道卡在哪，你其实也不知道。
解法就是今天要聊的：LLM可观测性。社区里有个更形象的说法，叫给Agent装"行车记录仪"。
一、89%的团队装了，但近三成在"裸奔"
先看数据，确认这不是炒概念，而是已经是生产级基础设施。
LangChain针对1300多名专业人士的《智能体工程现状》调查显示：57%的受访者已经在生产环境运行智能体，接近89%已经为智能体部署了可观测性。知乎
但往下翻，有一组反差数据：只有52.4%的团队做离线评估，37.3%做在线评估，还有29.5%完全没有做任何评估。知乎另有32%的受访者把"质量问题"列为部署到生产环境的最大障碍。
钱的方向也在验证这件事。Business Research Company估算，LLM可观测性平台市场2026年规模约26.9亿美元，2030年预计达到92.6亿美元，年复合增长率36.2%。知乎Gartner的预测更直接：到2028年，LLM可观测性投入将覆盖50%的生成式AI部署，而2026年初这个比例只有15%。
所以结论先行：如果你的Agent准备上生产，或者已经在生产但你还在靠grep日志排障，这件事值得做。问题从来不是"做不做"，而是"选哪条路线、花多少钱、怎么避坑"。
二、为什么老的监控栈看不见LLM
有人会说，Prometheus加Grafana不够用吗？
对传统服务，够。但LLM应用的故障模式有三个本质不同：
第一，非确定性。同一个提示词会得到不同输出。如果不记录调用当时的确切输入、模型参数和温度，你连问题都复现不了。
第二，故障发生在语义层。检索步骤返回了错误文档，但每个接口都是200；答案听起来很确定，但内容是编的。延迟、错误率、可用性这些传统指标全部正常。
第三，调用轨迹是嵌套的树。一次Agent运行会经历多次模型推理、工具调用、RAG检索、记忆读写和反思修正，一次对话就可能产生数MB的数据。
所以LLM可观测平台要回答的其实是三件事，可以记一下这个框架，后面选型全用它：
追踪（Tracing），把一次请求还原成一棵可钻取的树——每一步用了什么提示词、调了什么工具、烧了多少Token、花了多久；
评估（Evals），回答"这个输出到底好不好"——离线评测在发版前拦回归，在线评测对生产流量抽样打分；
生产监控，成本按模型和用户归集、延迟分位数、质量分下降时告警。
三、四条技术路线，四种适用人群
2026年的市场大致分成四类，先看清各自站在哪里，比逐项对比功能更重要。
第一类，AI原生可观测平台：Langfuse、LangSmith、Braintrust、Arize、Opik。它们把LLM调用轨迹当作核心对象，能捕捉智能体、检索器和工具之间的嵌套span，还能把评估分数附加到生产流量上。这是大多数团队的主赛道。
第二类，开源评估库：Arize Phoenix、DeepEval、MLflow、RAGAS。重点给输出打分，常见指标是忠实性、幻觉、答案相关性、任务完成度，通常用LLM当评审。适合已经有监控、只缺评估能力的团队。
第三类，AI网关：Helicone、Portkey、LiteLLM。在你和模型供应商之间加一层代理，少量代码改动就能拿到日志、缓存、成本追踪和路由。适合"先看清Token账单和基础调用"的轻量需求。
第四类，APM扩展：Datadog LLM Observability、New Relic、Dynatrace。把LLM追踪接进现有基础设施监控，AI信号可以和CPU、内存、网络关联分析。适合已经重度使用某家APM的公司。
几个值得点名的产品：
Langfuse，MIT许可开源，被普遍认为是这一类里自托管能力最强的。Docker Compose几分钟就能跑起来，也有带免费层的云托管版。2026年3月上线了以observation为中心的数据模型，官方称仪表盘性能提升10倍以上，为v4铺路。知乎
LangSmith，LangChain官方商业平台，是LangChain 1.0和LangGraph 1.0的默认后端，接入几乎零胶水代码。它的Engine功能能把生产环境的失败聚类成按优先级排列的问题列表，定位根因并给出修复建议。
Braintrust，评测优先的平台，版本化数据集加CI回归测试，拿到了2026年这个领域最大融资轮次之一。
Arize，企业版AX加可查看源码的Phoenix双轨，Phoenix月下载量超过200万，和LlamaIndex、OpenAI Agents SDK集成较深。
还有一件事必须单独强调：OpenTelemetry GenAI语义约定。
这套由CNCF维护的标准定义了厂商中立的gen_ai.属性，已经被Google Cloud、AWS、Azure、Datadog等平台采用。知乎连编程智能体都在接入：GitHub Copilot的智能体遥测会暴露gen_ai.的span树，Claude Code提供可选的OTel追踪，Codex原生支持OTel导出。
对选型的意义很实际：围绕gen_ai.*做一次埋点，将来可以随时换后端，不被单一厂商锁死。2026年选这类产品，OTel兼容性应该当硬性要求，而不是加分项。
四、谈钱：一笔真实的成本账
可观测性这笔账，主要有三笔。
第一笔，部署成本。以开源的Langfuse为例，官方一行docker-compose确实能跑起来，但做过生产落地的实践者提醒：那个compose的价值是"五分钟看到效果"，不能直接上生产。v3架构有四个有状态组件：PostgreSQL、ClickHouse、Redis和对象存储。生产做法是应用层的web和worker拆成两个独立Deployment各配HPA，四个有状态组件全部交给云托管服务。知乎
第二笔，评估的Token成本。这是最容易被忽略的一笔。LLM-as-Judge是让一个大模型给你的Agent输出打分，裁判本身要消耗Token。有开发者算了笔实账：日均3000条trace，用混元当裁判，每次平均吃800个Token、按0.8元每千Token算，一个月评测成本200多元。知乎他的降本技巧是只对GENERATION那一层打分，不给工具调用、检索这些中间步骤打分，一刀砍掉60%以上的成本。
第三笔，托管还是自建。有实践者的建议很实在：不要一上来就自建全套，先用托管看清价值，再按需自建。云版免费层够Demo和小流量用；到了数据必须留在自己域内的体量再谈自托管——而且自托管不是免费的，下面要说的坑，人力成本也得算进去。
五、避坑清单：三个已经有人替你摔过的地方
坑一：托管ClickHouse的两个"默认值"。前面提到的生产落地实录踩了两个坑。一是Langfuse迁移SQL里把集群名硬编码成ON CLUSTER default，而不少云厂商的集群名并不叫default，比如叫default_cluster，初始化建表会直接失败；二是ClickHouse服务器时区如果不是UTC，界面上所有时间戳会整体偏移8小时。知乎后者别在应用层到处补换算，把服务端时区参数直接改成UTC，一个配置项解决，还和代码彻底解耦。
坑二：LLM-as-Judge的"三个别"。别给裁判宽泛的角色——写"AI评审专家"，跑出来的分数全是0.7、0.8，分不出好坏；改成"意图识别评估专家"，分数立刻拉开差距。知乎别省掉"先说理由再打分"那一步——不填推理提示，同一条trace跑两次分数能差0.3。别用没定义区间语义的评分标准——今天0.8是"好"、下周0.8变"还行"，趋势对比直接失效。另外接入前一定先在Playground验证连接，API Key错一位，评分全0，查半天都查不出来。
坑三：别急着把锅扣给Agent。还是那位开发者，上线第三周发现6%的trace长期0分，以为是Agent出了bug，查下来发现是产品同学新加了一个意图类别但训练数据没补上，落到这类的输入全被识别成"其他"。评分数据反映的不只是Agent质量，还有产品定义的稳定性。知乎这种问题，改Prompt永远改不好。
六、三个值得继续盯的行业动向
最后把最近的动态理一理，有三件值得放进关注列表。
第一，ClickHouse收购了Langfuse。交易在今年1月宣布，Langfuse整个团队加入ClickHouse，官方承诺路线图不变、继续坚持开源和自托管，改变的是投入力度。知乎从基础设施角度看算利好——Langfuse v3的核心数据层本来就是ClickHouse，高吞吐写入加快速分析读取正是ClickHouse的主场。但对用户来说，后续商业功能和社区版权益的节奏，值得持续观察。
第二，新玩家用"成本"切入。SelectDB今年6月开源了Litefuse，基于Apache Doris，单机单进程版一行命令约25秒完成部署，官方宣称凭存算分离可让Trace数据整体成本比Langfuse低75%到88%——注意这是厂商口径，还需要独立验证。知乎8月中旬，DeepSeek Harness接入Litefuse，用它提供Agent可观测与评估能力。知乎"存储厂商下场做可观测"这条国产路线能不能走通，可以再看看。
第三，零代码可观测补齐最后一块拼图。7月，OpenTelemetry Go Compile-Time Instrumentation发布v1.0稳定版，项目由阿里巴巴和Datadog联合发起，Go由此成为最后一个获得零代码可观测能力的主流语言。知乎有意思的是，评论区有人质疑"编译期插桩是不是往二进制里塞代码"，其实这是开发端的编译期技术，大型工程很常见——这种认知差本身就说明，零代码插桩的普及还有很长的路要走。
七、一句话建议，对号入座
Demo阶段的个人开发者：直接用云版免费层或Litefuse单进程模式，25秒跑起来，先看见价值再谈别的。
准备上生产的中小团队：Langfuse自托管或云版，按OTel GenAI约定埋一次点，评估先从GENERATION层的Boolean打分开始，这是成本最低的组合。
LangChain、LangGraph技术栈：LangSmith优先，胶水代码最少，有数据驻留需求它也支持自托管。
已经重度使用Datadog、New Relic的公司：直接加购LLM Observability模块，别另起炉灶。
最后留一句可以带走的话：可观测性解决的不是"系统死没死"，而是"系统对不对"。89%的团队已经装上了行车记录仪，但真正值钱的，是学会看录像——评估、成本归集、回归测试，才是Agent工程化的开始。
