考察点
Agent 可观测性是「Agent 性能量化评估」这道高频题的自然延伸，面试官想确认你的 Agent 在生产环境是「透明的」：出了问题能回放整个决策过程，而不是对着一个错误答案干瞪眼。考点集中在 trace 怎么设计、指标怎么聚合、成本怎么归因。追问常往「trace 数据量太大怎么存」和「怎么从监控走到自动止损」走。
参考答案
为什么传统 APM 不够用
传统微服务监控看的是请求-响应：一次调用一个 span，看状态和耗时。Agent 的一次用户请求内部是几十次模型调用和工具调用的链式组合，且每一步的输出决定下一步的走向——光看「这次请求 200、耗时 15 秒」完全无法回答「为什么答错了」。可观测性的重心从「服务健康」扩展到「决策过程可回放」，数据模型从 span 树变成有向的、带语义内容的轨迹。
Trace 设计：一次任务一条完整链
工程上用 OpenTelemetry 作为埋点标准，每次用户任务生成一个 trace_id，内部所有步骤（LLM 调用、工具调用、检索、审核）作为 span 挂上去，多 Agent 场景还要跨服务传播这个 id。每个 span 记录的关键字段：
- LLM 调用：模型版本、完整 prompt（含 system 和上下文）、原始输出、解析后的 tool_calls、输入输出 token 数、耗时、温度等参数。
- 工具调用：工具名、入参、返回结果（或截断后的摘要）、状态码、重试次数。
- 控制流：规划器的决策理由（ReAct 的 thought 部分）、步数序号、循环检测标记。
两个工程取舍值得说。一是内容 vs 体积：完整 prompt 和输出对归因最有价值，但量大且可能含敏感信息，做法是内容全文进对象存储、trace 系统只存引用和摘要，敏感字段脱敏后入库。二是采样：全量存 trace 成本高，常见策略是失败任务和低分任务全量存、成功任务按比例采样存，保证诊断数据密度向问题倾斜。
平台选型上 Langfuse、LangSmith 这类 LLM 观测平台已经把上述模型做好了，自研的话核心是把「按 trace 回放整段决策过程」这个交互做顺，这是使用频率最高的功能。
指标体系：按步维度聚合
有了 trace 数据，指标分三组：
质量组：任务成功率（按意图/场景拆分）、judge 评分趋势、无效步骤占比、死循环次数、工具调用失败率和参数错误率。这组指标接告警，成功率单小时下跌超阈值就要响。
性能组：端到端 P50/P95 延迟、首 token 延迟（流式体验）、单步延迟分布。单步延迟分布很有诊断价值——P95 高常常不是模型慢，而是某个工具接口慢或者某类任务的步数异常多。
成本组：单任务平均 token、按模型/按场景/按租户拆分的成本、每日累计成本对预算的消耗速率。成本告警要设「速率告警」而不只是「总量告警」——某个 Agent 陷入死循环会在一小时内烧掉一天的预算，总量告警发现时已经晚了。
从监控到止损
可观测性的高级阶段是自动止损。几个实战规则：单任务步数超上限（比如 20 步）强制终止并降级为人工或兜底回复；单任务成本超阈值熔断；同一工具连续失败 N 次自动摘除该工具并在 prompt 层面隐藏；某租户成本速率异常自动限流。这些规则让系统在没人盯的时候也不会出大事故。
Trace 数据的第二生命
trace 库不只是运维工具，它是团队最重要的数据资产：badcase 归因从 trace 开始；高质量成功轨迹蒸馏成微调数据；失败轨迹聚类后指导工具描述和 prompt 的优化方向；评测集从真实 trace 里采样构建。可以说评估、优化、微调三条工作流都长在 trace 基础设施上，这也是为什么可观测性应该在 Agent 项目的第一天就建好，而不是上线后再补。
可能的追问
- 多 Agent 系统的 trace 怎么串？ 答：统一 trace_id 跨 Agent 传播（HTTP header 或消息队列元数据），每个 Agent 内部是子 trace，观测平台按父子关系渲染。关键是任务分解和结果合并两个交接点要记全，大多数多 Agent bug 出在信息交接丢失。
- trace 里存了用户数据，合规怎么处理？ 答：入库前脱敏（手机号、身份证、银行卡正则加模型双重识别替换），存储设保留期（比如 30 天热数据、之后归档或删除），访问 trace 平台要权限控制和审计日志。
- 怎么判断步数上限设多少？ 答：看线上成功任务的步数分布，取 P99 再加一点余量。设太低会误杀复杂任务，设太高失去死循环保护。分布本身也要监控——平均步数悄悄上涨通常是检索质量或工具可靠性退化的前兆。