AI应用可观测性实战：从Callback到Trace的完整落地指南

我们组上一个AI项目上线不到两周，就被线上问题按在地上摩擦。模型偶发返回空结果，Agent偶尔多调用了一个工具，用户反馈“答非所问”，但我们翻遍日志也拼不出完整的调用链，最后只能靠回归测试复现。那段时间我意识到一件事：大模型应用写出来只是第一步，让它能在生产环境里被“看懂”才是真正的分水岭。

这篇内容，我就围绕“AI大模型落地”这个场景，把Callback、Trace和生产级可观测性这三件事一次讲透。这不是教科书式科普，是我在真实项目里踩坑踩出来的经验总结。内容适合正在做AI应用开发、Agent框架集成、或者负责AI服务运维的工程师，也适合那些已经被线上诡异问题折磨过、想建立一套规范化排查体系的技术负责人。

1. 内容整体设计与思路拆解

1.1 为什么说Callback是AI应用可观测性的第一块基石

大部分做AI应用的同学，第一次接触可观测性相关的概念，就是从Callback开始的。这个名词听起来有点“框架专属”的味道，实际上它的本质非常简单：在模型调用链路的特定节点上，插入你自定义的逻辑，用来捕获当时的状态和上下文。

我在LangChain和LlamaIndex里都深度用过Callback机制，它们的设计思路是相通的。模型开始调用了、模型返回结果了、中间调了哪个工具、检索器命中了几条文档，这些都是触发点。在这些触发点里，你可以把当时的输入、输出、耗时、Token数全部记录下来。

但很多人的理解止步于此，觉得“我在回调里print一下，能看到日志就够了”。我见过不少项目，日志里确实打了“LLM started”和“LLM finished”，但实际上什么问题也排查不了。为什么？因为Callback如果只是零散地打日志，它提供的只是“事件碎片”，而不是“调用链路”。

生产级的做法，是把Callback当作采集器，把每次触发时的关键数据规范化，并附带上链路标识（Trace ID和Span ID），让这些碎片可以串起来。所以，Callback不是可观测性的终点，它是起点，是数据进入可观测性体系的入口。

1.2 从日志到Trace：可观测性到底在解决什么问题

说到Trace，很多从传统后端转过来的同学会觉得熟悉，但又有点陌生。熟悉的是分布式追踪的概念，陌生的是，AI应用里的Trace和传统RPC调用的Trace，确实有些不同。

传统后端里，一个请求从前端打到网关，网关调订单服务，订单服务调支付服务，链路相对固定、依赖清晰。AI应用呢？一个用户问题进来，可能要经过意图识别、检索召回、Prompt组装、多轮模型调用、工具选择、结果校验，每一步都可能产生分支，甚至模型会自己“决定”下一步调什么。链路不但长，而且动态性极强。

所以AI场景下的Trace，本质上是在解决一个问题：当系统行为充满不确定性时，你怎么知道这一次请求到底发生了什么。

一个完整的Trace，至少应该包含这些要素：

• Trace ID：一次完整请求的唯一标识，从入口处生成，贯穿整条链路。
• Span ID：链路中每一个环节的唯一标识。
• Parent Span ID：指明当前环节的上一级是谁，这样才能构建出一棵完整的调用树。
• 时间戳和耗时：每个环节的开始、结束、耗时。
• 属性信息：模型名、Prompt摘要、Token数、温度参数、工具名等业务上下文。

只有把这些要素组织成树状结构，你才真正拥有了“追踪”能力。否则，那只是一堆带时间戳的日志而已，和用grep翻文件几乎没有本质区别。

1.3 生产级可观测性的三层体系与AI场景的特殊性

成熟的互联网后端，早就把可观测性归纳成三大支柱：Metrics（指标）、Logs（日志）、Traces（链路）。它们各有分工，又互相补充。指标告诉你系统整体健康度，日志告诉你单个事件细节，链路告诉你一次请求的完整路径。

但AI大模型应用的落地，给这三层体系增加了一些新的维度。最典型的就是模型行为本身的“黑盒性”。传统后端代码逻辑是确定的，输入一样输出一定一样，但模型不是，它自带随机性。这意味着，即使指标、日志、链路都有，你可能仍然定位不到“为什么模型这次返回了空”的根因。

