想象你是一家繁忙日料店的老板，后厨分成主厨、配菜、烤台三个工位。一天晚上，客人连续退了三份寿司，你冲进后厨想追责，却发现没有任何记录：是食材不新鲜，还是捏法变了？是芥末放多了，还是出菜太慢导致凉了？没有监控和记录的后厨，就是一个“黑箱”——出了问题只能靠猜。AI Agent 的开发体验正是如此：用户的一个请求会触发“大模型规划 → 调用工具 → 再总结回复”多个环节，每一步都可能出错、变慢或烧掉大量 Token，而开发者面对的全是迷雾。 可观测性（Observability）就是给后厨装上监控系统，由三根支柱构成：日志像厨师便签、指标像营业统计、追踪像全程录像。LangSmith 与 Phoenix 是两套围绕“追踪”构建的成熟工具——LangSmith 像一张“订单追踪单”，逐条记录每次执行的每个步骤；Phoenix 像一块“后厨监控大屏”，把执行链、Token 消耗、延迟瓶颈直观呈现。掌握它们，你就拥有了透视 Agent 黑箱的能力。

岗位关联

对 AI Agent 开发者而言，可观测性决定了你能否从“能跑通”走向“能调优”。学会 LangSmith 和 Phoenix，等于给 Agent 装上仪表盘——这是从原型到生产级应用的关键技能。

目录
  1. 可视化演示
  2. 可观测性基础
  3. LangSmith追踪
  4. Phoenix可视化
  5. Token消耗分析
  6. 延迟瓶颈定位
  7. 错误诊断
  8. 调试优化实战
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

动态演示Agent可观测性的核心机制，通过概览/流程/对比/趋势四种模式展示关键概念与交互流程。

本节配有交互动效（进入视口后自动加载，约 3KB）。

Agent可观测性：Agen Agent可观测性的核心概念与 LangSmith的执行链追踪 核心机制可视化 Agent可观测性整体架构与关键组件

可观测性基础

假设你经营一家日料店，后厨分成主厨、配菜、烤台三个工位。一个晚上，客人连续退了三份寿司，你冲进后厨想追责，却发现没有任何记录：是食材不新鲜，还是捏寿司的手法变了？是芥末放多了，还是出菜太慢导致凉了？没有监控和记录的后厨，就是一个“黑箱”——出了问题只能靠猜。

AI Agent 的开发体验正是如此。用户的一个请求，会触发“大模型规划 → 调用工具 → 再交给大模型总结”的多个环节，每一步都可能出错、变慢或消耗大量 Token。当结果不符合预期时，开发者面对的也是一团迷雾。可观测性（Observability）就是给这个“后厨”装上监控记录系统，它由三大支柱构成：日志（Logs）像厨师的便签，记录零散事件；指标（Metrics）像营业统计，反映整体趋势；追踪（Traces）像全程录像，还原单次请求的完整执行过程。三者配合，才能把黑箱变成明箱。

对 Agent 而言，追踪是价值最高的那根支柱。一条 Trace 记录一次完整的请求执行链，内部由若干 Span 组成——每个 Span 对应一次 LLM 调用、一次工具调用或一段逻辑判断，附带耗时、Token 消耗、输入输出等元数据。LangSmith 和 Phoenix 正是围绕 Trace 构建的观测平台。它们能回答三个问题：发生了什么、为什么发生、如何修复。这就是可观测性区别于“打印日志”的核心：数据是结构化的、有关联的、可查询的。

装上监控系统之后，再有人退单，你可以直接调出对应时段的“录像”，看到是配菜切错料还是烤台温度失控。Agent 应用同样是这个道理——LangSmith 与 Phoenix 就是你的后厨摄像头，让每一次执行都有据可查、有因可溯。

