一次请求花2块，token去哪了？

01三个信号：trace、metric、log

可观测三件套在LLM时代升级：trace记一次请求的span树，metric记聚合指标（P50/P99延迟、token/s），log记原始事件。

传统应用trace记函数调用链，LLM应用trace要额外记token流：每个span标明输入token、输出token、模型名、成本。一个Agent请求可能是这样的span树：根span（用户请求）→ 检索span（embedding+向量库）→ 规划span（LLM call 1）→ 工具调用span（LLM call 2 + API）→ 整合span（LLM call 3）。每一步的token和延迟都标出来，贵在哪、慢在哪立刻清楚。

工具栈：LangSmith/Langfuse（应用层trace）、OpenTelemetry + GenAI语义约定（标准协议）、Arize/Phoenix（LLM专用）。选型逻辑：用LangChain选LangSmith，自研选Langfuse（开源），要标准化选OTel。核心都是把LLM调用当一等公民记token和成本。

02tracing演示：看一次请求的token流

点「跑一次Agent请求」，看它被拆成5个span，每个span的token数、延迟、成本逐个点亮。最后看总账：哪步最贵、哪步最慢。

03trace能帮你发现什么

• 贵在哪：发现90%成本花在「整合LLM」那一步的输出token上——优化它（换小模型/压缩prompt）成本砍半。
• 慢在哪：发现P99延迟被「工具调用」的串行等待拖垮——改并行或加缓存，延迟降60%。
• 浪费在哪：发现检索每次都把全部文档塞进prompt（输入token爆）——改top-k或重排，输入token砍70%。
• 错在哪：发现某类请求总在「规划LLM」步重试3次——改prompt或加few-shot，错误率下降。

一个真实案例：Agent上线后单请求成本$0.05，老板觉得贵。trace一看，60%成本在「整合LLM」输出2000 token总结，但用户只看前200字。解法：整合步换GPT-4o-mini + 限制max_tokens=300，成本砍到$0.015，体验无感。没有trace，这种优化无从下手——你根本不知道token去哪了。

04带走这套清单