所以在AI场景下，生产级可观测性还要额外关注一层，我称之为“行为可观测性”。不只是看到“模型调用耗时2秒”这个指标，还要能看到“这2秒里，Prompt长什么样、模型有没有被反复重试、Token消耗是异常高还是有降级”这些贴近模型行为的细节。

这就是为什么我强调把Callback、Trace和整个可观测性体系放在一起打通，而不是各做各的。任何一环缺失，都会在线上问题排查时让你抓瞎。

2. 核心细节解析与实操要点

2.1 Callback触发时机与数据捕获粒度

先用LangChain来举例，因为这是目前AI应用开发里最主流的框架之一。LangChain的Callback机制，核心类叫BaseCallbackHandler，里面定义了大量的回调方法。你要做的，就是继承这个类，然后覆写你关心的那些方法。

我根据自己的实战经验，把最常用的触发时机整理了一张表：

实际开发中有个很容易踩的坑：回调方法里不要做重活。我见过有同事在on_llm_end里同步去写数据库、调外部API，结果模型调用本身才几百毫秒，回调里却耗了2秒，直接把整个接口拖垮了。Callback的正确姿势是“轻采集、快返回”，把数据塞进队列或者直接打到日志系统，后续异步去做聚合和分析。

还有细心的同学会问，如果不用LangChain，纯手写OpenAI接口调用，Callback还要不要用？我觉得不需要刻意引入框架，你只需要自己在调用chat.completions.create之前和之后，加上采集逻辑即可。本质是一样的，核心在于你愿意在哪些节点插桩。

2.2 Trace的上下文传播到底在传播什么

Trace的实现五花八门，但核心思想就一个：把同一个请求的标识，从一个环节传到下一个环节，并且记录父子关系。

用OpenTelemetry来做的话，上下文传播靠的是Context机制。当你开始一个新Span时，这个Span会从当前的Context里读取父Span信息，把自己挂上去。然后在调用下一个组件时，把当前的Context塞到请求头或参数里，下游就通过这个Context知道自己是哪个请求的一部分了。

举个例子，用户请求进来，你创建了根Span，叫POST /chat，得到一个Trace ID。然后你调用检索器，创建一个子Span叫retrieve_documents，这个子Span的Parent Span就是根Span。接着你调用模型，创建另一个子Span叫llm_call，Parent Span同样指向根Span。最后，这三个Span上报到后端，你就能看到一棵树：

code复制POST /chat
├── retrieve_documents (245ms)
└── llm_call (1832ms)

这个结构看着简单，但生产环境里真正容易出问题的，是上下文传播的“断链”。比如你用LangChain的langchain.llms.OpenAI去调用模型，它在内部可能新建了线程池或者异步任务，如果子线程里没有正确继承父线程的Context，Trace的链路就会在某个节点断掉。

我自己调试过这类问题，最后总结出来的经验是：尽量使用框架官方支持的OpenTelemetry追踪集成，不要自己手动传播Context，除非你非常清楚底层线程模型。

2.3 生产级可观测性的核心指标设计

聊完Trace的原理，回到生产实践。你在线上看监控大盘，最关心的无非这几个问题：系统还活着吗？响应快不快？用户请求成功没有？模型调用有没有异常？

围绕这些问题，我建议你在AI应用的指标设计上，至少要覆盖五个维度：

• QPS和延迟：接口总QPS、模型调用QPS、P50/P95/P99延迟。延迟指标能暴露性能瓶颈。
• 错误率：接口错误率、模型调用错误率，需要区分超时、限流、无效请求等不同错误类型。
• Token消耗：每请求平均Token数、每日总Token数。这直接对应成本，是老板最关心的指标之一。
• 模型行为指标：空响应率、拒绝率、安全拦截率。这些指标是传统后端没有的，但对AI应用至关重要，比如模型返回空字符串，接口可能200，但实际是一次无效应答。
• 工具与检索指标：工具调用次数、检索命中率、检索耗时。Agent类应用特别关注这些，用于判断模型“决策”是否合理。

这些指标采集上来之后，再配上延迟和错误率的告警规则，才算搭起了一个初步的生产监控骨架。我见过太多AI项目，上线后只看CPU和内存，模型本身的行为完全处于“盲区”，这种状况下出问题基本只能靠用户投诉来感知。

3. 实操过程与核心环节实现

3.1 快速搭建一套OpenTelemetry基础的Trace采集环境

讲了这么多理论，该上实操了。我这里用一个最小可行的方案，带你从零搭一套基于OpenTelemetry的Trace采集环境。整个链路是：Python应用（FastAPI + LangChain） → OpenTelemetry Collector → Jaeger界面展示。