Ttotal=T1+T2+⋯+Tn\displaystyle T_{\text{total}} = T_1 + T_2 + \cdots + T_n
这条公式说明：Agent 串行执行的步骤越多、每步越慢，整体延迟就越高。它也是后面“瓶颈占比”计算的基础。
  1. 总耗时 T_total表示 Agent 从接收请求到返回结果的完整时长，是整个执行链的性能总指标。
    TtotalT_{\text{total}}
  2. 单步耗时 T_i执行链中的每个环节，例如一次 LLM 推理或一次工具调用，各自花费的时间。
    TiT_i
  3. 累加求和由于 Agent 默认串行执行各步骤，总耗时就是每一步耗时的总和。
    T1+T2+⋯+TnT_1 + T_2 + \cdots + T_n

LangSmith追踪

大型餐厅的每位服务员手里都有一张订单追踪单：几点接单、谁配菜、谁掌勺、几点出菜，每一站都盖时间戳。顾客催单时，扫一眼追踪单就知道卡在哪个工位。LangSmith 就是 AI Agent 世界的“订单追踪单”。

LangSmith 由 LangChain 团队开发，接入方式非常轻量——在代码里配置一个环境变量或回调，它就能自动为每一次 Agent 执行生成 Trace。打开 LangSmith 的项目面板，所有执行记录按时间排列；点开任意一条，一棵“执行树”徐徐展开：根节点是整个 Agent 执行，子节点依次是 LLM 调用、工具调用、检索等具体步骤，每个节点都记录着耗时、输入输出、模型信息和 Token 用量。这个结构化的记录，就是调试 Agent 的第一手材料。

新手拿到一条 Trace 通常会问：先看什么？答案是看三样东西——一是步骤顺序，确认 Agent 是否按预期规划执行；二是每步耗时，找出拖慢整体的环节；三是 Token 消耗，找出成本黑洞。LangSmith 的每个 LLM 节点都会标注输入 Token 与输出 Token，聚合后可以说清“哪个步骤在为哪部分内容付费”。

就像订单追踪单让催单的顾客得到准确答复，LangSmith 让“Agent 在做什么、做到哪一步了”第一次变得可见。调试不再靠猜，而是按图索骥。

Ntokens=Nprompt+Ncompletion\displaystyle N_{\text{tokens}} = N_{\text{prompt}} + N_{\text{completion}}
一次 LLM 调用的 Token 消耗由输入（送进模型的全部内容）和输出（模型生成的内容）两部分构成，LangSmith 会为每个 LLM 节点记录这两个数值。
  1. Token 总量 N_tokens一次 LLM 调用在计费意义上的消耗总和，也是衡量一次执行“贵不贵”的基本单位。
    NtokensN_{\text{tokens}}
  2. 输入 Token 数 N_prompt系统提示词、历史对话、工具返回结果等拼装进请求的 Token 总和。
    NpromptN_{\text{prompt}}
  3. 输出 Token 数 N_completion模型本次生成内容的 Token 总和。
    NcompletionN_{\text{completion}}
  4. 相加输入与输出分别计数，共同构成一次调用的完整消耗。
    Nprompt+NcompletionN_{\text{prompt}} + N_{\text{completion}}

Phoenix可视化

除了订单追踪单，大型后厨还会在墙上挂一块实时监控大屏：所有工位的状态、等待中的订单、异常警报，一屏尽览。Phoenix 就是 Agent 后厨的这块“监控大屏”。

Phoenix 是 Arize AI 推出的开源可观测性平台，它的最大特点是“本地优先”——可以跑在你的 Jupyter Notebook 里，也可以作为本地服务启动，追踪数据不需要上传任何云端。它兼容 OpenTelemetry 标准，并内置了 LangChain、LlamaIndex 等框架的回调集成。启动本地服务后，打开浏览器就能看到 Agent 的实时执行流。

