Appearance
一句话总结:可观测性 = Trace(追踪)+ Evaluation(评估)+ Monitoring(监控)三合一——看到 Agent 每一步在做什么、每步花多少 token、失败在哪一步,再用评估闭环把生产问题转成系统性改进;生产级 Agent 没有它等于盲飞。
三合一公式(面试默写)
可观测性 = Trace + Evaluation + Monitoring
| 组件 | 做什么 | 解决什么 |
|---|---|---|
| Trace 追踪 | 记录完整执行树:每次 LLM 调用、工具调用、检索、推理链 | "Agent 到底干了什么" |
| Evaluation 评估 | 自动/人工给输出打分 | "干得好不好" |
| Monitoring 监控 | 看板:token 趋势、QPS、错误率、延迟、成本 | "现在稳不稳、贵不贵" |
看得到什么(价值清单)
- 每步输入输出:LLM 调了什么 Prompt、返回了什么
- 每步耗时:哪个工具是瓶颈
- 每步 token 消耗:成本归因
- 失败发生在哪一步(而不是靠猜)
- 生产环境整体质量趋势
Tracing 实现
- LangSmith:框架无关可观测平台,Python/TS/Go/Java SDK 接入任意栈;显示完整执行树(含 Agent 内部"独白"与每步模型参数)
- OpenTelemetry:更底层的标准(与 LangSmith 是互补关系)
- 成本跟踪:自动记录 token 用量与成本(inputs×price + outputs×price),按会话/任务/Agent/用户聚合——能揪出"简单任务耗巨量 token 的低效 Agent"(常因 system prompt 太啰嗦,对接 AI基础概念-上下文工程实战与Prompt缓存)
EvalOps 闭环(从生产到改进)
- Tracing 收集生产 trace
- Annotation Queues:领域专家无需工程技能即可标注/纠错生产 trace
- LLM-as-a-judge:用 LLM 按自定义标准自动评分数千条运行
- 生产→开发反馈回路:真实问题转成系统性改进(回归测试集)
监控看板核心指标
| 指标 | 含义 |
|---|---|
| Token 消耗趋势 | 每天/每小时用量 |
| QPS | 并发负载 |
| 错误率 | 请求失败比例 |
| 平均延迟 | 响应速度趋势 |
| 成本预估 | 基于 token 的实时费用 |
面试要点
- 能默写三合一公式并各说一句作用
- 能说出可观测性解决的 5 类问题(输入输出/耗时/token/失败定位/质量趋势)
- 能讲 EvalOps 闭环 4 步(trace → 专家标注 → LLM judge → 反馈改进)
- 能举成本归因例子(按 agent/会话聚合揪出低效 prompt)——工程落地感是拉分点
相关概念
- [AI-Agent-评估评测](/学习笔记/AI技术/AI Agent/AI-Agent-评估评测) — 评估方法论
- [AI-Agent-生产部署](/学习笔记/AI技术/AI Agent/AI-Agent-生产部署) — 部署与 FinOps
- [AI-Agent-框架内部机制](/学习笔记/AI技术/AI Agent/AI-Agent-框架内部机制) — trace 的图执行来源
- AI基础概念-上下文工程实战与Prompt缓存 — 成本优化的上游