你不需要一开始就上Kubernetes或者大规模集群，先在本地把链路跑通，理解数据流转，再逐步扩展。

第一步：安装核心依赖

bash复制pip install opentelemetry-api
pip install opentelemetry-sdk
pip install opentelemetry-exporter-otlp
pip install opentelemetry-instrumentation-fastapi
pip install opentelemetry-instrumentation-requests

注意，这几个Instrumentation库是自动埋点的，可以让你不用手动改业务代码，就能收集FastAPI接口和HTTP调用的Trace。对LangChain，我建议你再装一个官方或者社区维护的LangChain Instrumentation包，这能让模型调用、检索器等组件自动生成Span，非常省事。

第二步：初始化OpenTelemetry

python复制from opentelemetry import trace
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import BatchSpanProcessor
from opentelemetry.exporter.otlp.proto.grpc.trace_exporter import OTLPSpanExporter
from opentelemetry.sdk.resources import Resource, SERVICE_NAME

resource = Resource.create({SERVICE_NAME: "ai-chat-service"})
provider = TracerProvider(resource=resource)
provider.add_span_processor(
    BatchSpanProcessor(OTLPSpanExporter(endpoint="http://localhost:4317", insecure=True))
)
trace.set_tracer_provider(provider)

这里端的解释一下几个关键参数。SERVICE_NAME会作为服务的标识出现在所有Trace里，一定要起得规范。BatchSpanProcessor是批量上报，攒一批再发，性能比逐条发送好很多。OTLP的默认端口是4317，如果你用的是Collector的HTTP协议，那端口会变成4318。

第三步：部署OpenTelemetry Collector

Collector是一个独立进程，负责接收应用上报的Trace数据，然后转发给后端存储和展示系统。它最核心的价值，就是对各种数据源和输出端做适配和缓冲。比如应用发OTLP协议的数据，Collector转成Jaeger需要的格式；如果后端挂了，Collector还能在内存里缓冲一段时间，不至于丢数据。

一个最小的otel-collector-config.yaml长这样：

yaml复制receivers:
  otlp:
    protocols:
      grpc:
      http:

processors:
  batch:

exporters:
  jaeger:
    endpoint: localhost:14250
    tls:
      insecure: true

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch]
      exporters: [jaeger]

然后用otelcol --config otel-collector-config.yaml启动它就行。当然，线上正式环境我一般建议用Docker或者Kubernetes部署Collector，配置还会加上内存限制、队列大小、重试策略，但本地方案能跑通就已经解决了80%的问题。

第四步：配置Jaeger展示Trace

Jaeger是最常用的分布式追踪展示系统之一。本地起一个最简版：

bash复制docker run -d --name jaeger \
  -e COLLECTOR_ZIPKIN_HOST_PORT=:9411 \
  -p 5775:5775/udp \
  -p 6831:6831/udp \
  -p 6832:6832/udp \
  -p 5778:5778 \
  -p 16686:16686 \
  -p 14250:14250 \
  -p 9411:9411 \
  jaegertracing/all-in-one:latest

启动之后，浏览器访问http://localhost:16686，选择你的服务名，就可以查询到上报的Trace了。到此，一套最基础、但五脏俱全的Trace系统就跑起来了。

3.2 手动给LangChain应用埋点，捕获模型调用Span

上面的自动化埋点能覆盖框架层的调用，但如果你有自己封装的业务逻辑，比如你封装了一个generate_answer函数，里面做了Prompt模板组装、调用模型、然后做输出格式校验，你想让这一整段业务逻辑也成为一个Span，那你就需要手动埋点。

手动埋点的代码其实很简洁：

python复制from opentelemetry import trace

tracer = trace.get_tracer(__name__)

def generate_answer(user_query: str):
    with tracer.start_as_current_span("generate_answer") as span:
        span.set_attribute("user_query", user_query)
        # 拼接 Prompt、调用模型、校验输出...
        span.set_attribute("model", "gpt-4o-mini")
        span.set_attribute("prompt_tokens", 1230)
        span.set_attribute("completion_tokens", 210)
        return result

start_as_current_span这个Context Manager的好处是，它会自动把当前Span设为新的“当前Span”，所有在这个代码块里创建的子Span，都会自动挂到它下面。用set_attribute设置的自定义属性是后续排查问题时的关键索引，比如你可以按model字段过滤，看看某个模型是不是延迟明显偏高。