Phoenix 的强项在可视化交互：执行链以树状图呈现，点开任意节点，完整的 Prompt、工具参数和返回结果都摊在眼前；它还支持在时间轴上回放执行轨迹，观察多轮对话中上下文如何演变。对 RAG 类 Agent，Phoenix 还提供了 embedding 向量的聚类与检索质量分析——这补上了 LangSmith 不具备的一块拼图。两者定位不同：LangSmith 是托管式追踪服务，Phoenix 是本地化深度分析利器。

监控大屏的价值在于把零散的信息组织成可读的图景。Phoenix 把执行链中的每一个 Span 组织成一棵可视化树，就像大屏上的工位状态灯，哪里积压、哪里异常，一眼看完。

S=1+∑i=1mCi\displaystyle S = 1 + \sum_{i=1}^{m} C_i
这条公式描述执行链的结构：整条 Trace 是一棵树，根节点之外的每一个 Span 都属于某一层，总节点数就是树上所有节点的和。Phoenix 把这棵树画给你看。
  1. Span 总数 S一条执行链（Trace）中被记录节点的总个数，树越大说明 Agent 逻辑越复杂。
    SS
  2. 根节点 1整个 Agent 执行本身也是一个 Span，作为树的根。
    11
  3. 子 Span 数 C_i第 i 层（如一次 LLM 调用、一次工具调用）产生的子 Span 数量。
    CiC_i
  4. 全层求和把每一层的子 Span 数加起来，就是根以外全部节点。
    ∑i=1mCi\sum_{i=1}^{m} C_i

Token消耗分析

餐厅老板每月对账时，最关心的是食材成本：进货花了多少、哪道菜毛利最低、哪个环节浪费最严重。AI Agent 的“食材”就是 Token——每一次 LLM 调用的输入输出都按 Token 计费，而账单总在月底才让人肉疼。

Token 消耗分析的第一步是拆解。一次 LLM 调用的 Token 消耗分为两部分：输入 Token（prompt_tokens），包括系统提示词、历史对话、工具返回等送入模型的全部内容；输出 Token（completion_tokens），即模型生成的内容。两者计价不同，通常输出 Token 的单价是输入的两到三倍。LangSmith 和 Phoenix 都会在 Trace 的每个 LLM 节点上记录这两项数值。

把同一执行链上的 Token 数按 Span 聚合，就能回答关键问题：哪一步消耗最大？是历史对话太长，还是模型回复过于冗长？更进一步，乘以单价就能得到每次调用的成本，并据此建立“单次任务成本基线”。常见的优化手法包括：压缩系统提示词、用滑动窗口代替全量历史、对工具返回结果做摘要、把简单任务路由到更便宜的小模型。没有 Trace 数据，这些优化都无从谈起。

正如成本卡决定一道菜的毛利，Token 分析为 Agent 的每个“动作”定了价。当账单来临，你能精确指出“六成 Token 花在了历史重注入上”，而不是对着总费用发愁。

C=pin×Nin+pout×Nout1000\displaystyle C = \frac{p_{\text{in}} \times N_{\text{in}} + p_{\text{out}} \times N_{\text{out}}}{1000}
云厂商的 API 普遍按“每千 Token”计价，且输入输出单价不同。这条公式把 Token 数量换算成真实的金钱成本。
  1. 输入成本输入 Token 单价乘以输入 Token 数，得到输入部分的原始计费额。
    pin×Ninp_{\text{in}} \times N_{\text{in}}
  2. 输出成本输出 Token 单价乘以输出 Token 数，得到输出部分的原始计费额。
    pout×Noutp_{\text{out}} \times N_{\text{out}}
  3. 合并输入与输出成本相加，得到本次调用的完整计费额。
    pin×Nin+pout×Noutp_{\text{in}} \times N_{\text{in}} + p_{\text{out}} \times N_{\text{out}}
  4. 除以 1000把“Token 个数”换算成“千 Token”这一计价单位。
    ⋯1000\frac{\cdots}{1000}

延迟瓶颈定位

