传统 API 监控里，一条 HTTP 请求通常对应一个服务操作。LLM 应用不一样：用户问一句话，内部可能先检索两次、调用主模型、执行工具、再调用模型总结；上游断流后还可能换模型重试。只记录入口 latency 和 status=200，看不出回答为何错，也算不清真实成本。
我把 run 定义成一次用户意图的完整处理，下面挂 retrieval、model attempt、tool call、policy decision 和 finalization。HTTP request 是承载方式之一，不是业务身份。所有事件通过 run_id 串起来，最终状态由证据归并得出。
