自测与辨析

①概念层 · 记得 / 认得

1. 用一句话分别说出可观测性、eval、传统 APM 三者在时机和对象上的区别。
   展开答案

   可观测性：运行期，对象是单条真实运行。eval：开发期 / CI，对象是固定数据集。传统 APM：运行期，对象是单请求（但判据只到状态码 + 延迟，不进语义）。三者只在"在线评估"处相交（详见第 3 章）。

2. 一个 span 的 parent_span_id 为空，意味着什么？它在 agent 的一次运行里通常是哪个 operation？
   展开答案

   它是这棵 trace 的根 span（root span），没有父节点。在 agent 运行里通常是 invoke_agent，代表一次完整运行的起点，其下挂着各 chat / execute_tool / retriever 子 span，全树共享同一 trace_id。

3. 为什么 prompt / completion 文本放在 span 的 events 而不是 attributes？给两个原因。
   展开答案

   ① attributes 设计为低基数、可聚合的结构化键值，prompt 文本每条唯一（高基数），放进去会撑爆时序索引；② prompt 体积大（数 KB）且常含 PII，attributes 的批量索引无法做细粒度访问控制，且会被 SDK 默认的 4–64KB 截断阈值静默砍掉。events 是带时间戳的日志事件，为大块 / 敏感内容而设，且 opt-in。

4. OTel GenAI semconv 里有 gen_ai.usage.input_tokens，却没有 gen_ai.cost.*。成本由谁、在什么时候算出来？
   展开答案

   由可观测性 backend 在 ingestion（落库）时算：用 span 里的 token 数 × 内置定价表。规范不定义成本，是因为同样 token 数的价格随账户折扣、厂商调价、模型版本变动，写进规范会让规范追着调价跑。后果：不同 backend 的成本数字可能因定价快照时间点不同而有差异，不代表 token 数据有误。

5. 说出"三支柱"（traces / metrics / logs）在 LLM 可观测性里各自的角色变化。
   展开答案

   traces 主导——span 树是执行图，是"为什么"的直接载体。metrics 退化为直方图（token 用量、操作耗时、TTFT 分布）；把 prompt / user-id 当 metric label 会引发基数爆炸。logs 降级为 span 上的 events，独立日志流不再是主要手段。

②机制层 · 会推 / 会算

1. 两个独立进程里的 agent，怎么做到它们的 span 落在同一棵 trace 树上？关键是哪个 HTTP 头，它传的是什么？
   展开答案

   靠 context propagation：上游在跨进程调用时把 W3C traceparent 头（含 trace_id 和当前的 parent_span_id）附在请求里；下游读取它，用其中的 parent_span_id 作为自己根 span 的父，并把 trace_id 原样继承。于是两个进程的 span 共享同一 trace_id、父子关系正确相连。头没传，子 agent 的 span 就成孤儿，树断裂。

2. 差旅助理并发调用 search_flights 和 retrieve_policy，怎么保证两个 execute_tool span 都挂在正确的父节点下？什么情况下会变成孤儿 span？
   展开答案

   每个 span 创建时从当前调用点的 context storage（如 Python 的 contextvars.ContextVar）读取当前 span id 作为自己的 parent_span_id。只要两个工具调用都在同一个决策 chat span 的执行上下文里发起，就都以它为父，互不干扰。孤儿出现在：把调用扔进新线程 / 新进程却没把 context 复制过去（如裸 threading.Thread 而非 OTel 的 context-propagating wrapper），新执行体看到空 context。

3. 代理网关（HTTP 拦截）和进程内 SDK 相比，哪一类信息代理网关结构性地看不到？为什么这是架构决定的、不是配置问题？
   展开答案

   代理网关只看到进出 LLM API 的 HTTP 请求 / 响应（模型名、prompt、completion、latency、状态码），看不到进程内的编排状态：agent 为什么选这个工具、检索召回了哪些文档、路由决策的候选是什么。这些状态从不离开应用进程、不走那一跳 HTTP，所以代理在网络层无论怎么配置都拿不到。因此代理网关适合成本 / latency 监控，不适合调试 agent 决策链。

4. 在线评估的步骤里，"异步"和"分层采样"分别解决什么问题？去掉它们各会怎样？
   展开答案

   异步：scorer 在 trace 落库后才跑，不阻塞热路径。去掉（同步打分）= 给每次 agent 运行的关键路径叠加一次额外 LLM 调用的延迟。分层采样：低分 / 可疑区域多采、正常区域少采。去掉（均匀采样）= 在 bug 密度低时几乎采不到失败 trace，scorer 看到的全是正常 case，监控形同虚设。