顾客投诉“出菜太慢”时，有经验的店长不会盲目加人，而是站在出菜口观察：是烤台积压，是配菜太慢，还是传菜路线太长？定位瓶颈的正确姿势，是记录每个工位的耗时，让数据说话。

Trace 天生就是“耗时账本”。打开一条慢请求的执行链，把每个 Span 的耗时从大到小排列，占比最高的那个就是瓶颈。Agent 的延迟大多来自三个环节：LLM 调用（网络传输加 Token 生成，往往占据大头）、工具调用（外部 API 或数据库查询）、上下文构建（历史越长，传输越慢）。这三类问题的优化手段截然不同，所以先定位、再优化，是延迟调优的铁律。

定位之后对症下药。如果瓶颈是 LLM 输出过长，限制 max_tokens 或换用更快的模型；如果瓶颈是工具调用，加上缓存或把多个独立调用改成并发；如果瓶颈是历史上下文臃肿，缩短对话窗口或引入检索摘要。Phoenix 的时间线像甘特图一样把各 Span 并排铺开，一眼就能看出哪个步骤“长得离谱”。

瓶颈占比超过 50% 意味着什么？就像烤台聚集了六成积压订单，此时加两个烤台位远比给传菜员买运动鞋有效。优化永远要瞄着占比最高的环节打，这正是可观测性给出的方向感。

R=Tmax⁡Ttotal\displaystyle R = \frac{T_{\max}}{T_{\text{total}}}
瓶颈占比 = 最长步骤耗时 ÷ 总耗时。这个比值告诉你：优化哪一步，收益最大。
  1. 最长步骤耗时 T_max从 Trace 各 Span 耗时中取最大值，这个步骤就是首要怀疑对象。
    Tmax⁡T_{\max}
  2. 全链路总耗时 T_totalAgent 从开始到结束的整体执行时长。
    TtotalT_{\text{total}}
  3. 做比值最长步骤占总耗时的比例。超过 50% 说明该步骤是决定性瓶颈，优化它收益最大。
    Tmax⁡Ttotal\frac{T_{\max}}{T_{\text{total}}}

错误诊断

顾客退菜时，讲究的餐厅会做“事故复盘”：是食材不新鲜（输入问题），是菜谱本身有问题（提示词问题），是厨师火候失控（模型行为异常），还是传菜送错了桌（输出解析错误）？没有记录，只能重做一份碰运气；有记录，才能锁定真正的原因。

Agent 的错误诊断遵循同样的逻辑。LangSmith 的 Trace 列表支持按状态过滤，失败的执行会标注错误类型：超时、工具异常、输出格式非法等。点开一条失败轨迹，出错的 Span 会高亮显示，输入、输出、异常堆栈全部保留，上下文完整无缺——这比传统日志的“一行报错信息”有用得多。

更进阶的用法是对比诊断：把一条成功轨迹和一条失败轨迹并排放置，逐 Span 对照差异——是工具参数不同？是上下文缺失？还是模型随机性导致规划分叉？Phoenix 的时间轴回放也擅长这个。此外，Trace 数据还能支撑自愈设计：遇到偶发错误时，超时重试一次，或让 Agent 切换到备用工具路径，并在下一次追踪中验证修复是否生效。

有了全程记录，菜品出错不再是玄学。成功与失败轨迹的并排对比，就像两次出菜的监控录像同时回放，一切差异都摆在眼前——这就是可观测性给错误诊断带来的确定性。

P=NokNtotal\displaystyle P = \frac{N_{\text{ok}}}{N_{\text{total}}}
成功率 = 成功执行的轨迹数 ÷ 全部被追踪的轨迹数。它是 Agent 可靠性的最直观体检指标。
  1. 成功轨迹数 N_ok观测平台上标记为成功完成的执行轨迹条数。
    NokN_{\text{ok}}
  2. 总轨迹数 N_total所有被追踪到的执行轨迹，包含成功与失败。
    NtotalN_{\text{total}}
  3. 计算比率成功率越接近 1，Agent 越稳定；失败轨迹则是诊断问题的最佳入口。
    NokNtotal\frac{N_{\text{ok}}}{N_{\text{total}}}

