一个接口返回 HTTP 200，说明请求走完了。对普通程序来说，这通常是个好消息；对 AI 应用来说，事情才刚开始变得麻烦。
模型可能一本正经地编造事实，检索程序可能拿回了不相关的资料，工具调用可能格式正确却查错账户，Agent 也可能绕了十几步才得到一个勉强能用的答案。代码没报错，用户仍然会说：“这个结果不对。”
传统监控很擅长回答机器层面的问题：服务活着吗，接口慢不慢，数据库有没有异常。AI 应用还需要回答另一组问题：模型当时看到了什么，为什么选择这个工具，检索结果如何进入 Prompt，答案由哪一个版本产生，成本花在了哪一步。可观测性就是为了留下这些证据。
一个成功返回的错误答案
贯穿这套内容的案例是一套多轮业务问答 Agent。用户问：
昨天哪个广告计划表现异常？
系统先识别客户和时间范围，查询投放数据，计算异常程度，再由模型组织答案。最后它返回：“A 计划转化率下降 32%。”接口耗时 4.8 秒，没有异常日志。
用户核对后台后发现，实际异常的是 B 计划。只看最终响应，开发人员很容易先去改 Prompt。可问题也许早在前面就发生了：
- “昨天”按 UTC 计算，少取了八个小时的数据；
- 查询工具用了另一个客户的账户 ID；
- 指标计算把点击率当成转化率；
- 工具返回空值后，模型根据旧上下文补出了一段解释。
这些情况在程序层面都可能是“成功”。如果没有完整的执行记录，排查只能依赖复现、猜测和临时加日志。概率模型又不保证下一次给出相同答案，等日志补好以后，现场往往已经变了。
AI 可观测性要做的，是把一次运行保存成可以回看的证据链：请求从哪里开始，经过哪些步骤，每一步收到了什么、返回了什么，调用了哪个模型或工具，花了多久，最后怎样结束。团队可以沿着结果倒查，而不用把每个系统的文本日志拼在一起猜。
日志、Trace、监控和评估不是一回事
日志记录某个时刻发生的事件，例如“查询接口返回 500”或“重试次数达到 3”。它仍然有用，只是单条日志通常不知道自己在整个业务任务中的位置。
Trace 关注一次请求的完整路径。它把模型调用、检索、工具和业务步骤放进同一条有父子关系的时间线里。看到“调用失败”以后，还可以继续查到它属于哪个用户请求、上一步给了什么参数，以及系统是否执行了降级。
监控把大量运行数据聚合成趋势，例如请求量、错误率、P95 延迟、Token 和费用。它适合回答“最近是否异常”，但平均值很难解释某一次回答为什么错。
评估回答“结果好不好”。判断依据可能来自用户反馈、人工审核、业务规则或另一个模型。它与可观测性互相依赖，却不能互相替代：Trace 记录过程，不会自动证明答案正确；一个低分告诉我们结果有问题，也未必解释问题出在哪一步。
这几类能力放在一起，才形成一条可用的工作路径：先从监控或反馈发现异常，再进入 Trace 查过程，找到原因后修改 Prompt、模型、工具或流程，最后用相同标准验证改动。
为什么“多打日志”不够
假设 Agent 涉及一个应用服务、一个检索服务和两个外部工具。每个系统都写了日志，但它们没有共同标识，时间格式也不一致。排查人员需要根据时间戳推测哪些记录属于同一次请求。并行步骤和重试一多，这种推测很快就失效。
结构化观测数据至少保留三种关系：一项业务任务的边界、任务内部步骤的父子关系，以及跨请求的会话关系。稳定的 ID 把它们连起来，输入输出、状态、时间和版本再附着到对应步骤上。后面讨论的 Trace、Observation、Generation 和 Session，都是这套关系里的不同层级。
采集也不是越多越好。完整保存所有 Prompt、用户对话、检索文档和附件，会带来费用、隐私与权限风险。设计时应从待解决的问题出发：定位错误需要保存哪些步骤，比较版本需要哪些稳定字段，哪些原文不能离开业务系统。字段没有对应的使用场景，就只会增加存储和治理负担。
Langfuse 在这里做什么
Langfuse 是一套开源的 LLM 工程平台。它接收应用产生的观测数据，把一次任务及其内部步骤组织起来，并提供搜索、成本分析、Prompt 管理、反馈、数据集和评估等能力。使用者可以选择官方 Cloud，也可以部署在自己的基础设施中。
它位于业务应用旁边。执行任务的仍然是应用代码、模型、知识库和外部工具；“转化率异常”如何计算，也要由业务团队定义。Langfuse 能展示查询工具返回了什么，却不会凭空知道公司采用哪套指标口径。平台能保存 Score，也不会替团队决定什么叫好答案。
Trace、Span、Session、Dataset 和 Evaluation 也不属于某个厂商。LangSmith、Phoenix、MLflow、Braintrust、Weave、传统 APM 与自建 OpenTelemetry 链路都可能承载其中一部分。名称和界面会变，长期可复用的是团队自己的定义：什么算一次任务，哪些步骤值得观察，如何标识用户和版本，什么证据足以说明改动有效。
本书使用 Langfuse，是因为它能把抽象概念落到一套可操作的数据模型和界面中。读者应同时保留两层认知：先理解通用问题，再理解 Langfuse 如何实现。以后更换工具时，迁移的重点是前一层。
先能还原，再开始做质量评估
刚开始建设时，不必一次接入所有高级能力。先挑一条重要请求，让团队能够从用户输入看到模型、检索与工具步骤，并查到最终输出。接着补上环境、用户、会话和版本，确保数据可以筛选。等线上失败能够稳定沉淀下来，再讨论 Dataset、自动评估和发布门禁。
这个顺序有意把 Eval 放在后面。团队连一次错误回答都无法还原时，贸然增加大量评分，只会得到一组解释不了的数字。先看清系统怎样运行，后面的质量判断才有证据可依。
参考资料
系列目录：AI 应用可观测性与评估