这样一层层叠加，你的Trace就不是只有“接口进、接口出”的粗粒度结构了，而是能看出某次用户请求里，Prompt组装花了多久、模型返回了多少Token、输出校验有没有触发重试，这些细节才是生产环境排查问题的利器。

3.3 用Callback把LangChain事件桥接到现有监控体系

前面说OpenTelemetry能自动埋点LangChain，但现实情况是，很多公司已经有了自己的日志和监控体系，比如ELK，比如自研的监控平台。这种情况下，你未必想把所有数据都搬到Jaeger里去，而是希望LangChain的事件，能按你自己定义的格式进到现有体系里。这时候，自定义Callback就是最优解。

下面我写一个简化的Callback实现，逻辑是把LangChain事件转换成结构化日志，带上Trace ID方便后续串联：

python复制import json
import logging
from langchain.callbacks.base import BaseCallbackHandler

logger = logging.getLogger("langchain_monitor")

class MonitorCallbackHandler(BaseCallbackHandler):
    def __init__(self, trace_id: str):
        self.trace_id = trace_id

    def on_llm_start(self, serialized, prompts, **kwargs):
        self._log("llm_start", {
            "prompts": prompts,
            "model": serialized.get("name", "unknown")
        })

    def on_llm_end(self, response, **kwargs):
        self._log("llm_end", {
            "token_usage": response.llm_output.get("token_usage", {}),
            "generated_text": response.generations[0][0].text[:200]
        })

    def on_llm_error(self, error, **kwargs):
        self._log("llm_error", {"error": str(error)})

    def on_tool_start(self, serialized, input_str, **kwargs):
        self._log("tool_start", {"tool": serialized.get("name"), "input": input_str})

    def on_tool_end(self, output, **kwargs):
        self._log("tool_end", {"output": str(output)[:200]})

    def _log(self, event_type: str, data: dict):
        record = {
            "trace_id": self.trace_id,
            "event_type": event_type,
            "data": data
        }
        logger.info(json.dumps(record, ensure_ascii=False))

使用的时候，在请求入口生成一个trace_id，然后实例化这个Handler，传给LangChain的调用即可：

python复制trace_id = uuid.uuid4().hex
handler = MonitorCallbackHandler(trace_id=trace_id)
llm = ChatOpenAI(model="gpt-4o-mini", callbacks=[handler])
result = llm.invoke("介绍一下分布式链路追踪")

这么做的好处非常明显：你在自己熟悉的ELK或者日志平台里，就能按trace_id把所有的事件串起来看。比如一条完整的Agent执行过程，你搜索同一个trace_id，能看到“工具被调用了”、“工具返回了什么”、“模型生成了什么”，这就是一套低成本、不依赖外部观测平台的“轻量级Trace”。

我建议ArgoCD风格的AI平台、或者中小团队，在没有预算搭建完整可观测性平台时，先用这种方案过渡，效果远好于裸打印日志。

3.4 Callback与Trace深度联动：让Span拥有完整的Prompt上下文

前面几节，Callback和Trace是分开讲的。但生产级实践里，它们必须合体，才能发挥最大价值。我分享一个我目前在用的标准做法。

在LangChain里，OpenTelemetry的LangChain Instrumentation会自己创建Span，但这些Span里的Attribute是通用的，不包含Prompt内容和工具调用详情。要补充这些信息，就需要配合Callback，把它们写进对应的Span里。

具体做法分三步执行：

第一步，在请求入口创建一个根Span，并通过trace.get_current_span()拿到它的句柄。
第二步，在自己的Callback Handler里，用全局的Tracer创建子Span，命名规则建议和LangChain的事件名保持一致，比如llm_call、tool_call。
第三步，在子Span里写入关键属性，比如prompt、model_name、temperature、token_usage、tool_result等。

这样做完之后，你在Jaeger里看Trace，不只能看到每个环节耗时多少毫秒，还能直接点击某个Span，展开看到当时传进去的完整Prompt是什么、模型返回了什么内容。这个能力在线下测试时感受不明显，但在线上复现“某次请求为什么结果异常”的时候，简直是救命稻草。有一次用户反馈模型答非所问，我就是靠这种Trace里的Prompt上下文，发现是某次检索把一段无关文档拼进了上下文，导致模型被带偏。