调试优化实战

生意好的餐厅，每月都会做一次复盘：哪些菜卖得好，哪些工位忙闲不均，哪些环节浪费严重。复盘的方法论永远是同一句话：记录、分析、调整、再记录。Agent 的调试优化，走的也是这条闭环。

实战中的标准流程可以拆成四步。第一步，发现问题：通过 Trace 面板的延迟、错误率或成本指标，找到异常的轨迹。第二步，复现并拆解：在 LangSmith 中打开对应 Trace，确认失败或卡顿发生在哪个 Span，把这条轨迹存成回归用例。第三步，修复与验证：修改提示词、工具逻辑或模型参数后重跑，用新旧两条 Trace 对比差异。第四步，持续监控：把指标接到告警，让下一次异常自动浮出水面。

优化的收益要量化才可信。先通过 Trace 测出基线耗时，实施优化后再测新值，用提升率评估效果。无论是缩短延迟、降低 Token 成本，还是提高成功率，都遵循“先测基线、再做优化、后验收益”的流程。可观测性工具的价值就在于，让每一次改动都有数据背书，而不是“感觉变快了”。

就像餐厅的月度复盘让经营越做越顺，Agent 开发者借助 LangSmith 与 Phoenix 这张“仪表盘”，把每一次调试都变成有数据支撑的迭代。可观测性不是一次性投入，而是伴随 Agent 整个生命周期的“后厨监控系统”。

Tnew=Told×(1−η)\displaystyle T_{\text{new}} = T_{\text{old}} \times (1 - \eta)
优化后耗时 = 基线耗时 ×（1 − 提升率）。这条公式把“优化有没有用”变成了一道可计算的题。
  1. 基准耗时 T_old通过 Trace 测得的优化前基线耗时。
    ToldT_{\text{old}}
  2. 提升率 η某项优化（并发、缓存、压缩上下文）带来的耗时下降比例，取值在 0 到 1 之间。
    η\eta
  3. 剩余比例 1−η优化后残留的耗时占比。
    1−η1 - \eta
  4. 相乘得新耗时用基线乘以剩余比例，预估出优化后的总耗时。
    Told×(1−η)T_{\text{old}} \times (1 - \eta)

AI 应用场景

场景一：Agent 上线后的性能监控与告警

阶段：部署与运维

解决的问题：Agent 上线后，传统方式靠用户反馈和人工翻日志排查问题，信息滞后且难以定位。接入 LangSmith 后，每次执行自动生成 Trace，开发团队可以按延迟、Token 消耗、错误率设置告警，第一时间发现异常轨迹。

具体案例：某客服 Agent 团队部署后，LangSmith 面板显示“工具调用”步骤的平均耗时从 300ms 飙升至 2s。点开 Trace 发现是天气 API 的第三方接口变慢，团队添加了缓存和超时重试，该步骤瓶颈占比从 60% 降回 20%。

场景二：RAG 问答 Agent 的检索质量排查

阶段：测试与调优

解决的问题：RAG Agent 答非所问时，难以判断是检索召回差还是生成环节的问题。Phoenix 的可视化执行链展示检索调用与生成调用，配合 embedding 质量分析，帮助定位问题环节。

具体案例：开发者用 Phoenix 打开一条“答非所问”的失败轨迹，发现召回的是无关文档，而生成环节正常。通过对比成功与失败轨迹的检索 query，发现是问题改写环节丢失了关键实体，修正后回答准确率提升 30%。

场景三：LLM 调用成本归因与优化

阶段：模型优化

解决的问题：月度 Token 账单高企，说不清钱花在哪。通过 Trace 按 Span 聚合 Token 消耗，识别出成本黑洞环节并精准优化。

