很多 AI 应用上线第一天，看起来都很体面。
页面上挂着“智能助手”四个字，接口返回 200，模型回答也很顺。直到一个用户来投诉：它引用了三个月前的退款政策，还为了确认订单状态连续调用了十几次工具。知识库里明明有新文档，Agent 却绕了一圈，用旧信息组织出看似合理但错误的结论。
此时最关键的问题是：到底是哪一步坏了？
传统日志通常只能告诉工程师“请求成功了”。AI 应用的失败更像一串连环扣：system prompt 过期、检索召回偏移、工具返回脏数据、judge 评测漏掉边界场景。最后生成的一段话很顺，账却对不上。
Langfuse 这类 LLM 可观测工具的价值，就在这张小票上。它把一次 AI 任务拆成 trace、observation、score、dataset 和 experiment，让团队能从坏结果倒查到具体环节。
没有 trace 的 AI 应用，像没有小票的报销单：结果看着体面，账根本对不上。
事故小票
Langfuse 的 trace 记录的不只是“问了什么、答了什么”。官方文档里，trace 可以覆盖 LLM 调用，也可以覆盖 retrieval、embedding、API call、tool execution 等非 LLM 步骤。对 Agent 来说，这比保存聊天记录更关键。
一次客服请求，表面上只有一个最终回复。拆开以后，里面可能有用户问题改写、知识库检索、重排、模型生成、工具查询、权限判断。其中任一环节发生偏移，最终都可能生成看似合理但错误的回答。
普通日志像监控录像，只能看到请求进来又出去。Trace 更像收银小票：几点发生，调用了哪个模型，检索命中了哪些文档，工具参数是什么，花了多少 token，延迟卡在哪一步。
这张小票最好不要锁死在某个私有格式里。OpenTelemetry 的 GenAI 语义约定正在把模型名、输入输出 token、工具调用、工具结果等信息标准化；Langfuse 可通过 OTLP endpoint 接收这些 trace。对团队而言，AI 观测数据可以进入既有工程体系，而不是另起一套孤岛。
质量闭环
只看 trace 还不够。Trace 解决“发生了什么”，但不能自动回答“做得好不好”。
Langfuse 里的 score，就是给某个 trace、observation、session 或 dataset run 打质量标签。用户反馈、人工标注、代码 evaluator、LLM-as-a-Judge，都可以落到这个对象上。
这一环节最容易流于形式。很多团队只给整段对话打一个“满意度”，看起来像质检，定位能力却很弱。Agent 时代更稳的方式，是把评测拆到操作层：最终回答看准确性，检索步骤看相关性，工具调用看参数是否正确，安全步骤看权限边界。
Langfuse v4 的 observations-first 方向，正是为这类问题服务。一个复杂 Agent trace 可能有几百甚至上千个操作。新数据模型把操作变成可直接过滤和聚合的 observation：哪些 generation 最贵，哪些 retrieval 经常低分，哪个 release 的工具调用错误率上升，都能从操作层查起。
Prompt management 也要进入这套闭环。prompt version 关联到 trace 后，团队才能比较版本之间的成本、延迟和 score；线上坏例子可以沉淀成 dataset item；改 prompt、换模型、调检索策略以后，再用 experiment 跑同一批样本。
这样，失败不会停在聊天记录里。它会变成下次发布前必须通过的回归测试。
接入路径
落地时可以从一条客服链路开始：给 trace 传入 userId、sessionId、release、environment 和 tags；给检索步骤记录命中文档；给工具步骤记录工具名和参数；给模型步骤记录成本、延迟和 prompt version；最后给关键 observation 打 score。下一次再出现坏回答，团队看到的就不只是一段漂亮但无法追责的回答，而是一串可以对账的证据。
如果这些信息都没有，AI 应用还停留在 Demo 阶段。它可能能跑，也可能偶尔显得很聪明，但团队并不知道成功来自设计，还是来自运气。
模型负责生成答案，工程系统负责留下证据。没有证据的智能，只是一次运气不错的表演。
