Agent可观测性应包含哪些维度和指标

1️⃣ 考察意图

面试官想看你能否跳出传统微服务可观测性的“三大支柱”（日志、指标、链路），针对Agent系统的特殊性——LLM调用不可控、工具调用有副作用、决策链长且非确定性——给出系统性设计。考察类型是系统设计+工程取舍，刁钻点在于：Agent的“成功”不是HTTP 200，而是任务完成质量；LLM的延迟和Token消耗是核心成本，但传统监控不关注。答好了能展示你对Agent生产化落地的硬实力，包括成本控制、故障定位和SLA保障。

2️⃣ 标准答

Agent可观测性需覆盖三个核心维度：调用链、性能与成本、质量与安全。每个维度对应不同指标和工具，下面拆解。

维度一：调用链（Trace）—— 还原Agent决策路径

Agent的每次任务是一个有向无环图（DAG），包含LLM调用、工具调用、中间结果。传统微服务Trace只记录RPC调用，这里必须扩展：

LLM调用：记录prompt、response、Token消耗（input/output）、模型名、temperature。用OpenTelemetry的Span封装，属性（attributes）带上llm.model、llm.prompt、llm.completion_tokens。
工具调用：记录工具名、输入参数、输出结果、HTTP状态码、执行时长。关键：工具调用可能有副作用（如写数据库），Trace必须能关联到业务ID。
决策节点：Agent的“思考”步骤（如ReAct的Thought），记录中间推理和选择的工具。用Span的events字段打点。
实现：集成OpenTelemetry SDK，用Jaeger或Zipkin做后端。坑：Agent的Trace可能很长（几十个Span），全量采样成本高。解法：动态采样——对错误Trace全量采样，成功Trace按1%采样；或用Head-based sampling，根据任务ID哈希决定是否采样。

维度二：性能与成本（Metrics）—— 量化延迟与Token消耗

Agent的延迟和Token消耗是直接成本，必须实时监控。指标分三层：

端到端指标：任务完成率（成功/失败/超时）、P50/P95/P99延迟（从用户请求到最终响应）、重试次数（LLM调用失败后重试）。Trade-off：P99延迟高可能是LLM慢，也可能是工具调用阻塞，需结合Trace定位。
LLM指标：每次调用的延迟、Token使用量（input+output）、错误率（rate limit、context length exceeded）。用Prometheus的Histogram记录延迟分布，Counter记录Token消耗。坑：Token消耗是累计值，但Agent可能多次调用同一LLM，需按任务ID聚合。解法：在Trace的Span中记录Token，用Prometheus的Exemplar关联TraceID。
工具指标：调用次数、成功率、平均延迟。对HTTP工具，记录状态码分布（2xx/4xx/5xx）。实际落地：某Agent调用外部API时，4xx错误率突增，通过工具指标发现是认证Token过期，立即触发告警。

维度三：质量与安全（Logs + 审计）—— 确保任务正确性

Agent的“成功”不是HTTP 200，而是任务完成质量。需要：

任务质量指标：用户满意度（通过反馈按钮打分）、任务完成率（用户明确确认完成）、错误类型分布（LLM幻觉、工具调用失败、超时）。用ELK收集日志，日志中带上task_id、user_id、error_type。
安全审计：LLM的prompt和response可能含敏感信息（PII），必须脱敏。用正则或NLP模型过滤，日志中只保留脱敏后的摘要。坑：脱敏可能破坏调试能力。解法：在日志中保留原始数据但加密存储，只有授权人员可解密。
告警设置：多级告警——P99延迟>5s触发P0告警（影响用户体验），Token消耗日环比增长>20%触发P1告警（成本异常），错误率>5%触发P2告警。用Grafana的Alerting规则，结合Prometheus的rate函数。

总结

Agent可观测性不是简单堆工具，而是按维度分层：Trace还原决策链，Metrics量化成本与性能，Logs保障质量与安全。核心取舍：采样策略平衡成本与可观测性，脱敏平衡安全与调试。

3️⃣ 答题模板（30 秒电梯版）