具体案例：某数据分析 Agent 团队通过 LangSmith 的 Token 聚合发现，68% 的输入 Token 来自重复注入的历史对话。改为滑动窗口 + 关键信息摘要后，总 Token 消耗下降 42%，单次任务成本降低近一半。

Python 演示

python56 行
"""简易 Agent 轨迹分析器：模拟 LangSmith / Phoenix 的 Trace 数据并做多维度分析。"""from dataclasses import dataclass, fieldfrom typing import List, Dict, Any  @dataclassclass Span:    name: str    span_type: str  # llm / tool / agent    duration_ms: float    token_in: int = 0    token_out: int = 0    error: str = ""    children: List["Span"] = field(default_factory=list)  def build_sample_trace() -> Span:    """构造一条模拟的天气问答 Agent 执行链。"""    llm1 = Span("规划指令", "llm", 850, token_in=420, token_out=180)    tool = Span("查询天气", "tool", 1200, token_in=60, token_out=45)    llm2 = Span("总结回复", "llm", 640, token_in=700, token_out=210)    root = Span("天气助手", "agent", 0)    root.children = [llm1, tool, llm2]    root.duration_ms = llm1.duration_ms + tool.duration_ms + llm2.duration_ms    return root  def walk(spans: List[Span]):    """深度优先遍历，产出所有 span。"""    for s in spans:        yield s        yield from walk(s.children)  def analyze_trace(root: Span) -> Dict[str, Any]:    """汇总 span 数、Token 消耗、耗时、错误与瓶颈。"""    spans = list(walk([root]))    total_tokens = sum(s.token_in + s.token_out for s in spans)    total_ms = max(root.duration_ms, 1)    slowest = max(spans, key=lambda s: s.duration_ms)    errors = [s.name for s in spans if s.error]    return {        "span_count": len(spans),        "total_tokens": total_tokens,        "total_ms": total_ms,        "errors": errors,        "slowest_step": slowest.name,        "bottleneck_ratio": round(slowest.duration_ms / total_ms, 2),    }  if __name__ == "__main__":    trace = build_sample_trace()    report = analyze_trace(trace)    for key, value in report.items():        print(f"{key}: {value}")
目的：用一段极简代码模拟 LangSmith/Phoenix 的核心分析能力——把一条 Agent 执行链（Span 树）汇总为 Token 总量、总耗时、错误清单和瓶颈占比。
  1. root.children = [llm1, tool, llm2]手动构造执行链的父子关系，对应真实工具自动生成 Trace 时的层级结构。
  2. yield from walk(s.children)递归深度优先遍历，把所有层级的 Span 都找出来，就像展开一棵执行树。
  3. total_tokens = sum(...)聚合所有 LLM 调用的输入输出 Token，对应 LangSmith 的 Token 统计。
  4. slowest = max(spans, key=lambda s: s.duration_ms)找出耗时最长的步骤，这是瓶颈定位的关键一步。
  5. "bottleneck_ratio": round(...)计算瓶颈占比，呼应正文公式 R = T_max / T_total。

常见误区

误区我在代码里加了很多 print，把中间结果都打出来了，这不就是可观测性了吗？

正解print 日志是零散、无结构的，无法自动关联一次请求的全链路。真正的可观测性需要结构化的 Trace 数据——每条记录都带 trace_id、span_id 和父级关系，LangSmith 和 Phoenix 正是基于这种结构化数据还原执行链，而不是靠人肉读日志。就像后厨的监控录像和厨师随手写的便签，记录的详略和关联性完全不同。

为何常见：初学开发时调试小程序只用 print，习惯性地把“输出信息”等同于“可观测性”，忽略了数据结构与关联关系才是核心。

误区每次调用都记录 Trace，肯定会让 Agent 慢很多，生产环境不敢开。

