当我们的程序从”按逻辑执行”退化为”按提示词生成”时，一个尴尬的问题随之而来：程序出错了，我该如何定位问题？传统日志里只有输入输出，而大语言模型（LLM）的本质是黑盒——它的每一次”思考”都是一次不可复现的概率采样。本文分享我在构建 LLM 应用时，如何借助可观测性手段，让 AI 的推理过程变得看得见、可追踪、可优化。
为什么 LLM 应用尤其需要可观测性
传统后端应用也有日志、指标和追踪，但 LLM 应用的可观测性需求要苛刻得多。首先是不确定性：同一个提示词，不同时间调用可能给出不同答案，一次偶发的坏输出很难靠”重跑一下”复现。其次是成本与延迟：一次请求可能串联了模型调用、工具调用、向量检索多个环节，任何一个环节变慢或花费飙升，都需要精确归因。最后是质量评估难：普通 API 的返回只有对错之分，而 LLM 的返回有”好与不好”的连续谱系，需要额外的评价维度。
换句话说，传统可观测性回答的是”系统运行得健不健康”，LLM 可观测性还要回答”它的回答靠不靠谱”。我们必须把模型的每一次调用都当成可追踪的完整生命周期来记录，而不是只看最终的一行日志。
落地三件套：追踪、评估与成本
我的实践中，一个可落地的 LLM 可观测性体系通常由三部分构成。第一是结构化追踪：把一次 Agent 请求展开成完整的调用链——用户的原始输入、系统提示词、每个工具调用的参数与返回、每次模型生成的若干 token、最终答案以及耗时。借助 OpenTelemetry 生态或专有的 tracing 平台，我能像浏览分布式调用拓扑一样，直观看到哪一步最慢、哪一步花费了最多 token。
第二是自动评估：对生产环境采样一部分请求，让一个更高配的模型作为”评审”打辅助，或运行预先写好的断言，判断回答是否跑题、是否忠实于上下文、关键字段是否齐全。这一层把”感觉不对劲”转化为可量化的分数，能在问题扩散前发出告警。
第三是成本归因：按用户、按功能、按模型分别聚合 token 消耗。很多团队上线后才发现某个看似无关紧要的功能占据了过半成本，正是因为没有在第一天把成本埋点做进去。这三件事单看都不难，难的是从项目第一天就坚持，而不是等出了问题才补建。
几个务实的取舍与避坑
完整接入可观测性并不意味着面面俱到。我在实践中总结出几条取舍原则：一是采样而不是全录，高频且无价值的请求抽样记录即可，重点保留失败与异常分支；二是小心隐私，提示词与输出往往包含用户敏感信息，接入第三方观测平台前务必做好脱敏与脱敏验证；三是把评估写进 CI，让新提示词或新模型的改动在上线前就接受自动评测，而不是靠上线后人工抽查。
还有一个常被忽略的点：可观测性要服务于人，而不是反向绑架流程。观测面板是定位问题的工具，如果每改一个提示词都被繁杂的配置和审批卡住，团队迟早会绕开这套体系，让观测流于形式。好的可观测性是”润物细无声”的：默认配置好用、能主动兜底，开发者几乎感觉不到它的存在，却在关键时刻给出致命情报。
为 AI 应用建立可观测性，本质上是从”信任魔法”走向”理解魔法”。我们无法消除大模型的随机性，但能通过记录、评估与归因，把这团概率云雾拆解成可解释的链路，让每一次”灵光闪现”和每一次”翻车现场”都有迹可循。当 AI 的思考真正变得透明，我们才配得上把它托付给更多关键的生产场景。