5. 一棵 trace 里有 5 个 chat span，根 invoke_agent span 自己不调 LLM。trace 级的 token 总量怎么得到？两种实现方式分别在哪一层做聚合？
   展开答案

   每个 chat span 自记 gen_ai.usage.*（billable token），父 span 汇总子 span 的数值得到 trace 级总量。两种实现：① SDK 侧——父 span 关闭时遍历子 span 求和（OpenInference / Phoenix 路线）；② backend 侧——ingestion 后由查询 API 提供 trace 级聚合（LangSmith / Langfuse 路线）。结果相同，区别只在聚合发生的位置。

③应用判别层 · 会选 / 会判（跨章）

每个场景都把多章概念混在一起，括号标出主要涉及哪些章。先判断"该用哪个工具 / 看哪里"，再展开。

1. 场景（第 1、3 章）：线上 agent 给用户的答复是错的，但 HTTP 返回 200，Datadog 的错误率 / 延迟仪表盘一切正常。这是可观测性、eval 还是 APM 的活？下一步具体看什么？
   展开分析

   这是可观测性的活（运行期、还原单条真实运行）。APM 盲，因为语义失败对状态码不可见。下一步：打开这条 trace，沿父子链从最终答复 span 向上回溯，逐级检查每个 span 的中间状态——工具返回了什么、检索召回了哪些文档、路由 chat 选了哪个工具，找到第一个产出"语义上坏"输出的 span（根因 span）。eval 在这里帮不上：它对的是数据集，不是这一条线上运行。

2. 场景（第 2、4 章）：LangGraph 创业团队，数据不能出境（自托管），人力有限但想要在线评估。给出 emitter + backend 的组合，并说出五条判别轴各倾向哪端。
   展开分析

   组合：OpenLLMetry（emitter）+ 自托管 Langfuse（backend），OTLP 串联。五轴：开放标准（OTel，避免迁移成本）；自托管（数据不出境，Langfuse 开源 MIT 自托管成熟）；框架无关（妥协 LangSmith 的 LangChain 耦合换数据主权）；all-in-one（Langfuse 2025-06 开源 LLM-as-judge 满足在线评估）；进程内（要调试编排失败，必须进程内 instrumentation）。

3. 场景（第 1、3 章）：差旅助理某次运行成本是平时的 3 倍，但功能正常、用户拿到了答复。怎么用 trace 定位？这是 obs 还是 eval 的活？
   展开分析

   obs（运行期单条运行的成本归因）。定位：按 invoke_agent 根 span 找成本最高的运行，展开子树，比较各 chat span 的 gen_ai.usage.*；若看到同名 execute_tool（如 search_flights）并列出现多次，且其中有 status=ERROR，说明工具失败触发了 LLM 自发重试循环，每次把全量历史重喂、token 线性叠加。根因是工具层无重试上限，不是 prompt。eval 看不到这个——它不跑在这条真实 trace 上。

4. 场景（第 1、3 章）：团队声称"99.9% 可用性 + P95 延迟监控都正常，质量没问题"。这套监控有什么盲区？需要补什么？
   展开分析

   盲区：可用性和延迟是 APM 式指标，对语义失败和悄悄重试都不可见。一个 agent 可以 99.9% 可用、P95 正常，同时幻觉率在涨、工具在后台重试烧钱。需要补：① cost/run 告警（APM 没有的一等信号）；② 子 span 工具失败率（根 span OK 掩盖工具层 ERROR）；③ 在线评估——对采样生产 trace 打质量分，把"答得对不对"变成可监控的数。

5. 场景（第 1、3 章）：受 HIPAA 约束，团队对生产 trace 做脱敏，只对 gen_ai.output.messages（最终输出）脱了敏。够吗？还缺什么？
   展开分析

   不够。① 输入侧 gen_ai.input.messages 同样含 PII，也要脱；② 更隐蔽的是推理链 PII 泄漏——带思维链的模型（o1/R1 类）在 reasoning token 里会用到上下文 PII，即便最终输出干净。正确做法：把 input / output / reasoning 三类 events 全纳入脱敏管道，或对敏感业务直接禁用这三类 opt-in 捕获、改自托管私有存储。只脱输出是半截子工程。