正解LangSmith 等工具采用异步上报和本地缓冲，追踪开销通常在毫秒级，对整体延迟影响很小（一般低于 5%）。Phoenix 更是支持纯本地部署，数据不出内网。相比盲目运行导致的高昂排查成本，这点开销完全可以接受；如果实在敏感，还可以配置采样率，只追踪部分请求。

为何常见：担心额外的 IO 会阻塞主流程，实际上追踪是异步旁路，与主执行链解耦，并非串行等待。

误区都是追踪工具，选一个用就行了，两个都用太浪费。

正解两者侧重点不同：LangSmith 是托管式全流程追踪加数据集管理，适合团队协作与持续集成；Phoenix 是开源本地可视化，擅长深度分析执行树、embedding 和检索质量。生产实践中常常组合使用——LangSmith 做日常监控，Phoenix 做专项剖析，各取所长。

为何常见：同类工具容易造成“替代品”的印象，忽略了它们在追踪、可视化、嵌入分析等不同环节上的互补价值。

误区Agent 跑通了就重点看成功案例，失败案例反正会重试，无所谓。

正解失败轨迹往往藏着系统设计缺陷——是提示词不清、工具参数错误，还是上下文缺失？LangSmith 可以按错误类型过滤失败轨迹，Phoenix 支持对比成功与失败路径。分析失败轨迹才是提升可靠性的关键入口，成功率公式中的失败样本就是诊断的富矿。

为何常见：人天然倾向于从成功中总结经验，但失败样本的信息量往往大得多，只是需要主动去看。

误区月度 Token 账单看总数就够了，超标了再说。

正解总量掩盖了结构性问题——是哪一步调用消耗了 80% 的 Token？是上下文重复注入，还是输出过长？通过 Trace 的 Token 明细按 Span 聚合，才能定位成本黑洞，再针对性地压缩历史、精简提示词或路由到小模型。没有结构拆解的成本分析，就像只看到食材总账单却不知道哪道菜赔钱。

为何常见：成本监控停留在汇总层面，缺乏拆分到调用维度的意识和工具支撑。

面试题

Q1. 可观测性的三大支柱通常是指？

单选题 · easy

  • A.日志、指标、追踪← 正确答案
  • B.代码、测试、部署
  • C.输入、输出、缓存
  • D.网络、存储、计算

答案：A。可观测性三支柱是日志（Logs）、指标（Metrics）和追踪（Traces），分别对应餐厅后厨的纸质便签、统计数据与全程录像，三者互补构成完整图景。B 是开发流程，C 是数据形态，D 是系统资源，均不构成可观测性支柱。

Q2. LangSmith 的核心功能是？

单选题 · easy

  • A.训练大模型基础参数
  • B.追踪 Agent 执行链路← 正确答案
  • C.部署模型到目标服务器
  • D.自动生成海量训练数据

答案：B。LangSmith 是 LangChain 生态的追踪与调试平台，核心功能是记录每次 Agent 执行的完整链路（Span 树），相当于餐厅的订单追踪单。训练、部署、数据生成均不在其核心定位内。

Q3. Trace 与 Log 的关键区别在于？

单选题 · easy

  • A.Trace 有层级关联，Log 相互独立← 正确答案
  • B.Log 只能存文本，Trace 只能存数值
  • C.Trace 用于前端，Log 只用于后端
  • D.两者在概念上完全等同没有区别

答案：A。Trace 通过 Span 的父子关系还原一次请求的完整执行树，而传统 Log 是独立条目，难以自动关联。就像餐厅的监控录像（Trace）与零散便签（Log），前者能还原完整过程，后者只能看到碎片信息。

Q4. 在一次追踪中，一次 LLM 调用通常被记录为？

单选题 · mid

  • A.一条普通日志条目
  • B.一个 Span 追踪节点← 正确答案
  • C.一组聚合统计指标
  • D.一份静态配置文件

