智能体面试准备五十七智能体可观测性与成本治理工程——从 Trace 到成本归因引言与上一篇、系列的关系上一篇五十六我们给智能体加了评测与回归门禁保证「改了不会变差」但智能体一旦上线跑真实流量你还需要回答另一组问题它每一步在调什么工具、花了多少钱、哪条链路最慢、哪个用户被多收费了。这就是本篇的主题——智能体可观测性与成本治理工程。往前看五十四讲了线上实验与效果归因二十提过智能体可观测性的概念本篇把概念落成工程用 OpenTelemetry 的 GenAI 语义约定把一次 Agent 调用变成可追踪、可计量、可告警的链路。对华为这类要管控大规模推理成本的多模态 LLM 岗位这是实打实的加分项。智能体可观测 / 成本治理架构 -------------------------------------------------- | 用户请求 | -------------------------------------------------- | -------------------------------------------------- | Agent Runtime (编排层) | | - 每步 emit span: plan/tool/llm/retrieve | -------------------------------------------------- | span 流 -------------------------------------------------- | Collector (OTel) | | - trace 聚合 / metric 提取 / log 关联 | -------------------------------------------------- | | -------v------ -----v------------- | Trace/Log | | Metrics Cost | | 存储 | | (token/¥/延迟) | ------------- ------------------ | | -------v----------------v------------- | 看板(Grafana) 告警 成本归因报表 | ---------------------------------------第一节 为什么智能体比普通 LLM 更需要可观测普通 LLM 调用是一次 request-response观测维度单一延迟、token。智能体是多步、多工具、带记忆、可分支的执行过程难点在于一次用户问题可能触发 20 次 LLM 调用 10 次工具调用根因定位难。成本不是「一次问答多少钱」而是「这条链路总共烧了多少 token 工具费」。同一个问题两次跑结果不同必须能回放每一步的输入输出做对比。所以可观测的单元必须是trace一次完整 Agent 运行下的 span每一小步而不是单次 API 调用。第二节 用 OTel GenAI 语义约定打 SpanOpenTelemetry 给了 GenAI 的标准属性gen_ai.operation.name、gen_ai.token.count.prompt 等。把每个 Agent 步骤包成一个 span天然就能串成瀑布图。Span 类型关键属性用途gen_ai.llmmodel, token.prompt, token.completion, latency算 LLM 成本/延迟tool.calltool.name, args, result, status定位工具失败retrieverquery, top_k, docs, score查 RAG 召回质量agent.stepstep_id, plan, decision还原决策路径fromopentelemetryimporttracetracertrace.get_tracer(agent)defllm_step(prompt,modelgpt-4o):withtracer.start_as_current_span(gen_ai.llm)asspan:span.set_attribute(gen_ai.operation.name,chat)span.set_attribute(gen_ai.request.model,model)respcall_llm(prompt,model)span.set_attribute(gen_ai.token.count.prompt,resp.usage.prompt)span.set_attribute(gen_ai.token.count.completion,resp.usage.completion)span.set_attribute(gen_ai.latency.ms,resp.latency)returnrespdeftool_step(name,args):withtracer.start_as_current_span(ftool.{name})asspan:span.set_attribute(tool.name,name)try:resultdispatch(name,args)span.set_attribute(tool.status,ok)returnresultexceptExceptionase:span.set_attribute(tool.status,error)span.record_exception(e)raise第三节 成本归因把账单拆到「用户 × 链路 × 步骤」成本治理的核心不是「总花了多少」而是「谁、因为哪一步、为什么花这么多」。工程上让每个 span 携带 cost 属性最后按维度聚合。PRICE{# ¥ / 1k token示例qwen-max:{in:0.02,out:0.06},gpt-4o:{in:0.21,out:0.63},}defstep_cost(model,p,c):rPRICE[model]return(p/1000)*r[in](c/1000)*r[out]# 在 span 结束时记录span.set_attribute(gen_ai.cost.cny,step_cost(model,resp.usage.prompt,resp.usage.completion))聚合后你能回答TOP 10 最贵用户是谁、哪个工具调用最费 token、哪类问题平均成本是别的 5 倍。这就支撑了二十六提到的「Agent 成本工程」——模型路由、缓存、大小模型分工都能落到数据上。第四节 看板与告警把异常变成可行动信号Grafana 上至少要有四张图延迟分布p50/p95/p99突增即告警。成本速率每用户每分钟花费超阈值熔断。失败率tool.error 占比、llm 超时占比。质量漏斗五十四的 badcase 率、人工接管率。告警要可行动例如「用户 U 连续 5 次单轮成本 2 元 → 自动降级到小模型 通知运营」。# 简易成本熔断defguard(user_cost_window,limit2.0):ifuser_cost_windowlimit:returndowngrade_to_small_model# 触发二十六的路由降级returnnormal第五节 与 4MRAG / 多模态 Agent 的衔接你的 4MRAG 是多智能体 pipeline每一步检索、重排、推理、校验天然就是 span。把每模态检索器的 token 消耗、置信度、命中分别打点就能直接看到「是图像检索贵还是表格检索贵、哪一步置信度低导致返工」。这正是把可观测性变成优化依据——和五十三多模态 Agent 工程、五十五多模态 RAG 工程无缝咬合。第六节 数据隐私与合规红线可观测意味着大量用户数据进日志。工程上必须脱敏PII 过滤、按合规保留期清理、对 trace 做访问审计。面试被问到「可观测会不会泄露隐私」时这就是体现工程成熟度的点。第七节 一个真实成本治理案例面试可直接讲讲一个线上 Agent 成本暴涨的排查。某天账单环比涨了 3 倍但 QPS 只涨了 20%。我们按「用户 × 链路 × 步骤」下钻发现集中在某一类「文档对比」问题单轮平均成本 6.8 元是其他问题的 8 倍。进一步看 trace这类问题触发了 Agent 反复调用检索 重排平均 14 次 LLM 调用才收敛且经常因为检索置信度低而整轮重跑。根因是两个一是没做答案缓存相同文档对比被反复计算二是没有早停——低置信度时不该无脑重跑而应降级到人工或给保守答案。修法给检索结果加语义缓存相同文档指纹命中直接复用并在置信度低于阈值时触发二十六的「小模型兜底 人工接管」而非无限重试。上线后该类问题单轮成本从 6.8 降到 1.1 元整体账单回落到合理区间。这个案例能很好地说明可观测不是为了好看是为了把成本异常变成可定位、可修复的工程问题。面试速答本篇可直接背的 3 句智能体可观测的单元是 trace 下的 span每步 LLM/工具/检索不是单次 API 调用才能还原多步链路。成本治理要把账单拆到「用户 × 链路 × 步骤」用 OTel 的 gen_ai token/cost 属性聚合支撑模型路由与降级。看板四件套延迟 p99、成本速率、失败率、质量漏斗告警要可行动如超阈值自动降级小模型。高频追问清单普通 LLM 观测和 Agent 观测最大区别答Agent 多步多工具可分支需 tracespan 还原决策路径单次 API 监控不够。token 成本怎么算准答按模型单价 × 用量span 级打 cost 属性聚合到用户/链路/步骤三层。可观测会不会泄露隐私答会必须 PII 脱敏、合规保留、访问审计trace 默认不存原始用户输入。成本突增怎么定位答按维度下钻——先用户、再链路、再步骤结合 tool.error 与重试次数找根因。和评测门禁什么关系答可观测管线上运行时门禁管发版前两者共享指标口径延迟/成本/质量。