真实面经题目 · 原创解析
这题考 Agent 可观测平台该记录什么，以及如何把 trace 用于调试和评估。好的回答要覆盖请求级 trace、LLM 调用、工具调用、检索、记忆、planner、guardrail、人工反馈、成本延迟和评测结果，并说明 LangSmith 与 Langfuse 都可以承载调试和评估闭环，但选型应基于技术栈、部署合规、数据治理、评测流程、成本和集成方式，而不是简单说谁更强。
Agent 可观测平台我会按三类数据设计：运行 trace、质量评估、运营指标。运行 trace 是最基础的，一次用户请求要有 root trace，下面挂 LLM span、retrieval span、tool span、memory span、planner span、guardrail span 和 postprocess span；每个 span 记录输入输出摘要、模型或工具版本、prompt 版本、参数、错误、耗时、token、成本、重试和关联 ID。质量评估层要记录用户反馈、人工标注、自动打分、参考答案、任务是否完成、工具是否选对、参数是否有效、是否触发安全策略，并把线上失败样本沉淀到数据集和回归实验。运营指标层关注成功率、错误率、p50/p95 延迟、成本、工具失败率、人工接管率、版本对比和租户差异。LangSmith 和 Langfuse 的使用方式可以这样讲：如果系统大量基于 LangChain 或 LangGraph，LangSmith 在链路追踪、run 树、dataset、experiment、evaluator 和调试体验上通常接入成本较低；如果团队更看重开源自托管、数据留存控制、SDK 与 OpenTelemetry 接入、prompt 与成本分析，Langfuse 会是常见选择。这里不能把它们说成绝对替代关系，工程上更应该比较接入成本、是否能覆盖非 LangChain 代码、是否支持本地或私有化、评测工作流是否匹配、权限和脱敏是否满足合规、导出能力是否能进内部数仓。最终目标是让 trace 不只是排障页面，而是能回答为什么失败、哪个版本变差、哪些样本应回归、哪类工具最不稳定、一次改动是否提升了任务完成率。
Agent 可观测不只是看模型请求日志，而是回答四个问题：用户任务是否完成，失败发生在哪个决策环节，版本变化是否让质量变好，成本和延迟是否可控。因此平台需要同时覆盖调试、评估、告警、回归和运营分析。
一次请求应记录 root trace，下面拆成输入预处理、上下文组装、意图识别、planner、检索、LLM 调用、工具选择、工具调用、记忆读写、guardrail、后处理和响应输出。每个 span 的输入输出可以脱敏或摘要化，但必须能还原关键决策。
LLM 调用要记录模型名、provider、temperature、max tokens、streaming 情况、prompt 模板版本、system prompt、工具定义版本、输入输出 token、耗时、成本、finish reason、错误和重试。这样才能判断问题来自模型版本、prompt 改动、上下文长度、工具定义还是网络调用。
工具 span 要记录候选工具、最终工具、选择理由、参数、schema 校验、请求响应和服务端关联 ID。检索 span 要记录 query rewrite、召回源、top-k 文档、分数、过滤条件和最终注入上下文。否则 RAG 和 tool use 出错时只能看到模型回答错，无法定位证据链断在哪里。
线上 trace 中要能挂用户点赞点踩、人工标注、自动 evaluator 分数、参考答案、任务完成状态、错误类别和严重程度。高价值失败样本应能一键进入 dataset，后续新 prompt、新模型或新工具版本都用同一批样本回放比较。
从工程选型看，如果系统使用 LangChain 或 LangGraph 较多，LangSmith 的 run 树、trace 调试、数据集、实验和 evaluator 工作流通常比较顺手。它的价值在于把链路观测和实验对比连起来，方便回答某个链路为什么失败、某个 prompt 或模型版本是否变好。
Langfuse 常被用于多 SDK 或非单一框架的 LLM 应用观测，工程上可以关注自托管、OpenTelemetry 风格接入、prompt 管理、成本分析、用户会话、评分和数据导出能力。它的优势是否成立取决于团队部署方式、合规要求、已有观测栈和评测流程，而不是一个固定答案。
可观测平台不是只给开发看单条 trace，而要支撑版本发布门禁、线上质量回归、异常告警、成本治理和故障复盘。关键指标包括任务完成率、工具成功率、参数校验失败率、检索命中率、p95 延迟、单位任务成本、人工接管率和高危错误率。
理想情况下要能复现请求，但生产环境通常要做脱敏、采样和权限控制。可以记录 prompt 模板版本、变量摘要、上下文片段 ID、敏感字段掩码和必要的原文采样。对高风险业务，完整 prompt 只给授权人员查看，普通调试页面展示摘要和结构化字段。
不要只做一个总分。Agent 至少要拆成任务完成、事实正确性、工具选择正确性、参数有效性、引用证据质量、安全合规、格式可用性和用户体验。不同任务用不同 evaluator，并保留人工标注样本校准自动评估，避免 evaluator 自己漂移。
可以，但要避免双写后没有主数据口径。实践中可以短期双写做选型，或一个负责开发调试，一个负责统一观测和自托管数据治理。无论如何都要统一 trace_id、用户会话 ID、错误分类和评估指标，否则两套系统会产生两套不可比较的数据。
从线上失败和关键业务场景构建固定 dataset，对新模型、新 prompt、新工具 schema 做回放实验。门禁指标可以包括任务完成率不下降、严重错误不增加、工具参数错误率下降、p95 延迟和成本在预算内。只有离线通过后再灰度，灰度期间继续比较线上 trace 指标。
要在采集层做字段级脱敏和最小化采集，区分可检索字段、可展示字段和仅审计字段；存储层设置租户隔离、访问控制、留存周期和导出审计；调试层对敏感 prompt、用户输入、工具响应做权限控制。否则 trace 越完整，数据风险越高。
