为什么 Demo 能跑，上线却「看不见」
在前一篇生产化实践里，我们谈了护栏、成本与评估集。很多团队把评估集建好后，仍然会遇到一个尴尬局面：用户反馈「答错了」，你却无法还原那一次请求里调了哪些工具、哪一步超时、上下文被截断到哪里。
可观测性不是 APM 厂商的专属名词。对 Agent 来说，它要解决的是：一次用户意图如何经过 LLM 与工具链，最终变成可见的结果或失败。
三个最小信号：Trace、Span、结构化日志
我们建议从三个信号开始，而不是一上来就上全套 Grafana。
Trace ID：每个用户请求分配全局 trace_id，在所有日志、工具回调、异步任务里透传。排查时按 trace 聚合，而不是按时间大海捞针。
Span：把一次 LLM 调用或一次工具执行记为一个 span，记录耗时、输入摘要、输出摘要、是否重试。多 Agent 场景下，子 Agent 的 span 挂在父 trace 下，才能看清「谁委托了谁」。
结构化日志：抛弃纯文本拼接，至少固定字段：trace_id、span、agent、tool、latency_ms、tokens_in/out、status。后续无论是进 ELK、Loki 还是云日志，都能过滤聚合。
{"trace_id":"t_8f2a","span":"tool:kb_search","tool":"kb_search","latency_ms":420,"status":"ok"}工具链追踪：比「最终答案」更重要
Agent 调错工具时，用户看到的是一句胡话；工程师需要的是工具决策链。建议在编排层记录：
- 模型收到的 tools schema 版本
- 每次
tool_call的名称、参数、返回码 - 若启用 RAG，记录检索 query、命中文件路径、片段 hash（与记忆与 RAG 实战里的出处原则一致）
这样当评估集里新增一条失败样本时，你能直接关联到对应的 trace，而不是重新猜 prompt。
指标：延迟、成功率与 token 成本
生产化必须同时看体验与账单：
| 指标 | 用途 |
|---|---|
| P95 端到端延迟 | 发现慢工具或过长上下文 |
| 工具调用成功率 | 识别脆弱的外部依赖 |
| 每 trace token 消耗 | 与护栏联动做预算告警 |
这些指标可以和上一篇里的成本控制共用同一套看板：护栏拦截算「预防」，指标异常算「发现」。
失败样本如何回流评估集
可观测性的终点，是让失败可复现、可回归：
- 从结构化日志筛选
status=error或用户点踩的 trace - 自动抽取「用户问题 + 工具链 + 最终回答」生成候选样本
- 人工审核后写入评估集（避免把 PII 直接入库）
- 发版前跑回归，与 CI 集成
经验判断：评估集样本增长过快时，优先修高频工具失败，而不是堆更多 prompt 技巧。
小结
可观测性应和生产化一起设计：Trace 贯穿请求、Span 刻画工具链、结构化日志支撑检索，再把失败样本回流评估集，形成「上线—观测—改进」闭环。
延伸阅读：多 Agent 编排实战、工具调用设计详解。
本文为《从零到上线》Agent 应用开发系列第 6 篇。
发表回复