答案：B。追踪系统用 Span 表示一次有父级关系的操作单元，多个 Span 组成一棵 Trace 树来还原完整执行链。日志条目无结构、指标是聚合数值、配置文件是静态内容，都不具备“执行链节点”的语义。

Q5. 某次 LLM 调用输入 800 Token、输出 200 Token，输入单价 $3/千Token、输出单价 $6/千Token，本次调用成本为？

单选题 · mid

  • A.成本约 1.8 美元
  • B.成本约 2.4 美元
  • C.成本约 3.6 美元← 正确答案
  • D.成本约 6.0 美元

答案：C。按成本公式 C = (800×3 + 200×6)/1000 = (2400 + 1200)/1000 = 3.6 美元。输入输出分别计价、输出更贵是云 API 的通用计费模式，误选 A 是把输出按输入单价算，误选 B 是漏算输出部分。

Q6. 关于 Phoenix 工具，下列说法正确的有？

多选题 · mid

  • A.支持执行链路可视化← 正确答案
  • B.开源且可本地化部署← 正确答案
  • C.只能用于云端托管服务
  • D.支持嵌入向量质量分析← 正确答案

答案：ABD。Phoenix 是开源可本地部署的可观测性平台（A、B 对），支持执行链树状可视化，还提供 embedding 聚类与检索质量分析（D 对）。它不限定云端托管（C 错），本地 Jupyter 或服务均可运行。

Q7. 关于错误诊断，正确的做法包括？

多选题 · mid

  • A.只查看最终产生的错误提示
  • B.定位到出错的 Span 节点← 正确答案
  • C.对比成功与失败的轨迹← 正确答案
  • D.忽略所有偶发性的超时错误

答案：BC。错误诊断应定位具体出错的 Span（B 对），并对比成功与失败轨迹找出差异（C 对）。只看最终错误提示会丢失上下文（A 错）；偶发超时可能是系统设计缺陷的信号，不能直接忽略（D 错）。

Q8. 某 Agent 执行 4 步耗时分别为 200ms、800ms、300ms、100ms，瓶颈步骤耗时占比为？

单选题 · mid

  • A.200ms 步骤占比约 28.6%
  • B.800ms 步骤占比约 57.1%← 正确答案
  • C.300ms 步骤占比约 71.4%
  • D.100ms 步骤占比约 42.9%

答案：B。总耗时 = 200 + 800 + 300 + 100 = 1400ms，最长步骤 800ms，占比 800/1400 ≈ 57.1%。超过 50% 说明该步骤是决定性瓶颈，优化它收益最大，这正是瓶颈占比公式的意义所在。

Q9. Agent 连续处理 10 轮对话，每轮新增历史 1200 Token，且每次请求都把全部历史注入输入，则 10 次请求因历史注入累计消耗输入 Token 为？

单选题 · extreme

  • A.累计约 1.2 万个 Token
  • B.累计约 6.6 万个 Token← 正确答案
  • C.累计约 7.2 万个 Token
  • D.累计约 13.2 万个 Token

答案：B。第 i 次请求注入 1200×i 个 Token，总消耗 = 1200×(1+2+…+10) = 1200×55 = 66,000，即约 6.6 万个。选 A 是只算了最后一轮的 1.2 万；选 C 是按 1200×60 误算；选 D 是把历史重复计算了两遍。

Q10. Agent 可观测性优化的最佳实践包括？

多选题 · hard

  • A.全链路追踪并使用唯一标识← 正确答案
  • B.Token 成本按调用维度聚合← 正确答案
  • C.失败轨迹单独归档并复盘← 正确答案
  • D.只需关注最终生成的结果

答案：ABC。最佳实践是给每次执行打上唯一 trace_id 实现全链路追踪（A 对），按调用维度聚合 Token 定位成本结构（B 对），并把失败轨迹归档以持续复盘（C 对）。只关注最终结果（D 错）会错过大量中间环节的问题信号，这正是可观测性要解决的痛点。