我强烈建议，你在设计AI应用的可观测性方案时，就把Callback当成“给Span添加血肉”的机制，而OpenTelemetry提供的Span骨架负责“连接关系”。两者结合，才是真正意义上的生产级可观测性。

4. 常见问题与排查技巧实录

4.1 采集了Trace但Jaeger看不到数据，怎么排查

这个问题的出现频率，在我参与过的所有AI项目里能排前三。明明代码里初始化了OpenTelemetry，也调用了接口，Jaeger界面却一片空白。遇到这种问题，先别急着怀疑代码逻辑，按下面的顺序排查，大概率能定位到根因。

第一，确认应用是否真的把Span发出去了。OpenTelemetry SDK默认的导出方式有同步和批量两种，BatchSpanProcessor是攒一批再发，默认的调度间隔是5秒。也就是说，请求结束后要等最多5秒，数据才会出现在Jaeger里。很多人测试时请求一发完立刻去刷新Jaeger，自然什么都看不到。

第二，确认Collector端口和协议是否匹配。如果你的应用用GRPC方式发OTLP，而Collector只开启了HTTP接收，数据会被拒绝。反过来也一样。我常用的验证方法是，直接往Collector的HTTP端点用curl发一条测试数据，看看Collector日志有没有报错。

第三，确认服务名是否在Jaeger里正确显示。Jaeger的查询首页会列出所有上报过的服务名，如果你找不到自己的服务，大概率数据就没到Jaeger。如果能找到，只是查询条件不对，那问题的范围就小很多。

第四，确认网络连通性。本地测试时，localhost没问题，但如果在Docker容器里跑应用，localhost指向的是容器自身，根本访问不到宿主机上的Collector。这种情况必须用host.docker.internal或者宿主机的具体IP。

4.2 Token统计为何总是对不上账

模型返回的usage字段里给了Prompt Tokens和Completion Tokens，但如果你自己数一下Prompt里的字符，往往会发现对不上。这里有个容易误解的地方：模型的Token计算和字符数不是简单的一对一关系，一个英文单词可能拆成多个Token，一段中文可能一个汉字就是一个Token甚至更多。

此外，不同模型的Token计算方式也有差异。有些模型会把聊天模板的格式也算进Token数，所以你实际付费的Token数和API返回的usage数之间，可能还会差一些。更隐秘的是，某些框架会在调用时自动往Prompt里加一些系统提示词，这些额外Token会体现在usage里，但如果你只检查自己拼接的Prompt，就会觉得对不上。

所以在做Token成本监控时，我建议以API返回的usage字段为准，而不是自己估算。同时，在Callback里记录Token数据时，一定要区分是Prompt侧的还是Completion侧的，这两个数字对成本分析的意义完全不同。

4.3 模型偶发超时或空响应，如何用Trace快速定位根因

模型偶发超时是最让人头疼的问题，因为复现概率低，没有固定规律。但如果你有完整的Trace数据，定位起来就从容很多。

拿到一条超时的Trace，先看耗时分布在哪一段。如果从llm_call Span来看，耗时达到了15秒，而整体超时阈值是20秒，那问题大概率出在模型服务本身。这时候再去查这个时间点有没有触发限流、模型服务有没有大量重试，就容易找到线索。

如果llm_call耗时正常，但整条链路还是超时了，那问题往往出在某个中间环节，比如检索器调用了外部搜索引擎，或者工具调用里去请求了一个第三方API，这个API在这个时间段变慢了。Trace的树状结构，能一秒钟帮你定位“慢在哪一段”。

对于空响应问题，Trace能提供的信息更加关键。一次正常回答的Trace里，llm_call的Span属性会有completion_tokens，如果这个值是0或者非常小，说明模型确实“什么都没输出”。这时候你再往前看Prompt属性，很可能是Prompt里包含了“如果你不知道答案，就回复不知道”之类的保守指令，遇到边缘问题模型就摆烂了。这种问题只看日志是看不出来的，非要看到完整的Prompt上下文才能揪出来。

4.4 主流可观测性工具选择：从Langfuse到OpenTelemetry生态

聊完排查技巧，再说说工具选型。这可能是很多团队最开始纠结的问题，我直接给出我的判断和建议。

如果你只是做一个简单的POC或者个人项目，想快速看到模型调用记录，Langfuse和LangSmith这类专门为LLM应用设计的可观测性平台是最省事的。它们开箱即用，界面直观，Token统计、Prompt追踪、成本分析都帮你做好了。Langfuse还支持开源自托管，数据安全上比较灵活。

