By 黄金金枪鱼 
一、面试官为什么问这道题
「AI Agent 的可观测性」是中级到资深 Agent 工程师的必问题。它考的不是「会不会打印日志」，而是**面对一个多步推理、多工具调用、多模型协作的系统，能否像对待传统微服务一样搭建完整监控链路**。
典型失败：(1) 只看 console.log 抓异常；(2) 不区分 token cost 与延迟；(3) 没有 trace 串联多步调用。面试官想听的是：**你有「把 Agent 当分布式系统」的系统观**。
本文拆解 5 类核心指标 + 3 种埋点策略 + OpenTelemetry 方案，覆盖 Agent 全链路可观测。
二、5 类核心指标：Agent 监控不能只看成功率
传统微服务看「QPS / 延迟 / 错误率」三件套，Agent 多了一组**业务级**指标：
| 类别 | 指标 | 含义 | 业务影响 |
|------|------|------|----------|
| 成本 | `llm_token_total` / `cost_usd` | 单次请求消耗的 token 与美元成本 | 直接影响毛利 |
| 性能 | `latency_ms` / `ttft_ms` | 端到端延迟 + 首 token 延迟 | 用户体验 |
| 质量 | `success_rate` / `tool_call_accuracy` | 任务完成率 + 工具调用准确率 | 业务效果 |
| 稳定性 | `error_rate` / `retry_count` | 异常率与重试次数 | SLA 保障 |
| 业务 | `user_satisfaction` / `task_completion` | 用户反馈 + 业务漏斗 | 长期价值 |
**关键洞察**：很多团队把 Agent 当黑盒只看 `success_rate`，结果上线 1 个月发现**成本失控**——单用户日均成本超预期 3 倍。**成本指标必须和性能指标并列监控**，否则「系统跑得好」和「系统跑得便宜」是两个完全不同的问题。
三、埋点策略 1：框架层（LangSmith / LangChain Callback）
**最简单但功能强**：用框架自带的 callback 系统。
**优势**：零代码侵入，3 行配置即可拿到完整调用链。
**局限**：(a) 锁死框架；(b) 数据在 SaaS 上，敏感场景不合规；(c) 自定义业务维度困难。
适合：**PoC 阶段 + 中小团队 + 不涉及强合规**。
四、埋点策略 2：协议层（MCP Server 端到端 tracing）
**Agent 时代特有的视角**：把所有 MCP Server 调用当成「分布式 RPC」，每个 tool call 都是一次远程过程调用。
落地 3 步：
1. **MCP Server 端**：在每个 tool handler 入口注入 OpenTelemetry span，span name = tool name，attributes 包含 input hash（不存原文）+ 耗时 + 错误码
2. **MCP Client 端**：在每次 `tools/call` 请求时记录 parent span context，通过 `_meta` 字段透传到 Server（标准 MCP 协议支持 trace propagation）
3. **协议网关**：在 MCP 代理层（如果有）记录所有 JSON-RPC 消息的延迟分布与错误码
**优势**：跨进程可串联，trace 能从用户输入一直串到具体 tool 实现。
**局限**：需要 MCP Server 实现支持自定义 span 注入。
适合：**自研 MCP Server + 多 Server 协作 + 中大型团队**。
五、埋点策略 3：业务层（自定义 span + 业务标签）
**最深也最灵活**：在业务代码里手插 span，加业务专属标签（用户分群 / A/B 实验 / 业务节点）。
典型应用：
**关键实践**：所有业务 span 必须沿用同一 `trace_id`，否则 trace 串不起来。推荐**入口处生成 trace_id，全程透传**。
**OpenTelemetry 完整链路**（最工业级方案）：
| 组件 | 角色 | 部署 |
|------|------|------|
| OTel SDK | 应用内 span 生成 | 嵌入业务代码 |
| OTel Collector | span 聚合 + 路由 | DaemonSet 或 Sidecar |
| Prometheus | 指标存储 | 长期保留 |
| Grafana | 仪表盘 | 团队共享 |
| Jaeger / Tempo | trace 存储 | 排查用 |
六、生产实战：3 个最常被忽视的细节
**细节 1：Token 计费要按模型分桶**
OpenAI GPT-4o、Claude 3.5 Sonnet、DeepSeek V3 单价差 50 倍，混在一起算「平均 token 成本」会掩盖问题。**必须按 `model` 维度分别统计**。
**细节 2：工具调用失败要区分 4 类错误**
不同错误对应不同修复路径，**别都归为「工具失败」**。
**细节 3：缓存命中要单独埋点**
启用 Anthropic prompt caching 或 OpenAI batch 后，**「cache hit」与「cache miss」的成本差 10 倍**。没埋点就不知道自己有没有用上缓存。
七、面试答题模板（生产工程师视角）
按 STAR-L 法则组织答案：
1. 先用 LangSmith 跑通 PoC（框架层）
2. 给自研 MCP Server 加 OTel SDK（协议层）
3. 关键业务路径加自定义 span（业务层）
4. Grafana 看板 + Alert Rule 接入告警
八、关键点
行业影响 / 展望
可观测性正成为 Agent 平台的「水电煤」。2026 年上半年，LangSmith、Langfuse、Phoenix（Arize）、Helicone 等开源 / SaaS 工具集中爆发，把 LLM 可观测性从「大厂专属」拉到「中小团队也能用」的水平。
未来 12 个月有 3 个值得聚焦的方向：(1) **Agent 专属 trace 标准**—— OpenTelemetry 正起草 LLM 语义约定；(2) **成本监控前置**—— CI/CD 阶段预估单请求成本；(3) **质量监控自动化**——用 LLM-as-Judge 形成质量闭环。
对求职者而言，「会调 LLM API」已是基本功，**「会用 OTel 把 Agent 全链路打通」** 才是 2026 年下半年 Agent 工程师的差异化能力。
参考资料
**官方文档**
**开源项目**
**行业报道**
**社区讨论**
**对比基准**
**本文由 AI 生成**。内容基于公开资料整理，可能存在事实偏差，引用链接请以原始来源为准。