AI 故障不能只靠复现一句提示词
传统接口出错常有明确异常，而 LLM 应用更常见的问题是回答变差、成本突然升高、某个工具调用走错分支或长链路中间一步偏离。Langfuse 通过 trace、span 和 generation 把一次请求拆开，能看到模型、提示、耗时、令牌和关联元数据。
接入后最先解决的应是可定位性，不是打造一块漂亮仪表盘。我会先为会话、用户匿名标识、功能版本和错误类型设计少量稳定字段，然后让一次用户操作可以完整串联。若项目由 Dify 或其他工作流工具搭建，也要确认链路标识没有在节点之间丢失。
先定义问题，再决定记录哪些数据
记录越多并不自动带来答案。先列出最常处理的三类问题，例如哪一步最慢、哪个模型版本导致格式失败、某类请求为何成本异常，再围绕这些问题设置标签、评分和保留期。这样能减少无用日志，也降低敏感内容被长期保存的风险。
- 为生产、测试和回放环境使用明确标签；
- 记录提示版本和模型标识，不只保存最终文本；
- 把人工反馈与自动评估分开，避免分数含义混乱；
- 设置采样、脱敏与保留策略，定期检查存储增长。
评估要从真实失败样本长出来
最实用的数据集通常不是网上下载的通用题库，而是线上出现过、已经由人判断的失败案例。把这些样本清理隐私后加入回归集，修改提示、检索或模型时重复运行，才能知道优化是否只改善了演示案例。
自动评分适合结构、关键词或可验证事实，主观写作仍需要抽样人工复核。模型充当裁判时还会带入自身偏好，因此评分提示、裁判模型和阈值也应版本化。Langfuse 提供工作台，但评价标准仍由业务负责。
云端和自托管取决于团队维护能力
托管版适合快速验证，自托管则便于控制网络、存储和访问权限，但会增加数据库、升级、备份和监控工作。不要因为项目开源就低估运维成本，也不要在没有恢复演练时把追踪系统当作唯一审计记录。
开始时只接一条低风险链路，观察 SDK 对延迟和错误处理的影响，再逐步扩展。与 n8n 一类自动化平台结合时，尤其要给外部操作保留人工确认和独立日志，避免一次模型误判直接触发不可逆动作。