如果你的项目已经有一定规模，或者公司有统一的监控体系，我建议直接上OpenTelemetry生态。它的优势在于标准化程度高，可以同时覆盖传统后端和AI场景，数据可以接入Prometheus、Jaeger、Grafana等一套成熟体系，不再为每一个新框架“造轮子”。特别是团队里还有传统后端服务需要监控时，统一用OpenTelemetry可以减少维护多套工具的成本。

还有一个我近期在用的方案，Arize Phoenix和Langfuse都提供了OpenTelemetry兼容的接口，相当于你用了OTel的标准协议，又能获得LLM专用的分析界面，算是一个两全其美的折中点。

工具没有绝对的好坏，关键是和你团队的规模、技术栈、预算匹配。测试阶段怎么快怎么来，生产阶段怎么稳怎么来，这两个阶段的诉求本来就不一样。

5. 经验总结与后续扩展方向

5.1 我的落地顺序建议：从日志埋点到链路治理分四步走

很多团队看到可观测性这么复杂，容易陷入两个极端。一个极端是“先搭个平台再说”，结果平台搭好了，业务代码没有埋点，数据全空；另一个极端是“业务先上线，监控以后再说”，结果上线那天就抓瞎。

我比较推荐的做法是，分四个阶段逐步落地，每个阶段都有明确的交付物，不追求一步到位。

第一阶段，先把结构化日志做好。所有关键事件都输出JSON格式日志，带上时间戳、事件名、请求ID。这一阶段不需要引入任何新平台，成本极低，但已经能支撑大部分问题的回溯。第二阶段，引入Trace。选择一个工具，把关键链路的Span打出来，重点关注“耗时分布”和“节点依赖关系”。第三阶段，把Callback和Trace打通，让Span拥有完整的业务上下文，这一步是排查“模型为什么这么回答”的利器。第四阶段，建立指标监控和告警体系，让问题在发生的一瞬间就被感知，而不是等用户来投诉。

这四个阶段不一定要严格按照顺序走，比如你一开始就在用LangSmith，那第一阶段可能直接跳过了，但思路是清晰的：数据采集从简单到复杂，排查能力从被动到主动。

5.2 下一阶段，可以给可观测性系统加入哪些能力

当你的Trace和指标体系稳定运行之后，可观测性的数据其实还有更大的价值可以挖掘，不只是“出问题时用来排查”这么简单。

比如，你可以基于历史的Trace数据，做模型性能的回归分析。每次升级模型版本、调整Prompt模板，都对比一下Token消耗、响应延迟、空响应率这些核心指标，用数据说话，而不是凭感觉判断“新版Prompt好像效果更好了”。

再比如，你可以设计自定义的业务指标，把“用户满意度”这类主观评价和Trace里的客观行为关联起来。我最近在试用一个方案，让用户在对话结束后点“满意/不满意”，然后把评价结果和Trace ID绑定。这样一来，我就能直接查看一条被用户点“不满意”的Trace，分析是检索没召回到有效信息，还是模型生成了低质量回复，这对产品迭代的价值极大。

还有更进阶的玩法，用可观测性数据做成本优化。Trace里记录了每次调用的Token和模型名，按天聚合之后，你能看到哪些功能消耗了大部分Token成本，哪些Prompt模板特别“烧钱”，从而指导模型选型和Prompt精简。

5.3 最后几句踩坑后的实话

回头来看，我做AI应用可观测性最大的体会是：不要等出了问题才想起来补监控，那时候你已经丢掉了很多关键数据。

有一次我在调整Prompt模板之后，没有及时对比Trace数据，结果模型空响应率悄悄涨了两个百分点，上线三天才被用户反馈发现。后来养成了习惯，每次Prompt变更，必看前后两天的Trace对比，确认空响应率、Token消耗、延迟三项指标没有恶化，才敢全量上线。

另外，可观测性建设一定要“贴着自己的业务做”。网上各种教程里的埋点方案可以抄，但哪些指标对你有意义，只有你自己最清楚。你需要的不是一套通用平台，而是一套能让你的团队“问出问题、得到答案”的数据链路。

这条链路搭好了，AI应用就不再是一个“靠概率工作”的黑盒，而是一个可以审视、可以优化、可以复盘的系统。对做技术的我们来说，这本身就很有成就感。