Agent可观测性与质量保障#
一句话答案#
Agent 可观测性通过全链路 Trace（每步思考/工具调用/耗时/token）、核心 Metrics（任务成功率/延迟/成本）和质量保障体系（灰度发布/A-B 测试/回归评测）保障生产稳定。
核心要点
1. Agent Trace 设计#
每步记录思考过程、动作、工具参数、结果、延迟和 Token 消耗：
Step 1: { thought: "需要查询用户订单", action: "call_tool",
tool: "query_order", params: {user_id: 123},
result: {order_id: 456, status: "shipped"},
latency_ms: 230, tokens: {input: 150, output: 45} }
Step 2: { thought: "已获取订单信息，生成回答", action: "final_answer",
result: "您的订单456已发货...",
latency_ms: 180, tokens: {input: 280, output: 60} }与传统微服务链路追踪的区别：传统 Trace 记录服务间调用；Agent Trace 还要记录 LLM 的思考过程和决策逻辑，每步都有不确定性。
2. 核心 Metrics#
| 指标 | 意义 | 告警阈值 |
|---|---|---|
| 任务成功率 | 端到端完成率 | < 80% |
| 平均迭代次数 | Agent 效率（步数越少越好） | > 5 次 |
| 工具调用准确率 | 选对工具的比例 | < 90% |
| P99 延迟 | 用户体验底线 | > 10s |
| Token 消耗/请求 | 成本控制 | 超预算 120% |
| 幻觉率 | 回答可靠性 | > 5% |
3. 可观测性工具链#
| 工具 | 定位 | 特点 |
|---|---|---|
| Langfuse | LLM 全链路追踪 | 开源，支持 Trace/Score/Dataset |
| LangSmith | LangChain 官方 | 与 LangChain 深度集成 |
| Arize Phoenix | LLM 监控 + 评测 | 实时监控，漂移检测 |
4. 质量保障流水线#
离线评测（回归测试集）
→ 影子流量对比（新旧版本跑同一批请求，比对结果）
→ 灰度发布（5% → 25% → 100%）
→ A/B 实验（线上随机分流，统计显著性检验）
→ 持续监控（Metrics 告警 + 人工抽检）5. Demo 为什么上不了生产#
| Demo 阶段 | 生产要求 |
|---|---|
| 无错误处理 | 每步都有降级兜底 |
| 无超时控制 | 工具调用 + LLM 调用都有超时 |
| 无可观测性 | 全链路 Trace + 告警 |
| 无成本控制 | Token 预算 + 模型级联 |
| 无安全防护 | 注入检测 + 权限控制 |
面试回答（2分钟版）
Agent可观测性要解决的核心问题是”Agent在生产环境出了问题怎么查”。我把它分三个维度：Trace、Metrics和质量保障。Trace设计上，Agent每一步都要记录思考过程Thought、执行动作Action、工具调用和返回结果、耗时和token消耗，形成完整的执行链路可以回放排查。核心Metrics关注六个指标：任务成功率要大于80%，平均迭代次数不超过5次代表Agent效率，工具调用准确率要90%以上，P99延迟不超过10秒保证用户体验，token消耗控制在预算内，幻觉率低于5%。工具链方面推荐Langfuse做LLM全链路追踪，支持Trace打分和数据集管理。质量保障是重点：上线前跑离线回归测试集，用影子流量对比新旧版本，灰度发布从5%逐步放量到100%，线上持续A/B实验和人工抽检。很多Agent项目Demo效果很好但上不了生产，本质就是缺了错误处理、超时控制、可观测性、成本控制和安全防护这五个维度。
追问与易错
追问方向：
- Agent 的 Trace 怎么设计？和传统微服务链路追踪有什么区别？ → Agent Trace 多了 Thought/Action 语义信息和 token 消耗维度，传统 Trace 只有 RPC 调用链。DocMind 用 TracedOp 封装 OTel Span，每步记录思考/动作/工具/耗时/token
- 怎么判断 Agent 是”真的好”而不只是”会演示”？ → 跑离线评测集（覆盖 factual/adversarial/unanswerable 等边界），看 Faithfulness 和拒答率。Demo 通常只测 happy path，评测要覆盖失败场景
- 灰度发布怎么做？新旧版本结果不一致怎么判断哪个好？ → 灰度 5%→25%→100%，用影子流量新旧版本跑同一批请求对比 Metrics。判断标准：Faithfulness 不降 + Recall 不降 + 延迟不涨 + 成本不涨
- 线上 Agent 突然变差了怎么排查？ → 按链路逐段查：检索端（Recall 下降?）→ 生成端（模型更新?）→ 工具端（API 异常?）。Langfuse Trace 可定位到具体哪一步出问题
易错点：
- ❌ “任务成功率是唯一指标” → 还要看效率（迭代次数）、成本（token）、延迟（P99）
- ❌ “上线前测好了就行” → 模型更新、数据漂移会导致线上退化，需要持续监控
- ❌ “灰度就是慢慢放量” → 还需要对比实验，判断新版本是否真的更好
项目实践（DocMind）： Langfuse + OpenTelemetry 全链路追踪。TracedOp 工具类把 14 行 Span 模板代码封装成 4 行（tracer + name + attrs + lambda），每步记录 latency/tokens/attributes。评测体系：52 query × 7 类别 × 4 pipeline 变体（纯向量→+BM25→+Rerank→+Reflection）× 3 轮取均值。关键发现：Self-Reflection 在流式模式下是 no-op（SSE flush 阻止了中途改写），但置信度分流仍有独立价值——70% 高分短路省 LLM 调用，30% 低分触发 Web Search 兜底。