“这个问题我从三个维度回答：第一，调用链维度，用OpenTelemetry记录LLM和工具调用的Trace，动态采样控制成本；第二，性能与成本维度，用Prometheus监控延迟、Token消耗和错误率，P99延迟>5s触发告警；第三，质量与安全维度，用ELK收集日志并脱敏PII，结合用户反馈评估任务质量。总结一句：Agent可观测性要覆盖决策链、成本和质量，核心是采样策略和脱敏的工程取舍。”

4️⃣ 高频追问 & 应对

追问 1：Agent的Trace很长（比如50个Span），全量采样成本太高，你怎么设计采样策略？

采用分层动态采样：第一层，基于错误——错误Trace全量采样（因为故障定位需要完整链路）；第二层，基于任务类型——高价值任务（如支付）全量采样，低价值任务（如闲聊）按1%采样；第三层，基于延迟——P99延迟>3s的Trace全量采样（慢任务可能隐藏问题）。实现上用OpenTelemetry的Sampler接口，结合任务ID哈希。坑：采样后可能丢失低概率异常，需定期做全量采样快照（比如每1000个任务全量采样一次）来校准。

追问 2：如何区分Agent的“成功”和“失败”？HTTP 200不代表任务完成。

定义任务级成功指标：用户明确确认（如点击“完成”按钮）算成功；LLM输出被用户修改后提交算部分成功；用户超时未响应或主动取消算失败。实现上，在Agent的最后一个Span中记录task_result属性（success/partial/failure），并关联用户反馈日志。Trade-off：用户反馈有延迟，不能实时监控。解法：用代理指标——LLM调用次数异常（正常任务平均3次，超过5次可能失败）、工具调用失败率>50%等，作为实时告警依据。

追问 3：Agent调用LLM时，Token消耗波动大，如何设置合理的告警阈值？

不设固定阈值，用动态基线：基于历史7天的Token消耗数据，用Prometheus的predict_linear函数预测未来趋势，或使用季节性分解（如STL算法）识别周期性波动。告警规则：当日Token消耗超过基线+3σ时触发。坑：新功能上线时基线不准。解法：上线后24小时内用百分比增长告警（如环比增长>50%），之后切换为动态基线。

5️⃣ 避坑 · 常见错误答法

❌ 只提“日志、指标、链路”三大支柱，不针对Agent特殊性（如LLM调用、工具副作用）。 → ✅ 必须强调Agent的Trace是DAG结构，LLM调用和工具调用是核心Span，且需要记录prompt和Token消耗。
❌ 说“用Prometheus监控所有指标”，忽略Token消耗和任务质量。 → ✅ 明确指标分层：LLM延迟、Token消耗、工具成功率、任务完成率，并给出具体Prometheus指标类型（Histogram、Counter、Gauge）。
❌ 认为“全量采样是标准做法”，不考虑成本。 → ✅ 必须讨论采样策略（动态采样、Head-based sampling），并给出具体数字（如错误Trace全量，成功Trace 1%）。

6️⃣ 简历呼应

如果你有RAG项目：从“RAG的检索+生成链路与Agent的决策链类似”切入，强调你已用OpenTelemetry追踪检索和LLM调用，可扩展至Agent的工具调用和中间结果。
如果你只做过传统微服务监控：用“微服务Trace的Span类比Agent的决策节点”迁移，强调你熟悉Prometheus和Grafana，但需补充LLM调用和Token消耗的指标设计。
如果你是校招无项目：聚焦“论文复现”——引用《AgentBench》或《ToolLLM》中的评估框架，说明你理解Agent的“任务成功率”指标，并设计过简单的Trace demo（如用Python的opentelemetry-api记录LLM调用）。
《OpenTelemetry Semantic Conventions for LLM》—— 官方LLM调用Span规范
《AgentBench: Evaluating LLMs as Agents》—— 任务级评估指标设计
《Prometheus + Grafana 监控最佳实践》—— 指标采集与告警规则
《Jaeger 分布式追踪实战》—— Trace采样策略与Span设计
《LLM 应用的可观测性：从日志到成本控制》—— 博客，聚焦Token消耗监控

—— 本场面试完 ——